[Talk-es] pgrouting

Vie Feb 27 17:19:48 GMT 2009

El 27 de febrero de 2009 11:57, Ivan Garcia <capiscuas en gmail.com> escribió:

> Hola José,
>
> he probado el OpenJump y me gusta más que el uDig, que al estar basado en
> Eclipse me va más lento, tiene fallos de renderización,etc.

Me alegro de que compartas esta opinión. Tener uDig es como mover una rueda
de molino sin engrasar.

>
>
> Lo único que no he podido conseguir hacer es poder modificar/grabar los
> datos de mi Postgis directamente desde el OpenJump, puedo editarlos, pero no
> sé como grabarlos, ya que cuando le doy a "Guardar datos seleccionados" me
> da un error de
> SaveDatasetsPlugIn Exception:java.lang.NullPointerException
>

Me imagino que te habrás instalado el plugin correspondiente de PostGIS:
http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=179545&release_id=464883
e instalado correctamente, es decir, en el directorio "<path
openjump>/lib/ext". El driver jdbc debe de estar en tu ext/lib de tu
instalación de java (en mi caso
/usr/lib/jvm/java-6-sun-1.6.0.10/jre/lib/ext/ postgresql-8.0.309.jdbc3.jar)

Posteriormente, una vez que has cargado una layer de postgis y lo has
editado para guardar debes de tener la precaución de asignar correctamente
la SRID (referencia  espacial) a la que se corresponde con tu tabla postgis.
En el caso de layers de OSM utiliza el 4326. Para ello: Barra Menu -> Layer
-> ChangeSRIDplugin. Ten presente que OJ por defecto trabaja sin proyección,
es decir, SRID = -1

Con esto debe de ser suficiente.

Una aclaración: si no ha cambiado OJ, lo que hacía era borrar todos los
registros de la tabla y volcarlos de nuevo. Esto está bien si tus datos no
tienen otras dependencias, o procede de una shape o similar que quieres
añadir como una tabla nueva. Por ello nunca utilizo OJ para la edición de
PostGIS. Siempre utilizo Qgis porque está diseñado específicamente para
PostGIS, y de hecho trabaja de forma transaccional, es decir,
1. inicias sesión de digitalización
2. borras, modificas posiciones, añades, etc
3. cierras la sesión de digitalización.
Sólo los registros afectados se incluirán en la transacción, es decir, un
BEGIN y un COMMIT

Por cierto, hay un plugin en QGIS para crear una layer a partir de un OSM.
Sólo obtiene la geometria, obviando los atributos, pero es un buen comienzo.

Saludos,

Jose

>
>
> Saludos.
> Iván.
>
> 2009/2/26 José Manuel Mira Martínez <josema.mira en gmail.com>
>
>>
>>
>> El 26 de febrero de 2009 17:02, Ivan Garcia <capiscuas en gmail.com>escribió:
>>
>>> Hola José,
>>>
>>> para compilar el osm2pgrouting sin problemas prueba esto
>>>
>>> modifica en src/stdafx.h:
>>> de
>>> "#include <string>"
>>> a
>>> "#include <string.h>
>>>
>>> y dale al make
>>>
>>
>> Muchas gracias por la información. He realizado el cambio y ha compilado a
>> la primera. Ahora sólo me queda probarlo.
>>
>>>
>>> Saludos, ya nos dirás como te ha ido. A mí de momento me funciona genial,
>>> he probado con el OSM de Valencia y me lo carga en la base de datos de
>>> Pgrouting (postgis) y entonces uso la función
>>>
>>> SELECT assign_vertex_id('edges', 0.0001, 'the_geom', 'gid');  para crear
>>> los vértices de las intersecciones de las vías.
>>
>>
>> Me gusta mucho como trabaja esta utilidad. Ahora las intersecciones si que
>> son generadas perfectamente, sin tener que recurrir a herramientas externas
>> (ej. OpenJump, GRASS, ArcInfo). El resultado es muy notable, y tiene en
>> cuenta los pasos a distintos nivel,
>> no computa elementos lineales no "rutables" (ríos, barrancos, ffcc,tram).
>> (ej:http://www.openstreetmap.org/?lat=38.37951&lon=-0.45314&zoom=16&layers=B000FTF
>> )
>> , asigna el coste en función de la dirección, lo mismo para el
>> reverse_cost, genera los x1,y1,x2,y2 sólo. Vamos, que preparado para
>> realizar cálculos de rutas optimas a la primera.
>>
>> Sólo le veo una mini-pega, es que desaparece la columna del tipo de vía,
>> que es sustituida por class_id, que viene definida en el fichero de
>> configuración xml (mapconfig.xml).
>>
>>>
>>>
>>> Después ya puedo calcular mis rutas usando
>>>
>>>             DROP TABLE IF EXISTS dijsktra_result;
>>>
>>> CREATE TABLE dijsktra_result(gid int4) with oids;
>>>
>>> SELECT AddGeometryColumn('dijsktra_result', 'the_geom', '4326',
>>> 'MULTILINESTRING', 2);
>>>
>>> INSERT INTO dijsktra_result(the_geom)
>>>
>>>             SELECT the_geom FROM dijkstra_sp('edges', 52, 35);
>>>
>>>  Donde 52 es el vértice de inicio y 35 es el vértice de llegada, son
>>> ejemplos.
>>> Finalmente para visualizar esa ruta generado uso el uDIG para conectarme
>>> directamente a la BBDD y lo representa en colores muy chulo.
>>
>>
>> Sí en uDig te parece chulo, te aseguro que con OpenJump, con la opción
>> Capa -> Ejecutar consulta de almacén de datos -> tu query sql donde debes de
>> formatear la columna geometria por st_aseWkb(<tu columna geométrica>)  el
>> resultado es sensacional. Reconozco que tengo debilidad por OpenJump, es muy
>> didáctico.
>>
>> En fin, que muchas gracias por la información.
>>
>> Por último, he pensado realizar un mini-manual sobre este tema y colgarlo
>> en la wiki de OSM para que todos tengamos un punto de partida. y mejorarlo y
>> ampliarlo al gusto de todos. Cuando lo tenga lo comunicaré a la comunidad.
>> Creo que ya sólo queda realizar salidas por internet con OpenLayer o
>> MapServer.
>>
>> Un saludo a todos.
>>
>> J3M
>>
>>>
>>>
>>> Saludos.
>>> Iván.
>>>
>>> 2009/2/26 José Manuel Mira Martínez <josema.mira en gmail.com>
>>>
>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20090227/da0e1efe/attachment.html>