<div>For what it's worth:</div><div><br></div>Wouldn't get too excited about the PostGIS 2.0 implementation of st_concavehull. It does allow for more flexibility but I found it to be a couple orders of magnitude slower than the pgRouting (CGAL) implementation. <div>
<br><div class="gmail_quote">On Wed, Aug 22, 2012 at 4:03 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello T,<br>
<br>
Lots of good questions.<br>
<br>
In general, as you found out, "One size fits all" solutions tend to not work well for everyone. So I think have multiple solvers for various problems is a good idea. In an ideal world, we would build things such that they can be chained together, such that the output of one part can be fed as input into the next part.<br>

<br>
So if we had something like:<br>
<br>
solve graph -> points with costs -> makealpha -> geometries<br>
<br>
Where makealpha could be any number of solutions like convex hulls, concave hulls, your_code, etc<br>
<br>
In fact I have code the takes points with costs and makes a triangulated surface and then slices that at z-levels and extracts geometries from that, but not integrated into pgRouting at the moment.<br>
<br>
So, yes, contributions are welcome. Don't think of them as needing to be exclusive of other existing solutions.<br>
<br>
Thanks,<br>
  -Steve<div class="HOEnZb"><div class="h5"><br>
<br>
On 8/22/2012 3:29 PM, T S wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
For some projects I've been working on, I've had to make some<br>
modifications to the alphashape method -<br>
namely, allowing a custom alpha instead of just picking the optimal<br>
regularly connected alpha, and allowing for disconnected multipolygons<br>
instead of only returning a single polygon.<br>
<br>
The use case that comes up is that some networks have holes or gaps in<br>
the 2d plane. I.e., driving over a bridge, you can get to the<br>
landmasses on either side of the bridge, but you can't really get to<br>
all the water around the bridge. This water shouldn't be included in<br>
the polygon.<br>
<br>
I have an initial implementation of how this works, I have a few<br>
questions about trying to contribute it in -<br>
1.) Is there any interest in this feature? Or does pgRouting prefer<br>
the current behavior?<br>
2.) I noticed an earlier email thread discussing moving to<br>
st_concavehull in postgis 2.0. While this would remove the dependency<br>
on CGAL, st_concavehull doesn't appear to support returning multiple<br>
disconnected geometries, and it's not really a true alpha shape.<br>
3.) If there is interest in moving this in, where should I look to for<br>
coding standards, and which parts of the API are 'stable' and which<br>
aren't? in specific -<br>
4) why does points_as_polygon return a setof geoms instead of just a geometry?<br>
5) is it important for there to be both a points_as_polygon() and an<br>
alphashape() function, or could the functionality be rolled up?<br>
<br>
Thank you,<br>
T<br>
<br>
</blockquote>
<br></div></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/pgrouting-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Steve Horn<br><br>
</div>