Sandbox

EDIT BELOW THIS LINE

Googoo gaga

Flujo: Tejido Urbano → limpieza geométrica → Control 1 → clasificación contra OSM en vivo → Control 2 → archivos de salida.

Resultado	Formato	Quién lo sube	Ronda 1	Ronda 2
Nuevo	un `.osm` por sección	cuenta de importación	sí (primer paso)	se repite con OSM nuevo
Reforma	desafío de MapRoulette	cada mapeador, desde su cuenta	sí (segundo paso)	se repite con OSM nuevo
Conflictos	un `.osm` por cuadra	la comunidad, a mano	en espera	sí

Estructuras en Conflictos por motivo (datos de OSM del 27/09/2026)
Motivo	Estructuras
Superposición sin vínculo	15.666
Vecino que permanece	11.808
N:1 con etiquetas en varios lotes	10.573
Enredo N:M	1.342
`building:part` ya en OSM	770
1:N con etiquetas ambiguas	637
Huella partida en la limpieza	538
Geometría inválida	0

Objetivo

El objetivo es incorporar a OpenStreetMap el dataset oficial de edificación de la Ciudad de Buenos Aires, con dos fines: cargar los edificios que todavía no están en el mapa, que son la mayoría, y actualizar los que ya están pero tienen geometría desactualizada o carecen de altura.

Cronograma

2024: comienza la discusión en el hilo de OSM Argentina.
Se publica este plan en la wiki y en el foro con la etiqueta import. Desde ese momento corren los 14 días de espera que exigen las Import Guidelines.
Se responden las objeciones que surjan en el foro durante esos 14 días.
Ronda 1: en dos pasos. Primero se sube Nuevo desde la cuenta de importación; después se vuelve a descargar OSM, se ejecuta el proceso otra vez y se habilita el desafío de Reforma en MapRoulette. Conflictos queda en espera.
Ronda 2, una vez que la comunidad procesa la ronda 1: se vuelve a descargar OSM, se ejecuta el proceso completo otra vez y se publican Nuevo, Reforma y Conflictos.

Después del punto 1 no hay fechas fijas: cada paso comienza cuando se completa el anterior.

Datos a importar

Introducción a los datos

El dataset Tejido Urbano del GCBA contiene unas 1,39 millones de huellas de edificación, repartidas en las 94 secciones catastrales de la ciudad. Cada huella incluye su altura en metros y, en casi todos los casos, su código catastral (Sección-Manzana-Parcela, de ahora en adelante referido como SMP).

El dataset no incluye la cantidad de pisos: el campo altos figura en cero en toda la fuente, por lo que building:levels queda fuera del alcance.

Origen y acceso a los datos

Lo publica el GCBA en su portal de datos abiertos, en SHP, GeoJSON y CSV: Tejido Urbano en data.buenosaires.gob.ar.

El conjunto contiene datos hasta 2021 y el archivo no cambia desde el 10/05/2021. Los edificios construidos o demolidos después de esa fecha no figuran en él. No se aplica ninguna regla especial para ellos: datos algo desactualizados son mejores que ninguno. Una misma copia descargada sirve para todas las rondas.

Licencia

CC-BY-2.5-AR, con autorización explícita del GCBA para su uso en OpenStreetMap.

Tamaño del conjunto de datos

Unas 1,39 millones de huellas en 94 secciones. Con los datos de OSM del 27/09/2026, cerca del 86 % de las estructuras no tiene ningún edificio de OSM debajo (ver Combinación de datos).

Etiquetas en OSM

building=yes en todos los edificios.
height=* en metros, con la altura del dataset.
ref:cadastre=<SMP> (por ejemplo 87-006A-015) en el way de cada edificio, pero no en las partes. Se eligió ref:cadastre y no smp porque es la clave que se usa internacionalmente para códigos catastrales: registra miles de usos, contra ninguno de smp.

Muchos edificios están formados por varias huellas de distinta altura unidas por pared: casi 1 de cada 3 pares de huellas que se tocan dentro de un mismo lote tienen alturas distintas. En esos casos se usa el modelo Simple 3D Buildings (S3DB, la convención de OSM para describir un edificio como volumen: un contorno general más partes con su propia altura, que es lo que leen los visores 3D como OSM Buildings o F4 Map): el contorno completo se publica como building=yes con la altura mayor, y cada huella como building:part=yes con su propia altura.

