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

Thu May 16 09:01:16 PDT 2013

On 5/16/2013 11:19 AM, Stephen V. Mather wrote:
> 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

OK, so Daniel is suggesting these go to a gist. I have not had a chance 
to review these in any detail. I think that there is some value for the 
find nearest so I might be inclined to argue that these could stay as 
generic helper functions. I would also be inclined to push the match* 
functions into a gist.

>  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.

Thanks, we have been trying to learn for the postGIS example and this is 
the model we are following for the most part.

> 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.

Right, I can see this. So there is a bar that functions need to cross to 
get moved into core.

1. needs to be generic functionality that can be applied generally to 
multiple users needs this can be a low level function the solves 
multiple use cases or a higher level function that solves in a generic 
way a specific use case and can be applied by multiple users without 
putting to many additional constraints on them.
2. it needs test cases and documentation
3. and it needs to be review and approved by the PSC

Using pgrouting forks and gists and whole github repositories is where 
this process starts. It allow for easy sharing of functionality, it 
allow user to give feedback on it. And if we want to move it or part of 
it into core it is very easy to pull code int from these.

Thanks,
   -Steve

> 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
>
>
> _______________________________________________ Pgrouting-users
> mailing list Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>