[Talk-es] Herramienta de fusión de los datos actuales con el catastro

Mar Ene 24 08:41:12 GMT 2012

Ok, mas o menos queda claro.

Esta semana queremos dejar algo bastante aceptable por lo que vamos a
llevar un ritmo bastante rápido y seguramente os consultemos bastantes
dudas por aquí.

Una duda importante:
Para reutilizar el máximo de información que ya hay en la base de datos de
OSM estamos añadiendo antes de la carga de los shapefiles, que cargue de un
archivo .osm descargado con el área que vamos a importar. De esta manera
reutilizar todos los nodos, ways e información que ya existan. Entonces de
esta linea que habría que conservar:

<node id='1568151037' timestamp='2011-12-29T21:05:53Z' uid='Numero'
user='User' visible='true' version='1' changeset='10239760'
lat='38.9849932' lon='-3.8740057' />

El id, lat y lon lógicamente los guardamos para luego generar el archivo
resultado pero ¿seria necesario especificar en nuestro archivo
resultado quien creó el nodo?
Explicado de otra forma, en el archivo habrá nodos con id negativo para que
cree nuevos en la base de datos y nodos con numero existente para que lo
reutilice. Según yo entiendo a la hora de crear los nodos nuevos,
josm cogerá la id de usuario con la que yo he iniciado sesión para
apuntarlo en memoria. Y con los ids positivos (nodos existentes) ¿será
suficiente con el id para que sepa a que nodo me refiero
y seguirá manteniendo la información del que creó el nodo?

Saludos

El 23 de enero de 2012 11:27, Jaime Crespo <jynus en jynus.com> escribió:

> El 23/01/12, Ander Pijoan <ander.pijoan en deusto.es> escribió:
> > Hola a todos perdón por el email anterior, se ha comido todos los
> párrafos,
> > os lo reenvío para una lectura menos dolorosa,
> >
> > Después del parón por exámenes continuamos con los últimos flecos que
> > quedaban por pulir de la parte de traducción de datos de Catastro.
> >
> > Se que ya tubimos esta discusión y que Jynus nos va a colgarde un árbol
> > pero seguimos viendo necesario que algúnos "inner" lleven tags. Os
> adjunto
> > dos imágenes de ejemplo.
>
> Nadie ha dicho que los ways inner no deban tener etiquetas: lo que no
> tienen que tener es las etiquetas de la relación a la que pertenecen.
> Please 10 GOTO <
> http://lists.openstreetmap.org/pipermail/talk-es/2011-December/008722.html
> >
>
> > Un terreno rústico en el cual hay una zona dentro para un uso de suelo
> > distinto. Hay pocos casos, pero los hay.
> > http://i.imgur.com/bDoL3.png
> > http://i.imgur.com/BNyDd.png
> >
> > Un edificio que tiene en su "silueta" distintas alturas. Este es el
> > importante.
> > http://i.imgur.com/nklCO.png (Edificio de 2 plantas, que en un inner
> tiene
> > 3 y en el otro tan solo 1)
> > http://i.imgur.com/67wlL.png
>
> Si es un mismo edificio, son subedificios/distintas alturas, como
> quiera que se mapee eso (y no son miembros inner); si son edificios
> distintos, distintas relaciones (o vías inner, si no hace falta
> partirlas).
>
> > La solución sin poner tags a los inner sería hacer un inner vacio y crear
> > otro multipolygon que coincida con el inner que este si tenga los tags y
> no
> > esté relacionado para nada con el que lo rodea, pero en el caso de los
> > edificios no creo que tuviese lógica.
>
> > No se si esto es a lo que se refería Jynus.
>
> No. Aunque la otra opción no sé si te la va a reconocer nadie, ni creo
> que es topológicamente correcta (un miembre de un multipolígono que
> está dentro de otro pero no es inner o etiqueta distinta sin ser
> miembro). Tal vez debamos hacer/seguir una propuesta nueva (¿viste
> <http://t.co/YnP8d1rz> / <http://t.co/6hsx28Bt>?) u olvidarnos de las
> alturas por el momento...
>
> > Por lo demás estamos en la parte de intentar interpretar todos los tipos
> de
> > atributos Constru en los shapes Constru para intentar adecuarlos lo
> máximo
> > posible a sus tags, ya que estamos encontrando que el atributo a veces
> toma
> > valores que no vienen documentados.
>
> No esperéis tener que importar todos los datos, habrá muchos
> irrelevantes. Con tal de que esté el ID del objeto... No importéis
> nada que no sea relevante para OSM, con el ID ya se podrá acudir a los
> datos externos.
>
> > Ahora vendría la parte de "mezclar" los datos que genere el programa con
>
> La cosa se pone interesante.
>
> > los actuales de catastro. En esto si que necesitaremos que nos indiqueis
> > cuales suelen ser los pasos a seguir y qué opciones hay. Sabemos que se
> > puede lanzar consultas para modificar las bases de datos (los changeset)
> y
> > no se si también para borrar. Entonces imaginemos un caso en el que
> tenemos
> > una pequeña población que tiene algunos edificios ya en OpenStreetMap,
> > descargamos solo esos edificios y nosotros generamos únicamente la capa
> de
> > construcciones para hacer la comparación. ¿Cual tendría que ser mas o
> menos
> > el procedimiento? Se me ocurren dos formas.
> >
> > Comparar lo que hay subido y lo que hemos generado e ir eliminando de lo
> > que hemos generado lo que ya esté. Comparar los tags también para añadir
> > cosas que faltasen en lo que está en la base de datos. Una vez hecho esto
> > subir lo que tenemos que no está arriba. Puede ser complicado sobretodo
> si
> > los edificios los han hecho "a mano alzada" siguiendo las imágenes de
> > satélite, a ver como compruebas que dos edificios que no se parecen en
> nada
> > pero que están en el mismo sitio son el mismo.
>
> Me suena esto que dices...
>
> > O comparar para intentar pasar tags que ya tengan los edificios
> existentes,
> > volcarlos sobre nuestra capa (en caso de colisiones cual debería ser
> tomado
> > como correcto), borrar de la base de datos de OpenStreetMap, lo que hemos
> > descargado y volcar lo nuevo. Esta parece que puede ser mas "fácil" creo
> yo
> > pero también sobrecarga mas la red.
>
> No te van a dejar, eso de borrar datos masivamente sin intervención manual.
>
> > No se si me dejo algo pero creo que como recordatorio y para ir
> preparando
> > las muchas cosas que todavía quedan por hacer es suficiente.
>
> Tercera opción, y la que te recomendaron desde la lista import, y
> siguiendo la guía para importaciones: importación semiautomática, tal
> y como se está haciendo con el EGRN.
> --
> Jaime Crespo
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>

-- 
Ander Pijoan Lamas
Ingeniero Técnico en Informática de Gestión
Universidad de Deusto

Contacto:
Email: ander.pijoan en deusto.es
Móvil: +34 664471228
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120124/e4b7f1f5/attachment.html>