Asentamientos informales (parcelas con código BEM*): cada huella se publica como edificio independiente (building=yes), sin ref:cadastre y sin altura. Las alturas de origen en estos barrios no son confiables; hay valores imposibles, como 830 m.

Combinación de datos

Antes de publicar, cada estructura se compara con lo que ya existe en OSM, para no duplicar edificios. Se denomina estructura a un edificio o a un grupo de huellas que comparten pared. Cada una se asigna a uno de tres grupos:

Nuevo: no se superpone con ningún edificio de OSM y se publica tal cual. Es la gran mayoría: cerca del 86 % de las estructuras.
Reforma: coincide claramente con un único edificio de OSM. La geometría de ese edificio se reemplaza por la de la ciudad, y se conservan su id, su historial y sus etiquetas (nombre, dirección, etc.).
Conflictos: la superposición es ambigua: puede haber varios edificios de OSM involucrados, una geometría inválida o un edificio con etiquetas que podrían perderse. Estos casos se revisan manualmente, uno por uno. Con los datos de OSM del 27/09/2026 son el 8,5 % de las estructuras (8,6 % de las huellas del dataset)

Antes de clasificar, cada ejecución omite sin modificarlas las estructuras que ya están en OSM. Una estructura se omite si un edificio de OSM lleva su ref:cadastre y ese SMP corresponde a una sola estructura, cualquiera sea su forma, para conservar la edición posterior de un mapeador. También se omite si un edificio de OSM vinculado a ella fue editado por última vez por la cuenta de importación. Con los datos del 27/09/2026 se omiten 47 estructuras, que alguien ya había importado a mano del mismo dataset en julio de 2026.

Con los datos de OSM del 27/09/2026, las 430.353 estructuras se reparten así

Estructuras por grupo (ejecución completa sobre los datos de OSM del 27/09/2026)
Grupo	Estructuras	Proporción
Nuevo	371.754	86,4 %
Reforma	22.078	5,1 %
Conflictos	36.521	8,5 %
Total	430.353	100 %

Conflictos incluye los grupos retenidos por la regla del vecino

La proporción de Nuevo varía mucho entre secciones. En 63 de las 94 supera el 85 %. En 15 secciones queda por debajo del 50 %, casi todas en el centro, el puerto y La Boca, donde OSM ya tiene muchos edificios dibujados; en la sección 6 llega al 10 %.

Ejemplo: en el lote 05-035-027, en Talcahuano 36, hay seis huellas de la ciudad unidas por pared, de entre 8,4 m y 19,6 m de altura; el escalonamiento se puede corroborar en imágenes satelitales. Forman una sola estructura. Si esa estructura se superpone con un único edificio de OSM, las seis se clasifican juntas como Reforma; nunca quedan unas como Nuevo y otras como Reforma.

Ejemplo real (manzana 46-130, entre Crespo, Agustín de Vedia y Rabanal): el dataset contiene 32 huellas en esta manzana. 20 forman estructuras que no tocan ningún edificio de OSM y se publican como Nuevo. El galpón ya mapeado queda vinculado a la estructura que ocupa su lugar, que pasa a Reforma (2 huellas). Las estructuras vecinas que también se superponen con el galpón, pero sin vínculo, pasan a Conflictos (10 huellas). Una vez que el galpón se reforme en OSM, esas estructuras ya no pisan ningún edificio existente y pueden recategorizarse como Nuevo en la ronda siguiente. La regla es estricta: cualquier superposición con un edificio existente basta para que una estructura deje de ser Nuevo.

Ejemplo real (SMP 38-110-029): el edificio de OSM (289 m²) y la huella del dataset (304 m²) tienen casi la misma forma, pero el dibujo de OSM está desplazado unos metros hacia un costado. Comparten el 78 % del área del menor, bastante por encima del mínimo del 50 %. Se reemplaza solo la geometría; el id, el historial y las etiquetas de OSM se conservan.

