La base de cualquier proyecto de construcción o cartografía es la definición de un sistema de referencia de coordenadas (SRC) horizontal y vertical inequívoco y recuperable. Esto debe incluirse en las especificaciones del contrato. No se trata de nada nuevo, pero los procedimientos del pasado podrían no ser compatibles con las técnicas de posicionamiento modernas, como el GNSS PPP. Si bien el SRC horizontal puede ser complejo, el vertical suele plantear un problema aún mayor debido a las referencias ambiguas durante el diseño de una construcción. Incluso con una definición inequívoca, la recuperación de los niveles de referencia verticales sigue siendo difícil. En este artículo, describo algunos de los problemas desde una perspectiva hidrográfica, centrándome en los aspectos geodésicos que deben abordarse en las especificaciones.

Especificación de un CRS horizontal

El CRS horizontal especifica cómo deben entregarse al cliente los resultados del estudio. A menudo, se trata de un CRS proyectado a nivel regional o nacional, como la proyección UTM. Una proyección por sí sola no es suficiente y debe ir acompañada de un datum horizontal. Este datum horizontal no suele ser el mismo que el proporcionado por el sistema de posicionamiento (GNSS), por lo que se requiere una transformación del datum con sus parámetros correspondientes. La transformación del datum más común requiere siete parámetros.

Esta transformación de datum requiere especial atención. Mucha gente asume que la salida de un GNSS se basa en el datum WGS84. Si nos fijamos, por ejemplo, en la especificación NMEA0183, que incluso lo indica, esto es lógico. Sin embargo, el CRS de salida de un receptor GNSS está directamente vinculado al CRS del sistema de aumentación. Un GNSS absoluto (GNSS no aumentado, dGNSS de fase de código y PPP) genera sus posiciones según un CRS mundial. Este puede ser WGS84, pero la mayoría de los sistemas PPP generan posiciones basadas en ITRF. Si bien WGS84 se mantiene a 10 cm del ITRF, existen pequeñas diferencias que podrían notarse con PPP. Para colmo, la Tierra es inestable y, debido a la deriva continental, el ITRF (pero también WGS84) se recalcula periódicamente, siendo la última iteración (época) ITRF2020.

RTK genera sus coordenadas en un CRS directamente vinculado a las coordenadas especificadas de la estación base o red. Generalmente, RTK está vinculado a un CRS regional, como ETRS89 en Europa o NAD83 en EE. UU. El CRS utilizado por un sistema relativo se desplaza con la placa continental a la que está fijado, por lo que las posiciones horizontales en un CRS regional son relativamente estables a lo largo del tiempo. Sin embargo, no son completamente estables debido a los cambios en la orientación de la placa y a la creación de nuevas realizaciones (épocas) a intervalos.

Transformaciones de datos

Esto nos lleva al tema de los parámetros de transformación del datum. El datum de salida se define efectivamente a través del datum de entrada del GNSS y la transformación del datum utilizada. Diferentes realizaciones de un datum horizontal requieren parámetros de transformación del datum ajustados. El desplazamiento de siete parámetros por sí mismo no compensa la deriva continental y, por lo tanto, la precisión se deteriora con el tiempo (dentro de un solo levantamiento, un error semiconstante). Esto requiere actualizaciones periódicas de los parámetros de transformación del datum, algo que no necesariamente se hace con especificaciones de copiar y pegar. La alternativa son los desplazamientos de 14 parámetros, que incluyen los siete parámetros y su cambio a lo largo del tiempo. Estos parámetros pueden usarse durante más tiempo, pero aún deben estar vinculados al datum proporcionado por el receptor GNSS, que a su vez depende de la aumentación utilizada.

A menudo, los parámetros de transformación de datum indicados no coinciden con el datum de salida del receptor GNSS. Por ejemplo, en los Países Bajos se utiliza una transformación de datum de ETRS89 a Bessel 1841 para zonas costeras y cercanas a la costa. Si se utiliza RTK, es necesario comprobar la época de ETRS89 en la red RTK y seleccionar los parámetros de transformación de datum adecuados en el software. Sin embargo, la situación se complica si se utiliza PPP. En este caso, tenemos una salida ITRF2020 que debe transformarse a ETRS89, y que a su vez debe transformarse a Bessel 1841. Ignorar el primer paso resulta en errores de unos nueve decímetros, lo cual es excesivo para la mayoría de los proyectos de construcción. Las especificaciones suelen indicar la conversión de ETRS89 a Bessel 1841 (mediante un conjunto de conversión combinado 'RDNapTrans') y la mayoría (¿todos?) del software topográfico solo pueden gestionar una única conversión. Entonces, ¿cómo abordar el primer paso?

Algunos receptores GNSS tienen la opción interna de realizar una transformación de datum. Si bien esto técnicamente no está permitido por el protocolo NMEA0183, soluciona un problema. En este caso, la conversión de ITRF2020 a ETRS89 (¡revise la época!) se realiza en el receptor GNSS y la de ETRS89 a Bessel 1841 en el software topográfico. Sin embargo, no todos los receptores tienen esta opción. La alternativa es realizar un desplazamiento de bloque en el software topográfico. La mayoría del software lo permite en las coordenadas proyectadas. En este caso, la primera transformación de datum se calcula como un desplazamiento dE, dN en UTM (u otra proyección cartográfica) y se aplica a las coordenadas transformadas. Para un área de unas pocas decenas de kilómetros de ancho, el error resultante se limita al nivel de centímetros y suele ser aceptable.

LAT y MSL

