[pgrouting-dev] postgis2 and driving distance

Thu Jun 21 01:38:41 PDT 2012

cool. thanks Steve.

Mario.

On Wed, Jun 20, 2012 at 11:15 PM, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> You should be able write a simple wrapper for st_startpoint like:
>
> create or replace function pgr_startpoint(line geometry)
> returns geometry as
> $body$
> declare
>  pnt geometry;
> begin
>  if geometrytype(line) = 'LINESTRING' then
>    pnt := st_startpoint(line);
>  elsif geometrytype(line) = 'MULTILINESTRING' then
>    pnt := st_startpoint(st_geometryn(line,1));
>  else
>    return null;
>  end if;
>  return pnt;
> end;
> $body$
>  language plpgsql stable;
>
> I think we need to support MULTILINESTRING because the shapefile loader
> creates then by default. I understand that "real" MULTILINESTRING objects
> may not make sense but we can also just state the ALL MULTILINESTRING
> objects will be treated as those it is a valid contiguous path from start
> point to end point and that it is the users responsibility for model the
> graph correctly if they have a different interpertation of what a
> MULTILINESTRING means in their models.
>
> -Steve
>
>
> On 6/20/2012 2:37 AM, Daniel Kastl wrote:
>>
>> 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
>> <mailto: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
>>    <mailto: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 <mailto: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
>>            <mailto:pgrouting-dev at lists.osgeo.org>
>>
>>            http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>>
>>        --
>>        Georepublic UG & Georepublic Japan
>>        eMail: daniel.kastl at georepublic.de
>>        <mailto:daniel.kastl at georepublic.de>
>>        Web: http://georepublic.de <http://georepublic.de/>
>>
>>        _______________________________________________
>>        pgrouting-dev mailing list
>>        pgrouting-dev at lists.osgeo.org
>> <mailto:pgrouting-dev at lists.osgeo.org>
>>
>>        http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>>    _______________________________________________
>>    pgrouting-dev mailing list
>>    pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
>>
>>    http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>>
>> --
>> Georepublic UG & Georepublic Japan
>> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
>> Web: http://georepublic.de <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