Cargar datos en PostGIS con GDAL: staging y validación antes de publicar

Una carga repetible conserva el archivo recibido, registra sus características y publica únicamente después de validar. El esquema de staging permite inspeccionar una importación sin cambiar las tablas que consumen los usuarios. Use una base de laboratorio y una copia pública o sintética; estos comandos crean datos.

Inspeccione la entrada

Registre nombre de capa, número de registros, CRS, tipos de campo, codificación y tamaño. Una columna llamada area no explica su unidad. Un identificador que parece numérico puede necesitar texto para conservar ceros iniciales. Defina estas decisiones antes de cargar.

ogrinfo -ro -so -al input.gpkg
ogr2ogr -f PostgreSQL 'PG:service=gis_lab' input.gpkg points -nln staging.points_import

La conexión gis_lab debe apuntar exclusivamente a la base de pruebas. El esquema staging debe existir y el usuario debe poder crear la nueva tabla. No añada -overwrite para resolver un error de nombre: elija un identificador nuevo y revise la carga anterior.

Compruebe la geometría

Con una columna geom y clave code, estas consultas permiten detectar defectos frecuentes. Si GDAL generó otro nombre de geometría, sustitúyalo tras inspeccionar la tabla.

SELECT count(*) AS rows,
       count(*) FILTER (WHERE geom IS NULL) AS missing_geometry,
       count(*) FILTER (WHERE NOT ST_IsValid(geom)) AS invalid_geometry
FROM staging.points_import;
SELECT ST_SRID(geom), GeometryType(geom), count(*)
FROM staging.points_import GROUP BY 1, 2;
SELECT code, count(*) FROM staging.points_import
GROUP BY code HAVING count(*) > 1;

El resultado esperado depende del contrato: si las claves son únicas, la última consulta debe devolver cero filas. Un número de filas coincidente no basta; compare también valores agregados, fechas y una muestra por clave. Compruebe que una transformación de CRS no se confundió con la asignación de un código.

Publicación controlada

Diseñe la tabla operativa por separado con restricciones y permisos. Inserte o actualice desde staging dentro de una transacción según la clave de negocio, sin cambiar identificadores externos de manera accidental. Valide referencias antes de confirmar. Para cargas grandes, mida bloqueos y duración sobre una copia representativa.

Conserve un informe de filas rechazadas con información suficiente para corregirlas, evitando duplicar datos personales innecesarios. Si falta un campo obligatorio o cambia su tipo, detenga la publicación y solicite aclaración del productor. No convierta silenciosamente errores de fecha en nulos.

Prueba de repetición

Cargue el mismo archivo dos veces en staging independiente. La tabla publicada no debe duplicarse si el diseño es idempotente. Pruebe también una clave duplicada, un archivo vacío y una geometría inválida. El operador debe distinguir una recepción válida sin cambios de una importación incompleta; esa diferencia evita que una automatización borre información por error.

Tratar la carga como un cambio controlado

Define instantánea de origen, esquema de destino y conteo esperado antes de importar. Para practicar, usa los datos sintéticos del laboratorio. No confundas sus conteos publicados con supuestos sobre una fuente operacional. Registra suma de comprobación u otra versión inmutable para confirmar que dos analistas cargaron el mismo archivo.

Utiliza un esquema intermedio sin servicios públicos conectados. La cuenta de carga necesita crear o poblar los objetos previstos; no requiere ser propietaria de otros esquemas operacionales. Maneja conexiones mediante servicios PostgreSQL y contraseñas fuera del historial de terminal.

Inspeccionar antes de cargar

Consulta versión y esquema antes de escoger opciones:

ogrinfo --version
ogrinfo -ro -so -al incoming.gpkg

Revisa tipos, identificadores, dimensiones, CRS y nombres de capas. -a_srs asigna una descripción; -t_srs transforma coordenadas. Asignar para “corregir” coordenadas que necesitan transformación cambia su interpretación sin calcular valores correctos. Forzar todas las geometrías a un tipo también puede ocultar partes o dimensiones necesarias.

Explicita cada conversión. Promover polígonos conocidos a un destino multipart puede ser razonable, pero comprueba tipo y dimensiones resultantes. No agregues -skipfailures a la primera migración para obtener salida exitosa. Los rechazos forman parte del resultado y requieren decisión.

Conciliar la tabla intermedia

Estas consultas suponen staging.assets, clave de negocio asset_id y columna geom; adapta nombres al esquema inspeccionado.

SELECT count(*) AS rows,
       count(DISTINCT asset_id) AS distinct_ids,
       count(*) FILTER (WHERE asset_id IS NULL) AS missing_ids,
       count(*) FILTER (WHERE geom IS NULL) AS missing_geometry
FROM staging.assets;

SELECT ST_SRID(geom), GeometryType(geom), count(*)
FROM staging.assets
GROUP BY ST_SRID(geom), GeometryType(geom);

SELECT asset_id, ST_IsValidReason(geom)
FROM staging.assets
WHERE geom IS NOT NULL AND NOT ST_IsValid(geom);

Coincidir en conteos es necesario pero insuficiente: duplicados pueden compensar faltantes. Compara conjuntos de claves y revisa ceros iniciales, tildes, nulos, fechas cerca de medianoche y precisión máxima. Si hay zonas horarias, define cómo conservarlas.

Publicar después de comprobar al consumidor

Carga la capa intermedia en QGIS con clave única y CRS esperados. Ejecuta una consulta representativa del servicio si se publicará. Valida fecha, etiqueta de categoría y entidad multipart desde la aplicación consumidora. Una fila correcta puede ser malinterpretada por el cliente.

Diseña el reemplazo considerando dependencias. Eliminar y recrear una tabla operacional puede romper vistas, permisos e identificadores. Usa una transacción revisada o publicación versionada que preserve el contrato. Ensáyala con vistas dependientes y un consumidor de lectura en un entorno desechable.

Hacer predecibles los reintentos

Define si el proceso crea un lote, sustituye uno acotado o actualiza por clave estable. Agregar filas sin más no es seguro ante una interrupción que deje dudas sobre lo confirmado. Concilia el identificador del lote antes de reintentar y rechaza duplicados mediante restricciones. Conserva entrada, parámetros, conteos y motivos de rechazo juntos; permiten investigar sin registrar secretos.

Referencia: opciones de ogr2ogr.

Fuentes y documentación

• PostGIS reference
• PostgreSQL documentation
• ogr2ogr reference

Siguiente paso

Continúe en la colección Open GIS. Para comparar un proyecto concreto, use la calculadora de costo total y solicite una evaluación.

Lecturas relacionadas

• PostGIS para catastro: modelo mínimo, geometría y controles de calidad
• Índices espaciales en PostGIS: mida antes de optimizar