Saltar al contenido
SISTEMA EN OPERACIÓNLADM-COL NATIVO · SINIC V1.0
ANTIOQUIA · BARRIDO PREDIAL · FICHA →
TÉCNICO

Por qué el IGAC rechaza tu entrega XTF al SINIC · errores de validación y cómo evitarlos

Generar el XTF es la parte fácil. Que el Validador SINIC lo acepte es donde se cae la mayoría de las entregas. Un archivo que abre perfecto en su software puede rebotar al chocar contra el modelo LADM-COL vigente, contra las reglas topológicas o contra los catálogos del IGAC.

Esta es la lista de los errores que más rechazan entregas RIC/XTF, con el síntoma que verá en el reporte del validador y la corrección concreta. La idea es que ningún operador descubra el problema cuando ya radicó.

Nota: los nombres de mensajes y herramientas son ejemplos típicos del flujo INTERLIS/LADM-COL. El mensaje exacto depende de la versión del validador del IGAC que tenga publicada al momento de su entrega.

1. Modelo o versión LADM-COL incorrecta

El error más caro porque invalida el archivo completo, no un predio.

  • Síntoma: el validador no abre el XTF, reporta MODEL not found / incompatible model o rechaza el header INTERLIS. También aparece cuando se exporta contra LADM-COL 3.0 pero el SINIC ya exige el modelo vigente (SINIC V1.0).
  • Causa: el schema operativo está desincronizado con el modelo publicado por el IGAC, o el .ili referenciado en el encabezado del XTF no coincide con el repositorio oficial.
  • Cómo se corrige: actualice el schema al modelo SINIC vigente antes de exportar, no después. Verifique que la declaración MODELS del header apunte a la versión exacta y que la herramienta use el .ili oficial, no una copia local desactualizada. Si viene de RIC V0.1, la migración no es opcional: el SINIC ya no recibe el modelo anterior.

2. Topología (geometrías inválidas, solapes y huecos)

La § 13 de la R.388 exige topología cerrada. Es la familia de errores que genera más líneas de bitácora.

  • Síntoma: el reporte marca invalid geometry, self-intersection, overlap o gap con el identificador del predio responsable. Polígonos abiertos, vértices duplicados o geometrías nulas también caen aquí.
  • Causa: edición sin reglas topológicas activas, importación desde shapefiles sucios, o reproyección que rompió la geometría.
  • Cómo se corrige: corra control de calidad topológico antes de generar el XTF. Reglas mínimas:
  1. Polígonos cerrados, sin auto-intersección.
  2. Sin solapes (overlaps) entre predios vecinos.
  3. Sin huecos (gaps) dentro del universo predial donde no deben existir.
  4. Sin vértices duplicados ni geometrías de área cero.
  5. Sin geometrías nulas en atributos espaciales obligatorios.

Cada error debe quedar trazado al predio que lo produce; corregir a ciegas es lo que alarga las entregas.

3. CRS / EPSG:9377 mal reproyectado

  • Síntoma: el validador acepta el archivo pero las geometrías caen fuera del territorio, o reporta coordenadas fuera de rango. A veces pasa el chequeo de CRS pero falla la topología contra predios vecinos por un desfase de metros.
  • Causa: se declaró EPSG:9377 en el header pero las coordenadas siguen en otro datum (Bogotá, orígenes nacionales antiguos, UTM), o se reproyectó con parámetros aproximados en lugar de la transformación oficial MAGNA-SIRGAS.
  • Cómo se corrige: reproyecte todo el universo a EPSG:9377 / MAGNA-SIRGAS origen único nacional con la transformación oficial, no con un on-the-fly del SIG. Confirme que el código EPSG declarado en el XTF coincida con las coordenadas reales. Si tiene dudas sobre la cadena de reproyección, revise cómo reproyectar a EPSG:9377 sin perder precisión.

4. Dominios y codelistas fuera de catálogo

  • Síntoma: value not in domain / illegal value sobre atributos como destino económico, tipo de construcción, condición predial o tipo de documento.
  • Causa: el dato trae un valor heredado del sistema anterior, una mayúscula/tilde distinta a la del catálogo, o un código que ya no existe en la versión vigente de las codelistas.
  • Cómo se corrige: mapee cada campo enumerado contra el catálogo del modelo vigente antes de exportar. No confíe en coincidencias "parecidas": el validador compara contra el dominio exacto. Mantenga una tabla de equivalencias de migración (valor antiguo → valor SINIC) para no reintroducir el error en cada corte.

5. Llaves y relaciones rotas (referencias huérfanas)

  • Síntoma: dangling reference / target object not found / mandatory association missing. Una unidad de construcción que apunta a un predio inexistente, un derecho sin interesado, un predio sin terreno asociado.
  • Causa: exportación parcial del grafo de objetos, borrado de un objeto sin limpiar sus referencias, o oid que no se conservaron entre cortes.
  • Cómo se corrige: valide integridad referencial sobre el conjunto completo antes de exportar. Asegure que toda asociación obligatoria tenga ambos extremos presentes en el XTF y que los oid sean estables y únicos entre entregas. Una exportación "por capas" suele romper esto: exporte el universo como una unidad consistente.

