TRABAJOS DE INVESTIGACIÓN

Los marcos de referencia en el posicionamiento satelital a tiempo real

Reference frames in real time satellite positioning

 

Maria Fernanda Camisay^1,4, Esteban Striewe², María Virginia Mackern^1,3

¹ Facultad de Ingeniería - CONICET, Universidad Juan Agustín Maza, Mendoza; fcamisay@conicet.gov.ar.
² Instituto de Agrimensura, Fac. de Ingeniería, Universidad de la República, Montevideo, Uruguay; estriewe@fing.edu.uy
³ Facultad de Ingeniería, Universidad Nacional de Cuyo, Mendoza; vmackern@mendoza-conicet.gov.ar
⁴ Consejo Nacional de Investigaciones Científicas y Técnicas

---

RESUMEN

Los servicios de posicionamiento satelital a tiempo real (RT), utilizan el protocolo de internet NTRIP (Networked Transport of RTCM via Internet Protocol) para transmitir correcciones diferenciales provenientes de estaciones GNSS permanentes. Los usuarios pueden posicionarse de manera precisa en el instante de medición y obtener coordenadas en el marco de referencia implícito en las correcciones recibidas. Por lo tanto, una correcta configuración de los servicios RT, garantizará a los usuarios no sólo vincularse adecuadamente al marco de referencia sino también alcanzar óptimas precisiones en las coordenadas resultantes.
Luego el objetivo de este trabajo fue analizar la actual situación de los servicios ofrecidos en Brasil, Uruguay y Argentina. Para ello se estudió la estructura de configuración tanto para las estaciones GNSS permanentes de la región (Servers-NTRIP), como para los servidores centrales o Caster-NTRIP. Se analizaron en detalle cada uno de los mensajes transmitidos (RTCM) por las estaciones server. Se verificó el marco al que refieren las correcciones, al igual que la referencia al respecto en el sitio de su publicación. Se constató que un usuario no accede al conocimiento del marco de referencia en el momento de medición.
Se presentan experiencias de aplicación realizadas en la zona limítrofe Uruguay-Argentina en las cuales se crearon en modo experimental, correcciones generadas por una misma estación en tres marcos de referencia distintos: POSGAR 2007 (Arg.), ROU 98 (Uru.) y coordenadas semanales SIRGAS. Los resultados permiten cuantificar la influencia de emplear distintos marcos de referencia, en la precisión y exactitud de la posición obtenida en tiempo real.

Palabras claves: GNSS; Tiempo Real; NTRIP; Marco de Referencia; Época.

ABSTRACT

Real time (RT) satellite positioning services offered by the latinamerican countries are using the Internet Protocol NTRIP (Networked Transport of RTCM via Internet Protocol) for transmitting differential corrections from GNSS permanent stations (Servers-NTRIP). Users can be positioned with precision at the moment of measurement and get the coordinates in the reference frame implicit in the base station coordinates from which the corrections was received. Therefore, a correct configuration of RT services, will ensure users not only to refer to the appropriate reference frame but also obtain optimal precision in the resulting coordinates.
Then the objective of this work was to analyze the current situation of the services offered in Brazil, Uruguay and Argentina. The configuration of the reference stations as well as the regional caster has been studied to accomplish such object. Each RTCM messages transmitted from server stations was also analyzed in detail. The reference frames of the coordinates were verified, as well as the reference to it in the publishing site. It was found that a user does not have information of the framework at the time of measurement.
Results of experiences performed in the Uruguay - Argentina border zone were presented. Experimental streams was created from the same station on three different reference frames: POSGAR 2007 (Arg) , ROU 98 (Uru.) and weekly SIRGAS coordinates. These results quantify the influence of using different reference frames in the accuracy of the real time positioning.

Key words: GNSS; Real Time; NTRIP; Reference Frame; Epoch.

---

 

INTRODUCCIÓN

