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