Las reglas completas están en el anexo técnico, Fase 4: cuándo dos polígonos se consideran "el mismo edificio", qué ocurre si hay varios de cada lado y qué se hace si el edificio de OSM ya tiene nombre o dirección.

Importación de datos

Plan de trabajo

El proceso consta de tres pasos:

Limpieza geométrica: el dataset trae errores de codificación, polígonos superpuestos, agujeros minúsculos y bordes que no encajan. La geometría se corrige hasta que cada cuadra queda sin huecos ni superposiciones (detalle en el anexo).
Clasificación contra OSM: justo antes de publicar se descarga el estado actual de OSM (los "datos en vivo") y se compara estructura por estructura (ver Combinación de datos).
Revisión: Nuevo y Conflictos se publican como archivos .osm para JOSM, uno por sección (Nuevo) o por cuadra (Conflictos). Reforma se publica como desafío de MapRoulette, con una tarea por cada conjunto de grupos de Reforma vecinos dentro de una misma cuadra, para que las paredes compartidas tengan un solo juego de nodos. Cada mapeador revisa su tarea y la sube desde su propia cuenta.

Dataset Tejido Urbano ──► Limpieza geométrica ──► Control 1 ──► Clasificación contra OSM ──► Control 2
                                                                         ▲                    │
                                                                    OSM en vivo               │
                                                                                              │
   ┌──────────────────────────────────────────────────────────────────────────────────────────┘
   ├──► Nuevo (archivos por sección) ──┐
   ├──► Reforma (MapRoulette) ─────────┴──► Ronda 1 ──► Ronda 2 (nueva descarga y ejecución)
   └──► Conflictos (en espera) ────────────────────────► Ronda 2

Los controles son verificaciones automáticas (detalle en la Fase 5). El Control 1 revisa la geometría limpia antes de mirar OSM: coberturas válidas por cuadra, sin geometrías nulas y sin huellas perdidas. El Control 2 revisa la clasificación antes de generar archivos: ningún Nuevo pisa un edificio de OSM y ninguna estructura queda partida. Si alguno de los dos falla, la ejecución se detiene y no se genera ningún archivo. La ronda 2 repite el proceso completo con OSM descargado de nuevo.

Los umbrales se calibraron con una copia fija de OSM del 5 de octubre de 2025 (la "línea de base"). Esa copia se usa solo para calibrar: ningún resultado publicado sale de ella. Las cifras de clasificación de este documento se calcularon con los datos de OSM descargados el 27/09/2026.

Para los mapeadores, las herramientas son JOSM, con el plugin de conflación para revisar los casos de Reforma, y MapRoulette para trabajar tarea por tarea. El procesamiento de datos se ejecuta aparte, de forma automática (herramientas y comandos en el anexo).

Publicación:

Se registra una cuenta dedicada, (usuario)_Import, que sube únicamente los archivos de Nuevo mediante un script. Conflictos no se sube automáticamente: los archivos quedan disponibles para que la comunidad los revise y los suba manualmente. Reforma tampoco pasa por esta cuenta; cada mapeador la sube desde la suya, vía MapRoulette.
Cada changeset lleva source=* con el dataset y la fecha del archivo: Buenos Aires - Tejido Urbano (data.buenosaires.gob.ar, 2021-05-10). Su comentario incluye el hashtag #tejido-urbano-caba, tanto en Nuevo como en las tareas de Reforma, cuyo desafío propone ese comentario.
El proceso se realiza en dos rondas, según el cronograma: la primera publica Nuevo y Reforma en dos pasos (primero Nuevo; después, con OSM descargado de nuevo, Reforma), y la segunda, con OSM descargado de nuevo, agrega Conflictos.

Repositorio y código: github.com/nicolaslazo/osm-bsas-building-import.

Plan de reversión

Antes de la primera subida se documenta el procedimiento para deshacer la importación, como exigen las Import Guidelines. Todos los changesets llevan el hashtag #tejido-urbano-caba en su comentario. Si una subida resulta defectuosa:

Se reúne la lista de changesets afectados: los de la cuenta de importación, para Nuevo, y los que llevan el hashtag, para Reforma. Ambos se filtran en OSMCha por usuario, comentario y rango de fechas.
Se revierten con osm-revert o con el plugin Reverter de JOSM, de a uno o por lote.
Donde otra persona editó un objeto después de la subida, la reversión produce un conflicto. Se resuelve a mano en JOSM y se conserva la edición posterior cuando es válida.
La reversión se anuncia en el hilo del foro, con la lista de changesets revertidos.

