Saltar al contenido
TUTORIAL TÉCNICO

PostGIS para catastro · construir esquema LADM-COL en 30 días

2026-05-20 · 12 min · ← Volver al blog

PostgreSQL + PostGIS es el stack abierto más usado para catastro institucional en Colombia. Es gratuito, robusto, soporta el modelo LADM-COL sin licencias adicionales, y se integra naturalmente con QGIS, ArcGIS y herramientas oficiales del IGAC.

Este post es un tutorial pragmático para implementar el esquema LADM-COL en PostGIS en 4 semanas (1 mes), desde instalación hasta exportación XTF lista para SINIC.

Por qué PostGIS para catastro

  • Open source · sin licencias: cero costo de adquisición. Solo infra y operación.
  • Soporte nativo de geometría: tipos geometry y geography con índices espaciales rápidos
  • Compatibilidad LADM-COL: el modelo INTERLIS se traduce naturalmente a esquema PostgreSQL
  • Herramientas oficiales IGAC: el ecosistema INTERLIS (ili2pg, pg-iliexport) soporta PostGIS de forma nativa
  • Escalabilidad probada: bases con millones de predios funcionan sin problema
  • Backup + replicación: PostgreSQL tiene 30 años de madurez en operación crítica

Lo que necesita antes de empezar

  • Servidor Linux (Ubuntu 22.04+ recomendado) con 16–32 GB RAM
  • PostgreSQL 14+ con extensión PostGIS 3.3+
  • Java 11+ (para herramientas INTERLIS)
  • QGIS 3.30+ con plugin Catastro Colombia (opcional, recomendado)
  • Acceso a internet para descargar modelos LADM-COL desde el repositorio IGAC

Semana 1 · Instalación y modelo base

Día 1 · Instalar PostgreSQL + PostGIS

# Ubuntu 22.04
sudo apt update
sudo apt install postgresql-15 postgresql-15-postgis-3 postgresql-15-postgis-3-scripts

# Crear base catastral
sudo -u postgres psql -c "CREATE DATABASE catastro_municipio;"
sudo -u postgres psql -c "CREATE USER catastrero WITH PASSWORD 'cambieme';"
sudo -u postgres psql -d catastro_municipio -c "CREATE EXTENSION postgis;"
sudo -u postgres psql -d catastro_municipio -c "GRANT ALL PRIVILEGES ON DATABASE catastro_municipio TO catastrero;"

Día 2 · Descargar modelo LADM-COL

El IGAC publica los modelos INTERLIS de LADM-COL. Descargue la versión vigente del SINIC desde el normograma IGAC. Los archivos .ili describen el esquema.

mkdir -p ~/ladm-col
cd ~/ladm-col
# Descarga del repositorio oficial IGAC
wget https://repositorio.igac.gov.co/ladm-col/v1.0/LADM_COL_Catastro.ili

Día 3-5 · Generar esquema en PostGIS con ili2pg

ili2pg es la herramienta oficial INTERLIS para traducir .ili a esquema PostgreSQL:

wget https://downloads.interlis.ch/ili2pg/ili2pg-5.0.0.zip
unzip ili2pg-5.0.0.zip
cd ili2pg-5.0.0

# Crear esquema
java -jar ili2pg.jar --schemaimport \
  --dbhost localhost --dbdatabase catastro_municipio \
  --dbusr catastrero --dbpwd cambieme \
  --models LADM_COL_Catastro \
  --modeldir ~/ladm-col \
  --defaultSrsCode 9377 \
  --noSmartMapping

Después de esto, su base catastro_municipio tiene todas las tablas LADM-COL:

  • la_baunit (unidades básicas administrativas = predios)
  • la_party (personas naturales y jurídicas)
  • la_spatialunit (geometrías)
  • la_rrr (derechos, restricciones, responsabilidades)
  • la_valuation (avalúos)
  • la_administrativesource (documentos fuente)
  • 60+ tablas adicionales con relaciones definidas

Semana 2 · Carga de datos existentes

Día 6-7 · Auditar la fuente actual

Antes de cargar, identifique qué tiene:

  • ¿Catastro existente en SICtax, Oracle, SQL Server, archivos planos?
  • ¿Geometrías en Shapefile, GeoPackage, geodatabase Esri?
  • ¿Avalúos históricos disponibles?
  • ¿Histórico de propietarios?
  • ¿Soportes documentales (escrituras, planos)?

Día 8-10 · Mapeo de campos

Cree un documento (Excel funciona) con dos columnas: campo origen → campo LADM-COL destino. Para predios:

| Campo origen (SICtax) | Campo destino (LADM-COL) | Notas | |---|---|---| | id_predio | la_baunit.t_id | Generar nuevo UUID | | numero_catastral | la_baunit.nombre | Mantener formato | | area | la_baunit.area_total | Validar coherencia con geometría | | propietario_id | la_party.t_id | Crear party si no existe | | polígono | la_spatialunit.geometria | Reproyectar a EPSG:9377 |

Día 11-14 · Carga estructurada con bitácora

-- Tabla de auditoría
CREATE TABLE migracion_log (
  id SERIAL PRIMARY KEY,
  fecha TIMESTAMP DEFAULT NOW(),
  tabla_destino TEXT,
  id_origen TEXT,
  id_destino TEXT,
  estado TEXT,  -- importado, error, rechazado
  detalle TEXT
);

-- Función de migración con bitácora
CREATE OR REPLACE FUNCTION migrar_predio(
  p_id_origen TEXT,
  p_numero_catastral TEXT,
  p_area NUMERIC,
  p_geometria GEOMETRY
) RETURNS UUID AS $$
DECLARE
  v_id_baunit UUID;
