[Talk-ar] comunidad
Igor Iván Spiler
spiler en gmail.com
Lun Mar 5 01:21:51 GMT 2012
corrijo lo dicho =) no uso quadtree, la idea es similar, subdivido pero en
3x3 en vez de 2x2 y etc pero no de la misma manera, quadtree subdivide
cuando desbordás un límite, en mi código no subdivido, ya sé de antemano a
qué espacio va a ir un objeto por su lat/lon
saludos,
2012/3/4 IgnacioZ <zignacio at gmail.com>
> si, termine haciendo algo como lo q decis usando un quadtree :)
>
>
> suerte!
>
> 2012/3/4 Igor Iván Spiler <spiler at gmail.com>
>
>> exactamente, le diste en el clavo, ahí está la mágia (y el valor agregado
>> que comentaba que le doy a los datos) los "relations" referencian "nodos" y
>> "ways", los "ways" referencian "NDs", los "nd" apuntan a los node. el truco
>> es cómo almacenás la información que geográficamente es "cercana"
>> contiguamente en el repositorio de manera de que al leer los datos de un
>> determinado espacio geográfico tengas un snapshot con suficientes datos en
>> un único bloque mapeado en memoria (en mi arquitectura el espacio de página
>> máximo que tengo es de 4k) y sin perder información de los "ID" para poder
>> actualizar con changesets y seguir reutilizando los nodos en los ways y etc.
>>
>> tengo 2 discos, el parser de XML lee a 120 MB/s, en el 2ndo disco
>> escribo/updatea durante la importación, planet.osm pesa 287GB
>> descomprimido, ~40 minutos lee XML, las otras 2 horas 20 se la pasa
>> transformando de char a unsigned long/int/lo que corresponda y almacenando
>> los structs (son todos fixed-size, tengo 1 solo archivo para data variable
>> que comparten todos para guardar info de tags), es un lindo repositorio, la
>> clave de todo está en el algoritmo de geocoding que le aplico a cada objeto
>> para poder particionar los datos como te comentaba arriba, empecé usando
>> c-squares pero lo modifiqué para que sea CPU/HD friendly
>>
>> originalmente lo había hecho en java pero mapear memoria del disco en
>> java es una mentira, en C es otra historia, en recuperarme toda la
>> información que necesito para dibujar un área (demarcada por geocoding, mis
>> áreas son de promedio 35km2, esto varía según la latitud) le lleva 5ms (que
>> es prácticamente el tiempo de acceso al disco), si el área usa más de un
>> código usando "madvise" al kernel le indicás que vas a hacer acceso
>> secuencial del archivo/dispositivo mapeado a memoria y al ser contiguos
>> esto le indica al kernel hacer "read ahead" asique está optimizado dentro
>> de lo razonable
>>
>> ahora estoy en generar gráficos lindos con cairo, por ahora dio
>> resultados bastante buenos pero falta, quiero ver cuánto tarda en generar
>> el área con anti-aliasing y etc, así como está generar estos 35km2 que te
>> comentaba tardó:
>>
>> real 0m0.323s
>> user 0m0.280s
>> sys 0m0.040s
>>
>> 1752 x 1752 pixels
>>
>> esta parte gráfica no tienen ninguna optimización todavía, recién empecé
>> a graficar con c++ el fin de semana pasado, este finde no le dediqué nada
>> todavía, supongo que poner otro color en vez del que utiliza no va a
>> afectar mucho la performance
>>
>> saludos!
>>
>>
>>
>> 2012/3/4 IgnacioZ <zignacio at gmail.com>
>>
>>> Bueno, es probable que lo cargues todo, pero no estoy seguro que este
>>> muy optimizado, dado que guardarias los vecinos de los ways sin informacion
>>> de latitud/longitud. Por lo que cuando quieras obtener esa informacion vas
>>> a tener q buscarla en el disco por cada id de nodo. Acordate que de los
>>> nodos tambien tenes q guardar lat y long...
>>>
>>> Si lo haces durante la carga, casi seguro q no se lo vas a poder hacer
>>> en ese tiempo con ese RAM, aunque si lo haces, avisame como ya que me
>>> interesaria :)
>>>
>>> saludos
>>> Ignacio.
>>>
>>> 2012/3/4 Igor Iván Spiler <spiler at gmail.com>
>>>
>>>> Me quedo con mi propia herramienta, =) sin información de referencia
>>>> concreta de la implementación es imposible hacer comparaciones.
>>>>
>>>> En la forma que lo estoy haciendo estoy seguro que en 3 horas cargo
>>>> todos los datos de planet.osm (una vez descargado y descomprimido), aplicar
>>>> un changeset me lleva no más de 1 o 2 minutos.
>>>>
>>>> Durante la carga inicial a una db tendría que cargar 1.383.935.462 de
>>>> nodos solamente (según
>>>> http://www.openstreetmap.org/stats/data_stats.html) en cualquier base
>>>> de datos es un pequeño parto, por más que optimices la carga masiva
>>>> eliminando las PK, después al definir la PK de la tabla tenés que dejar a
>>>> la DB indexar todos esos nodos... te la regalo =) son más de 5GB solamente
>>>> de datos (4 bytes el unsigned long en mi arquitectura) + el índice para la
>>>> PK, para mi la única forma de que funcione con una base de datos es
>>>> teniendo el hardware que tienen los muchachos de OSM tipo esto:
>>>>
>>>> http://wiki.openstreetmap.org/wiki/Servers/smaug
>>>>
>>>> de otra manera con los pobres 4gb de ram que tengo para una base de
>>>> datos se la pasaría swapeando a disco, con el índice particionado y todo, y
>>>> eso solo a la carga... después en el trabajo del equipo en el día a día no
>>>> hay equipo que aguante
>>>>
>>>> capaz lo que estoy desarrollando es muy específico, cada proyecto tiene
>>>> sus requerimientos no?
>>>>
>>>> saludos!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2012/3/4 IgnacioZ <zignacio at gmail.com>
>>>>
>>>>> Como t dije, algunas cosas las hice a mano :) y lo del camino mas
>>>>> corto es parte de eso, mas que nada porque necesitaba mucha performance, en
>>>>> grafos muy grandes.
>>>>>
>>>>> De cualquier manera hay un par de ejemplos en la pagina. Sino podes
>>>>> unirte al grupo que el creador siempre responde y muy bien
>>>>>
>>>>> Saludos,
>>>>> Ignacio.
>>>>>
>>>>> 2012/3/4 Igor Iván Spiler <spiler at gmail.com>
>>>>>
>>>>>> che, me interesa, como resolvés con sqlite el tema de insertar la
>>>>>> información de los nodos de planet.osm, cuánto tiempo te llevó más o menos?
>>>>>>
>>>>>> saludos,
>>>>>>
>>>>>>
>>>>>> 2012/3/4 IgnacioZ <zignacio at gmail.com>
>>>>>>
>>>>>>> Hola Igor yo ya he caminado un poco ese camino, y a a veces es
>>>>>>> verdad q esta bueno arrancar de cero.
>>>>>>>
>>>>>>> Te paso unos pequeños datos: la libreria sqlite y spatialite tienen
>>>>>>> bastante hecho de lo que es camino mas corto. Lo mismo existe para
>>>>>>> postgresql
>>>>>>> Tambien hay herramientas desarrolladas por la comunidad que te dan
>>>>>>> el camino mas corto, fijate en la wiki hay un par que son realmente muy
>>>>>>> buenas. Hay una que es Openstreetmap Routing Machine creo.
>>>>>>>
>>>>>>> De cualquier manera yo tambien hice algunas cosas de cero, asi que
>>>>>>> no puedo quejarme, pero esta bueno revisar un poco antes aunque sea para
>>>>>>> inspirarse.
>>>>>>>
>>>>>>> Tambien existen varios q han trabajado con SRTM, si te fijas hay
>>>>>>> varios q han hecho mapas topograficos que estan muy buenos. A futuro tenia
>>>>>>> ganas de ver un poco como se hacen, parece interesante, y tengo ganas de
>>>>>>> aplicarlo en un proyecto propio.
>>>>>>>
>>>>>>> Saludos,
>>>>>>>
>>>>>>> Ignacio.
>>>>>>>
>>>>>>> 2012/3/4 Igor Iván Spiler <spiler at gmail.com>
>>>>>>>
>>>>>>>>
>>>>>>>> Hola Federico, en mi caso más allá de que no cuento con el hardware
>>>>>>>> para hacerlo de la manera que propone OSM desarrollar herramientas desde
>>>>>>>> cero me permite agregar valor al producto final y tener algo distinto al
>>>>>>>> resto del mundo que descargó las herramientas, ahora por ejemplo gracias a
>>>>>>>> que almaceno la información de los nodos/ways/relations como grafos en vez
>>>>>>>> de en una base de datos relacional me permite aplicar algoritmos "del
>>>>>>>> camino más corto" (creo que se traduce así). Usando el modelo relacional de
>>>>>>>> OSM y almacenado todo en una base de datos tardaría mucho más.
>>>>>>>>
>>>>>>>> grafos según wikipedia:
>>>>>>>> http://en.wikipedia.org/wiki/Graph_%28data_structure%29
>>>>>>>>
>>>>>>>> algoritmos para resolver problemas de "el camino más corto":
>>>>>>>> http://en.wikipedia.org/wiki/Shortest_path_problem
>>>>>>>>
>>>>>>>> además a futuro pienso cruzar los datos con información de altura
>>>>>>>> de SRTM (shuttle radar topography mission)
>>>>>>>> http://www2.jpl.nasa.gov/srtm/ me llevaría más tiempo pensar cómo
>>>>>>>> agregar funciones a las herramientas existentes de OSM (que además están
>>>>>>>> escritas en distintos lenguajes) que hacer algo desde cero.
>>>>>>>>
>>>>>>>> Los datos de OSM por suerte son libres y son muy buenos pero las
>>>>>>>> herramientas que desarrollaron no tanto, pienso publicar algunas de las
>>>>>>>> cosas que estoy desarrollando pero todavía están muy verdes.
>>>>>>>>
>>>>>>>> saludos!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/4 Federico Pértile <lfpertile at yahoo.com.ar>
>>>>>>>>
>>>>>>>>> Pregunta, por qué desarrollar algo de cero en vez de ampliar
>>>>>>>>> alguna de las herramientas libres que hay.
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>> *De:* Fernando <correo at fernando.com.ar>
>>>>>>>>> *Para:* Igor Iván Spiler <spiler at gmail.com>
>>>>>>>>> *CC:* Talk-ar at openstreetmap.org
>>>>>>>>> *Enviado:* jueves, 1 de marzo de 2012 11:27
>>>>>>>>> *Asunto:* Re: [Talk-ar] comunidad
>>>>>>>>>
>>>>>>>>> Igor,
>>>>>>>>>
>>>>>>>>> Aprovecho para presentarme en la lista luego de algunos meses de
>>>>>>>>> acecho :P
>>>>>>>>>
>>>>>>>>> Hace tiempo soy aficionado a la cartografía web y al opendata /
>>>>>>>>> linkeddata, y desde hace un año mi lealtad acompaña a OSM, ya que luego de
>>>>>>>>> tanto tiempo fue la herramienta que me permitió armar mi propio deployment
>>>>>>>>> sin mayores dificultades. (mi experiencia anterior fue con Mapserver y tuve
>>>>>>>>> mucha difucultad para conseguir los shapes y ni hablemos de las calles)
>>>>>>>>>
>>>>>>>>> Actualmente tengo en un pequeño dedicado en leaseweb un tile
>>>>>>>>> server (http://tiles.sisdar.com/${z}/${x}/${y}.png), sólo de
>>>>>>>>> Argentina y hasta el zoom 15.
>>>>>>>>> En http://sisdar.com/mapa.php puse un slippymap con unos layers
>>>>>>>>> (geoJSON) donde se aprecian las escuelas de todo el país separadas por
>>>>>>>>> regiones y agrupadas con un cluster strategy (aún así en Firefox es algo
>>>>>>>>> lerdo, en comparación con Chrome)
>>>>>>>>>
>>>>>>>>> Estos dias estuve experimentando con Cascadenik, mod_tiles, etc,
>>>>>>>>> para hacer mapas mas lindos y acompañar el tilecache con tiles generados on
>>>>>>>>> demand, particularmente para los zoom >15
>>>>>>>>>
>>>>>>>>> Me gustaría intercambiar ideas y conocimientos, algún workshop de
>>>>>>>>> OSM Argentina sería delicioso, yo podría conseguir el lugar.
>>>>>>>>>
>>>>>>>>> Por otro lado, les agradezco infinitamente a quienes colaboran
>>>>>>>>> editando los mapas de Argentina, y me gustaría introducirme pronto en esos
>>>>>>>>> temas también.
>>>>>>>>>
>>>>>>>>> Es todo por ahora,
>>>>>>>>> Saludos,
>>>>>>>>>
>>>>>>>>> Fernando Sanz
>>>>>>>>> www.fernando.com.ar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/02/12 18:45, Igor Iván Spiler wrote:
>>>>>>>>>
>>>>>>>>> Hola gente de talk-ar,
>>>>>>>>>
>>>>>>>>> hace un tiempo empecé a desarrollar una aplicación en java para
>>>>>>>>> trabajar con datos geográficos, quizás hacer mapas webs, etc, la versión
>>>>>>>>> java es demasiado lenta para el volúmen de datos de OSM asique estoy
>>>>>>>>> escribiendo algunas partes de cero en C++ quizás a alguien le interese dar
>>>>>>>>> una mano, a diferencia de cuando la programé en java esta vez estoy
>>>>>>>>> publicando en un blog información de la aplicación a medida que progreso,
>>>>>>>>> si a alguien le interesa dar una mano tirando ideas, programando,
>>>>>>>>> redactando en el blog, lo que sea contáctenme!
>>>>>>>>>
>>>>>>>>> el blog:
>>>>>>>>>
>>>>>>>>> http://codeforprofit.wordpress.com/2012/02/29/diy-web-maps/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> saludos,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-ar mailing listTalk-ar at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-ar mailing list
>>>>>>>>> Talk-ar at openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-ar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-ar mailing list
>>>>>>>> Talk-ar at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-ar
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ar/attachments/20120304/16e86e60/attachment-0001.html>
Más información sobre la lista de distribución Talk-ar