Si el datum horizontal es complejo, el datum vertical lo es aún más. Dependiendo del tipo de proyecto, suele especificarse un datum derivado de mareas, como 'LAT' o 'MSL'. La OHI también recomienda el primero como referencia vertical (o un nivel cercano a este). Sin embargo, no existe tal cosa como LAT o MSL. O, como indica la base de datos EPSG para MSL (y LAT): «Aproximado porque no es específico de ninguna ubicación o época. Se recomienda a los usuarios no utilizar este CRS genérico, sino uno con un origen de datum específico (por ejemplo, 'Nivel medio del mar en xxx durante yyyy-yyyy') o definido mediante un modelo geoidal/hidroide específico».

En otras palabras, los datos verticales basados en mareas deben especificarse para un lugar específico y con una época específica en la que se basan. En el caso del nivel medio del mar (NMM), esto es fácil de entender, ya que todos conocemos el aumento del nivel del mar. En promedio, el NMM aumenta 4 mm al año, pero este cambio no es el mismo en todas las ubicaciones. La LAT varía aún más de una ubicación a otra, ya que depende de la forma y la amplitud de la curva de mareas. Como resultado, la LAT puede variar significativamente (de decímetros a metros) en tan solo unos pocos kilómetros de costa, mientras que el NMM se mantiene relativamente estable.

Alturas GNSS y datum vertical

Sin embargo, este es solo un aspecto del datum vertical. Hoy en día, muchos proyectos se realizan utilizando GNSS para mediciones de altura (RTK o PPP GNSS). Como se mencionó anteriormente, estos generan su posición en un datum global (elipsoidal). Sin embargo, la mayoría de los proyectos no están interesados en alturas elipsoidales, sino que requieren "algo" relacionado con un datum terrestre o una referencia de marea. Para convertir una altura elipsoide en un datum geoidal (ortométrico) terrestre, se requiere un modelo de separación geoide-elipsoide. Aunque a menudo se afirma que son lo mismo, el MSL y el geoide no lo son. Mientras que el geoide se basa en la gravedad, el MSL se basa (tradicionalmente) en mediciones reales de marea. Las diferencias dependen de la definición del geoidal (datum terrestre), pero también del comportamiento de las mareas. Los cambios a lo largo del tiempo entre ambos no solo dependen del aumento del nivel del mar, sino también de la subsidencia del terreno (o incluso de la elevación), donde el datum terrestre puede verse influenciado por cambios geológicos (dependiendo de cómo se defina).

Como resultado, las alturas GNSS deben transformarse de alturas elipsoidales a alturas geoidales y de ahí a un valor MSL o LAT utilizando un modelo de separación. Para algunas áreas en el mundo, existen modelos que permiten la transformación directa de un datum GNSS a un valor LAT o MSL. Para otras áreas, se requieren dos correcciones o modelos separados, uno para derivar la altura geoidal del datum GNSS y otro para determinar MSL o LAT a partir del geoide. Aunque las diferencias entre la altura derivada de diferentes datums GNSS son pequeñas (nivel de cm), no obstante tienen un efecto sistemático. Diferentes modelos para derivar LAT y MSL potencialmente dan diferentes respuestas, incluso sin considerar la elevación del MSL y la elevación de LAT que la acompaña (en relación con el datum GNSS - geoide).

 

Obtención de valores de desplazamiento vertical

Es posible obtener una separación geoide-elipsoide local con un coste relativamente bajo, siempre que se disponga de al menos un punto de referencia. La altura GNSS debe registrarse sobre este punto de referencia (preferiblemente durante un período prolongado, por ejemplo, más de 24 horas) y, al compararla con la altura del punto de referencia dada, se obtendrá una compensación para ese punto. Una campaña de nivelación en torno al proyecto permitirá determinar con mayor precisión puntos adicionales. Por lo tanto, con un esfuerzo relativamente pequeño, se puede crear un modelo rudimentario pero eficaz de separación geoide-elipsoide local.

Para obtener una desviación geoide-LAT local se requieren mediciones de mareas con un mareógrafo conectado al datum local terrestre. Para un análisis armónico adecuado, se requieren al menos 18,6 años de datos (continuos). No es imposible obtener la LAT a partir de series temporales más cortas, pero estas presentan una inexactitud que depende de la representatividad de las condiciones para ese período. Por ejemplo, un período de medición de 30 días puede verse afectado por fenómenos meteorológicos de corta duración, como tormentas, y no incluirá las influencias estacionales. Un análisis armónico de 30 días tiene una precisión de centímetros a decímetros con respecto al valor de LAT de período largo. Un año de mediciones proporcionará un valor más estable. Si el proyecto es lo suficientemente corto, un solo valor es suficiente. Para proyectos más largos o mediciones de mareas de hace algún tiempo, se debe incorporar la subida del nivel del mar (NM) en la desviación vertical.

Especificaciones y geodesia

Al redactar las especificaciones, se debe considerar todo lo anterior, pero no necesariamente el especificador debe resolverlo. Se debe especificar el CRS horizontal de salida (incluido el datum local), pero la transformación del datum puede dejarse en manos del contratista si el cliente proporciona una coordenada de punto de control que le permita verificar que la transformación se ha implementado correctamente. Como alternativa, el especificador debe indicar los datums y parámetros exactos que se utilizarán y mantenerlos actualizados para proyectos posteriores.

El datum vertical debe especificarse mediante la ubicación y la época de referencia o, alternativamente, mediante un modelo (que indique claramente qué entrada y salida del modelo se requieren). Se recomienda mantener los modelos constantes para proyectos consecutivos, siempre que el aumento del nivel del mar no sea un problema. Al cambiar de modelo, se deben investigar los efectos.