Los sistemas globales de navegación satelital (GNSS) han tenido un gran avance en la última década por la evolución de la tecnología asociada y por el mejoramiento de los métodos de posicionamiento. En este sentido, la señal emitida por los satélites se puede corregir actualmente mediante el uso de estaciones de referencia, que transmiten correcciones en Tiempo Real (RT) a los receptores GNSS que se encuentren en las inmediaciones [Weber et al., 2005]. De esta manera han ido surgiendo diversos Servicios de correcciones diferenciales permitiendo a sus usuarios posicionarse mediante técnicas diferenciales tanto de fase, con RTK, cómo con código, a través de la técnica DGPS. Por lo tanto, estos servicios pueden ser utilizados por aquellos usuarios que posean receptores topo-geodésicos, realizando posicionamiento RTK y alcanzando precisiones centimétricas; como así también por usuarios con simples navegadores de mano obteniendo precisiones de 1 a 5 metros, con DGPS.
Este nuevo concepto de método diferencial requiere de un enlace de comunicación entre el receptor base y el remoto. Allí se introduce el concepto de Tiempo Real, ya que esta comunicación debe llevarse a cabo en el momento de observación.
Desde sus orígenes las técnicas RT han utilizado enlaces radiales para el envío de correcciones mediante radiotransmisores, UHF y VHF principalmente. Este enlace es muy confiable pero su alcance está limitado a la potencia de los radiotransmisores, por lo que la distancia base-móvil es un factor fundamental. Así también las posibles interferencias que hubiese en el terreno, afectan el alcance. Esta limitación, se convirtió en la razón principal para investigar nuevas formas de transmisión de la corrección.
De esta manera desde 2003, se ha impuesto la utilización del protocolo de Internet NTRIP (del inglés "Networked Transport of RTCM vía Internet Protocol"), para la transmisión de correcciones y datos GNSS. Su principal desarrollador es la Agencia alemana de Cartografía y Geodesia BKG (Bundesamt für Kartographie und Geodäsie) y está basado en el protocolo de transferencia de hipertexto HTTP/1.1. NTRIP es un protocolo de internet genérico diseñado para difundir correcciones diferenciales u otro tipo de datos GNSS bajo el formato estándar RTCM (Radio Technical Comission of Maritime Service) [Gebhard and Weber, 2003; Weber et al., 2003].
El formato RTCM, está compuesto por diversos mensajes, cada uno de ellos está definido en cuanto a contenido y frecuencia de emisión. A su vez, existen distintas versiones de este formato estándar, ya que el mismo ha ido sufriendo actualizaciones. Siendo las más utilizadas en la actualidad la versión 2.3 y la 3.0. De acuerdo a la versión los mensajes varían, pero en líneas generales, contienen los observables de los sistemas de posicionamiento satelital GPS y GLONASS, coordenadas de la estación de referencia, definición y tipo de antena, correcciones de código y fase, entre otros. En el caso de la versión 3.0, se puede transmitir adicionalmente un mensaje de solución de red, conformado por las correcciones diferenciales de un conjunto de estaciones permanentes, lo cual aumenta la consistencia y estabilidad de las soluciones de posicionamiento en Tiempo Real. El flujo de datos se denomina "stream".
De acuerdo con la descripción del protocolo NTRIP [RTCM 10410.0, 2004] este cuenta con 4 elementos principales: NTRIP Source, NTRIP Server, NTRIP Caster y NTRIP Client. Ntrip Source y Ntrip Server, se consideran como un único elemento ya que el primero se refiere a las estaciones de referencia que generan las correcciones (fuentes de datos) y el segundo al programa que envía esas correcciones al Caster. Las estaciones GNSS permanentes modernas, se consideran Source y Server a la vez, ya que generan las correcciones y las envían ellas mismas al Caster sin necesidad de utilizar un programa Server adicional. Por lo tanto, el sistema consta de 3 componentes:
1) Server NTRIP, está conformado por las estaciones GPS/GNSS permanentes que transfieren datos RTCM al Caster NTRIP a través de una conexión TCP/IP.
2) Caster NTRIP, es un servidor de Internet que, por un lado recibe los streams de datos provenientes de las estaciones Server, y por otro controla si los usuarios están autorizados para recibirlos y se los re-transmite.
3) Clientes NTRIP, está conformado por los usuarios que reciben los streams de datos RTCM. Los clientes primero necesitan ser aceptados por el Caster NTRIP y, una vez autorizados, pueden seleccionar y recibir los datos GNSS y correcciones desde el Caster NTRIP.
Respecto a las aplicaciones que tiene este protocolo, una de las más importantes es en la Georreferenciación de parcelas. Antes de la aparición de las técnicas RT, esa tarea se llevaba adelante mediante posicionamiento diferencial convencional: un receptor base sobre un punto de coordenadas conocidas y el móvil sobre el vértice de la parcela a georreferenciar. Luego se procesaban las observaciones obtenidas ya que sólo se alcanzaba precisión centimétrica realizando un cálculo diferencial, con posterioridad a la medición.
Actualmente, con las técnicas RT, es posible vincularse a un determinado marco de referencia, con precisión, en forma rápida (en el instante de medición), simple (con un único receptor por parte del usuario, ya que las bases son las estaciones server) y segura (el usuario se posicionará en el marco de referencia en el que están las coordenadas de la estación server).
Por lo tanto, una de las ventajas más relevantes de NTRIP es que permite obtener coordenadas en el marco de referencia de las estaciones Server-NTRIP utilizadas, sin necesidad de realizar cálculos adicionales ni pos-procesamiento.
De esta forma, una correcta configuración de las estaciones GNSS permanentes que transmiten las correcciones RT-NTRIP, asegura no sólo la vinculación de los usuarios al marco de referencia sino alcanzar óptimas precisiones en las coordenadas resultantes.
Es recomendación que las coordenadas de las estaciones estén referidas al mismo marco de referencia en el que se encuentren las efemérides utilizadas, es decir a la última solución del marco de referencia internacional ITRF.
Se presentan entonces dos problemáticas, por un lado los marcos nacionales de la región no materializan la última solución ITRF, presentando una desactualización de entre 7 y 18 años, según el caso. Por otro lado, dichos marcos no son consistentes entre sí, si consideramos precisión centimétrica. Es decir que si un usuario quisiera vincularse a estaciones de distintos países tendría que tener presente esta situación.
En este trabajo se presenta el análisis del tratamiento del Marco de referencia en las tres componentes del sistema NTRIP: Caster, Server y Usuario. El objetivo perseguido a partir de este análisis es proponer una estructura de configuración para las estaciones server-NTRIP de la región que permita a los usuarios RT vincularse al marco de referencia, en forma segura y consistente.
Luego se expone un caso de aplicación concreto, donde se evalúa la influencia de las coordenadas introducidas como control en las estaciones server, sobre la precisión y exactitud de las coordenadas resultantes del usuario.

