SOS Services that serve WaterML2.0
CSIRO and 52North are working on adapting current SOS implementations to serve WaterML2
KISTERS implemented SOS with O&M1 and WML2 in their http://kiwis.kisters.de Web Interoperability Solution (KIWIS)
, as well as WaterOneFlow
, and other http based query services
Support for different RDBMS/storage layers
Open question 1:
what types of database schemas would people like to support? Currently the 52North schema is a light schema for transmitting O&M style data. Water-based databases (ODM, WISKI7, Hydstra etc.) could be supported.
Open question 2:
Architecture. The services will provide a subset of data from organisations. It would be best to use a staging server to hold the data relevant to the IE. It may be possible to do a translation in this case (e.g. WISKI to a 52North extended schema).
- 16 Jun 2010
*About open question 1
After the "Use Case 1" last week phone conference and email exchanges with Peter Taylor,
it appeared a feedback and discussions on the different solutions to adapt 52n-SOS to the SWIE might be necessary.
(for the record : http://external.opengis.org/twiki_public/bin/view/HydrologyDWG/EuroIETelco20100630
Different solutions that are offered (from my short experience):
- Fully adapt one's database to 52North SOS application
It's the short-term perfect solution for the SWIE, but not fully compliant with WML2.0/OMv2 requirements regarding the actual 52N's DB.
That implies fitting own database to 52N's.
In terms of coding, a unique mapping has to be conducted by modifying dssos.config file, skipping any "heavy" modification in the source code.
- Partially adapt one's database to 52N's by customizing DAO
It's our current choice at the SANDRE since we wanted to fit our OM-ised DB with the 52N-SOS application.
This solution implies adding to/deleting from SOS DB some tables (for example, we have added tables to simulate time-series) to fit more closely to O&M, plus modifying source code (especially, the PGSQL DAO for the time being)
From us, final result could be providing a way of customizing "as easily as possible" DB and DAO classes.
It's the mid-term solution, since following own schema, even if it's close to O&Mv2, might introduce delay for the "interoperability experiment".
- Adapt one's database to WML2.0 schema together with a specific WML2.0 Data Access Object
This solution requires mapping between own database and WML2 schema
It requires more development from the 52N/CSIRO, but may be more relevant if every part agree on using this schema.
We can consider this as the long-term solution.
- Peter Taylor wrote something about adapting WaterML2 to Object DB?
(IOW -SANDRE) - 08 Jul 2010