ES talk:Catastro español/Importación de edificios/Conversión de datos
| Esta es una página de discusión para discutir mejoras en la página ES:Catastro español/Importación de edificios/Conversión de datos y sus temas relacionados. |
|---|
|
Estado de la construcción
Campo <bu-core2d:conditionOfConstruction> del conjunto de datos de edificios.
En concordancia con ES:Key:ruins: y como no se trata de ruinas históricas, creo que es mejor separar el estado del edificio de la naturaleza del mismo y usar este campo como Prefijo de ciclo vital de building en conjunción con el campo <bu-ext2d:currentUse>. Así si tenemos conditionOfConstruction=ruin, currentUse=residencial emplearíamos la etiqueta disused:building=residential. Si tenemos conditionOfConstruction=declined, currentUse=agriculture empleamos la etiqueta disused:building=barn y si conditionOfConstruction es functional empleamos la etiqueta building a secas. Javiersanp (talk) 10:45, 13 March 2017 (UTC).
- El inconveniente es que no se visualiza el edificio en la mayoría de representaciones del mapa. También existen otras alternativas.Javiersanp (talk) 19:45, 13 June 2017 (UTC)
Otra solución sería usar dos etiquetas building=* y ruins=yes o building=* y disused=yes. Javiersanp (talk) 12:08, 19 March 2017 (UTC)
- Fuertemente desaconsejada. Javiersanp (talk) 19:45, 13 June 2017 (UTC)
Propuesta final a continuación: Javiersanp (talk) 23:05, 19 June 2017 (UTC)
| Inspire | OSM |
|---|---|
| conditionOfConstruction=ruin, currentUse=* La construcción ha sido parcialmente demolida y algunos elementos principales (techo, paredes) han sido destruidos. Hay algunos restos visibles de la construcción [1] |
building=ruins, abandoned:building=* Para estructuras en ruinas que no tienen ninguna importancia histórica puede también ser utilizada conjuntamente con otras etiquetas, tales como "edificio". Por ejemplo: building=yes, ruins=yes, pero es mejor usar building=ruins y abandoned:building=yes en este caso.
ES:Key:ruins |
| conditionOfConstruction=declined, currentUse=* La construcción no se puede utilizar en condiciones normales, aunque sus elementos principales (paredes, techo) todavía están presentes. EJEMPLO: Una casa cuyas ventanas han estado durante mucho tiempo rotas o amuralladas (incluso ocupadas por ocupantes ilegales). [2] |
disused:building=*, building=yes Características que están en un estado razonable de reparación pero que actualmente no están en uso. Como ejemplos tenemos edificios de tiendas polvorientas disponibles o antiguos estacionamientos en desuso. ES:Key:disused: |
Simplificar edificios y partes
En los datos de Catastro, por cada edificio hay un objeto geográfico con la información del uso y estado del edificio y uno o varios objetos para cada "parte" del edificio definiendo valores para el número de niveles por encima y por debajo del suelo. Si el edificio tiene solamente una parte, creo que es bastante claro que se puede eliminar y pasar los valores del número de niveles al edificio. Es decir, una vía con building=* + otra vía igual con building:levels=* es lo mísmo que una vía con building=* + building:levels=*.
En los casos en los que el edificio tenga varias partes, ¿es necesario que las partes cubran por completo el edificio? ¿No se podría eliminar las partes de uno de los niveles, ya que no aportan más información como tipo de techo, y pasar las etiquetas al contorno? Hay un ejemplo de este sistema en este pueblo: http://www.openstreetmap.org/#map=18/28.37294/-16.7623
En 3D queda bien, al menos en este render: http://demo.f4map.com/#lat=28.3714708&lon=-16.7624734&zoom=19&camera.theta=49.888&camera.phi=0.573
En Simple_3D_buildings dice que las partes deben cubrir todo el contorno, pero también dice que pueden ser disjuntas, lo cual entra en contradicción.
"Cover the whole building outline with building:part=* areas, tagged with their respective height and other attributes. These areas may overlap each other or may be disjunct, depending on the building.
Para elegir el nivel cuyas partes se descartan, se puede escoger el más bajo o el que sumen mayor área sus partes. Javiersanp (talk) 12:53, 25 March 2017 (UTC)
Finalmente se descartan las partes del nivel más alto para pasar sus etiquetas de número de plantas al contorno del edificio. Las etiquetas de altura y plantas del edificio deben contener los valores máximos. Ver https://lists.openstreetmap.org/pipermail/tagging/2017-August/033056.html Javiersanp (talk) 16:39, 20 August 2017 (UTC)
Partes de edificio anidadas.
Relacionado con lo anterior. En los datos de Catastro hay casos de partes anidadas. Es decir, una parte grande con un nivel (por ejemplo 2 pisos), y una parte interna más pequeña con otro nivel (por ejemplo 3 pisos). La parte de tres pisos es interior a la de dos. En Catastro estas dos partes no se superponen. Es decir, la parte más grande está definida como un polígono con un hueco correspondiente a la parte más pequeña. Al convertir a OSM se genera una relación multipolígono para la parte de dos pisos con el contorno exterior con papel 'outer' y una vía sin etiquetas con papel 'inner' para el hueco. Como cada parte tiene distinto valor <localId>, por otro lado se genera otra vía que se superpone al hueco anterior con la etiqueta de nivel de dos pisos. Veo dos opciones:
- Eliminar la relación multipolígono y el hueco dejando la parte externa con la etiqueta building:levels=2 y por otro lado la parte interna con building:levels=3. No importa que ambas partes se superpongan.
- La otra opción sería mantener la relación multipolígono, pero al menos habría que fusionar las dos vías que resultan para el hueco. Es decir, pasar la etiqueta building:levels=3 al hueco y eliminar la parte que está dentro. Javiersanp (talk) 13:03, 25 March 2017 (UTC)
¿Qué hacer con los municipios?
El conjunto de datos de direcciones contiene el campo AdminUnitName con el nombre del municipio y se está trasladando a la etiqueta OSM addr:city=*. Se me plantea la duda que, según la wiki, esta etiqueta se refiere al nombre de la ciudad o pueblo indicada en la dirección, no al del municipio. Aunque en la mayoría de los municipios españoles su nombre y el de la capital coinciden, hay varios ejemplos en los que no sucede así. Por tanto habría que emplear una de estas soluciones:
- Obtener el nombre de la capital del municipio cuando no coincida.
- Trasladar el dato a una etiqueta más relacionada con el municipio como is_in:municipality o addr:municipality.
- Ignorar este dato.
En cualquier caso, el dato viene en mayúsculas, sin tildes y en muchos casos con variaciones respecto al nombre oficial. Por ejemplo, GUIA ISORA = Guía de Isora
Yo me decanto por la tercera opción. Soy detractor de las etiquetas de tipo is_in que repiten un dato en innumerables características cuando se puede obtener fácilmente a través de una consulta espacial por parte de los consumidores de datos. Javiersanp (talk) 18:54, 13 June 2017 (UTC)
- Yo también opino que es mejor ignorar esta información, es redundante y costaría mucho trabajo procesarla para dejar algo decente --Alejandroscf (talk) 10:26, 15 June 2017 (UTC)
- Se abre la discusión en la lista Talk-es.
Acordar etiqueta a utilizar para el enlace url a la foto.
El campo <bu-ext2d:document> del conjunto de datos de edificios contiene un enlace a una imagen de la fachada del edificio alojada en los servidores del Catastro. Hay que decidir si se va a usar este dato y que etiqueta utilizar. Opciones:
- No usar el dato. ¿Qué licencia cubre las fotos? ¿Podemos enlazarlas?..
- building:photo=*. Es la etiqueta propuesta actualmente, pero no existe...
- image=*. Es una etiqueta utilizada, pero con algo de polémica...
Javiersanp (talk) 19:20, 13 June 2017 (UTC)
- Todos los edificios tienen la url de una imagen pero no se garantiza que esa imagen exista en el servidor. Para agregarla a OSM habría que verificarlas primero, aparte de la dificultad que tendría mantener los enlaces actualizados en el futuro. Propongo que no se importen. Si se quiere usar las imágenes para mapear las direcciones, la situación exacta del portal, el estado del edificio, la url sigue estando accesible en un fichero en formato geojson que se genera con la opción --log=DEBUG del programa. En cualquier caso, está pendiente comprobar cual es la licencia de estas imágenes y si se puede usar.Javiersanp (talk) 07:50, 20 June 2017 (UTC)
- File:Autorizacion_fotos_fachadas_catastro.pdf Javiersanp (talk) 22:49, 9 July 2017 (UTC)
Confirmar si las piscinas se van a importar
Elementos <OtherConstructions> (Piscinas). Pon tu opinión aquí.
- Opino a favor de importarlas.Javiersanp (talk) 21:07, 13 June 2017 (UTC)
- ¿Se podría posponer la importación para no liarla más o complicaría mucho el tratamiento de los datos? --Alejandroscf (talk) 10:28, 15 June 2017 (UTC)
- Actualmente el programa las incluye, pero sería bastante sencillo ignorarlas. Javiersanp (talk) 23:12, 19 June 2017 (UTC)
- Yo también estoy a favor de que las piscinas sean importadas ya que es un elemento común y además puede ser muy útil en caso de incendio Javiersp (talk) 12:08, 15 June 2017 (UTC)
Decidir qué se va a hacer con las parcelas catastrales
Elementos <CadastralParcel> (Parcela Catastral). Se pueden utilizar para trazar elementos barriers (vallas, paredes, etc.) en límites exteriores de una parcela. Gpesquero (talk)
- Estoy a favor de que se importen las parcelas siempre y cuando no de problemas de aprobación ya que tengo entendido que al crear muchas relaciones a IMPORTS no les hace mucha gracia.Javiersp (talk) 12:51, 15 June 2017 (UTC)
- En el intento anterior de importación desde catastro se decidió no importar las parcelas en sí, ya que no son verificables en terreno por una persona que pase por allí. Lo que sí puede (y debería importarse, si es posible) son las vallas, setos, muros, etc. que sirven para la separación de parcelas. --DaveFX (talk) 16:17, 15 June 2017 (UTC)
- Yo no importaría las parcelas en sí, si acaso, fusionaría las parcelas adyacentes para crear un área mayor con etiqueta landuse=*. Es cierto que con una foto aérea puede ser difícil verificar los usos del terreno, pero no me parece que lo sea estando en el lugar o si lo conoces. Las separaciones de las parcelas si que me parece más complicado de verificar, pueden no estar visibles, tanto in-situ como con foto aérea. Podría dejarlas disponibles en un fichero para usar como fuente de datos y revisarlas una a una, pero no las incluiría junto con los edificios por que habría que poner barrier=yes sin especificar tipo concreto y habría mucho trabajo para revisar y eliminar manualmente las que no existen. Javiersanp (talk) 08:27, 16 June 2017 (UTC)
- Revisando los datos de parcelas, los datos originales no incluyen la información sobre el uso del suelo, no se puede generar una etiqueta landuse=*. En contra de importarlas. Javiersanp (talk) 11:01, 6 July 2017 (UTC)
Problemas relacionados con las direcciones
- Decidir qué hacer con todos los Address que no tengan un Building asociado (por ejemplo, los solares sin edificios). Gpesquero (talk)
- Voto por no incluir estas direcciones. Javiersanp (talk) 09:04, 16 June 2017 (UTC)
- Decidir si queremos utilizar la posición del elemento Address para ubicar la entrada del edificio. No es algo inmediato porque normalmente el elemento Address está ubicado fuera del edificio, cerca de la entrada real pero no siempre. Además, si se establece de forma automática la entrada en el punto más cercano del edificio, muchas veces se va a ubicar erróneamente. Gpesquero (talk)
- Se intenta mover. Si la distancia es demasiado grande o va a para a una esquina del edificio, coloca las etiquetas en la vía del edificio. Ver Problemas con las direcciones. Javiersanp (talk) 10:35, 6 July 2017 (UTC)
- Que hacer cuando en el elemento CadastralParcel al que está asociada la dirección hay más de un elemento Building separados. Javiersanp (talk) 21:49, 13 June 2017 (UTC)
- En ese caso habría que hacer un multipolígono con todos los building que compartan dirección y poner en el multipolígono la dirección --Alejandroscf (talk) 10:30, 15 June 2017 (UTC)
- +1 Javiersanp (talk) 23:08, 19 June 2017 (UTC)
- Tras revisar en más detalle los datos compruebo que es difícil distinguir cuando se trata de un conjunto de edificios similares o si es un edificio principal y otros secundarios (garage, almacén). Incluso puede darse edificios separados por grandes distancias en parcelas grandes. El programa ignorará estas direcciones quedando para comprobación manual. Javiersanp (talk) 14:51, 9 November 2017 (UTC)