Una ingeniería técnica lleva tres años prescribiendo la misma plataforma GMAO+GIS a distintos clientes del sector industrial privado. Con el quinto proyecto llega un grupo industrial con sitios repartidos por toda la península ibérica: una planta en Braga, otra en Vilagarcía, un centro logístico en Torrelavega, una tercera planta en Girona y una cartera fotovoltaica en Sevilla. La ingeniería entrega el asset register del primer sitio en el sistema de coordenadas local portugués, PT-TM06/ETRS89. El segundo en ETRS89 UTM 29N. El tercero en UTM 30. El cuarto en UTM 31. El quinto vuelve a UTM 30. Seis meses después de la puesta en operación del quinto proyecto, el asset manager central del grupo pide al proveedor una vista consolidada de la cartera. La plataforma superpone las cinco proyecciones y el resultado es inutilizable: sitios que aparecen a kilómetros de donde deberían, capas que se caen fuera del extent de la proyección activa, distancias entre sitios de escalas incoherentes. La ingeniería recibe la llamada. No hay una intervención rápida disponible: cada coordenada del maestro de cada sitio se registró en su proyección local y rehacer el cruce implica reproyectar cada geometría y validar cada transformación una a una.
La decisión sobre el sistema de coordenadas del asset register es una de las primeras que se toman en un proyecto GMAO+GIS y una de las que se hornean permanentemente en el resultado. Deshacerla no es imposible, pero es cara, lenta y con riesgo de pérdida de precisión. Las ingenierías técnicas la tratan con frecuencia como un detalle de configuración y heredan la proyección habitual del área de trabajo sin fijarla explícitamente en el pliego. Ese silencio inicial es lo que se convierte, tres o cinco años después, en el problema que la escena anterior describe.
Lo que la decisión de SRS decide en realidad
Cuatro consecuencias viven durante toda la vida del asset register desde el momento en que se elige el sistema de coordenadas. La primera es si las consultas espaciales a escala de cartera funcionan o no. Un asset register almacenado íntegramente en un mismo sistema geodésico soporta cualquier consulta espacial global; un asset register que mezcla proyecciones diferentes por sitio necesita transformar cada elemento cada vez que se consulta, con la pérdida de rendimiento y el riesgo de error acumulado que esto conlleva. La segunda es la interoperabilidad con los otros sistemas GIS del cliente: catastro, cartografía oficial, capas de aseguradoras, servicios de terceros. La transformación es siempre posible; el punto es si es directa o si exige un paso adicional por proyecto. La tercera es el suelo de precisión en cálculos de distancia y área a escala de la cartera. Una proyección optimizada para un huso concreto degrada su precisión cuando se la fuerza fuera de él; una proyección geográfica global degrada precisión al mostrarla como plano. El compromiso es real y hay que aceptarlo conscientemente. La cuarta es la complejidad de las transformaciones que terceros necesitan para consumir el dato: cuando cada sitio vive en una proyección distinta, cada consumidor externo tiene que gestionar la lógica de detección de sistema y aplicación de transformación.
Los tres arreglos clásicos para carteras distribuidas en Iberia
Un operador privado con cartera distribuida en la península ibérica se encuentra clásicamente con tres opciones de arranque, cada una con su compromiso. El primero es proyección local por región: ETRS89 UTM 29N, 30N o 31N según huso ibérico correspondiente al sitio, con PT-TM06/ETRS89 para el ámbito portugués. Este arreglo maximiza la precisión de las operaciones espaciales por sitio y minimiza la interoperabilidad cross-cartera. El segundo es un sistema geográfico único: ETRS89 en coordenadas geográficas (latitud, longitud) para toda la cartera. Este arreglo unifica la vista de cartera y las transformaciones a otros sistemas se hacen sobre la marcha; su compromiso es que las operaciones espaciales complejas requieren proyectar temporalmente a un sistema local. El tercero es Web Mercator (EPSG:3857) para presentación visual: el sistema estándar de Google Maps, OpenStreetMap y todas las herramientas de mapa web. Es útil como sistema de renderizado y desastroso como sistema de cálculo geodésico, porque introduce distorsión creciente con la latitud.
La lectura sensata para una cartera privada distribuida no es elegir uno de los tres, sino separar las tres funciones y usar el sistema apropiado para cada una: almacenamiento en el sistema geográfico global, cálculo en el sistema proyectado local pertinente y presentación en el sistema de mapa web. Una plataforma moderna soporta las tres capas simultáneamente por diseño.
Las tres líneas que el pliego debería fijar
Una ingeniería que quiera cerrar la ambigüedad del proveedor y la del cliente sobre el sistema de coordenadas debería incluir tres líneas específicas en el pliego técnico. La primera es el sistema de almacenamiento primario: el SRS en el que el maestro de activos vive en la base de datos de la plataforma. La convención sensata en Europa es ETRS89 en coordenadas geográficas, con el código EPSG correspondiente explícito. La segunda es el sistema de presentación por defecto para el navegador operativo: típicamente Web Mercator, que se alinea con la experiencia visual del resto de mapas web que el usuario de campo o el asset manager ven a diario. La tercera es el sistema o sistemas de cálculo geodésico habilitados: qué UTM se usará para consultas de distancia y área en cada región de la cartera. Una plataforma seria puede activar dinámicamente el sistema de cálculo apropiado al ámbito de la consulta sin que el usuario tenga que preocuparse; pero eso solo funciona si el pliego lo especifica de antemano.
Cómo lo resuelve Maptainer
En Maptainer la decisión de almacenamiento está tomada en la plataforma y conviene conocerla antes de redactar el pliego: las geometrías se guardan internamente en EPSG:3857, coherente con la teselación web, y se transforman a EPSG:4326 en las fronteras del sistema; la API y la exportación entregan siempre GeoJSON en 4326. Al importar se indica el sistema de referencia de origen de cada fichero, de modo que sitios levantados en UTM 29, 30 o 31 o en PT-TM06 conviven en una misma base sin que el usuario elija proyección. Para cálculos de distancia y área con exigencia geodésica, lo prudente es trabajar sobre la exportación en el sistema proyectado local que corresponda. Lo que la ingeniería debe fijar en el pliego, por tanto, es el sistema de entrega y el de cálculo, no el de almacenamiento.
La decisión de arranque como protección profesional
La conversación clásica del arranque de un proyecto GMAO+GIS suele saltar por encima de la decisión del SRS y bajar directamente a la carga del maestro y a la definición de flujos. La ingeniería que dedica quince minutos del arranque a fijar en el pliego las tres líneas anteriores está haciendo un trabajo que su cliente no le pide en ese momento y que su cliente le agradecerá tres años después. No es un refinamiento técnico opcional: es la protección profesional de la flexibilidad futura de la cartera. Y es un ejemplo concreto de la diferencia entre una prescripción que gana el proyecto en curso y una prescripción que gana los próximos cinco años del cliente.