LADM-COL y catastro multipropósito para quien contrata

Cuando una entidad redacta el pliego de un sistema de catastro, suele escribir una línea: «el software deberá cumplir el estándar LADM-COL». Esa línea es correcta y, sola, casi inútil. Cualquier proveedor puede responder «sí cumple» sin que nadie pueda comprobarlo. Este artículo explica el estándar en lenguaje de contratante y le da las herramientas para que esa línea se convierta en una exigencia verificable.

¿Qué es LADM y qué es LADM-COL?

LADM (Land Administration Domain Model) es la norma ISO 19152. Describe, de forma neutral, cómo se representa la relación entre las personas, la tierra y los derechos que las unen. No dice cómo programar, dice qué conceptos existen y cómo se conectan.

LADM-COL es el perfil colombiano de esa norma. Toma el modelo internacional y lo ajusta a la realidad del país: predios rurales y urbanos, informalidad en la tenencia, fuentes documentales propias y la relación entre el catastro y el registro de la propiedad. El modelo está escrito en INTERLIS, un lenguaje que permite definirlo de manera que una máquina pueda validar los datos contra él. El modelo de aplicación vigente lo publica la autoridad catastral nacional; antes de contratar, confirme con ella la versión que debe usarse.

Para el catastro multipropósito, que reúne en un solo expediente la información física, jurídica y económica del predio, este modelo es el lenguaje común entre los gestores catastrales y la autoridad catastral nacional.

¿Cuáles son las clases principales del modelo?

No necesita memorizar el modelo completo. Basta con entender seis ideas y cómo se relacionan.

Concepto	Clase en LADM	Qué representa en palabras simples
Interesado	LA_Party	La persona natural o jurídica que aparece en el expediente: propietario, poseedor, ocupante, entidad.
Derecho, restricción, responsabilidad	LA_Right, LA_Restriction, LA_Responsibility	Lo que el interesado puede, no puede o debe hacer sobre el predio: dominio, servidumbre, hipoteca, deber de conservación.
Unidad administrativa básica	LA_BAUnit	La unidad sobre la cual se ejercen los derechos. En Colombia, el predio.
Terreno	LA_SpatialUnit	La porción de superficie con su geometría y sus linderos.
Construcción y unidad de construcción	Especializaciones colombianas	Lo edificado sobre el terreno y sus partes (apartamentos, locales, anexos).
Fuente administrativa y fuente espacial	LA_AdministrativeSource, LA_SpatialSource	El soporte que prueba el dato: escritura, sentencia, resolución, plano, levantamiento.

Y así se conectan, en texto:

Interesado ──(tiene)──> Derecho / Restricción / Responsabilidad ──(recae sobre)──> Predio
                                                                                      │
Fuente administrativa ──(soporta)──> Derecho                          Terreno <───────┤
Fuente espacial       ──(soporta)──> Terreno                          Construcción <──┘
                                                                         └─ Unidad de construcción

La idea de fondo es que el predio no es un polígono. Es un conjunto de relaciones: alguien tiene un derecho sobre algo, y existe un documento que lo respalda. Un software que guarda «predio, propietario y mapa» en tres tablas sueltas no modela eso.

¿Por qué debe exigirlo un pliego?

Hay cuatro razones prácticas, todas de costo.

1. Intercambio sin reprocesos. La información catastral de su entidad debe poder entregarse a la autoridad catastral nacional y recibirse de ella. Sin el modelo común, cada intercambio es un proyecto de conversión.
2. Cambio de proveedor. Si sus datos están en el modelo estándar, el siguiente contratista no parte de cero.
3. Calidad medible. El modelo trae reglas (dominios, cardinalidades, restricciones) que permiten decir con precisión qué registros están bien y cuáles no.
4. Trazabilidad jurídica. Cada derecho apunta a su fuente. En una auditoría o un conflicto, el dato se puede rastrear hasta el documento.

Para ver cómo lo abordamos en un proyecto, consulte nuestra página de catastro multipropósito.

¿Cómo se verifica que un software cumple de verdad?

Se verifica con archivos, no con presentaciones. El procedimiento es repetible y lo puede ejecutar el equipo de la entidad o un tercero.

1. Pida al proveedor un archivo XTF de muestra generado por el sistema, con datos reales o de prueba.
2. Descargue el modelo oficial (archivo .ili) de la fuente que indique la autoridad catastral nacional.
3. Importe el XTF a una base de datos PostgreSQL con ili2pg, que crea el esquema a partir del modelo.
4. Valide el archivo con las reglas del modelo.

