[pgrouting-users] removal of the find nearest node/link/etc from 2.0

Stephen Woodbridge woodbri at swoodbridge.com
Thu May 16 07:57:50 PDT 2013


Hi Stephen,

Daniel and I have been struggling with the volume of cruft in the 
non-core functions in pgrouting. I particular the wrapper functions are 
huge problem in that:

1. they make great examples for people to customize

2. each one fits a narrow use case cause new functions to be added to 
fit similar but different use case. For example bbox, delta, start at 
x,y vs start at node vs start at edge, specify cost and reverse cost 
names,  directed or not, has reverse cost or not. And all these cases 
times the number of algorithms. Host to document them, how to test them, 
etc.

We are adding a lot of functionality and new algorithms and don't want 
the expansion of cruft to be multiplied by all the new functionality.

We are also adding some utility functions that fit generic use cases and 
address problems that Daniel and I have fielded multiple times over the 
last few years. These include:

1. graph analytic functions
2. tool for noding a network
3. the matching code

I think you may find what you are looking for in 
src/common/sql/pgrouting_matching.sql but the names have been changed to 
our new standard of "pgr_<camelCaseFunctionName>"

pgr_findNearestLinkDwithin
pgr_findNearestNodeDwithin
pgr_findNodeByNearestLinkDwithin
pgr_matchLineAsGeometry
pgr_matchLine
pgr_matchLineAsLinestring

I have concerns with respect to the matching code because a found lots 
of typos in the code that would absolutely cause the function to not 
work correctly. Especially in the pgr_match* functions.

None of these functions has any test cases So we have no idea if they 
work at a trivial level or not, let alone anything more comprehensive, 
but this is a problem overall.

Anyway back to my point about a leaner meaner pgRouting, we need to have 
less cruft and focus our time on making sure what we have works well. We 
would like to have a community that gets more involved and contribute to 
the core or contributes add-ons or snippits via https://gist.github.com/ 
We can maintain a wiki page that points to various gists if we need to.

So thank you for asking this question, it touches on some important 
changes as we move forward and while Daniel and I have mentioned a lot 
of these points in various posts, I'm not sure it have been clearly 
communicated. Nothing is set in stone so we seek user feedback to better 
serve the community.

Thanks,
   -Steve

On 5/16/2013 10:09 AM, Stephen V. Mather wrote:
> Hi All,
>
> What is the rationale/thought behind removing the find nearest
> node/link/etc from the 2.0 version of pgRouting?
>
> Greg Allensworth wrote some code for us which extends that problem to
> search for nearest node within a distance, respecting polygon barriers,
> to avoid, for example, finding the nearest node Y from point X to start
> routing when there's a cliff or steep slop preventing a walker from
> getting to a network node to start the routing.  I was just about to
> e-mail him to suggest maybe we could contribute it, when I saw that that
> family of functions is going away... .
>
> Top of hill
> X______
>         \
>          \
>           \
>            \____Y   Bottom of hill
>
> Best,
> Steve
>
> http://sig.cmparks.net/cmp-ms-90x122.png Stephen V. Mather
> GIS Manager
> (216) 635-3243 (Work)
> clevelandmetroparks.com <http://www.clemetparks.com>
>
>
>
>
>
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>



More information about the Pgrouting-users mailing list