Extending sensor description content filter capabilities

[jruizaranguren]

If I'm not missing something, available filtering capabilities for getObservations include procedure, offering, observedProperty, featureOfInterest and spatial and temporal filters.

According with the standard it could be possible to include more filters following OGC 09-026r1/ISO 19143.

I would be interested in adding more filters related to SensorML metadata related to the observations (value filtering may suffice to start).

Is there an easy way (happy path) to extend 52North/Sos in order to get additional filters? Do you see any benefit in adding this or you think this is out of scope here?

[nuest]

Just to clarify: do you mean filtering within the DescribeSensor operation?

[CarstenHollmann]

The SWE Service Model Implementation Standard (SWES) defines the "SWES Extensions Points" (chapter 18) which allows to add further parameter/information to the requests/responses. The SOS 2.0 requests/responses are based on SWES and thus they contain these extension.

The 52°North SOS uses the "SWES Extensions Points" for observation splitting/merging.

[jruizaranguren]

@nuest, I have changed mi mind, thanks to UpdateSensorDescription, filtering DescribeSensor may suffice for my use case.

@CarstenHollmann, SWES Extensions Points sound great.

Reformulation: how to add SWE Extension which allows filtering Procedures by their description, by applying XQuery queries to SensorML descriptions. Ideally this filter could be applied to DescribeSensor, GetObservations and GetResults, although in a first iteration to DescribeSensor may suffice.

Do you think more people will think this extension is useful? (I mean, something that would enhance 52North/Sos features).

I have dived in code, and it seems that adding a filter requires modifying a bunch of files. Could you please briefly point me to which files, or group of files I should take into account?

[nuest]

Could be interesting. Would you be willing to contribute this feature back to the codebase?

[jruizaranguren]

Yes, that's the idea. But I (or we) would need some help to jump fast into your code in order to choose the best approach. Could you from your experience roughly estimate how much could take to develop this?

[CarstenHollmann]

The SOS internal representation of SWE Extension is defined in this package. And in the AbstractServiceRequest you can set the decoded internal representation of the SWE Extension to the request.

What needs to be done is to expand the decoder(XML, JSON, KVP ), if necessary, to support the new filters and implement a SweExtension for the internal representation. If the SweExtension is set in the AbstractServiceRequest, you can use the extension wherever the request is present.

To apply the filter on the XML representation of the procedure description, you have to extend the DescribeSensorDAO

The following should be noted for the implemenation:

• The implementation should be procedurDescriptionFormat independently
• The implementation should be database/datasource independently, if possible.
• The XML representation of the procedure can be stored in different places, in the validProcedureTime table, in the procedure table, in a file whose link is stored in the procedure table.
• No XML representation is available and the SOS generates the procedure description.