Cuadras (place="city_blocks")

[GAZ082 (Gabriel)]

Hola Comunidad,

Quería hacer una visualización de cosas por cuadras en CABA y de inmediato pense en tomar los datos GeoJson de OSM de las mismas (con overpass), y para mi sorpresa al intentar filtrar por place=“city_block” encontré muy poquitas cuadras. Bueno dije, acaba de nacer un nuevo sub-proyecto, taggear las cuadras de CABA como tales!

El tema es que quiero hacerlo via un script Python. Tengo algunas consultas:

1. Me base en los shapes ya definidos con tags “land_usage”
   Hice unas pruebitas en mi territorio (Liniers, pueden verlo)
   Problema: hay cuadras donde fisicamente son retail y residenciales, con lo cual en una cuadra hay dos shapes.
   Solución: ignorarlos a mano.
   Pregunta: esta bien usar los shapes que ya existen en OSM que se usan para el land_usage?
2. Esta bien crear otro shape que solape en la cuadra, en el caso de que sea una cuadra de uso mixto?
3. Me olvidaba, hay una gran zona de uso en Liniers que abarca muchas cuadras. Como quiero hacerlo todo programáticamente, de donde bajan las coordenadas de las cuadras del GCBA? (por lo menos quiero probar, si es complicado, lo hago a mano)

Consulto mas que nada para no romper con buenas prácticas y costumbres propias de los editores.

Gracias!

[GAZ082 (Gabriel)]

Bueno, yo ya estoy trabajando en la zona de Liniers. Veo que en la ciudad hay landuse que son supercuardas (un grupo de cuadras en vez de una). Voy a ver si puedo reconfigurarlos con los datos del GCBA.

[ignaciolep]

Hola @GAZ082, ¡bienvenido a la comunidad!

Paso a responder tus consultas, tratando de darte un poco de contexto sobre cómo se vienen trabajando estos temas.

Uso de los polígonos de landuse

Históricamente,el mapeo de landuse comenzó con grandes áreas que agrupaban varias manzanas. Hace unos años, un editor (@Hernan) empezó un trabajo detallado para refinar esto, creando “islas” que excluyen la red vial, es decir, dibujando el polígono de landuse sobre el contorno de la manzana incluyendo su vereda, como bien se describe en la wiki de Land use. Esto generó en su momento algunas discusiones con otros editores (como @AgusQui), pero es la práctica que se fue adoptando en otros lugares.

Sobre el uso mixto y zonas que abarcan varias cuadras

Respecto a tu duda sobre cuadras con uso mixto (residencial y comercial), la decisión en CABA se ha ido tomando “a ojo”, etiquetando el landuse según lo que predomina en la zona, ya que no existen zonas de uso exclusivamente comercial por normativa.

En cuanto a solapar áreas, la práctica general en OSM es no hacerlo. Si ya existe un polígono para un área, lo correcto es agregar o modificar sus etiquetas, no crear un nuevo polígono encima para el mismo elemento. (Ver: ES:Un objeto, un elemento OSM - OpenStreetMap Wiki)

Diferencia: landuse vs. place=city_block

Si tu objetivo es mapear las manzanas (place=city_block), estas no deberían incluir la vereda . La wiki para place=city_block aclara que deberían mapearse sin incluir la calle y la vereda (they should not include pavements or sidewalks), es decir que llega hasta la línea municipal.

De hecho, en el portal BA Data el dataset de manzanas y el de veredas están separados. Esto refuerza la idea de que son entidades distintas.

Una solución prolija sería:

1. El contorno de la vereda para el landuse.
2. El contorno de la manzana (la línea municipal) para el place=city_block.

Si además querés aprovechar el identificador catastral de Sección-Manzana (SM) que provee el GCBA, podés etiquetar el place=city_block con ref:cadastre. Por ejemplo: ref:cadastre=003-001.

Importaciones y buenas prácticas

Dado que estás pensando en hacerlo de forma programática utilizando datos oficiales, es fundamental seguir las Directrices de Importación . Este es un proceso que requiere consenso de la comunidad para asegurar la calidad de los datos.

Justamente es algo que también estamos tratando en otro tema relacionado a la importación del dataset de edificación de CABA.

Próximos pasos

Para analizar mejor la propuesta, sería genial si pudieras compartir por acá un archivo GeoJSON de muestra con algunos polígonos como los procesarías. Así podemos revisar si la geometría y las etiquetas son correctas.

Finalmente, te invito a sumarte al grupo de Telegram de la comunidad Argentina (osm_ar).

Saludos y felicitaciones por la iniciativa.

[GAZ082 (Gabriel)]

Gracias Ignacio!