BEGIN
  -- Validar geometría
  IF NOT ST_IsValid(p_geometria) THEN
    INSERT INTO migracion_log (tabla_destino, id_origen, estado, detalle)
    VALUES ('la_baunit', p_id_origen, 'rechazado', 'Geometría inválida');
    RETURN NULL;
  END IF;

  -- Insertar
  INSERT INTO la_baunit (t_id, nombre, area_total)
  VALUES (gen_random_uuid(), p_numero_catastral, p_area)
  RETURNING t_id INTO v_id_baunit;

  -- Geometría
  INSERT INTO la_spatialunit (t_id, geometria, baunit_t_id)
  VALUES (gen_random_uuid(), ST_Transform(p_geometria, 9377), v_id_baunit);

  -- Log
  INSERT INTO migracion_log (tabla_destino, id_origen, id_destino, estado)
  VALUES ('la_baunit', p_id_origen, v_id_baunit::TEXT, 'importado');

  RETURN v_id_baunit;
END;
$$ LANGUAGE plpgsql;

Cada registro queda con bitácora — si algo se carga mal, se detecta y corrige.

Semana 3 · Validación topológica

Día 15-17 · Reglas LADM-COL básicas

Implemente validaciones automáticas:

-- 1. Predios sin geometría
SELECT b.t_id FROM la_baunit b
LEFT JOIN la_spatialunit s ON s.baunit_t_id = b.t_id
WHERE s.t_id IS NULL;

-- 2. Geometrías inválidas
SELECT t_id, ST_IsValidReason(geometria)
FROM la_spatialunit
WHERE NOT ST_IsValid(geometria);

-- 3. Solapamientos entre predios
SELECT a.t_id AS predio_a, b.t_id AS predio_b,
       ST_Area(ST_Intersection(a.geometria, b.geometria)) AS area_solape
FROM la_spatialunit a, la_spatialunit b
WHERE a.t_id < b.t_id
  AND ST_Intersects(a.geometria, b.geometria)
  AND ST_Area(ST_Intersection(a.geometria, b.geometria)) > 0.01;

-- 4. Predios duplicados (mismo número catastral)
SELECT nombre, COUNT(*)
FROM la_baunit
GROUP BY nombre
HAVING COUNT(*) > 1;

Día 18-21 · Reglas avanzadas

  • Cierre topológico verificado
  • Vecindad consistente con manzanas / vías
  • Área catastral coherente con área geométrica
  • Coordenadas dentro del polígono Colombia
  • Tolerancias geométricas según R.509 IGAC

Cada regla violada se reporta como excepción para revisión manual.

Semana 4 · Exportación XTF al SINIC

Día 22-25 · Configurar pg-iliexport

java -jar ili2pg.jar --export \
  --dbhost localhost --dbdatabase catastro_municipio \
  --dbusr catastrero --dbpwd cambieme \
  --models LADM_COL_Catastro \
  --modeldir ~/ladm-col \
  --xtf-out ~/exports/catastro_municipio_$(date +%Y%m%d).xtf

El archivo .xtf resultante es lo que se entrega al SINIC.

Día 26-28 · Validar XTF contra reglas IGAC

# Validador INTERLIS oficial
java -jar ilivalidator.jar --modeldir ~/ladm-col \
  ~/exports/catastro_municipio_*.xtf

Cualquier error topológico o estructural se reporta. Corregir en PostGIS y volver a exportar.

Día 29-30 · Documentar el proceso

Antes de "terminar", deje todo documentado:

  • Diagrama de arquitectura
  • Mapeo de campos (origen → LADM-COL)
  • Script de migración completo
  • Runbook de exportación XTF
  • Checklist de validación pre-radicación
  • Procedimiento de actualización del modelo (cuando IGAC publique nueva versión)

Sin documentación, el sistema queda en cabeza de una persona — y eso es riesgo operativo.

Operación continua

Una vez en producción, el flujo diario es:

  1. Mutaciones: trámites de conservación se ingresan vía aplicación (web, móvil, escritorio)
  2. Validación: cada cambio pasa por reglas topológicas y de coherencia
  3. Bitácora: cada cambio queda con autor, fecha, regla aplicada
  4. Sincronización con sistema fiscal: API REST o vista materializada
  5. Reportes: dashboards SQL o BI sobre la base PostGIS
  6. Backup: diario con retención 30 días
  7. Entrega XTF al SINIC: mensual o según convenio con IGAC

Lo que PostGIS no resuelve

PostGIS es base de datos, no aplicación catastral completa. Faltan:

  • Interfaz de usuario para operadores no-técnicos
  • App de campo offline-first
  • Portal ciudadano (Mi Predio)
  • Flujos de mutación con plantilla documental
  • Componente social
  • Integración con sistemas fiscales
  • Reportes operativos institucionales

Estos los aporta una plataforma como Terraes encima de PostGIS, o se construyen a medida (típicamente 12+ meses de desarrollo dedicado).

En resumen

PostGIS + LADM-COL es la base abierta del catastro multipropósito en Colombia. En 30 días un equipo técnico puede tener el esquema instalado, los datos migrados y la exportación XTF funcionando.

Construir la operación catastral completa sobre eso (interfaz, app de campo, portal ciudadano, mutaciones, social) toma más tiempo — pero la base de datos no es donde más se complica.

¿Su equipo técnico quiere implementar PostGIS + LADM-COL como base operativa? Tenemos acompañamiento técnico para gobiernos que quieren la base de datos abierta + Terraes como capa de aplicación. Solicite asesoría.

Referencias