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.
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
Saludos.
Iván.
2009/2/26 José Manuel Mira Martínez <josema.m...@gmail.com>
>
>
> El 26 de febrero de 2009 17:02, Ivan Garcia <capisc...@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.m...@gmail.com>
>>
>> Hola a todos,
>>>
>>> El 26 de febrero de 2009 0:16, Ivan Garcia <capisc...@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.m...@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 <mar...@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@openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-es mailing list
>>>>> Talk-es@openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-es mailing list
>>>> Talk-es@openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>>
>> _______________________________________________
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> _______________________________________________
> Talk-es mailing list
> Talk-es@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
>
_______________________________________________
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es