1. El contorno de la vereda para el landuse.
2. El contorno de la manzana (la línea municipal) para el place=city_block.

No se estarían solapando areas?

Estoy corto de espacio en mi Sony XZ1 Compact de hace 8 años
Cuando cambie de celu veré el tema Telegram.

Actualmente tengo automatizado tomar los waypoints tagueados como landuse y asignar el tag de city_block, los casos border los ignoro a mano, usando Overpass para visualizarlos (ej, cuadras con dos landuse).Lo que vos sugeris es remapear las cuadras tomando datos del GCBA. Mañana hago una prueba y mando algo.

Abrazo!

[ignaciolep]

De nada! Es una buena pregunta…

Eso no se considera un solapamiento problemático porque son dos elementos que describen cosas distintas, aunque compartan un espacio geográfico.

• La etiqueta landuse describe el uso del suelo de un área (que incluye la vereda, etc.).

• La etiqueta place=city_block define un objeto geográfico discreto y administrativo: la manzana en sí misma.

Un ejemplo análogo sería mapear un edificio (building=yes) dentro de un parque (leisure=park). Los polígonos se superponen, pero es la forma correcta de mapearlo, porque el edificio está dentro del parque. En este caso, la city_block está dentro de un área con un determinado landuse. El solapamiento que sí se debe evitar es, por ejemplo, tener dos áreas de landuse=residential una encima de la otra.

Para completar la idea, en el supuesto que la comunidad decidiera que el landuse no debiera incluir la vereda, sino llegar solo hasta la línea municipal. En ese caso, el polígono del landuse y el del place=city_block serían geométricamente idénticos. Acá sí aplicaría el principio de no duplicar elementos: no tendría sentido dibujar dos polígonos iguales uno encima del otro. La forma correcta de mapearlo sería crear un único polígono (el contorno de la manzana) y asignarle ambas etiquetas , por ejemplo:

landuse=residential
place=city_block

Te recomendé crear polígonos separados porque según las definiciones de la wiki, sus geometrías no son idénticas.

Por cierto, también existen las relaciones multipolígono, con las que se pueden hacer recortes de áreas, pero es preferible evitar el uso de relaciones a menos que sea realmente necesario. Son estructuras de datos mucho más complejas de crear y mantener. Por eso, la solución de tener dos polígonos simples superpuestos es preferible: es más fácil de mapear y más robusto a largo plazo.

Yo creo que, para lograr la precisión que requiere place=city_block (la línea municipal), lo ideal sería tomar la geometría del dataset oficial, revisar si es necesario simplificarla para que no tenga nodos innecesarios y agregarle las etiquetas correspondientes. Luego se podría preparar dos versiones, una para incorporar donde no haya conflictos con los datos existentes de OSM, y otra para revisar manualmente y hacer un conflation para ajustar la geometría y etiquetas existentes sin perder la historia. (Ah, y por el momento te recomiendo no modificar las manzanas de la villas 1-11-14, 31, Zavaleta…)

No hay drama con lo de Telegram, cuando puedas, serás bienvenido al grupo. Mientras seguimos por acá.

[GAZ082 (Gabriel)]

Bueno, los datos del GCBA marcan las cuadras en el medio de las calles:
Ejemplo con Comuna 9:

https://gaz082.github.io/c_9.html

Datos que use: https://infra.datos.gob.ar/georef/cuadras.geojson (1.1gb).

Mas que cuadras son calles estos, mirando un poco los campos disponibles y las coordenadas. Se podría hacer un algoritmo para que genere las cuadras, pero quizas Nacho vos tenés otro dataset con cuadras de verdad.

[GAZ082 (Gabriel)]

• un padding de 5 metros:

https://gaz082.github.io/ (link pertinente, voy a ir actualizandolo).

Creo que esto como base sirve. Ahora tengo que ver la manera de traducir esto a OSM.

[ignaciolep]

@GAZ082

Datos que use: https://infra.datos.gob.ar/georef/cuadras.geojson (1.1gb).

Todavía no revisé la muestra, pero quería comentarte que no conozco el origen de ese dataset (cuadras.geojson). Parecería salir del portal de datos nacional, ¿Tenés el link a la página donde describa el contenido, fecha de actualización y, sobre todo, la licencia? (Hay que asegurarse que la licencia sea compatible con OSM, o de tener un permiso explícito como el que conseguimos del GCBA)

@GAZ082

Mas que cuadras son calles

Como el propio nombre lo indica, una “cuadra” suele representar el eje de la calle o el segmento lineal entre dos esquinas. Es un concepto lineal, no poligonal. No es la “manzana”, que es el polígono de forma cuadrada o rectangular que se busca mapear con city_block.

