ES:Catastro español/Importación de edificios/Conversión de datos/Problemas

From OpenStreetMap Wiki
Jump to: navigation, search
Idiomas disponibles — Spanish Cadastre/Buildings Import/Data Conversion/Problems
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ‎ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް

En esta página se describen los problemas encontrados para la conversión de los conjuntos de datos de los Servicios INSPIRE de Cartografía Catastral de la Dirección General del Catastro para la Importación de Edificios y como se soluccionarán.

Edificios con geometría multiparte

El conjunto de datos Building de Catastro contiene geometrías de dos tipos.

  • Polígono: Formados por una lista de anillos. El primer anillo es el contorno del edificio, los siguientes son anillos interiores que corresponden a huecos en el edificio. Si sólo hay un anillo el edificio se corresponde con una vía OSM. Si hay varios anillos tendríamos una relación multipolígono OSM con la primera vía con el papel 'outer' y las demás con 'inner'. Se trata de relaciones imprescindibles para reflejar los huecos y no abundan demasiado.
  • Multipolígono: Formados por varios polígonos. En OSM se corresponde con una relación en la que hay varias vías con el papel 'outer'. Este caso se produce por que hay edificios que tienen el mismo valor de referencia Catastral (campo 'localId'). Como no se va a importar este campo, en OSM no es necesario mantener estas relaciones que elevan mucho el número de relaciones a importar.
Relación multipolígono con varias vías exteriores

Para más información consultar la wikipedia: WKT

Solución: Se separan los edificios con geometría multiparte mediante este algoritmo.

Partes de edificio bajo el nivel del suelo

La capa de partes de edificios contiene geometrías con los campos:

Existen partes de edificios que no tienen niveles por encima del suelo. Se trata generalmente de partes que están fuera del contorno del edificio o que se corresponden con elementos tales como escaleras. Si tanto el número de niveles sobre y bajo rasante es cero, la parte corresponde a un porche.

Partes de edificios bajo el suelo.

Solución: Al transformar etiquetas se asigna building:part=roof a las partes de edificio sin niveles sobre ni bajo rasante ('numberOfFloorsAboveGround' = 'numberOfFloorsBelowGround' = 0). El algoritmo partes exteriores a edificios elimina el resto de partes bajo rasante.

Reducción del número de partes

En el conjunto de datos de partes de los edificios se importan sólo dos atributos, el número de niveles sobre y bajo rasante. El conjunto contiene edificios con partes adyacentes que tienen los mismos valores de niveles. Se puede reducir fusionando las geometrías de estas partes en una.

Otra estrategia para reducir más los datos es eliminar aquellas partes del edificio cuyos niveles coincidan con el valor máximo y mínimo para el edificio. Estos valores pueden trasladarse al contorno del edificio y las partes, al no contener ninguna otra información, son redundantes. En estos casos, las partes del edificio no lo recubrirán por completo.

El esquema 3D resultante funciona correctamente en algunos renderizadores, pero no en otros.

Esquema de edificios 3D con recubrimiento parcial del edificio

La imagen a la izquierda muestra como, para el mismo conjunto de datos, con el rederizador Glosm el valor de Key:building:levels del edificio prevalece sobre el de sus partes. Con el renderizador OSM2World, el valor del número de niveles de las partes prevalece sobre el del edificio y sólo se utiliza este en los 'huecos' no recubiertos por partes.

Solución: Algoritmo para reducción del número de partes.

Detección de piscinas dentro de edificios

Algunas piscinas pueden aparecer situadas dentro del contorno de un edificio. En estos casos, los datos de Catastro contienen dos entradas con geometría idéntica, una en el conjunto de datos de piscinas y otra en el conjunto de datos de partes de edificios. La parte de edificio que coincide con una piscina sirve para definir su vaso en el techo del edificio. Usando las etiquetas location=roof y layer=1 en la piscina, la parte de edificio coincidente es redundante y se puede eliminar. También se pueden eliminar los anillos interiores de geometrías del edificio que coincidan con la piscina. Si es el edificio completo el que coincide, por los casos revisados se corresponden a falsos casos y también se pueden eliminar.