Importaciones similares

Este plan sigue la estructura del import de edificios de Fortaleza (Brasil), que a su vez cita otros proyectos brasileños:

Anexo técnico

En esta sección se resume cada decisión con su motivo y las cifras que la respaldan, medidas en ejecuciones de prueba sobre PostGIS 3.6. El código completo está en el repositorio.

Fase 1: código catastral (SMP)

Antes de cualquier limpieza geométrica debe corregirse la lectura del código catastral (SMP, sección-manzana-parcela), porque los errores en este punto se propagan a todos los pasos siguientes:Normalización: se eliminan los ceros a la izquierda de la sección y de la parte numérica de la manzana, sin modificar los sufijos con letra (006A → 6A), y la grafía original se guarda en una columna aparte. Por ejemplo, 20-014 y 020-014 corresponden a la misma cuadra: las cuatro huellas de 020-014-045 comparten pared con las de 20-014. Sin normalizar, el proceso las trataba como dos cuadras distintas y limpiaba cada parte por separado. El problema afectaba a 19 secciones.

SMPs inválidos: antes se reescribían como 0-0-0, lo que los agrupaba a todos en una cuadra inexistente. Ahora se guardan como NULL y cada huella se publica como lote propio, sin ref:cadastre. Son 20.864 huellas.
SMPs atípicos: códigos que no son un número ordinario con sufijo de letra, o lotes con más de 50 huellas (asentamientos informales, plazas, baldíos fiscales, etc.). En estos casos no se agrupa: cada huella se trata como edificio y lote independientes. Son 2.072 lotes y 40.556 huellas. La familia más grande es la de los asentamientos informales (BEM, 8.651 huellas), que además se publican sin altura y sin código catastral. Otro caso es el Cementerio de la Chacarita (49-027-0FRE): un solo lote de casi un kilómetro de lado con 72 huellas, donde cada panteón, cada galería de nichos y cada tramo del muro perimetral es una huella aparte.
Se corrigen además parcelas unidas por una barra y una Ñ con doble codificación.

Fase 2: tolerancias geométricas

Dos parámetros definen cómo se "cose" cada cuadra para que no queden huecos ni superposiciones:

Distancia de snapping (unir vértices cercanos): 22 cm. También se probó llevar a 22 cm el ancho de hueco tolerado, con un resultado mucho peor: 729 huellas vaciadas o desplazadas más de 2 m, contra 253 con la combinación elegida. Por eso el ancho de hueco se mantuvo en 2,2 cm y solo el snapping se subió a 22 cm.
Simplificación de la coertura (ST_CoverageSimplify) a 22 cm, incluidos los bordes entre cuadras. Reduce los vértices de 15,1 a 12,0 millones sin desplazar ningún punto más de 50 cm.
Las huellas que la limpieza deja vacías (su geometría colapsa a nula) se descartan y no pasan a Conflictos. Son 253 de 1,39 millones: duplicados casi idénticos con distinta altura.
Se fija la versión de PostGIS en 17-3.6, porque la limpieza de cobertura no existe en 3.5, y el runner de migraciones se detiene ante el primer error en lugar de continuar silenciosamente.
Las huellas de un mismo lote y altura se unen en un solo edificio solo si comparten una pared (una línea). Si se tocan únicamente en una esquina (un punto), no se consideran conectadas.

Ejemplo real (lote 77-098-004C, Mercado Vélez Sarsfield): el dataset de origen trae 8 huellas superpuestas, cinco de ellas de 2,8 m. Las huellas de igual altura que se tocan se unen, las anidadas se recortan de su contenedor y la cobertura se limpia y simplifica. El resultado son 4 partes sin superposición y 50 vértices en lugar de 139.

Fase 3: modelo de salida