@GAZ082

quizas Nacho vos tenés otro dataset

Los datasets que te recomiendo revisar, y que son los que mencioné antes, son los específicos del portal de datos abiertos del GCBA . Para lo que necesitas, deberías buscar estos dos:

1. Manzanas: Este es el dataset ideal. Te va a dar directamente los polígonos con la geometría de la línea municipal, que es exactamente lo que necesitás para etiquetar como place=city_block.

2. Veredas: Te lo menciono para que lo tengas de referencia, vinculando con nuestra charla anterior. Si en algún momento se quisiera mapear el landuse que debería mapearse con la geometría que incluye la vereda, se podría usar este dataset, pero requeriría un procesamiento para quedarse únicamente con el contorno exterior.

Mi sugerencia es que te enfoques directamente en el dataset de Manzanas del GCBA.

[GAZ082 (Gabriel)]

Gracias nacho,
El que me pasaste es una BD de sección-manzana, y buscando esa BD para referencarla encontre esto:

Buenos Aires Data

Vamos a ver que onda.

[GAZ082 (Gabriel)]

https://gaz082.github.io/cuadras_directo_gcba.html

es casi exactamente lo que queremos, a excepción de que cada cuadra esta dividida en segmentos. Interesante.

[GAZ082 (Gabriel)]

https://gaz082.github.io/cuadras_directo_gcba.html

Listo. Bastante bien, hay algunas zonas que quizas se pueden arreglar a mano una vez subido a OSM.

Las cuadras no incluyen veredas:

En algun momento voy a probar en el servidor de test. Ahora mi pregunta es, esto deberia sobreescribir lo hecho por @Hernan, verdad?

[ignaciolep]

Gracias por compartir el avance del proyecto y el enlace al visualizador. Así podemos entre todos analizar la propuesta de manera colaborativa.

Te comento por acá lo mismo que en Telegram, pero con más detalle.

Basado en lo que se ve en el visualizador, hay algunos puntos a trabajar:

1. Corregir la geometría: Como primer punto crítico, muchos polígonos se solapan. Habría que ajustarlos para que los límites de las manzanas respeten el trazado de las calles, asegurando que no haya superposiciones.
   

   

2. Omitir datos existentes y relevamientos locales: Se debería identificar y omitir las manzanas que ya existen en OSM como place=city_block. Y, como ya te comenté, hay que excluir por completo las áreas de las villas 1-11-14, 31, Zavaleta, etc. El mapeo en estas zonas se hizo con relevamientos en el terreno (ground truth), cuyo detalle y precisión son superiores a los del catastro. Es muy importante preservar ese trabajo.

3. Alcance de place=city_block: Viendo que el dataset incluye polígonos enormes como el de la Reserva Ecológica, propongo que nos limitemos a la definición clásica de manzana urbana: un espacio delimitado por calles en todos sus lados.

Sobre el trabajo de Hernan

@GAZ082

esto deberia sobreescribir lo hecho por @Hernan, verdad?

La respuesta más probable es: no, no debería sobreescribirlo, sino complementarlo.

Para poder responder con más seguridad, te pediría si podés compartir un enlace a un ejemplo concreto de la zona que estás analizando.

Según recuerdo, el gran trabajo que comenzó @Hernan fue el mapeo detallado del landuse (uso del suelo) y al mismo tiempo ajustaba la calles y demás elementos. Según la definición de la wiki, el landuse debería abarcar el área hasta el cordón de la vereda. Por otro lado, el place=city_block que vos estás proponiendo mapear representa la manzana catastral, cuyo límite es la línea municipal .

Si esto es así, estamos hablando de dos objetos distintos con geometrías diferentes:

• landuse=* (polígono más grande, incluye vereda).
• place=city_block (polígono interior, solo la manzana).

En este escenario, no hay sobreescritura. Se trata de añadir un nuevo elemento (city_block) que convive con otro existente (landuse), tal como te comenté antes. La revisión manual es fundamental para casos donde un landuse pudo haber sido mapeado erróneamente con la geometría de una manzana. En esos casos, se podría fusionar (conflation) la geometría y reemplazar etiquetas.

Próximos Pasos

El haber compartido la muestra es un gran avance y el paso correcto según las Directrices de Importación .

Lo ideal ahora sería trabajar en una nueva muestra que incorpore estos puntos:

• Geometrías corregidas.
• Omisión de las manzanas ya existentes (especialmente los de las villas que fueron mapeadas en detalle), tomando en cuenta los place=city_block y también las manzanas que podrían estar etiquetadas con landuse=*.
• Agregar el etiquetado con place=city_block y, opcionalmente, ref:cadastre=* para el dato de SM.