Siguiendo con el post anterior, si bien considero que es mejor evitar relaciones salvo que sean realmente necesarias, estoy pensando si no sería más conveniente aprovechar todos los polígonos del dataset con el dato de altura. Esto permitiría obtener una representación 3D más fiel a la realidad.
Buenas tardes @ignaciolep
Soy Nicolas, amigo de La Revacholiere, que lamentablemente no va a poder seguir con el proyecto. Aunque ella manejaba las comunicaciones estuvimos mirando este problema en conjunto y todavía tengo copia del código
Este es un problema. Consideré usar el algoritmo RDP Algoritmo de Ramer–Douglas–Peucker - Wikipedia, la enciclopedia libre pero tengo miedo de ensuciar la calidad del 99% de los datos por el 1% que está mal
Llegué a este algoritmo de fuerza bruta. Voy a ir deshabilitando uno a uno cada vértice del perímetro exterior de cada polígono. Si la diferencia en el área es de menos de 50 centímetros cuadrados, el vértice se considera superfluo. Esto debería eliminar todos los vértices malos sin tocar los vértices que contribuyen significativamente a la forma del edificio
Me interesa mucho esto pero google.me.dice que un edificio no puede tener más de un atributo de altura. Tenemos otras opciones? Esto eliminaría el problema de tener que determinar una altura característica
Hola. Google te esta cantando mal. Los edificios pueden tener distintas partes cada una con su altura, y eso que pasa en la realidad se puede mapear en OSM. El perimetro de todo el edificio que incluye todas sus partes (las mas altas y las mas bajas) se mapea con las etiquetas building=yes/(o el tipo), y su altura en height (el maximo de todas las partes), y las partes se mapean con building:part=yes y la altura correspondiente a esa parte. Ver Buildings - OpenStreetMap Wiki
Gracias Muralito, lo voy a tener en cuenta para la generación de los changefiles
Hice un geojson con las primeras 3000 figuras ordenadas por código de parcela. Me aseguré que no haya edificios adentro de edificios, cortes internos, ni intersecciones con el dataset vivo de osm a la fecha
https://pastes.io/primera-limpieza
Deberían encontrar los smp y las alturas como atributos en cada uno de los polígonos. Si piensan que este formato de geometría va a ser aceptable procedo a generar los .osc
Hola Nicolás! Bienvenido y gracias por retomar este proyecto! Es bueno que el trabajo de La_Révacholiere pueda continuar.
Gracias por compartir el nuevo GeoJSON y por tus avances. Estuve mirando el archivo.
A simple vista, el formato de la geometría parece bueno. Sin embargo, para que los datos sean compatibles con OpenStreetMap, habría que hacer algunos ajustes en las propiedades de cada polígono antes de generar archivos:
-
Etiquetas innecesarias: Los campos id, smp, y ogr_fid son metadatos del archivo de origen. No son etiquetas estándar de OSM y no deberían incluirse en el archivo final. Se pueden mantener en tus archivos de trabajo para referencia, pero se deben eliminar en la versión final.
-
Etiqueta de altura: La etiqueta para la altura en OSM es height, no “altura”. Deberías reemplazar altura por height.
-
Etiqueta de edificio: A cada polígono le falta la etiqueta fundamental building=yes. Sin esta etiqueta, los polígonos no serían reconocidos como edificios en OSM.
Por último, me gustaría insistir en un punto que comenté anteriormente: no descartar los datos que intersectan con edificios ya existentes en OSM. El archivo que compartiste, excluye estos casos. Si bien esto es lo más “seguro”, el mayor valor de este dataset reside en poder mejorar la calidad de los datos existentes. La mayoría los edificios de CABA fueron dibujados a mano sobre imágenes satelitales, por lo que sus geometrías suelen ser imprecisas y muy pocos tienen datos de altura.
Aprovecho para recordarte un punto clave: es fundamental no realizar importaciones masivas de datos. El camino ideal, como mencionamos antes, es ir trabajando de a poco, quizás por manzana o grupos de manzanas. Usando JOSM y su plugin Conflation, se puede comparar el dataset con los datos existentes en OSM, revisar los cambios y combinar la información cuidadosamente. Este proceso manual asegura la máxima calidad del resultado y respeta el trabajo previo de la comunidad.
Para que tengas una idea del resultado final que podríamos lograr, te recuerdo el ejemplo del Barrio Soldati. Podés visualizarlo en 3D en F4map.
Gran trabajo! Cualquier duda podés consultar acá o en el Grupo de Telegram osm_ar.
1 Like
Espeectacular! pero que bien le vendria un sumarle un DEM a esa vision 3D para que se vea mas realista y no quede todo plano plano.
1 Like
En Fortaleza (una ciudad de Brasil) hicimos una importación masiva de edifícios. Después de tratar los datos, nuestra estratégia fue:
1 - edifícios donde tocan polígonos existentes en el OSM: guardar estos edifícios en un archivo revisar.osm (o algo así)
2 - edifícios donde NO tocan ningún polígono existente en OSM: guardar en upload.osm.
Así, después de discutir la importación con la comunidade OSM y todo, los archivos del punto 2 hemos subido, y del punto 1 hemos usado trabajo manual para hacer la conflación (con JOSM, reemplazando geometria, para no perder el historial).
Cualquier duda podéis hablarme, con gusto 
1 Like
Hola Matheus! Muchas gracias por compartir tu experiencia.
La estrategia de separar los datos en dos versiones (una para los edificios que no se superponen con OSM y otra para los que sí) es muy buena. Permite avanzar en las zonas nuevas y, a la vez, tratar con cuidado los datos existentes mediante un conflation manual en JOSM.
Y tenés razón en un punto clave: las importaciones deben seguir las Directrices de Importación.
¿Podrías compartir la página de la wiki del proyecto de importación que comentaste?
Gracias!
No está actualizada, pero era la página original: Pt:Fortaleza/Importação de Edifícios PMF - OpenStreetMap Wiki
(hemos cambiado mucho el proceso, y no la actualicé todavía).
En la página 123, está el proceso, resumido, pero actualizado: https://sotm-br.github.io/2023/posters/anais.pdf
Aquí el código (creo que la última versión): buildings_import_osm_fortaleza.ipynb · GitHub
2 Likes
Gracias por compartir tu experiencia Matheus! Creo que tener una página en la wiki va a facilitar la revisión y construir consenso en la comunidad
Estuve revisando tu notebook y tenemos un flujo parecido. A la par de la wiki voy a crear un repositorio para que puedan mirar las manipulaciones de limpieza que tuve que hacer
Creo que puedo automatizar el proceso de conflations generando tres etapas de changefiles: creaciones de edificios nuevos, actualizaciones de edificios existentes para usar la nueva geometría, y una tercera etapa con todos los que no fueron incluídos en las otras dos
Ejemplo de changefile para la etapa 1
Antes de ponerme con la wiki y el repositorio voy a arreglar unos detalles mínimos que encontré. Si hacen zoom en las esquinas de algunos de los polígonos van a ver que hay vértices muy cercanos que terminan siendo redundantes. Creo que ya encontré la función que me dejaría corregirlos
Mientras tanto les pregunto: qué key de atributo debería usar para almacenar los SMP (Sección-Manzana-Parcela) del dataset original? Sería útil de tener para trazabilidad
si te sirve que esos datos vayan como parte de la direccion (que en principio supongo que no porque la direccion en CABA seria “calle x, nro y, etc…”) para manzana seria addr:block y para parcela addr:plot. Ver Key:addr:* - OpenStreetMap Wiki*
Lo de seccion no tengo idea…
o sino, si eso que queres guardar es un numero identificador de tu organismo, que pueda servir para identificador y posterior tratamiento del elemento, lo que tenes que hacer es definir (documentar algo) en el namespace de la etiqueta ref.
ref:AR:<aca acuerden algo que les sirva, si nombre del organismo, si provincia:organismo o que>… y luego de documentar eso en Key:ref - OpenStreetMap Wiki ya lo empezas a usar y listo.
Para almacenar el identificador catastral de Sección-Manzana-Parcela (SMP), la etiqueta estándar en OSM es ref:cadastre (taginfo).
Esto nos alinea con la práctica de facto y evita tener que crear un ref nuevo y específico para CABA. El formato sería directo, por ejemplo: ref:cadastre=003-001-006.
Aprovecho para aclarar que las etiquetas addr:block y addr:plot se usan si la manzana/parcela son parte de la dirección postal, pero en este caso el SMP es un código de referencia interno del catastro, no parte de la dirección.
Si te parece, antes de que te lances a redactar, cuando tengas la nueva muestra de datos ya corregida, ¿la podrías compartir por acá? Así le damos una mirada.
Gracias por la información!
Habiendo experimentado con el dataset unos días encontré dos problemas de simplificación
Primero tenemos líneas con vértices redundantes
Éstas fueron completamente arregladas. Por el otro lado tenemos esquinas de 90 grados que, por alguna razón, son redondeadas en uno de los edificios pero no en el edificio adyacente
Pude simplificarlas a una diagonal más económica en vértices
Pero intentar seguir destruyó el perímetro característico del edificio (sólo deberíamos ver ángulos de 90)
Adjunto los changesets con los que trabajé. El número es el valor de agresividad con el que se intenta optimizar las figuras
https://pastes.io/changeset-1rawosc
https://pastes.io/changeset-1000002osc
https://pastes.io/changeset-1000003osc
https://pastes.io/changeset-1000004osc
https://pastes.io/changeset-100004osc
Este último fue uno que creé por accidente pero sirve para demostrar los tipos de fallas de geometría que tenemos cuando el valor de tolerancia es demasiado alto. Recomiento abrir todos como capas distintas en JOSM y comparar.
Experimenté con varias funciones de PostGIS (ST_Snap, ST_Simplify, ST_SimplifyPreserveTopology, ST_SnapToGrid, ST_CoverageSimplify) además de varias implementaciones propias. Mi conclusión es que no hay herramientas automatizadas que puedan arreglar estos detalles sin afectar la calidad del 99.5% restante de los casos, y mi recomendación es proceder con un parámetro de tolerancia de 0.000002 como ilustrado en el segundo archivo.
Si tengo su aval puedo arrancar con el trabajo de documentación y publicación
Respecto al ejemplo que mencionás sobre la esquina redondeada, ¿me podrías pasar la ubicación exacta (coordenadas o intersección de calles) de ese edificio? Quisiera comparar el render de Ciudad 3D y la situación real a través de imágenes a nivel de calle para entender mejor los datos de origen.
Solo abrí el primer archivo y noté que faltan etiquetas, pero asumo que por el momento el trabajo está enfocado en la simplificación de las geometrías.
Como dato adicional, para la visualización del modelo Simple 3D, el complemento kendzi3d de JOSM funciona (o al menos funcionaba) muy bien y permite una revisión rápida directamente en el editor.
Sí, le faltan varias cosas al conversor que escribí. Quería enfocarme en terminar la limpieza de geometría para después preparar las tags y los .osc más limpios posibles
El SMP del edificio es 013-101-011 y las coordenadas -34.6012752 -58.4054837. Parece que la página de Ciudad 3D renderiza a un nivel de detalle menor al que entregan cuando uno descarga el dataset
Que interesante esto de la diferencia de detalle entre el render de la página de Ciudad 3D y el dataset. Sobre este punto me gustaría sumar a @Ariel_Anthieni, que tiene mucha experiencia con eso.
Colo, te sumo a este tema porque estamos viendo de preparar el dataset del tejido 3D de CABA para incorporarlo a OSM. El primer desafío es simplificar/limpiar los polígonos del dataset.
Notamos que el visualizador web de Ciudad 3D parece usar una versión simplificada de esas mismas geometrías, que sería ideal para lo que buscamos. ¿Sabrás por casualidad qué proceso de simplificación se aplicó sobre los datos para publicarlos en la web?