52North SOS Server for NGMP

52North SOS Server for NGMP

As I recently wrote about the three major work packages (Boiling it down), I mentoined the publishing of groundwater measurements from a legacy DB. Actually it is the GGW database (GNS Science Geothermal and Groundwater Database) which besides a lot of other stuff (geothermal data for Geothermal and volcanic monitoring, GeoNET), holds the data of the National Groundwater Monitoring Programme (NGMP). This is a governmental sponsored, freely accessible data set that holds groundwater measurements and analysis results (mostly quarterly or half-year basis). But this data can only be accessed via a web-frontend, where registered users can download pdf or excel reports including the meausred values over time.

My ambitious first pillar of the SMART data portal prototype is to consume and display data from the NGMP. Therefore I need to access the NGMP data (technically the GGW DB). And as we want to demonstrate useful SOS data usage, I need to put a SOS server on top of it!

In search for a proper way to serve NGMP data via SOS, I came across two major Open Source players, the 52North initiative, the ecosystem around OOSThethys and istSOS, from the Geomatics department is part of the Earth Science Institute (IST) at the University of Applied Sciences of the South Switzerlad (SUPSI).

http://52north.org/communities/sensorweb/sos/
https://wiki.52north.org/bin/view/Sensornet/SensorObservationService

http://www.oostethys.org/
http://code.google.com/p/oostethys/

http://istgeo.ist.supsi.ch/software/istsos/
https://sites.google.com/site/istssosproject/

The 52North SOS server is written in Java and has a roburst architecture, which especially separates the data access from the main procesing modules, a so called Data Access Object design pattern. This seems very handy, as I needed to access a completely different database and data model. The OOSTethys project has several different packages in different programming languages with different levels of sophistication and the istSOS server is written python.

[todo: reasons for decision should be more documented :-) ]

I decided for the 52North software, it has a vibrant community that strives for a bigger integration pattern. They  are providing a broad OGC eb services solution portfolio and often tend have recent standards already (at least prototypically or in beta status) implemented. OGC recently approved SOS 2.0 specification and 52North already has began work to incorporate that (52North Blog).

"52n-sos-dao-oracle"

As the NGMP / GGW database unfortunately has no spatial extensions, the planned custom backend needs to be able to abstract / fake this functionality in the software itself, instead of using typical spatial DB extensions (e.g. Postgis geometry datatype and geometric functions, BBOX search, etc).

52North SOS data model (Source: 52North Wiki)

I started by copying the existing "52n-sos-dao-postgis" to "52n-sos-dao-oracle", included the ojdbc14.jar driver and adjusted the dssos.config and main pom.xml to build the new DAO, load the oracle db driver and connect to the oracle db.
That was "almost" easy, the server builds, connects to the db and dies, as the queries from the original Postgis DAO obviously don't work.

Now the heavy-duty data part, actually the really interesting part, begins...

As the GGW / NGMP data model ist based on the Australian National Groundwater Data Transfer Standard from July 1999 and has been modified to suite the demands of GNS Science's geothermal and groundwater data collection, the schema is huge and the model quite complex. After consultion with the DBAs on the side and the scientists on the other side, I got a feeling for the whole thing and started to find things via joining the right views and tables to respect necessary constraints.

Australian National Groundwater Data Transfer Standard (Release 1.0 July 1999)

Then I began to adjust the queries in the ConfigDAO and the DAOFactory to select the proper fields to make the server initialisation work. But to keep it simple for the beginning I concentrated on only one property out of several dozens with available data - water level.

The next big challenge is coming - geometry. The coordinates are in two columns related to the groundwater The spatial reference system is well-known (EPSG 27200, NZGD49 / New Zealand Map Grid) and the coordinates are in two columns. So I intend to use Geotools to build point features for the "groundwater features" that are supposed to be wells, spings and bores and make them availabe throughout the SOS internal data structure, just as the other (frequently updated items in CapabiltiesCache) list.

Good Luck :-)