Ir al contenido
ARE U LIVING IN THE REAL WORLD?
Escrito originalmente en Terraes5 min de lecturaEn español

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

Tutorial paso a paso para implementar la base de datos catastral LADM-COL en PostgreSQL + PostGIS desde cero. Esquema, herramientas (ili2pg, pg-iliexport), validación topológica y exportación XTF al SINIC.

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_prediola_baunit.t_idGenerar nuevo UUID
numero_catastralla_baunit.nombreMantener formato
areala_baunit.area_totalValidar coherencia con geometría
propietario_idla_party.t_idCrear party si no existe
polígonola_spatialunit.geometriaReproyectar 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

Dónde salió primero

Publicado primero en Terraes terraes.com/catastro/blog/postgis-ladm-col-30-dias · 2026-05-20

Siempre es hoy.

Sigue leyendo

Founder operations

En inglés

The illusion of everyone winning

I know what success can hide. Yet seeing other builders win still makes me feel behind, even after years of learning how to build.

Boletín

La suscripción por correo no está disponible. Puedes seguir las nuevas publicaciones por RSS.

Seguir por RSS