Hi Mario,<div><br></div><div>Thank you for this information!</div><div>Which files exactly do you mean with "wrapper sql files"?</div><div><br></div><div>So this means the line geometry MUST be LINESTRING from now? Or is there an alternative function to ST_startpoint?</div>
<div>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.</div><div><br></div><div> In the past it just didn't matter if you had LINESTRING or MULTILINESTRING, right?</div>
<div>I will create a ticket for this.</div><div><br></div><div>Daniel</div><div><br><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <span dir="ltr"><<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Daniel,<br><br>You might want to limit st_startpoint usage in your devel-2.0 wrapper sql files. According to documentation:<br>
<br>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.<br><br>I used osm2po to create the Japan networks and am getting nulls when I use st_startpoint.<span class="HOEnZb"><font color="#888888"><br><br>Mario.</font></span><div class="HOEnZb">
<div class="h5"><br><br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <span dir="ltr"><<a href="mailto:daniel@georepublic.de" target="_blank">daniel@georepublic.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mario,<div><br></div><div>I think it's a good idea to drop CGAL if possible ... and you proofed that it is possible.</div>
<div>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.</div>
<div><br></div><div>If you move it into "core" (which is a good idea), please don't commit it into "master" branch for now.</div><div>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: <a href="https://github.com/pgrouting/pgrouting/tree/devel-2_0" target="_blank">https://github.com/pgrouting/pgrouting/tree/devel-2_0</a></div>
<div><br></div><div>Daniel</div><div><br></div><div><br><br><div class="gmail_quote"><div><div>On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <span dir="ltr"><<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi,<br><br>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. <br>
<br>I used this:<br><br>select st_concavehull(st_collect(<br> st_geomfromewkt('srid=4326;POINT('||x1||' '||y1||')')),0.7) from jp_2po_4pgr,<br> driving_distance('SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr <br>
where st_contains(ST_GeomFromEWKT(''SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))''),<br> the_geom) = true',156598,0.07,false,false) where id = edge_id;<br><br>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.<br>
<br>I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions. <br><br>Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.<span><font color="#888888"><br>
<br>Mario.<br> <br><br>
</font></span><br></div></div>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>
eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span><br>
</font></span></div>
<br>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span><br>
</div>