Stephen V. Mather
GIS Manager
(216) 635-3243 (Work)
clevelandmetroparks.com
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 hillBest,
Stevehttp://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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
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@lists.osgeo.org [pgrouting-users-bounces@lists.osgeo.org] on behalf of Stephen Woodbridge [woodbri@swoodbridge.com]
Sent: Thursday, May 16, 2013 10:57 AM
To: pgrouting-users@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 hillBest,
Stevehttp://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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
On 5/16/2013 7:09 AM, Stephen V. Mather wrote:
What is the rationale/thought behind removing the find nearest
node/link/etc from the 2.0 version of pgRouting?
The code I wrote, as Mather pointed out, is PHP anyway, not really "in pgrouting" as much as PostGIS's own <-> operator. If we do contribute it, it would be in the form of posting it on Github so folks can crib off it, not a core part of pgrouting.
I expect that finding barriers is something specific to each use case, and that a higher-level code example would serve well, rather than trying to invent a solve-it-all solution for any possible use case.
(unlike my opinion of the astar wrapper function, which was a huge time-saver even though I did need to make minor mods to it for our use case)
--
Greg Allensworth, Web GIS Developer
BS A+ Network+ Security+ Linux+ Server+
GreenInfo Network - Information and Mapping in the Public Interest
564 Market Street, Suite 510 San Francisco CA 94104
PH: 415-979-0343 x302 FX: 415-979-0371 email: gregor@greeninfo.org
Web: www.GreenInfo.org www.MapsPortal.org
Subscribe to MapLines, our e-newsletter, at www.GreenInfo.org
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@lists.osgeo.org
[pgrouting-users-bounces@lists.osgeo.org] on behalf of Stephen
Woodbridge [woodbri@swoodbridge.com] Sent: Thursday, May 16, 2013
10:57 AM To: pgrouting-users@lists.osgeo.org Subject: Re:
[pgrouting-users] removal of the find nearest node/link/etc from 2.0Hi 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 codeI 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_matchLineAsLinestringI 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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users_______________________________________________ Pgrouting-users
mailing list Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users_______________________________________________ Pgrouting-users
mailing list Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
On Fri, May 17, 2013 at 1:01 AM, Stephen Woodbridge <woodbri@swoodbridge.com
wrote:
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_**
MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM**ZFE#gid=0<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 have just marked them with "GIST", but I'm also OK to keep it. I was just
trying to cleanup the list of functions.
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 PSCUsing 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.
Probably repeating things that have been said before, I think the problem
of everything that we call currently "wrapper" functions is, that (if they
work) they usually are written for a certain algorithm, assuming table and
column names, make assumptions and simplifications, that also restrict the
usage.
Wrapper functions that transform the result (ie. output geometries instead
of ids) are very helpful, though the next release will contain many new
algorithms and there are still quite a few waiting for integration in the
release afterwards. And each of these algorithms would then require such
kind of wrapper functions as well.
Best would be to have some common recipes that could be used by all
algorithms. Find-Nearest-Node functions actually could be of that kind.
I currently would prefer to "cleanup" first (alpha release) and then bring
useful utility functions back.
Daniel
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de