Los archivos .osm se generan con ogr2osm, leyendo directamente de PostGIS y unificando los nodos con la misma coordenada redondeada, de modo que los edificios vecinos compartan los nodos de su pared común.
Redondeo de coordenadas: 7 decimales (~1,1 cm), la precisión nativa de OSM. Cada punto se desplaza como máximo ~0,55 cm, menos que el ancho de hueco de la Fase 2, por lo que no se rompen la cobertura ni las paredes compartidas.
Las estructuras con sectores de distinta altura se publican con el modelo Simple 3D completo: un contorno building=yes más una building:part=yes por huella, como en el ejemplo de Combinación de datos.
Agujeros interiores, como los patios: si el hueco mide menos de 1 m² se rellena, por tratarse de ruido de escaneo; si es mayor, el edificio se publica como relación type=multipolygon. El hueco más grande detectado es la cancha del estadio Monumental (26.347 m²).

Fase 4: clasificación

En esta fase se decide si cada estructura es Nuevo, Reforma o Conflictos. Las reglas son estas:

Vínculo: una estructura y un edificio de OSM quedan vinculados cuando se superponen en al menos 1 m² y en más de la mitad del menor de los dos. Se probó vincular con cualquier superposición a partir del 5 %, pero eso generaba cadenas N:M enormes (hasta 1.954 huellas enredadas con 1.613 edificios de OSM), porque OSM y la ciudad no siempre dividen los edificios por las mismas paredes.
1:1 y N:1 (una o varias huellas de la ciudad contra un solo edificio de OSM) se clasifican siempre como Reforma, aunque la superposición sea baja. La geometría de la ciudad proviene de fotogrametría y es más precisa que un dibujo a mano; una superposición baja indica que el dibujo de OSM está desactualizado, no que el vínculo sea incorrecto.
Regla del vecino: si alguna parte de un grupo de Reforma se superpone con un edificio de OSM no vinculado que va a permanecer (sin cambios o en Conflictos), el grupo entero pasa a Conflictos, para no agregar superposiciones nuevas a OSM. Con los datos de OSM del 27/09/2026, esta regla retiene el 27 % de los grupos que de otro modo serían Reforma (6.847 de 25.236). Si el vecino se publica, el grupo se libera en la ronda siguiente.
1:N (una huella contra varios edificios de OSM): se fusiona como Reforma si a lo sumo uno de esos edificios tiene etiquetas propias (nombre, dirección, etc.). Con dos o más edificios etiquetados pasa a Conflictos, porque no hay un criterio seguro para decidir qué etiquetas conservar.
N:1 (varias huellas contra un edificio de OSM): la estructura con mayor superposición conserva el way, su historial y sus etiquetas; las demás se agregan como ways nuevos, sin etiquetas. Si el edificio de OSM tiene etiquetas y sus estructuras caen en más de un lote, el grupo pasa a Conflictos: las etiquetas podrían corresponder a un lote distinto del que conserva el way.
Los motivos de Conflictos son ocho: enredo N:M, 1:N con etiquetas ambiguas, N:1 con etiquetas repartidas en varios lotes, geometría inválida, building:part ya existente en OSM, superposición sin vínculo, superposición con un vecino que permanece y huella partida por una superposición durante la limpieza. Cada estructura guarda en la base del proceso todos los motivos que le corresponden, pero no se publican como etiqueta ni en los archivos: JOSM oculta fixme por defecto, y esas etiquetas podían llegar a OSM sin que nadie las viera.

Estructuras en Conflictos por motivo (datos de OSM del 27/09/2026)
Motivo	Estructuras
Superposición sin vínculo	15.666
Vecino que permanece	11.808
N:1 con etiquetas en varios lotes	10.573
Enredo N:M	1.342
`building:part` ya en OSM	770
1:N con etiquetas ambiguas	637
Huella partida en la limpieza	538
Geometría inválida	0

Son 36.521 estructuras en Conflictos. Una estructura puede tener varios motivos (4.221 tienen más de uno), por lo que la columna suma más que el total.

Ejemplo de vínculo: la ciudad divide un edificio en tres huellas y OSM lo tiene dibujado como uno solo. Si cada huella tiene más de la mitad de su área dentro de ese edificio de OSM, las tres quedan vinculadas como un grupo N:1 y se clasifican como Reforma, aunque la forma de cada una no coincida exactamente con el dibujo de OSM.

