Re: [Talk-ar] comunidad
Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de las
herramientas libres que hay.
De: Fernando
Para: Igor Iván Spiler
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 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
Re: [Talk-ar] comunidad
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
> Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de las
> herramientas libres que hay.
>
> --
> *De:* Fernando
> *Para:* Igor Iván Spiler
> *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
Re: [Talk-ar] comunidad
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
>
> 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
>
>> Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de
>> las herramientas libres que hay.
>>
>> --
>> *De:* Fernando
>> *Para:* Igor Iván Spiler
>> *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
>>
>>
>>
>>
Re: [Talk-ar] comunidad
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
> 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
>
>>
>> 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
>>
>>> Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de
>>> las herramientas libres que hay.
>>>
>>> --
>>> *De:* Fernando
>>> *Para:* Igor Iván Spiler
>>> *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áct
Re: [Talk-ar] comunidad
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
> 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
>
>> 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
>>
>>>
>>> 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
>>>
Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de
las herramientas libres que hay.
--
*De:* Fernando
*Para:* Igor Iván Spiler
*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áfico
Re: [Talk-ar] comunidad
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 > 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 > >> 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 >> >>> 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 >>> 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 > Pregunta, por qué desarrollar algo de cero en vez de ampliar alguna de > las herramientas libres que hay. > > -- > *De:* Fernando > *Para:* Igor Iván Spiler > *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
Re: [Talk-ar] comunidad
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 > 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 > >> 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 >> >>> 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 >>> 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 > > 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/
Re: [Talk-ar] comunidad
ah si llegas a necesitar algo avisame, saludos y contanos como t fue 2012/3/4 IgnacioZ > 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 > >> 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 >> >>> 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 >>> 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 > 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 > >> >> 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 suer
Re: [Talk-ar] comunidad
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ó: real0m0.323s user0m0.280s sys0m0.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 > 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 > >> 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 >> >>> 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 >>> 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? >>
Re: [Talk-ar] comunidad
si, termine haciendo algo como lo q decis usando un quadtree :) suerte! 2012/3/4 Igor Iván Spiler > 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ó: > > real0m0.323s > user0m0.280s > sys0m0.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 > >> 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 >> >>> 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 >>> 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 cre
Re: [Talk-ar] comunidad
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 > si, termine haciendo algo como lo q decis usando un quadtree :) > > > suerte! > > 2012/3/4 Igor Iván Spiler > >> 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ó: >> >> real0m0.323s >> user0m0.280s >> sys0m0.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 >> >>> 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 >>> 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
