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

pgRouting pgrouting-users
1

Hi all,

I have started looking at the function signatures with an eye toward clean them up and making them easier to deal with.

A little history. When we write code for a function in pgRouting there are typically a few functions that are very simple and map to the low-level C code fairly closely. Than on top of that people have written convenience functions to hide some of the complexity of the various ways to optimize the queries based on things like bounding boxes, or a buffer distance to create a bounding box. Then there are things like adding information about whether your graph is directed or not, and to specify a cost column name or a reverse cost column name, etc.

So if you look at the attached spreadsheet, you can see some of this mess.

I plan is to clean this up! I have not decided how deeply to cut into this mess. I'm inclined to put the old functions into a pgrouting_legacy.sql file that gets installed but not loaded into the database by default. People that don't or can't upgrade their code to use the new function names would be able to load this file at least for the 2.0 release, but this might go away in the future.

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

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 2.0 Functions.pdf (186 KB)

2

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

3

Here is the list imported into Google Docs:
https://docs.google.com/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE&usp=sharing

We can use this to add comments and indicate progress of documentation, etc.

Daniel

···

On Fri, May 3, 2013 at 10:08 AM, Daniel Kastl <daniel@georepublic.de> wrote:

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de