pgr_gsoc_vrppdtw enhancement ideas

[woodbri]

• rename this function to something reasonable
• add a parameter for number of iterations and default it to something so it is optional
• the current code is based on Euclidean distances, add an option to pass a distance matrix and use that instead of computing Euclidean distance.

[dkastl]

I also think it's necessary to keep the function names understandable and its number as low as possible.
In the end the user wants to solve a problem and doesn't want to choose between a dozen variations.

So I like optional parameters. Maybe some even invoke the use of a different algorithm, but it's not necessary for a user to know that.

Eventually we can solve this by making use of internal functions starting with underbar, so anyone is free to use it as well, but at the same time having a function such as pgr_optimize, that accepts a variety of arguments.

[Illedran]

Just an update on this issue:
#442 could be closed now.
In general, the code is not very well documented and has several hard-coded values. If everyone's okay with this, I would like to refactor/rewrite most of it if possible and then proceed to solve #443.

In case anyone's interested, I wrote this in order to create a PostGIS table of the results. You can visualize it with your preferred GIS software.

CREATE TABLE vrppdtw_visualization AS (
WITH res AS (
  SELECT *
  FROM pgr_gsoc_vrppdtw('select * from customer order by id'::text, 25, 200)
), res2 AS (
  SELECT *, lag(nid) OVER w AS prev
  FROM res
  WINDOW w AS (PARTITION BY rid)
)
SELECT rid, prev, nid, ST_MakeLine(c1.the_geom, c2.the_geom), cost
FROM res2, customer c1, customer c2
WHERE prev = c1.id AND nid = c2.id
)

[cvvergara]

I'll use your idea for the pgRoutingLayers plugin for qgis.
thanks

[woodbri]

postgis currently has 3 packages that it installs, postgis, topology and raster. For me, It is not an issue of documentation as I don't always have the available, but when I look at the function list is pgadmin to get the correct spelling and/or parameters, I find it nice that the functions are grouped by the prefix and functionality. If I'm look for a routing function pgr_* make sense, if I'm looking for a vrp function vrp_* makes sense. I could also see splitting routing functions and vrp function into two packages in the future if the number of function gets unwieldy over time. Minimizing function propagation or at least grouping functions has some value in finding any particular functionality so I would prefer names _ where might be dijkstra or pickupdeliver or etc. and might Euclidean or WithPoints etc. This way all dijkstra* functions are group together when listed.