<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 1:01 AM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5/16/2013 11:19 AM, Stephen V. Mather wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Steve,<br>
<br>
I missed these somehow:<br>
<br>
pgr_findNearestLinkDwithin pgr_findNearestNodeDwithin ...<br>
<br>
which addresses the specific question.  It looks like the equivalent<br>
or nearly equivalent functions are listed as <drop> in 2.0 instead of<br>
crosswalk between the two, hence the confusion:<br>
<a href="https://docs.google.com/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=0" target="_blank">https://docs.google.com/<u></u>spreadsheet/ccc?key=<u></u>0AiIg1pkkh_<u></u>MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM<u></u>ZFE#gid=0</a><br>


</blockquote>
<br></div>
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.</blockquote>

<div><br></div><div style>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br></div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think both PostGIS and pgRouting could be well served by a plethora<br>
of contrib functions as wrappers to the core functions.  But, the<br>
development of these will fall into two categories (I think), ones<br>
like some of the pgRouting 1.x which were wrappers for specific use<br>
cases, and encapsulate a single core function, vs. wrappers which tie<br>
together multiple functions into some generic meta-functions so that,<br>
e.g. a very simple middleware language wrapper can expose that<br>
functionality as a service either to web or desktop.  Specific<br>
examples: (Postgis) an intersection function which is intelligent<br>
enough to use ST_Intersects and other appropriate predicates;<br>
(pgRouting) a function which takes input points and network and<br>
returns geojson and turn-by-turn directions.<br>
</blockquote>
<br></div>
Right, I can see this. So there is a bar that functions need to cross to get moved into core.<br>
<br>
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.<br>


2. it needs test cases and documentation<br>
3. and it needs to be review and approved by the PSC<br>
<br>
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.<br>


<br></blockquote><div><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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.</div><div style><br></div><div style>I currently would prefer to "cleanup" first (alpha release) and then bring useful utility functions back.</div>

<div style><br></div><div style>Daniel</div><div style><br></div><div style> </div></div><br clear="all"><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>

eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span>
</div></div>