Los comandos, a modo de ejemplo (ajuste servidor, usuario y nombre del modelo):

# 1. Crear el esquema en PostgreSQL desde el modelo INTERLIS
java -jar ili2pg.jar --schemaimport \
  --dbhost localhost --dbdatabase catastro_prueba \
  --dbusr verificador --dbpwd "$CLAVE" \
  --dbschema ladm_prueba --defaultSrsCode 9377 \
  --models NOMBRE_DEL_MODELO --modeldir "./modelos;http://models.interlis.ch" \
  --createFk --createFkIdx --createBasketCol

# 2. Importar el XTF entregado por el proveedor, validando al cargar
java -jar ili2pg.jar --import --validate \
  --dbhost localhost --dbdatabase catastro_prueba \
  --dbusr verificador --dbpwd "$CLAVE" \
  --dbschema ladm_prueba --models NOMBRE_DEL_MODELO \
  --modeldir "./modelos;http://models.interlis.ch" \
  --log salida_validacion.log muestra_proveedor.xtf

# 3. Validar solo el archivo, sin tocar la base de datos
java -jar ilivalidator.jar --modeldir "./modelos" muestra_proveedor.xtf

Si la validación termina sin errores, el archivo respeta el modelo. Si aparecen errores, el registro indica qué objeto y qué regla fallaron. Eso es lo que debe revisar el supervisor del contrato.

¿Qué errores trae un software que «dice» cumplirlo?

Son los que más se repiten al revisar sistemas existentes:

• Cumplimiento solo en la exportación. La base interna es otra y existe un script que arma el XTF una vez. Funciona en la demostración y falla cuando cambia el modelo o el volumen.
• Modelo recortado. Faltan clases como la fuente administrativa o la responsabilidad, porque «no se usaban». El expediente queda sin soporte.
• Interesados duplicados. La misma persona aparece varias veces con distinto número de documento, y el derecho queda partido.
• Geometrías sin control topológico. Terrenos que se traslapan o dejan huecos entre vecinos; el XTF se genera, pero las reglas de calidad lo rechazan.
• Sistema de referencia equivocado. Datos en coordenadas geográficas cuando el intercambio exige el sistema plano oficial (en Colombia, MAGNA-SIRGAS / Origen-Nacional, EPSG:9377).
• Dominios inventados. Códigos de tipo de derecho o de predio que no corresponden a las listas controladas del modelo.
• Versión desactualizada. Cumple una versión anterior del modelo y nadie lo advirtió.

¿Qué 5 preguntas conviene incluir en el pliego?

Redáctelas como requisitos con evidencia, para que la respuesta sea un archivo y no un párrafo.

1. ¿Qué versión del modelo LADM-COL implementa el sistema y cómo se actualiza cuando la autoridad catastral nacional publica una nueva? Evidencia: archivo .ili usado y procedimiento de actualización.
2. ¿Puede el sistema generar un XTF completo que pase la validación con ilivalidator sin errores? Evidencia: archivo de muestra y registro de validación, ejecutado por la entidad en la fase de pruebas.
3. ¿Puede el sistema importar un XTF externo sin perder información y devolverlo igual? Evidencia: prueba de ida y vuelta con comparación de conteos por clase.
4. ¿Cómo se registran y se vinculan las fuentes administrativas y espaciales a cada derecho y a cada terreno? Evidencia: captura del flujo y consulta SQL que lista derechos sin fuente.
5. ¿Qué controles de calidad geométrica y de duplicados aplica antes de aceptar un predio? Evidencia: lista de reglas e informe de rechazos de una carga de prueba.

Incluya además que el pago esté atado a la aprobación de estas pruebas, no solo a la entrega del software.

¿Dónde entra la captura en campo?

El catastro multipropósito se alimenta de levantamientos. La app de campo no necesita hablar XTF, pero sí capturar los atributos que el modelo exige y entregar geometrías limpias. GcMapFlow, nuestra aplicación Android para captura sin conexión, exporta GeoPackage, GeoJSON, GPX y CSV; desde ahí un proceso de carga validado alimenta el modelo. Puede ver sus funciones en la página de GcMapFlow.

¿Cómo empezar?

Si va a contratar un sistema de catastro multipropósito, o necesita revisar uno que ya tiene, podemos acompañarle en la redacción técnica del pliego y en las pruebas de recepción. Conozca nuestra solución de catastro multipropósito y escríbanos desde contacto para una primera conversación.