[pgrouting-users] [pgrouting-dev] Proposal to clean up function signatures in pgRouting 2.0

[Daniel Kastl]

>
> My goal is to try and map most of the various shortest path functions to a
> template something like:
>
> func_name(
>     table_name, -- table or view name
>     start_id,   -- edge or vertix id, for trsp this could be [id, pos,]
>     target_id,  -- edge or vertix id, for trsp this could be [id, pos,]
>     delta,      -- *amount to expand an implied bbox
>     directed,   -- *is the graph directed?
>     has_rcost)  -- *does the table have reverse_cost column?
>
> * these items would be optional
>

Hi Steve,

The template above would be for the "wrapper" functions, right? The "core"
functions usually have an "sql" statement as first parameter".
I like the idea to use function overloading, so one function name allows
a different number of parameters.

There are quite a few functions with extra long names, and I would either
try to make them shorter or drop them completely, if they are not really
needed.

What about making a Google Docs spreadsheet to be able to add comments
directly to the list?

Daniel



>
> In the spreadsheet under the library column, the blanks represent wrapper
> function, the lib* entries are the low level SQL wrappers to the C code and
> legacy stuff I threw into the what will become the legacy file.
>
> Thoughts and feedback are welcome.
>
> -Steve
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>


-- 
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/20130503/ed8b091b/attachment.html>