[pgrouting-dev] postgis2 and driving distance

[Mario Basa]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120620/8d677eea/attachment.html>