[Talk-es] pgrouting

Jue Feb 26 09:18:57 GMT 2009

Hola a todos,

El 26 de febrero de 2009 0:16, Ivan Garcia <capiscuas en gmail.com> escribió:

> Hola José, dices que has probado el programa osm2pgsql y tiene ciertas
> limitaciones,

Matizo la frase. Tiene ciertas limitaciones para usar osm como tablas
adecuadas para calcular rutas. Por lo demás es una estupenda herramienta
para obtener de forma más o menos ordenada los datos de osm en la
geodatabase Postgres-postgis.
Para routing necesitas:
- nodos de inicio de linea y fin de línea en las intersecciones de calle
- tener bien definido el "oneway", al menos para obtener rutas que tengan en
cuenta las direcciones, que es lo que hace el algoritmo
shortest_path_shooting_star, que a su vez nos sirve para asignarle un coste
inverso (reverse_cost) a las direcciones en un único sentido (y a las
junction/roundabout)
- opcionalmente una tabla de nodos un poco más explícita, con alias para
nodos en cristiano, para que nos pueda llevar en vez del nodo 45 al 256, del
Hotel xxxx (nodo 45) al restaurante XXXXXXXX (nodo 256), que es lo que
hacemos con los navegadores de coche.
- Por otra parte, y esto es algo que deberiamos pensar todos los 'osemeros'
, pgrouting te permite asignar costes adicionales a las intersecciones, para
indicar que no se tarda lo mismo, por ejemplo, continuar recto, que girar a
la izquierda. Yo personalmente he pensado en utilizar los pocos semáforos de
osm, pero tienen que estar ubicados en la intersección.¿creo?, pero no se
como hacer para indicarle estos pesos de giro a izq. o dcha.
- osm2pgsql genera una tabla de líneas, donde se encuentran las calles entre
otras, pero también incluye los ríos y barrancos que los usuarios hemos
puesto, y que yo sepa esto no interviene en un cálculo de rutas, a no ser
que vayas en canoa.

>
>
> hace poco encontré el osm2pgrouting , pero no he tenido tiempo de probarlo,
> te sirve para aplicar las funciones de cálculo de rutas de pgrouting?
>

Tienes razón, existe esta utilidad, pero he intentado compilarla en mi
distro (Ubuntu 8.10) y no he podido. Me da muchos errores de compilación.
Sin embargo, en la web de osm2pgrouting, los pasos para la compilación están
ensayados en Ubuntu 8.04, por lo que no te puedo decir que hace o como.

>
> Si es así, nos puedes ponder algunos pasitos de como hacerlo?

Ya te he respondido antes. No he podido compilar la utilidad. Pero te puedo
decir lo que he hecho hasta ahora, que es bastante casero, pero al menos a
mi me funciona en un 80 % para calcular rutas.

1. descargar zona de osm (por ej. con josm), o si nuestro proyecto es
ambicioso todo el osm de España que existe en CloudMade o otras.
2. aplicar osm2pgsql para generar la geodatabase. Nota: PostGIS debe de
estas instalado previamente en la base de datos a utilizar
3. normalizar la tabla <nombre>_lines:

   - añadir índices al osm_id, o mejor, renombrarlo a gid. Si no hacemos
   estos no podremos ver el resultado (mapa) en programas como Qgis que exigen
   un índice en la tabla geométrica.
   - opcionalmente:convertir oneway en un booleano, y poner true o yes a
   "true", y false o null a "false"
   - crear columnas: source, target, cost, reverse_cost, x1, y1, x2, y2

