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

[Stephen V. Mather]

Hi Steve,

I missed these somehow:

pgr_findNearestLinkDwithin
pgr_findNearestNodeDwithin
...

which addresses the specific question.  It looks like the equivalent or nearly equivalent functions are listed as <drop> in 2.0 instead of crosswalk between the two, hence the confusion:
https://docs.google.com/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=0

I really appreciate the cleanup effort and have been tracking it.  I particularly appreciate the simplification and coordination of the API, and I think it now better follows the PostGIS model of providing core functionality.

I think both PostGIS and pgRouting could be well served by a plethora of contrib functions as wrappers to the core functions.  But, the development of these will fall into two categories (I think), ones like some of the pgRouting 1.x which were wrappers for specific use cases, and encapsulate a single core function, vs. wrappers which tie together multiple functions into some generic meta-functions so that, e.g. a very simple middleware language wrapper can expose that functionality as a service either to web or desktop.  Specific examples: (Postgis) an intersection function which is intelligent enough to use ST_Intersects and other appropriate predicates; (pgRouting) a function which takes input points and network and returns geojson and turn-by-turn directions.

Best,
Steve

  Stephen V. Mather
GIS Manager
(216) 635-3243 (Work)
clevelandmetroparks.com




________________________________________
From: pgrouting-users-bounces at lists.osgeo.org [pgrouting-users-bounces at lists.osgeo.org] on behalf of Stephen Woodbridge [woodbri at swoodbridge.com]
Sent: Thursday, May 16, 2013 10:57 AM
To: pgrouting-users at lists.osgeo.org
Subject: Re: [pgrouting-users] removal of the find nearest node/link/etc from 2.0

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
>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users