Reference Architecture
The basic infrastructure consists of two components:
The DVB Technisat software (transponder manager etc) and the Tellicast Client (decoder/license manager) on the groundstation (1) are responsible for receiving, decoding and serializing the geonetcast data-stream. The serialized stream (mainly fragmented, packed, raw data) is stored in a local folder on the hard drive. Since peaks in disk and bus usage could interrupt the DVB data reception, the groundstation (1) is only responsible for receiving and serializing the data stream. That means in particular no computational tasks should be performed on the groundstation. Therefore the groundstation is
encapsulated and only the incoming folder shared as a network drive with the data server (2) using a 1GBit lan connection.
More details regarding the system configuration and operational concept can be found on the
GroundStation site.
While the
GroundStation is only in charge for receiving data, the
DataServer is responsible for long-term data storage. The
DataManager, running continuously on the
DataServer, observes the incoming folder “GNC-GROUNDST\incoming” on the groundstaion and processes immediately the incoming serializations. This means, the data is moved (not copied), unpacked and distributed to the local folders of the
DataServer. In cases where the network connection to groundstation is interrupted or the data-server itself is down, the serialized data will be buffered on the
GroundStation (up to several weeks). Afterwards the
DataManager will continue, so no data will be lost. The stored data can be accessed with reading rights by applications/clients through a shared network folder “\\GNC-Data\Geonetcast”. This network folder will serve as the central (and exclusive) access point for interfaces or third party services. Due license restrictions the data can only accessed in the internal university network and by using university account authentication. By modifying the configuration of the
DataManager, it is possible to define:
- which products have to be processed
- where & by which naming convention the products have to be stored and
- how long they have to be stored on the data server.
More details regarding the system configuration and operational concept can be found on the
DataServer site.
Standardized Web Interfaces
To serve geodata on the web, standardized interfaces are required to enable a customized access. Web Service interfaces as specified by the Open Geospatial Consortium (OGC)
are highly applicable to serve geodata in a structured way and the portrayal of it.
Interfaces for serving Vector Data
Example Instance:
FireWebService
Interfaces for serving Raster Data
To serve coverage data on the web the Web Coverage Service (WCS) has been specified by the OGC. It allows users to query coverage data and especially grid data regarding
multiple aspects (space, time and channel).
We decided to use Mapserver for serving the data through
StandardizedCoverageInterfaces.
List of running service instances:
- MsgHritInterface - serves Meteosat Second Generation data (MSG) for meteorological analysis
Up to now WCS Interfaces are only rarely supported by common GI systems. We collected a small list of
ExistingWcsClients
Maintainance
We suggest three different roles of "Administrators":
- (technical) Infrastructure Administrators - responsible for operating system setup/configuration, security updates, restarts, user rightmanagement
- Product Administrators - responsible for specific software configuration e.g. activation of certain products, storage duration, storage location
- Service/Interface Administrators- responsible for specific configuration of the interface services
Materials & Links
1.
http://www.itc.nl/PDF/Organisation/Scientific%20departments/WRS/ILWIS_GEONETCAST_first_stepsinstructions.pdf
2.
http://www.itc.nl/PDF/Organisation/Scientific departments/WRS/geonetcast_toolboxMay2009.pdf
3.
http://www.itc.nl/Pub/WRS/WRS-GEONETCast/GEONETCast-Getting-started.htm
Open Issues
--
JohannesTrame - 2010-09-23