Errores frecuentes que rechaza la SEC al validar un GML INSPIRE

Si has llegado aquí porque la Sede Electrónica del Catastro (SEC) te ha rechazado un GML INSPIRE, lo más probable es que el motivo esté entre los nueve errores que cubre este artículo. La mayoría son detalles del formato XML que la documentación oficial del INSPIRE no resalta y que solo descubres cuando IVGA te dice "validación negativa" sin más explicación.

Vamos al grano. Los 9 motivos más habituales de rebote, ordenados por frecuencia real, con ejemplos del XML que falla y del XML que pasa.

1. Raíz <gml:FeatureCollection> en lugar de <wfs:FeatureCollection>

Es el error número uno. Mucha herramienta genérica de exportación INSPIRE produce el GML envuelto en <gml:FeatureCollection>. La SEC NO lo acepta — exige el envoltorio de WFS 2.0.

Mal:

<gml:FeatureCollection xmlns:gml="...">
  <gml:featureMember>
    <cp:CadastralParcel>...</cp:CadastralParcel>
  </gml:featureMember>
</gml:FeatureCollection>

Bien:

<wfs:FeatureCollection
    xmlns="http://www.opengis.net/wfs/2.0"
    timeStamp="2026-05-07T12:00:00"
    numberMatched="1" numberReturned="1">
  <member>
    <cp:CadastralParcel>...</cp:CadastralParcel>
  </member>
</wfs:FeatureCollection>

Tres detalles importantes que muchas veces se pasan por alto:

• El namespace WFS 2.0 va como xmlns por defecto (no como prefijo).
• timeStamp, numberMatched y numberReturned son obligatorios en la raíz.
• Cada parcela se envuelve en <member> (no en <gml:featureMember>).

2. srsName en URN antigua

Otro clásico. Las versiones antiguas de OpenLayers, GeoTools y la mayoría de scripts caseros usan la URN tradicional para identificar el CRS:

<gml:MultiSurface srsName="urn:ogc:def:crs:EPSG::25830">

La SEC actual rechaza esta forma. Hay que usar la URL:

<gml:MultiSurface srsName="http://www.opengis.net/def/crs/EPSG/0/25830">

El cambio parece cosmético pero es estricto: cada srsName (en MultiSurface, Surface y Point) tiene que llevar el formato URL.

3. Exterior CCW (sentido OGC) en lugar de CW

La OGC define como canónico que el polígono exterior se trace en sentido antihorario (CCW) y los huecos interiores en horario (CW). Es lo que producen shapely.orient, JTS, PostGIS ST_ForcePolygonCCW y casi cualquier librería geoespacial moderna.

La SEC exige lo contrario: exterior horario (CW), interiores antihorario (CCW). Si tu pipeline usa la convención OGC sin invertirla, la SEC rechaza con un error opaco que casi nunca menciona la orientación.

Bien (sentido SEC):

<gml:exterior>
  <gml:LinearRing>
    <gml:posList srsDimension="2" count="5">
      414000.00 4477000.00
      414000.00 4477025.00
      414040.00 4477025.00
      414040.00 4477000.00
      414000.00 4477000.00
    </gml:posList>
  </gml:LinearRing>
</gml:exterior>

En shapely lo fuerzas con orient(polygon, sign=-1.0). En PostGIS, con ST_ForcePolygonCW(geom).

4. MultiPolygon (más de un surfaceMember por parcela)

Si tu parcela tiene dos recintos disjuntos (clásico en fincas con caminos por medio), la tentación es exportar un MultiPolygon con varios <gml:surfaceMember>:

<gml:MultiSurface srsName="...">
  <gml:surfaceMember><gml:Surface>...</gml:Surface></gml:surfaceMember>
  <gml:surfaceMember><gml:Surface>...</gml:Surface></gml:surfaceMember>
</gml:MultiSurface>

La SEC no lo admite. Cada <cp:CadastralParcel> debe tener exactamente UN surfaceMember. Si hay varios recintos, se exportan como parcelas independientes con identificadores diferentes.

5. EPSG no soportado

Solo se aceptan cuatro CRS oficiales para el GML INSPIRE del Catastro español:

• EPSG:25829 — ETRS89 / UTM zona 29N (Galicia, Asturias, oeste)
• EPSG:25830 — ETRS89 / UTM zona 30N (centro y norte peninsular)
• EPSG:25831 — ETRS89 / UTM zona 31N (Cataluña, Baleares)
• EPSG:32628 — WGS84 / UTM 28N (Canarias)