Ejemplo real (SMP 08-060-009 a 011): tres casas vecinas, cada una en su propio lote, están dibujadas en OSM como un solo edificio sin etiquetas propias. Cada estructura tiene entre el 84 % y el 96 % de su área dentro de ese edificio, por lo que las tres quedan vinculadas. La de mayor superposición conserva el way; las otras dos se agregan como ways nuevos.

Ejemplo real de la regla del vecino (SMP 04-015-002D): la estructura está vinculada a un edificio de OSM y sería Reforma, pero además cubre 35 m² de un edificio vecino que no está vinculado a ninguna huella. Ese vecino permanece en OSM, de modo que la Reforma agregaría una superposición nueva; por eso el grupo pasa a Conflictos.

Los edificios de OSM sin ninguna huella debajo (por ejemplo, uno demolido que el dataset ya no registra) quedan fuera del proceso: no se clasifican, no se listan y no se modifican

Fase 5: verificación

Dos controles detienen la ejecución completa si fallan, y en ese caso no se escribe ningún archivo:

Control 1, después de la limpieza geométrica (no necesita datos de OSM): cada cuadra forma una cobertura válida, no hay geometrías nulas ni multiparte, y la cantidad de huellas cierra en cada paso de la migración.
Control 2, después de clasificar y antes de generar archivos: cada estructura está en un solo grupo, ningún Nuevo pisa un edificio de OSM y ninguna estructura queda partida entre dos archivos.

Los demás chequeos (deriva geométrica, distribución de alturas, coherencia espacial del SMP, idempotencia de una segunda ejecución, etc.) generan un reporte, pero no detienen la ejecución.

Fase 6: publicación (detalle técnico)

La copia de referencia de OSM del 5/10/2025 (la línea de base) se usa solo para calibrar umbrales. No se publica nada derivado de ella.
Antes de cada ronda se descarga OSM de nuevo con Overpass (out meta;, en .osm crudo, incluyendo building:part, las relaciones y toda vía que comparta un nodo con un edificio), acotado al polígono de CABA. La línea de base se obtuvo con una búsqueda por nombre e incluyó 2.745 edificios fuera de Argentina.
Nuevo se publica en un archivo por sección (94) y Conflictos en uno por cuadra (4.987). Las huellas sin SMP van en 936 archivos pequeños aparte; falta decidir si se agrupan. El archivo de Nuevo más grande tiene unas 29.000 vías y 124.000 nodos (~18 MB); el mediano, unas 12.000 vías (~8 MB). La cuenta de importación los sube en unos 840 changesets de hasta 10.000 elementos.
Reforma se publica como desafío de MapRoulette, con una tarea por cada conjunto de grupos de Reforma vecinos (los que comparten una posición de nodo, directamente o a través de otros) dentro de una misma cuadra. Con los datos de OSM del 27/09/2026 son 10.628 tareas: 8.153 con un solo grupo y 2.475 con dos o más; la mayor tiene 38 grupos. Cada tarea trae un .osm/.osc que JOSM carga como cambio propuesto; el mapeador lo revisa, lo ajusta si hace falta y lo sube desde su propia cuenta. Por eso no se usa aquí la cuenta de importación, que las Import Guidelines reservan para ediciones que nadie revisa una por una.
Reforma se genera después de subir Nuevo, con OSM descargado de nuevo. Donde un nodo de Reforma cae exactamente en la posición de un nodo existente, se reutiliza ese nodo, así que los edificios de Reforma comparten las paredes con los Nuevos de al lado sin duplicar nodos. Los nodos viejos que quedan sin uso cuando se completan varias tareas vecinas se verifican contra OSM y se eliminan antes de la ronda siguiente.
Cada changeset lleva source=* con el dataset y la fecha del archivo (2021-05-10), que el script de descarga lee del propio archivo y guarda junto a él. No se agrega source a cada objeto, siguiendo la práctica actual de OSM.
Antes de la primera subida deben cumplirse tres condiciones: la cuenta de importación registrada, el procedimiento de reversión documentado (ver Plan de reversión) y los 14 días de espera en el foro transcurridos sin objeciones pendientes.

Fuentes

Sandbox

Contents

EDIT BELOW THIS LINE

Objetivo

Cronograma