4. En OpenJump cargo la tabla de PostGIS y creo el grafo: Herramientas ->
Edición geométrica -> Convertir -> Crear grafo
Creará 4 tablas, y me las llevo a PostGIS
5. En Postgres con todas esas tablas realizo los SQL necesarios (join,
updates, create table, etc)  para tenerlo todo en una sólo tabla.
6. Como me preocupa bastante el tema del coste por direcciones lo que hago
es multiplicar por un valor (*1000) el valor del lenght de todas las filas
cuyo valor oneway sea true, y lo mismo para las roundabout. En mi caso el
length que utilizo es el de la UTM, pero, como ha dicho el compañero Martín
Vales, me calentaré el coco para utilizarlo en geográficas (¡gracias Martín
por la info¡)
7. Luego sólo tengo que aplicar las SQL necesarias para el cálculo de coste.
Os pongo unos ejemplos:
Dijkstra (sobre nodos):
SELECT * FROM shortest_path('SELECT gid as id, source, target, coste as cost
FROM alicante',518, 3418, false, false);
A* (sobre nodos):
SELECT * FROM shortest_path_astar('SELECT gid as id, source, target,
reverse_cost AS reverse_cost, x1, y1, x2, y2 FROM alicante', 518, 3418,
false, true);
Shooting star (sobre ejes):
SELECT * FROM shortest_path_shooting_star('SELECT gid as id, source, target,
coste as cost, reverse_cost,x1,y1,x2,y2, null as rule, null as to_cost FROM
alicante order by id',2571, 2634,true,true);

En las consultas utilizo muchos "WHERE" para evitar que el cálculo lo
realice sobre river, trail, tram, etc.

Los resultados son satisfactorios siempre que no calcules rutas que
necesiten cruzar autovías, autopistas por el problema ya comentado que el
grafo incluye nodos en estos viales.

Sí alguien está interesado le puedo dar la tabla que he creado ("alicante")
para realizar pruebas.

Quiero dejar claro que estas son mis experiencias, y que en ningún momento
pretenden ser la "verdad" sobre el tema del cálculo de rutas en OSM. Ya me
gustaría a mi saberlo todo. Aquí estamos para aprender.

Un saludo a todos

J3M

>
> Gracias.
>
> 2009/2/25 José Manuel Mira Martínez <josema.mira en gmail.com>
>
> Hola, pgrouting es una extensión para PostGIS que utiliza la librería
>> libboost (que es la que realiza el cálculo de los grafos). Es una extensión
>> que se renueva con cierta asiduidad, y lo más interesante es que propone
>> formas de publicación de cartografía con el servidor de MapServer, o bien
>> utilizando OpenLayer + MapServer, o OL+PHP.
>> El llevar la cartografía de OSM a Postgres-PostGIS es bastante sencilla,
>> puesto que existe una utilidad llamada osm2pgsql que crea cuatro tablas
>> geográficas (nodos, polígonos, líneas y otra que no me acuerdo).
>> El problema es que estas tablas carecen de información de "ruteo", por lo
>> que hay que utilizar herramientas externas, aunque la librería pgrouting
>> tiene una función para crear el grafo, ésta no sirve para los datos de OSM,
>> puesto que se necesita un nodo en cada intersección. Por ej. una calle
>> cualquiera, que tenga 3 intersecciones, sólo tiene un nodo de inicio y otro
>> final, cuando debe haber 2 tramos, cada uno con su par de nodo inicio-final.
>> Además hay que corregir muchas cosas:
>> - normalizar "oneway"
>> - asignar costes: no sirve st_length(the_geom), puesto que calcula la
>> longitud sobre la base de la SRID 4326 (geográfica), y a nosotros nos
>> interesa en metros (23030 o 25830 por ejemplo). Yo utilizo la función
>> anidada st_length(st_transform(the_geom, 23030)).
>>
>> Últimamente he hecho unos cuantos pinitos creando el grafo con OpenJump,
>> que tiene una herramienta excelente para generar intersecciones, crear nodos
>> e indexarlos. Ahora bien, intersecta todo lo que encuentra, y eso a nosotros
>> no nos interesa, por que por ejemplo no debe de generar un nodo en una ctra.
>> que va por encima de una autopista, a distintos niveles.
>>
>> En fin, este tema me apasiona, por lo que cualquier comentario será
>> agradecido.
>>
>> Un saludo a todos
>>
>> j3m
>>
>> 2009/2/25 Martín Vales <martin en opengeomap.org>
>>
>> hi!
>>>
>>> ¿Alguien ha probado esta extension de postgis para calcular rutas con
>>> datos masivos?
>>> http://pgrouting.postlbs.org/
>>> En las demos que ponen parece que va bien pero es muy poca cartografía.
>>>
>>> Internamente usa el famoso codigo fuente de los carteros que se comento
>>> por aqui por lo que he podido ver en lso fuentes.
>>>
>>>
>>> Un saludo.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-es mailing list
>>> Talk-es en openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>
>>
>>
>> _______________________________________________
>> Talk-es mailing list
>> Talk-es en openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20090226/564a949d/attachment.html>