Si tu DXF llega en cualquier otro CRS (típicamente coordenadas locales o un EPSG desactualizado como 23030), tienes que reproyectar antes de exportar. La SEC te rechaza el GML aunque la geometría sea perfecta.

6. <cp:label> vacío o demasiado largo

El elemento <cp:label> lleva el número de parcela dentro del lote. Reglas:

• No puede estar vacío (nunca).
• Para suelo urbano admite hasta 2 dígitos ("01", "02"...).
• Para suelo rústico admite hasta 5 dígitos.
• No se admiten letras ni caracteres especiales en este campo.

Es muy frecuente que los exportadores genéricos pongan ahí el nombre completo de la parcela ("Parcela A" o el localId). La SEC lo rechaza.

7. <cp:nationalCadastralReference> vacío

Otro campo que siempre debe llevar contenido. Si tienes una RC oficial, ahí va:

<cp:nationalCadastralReference>9872023VH5797S0001WX</cp:nationalCadastralReference>

Si todavía no la tienes (por ejemplo, en una segregación previa al alta catastral), se pone el identificador local sanitizado del proyecto:

<cp:nationalCadastralReference>PROV_SEGREGACION_NORTE_01</cp:nationalCadastralReference>

Lo que NO se puede hacer es dejarlo en blanco o autocerrarlo (<cp:nationalCadastralReference />).

8. Falta <cp:endLifespanVersion> con xsi:nil="true"

Aunque la parcela no tenga fecha de fin (lo normal), el elemento debe estar presente y declararse explícitamente nulo:

<cp:endLifespanVersion
    xsi:nil="true"
    nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"/>

Omitirlo, dejarlo vacío o usar otro nilReason distinto del Unpopulated provoca rebote.

<cp:beginLifespanVersion> complementa al anterior y lleva una fecha ISO-8601 de cuándo se creó la versión actual del registro:

<cp:beginLifespanVersion>2026-05-07T12:00:00</cp:beginLifespanVersion>

9. namespace mal asignado: ES.SDGC.CP vs ES.LOCAL.CP

Cada parcela lleva un <base:Identifier> con dos partes: el <base:localId> y el <base:namespace>. La regla simple es:

• ES.SDGC.CP — cuando el localId es una referencia catastral oficial ya emitida por la DGC.
• ES.LOCAL.CP — cuando es un identificador propuesto por el técnico (parcelaciones nuevas, segregaciones aún no registradas).

Mezclarlos al revés (poner ES.SDGC.CP con un localId propuesto) hace rebotar la validación.

¿Cómo detectar todos estos errores ANTES de presentar a IVGA?

Hay tres caminos:

1. Validar contra el XSD oficial (CadastralParcels.xsd) en local. Detecta los errores de estructura (1, 7, 8) pero no los de contenido (2, 3, 5, 9). Es necesario pero insuficiente.

2. Subir el GML al Validador IVG/IVGA de la propia SEC. Te da el veredicto definitivo, pero el mensaje de error es opaco y no siempre te dice qué línea falla.

3. Producirlo desde un pipeline que conozca el formato de la SEC. Es lo que hace nuestra herramienta: cada export se construye con una plantilla validada por golden-file tests; los 9 errores listados aquí están cubiertos por defecto, sin que el usuario tenga que pensarlos.

Nota técnica: la documentación oficial canónica de la DGC para el formato GML está en el documento "Fichero GML — Coordinación Catastro-Registro", que se puede descargar desde el Asistente Catastro-Registro. Es la única fuente fiable — los XSDs públicos de INSPIRE permiten cosas que la SEC rechaza, así que validar solo contra el XSD da falsos positivos.

Conclusión

La SEC no es estricta sin razón: cada uno de estos 9 puntos protege la integridad del expediente catastral cuando se cruza con el Registro de la Propiedad bajo la Ley 13/2015. Pero el coste para el técnico es alto si los descubre por rebote.

Si validas IVGA un par de veces al año, los plugins gratuitos (Check4SEC, SEC4QGIS) son una opción razonable. Si lo haces cada semana o cada día — y especialmente si tu cliente paga por un GML que debe pasar a la primera — vale la pena un pipeline que lo automatice.

💡 ¿Quieres saber si tu GML pasaría la SEC antes de presentarlo? Súbelo a nuestro validador online gratuito: comprueba estas reglas de formato al instante y te dice exactamente qué falla y cómo arreglarlo, sin guardar tu fichero.