[pgrouting-dev] driving_distance Synopsis

Steve Horn steve at stevehorn.cc
Tue Mar 6 21:13:41 EST 2012


On Tue, Mar 6, 2012 at 9:01 PM, Daniel Kastl <daniel at georepublic.de> wrote:

> Hi Steve,
>
> My answer probably isn't complete, but I hope others will add additional
> comments.
> This is what I think could be improved:
>
>    - Driving Distance should have the possibility to return a polygon,
>    but the "core" algorithm should just return a list of points that are
>    within driving distance together with useful attributes as for example the
>    cost to reach the point, or the previous point ID.
>
>    - Currently it requires CGAL for the "alphashape" function. It would
>    be nice, not to have CGAl as a dependency. With PostGIS 2.0 it's maybe
>    possible to use ST_ConcaveHull instead.
>
>    http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Alpha_shapes_2/Chapter_main.html
>
> I've been using the points_as_polygon successfully. It would be nice to be
able to have some ability to fine tune the alpha shape, but it does the job.


>
>    - For large networks it's a good idea to select only a small part
>    (BBOX). This is easy as long as the cost attribute is in the same unit as
>    the network data (ie. degree or meter). But if the cost is time for
>    example, how to define a BBOX extent? If the BBOX is too small the driving
>    distance area will look like the BBOX itself ;-)
>
> My use case works with time (how far can I travel in *n* minutes).
Streets/highways in the US rarely exceed 65mph/100kmph so I make my BBOX
the size of the maximum possible distance that would be able to
be traveled if all streets in all directions were the max speed.


>
>
> Daniel
>
>
> On Wed, Mar 7, 2012 at 10:36 AM, Steve Horn <steve at stevehorn.cc> wrote:
>
>> Hello list.
>>
>> I am interested in digging in more to the driving_distance functions to
>> do some refining and perhaps improve the usefulness of the results (
>> http://lists.osgeo.org/pipermail/pgrouting-dev/2012-February/000458.html
>> ).
>>
>> Having a hard time deciphering the current implementation, mostly because
>> of my lack of familiarity with c/c++. Is there someone who wouldn't mind
>> giving a synopsis of the overall approach that the algorithm takes?
>>
>> Thanks!
>>
>> _______________________________________________
>> 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
>
>


-- 
Steve Horn
http://www.stevehorn.cc
steve at stevehorn.cc
http://twitter.com/stevehorn
740-503-2300
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120306/4e74e84a/attachment.html


More information about the pgrouting-dev mailing list