The computational effort involved with running a single Dancer peer is of the same order of magnitude as the effort for running an IGS Anlysis Centre. This is not because the Dancer software would be particularly inefficient (...on the contrary!), but Dancer was of course designed like that: the Dancer logo represents the substantial increase in computational power between conventional centralized GPS analysis and distributed processing with one computer per GPS receiver.

Network operators typically manage a network of many dozens, if not hundreds of permanent GPS stations. Consequently, these operators would have to deal with a processing workload that requires hundreds of computers, as well as a very substantial internet bandwidth (... about 200 MB per Dancer process per hour). Clearly, not many network operators have this kind of computer capacity.

The original design studies for Dancer foresaw running Dancer processes at the actual GPS stations, where the receiver is usually connected to a computer (in a rack) and in turn to the internet. In principle, this remains a possible layout, and it resembles most closely a future network of smart receivers. However, over the past five years or so, cloud computing has become so cheap and accessible, that it is now probably the most attractive way of running Dancer processes for your own receivers.

Many commercial cloud computing providers exist. In fact, most internet providers are becoming cloud computing providers, and most websites (such as this one) run on a virtual computer inside a server park of some cloud computing centre. The large scale at which cloud computing providers can operate makes their facilities highly efficient, and the continuous monitoring of such server parks makes them highly reliable.

Running a GPS Dancer instance "in the cloud" costs roughly one US dollar per day (prices vary between providers, but not by much). So, if you operate a network of 100 GPS stations you pay around 3000 dollars per month, or 36500 dollars per year for analyzing all your GPS data with Dancer in the cloud. Is this expensive? Actually, it is much cheaper than today's analysis centres. An analysis centre requires a few computers, a few people (probably part-time, but still...), a room to put the computers in, electricity, heating or cooling, internet bandwidth, insurance, management... It would be completely impossible to do all that for just 36500 US dollars. In other words, the Dancer approach is not just much more powerful than centralized analysis at an Analysis Centre, but it is also a lot cheaper. As we live in a world that is mainly driven by cost arguments, the GPS Dancer system is remarkably competitive.

Another reason for running Dancer in the cloud is formed by the omni-present corporate firewalls. Most firewalls today do not allow you to make tcp connections to external computers, unless these are registered in the firewall settings. For Dancer, this is no good: it is impossible to know which computers you will have to talk to, and it is impossible to maintain a global list of all computers in the world that run GPS Dancer. An alternative is to run a proxy outside your firewall, or to run a JXTA relay peer outside your firewall. Both solutions require renting of some external server, in which case you might as well just run all your Dancer processes outside your firewall.

You can set-up and monitor your own GPS Dancer processes in the cloud, but you would have to launch a separate process for each receiver, and download the results from each peer. A facility like a web-portal is currently being planned to make this interaction easier, so that as an operator you may go to one particular website where you can link your receivers to a single account in the cloud, and download analysis products from that same account. Obviously you will get a legally binding non-disclosure agreement to ensure that nobody else has access to your data or products. Dancer is not interested in your input data or output products. It is only interested in the lumb-sum vector averages that you will form with other Dancer computers within the square dance exchange algorithm. This web-portal would pass the actual cost of launching individual Dancer processes in the cloud to the user, which is why the GGGF foundation is not legally allowed to offer this service directly. A clever way of making this nonetheless possible is being studied between ESA and the GPS Dancer project. Please check back soon to follow these developments.

The short-term objective is to raise funding that will allow the GPS Dancer project to launch Dancer processes in the cloud for all 450 ITRF reference statioins. This is called the ITRF backbone of the Dancer network. Any further Dancer process that joins the global Dancer network - either from a permanent site, or from an incidental geodetic user - will then obtains direct baselines to all ITRF stations, with proper estimation sigmas to indicate the solution accuracy. In other words: GPS Dancer provides direct access to the ITRF in the cloud, no matter where you are, as long as you have an internet connection.






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