[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