CarstenHollmann

This results in to long waiting. The running version is does not use this.

InsertSensor vs UpdateSensorDescription ( vs UpdateSensor) operation

1

If the procedure description of an InsertSensor request is SensoML, the SOS check the description for flags (, e.g. insitu or mobile) which are stores in the database. But when...

Add an admin feature for managing inserted resultTemplates, similar to the procedure and observedProperty feature.

To update a resultTemplate the SOS should provide an UpdateResultTemplate operation. This should only work if only one resultTemplate exist for the combination of offering and observedProperty. If more resultTemplates...

Add support to enable phenomenontimestart, phenomenontimeend and resulttime to be null in the database and the response would contain a configurable nilReason (unknown or missing).

Write a JUnit test to get a quick fail during the build process if new settings are defined in iceland.

Merge procedure description of a type to the procedure description of the instance

1

If the SOS contains procedure descriptions of sensor types (which do not have observations) and sensor instances which are typeOf the sensor type, the SOS should merge the information from...

Insert components of SensorML System/PhysicalSystem as separate procedures

1

If an InsertSensor request conatins a SensorML System or PhysicalSystem with components, the SOS should insert these component as separate procedures. - as (hidden)child procedure of the parent offering -...

Check the inserted/updated sensor/procedure description for supported definitions/names. Especially for definitions/names which are used in modifier, e.g. coordinate names.

Currently, the 52°North SOS 4.x only supports the insertion of observations with a simple/single observedProperty in a SweDataArray obsrevation with SplitDataArray extension. But in the 52°North SOS 3.x and O&M...