JSON versus XML geoespacial: qué conviene usar
Una referencia catastral llega desde un servicio oficial, pero convertirla en un dato útil para una aplicación no debería requerir un parser SOAP, namespaces XML y varias capas de transformación. En la discusión sobre JSON versus XML geoespacial, la diferencia real no es estética: afecta al tiempo de integración, a la fiabilidad del código y a la velocidad con la que un equipo puede lanzar funcionalidades de búsqueda, valoración o geolocalización.
Para productos que trabajan con Catastro español, la pregunta correcta no es si XML es un formato válido. Lo es, y sigue siendo necesario en muchos intercambios institucionales. La cuestión es qué formato reduce fricción cuando una aplicación moderna necesita consumir direcciones, inmuebles, coordenadas o datos administrativos mediante una API.
JSON versus XML geoespacial: la diferencia práctica
XML describe información mediante etiquetas. JSON representa objetos, arrays, cadenas, números y valores booleanos con estructuras nativas en casi cualquier lenguaje web. Ambos pueden transportar geometrías, atributos de parcelas y metadatos de sistemas de referencia, pero obligan a trabajar de forma distinta.
Un servicio XML geoespacial puede devolver una respuesta parecida a esta:
```xml
En JSON, el mismo dato puede exponerse así:
```json { "referenciaCatastral": "1234567VK4713S0001AB", "direccion": { "via": "Calle Mayor", "numero": "10" } } ```
La diferencia parece pequeña hasta que ese dato entra en un frontend TypeScript, una función serverless, un proceso ETL o un CRM. JSON se convierte directamente en un objeto utilizable. XML suele requerir deserialización, gestión de namespaces y una capa adicional para normalizar estructuras que pueden variar entre respuestas.
No se trata de afirmar que XML sea siempre peor. XML ofrece mecanismos maduros para validación formal con XSD, documentación contractual y documentos complejos con contenido mixto. Si se integra un sistema corporativo heredado o un flujo regulado que ya depende de SOAP, sustituirlo puede no ser prioritario. Pero para consultar datos catastrales desde una API REST, JSON suele encajar mejor con el stack que ya usa el equipo.
El coste oculto de SOAP y XML en Catastro
La complejidad de una integración no se mide solo por conseguir una respuesta correcta en una prueba manual. Se mide por lo que ocurre cuando hay direcciones incompletas, municipios con nombres similares, referencias inválidas, límites de cuota, errores temporales o cambios en el servicio de origen.
Con servicios SOAP/XML, es habitual tener que construir envelopes, enviar cabeceras específicas y recorrer nodos anidados para extraer un único valor. También aparecen respuestas donde un elemento puede ser único o repetirse, lo que obliga a tratar de forma distinta un objeto y una colección. En un producto con volumen, esos detalles terminan dispersos por el código si no existe una capa de normalización muy cuidada.
JSON no elimina los problemas de calidad del dato, pero reduce el trabajo mecánico. Un endpoint REST bien diseñado puede expresar los fallos mediante códigos HTTP, entregar errores con una estructura predecible y devolver siempre las mismas claves. Eso permite que el equipo concentre sus pruebas en reglas de negocio: qué hacer cuando no existe una referencia, cómo mostrar una dirección normalizada o cuándo pedir una conversión de coordenadas.
La diferencia es especialmente visible en aplicaciones con interfaz. Un frontend puede consumir una respuesta JSON, tiparla y pintarla sin convertir primero un documento XML a una estructura interna. Menos adaptadores significan menos puntos de fallo y menos tiempo de mantenimiento.
Geometrías y coordenadas: el formato no sustituye al criterio GIS
Hablar de datos geoespaciales introduce una precisión necesaria: JSON genérico no equivale automáticamente a GeoJSON. Una respuesta JSON puede contener latitud, longitud, una referencia catastral y datos de dirección sin ser una geometría interoperable para una librería cartográfica.
Cuando el caso de uso requiere puntos, líneas, polígonos o parcelas, GeoJSON aporta una convención clara. Por ejemplo, un punto puede representarse de este modo:
```json { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-3.7038, 40.4168] }, "properties": { "referenciaCatastral": "1234567VK4713S0001AB" } } ```
Este formato funciona bien con librerías de mapas y herramientas GIS, pero exige revisar el sistema de referencia. Las coordenadas del Catastro pueden manejarse en proyecciones distintas a WGS84. Confundir X/Y proyectadas con longitud/latitud genera marcadores desplazados y errores que parecen de datos cuando, en realidad, son de conversión.
XML también puede expresar geometrías mediante estándares como GML. GML es potente y detallado, sobre todo en entornos GIS tradicionales, pero su verbosidad tiene un coste en aplicaciones web. Para servir una capa cartográfica compleja, GML puede tener sentido si el consumidor lo exige. Para localizar un inmueble, completar una dirección o situar un punto en un mapa web, JSON o GeoJSON suele ser una elección más directa.
El formato correcto depende de la operación. Para consultas transaccionales de propiedades, direcciones y referencias, JSON es normalmente la opción práctica. Para intercambio geográfico especializado entre plataformas GIS que requieren GML, XML puede seguir formando parte del flujo. Lo útil es evitar convertir todo a XML por inercia cuando el consumidor final es una aplicación REST.
Rendimiento: menos bytes no siempre significa menos trabajo
XML suele ser más verboso que JSON porque repite etiquetas de apertura y cierre. En respuestas pequeñas la diferencia apenas importa. En lotes de miles de registros, geometrías extensas o procesos recurrentes, el volumen adicional afecta a transferencia, almacenamiento temporal y tiempos de parseo.
Aun así, no conviene decidir solo por el tamaño del payload. La compresión HTTP reduce buena parte de la diferencia, y una consulta mal planteada puede ser más costosa que cualquier formato. Pedir atributos innecesarios, hacer una llamada por cada resultado o no paginar son problemas mayores que elegir entre llaves y etiquetas.
La ventaja operativa de JSON está más relacionada con el ecosistema. Node.js, Python, Java, .NET, PHP y los navegadores lo procesan de forma nativa o casi nativa. Los logs son más legibles, las pruebas de contratos son más simples y las herramientas de observabilidad muestran el cuerpo de la respuesta sin pasos adicionales.
Qué debe exigir una API catastral moderna
Una API no mejora solo por devolver JSON. Puede entregar JSON inconsistente y seguir siendo difícil de integrar. Para que el cambio frente a XML sea útil, la interfaz debe mantener convenciones estables y documentar los casos reales.
Busque respuestas con nombres de campos previsibles, tipos coherentes y objetos anidados cuando representen una relación clara. Una referencia catastral debe tener el mismo nombre en la consulta por inmueble y en la búsqueda por dirección. Si un campo puede faltar, debe estar documentado. Si una consulta no devuelve resultados, la API debe expresarlo de forma explícita, no mediante una estructura ambigua.
También importan la autenticación y el entorno de pruebas. Una API key sencilla, ejemplos copiables, documentación interactiva y una colección para ejecutar peticiones reducen el tiempo desde la evaluación hasta la primera integración. CatastroAPI aplica este enfoque para evitar que los equipos tengan que lidiar directamente con la complejidad de los servicios SOAP/XML tradicionales.
Un buen diseño separa además las responsabilidades. La aplicación solicita una dirección o una referencia; la API resuelve y normaliza la consulta; el cliente recibe un objeto preparado para su dominio. No hace falta que cada equipo conozca los detalles internos del servicio administrativo para construir una búsqueda inmobiliaria fiable.
Una decisión orientada al producto, no al formato
Si está construyendo un tasador, un CRM inmobiliario, una plataforma proptech o software municipal, elija JSON como formato de consumo principal cuando necesite integrar y evolucionar rápido. Es el camino más corto para conectar backend, frontend, procesos de datos y mapas web con una misma representación.
Mantenga XML cuando un proveedor, un estándar GIS concreto o un sistema heredado lo requiera. En ese caso, encapsule esa dependencia en un adaptador y evite que el resto de la aplicación herede su complejidad. El objetivo no es eliminar XML por principio, sino impedir que una decisión de transporte condicione todo el producto.
La próxima vez que una integración catastral parezca lenta, revise dónde se pierde el tiempo: casi nunca está en leer una referencia. Suele estar en transformar formatos, interpretar respuestas irregulares y repetir trabajo que una API clara debería resolver antes de que el dato llegue a su código.