Cómo convertir coordenadas de Catastro sin errores
Una parcela aparece perfectamente situada en el visor oficial, pero al cargar sus coordenadas en tu mapa acaba varios metros -o varios kilómetros- fuera de lugar. El problema rara vez es la geometría: suele ser no haber definido bien cómo convertir coordenadas Catastro entre sistemas de referencia, husos UTM y formatos de salida.
Para una persona usuaria, una coordenada es un punto. Para una aplicación inmobiliaria, GIS o de valoración, es un dato con contexto técnico obligatorio: datum, sistema de coordenadas, zona UTM, orden de ejes y unidad. Si uno de esos campos se pierde entre un servicio SOAP, una hoja de cálculo y una API de mapas, la ubicación deja de ser fiable.
Antes de convertir coordenadas de Catastro, identifica el origen
Las coordenadas catastrales españolas se consultan habitualmente en proyección UTM. En gran parte de la península, el sistema de referencia actual es ETRS89, con coordenadas expresadas en metros. Un caso muy frecuente es ETRS89 / UTM zona 30N, identificado como EPSG:25830.
No conviene asumir esa zona para cualquier inmueble. España ocupa varios husos. La zona 29N es habitual en el oeste peninsular, la 30N cubre buena parte del territorio y la 31N aparece en áreas orientales. Canarias requiere especial atención y puede trabajar con la zona 28N o 29N. Por eso, una pareja de valores como `450000, 4470000` no basta para ubicar un punto: sin su EPSG o su huso, es información incompleta.
También existen conjuntos históricos en ED50, especialmente en integraciones antiguas, exportaciones GIS heredadas o bases de datos que no se han migrado. ED50 / UTM zona 30N se suele identificar como EPSG:23030, mientras que ETRS89 / UTM zona 30N es EPSG:25830. Ambos pueden presentar números parecidos, pero no representan exactamente el mismo punto. Tratar ED50 como ETRS89 introduce un desplazamiento suficiente para afectar a una parcela, un lindero o una validación de dirección.
La primera regla es simple: guarda siempre el sistema de referencia junto al valor. En lugar de persistir solo `x` e `y`, almacena `x`, `y`, `epsg`, fecha de consulta y, si aplica, el identificador de la referencia catastral que originó la consulta.
El destino habitual: UTM a latitud y longitud
Muchas aplicaciones web y móviles necesitan latitud y longitud para mostrar un inmueble sobre una capa de mapas. En ese caso, el destino normal es WGS84 geográfico, EPSG:4326. Aquí hay una diferencia que provoca errores recurrentes: UTM utiliza metros y WGS84 utiliza grados decimales.
Una conversión típica parte de estos datos:
```json { "x": 440321.52, "y": 4472098.34, "sourceEpsg": "EPSG:25830", "targetEpsg": "EPSG:4326" } ```
El resultado debería expresar la posición con campos explícitos, no con un array ambiguo:
```json { "latitude": 40.4167, "longitude": -3.7033, "epsg": "EPSG:4326" } ```
Esta claridad evita otra trampa habitual: invertir longitud y latitud. En GeoJSON, el orden de las coordenadas es `[longitud, latitud]`; en interfaces y formularios, lo habitual es mostrar `latitud, longitud`. Ambos formatos pueden contener valores válidos, así que el error no siempre genera una excepción. Simplemente coloca el activo en otro lugar.
Cuando el objetivo es renderizar el dato en un mapa web, valida el contrato de tu proveedor cartográfico. Si consume GeoJSON, entrega una geometría como esta:
```json { "type": "Point", "coordinates": [-3.7033, 40.4167] } ```
No conviertas a EPSG:4326 por inercia si el sistema consumidor trabaja en otro CRS. Un análisis de superficie, una distancia a infraestructuras o una intersección con polígonos catastrales puede requerir mantener UTM, porque las unidades en metros simplifican cálculos métricos y reducen conversiones innecesarias.
La referencia catastral no es una coordenada
Una referencia catastral identifica un inmueble, pero no equivale por sí sola a una coordenada. Una finca puede tener geometría, centroide, dirección o varias construcciones asociadas. Antes de convertir nada, define qué punto necesita el producto.
Para un CRM inmobiliario, un punto representativo o centroide suele ser suficiente para geocodificar y segmentar cartera. Para una plataforma de valoración, puede ser necesario conservar la geometría de parcela y su sistema de referencia. En un caso de uso municipal, la precisión puede afectar a expedientes, notificaciones o cruces con planeamiento, por lo que un marcador aproximado no debería sustituir a la geometría oficial.
Esta distinción también importa al diseñar una API. Un campo llamado `coordinates` es demasiado genérico si no indica si representa el punto de acceso, el centroide de un inmueble o un vértice de la parcela. Los nombres y los metadatos eliminan decisiones implícitas en el cliente.
Flujo de implementación recomendado
La conversión fiable no debería vivir dispersa en componentes de frontend, scripts de analistas y procesos de importación. Centralízala en un servicio o capa de datos con una entrada y una salida predecibles.
Primero, consulta el origen y recupera las coordenadas con su CRS. Después, valida que `x` e `y` sean numéricos, que el EPSG esté permitido y que el huso sea compatible con la ubicación esperada. A continuación, transforma con una librería geoespacial que conozca las definiciones EPSG y sus transformaciones de datum. Finalmente, devuelve el resultado con el CRS de salida, precisión y tipo de geometría.
El contrato puede ser tan directo como este:
```json { "source": { "x": 440321.52, "y": 4472098.34, "epsg": "EPSG:25830" }, "result": { "longitude": -3.7033, "latitude": 40.4167, "epsg": "EPSG:4326" }, "geometryType": "representative_point" } ```
Si trabajas con un backend moderno, evita transportar XML hasta el navegador para resolver una operación tan concreta. Una capa REST que entregue JSON estructurado reduce código de adaptación, hace más legibles las pruebas y permite monitorizar qué sistemas de referencia están llegando realmente a producción. CatastroAPI está planteada precisamente para ese flujo: datos catastrales y conversiones consumibles desde una API sin cargar al equipo con SOAP y estructuras XML heredadas.
Errores que no detecta una conversión “correcta”
Una librería puede completar la transformación sin errores y, aun así, devolver un resultado incorrecto para tu caso. El primer motivo es un EPSG mal asignado. Convertir valores de la zona 29 como si fueran zona 30 genera un punto válido matemáticamente, pero situado donde no corresponde.
El segundo es aplicar una conversión genérica entre ED50 y WGS84 sin revisar la transformación geodésica disponible. Para visualización general, la diferencia puede parecer pequeña. Para delimitación de parcela, contraste de linderos o análisis cercano a elementos lineales, no lo es. La precisión necesaria depende del uso, y debe quedar definida como requisito de producto, no como una decisión improvisada de implementación.
El tercero es redondear demasiado pronto. Seis decimales en grados pueden ser útiles para un marcador de mapa, pero si vas a realizar procesos posteriores con precisión métrica, conserva la precisión original en UTM y redondea solo en la capa de presentación. Lo mismo aplica a conversiones encadenadas: transformar repetidamente entre CRS acumula pequeñas diferencias evitables.
Por último, no confundas coordenadas proyectadas con grados por el aspecto de los valores. Una coordenada UTM X suele tener seis cifras y una Y, siete; una coordenada geográfica española suele estar alrededor de longitudes negativas de un dígito y latitudes cercanas a 36-44. Esta comprobación visual no sustituye al EPSG, pero es una alerta rápida muy útil en logs y paneles operativos.
Pruebas que merecen estar automatizadas
No basta con probar que la API responde 200. Incluye puntos de control conocidos en cada zona UTM que soporte tu producto y verifica el resultado con una tolerancia definida. Prueba también valores de borde entre husos, registros ED50 si tu inventario los recibe y casos en los que falte el CRS.
El comportamiento ante datos incompletos debe ser explícito. Si no sabes el sistema de origen, no devuelvas una latitud y longitud aparentemente precisa. Devuelve un error de validación que indique qué falta, por ejemplo `sourceEpsg is required`. En geodatos, una respuesta bloqueada es preferible a una ubicación falsa que termine en una decisión de negocio equivocada.
Añade trazabilidad operativa: registra el EPSG de entrada, el EPSG de salida, la versión de la transformación y el identificador de solicitud. Cuando un equipo de soporte reciba una captura con un pin mal situado, podrá reproducir el recorrido sin reconstruir una cadena de conversiones manuales.
La mejor conversión no es la que solo produce dos decimales reconocibles en un mapa. Es la que conserva el contexto, declara sus supuestos y permite que el siguiente sistema sepa exactamente qué está consumiendo. Esa disciplina convierte una coordenada catastral en un dato que tu producto puede usar con confianza.