The Earth Data Network
Considering the rapidly emerging new capabilities in global communication and networking, it makes sense to approach observation networks from a completely novel point of view. This would be in parallel to the necessary developments that use currently available concepts and approaches and improve these. One novel approach could be based on the assumption that we only have the Internet and the Web to link sensors to users and applications. In this situation, a viable concept is shown in Figure 1, which illustrates the generic connection between one station with n sensors to one application site with multiple users and applications. In this generic and universally applicable concept, the sensors at a station are connected to a computer, which runs a web server. The data are inserted in a local archive. Processing to produce data products out of the observations can be done locally. The web server on the station site can provide a number of services. Each sensor has its own URL, which is the unique identification of this sensor and, in combination with additional identifications, of all derived data products and associated services. For a future implementation, it would be valuable to have a top domain, e.g. “.eos”, or “.sen” to separate all sensor URLs clearly from all other URLs.
Figure 1: Sketch of the basic elements in a web-based network of observing sites, applications, and users.
An example of how the URLs could be used to uniquely identify sensors, products and services is the following. Of course, this is very preliminary and needs to be thought through in more detail. Let us assume we have a station identified by “example” with two GPS sensors (gnss), a temperature sensor (temp), a wind sensor (wind), a air pressure sensor (airp), a superconducting gravimeter (crgr), and an accelerometer (stron). Since we do not have the “.eos” top domain, we can use, e.g., “eodata.org” as the main domain. The station We would establish the following sub-domains:
www.example.usny.s1.gnss.eodata.org
www.example.usny.s2.gnss.eodata.org
www.example.usny.s1.temp.eodata.org
www.example.usny.s1.wind.eodata.org
www.example.usny.s1.crgr.eodata.org
www.example.usny.s1.stron.eodata.org
which would identify the sensors. Using a browser to access, e.g., http://www.example.usny.s1.gnss.eodata.org, would give access to a standardized web page for this sensor. A number of standardized services could be added to access the following:
/metadata: full meta information for the sensor,
/rtdata: a Real time data stream based on standard html protocols;
/archive: access to the local data archive.
The concept could easily be extended to have a number of additional standardized services associated with each sensor.
Using a similar concept to the update or adding of software to, e.g., Ubuntu, the adding of a new sensor to a station could be extremely simplified. Any new sensor would be more or less immediately available globally with all desired services.
On the user side, a human user could use a web browser to access any of the above sensors and products. A machine client could communicate with the user-side web server using, e.g., python, to access the sensor and any associated service through standard html protocols. Products received could be inserted into data archives or fed into applications. Identification of datasets would continue to be based on the URL of the sensor and/or product.
Searches for sensors would be extremely efficient, and could easily be constraint to geographical areas, sensor types, time intervals, etc.
We are developing the above concept to the state of a pilot project. We believe, RT and LL GPS would be an excellent case to develop the concept. We also consider the Group on Earth Observations (GEO) to be strong enough to get the top domain “.eos” or something similar accepted.
|