[pgrouting-users] Pgrouting-users Digest, Vol 94, Issue 3

[Vicky Vergara]

hello again:

> To do idea:
>Some pgr function thats return and use geometry like reverse_cost, maybe
has_geometry than pass to the 'sql', and results like cost
> vertex_start/vertex_end linestring, and agg_cost making final linemerge
linestring...

​Inventing a term, "middleend". Based on a backend function results a
middleend function will use the information and send the results that the
frontend needs.
​Based on that:​

​pgRouting is a backend,.
"middleend" functions​ we notice are very application specific.
frontend is in other languages that call the database (and is the
application from the user's point of view).

For example, in this wiki I made, where geometries are not aggregated (I
need to make one with aggregating geometries):
http://talks.vicky.georepublic.info/howto/flipGeometries.html#/
you can see that, besides the geometry, additional information can be
needed, and the query looks similar but not quite the same.
lots of howto are needed so people can copy/paste/adjust to what they need.

Also, like for example in your queries you were using Spanish (where are
you from?, I am from México), or your data comes from other source, maybe
your geometry column is not the_geom, maybe its geometria, or geom

​​pgRouting's focus is on the algorithms for graphs, and the graph
abstraction does not have a geometry involved.

​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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20160812/89ede511/attachment.html>