6. Atributos obligatorios vacíos

  • Síntoma: mandatory attribute not set sobre campos como número predial, área, fecha de corte, matrícula o tipo.
  • Causa: campos que el operador dejó en blanco en campo, migración que no rellenó obligatorios del modelo nuevo, o nulos que el software toleró localmente pero el modelo no permite.
  • Cómo se corrige: corra un chequeo de completitud contra la cardinalidad del modelo (qué es MANDATORY y qué admite OPTIONAL) antes de generar el archivo. Lo que su sistema acepta como nulo no es lo que el modelo LADM-COL acepta.

7. Inconsistencias catastro-registro

  • Síntoma: reglas temáticas que comparan el predio contra el folio del SNR fallan: matrícula inexistente, formato inválido, o interesados que no concuerdan con el folio.
  • Causa: matrícula digitada con errores, predio sin vínculo a su folio de matrícula inmobiliaria, o desactualización frente a la base del SNR.
  • Cómo se corrige: valide cada matrícula contra el formato y, donde sea posible, contra la base del SNR antes de radicar. La § 14 exige este vínculo; el SINIC lo revisa al recibir. Documente los casos sin folio (predios informales, baldíos) con la condición que el modelo prevé, en lugar de dejarlos vacíos.

8. Duplicados de número predial

  • Síntoma: unique constraint violated / duplicate key sobre el número predial nacional (NPN).
  • Causa: dos predios comparten NPN por error de digitación, una mutación mal aplicada que no liberó el número anterior, o fusión/división sin asignar números nuevos.
  • Cómo se corrige: verifique unicidad del NPN sobre todo el universo antes de exportar y revise la lógica de mutaciones para que cada predio resultante tenga su número correcto. Es un chequeo barato que evita un rechazo seguro.

Tabla de referencia rápida

| Error | Síntoma en el validador | Causa típica | Cómo se corrige | |---|---|---|---| | Modelo/versión LADM-COL | MODEL not found, no abre el XTF | Schema desincronizado del modelo vigente | Migrar al modelo SINIC vigente; corregir header MODELS | | Topología | invalid geometry, overlap, gap | Edición sin reglas topológicas | QA topológico previo, con predio responsable | | CRS / EPSG:9377 | Coordenadas fuera de rango o desfase | Datum incorrecto o reproyección aproximada | Transformación oficial a EPSG:9377 MAGNA-SIRGAS | | Dominios / codelistas | value not in domain | Valor heredado o fuera de catálogo | Mapear enumerados al catálogo vigente | | Referencias huérfanas | dangling reference, target not found | Exportación parcial del grafo | Validar integridad referencial sobre el universo | | Atributos obligatorios | mandatory attribute not set | Nulos tolerados localmente | Chequeo de completitud contra cardinalidad | | Catastro-registro | Falla regla temática SNR | Matrícula errada o sin vínculo | Validar matrícula y vínculo SNR | | Duplicado de NPN | duplicate key | Mutación o digitación errada | Verificar unicidad del NPN |

Checklist antes de entregar

Antes de radicar el XTF en el SINIC, confirme en este orden:

  1. Modelo: schema sincronizado con el modelo SINIC vigente y header MODELS correcto.
  2. CRS: todo el universo en EPSG:9377 con transformación oficial.
  3. Topología: cero overlaps, gaps, auto-intersecciones, vértices duplicados y geometrías nulas.
  4. Dominios: todos los enumerados dentro del catálogo vigente.
  5. Integridad: cero referencias huérfanas; asociaciones obligatorias completas.
  6. Completitud: cero atributos obligatorios vacíos.
  7. Catastro-registro: matrículas válidas y vinculadas al SNR.
  8. Unicidad: NPN único en todo el universo.
  9. Corrida previa: el Validador SINIC ejecutado sobre sus predios reales, no sobre datos de demo, con bitácora del resultado.

El orden importa: un modelo mal versionado invalida el archivo entero, así que es lo primero. La topología y los dominios son los que más líneas generan, así que son los que más tiempo ahorran si se atacan antes de exportar.

La regla práctica

El rechazo no suele venir de un solo error grande, sino de muchos pequeños que el software local toleró y el modelo no. La diferencia entre una entrega que entra y una que rebota es correr el control de calidad contra el modelo del IGAC antes de radicar, no después.

Si quiere ver el detalle de las exigencias que el validador audita, revise las 12 exigencias técnicas de la R.388 y cómo entregar el RIC al SINIC.

Fuente: IGAC · Resolución 388 de 2020.

Solicitar una corrida del validador SINIC sobre los predios de su municipio →

Revise en detalle las capacidades técnicas de Terraes: LADM-COL nativo, XTF/SINIC, portal ciudadano y conservación.

Ver la plataforma →