[pgrouting-dev] Thinking about V4.0

[Vicky Vergara]

You can reply to this mail thread or on the idea discussions:
https://github.com/pgRouting/pgrouting/discussions/categories/ideas
Thanks

On Thu, Dec 16, 2021 at 12:27 PM Vicky Vergara <vicky at georepublic.de> wrote:

> Hello all.
>
> I am working on what is going to be pgRouting v4.0 due at the end of 2023
>
> Many ideas have come out from my experiments
> From the internals simplifying (C/C++) code.
>
> For usage:
>
> *pgr_TRSP*
>
> Currently it is a mess internally (C/C++) and externally.
> Lets talk externally
>
> Currently the documentation in one page has the following signatures:
>
> pgr_trsp(sql text, source integer, target integer, directed boolean,
> has_rcost boolean [,restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, cost)
>
> pgr_trsp(sql text, source_edge integer, source_pos float8, target_edge
> integer, target_pos float8,
>                   directed boolean, has_rcost boolean [,restrict_sql
> text]);
> RETURNS SETOF (seq, id1, id2, cost)
>
> pgr_trspViaVertices(sql text, vids integer[], directed boolean, has_rcost
> boolean [, turn_restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, id3, cost)
>
> pgr_trspViaEdges(sql text, eids integer[], pcts float8[], directed
> boolean, has_rcost boolean [, turn_restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, id3, cost)
>
>
> *Change those signatures*
>
> FROM:
> pgr_trsp(sql text, source integer, target integer, directed boolean,
> has_rcost boolean [,restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, cost)
>
> TO
>
>     driving_side CHAR DEFAULT 'b', -- 'r'/'l'/'b'/NULL
>     details BOOLEAN DEFAULT false,
>
> pgr_trsp(Edges SQL, Restrictions sql, From vid, To vid [,directed]) -- one
> to one
> pgr_trsp(Edges SQL, Restrictions sql, From vid, To vids [directed]) -- one
> to many
> pgr_trsp(Edges SQL, Restrictions sql, From vids, To vid [,directed]) --
> many to one
> pgr_trsp(Edges SQL, Restrictions sql, From vids, To vids [,directed]) --
> many to many
> pgr_trsp(Edges SQL, Restrictions sql, Combinations SQL [,directed]) --
> combinations
> RETURNS SET OF (seq, path_seq, start_vid, end_vid, node, edge, cost,
> agg_cost)
>
> Note that regardless of the call all columns are returned
>
> FROM:
> pgr_trsp(sql text, source_edge integer, source_pos float8, target_edge
> integer, target_pos float8,
>                   directed boolean, has_rcost boolean [,restrict_sql
> text]);
> RETURNS SETOF (seq, id1, id2, cost)
>
> TO
>
> pgr_trsp_withPoints(Edges SQL, Restrictions sql, Points SQL, From vid, To
> vid [,directed][,driving_side][,details]) -- one to one
> pgr_trsp_withPoints(Edges SQL, Restrictions sql, Points SQL, From vid, To
> vids [,directed][,driving_side][,details]) -- one to many
> pgr_trsp_withPoints(Edges SQL, Restrictions sql, Points SQL, From vids, To
> vid [,directed][,driving_side][,details]) -- many to one
> pgr_trsp_withPoints(Edges SQL, Restrictions sql, Points SQL, From vids, To
> vids [,directed][,driving_side][,details]) -- many to many
> pgr_trsp_withPoints(Edges SQL, Restrictions sql, Points SQL, Combinations
> SQL [,directed][,driving_side][,details]) -- combinations
> RETURNS SET OF (seq, path_seq, start_pid, end_pid, node, edge, cost,
> agg_cost)
>
> Note: that regardless of the call all columns are returned
>
>
>
> FROM:
> pgr_trspViaVertices(sql text, vids integer[], directed boolean, has_rcost
> boolean [, turn_restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, id3, cost)
>
> TO
> pgr_trspVia(Edges SQL, Restrictions sql, Via Array,
>  [,directed][,strict][,allow_u_turn])
> RETURNS SET OF (seq, path_id, path_seq, start_pid, end_pid, node, edge,
> cost, agg_cost)
>
>
>
> FROM:
> pgr_trspViaEdges(sql text, eids integer[], pcts float8[], directed
> boolean, has_rcost boolean [, turn_restrict_sql text]);
> RETURNS SETOF (seq, id1, id2, id3, cost)
>
> TO
>
> pgr_trsp_withPointsVia(Edges SQL, Restrictions sql, Points SQL, Via Array
> [,directed][,driving_side][,details][,strict][,allow_u_turn])
> RETURNS SET OF (seq, path_id, path_seq, start_pid, end_pid, node, edge,
> cost, agg_cost)
>
> Note that regardless of the call all columns are returned
>
>
> *About Via functions*
>
> pgr_dijkstraVia(Edges SQL, Via Array
> [,directed][,driving_side][,details][,strict][,allow_u_turn])
> pgr_withPointsVia(Edges SQL, Points SQL, Via Array
> [,directed][,driving_side][,details][,strict][,allow_u_turn])
> pgr_trsp_withPointsVia(Edges SQL, Restrictions sql, Points SQL, Via Array
> [,directed][,driving_side][,details][,strict][,allow_u_turn])
> RETURNS SET OF (seq, path_id, path_seq, start_pid, end_pid, node, edge,
> cost, agg_cost)
>
> Note: that regardless of the call the same columns are returned
> Note: currently only pgr_dijkstraVia exist
>
> *About unifying return columns*
>
> For example on dijkstra
> pgr_dijkstra(Edges SQL, start_vid,  end_vid  [, directed])
> pgr_dijkstra(Edges SQL, start_vid,  end_vids [, directed])
> pgr_dijkstra(Edges SQL, start_vids, end_vid  [, directed])
> pgr_dijkstra(Edges SQL, start_vids, end_vids [, directed])
> pgr_dijkstra(Edges SQL, Combinations SQL [, directed])
> RETURNS SET OF (seq, path_seq [, start_vid] [, end_vid], node, edge, cost,
> agg_cost)
>
> Depending on the call, are the columns returned
>
> Change to
> RETURNS SET OF (seq, path_seq , start_vid, end_vid, node, edge, cost,
> agg_cost)
>
> That way regardless of the call the same columns are returned
>
> That unification of many other official, proposed and experimental
> functions like pgr_astar, pgr_bdAstar etc.
>
> Having for the same (family) calls the same returned columns, makes it
> easier to remember, aka less complicated API
>
> *About naming because of withPoints*.
>
> Currently there are the following proposed functions and they all work
> with dijkstra
>
> * pgr_withPoints
> * pgr_withPointsCost
> * pgr_withPointsCostMatrix
> * pgr_withPointsKSP
> * pgr_withPointsDD
> * pgr_withPointsVia -- to be done
>
> Thinking about trsp (for when they are developed):
>
> * pgr_trsp_withPoints
> * pgr_trsp_withPointsCost
> * pgr_trsp_withPointsCostMatrix
> * pgr_trsp_withPointsKSP
> * pgr_trsp_withPointsDD
> * pgr_trsp_withPointsVia
>
> Thinking about aStar (for when they are developed):
>
> * pgr_aStar_withPoints
> * pgr_aStar_withPointsCost
> * pgr_aStar_withPointsCostMatrix
> * pgr_aStar_withPointsKSP
> * pgr_aStar_withPointsDD
> * pgr_aStar_withPointsVia
>
>
> Having this convention when with points are involved, makes it easier to
> remember, aka less complicated API
>
>
> I would like your thoughts
> Regards
> Vicky
>
> --
>
> Georepublic UG (haftungsbeschränkt)
> Salzmannstraße 44,
> 81739 München, Germany
>
> Vicky Vergara
> Operations Research
>
> eMail: vicky at georepublic.de
> Web: https://georepublic.info
>
> Tel: +49 (089) 4161 7698-1
> Fax: +49 (089) 4161 7698-9
>
> Commercial register: Amtsgericht München, HRB 181428
> CEO: Daniel Kastl
>
>
>

-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20211216/47e4a9fa/attachment-0001.html>