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 <[email protected]> > si, termine haciendo algo como lo q decis usando un quadtree :) > > > suerte! > > 2012/3/4 Igor Iván Spiler <[email protected]> > >> 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 <[email protected]> >> >>> 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>>> 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 <[email protected]> >>>>> >>>>>> 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 <[email protected]> >>>>>> >>>>>>> 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 <[email protected]> >>>>>>> >>>>>>>> >>>>>>>> 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 <[email protected]> >>>>>>>> >>>>>>>>> Pregunta, por qué desarrollar algo de cero en vez de ampliar >>>>>>>>> alguna de las herramientas libres que hay. >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> *De:* Fernando <[email protected]> >>>>>>>>> *Para:* Igor Iván Spiler <[email protected]> >>>>>>>>> *CC:* [email protected] >>>>>>>>> *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 >>>>>>>>> [email protected]http://lists.openstreetmap.org/listinfo/talk-ar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-ar mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-ar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-ar mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-ar >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Talk-ar mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ar