En algunos pocos casos, estas piscinas no están localizadas en el techo del edificio, sino en el interior. No existe forma de identificar estos casos automáticamente y quedan para su revisión manual.

Solución: Algoritmo para detección del piscinas dentro de edificios.

Partes externas a edificios

En el modelo OSM empleado para representar edificios 3D sencillos, las partes de los edificios deben estar contenidas dentro del contorno del edificio. Sin embargo, en los datos de Catastro podemos encontrar partes fuera del contorno, incluso después de eliminar las partes soterradas. La imagen muestra un ejemplo. En verde el contorno de dos edificios y en rojo partes exteriores, a la izquierda la vista en alzado y a la derecha en planta.

Edificios con partes por fuera de su contorno

Se corresponden con partes del edificio con el suelo en pendiente que quedan bajo rasante a un lado y sobre rasante a otro. Existen dos soluciones posibles. La primera es expandir el contorno del edificio para englobar las partes externas anexas y promover la categoría del elemento de parte a edificio cuando no esté anexa al contorno. La segunda es eliminar estas partes de la importación.

También se pueden encontrar partes de edificio 'huérfanas', es decir, sin que exista edificio asociado.

Edificio con una parte fuera de su contorno y no contigua

Solución: El algoritmo partes exteriores a edificios elimina las partes externas al contorno del edificio si existe. Si encuentra partes sin edificio asociado, no las elimina y genera un contorno a partir de la unión de las partes.

Nodos duplicados

En la mayoría de los casos, la capa de edificios de Catastro tiene una precisión estimada de 0,1 metros. Se produce el caso de nodos muy próximos separados por escasos centímetros. Pueden encontrarse consecutivos en una misma geometría o pertenecer a dos edificios adyacentes. Su existencia puede implicar errores de topología y complica la resolución de este problema y el de nodos excesivos.

  • Nodos duplicados.
  • Pueden producir errores topológicos.

Solución: algoritmo para añadir nodos topológicos y simplificar nodos duplicados.

Errores topológicos

Los datos de Catastro pueden contener errores topológicos. Los errores topológicos pueden dar lugar a que se superpongan geometrías en vez de ser adyacentes.

  • Las cruces rojas duplicadas indican segmentos con errores topológicos.
  • Edificios superpuestos.

Solución: algoritmo para añadir nodos topológicos y simplificar nodos duplicados.

Nodos innecesarios

Los ficheros de Catastro contienen un número excesivo de nodos para cada geometría.

Nodos excesivos en una línea recta.

Solución: Para identificar y eliminar se utiliza un algoritmo para simplificar geometrías.

Vértices con ángulo demasiado bajo

Los datos originales contienen geometrías con vértices que forman un ángulo con los vértices adyacentes demasiado pequeño. Parecen el resultado de haber hecho una diferencia entre dos polígonos con tramos que deberían ser adyacentes pero topológicamente eran incorrectos. Este problema no es detectado por las pruebas de validación de JOSM.

Vértice con ángulo demasiado pequeño.

Otra variante es encontrar dos vértices consecutivos con ángulo bajo (en 'zig-zag').

Vértices en zig-zag.

Solución: El algoritmo para eliminar geometrías no válidas también trata este problema.

Geometrías basura

Los datos originales contienen edificios o partes que parecen el resultado de haber hecho una diferencia entre dos polígonos con tramos que deberían ser adyacentes pero topológicamente eran incorrectos. Este problema no es detectado por las pruebas de validación de JOSM.

Geometría con área demasiado baja.

Solución: El algoritmo para eliminar geometrías no válidas elimina geometrías que no superen las pruebas de validación GEOS o cuya área esté por debajo de un umbral.

División de los datos en tareas

