Chequeo mínimo para que tus modelos no aprendan "basura".
El mito no es la falta de datos: es la falta de juicio
¿De verdad el problema en LATAM es "conseguir datos"? No. El problema es usar datos correctos de forma incorrecta.
En Colombia tenemos cartografía oficial, datos geoestadística con continuidad temporal, series ambientales, satélite y portales con buenos servicios. Aun así, proyectos fallan. No por ausencia de información, sino por una mezcla explosiva: unidad espacial mal elegida, escalas incompatibles, calidad no validada y linaje desconocido.
El marco de los datos
En estándares de información geográfica, la calidad se describe para responder una pregunta simple: ¿este dato sirve para este propósito? e-education.psu.edu: Fitness for Use
ISO 19157 organiza cómo reportar calidad (completitud, consistencia lógica, exactitud posicional/temática, temporalidad, etc.) y cómo documentar evaluaciones. ISO 19157:2013 — Data quality
Y ISO 19115 empuja lo que casi nadie mira hasta que explota: metadatos y linaje (qué, quién, cómo, cuándo se generó). ISO 19115 — Metadata
NO basta con "tener capas". Hay que poder responder: qué significan, qué tan precisas son y de dónde salieron.
La regla práctica: 4 preguntas antes de usar cualquier capa
Marco de Evaluación de Datos Geoespaciales
1. Propósito: ¿Por qué existe este dato?
Legal, estadística, ambiental, monitoreo. Define el contexto del dato.
2. Escala/unidad: ¿en qué unidad tiene sentido?
Predio, manzana, vereda, municipio. Si agregas mal, caes en MAUP (Modifiable Areal Unit Problem): los resultados cambian según la unidad y zonificación. ESRI: Understanding the MAUP
3. Calidad: ¿qué sabemos de su completitud, consistencia, exactitud y vigencia?
Según ISO 19157: completitud, consistencia lógica, exactitud posicional, exactitud temática, temporalidad. ISO 19157 — Data quality
4. Linaje: ¿cómo se produjo y con qué supuestos?
Según ISO 19115/lineage: proceso, origen, transformaciones aplicadas. ISO 19115 — Metadata
Si no puedes responder una de esas cuatro, el cruce de capas es fe… no análisis.
Micro-caso Colombia: valoración rural sin criterio
Caso realista: quieres un modelo de valoración masiva rural. Tomas geometría predial (catastro), calculas índices con Sentinel-2, sumas clima histórico y entrenas.
Suena perfecto. Hasta que miras predios "carísimos" en zonas donde no hay ni vía, o "baratísimos" pegados a infraestructura.
¿Dónde suele estar el error?
Unidad y propósito mezclados. El predio es marco legal/administrativo; Sentinel-2 es observación física; clima es contexto temporal. No son "features equivalentes".
Linaje incierto. En catastro, el rezago de linderos no es raro. La geometría puede existir para fines administrativos y aún así no estar actualizada a nivel de borde.
Servicio ≠ dato. En Colombia, muchas capas vectoriales se consumen por WFS, pero ráster y modelos suelen estar por ImageServer/REST; si tu pipeline asume "OGC puro", pierdes control justo donde necesitas filtrar nubes, seleccionar bandas o construir mosaicos.
¿Cuál seria el flujo de datos?
1. Define la unidad de modelado
A veces no es el predio: puede ser una malla estable. En tu propio documento, la manzana censal aparece como unidad atómica para inferencia local y Divipola como estándar para normalizar territorio.
2. Usa IDEAM vía datos.gov.co
Cuando la pregunta es dinámica (riesgo, series), porque habilita consumo por API y reduce "descargas gigantes" sin control de actualización. datos.gov.co — Portal de Datos Abiertos Colombia
3. Para "normalidad regional" (Amazonía, biomas), apóyate en MapBiomas
Valor por consistencia temporal y temática (1985–2023 en varios productos) más que por detalle jurídico. MapBiomas — Mapeo anual de cobertura y uso del suelo
Eso no "reemplaza lo oficial". Lo vuelve auditable.
Interoperabilidad moderna: menos scraping, más estándares
Si quieres que tu flujo sea reproducible, el estado del arte hoy está en dos líneas:
Para vectores: OGC API – Features
WFS funciona, pero OGC ya empuja OGC API – Features como vía moderna (JSON/HTTP, más amigable para devs). OGC API - Features
Para satélite/catálogos: STAC
STAC (SpatioTemporal Asset Catalog) estandariza cómo describir y buscar assets espaciotemporales. Si consumes Planetary Computer o catálogos similares, STAC te evita "código pegado con babas". STAC Specification
Y esto conecta con lo que ya tienes: usar pystac-client y flujos STAC para escenas y series es un camino limpio para evitar descargar terabytes sin necesidad.
import pystac_client
import planetary_computer
catalog = pystac_client.Client.open(
"https://planetarycomputer.microsoft.com/api/stac/v1",
modifier=planetary_computer.sign_inplace,
)
search = catalog.search(
collections=["sentinel-2-l2a"],
bbox=[-74, -12, -73, -11],
datetime="2025-01-01/2025-12-31",
query={"eo:cloud_cover": {"lt": 20}}
)
items = list(search.items())
print(f"Encontradas {len(items)} escenas")
Y entonces...
Idea-clave: en GeoAI LATAM, la calidad no es una propiedad del dato; es una relación con tu decisión. e-education.psu.edu: Fitness for Use
Cuéntame qué capa te ha dado más problemas (catastro, nubes, escalas, servicios) y comparte esto con alguien de tu equipo que usa datos a diario.