[pgrouting-dev] postgis2 and driving distance

[Daniel Kastl]

Hi Mario,

Thank you for this information!
Which files exactly do you mean with "wrapper sql files"?

So this means the line geometry MUST be LINESTRING from now? Or is there an
alternative function to ST_startpoint?
Maybe it's better that import tools like osm2po create a correct geometry
type as MULTILINESTRING doesn't make sense really for a routing network
anyway.

 In the past it just didn't matter if you had LINESTRING or
MULTILINESTRING, right?
I will create a ticket for this.

Daniel


On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <mario.basa at gmail.com> wrote:

> Daniel,
>
> You might want to limit st_startpoint usage in your devel-2.0 wrapper sql
> files. According to documentation:
>
> Changed: 2.0.0 no longer works with single geometry multilinestrings. In
> older versions of PostGIS -- a single line multilinestring would work
> happily with this function and return the start point. In 2.0.0 it just
> returns NULL like any other multilinestring. The older behavior was an
> undocumented feature, but people who assumed they had their data stored as
> LINESTRING may experience these returning NULL in 2.0 now.
>
> I used osm2po to create the Japan networks and am getting nulls when I use
> st_startpoint.
>
> Mario.
>
>
>
> On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel at georepublic.de>wrote:
>
>> Hi Mario,
>>
>> I think it's a good idea to drop CGAL if possible ... and you proofed
>> that it is possible.
>> I guess that PostGIS 2.0 will soon become a standard, so if we now want
>> to make a bigger cleanup and new release of pgRouting it's OK to require
>> PostGIS 2.0 in my opinion. There haven't been many questions about driving
>> distance on the lists, so I assume there are not so many users of this
>> function either.
>>
>> If you move it into "core" (which is a good idea), please don't commit it
>> into "master" branch for now.
>> I would propose to either make a different branch for that, that we can
>> merge later, or use "devel-2_0" branch, which already contains code
>> cleanup: https://github.com/pgrouting/pgrouting/tree/devel-2_0
>>
>> Daniel
>>
>>
>>
>> On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <mario.basa at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> It really is possible now to take away CGAL from pgRouting since
>>> st_concavehull of PostGIS 2 can create the same alpha shape. I have already
>>> managed to compile diriving-dist without CGAL installed by modifying the
>>> cmake files and drivedist.c.
>>>
>>> I used this:
>>>
>>> select st_concavehull(st_collect(
>>>   st_geomfromewkt('srid=4326;POINT('||x1||' '||y1||')')),0.7) from
>>> jp_2po_4pgr,
>>>   driving_distance('SELECT id,source,target,cost,reverse_cost from
>>> jp_2po_4pgr
>>>   where st_contains(ST_GeomFromEWKT(''SRID=4326;POLYGON((139 35,139
>>> 36,140 36,140 35,139 35))''),
>>>   the_geom) = true',156598,0.07,false,false) where id = edge_id;
>>>
>>> to create the drive time polygon in the attached screen dump. The
>>> performance isn't so bad even with a 0.7 target percent parameter for the
>>> concave hull.
>>>
>>> I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and
>>> start using the newer st_* postgis functions.
>>>
>>> Will there be any objections if I move routing_dd into core instead of
>>> extra since it will now only use BOOST to compile.
>>>
>>> Mario.
>>>
>>>
>>>
>>> _______________________________________________
>>> pgrouting-dev mailing list
>>> pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>
>>>
>>
>>
>> --
>> Georepublic UG & Georepublic Japan
>> eMail: daniel.kastl at georepublic.de
>> Web: http://georepublic.de
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>


-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120620/2edecbf1/attachment.html>