No es conveniente subir conjuntos de datos de grandes dimensiones al servidor OSM. Por eso es necesario dividir los datos de Catastro, que cubren todo un municipio, en fracciones más pequeñas o tareas. Se propone usar el gestor de tareas para crear proyectos para los datos a importar. Por conveniencia se separa cada municipio en dos proyectos, uno para urbana y otro para rústica.

Es importante que las vías contenidas en cada tarea no compartan nodos con otras vías contenidas en otra tarea. Si no es así, antes de subir una tarea habría que comprobar si hay coincidencias con los nodos existentes y fusionarlos para evitar duplicados.

Se pueden usar los elementos de zonas catastrales para separar los datos por tareas. Estos elementos pueden ser de dos tipos según el valor del campo <cp:levelName>:

  • Polígonos: Forman una partición completa del municipio. Es decir, la unión de todos ellos es igual al área del municipio sin que ningún polígono se superponga a otro. Los edificios contenidos en 'Polígonos' que no están en 'Manzanas' se corresponden con el Catastro de Rústica.
  • Manzanas: Cubren los núcleos de población. Forman grupos separados por calles. No se superponen entre si, pero si sobre polígonos. Los edificios contenidos en 'Manzanas' se corresponden con el Catastro Urbano.
  • Ejemplo del conjunto de datos Zonificación Catastral.
  • Detalle de las zonas.

Primero es necesario generar ficheros en los que cada polígono representa una tarea que servirán para crear los proyectos en el gestor de tareas.

Posteriormente se reparten los edificios en ficheros OSM correspondientes a cada tarea.

Corrección de los nombres de viales

Los nombres de los viales en el conjunto de datos de direcciones vienen en mayúsculas, sin tildes y con distintas informaciones mezcladas. Es necesario corregir los nombres según las reglas de normalización. Además, el nombre de vía en la información de Catastro puede contener errores o discrepancias respecto a la información recogida a pie de calle.

El proceso de combinación de nombres de viales da prioridad a los nombres existentes en OSM e intenta encontrar de forma automática el nombre correspondiente en OSM. Si no se encuentra ninguna coincidencia, el programa propone una corrección del nombre del vial. Para ello, de izquierda a derecha, se distinguen tres partes:

  • Tipo de vía: Dos caracteres para indicar la designación genérica del tipo de vía. La relación de valores posibles se especifica en este documento, pero en los datos pueden aparecer algunos adicionales como AD=Aldea (en lugar de AL), PC=Placeta/Plaça, PG=Polígono (en lugar de PL), SB=Subida (en lugar de SU), SC=Sector y otros.
    • Para algunos tipos de vía existe más de una traducción posible, como AL=Aldea/Alameda, CJ=Calleja/Callejón, CR=Carretera/Carrera, etc.
    • Algunos tipos de vía no se refieren a ningún vial, sino a un lugar o zona territorial. En estos casos el texto debe ir en la etiqueta addr:place=* en lugar de addr:street=*.
  • Nombre de la vía propiamente dicho. El programa realizará una conversión de mayúsculas a minúsculas siguiendo las normas de normalización. Pueden aparecer artículos desplazados del comienzo al final del nombre, separados por coma o paréntesis. Deben corregirse manualmente.
  • Otros datos: Generalmente, pero no siempre, puede aparecer después del nombre de la vía texto adicional. Generalmente se tratará del nombre de una o varias localidades donde está ubicada la vía. Las localidades pueden estar entre paréntesis, o separadas por un guión. Se trata de información que no forma parte del nombre y debe ser eliminada manualmente o colocada en otra etiqueta.

Para el tipo de vía el programa convierte la clave de dos letras a la designación completa. Los valores a transformar se leen de un fichero de configuración que puedes completar o adaptar. El fichero está en formato texto con valores separados por punto y coma, editable con cualquier editor de texto o aplicación de hoja de cálculo y se llama 'highway_types.csv'. No va incorporado en la descarga del programa, se genera en la carpeta de instalación tras la primera ejecución del mismo. Debes seleccionar la alternativa más apropiada para los tipos que tengan varias opciones (como AL=Alameda en lugar de Aldea/Alameda) o traducirlos (CL=Carrer en lugar de Calle), si es adecuado a tu zona de trabajo.

