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

[Daniel Kastl]

On Fri, May 17, 2013 at 1:01 AM, Stephen Woodbridge <woodbri at 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 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.
>
>
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 at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20130517/91210441/attachment.html>