METODOLOGÍA

Análisis de Marco de Referencia en el sistema NTRIP
En primer lugar se procedió a investigar las características principales de los servicios de tiempo real existentes en la región. Se analizaron los más desarrollados de Latinoamérica: RAMSAC-NTRIP en Argentina, REGNA-ROU en Uruguay y RBMC-IP en Brasil. Haciendo especial hincapié en la información que publican a sus usuarios respecto del Marco de Referencia en el que están las coordenadas de las bases y que por consecuencia será, en el que se obtendrán las coordenadas de los puntos medidos.
Si bien una de las principales ventajas del posicionamiento diferencial RT, es que permite densificar los marcos de referencia de manera sencilla y rápida, la información sobre el marco no se reporta directamente sino que se transmite indirectamente a través de la corrección que recibe el usuario y no es fácilmente identificable. De allí la importancia que esta información se encuentre debidamente publicitada.
Se consultaron las páginas web de cada servicio NTRIP en la región y sólo en RAMSAC-NTRIP (Argentina) se encontró que es reportado el marco y la época de referencia utilizado: POSGAR2007, época 2006.632. Para los dos restantes casos se realizaron consultas a los administradores de cada servicio.
Como segunda medida se examinó la lista o "Sourcetable" que publica cada servidor. Este listado muestra el contenido de cada Caster, y puede ser visualizado a través de un navegador de Internet (browser) indicando la dirección IP y el puerto de conexión. La información puede publicarse de manera actualizada (en tiempo real) o estática dependiendo del software que utiliza cada servidor.
La Sourcetable contiene tres partes principales: la descripción del caster (CAS) propiamente dicho, información de la Red (NET) a la cual pertenecen las estaciones Server y de los streams (STR) o datos que estas transmiten. Se revisaron las primeras dos partes CAS y NET en los tres servicios nombrados, para verificar si existía información pertinente al marco y a la época de referencia.
Por otro lado, en las estaciones Server se analizaron las coordenadas de referencia que son emitidas en los streams o correcciones RT. Para ello se utilizó el software libre "GNSS Surfer" que permite transformar el mensaje transmitido en formato RTCM (binario) a un archivo de texto, permitiendo observar la información disponible en cada uno de los mensajes.
Según las normativas del formato RTCM versión 3.0, los mensajes 1005, 1006 y 1032 deben contener información de las coordenadas de la antena de referencia. Estas coordenadas deben ser cartesianas geocéntricas (Earth-Center-Earth-Fixed) referidas al punto de referencia de la antena (ARP). No deben referir al centro de fase, ya que este no es un punto fijo en el espacio y no puede ser indicado en la antena. El centro de fase cambia con la frecuencia y en especial para L1, se modifica según el método elegido para calibración de la antena. El mensaje 1006, a diferencia del 1005, contiene además la altura de la antena (desde la monumentación al ARP). El mensaje 1032 contiene la misma información que el 1005, pero se utiliza para las estaciones virtuales (VRS), cuando no hay una estación física [RTCM Special Committee No. 104, 2013].
Luego en el segmento del usuario, se evaluaron y observaron las diferentes aplicaciones que este utiliza para recibir las correcciones NTRIP. Estas aplicaciones cliente son variadas y pueden instalarse en computadoras, dispositivos móviles y actualmente, las controladoras de los receptores ya traen opciones NTRIP. Por lo tanto, se analizaron programas libres que el usuario utiliza en su PC, como el conocido BNC (BKG Ntrip Client), software desarrollado por la BKG, y su antecesor GNSS Internet Radio [http://igs.bkg.bund.de/ntrip/download]. Luego, aplicaciones pasibles de ser instaladas en teléfonos o dispositivos móviles como por ejemplo: MobileNtrip [www.mobilentrip.com] y LefebureNTRIP [http://lefebure.com]. Y finalmente, los programas instalados en las controladoras de los receptores comerciales RTK.
En todos los casos, los programas cliente NTRIP, son aplicaciones que gestionan la conexión del usuario con el Caster, para ello descargan la Sourcetable, y muestran la información contenida en cada una de las entradas STR de la tabla.

Influencia del Marco de Referencia en el posicionamiento RT-NTRIP
Se propuso conocer las ventajas y desventajas del posicionamiento RT frente a la vinculación a un determinado Sistema de Referencia, específicamente cuando se desea trabajar con estaciones GNSS pertenecientes a distintos países.
Para ello se planificó una experiencia de aplicación en la zona litoral limítrofe Uruguay-Argentina, utilizando correcciones diferenciales de una misma estación Server, en tres marcos de referencia distintos.
Se utilizó la estación uruguaya UYSO, ubicada en la ciudad de Mercedes, departamento de Soriano, como base del posicionamiento, por ser la más cercana a la zona de estudio (fig.1).

Figura 1: Zona de relevamiento
Figure 1: Survey area

En el caster del Servicio Geográfico Militar (SGM) de Uruguay, se encuentra disponible el stream UYSO-RTCM-V3, el cual transmite observables y correcciones de la estación elegida. Este fue el stream base de la experiencia. A partir del mismo se trabajó con el software Leica GNSS Spider para crear tres nuevos sitios, tomando el stream de UYSO antes mencionado, y modificando las coordenadas de referencia en las siguientes tres opciones:
1- coordenadas ROU98, marco de referencia oficial de Uruguay.
2- coordenadas POSGAR2007 marco de referencia oficial de Argentina, y
3- coordenadas de la solución semanal SIRGAS 1741(la última solución disponible al momento de generar la corrección).
Se indicó además el tipo de receptor (Trimble Net RS) y la antena (TRN 55971.00), para los tres casos.
Una vez disponibles los tres nuevos streams se constató en el software GNSS Surfer que efectivamente se estuviesen transmitiendo las coordenadas correspondientes en cada flujo de datos, para ello se decodificó el mensaje 1005.
Los tres streams se publicaron en el caster escuela de SIRGAS que funciona en la Facultad de Ingeniería, Universidad de la República (UdelaR), Montevideo, Uruguay. Los Mountpoint se nombraron de manera tal de identificarlos según el marco de referencia.
Una vez disponibles las tres correcciones, se planificó una campaña de medición con un receptor RTK doble frecuencia (Leica GS08). La medición se realizó en Las Cañas, poblado cercano a la ciudad uruguaya de Fray Bentos. Se midió en 3 sesiones, una con cada Mountpoint (tabla 1). Se grabaron 120 épocas en cada sesión, a intervalos de 60 segundos. Simultáneamente se grabaron los observables correspondientes para realizar luego el procesamiento diferencial de dichos datos y utilizarlos para control.

Tabla 1: Configuración de sesiones.
Table 1: Sessions configuration.

Terminada la campaña se realizaron en gabinete 3 pos-procesamientos, uno con cada Marco de Referencia. Se descargaron los datos de medición RINEX de la estación base UYSO correspondientes al día de medición (día GPS 181 del año 2013) del sitio ftp del SGM. Se trabajó con un software comercial (Leica GeoOffice), procesando el vector UYSO-CAÑAS con tres grupos de coordenadas de control diferentes (una referida a cada uno de los 3 marcos). De esta forma se obtuvieron tres juegos de coordenadas para la estación CAÑAS, en los tres marcos nombrados (tabla 2). Finalmente, las posiciones obtenidas en la campaña de tiempo real se compararon con la coordenada pos-procesada vinculada a la solución SIRGAS de la semana 1741.

Tabla 2: Coordenadas pos-procesadas de la base del relevamiento CAÑAS.
Table 2: CAÑAS post-processed coordinates.

RESULTADOS Y DISCUSIÓN

Publicidad del Marco de Referencia en los servicios RT de la región
Del análisis de la información ofrecida por los servicios de posicionamiento diferencial RT en Argentina, Brasil y Uruguay, se constató que la publicidad del marco y la época de referencia no es explícita en todos los casos.
Luego de una búsqueda bibliográfica, y de consultas a los administradores, se pudo determinar que las correcciones que cada servicio transmite se encuentran en el marco de referencia oficial de cada país, pero las coordenadas de las estaciones Server no han sido actualizadas, es decir están en la época original del marco respectivo (tabla 3).

Tabla 3: Servicios de Posicionamiento RT en Sudamérica.
Table 3: RT Positioning Services in South America.

Respecto a los usuarios se constató que estos no acceden al conocimiento del marco de referencia en el momento de efectuar la medición. La información ofrecida al momento de elegir un determinado stream solo contiene el nombre de la estación y en algunos casos la versión del formato RTCM en que se transmiten los datos. Todos los programas analizados leen la Sourcetable publicada por los Caster, y muestran al usuario solo el Mountpoint (nombre indentificatorio del stream). Este nombre por lo general contiene 4 dígitos que identifican a la estación permanente (server) y luego poseen alguna descripción de la versión del formato RTCM que están utilizando. Por ejemplo dos Mountpoint para la estación mendocina MZAC son: MZAC-v3.0 y MZAC-v2.3, que demuestran lo detallado. Sin embargo no hacen mención al marco ni a la época a la que refieren las coordenadas con las cuales se han calculado las correcciones transmitidas.
Como última instancia se estudió el contenido del campo "STR" de la Sourcetable y como se observa en la tabla 4, existe un campo para especificar las coordenadas que utiliza la estación, pero al estar estas expresadas hasta la centésima de grado, resultan muy aproximadas como para poder identificar la época y el marco de referencia de las mismas.

Tabla 4: Detalle de los campos STR en la Sourcetable.
Table 4: Sourcetable datails for STR fields.

La Publicidad del Marco de Referencia en los servicios RT de Europa
Se realizó un análisis respecto de esta situación en servicios más consolidados como el europeo EUREF-IP [http://www.epncb.oma.be/euref_IP/]. En su página web, existen guías [Bruyninx, 2013] de cómo deben ser configuradas las estaciones y los requisitos que estas deben cumplir para poder ser parte de la red de estaciones permanentes (EPN). Se especifica que las coordenadas a utilizar en los streams deben ser consistentes con el Sistema de Referencia Terrestre Europeo ETRF89, actualizadas anualmente y publicadas por el centro de control. Se aclara específicamente también que si las coordenadas estuviesen en otro marco de referencia, esto debe ser debidamente informado en la Sourcetable del Caster. Respecto a la nomenclatura de los streams (Mountpoint) está compuesta por cuatro dígitos que identifican a la estación y un número entero que indica el formato del mensaje. Pudiendo tratarse de datos crudos en formato propietario o RTCM en sus distintas versiones.

Una propuesta para hacer visible el Marco de referencia al usuario RT
A partir del análisis realizado se recomienda que los servicios RT de América Latina:
Publiquen en los sitios web de cada servicio, de forma clara y explícita el Marco de Referencia y la época a la que refieren las coordenadas de las estaciones server, que resulta ser la que el usuario utilizará como base de su posicionamiento. De igual manera se recomienda que esta información esté contenida y publicada en la Sourcetable de cada Caster, por lo tanto estos deberían configurarse de manera tal que en los campos CAS y/o NET se especifique el Marco y la época de Referencia en que se transmiten las correcciones.
Por otro lado, podría utilizarse como en los servicios europeos la nomenclatura del Mountpoint de un dígito para identificar la versión RTCM (de manera más breve) y sumar a este algunos caracteres identificadores del Marco de Referencia. De esta manera el usuario podría conocer, al momento de elegir un stream, la versión del formato RTCM y el marco de referencia en el que obtendrá su posición. En la tabla 5 se aprecia que con una cantidad de dígitos permitida, los usuarios RT podrían identificar en el momento de seleccionar la estación server para la medición, no solo la versión del mensaje RTCM sino con seguridad el marco de referencia implícito en el mismo.

Tabla 5: Sugerencias para nomenclatura de Mountpoints.
Table 5: Suggestions for streams' names (Mountpoints).

Respecto a los Server, según las recomendaciones internacionales las coordenadas utilizadas y transmitidas en el mensaje RTCM, deberían ser consistentes con el ITRF y deberían actualizarse al menos una vez al año.
Debido a que en los países de la región, los marcos oficiales permanecen sin actualizarse por períodos prolongados, se recomienda publicar en los diferentes servicios nacionales dos streams por estación. Uno referido al marco oficial y otro referido al ITRF, lo más actualizado posible. Para este último caso podrían utilizarse las coordenadas SIRGAS semanales o la última realización multianual.

Influencia del Marco de Referencia en la precisión y exactitud del posicionamiento RT
En la experiencia realizada en Las Cañas, se pudo observar que efectivamente la utilización de uno u otro marco en las coordenadas de la estación server UYSO, influye en la exactitud de las coordenadas finales del usuario. Se calcularon las diferencias entre las posiciones RT obtenidas respecto a la coordenada de control del sitio (vinculada a la solución semanal SIRGAS 1741, correspondiente a la semana de la observación). Dichos resultados se validaron al comparar las diferencias obtenidas en los procesamientos del vector UYSO- CAÑAS con los 3 marcos nombrados.

Posicionamiento RTK-NTRIP
Se analizaron los residuos Norte, Este y Vertical, comparando las tres sesiones (tabla 1). Los mayores residuos se observan en la sesión 1 referidos al marco ROU98, alcanzando 20 cm de diferencia en la coordenada Norte (fig.2). En la componente Este, se observan diferencias medias menores a 5 cm en las primeras 2 sesiones (fig. 2).

Figura 2: Residuos Norte y Este del Posicionamiento RT (respecto a coordenadas de control)
Figure 2: North and East residuals of RT Positioning (with respect to control coordinates)

En la sesión 2 se observan residuos (fig. 2, "a" y "b") que superan los valores medios. Los mismos corresponden a observaciones posteriores a cortes del servicio. Puede haberse debido a problemas en alguna de las estaciones de la red, o a inconvenientes en el servicio de Internet tanto en el servidor Caster como en el receptor remoto. En la sesión 3 con el stream transmitiendo en el marco de SIRGAS (marco de la coordenada control), se obtienen residuos significativamente menores, ofreciendo una exactitud de 2 cm en ambas componentes.
En los residuos de altura, no se aprecian diferencias entre las tres sesiones (fig. 3). Observándose un error medio de 12 cm y una desviación estándar de 3 cm, esto acuerda con resultados de otros autores [Mackern et al., 2009] en que la precisión en altura es entre dos y tres veces peor que la planimétrica. Esta imprecisión es superior a la influencia de los tres marcos de referencia analizados sobre el posicionamiento altimétrico.

Figura 3: Residuos en la Vertical del Posicionamiento RT (respecto a coordenada de control)
Figure 3: Vertical residuals of RT Positioning (with respect to control coordinates).

Posicionamiento diferencial convencional con pos-procesamiento
La tabla 6 muestra las discrepancias encontradas entre los tres marcos de referencia. Se contrastaron los marcos nacionales respecto a la solución semanal SIRGAS 1741 (SIR-PGAR07 y SIR-ROU98) y luego se compararon ambos marcos entre sí (ROU98- PGAR07).

Tabla 6: Residuos medios entre diferentes marcos de referencia (coordenadas procesadas)
Table 6: Mean residuals between different reference frames (processed coordinates)

Nuevamente la mayor diferencia se observa en la coordenada Norte referida a ROU98 respecto a SIRGAS. De igual modo en POSGAR07 la mayor diferencia se encuentra en la misma componente, pero en menor magnitud (7 cm). En la componente Este las diferencias medias para ambos marcos rondan los 3 cm, mientras que en altura las diferencias son mayores a 1 cm.
Comparando entre sí los 2 marcos nacionales, se vuelve a observar una gran diferencia hacia el norte, y un mayor incremento en las diferencias de altura.
Partiendo de que las coordenadas se encontraban referidas a distintas épocas, se procedió a calcular las velocidades de UYSO. Para ello se utilizó el modelo VEMOS2009 [Drewes y Heidbach, 2012], ya que todavía no se dispone de velocidades geodésicas para esa estación.
A partir de los valores calculados, se pueden explicar los considerables desplazamientos en la coordenada Norte, ya que se observa una velocidad en la latitud mayor a un centímetro por año (tabla 7).

Tabla 7: Velocidades de la estación UYSO [m/año].
Table 7: Velocities of UYSO reference station [m/year]

Lo cual nos lleva a pensar que la mayor parte de las diferencias encontradas es debida a la desactualización de las correspondientes coordenadas. Utilizar coordenadas desactualizadas (18 años para el caso del marco ROU98 y 7 años para POSGAR 2007), pueden introducir errores en la posición final del usuario de decenas de centímetros.

CONCLUSIONES

En la mayoría de los Caster-NTRIP de la región la información del marco de referencia no es publicada claramente, lo cual debe ser imperiosamente encaminado para asegurar el uso correcto de la técnica y sus aplicaciones.
Resulta fundamental la selección y adopción de las coordenadas de referencia en las estaciones NTRIP Server. Estas deben ser consistentes con el Marco de Referencia y época que se resuelva materializar a través de este servicio.
Considerando que un usuario solo accede, en el momento de medición, a una lista de Mountpoints, se concluye que estos deberían publicitar de alguna manera el Marco de Referencia en el que se está posicionando. De esta manera un usuario podrá seleccionar el stream adecuado a su necesidad.
En las aplicaciones RTK-NTRIP realizadas se alcanzaron las precisiones esperadas. En planimetría las diferencias medias respecto a una coordenada de control no superan los 2 cm. Sin embargo, la utilización de Marcos de Referencia desactualizados produce una pérdida en la exactitud de la coordenada final. Se observaron residuos medios de 20 cm respecto a la coordenada de control, evidenciando la falta de exactitud del método cuando se utilizan coordenadas muy desactualizadas.
Por lo tanto, si un usuario utiliza el servicio RT para aplicaciones topo-geodésicas, como replanteos, georreferenciación de parcelas, o cualquier otra aplicación topográfica que requiera precisión centimétrica (mejor que 5 cm), la actualización y adecuación de las coordenadas de las estaciones server resulta esencial y no puede perderse de vista. Existen muchas otras aplicaciones que no requieren tal nivel de precisión, cómo pueden ser las aplicaciones GIS, donde la falta de exactitud de las coordenadas resultantes puede no influir en el objetivo que persiguen las mismas, sin embargo el conocimiento del marco de referencia en el que se posicionará el usuario y la época de referencia resultan fundamentales para cualquier tipo de aplicación.
De igual modo, la utilización de la técnica DGPS (con receptores de código), que no ofrece precisiones mejores que 1 a 5 metros, no deja de ser un posicionamiento diferencial cuyo objetivo principal es conocer las coordenadas del receptor remoto (en este caso el navegador) en el marco de referencia y época de las coordenadas conocidas de la base (las estaciones server GNSS permanentes).
Frente al incremento de nuevos servicios nacionales de posicionamiento RT, se considera conveniente que utilicen coordenadas oficiales en las estaciones Server, siempre que estas estén actualizadas.
Dado que es posible utilizar estaciones Server provenientes de distintos países, los marcos nacionales deberían ser consistentes o bien re-publicar sus streams en algún marco de referencia regional que permitiese la interacción entre los servicios, sin pérdidas de exactitud y precisión.
Se recomienda utilizar un marco de referencia actualizado para todas las estaciones de la región, siendo una buena alternativa la última solución multianual SIRGAS disponible.

Agradecimientos

Especialmente al Ing. Agrimensor Roberto Perez Rodino, director del Instituto de Agrimensura (Fac. de Ingeniería, UdelaR), por posibilitar el intercambio y las tareas realizadas por los autores de esta publicación, como así también a la beca doctoral Tipo II otorgada por CONICET a la Ing. M. Fernanda Camisay. También se agradece al apoyo brindado por la Universidad Juan Agustín Maza, que desde 2010 ha financiando proyectos de investigación en la temática.

REFERENCIAS

1. Bruyninx, C. (2013). Guidelines for EPN Stations & Operational Centres. Disponible en http://www.epncb.oma.be/_documentation/guidelines/guidelines_station_operationalcentre.pdf         [ Links ]

2. Drewes H. and O. Heidbach (2012). The 2009 Horizontal Velocity Field for South America and the Caribbean. In: Kenyon S., M.C. Pacino, U. Marti (Eds.), "Geodesy for Planet Earth", IAG Symposia, 136: 657-664.         [ Links ]

3. Gebhard, H. and Weber, R. (2003). Networked Transport of RTCM via Internet Protocol, Design Protocol Software, BKG, Alemania.         [ Links ]

4. Mackern M. V., M.L. Mateo, A.M. Robin, A.C. Calori (2009). A Terrestrial Reference Frame (TRF), coordinates and velocities for South American stations: contributions to Central Andes geodynamics. Advances in Geosciences, 22, 181-184.         [ Links ]

5. RTCM Special Committee No. 104 (2004). RTCM Standard 10410.0 for Networked Transport of RTCM via Internet Protocol, Version 1.0. RTCM Paper 200-2004/SC104-STD.         [ Links ]

6. RTCM Special Committee No. 104. (2013). RTCM Standard 10403.2 for differential GNSS (Global Navigation Satellite Systems) Services - Version 3. RTCM Paper 104-2013-SC104-STD. Febrero, 2013.         [ Links ]

7. Weber, G., Gebhard, H. and Dettmering, D. (2003). Networked Transport of RTCM via Internet Protocol (NTRIP). Presentado en "A Window on the Future of Geodesy", IAG General Assembly, Sapporo, Japan.         [ Links ]

8. Weber G., D. Dettmering, H. Gebhard, R. Kalafus (2005). Networked Transport of RTCM via Internet Protocol (Ntrip) -Streaming for Real-Time GNSS Applications. Proceedings of the 18th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2005), Long Beach, CA, September 2005, pp. 2243-2247.         [ Links ]

Recibido: 29-11-2013
Aceptado: 11-04-2014