we use the "observation parameter" feature of the SOS specification to transmit and maintan some metadata of the single observation.
As for the observation, the DB stores (v.4.4.0) parameters using a main table (parameters) to mantain the parameter's id, the parameter's name and its relation with the observation and some linked tables to store the actual value of the parameter depending on its data type (countparametervalue, booleanparametervalue, categoryparametervalue....).
But if for the observation's result, the type of the observation is available inside the DB schema (the observationtype table and its relation with offering and constellation), for the parameter type it seems that this information is available only inside the payload of the InsertObservation when inserting data into the DB or in the SensorML for the GetObservation.
So it seems that it can't be really performing either to check if the parameters are of the correct declared type during insertion or to retrieve data in the right *parametervalue table during the Getobservation.
the om:parameter are inserted into the database as they are defined in
the OM_Observation of the InsertObservation request. If the value is a
swe:Category it would be inserted into the categoryparametervalue,
swe:Boolean into the booleanparametervalue, ... .
In the OM_Observation of the GetObservation response the
categoryparametervalue is encoded as swe:Category, ... .
Other parameter types are not yet supported by the 52N SOS, so a type
check is not required.
Parameters which are defined in the procedure description (e.g.
SensorML) of the InsertSensor request are not considered by the 52N SOS.