[pgrouting-dev] postgis2 and driving distance
Stephen Woodbridge
woodbri at swoodbridge.com
Wed Jun 20 08:15:37 PDT 2012
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
>
More information about the pgrouting-dev
mailing list