Most CORS network operators do not like to publish their GPS observation data - let alone in real-time - or their analysis products such as clocks or troposphere delays. Many CORS networks have perfectly valid reasons for keeping their data private, such as security, or commercial interests.

The most accurate analysis that allows complete privacy of a CORS station (i.e. no outgoing data whatsoever) is Precise Point Positioning (PPP) on the basis of published reference orbits and clocks for the GPS constellation. This approach is typically accurate to about 1 cm in the horizontal direction, and 2 cm in the  vertical. If that is accurate enough for your station, GPSdancer is of no interest to you.

However - the trouble with PPP is that as a CORS operator, you are 100% responsible for updating your own analysis software every time that there is an update of the IERS conventions or some fancy new file format for your input orbits and clocks. Many operators always have this nagging feeling about their analysis: should we remove ANTEX corrections from those clock RINEX files or not? Have we really implemented those complex IERS conventions correctly, to ensure millimeter-level consistency with the IGS analysis centres in interpreting the polar motion data? The truth is that you can only know this for sure with some form of feedback between your regional CORS analysis and the formal International Terrestrial Reference Frame, as routinely realized by the IGS.

The best guarantee of modelling consistency is when your CORS stations are analyzed simultaneously with those IGS reference stations, using exactly the same models and conventions, because you literally use the same software (...different versions of the GPSdancer software cannot communicate with each other, by design). The internal consistency of your station coordinate time series can be accurately monitored: it is the noise on the baselines to all ITRF stations in the GPSdancer solution. The external consistency of the GPSdancer solution can be accurately monitored from the estimated ITRF station coordinates themselves, relative to the formal ITRF (straight line) solution. In other words: for the first time ever, a CORS operator can know the accuracy of his own ITRF station coordinates!

There is no way to join the GPdancer solution without interacting with the other GPSdancer processes in the global solution network. However, the input observation data and the output station products remain strictly private to the CORS station: no other GPSdancer instance (i.e. no other CORS station) has access to your station data. The exchanged information consists of normal equation information and some network housekeeping data, and even that data is not made accessible from a running GPSdancer instance (and remember, all running instances must be identical, or they won't communicate with each other).

Figure 1: data flows within the GPSdancer solution network


In the most general network layout, there are three communication flows in the GPSdancer system, as indicated in Figure 1:

  1. The input observation data flows from the CORS station to its on-line GPSdancer instance
  2. The GPSdancer instances mutually exchange information in order to perform a global solution process
  3. The CORS output products are transferred from the GPSdancer instance to a remote computer configured by the CORS operator

By far the largest communication flow is the second exchange, because it consists of global normal equation information in the square dance exchange process. The enormous advantage of running GPSdancer in the cloud (Figure 2) is that this largest dataflow disappears from the public internet, and takes place on the much faster internal network connections inside a single server park. On the public internet, GPSdancer never assumed to have faster communications than 2 Mbit/s. Within the server park of (e.g.) the Amazon EC2 cloud, an internal bandwidth of 10 Gbit/s is normal. Most importantly: such internal data traffic is free of charge to the user.


If the GPSdancer processes are collocated with the CORS station (...this was originally foreseen in the GPSdancer design) the first and third communication flow disappear completely. The large internal dataflow must now make use of the public internet, which probably limits the processing speed to running one solution per hour. Regarding privacy and security of their data, most CORS operators might intuitively prefer this layout, because the data or products do not travel at all over the public internet. However, this layout is only possible if the local firewall is almost completely switched off, because an individual GPSdancer process may have to communicate with an arbitrary set of other computers in the world that also run GPSdancer instances. The cloud-computing approach of Figure 2 does not have this problem: both the local CORS computer and its GPSdancer instance in the cloud can use a white-list firewall strategy, in which only these two computers are allowed to connect to each other. The GPSdancer instances within the cloud are collectively hiding behind such firewalls, which has no impact on their capability to talk to each other (within the server park). In other words: living together - yet separated - is by far the mot secure approach.

It is important to understand that no matter which layout is used, the privacy of individual CORS operators is guaranteed by design, because the input data and output products are never accessible to other GPSdancer instances. Only the normal equation data is exchanged between the processes, and some housekeeping data to maintain the network of interacting GPSdancer instances. None of this data can be reverse=engineered into CORS-dependent information, and none of this data is accessible to any of the CORS operators (or indeed, to the GPSdancer project itself).

Project details

Ultimate Browsers SupportThe GPS Dancer project started in 2007 as a voluntary project of a working group of the International Association of Geodesy.

Read more ...

Square dance algorithm

Great Docs and SupportThe GPS Dancer system was named after its "square dance" exchange algorithm. Of course, it also wants to to make the GPS reference frame denser.


Here, there be pirates

The Dancer on-line network became immune against internet connection problems by leaving the US marines, and becoming a pirate.

Read more ...

Go to top