Sensor Instance Registry
Discussion Paper
The Sensor Instance Registry (SIR) is a web service interface for managing sensor catalogues. It is based on the
OGC discussion paper 10-171 (
Download at OGC) and
09-163r2 (
SensorML discovery profile,
https://portal.opengeospatial.org/files/?artifact_id=37944) and presents a quite pragmatic solution that may serve as the basis for further discussion and development. The paper contains extensive descriptions of the service operations (requests and responses) for GET and POST requests.
Schemata
The schemas (one file for each operation) are available online for validation at
http://52north.org/schema/sir/. You can use these schemas for direct validation by including the root schema document into the XML documents, i.e.
xsi:schemaLocation="http://52north.org/sir/0.3.2 http://52north.org/schema/sir/0.3.2/sirAll.xsd"
.
For development, the schema files are located in the common XML project in a module
52n-xml-sir-v032 on GitHub at
https://github.com/52North/common-xml/tree/master/52n-xml-sir-v032. XSD files are located in the folder
/src/main/xsd/sir//. The common XML project is used to build XMLBeans libraries for the schemas, which can be downloaded from the 52°North Maven repository, see
http://52north.org/maven/repo/snapshots/org/n52/sensorweb/52n-xml-sir-v032/1.1.6-SNAPSHOT/. They can be added to your own Java project with Maven (here with a snapshort version as an example):
<dependency>
<groupId>org.n52.sensorweb</groupId>
<artifactId>52n-xml-sir-v032</artifactId>
<version>1.1.6-SNAPSHOT</version>
</dependency>
Notes about SIR Specification
- OWS Interface
- Exploit more features of OWS common (e.g. the update sequence parameter)
- The sir:Contents section should be extended
- The element name HarvestedService is misleading, as all (indirectly via Sensor descriptions) inserted services are listed there as well!
- Make the SIR usable in many application by defnining mappings to very common formats, e.g. output conform to W3C POI
- Abstract data model
- JSON binding * Add the concept of a "sensor network" to the SIR, which can take many shapes (network of networks - hierarchies?). This could also be too much unless it can be derived automatically (e.g. IOOS sensor networks, which use procedures/offerings for the whole network). -- DanielNuest - 2012-10-26
- Move to SensorML 2.0 asap - it's the better standard.
- Discuss versioning in the specification, it's very important and could be more explicit/easier to use than the validTime element if it is a feature of the API
- Define multi-language features, i.e. multiple documents for the same sensor, using the HTTP Accept-Language header for retrieval - and what for insertion?
Notes about Discovery Profile
Some notes on the discovery profile and the SIR specification for future work:
- Why does the Envelope not have a referenceFrame attribute? In fact, the Envelope is completely undefinded, should be fixed. For example, the SRS name is strictly needed when using GML output.
- Do not allow spatial reference frame (see ifgi HWS).
SIR Software
All software development under the name "SIR" / "Sensor Instance Registry" is continued in OpenSensorSearch.
In OSS, the SIR definition provides a powerfull transactional interface for advanced application scenarios. The old implementation's binary releases are available in the 52°North downloads section:
http://52north.org/downloads/sensor-web/sir
Requirements
- JRE/JDK 1.6
- Apache Tomcat 6.0.xx
- PostreSQL Version 8.3.x
- PostGIS Version 1.5.x
- Apache Ant 1.8.x (if you want to build SIR yourself)
Naturally, newer versions should work as well and should be preferred.
Releases
- > 0.5
- 0.5.2
- 0.3.1
- 0.3.0
- First release of working implementation, status of the discussion paper.
Documentation and Installation Instructions
An extensive
documentation for users (installation instructions, troubleshooting, ...) is available in the Sir Tutorial
here.
Contributor documentation can be found on the page
SensorInstanceRegistryDevelopment.
SPS
For testing of the SPS harvesting, a simple mockup service was implemented at
http://giv-genesis.uni-muenster.de:8080/SpsMockup/. It serves
GetCapabilities requests via GET or POST and provides access to the sensor metadata documents linked in the capabilities file. You can download the
Eclipse project source and
deployable WAR archive.
Catalogue
The testing of the catalogue connection was done with an instance of
buddata (
http://code.google.com/p/buddata-ebxml-registry/). Buddata ebXML Registry/Repository is an open source implementation of the
OASIS ebXML Registry and
OGC Catalogue Service.
You can download a zip-file with an Eclipse project here:
ErgoRR-Eclipse-project.zip.
An installation guide and
download of an installer is possible on the project website and an installation of the newest version is recommended.
The test server is available at
http://giv-genesis.uni-muenster.de:8080/ergorr/.
Some useful requests are:
Some notes on the service:
- The GetRepositoryItem looks for files in the repository folder (repository.root can be set in the file ergorr.properties) and cannot be used to query elements from the database. Use GetRecordById instead for database-based storage.
- If the database should be reset without deploying the service again, you can use the files
database.sql
and init-data.sql
(from the Eclipse project folder /ErgoRR/ErgoRR-persistence/src/main/config/
), but problems were sometimes encountered due to missing tables in the drop statements - please take a good look at the output of the SQL calls!
Data
The simple test set-up consists of harvesting
WeatherSOS (
http://v-swe.uni-muenster.de:8080/WeatherSOS/) and the
SpsMockup service (
http://giv-genesis.uni-muenster.de:8080/SpsMockup/).
More data can be generated using the test data generator from the package
org.n52.sir.util.testData
. The main method including examples can be found in the class
GeneratorClient.java
.