[pgrouting-dev] postgis2 and driving distance

[Mario Basa]

Daniel,

They are all over the place. I am currently cleaning up matching.sql
in core since the routine_dd_wrapper.sql functions uses it.

Doing things like changing:

'select getsrid(the_geom) as srid from '||tbl||' where gid = (select
min(gid) from '||tbl||')'

to

'select st_srid(the_geom) as srid from '||tbl||' limit 1'


Actually I find this inconsistent since some sql files get the srid
via the above method while others it gets it from the geometry_column
metadata table. Either or is fine though except the latter assumes a
'the_geom' geometry column.

osm2po names its geometry column as 'geom_way' so there is a renaming
that has to be done.

I will try if it is possible to typecast a multilinestring into a
linestring so that st_startpoint will work.

Mario.




On Wed, Jun 20, 2012 at 2:37 PM, Daniel Kastl <daniel at georepublic.de> 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> 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
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>