Al generar el fichero de salida en formato OSM, se colocará el nombre de la vía en una etiqueta addr:place=* en lugar de addr:street=* si el tipo de vía empleado en el fichero de conversión es uno de los siguientes: Agregado, Aldea, Área, Barrio, Barranco, Cañada, Colegio, Cigarral, Chalet, Concejo, Campa, Campo, Caserío, Conjunto, Diputación, Diseminados, Edificios, Extramuros, Entrada, Ensanche, Extrarradio, Finca, Grupo, Huerta, Huerto, Jardines, Lugar, Mercado, Muelle, Municipio, Masias, Monte, Manzana, Poblado, Partida, Polígono, Páramo, Parroquia, Solar, Terrenos, Urbanización, Bulevar, Sector. Esta lista se puede modificar mediante la variable 'place_types' en el fichero de configuración 'setup.py'.

Ejemplos de conversiones
Catastro Conversión propuesta Conversión final
CL PEÑA LA (CHARCO DEL PINO) Calle Peña la (Charco del Pino) Calle la Peña
CL JOSE REYES MARTIN (GRANADILLA ABON) Calle Jose Reyes Martin (Granadilla Abon) Calle José Reyes Martín
CL NISCALO-SERRETA T Calle Niscalo-Serreta T Calle Níscalo

Problemas con las direcciones

Problemas direcciones postales.png

Esta imagen muestra algunos de los problemas que podemos encontrar con las direcciones. Es una combinación del mapa OSM, números de portal de Cartociudad (los rótulos pequeños) y los datos convertidos de Catastro para edificios y direcciones. Las direcciones de tipo "entrance" muestran el icono de una puerta y las de tipo "parcel" un icono azul de placa de número de portal.

  • Los nodos de direcciones están desplazados respecto al contorno del edificio o de la parcela.
  • Aparecen direcciones de tipo "entrance" y "parcel" de forma poco homogénea.
  • Direcciones desplazadas respecto a su posición correcta. Se han señalado algunos ejemplos con flechas.
  • Edificios que tienen varias direcciones. Los edificios entre las calles Juan Rumeu García y Rafael Arocha Guillama y entre la anterior y la calle Lorenzo García del Castillo tienen acceso y número de portal por dos calles. Esto no es problema si ambas direcciones son de tipo "entrance" y están correctamente situadas. Este problema no es exclusivo de Catastro, también puede darse en Cartociudad.
  • Si se intenta que el programa traslade las entradas al punto más cercano sobre el contorno del edificio, hay que tener en cuenta que en algunos casos, el/los edificios están inscritos dentro de la parcela, como en el caso de casas tipo chalet o edificios rodeados de zonas ajardinadas. Es el caso de los edifícios situados en la parte superior de la imagen anterior. Si la parcela es un reciento privado, con una barrera (muro, cerca, valla), el nodo de entrada debe estar situado en el contorno de la parcela que no se van a importar [1]. Si existe una zona transitable libremente hasta el edificio (escaleras, acera), aunque esté en una parcela privada, el nodo debe estar situado en el contorno del edificio [2]. El programa no puede distinguir estos dos casos, el usuario deberá decidir que hacer. El programa deberá no trasladar al contorno del edificio aquellas direcciones que están situadas más lejos que un umbral a definir.

Solución: Las direcciones se colocan en distintos elementos según la siguiente tabla:

Resumen de situación de las direcciones
<AD:specification> Nº de edificios Posición addr: Notas
parcel 0 N/A No se importan
parcel 1 Area cerrada Poner las etiquetas de la dirección en la vía del edificio
parcel > 1 N/A No se importan
entrance 0 N/A No se importan
entrance >= 1 Nodo Mover el nodo al contorno del edificio más cercano siempre que la distancia sea pequeña y la nueva ubicación no coincida con una esquina del edificio, en otro caso no se importa.