Datastream Type.

[paulau]

The type of a variable is very important.

Example :
I create Datastream to save Temperatures. It should be double values. If someone saves some string value e g "abc" in my datastream,
I have a problem. It could also have a problem, and I really do have this problem, if someone saves me eg a string representation like "21.1" in my Datastream.

In STA, there is observationType property of a Datastream. Unfortunately, It is not obligatory Property(at least in Frost implementation). One can initialise Datastreaym with Observationtype "AbraCadabra".

Unusually, the Property is called "Observationtype", however, it is a property of the whole Datastream. so all observations. Would it not be more logical to call it DatastreamType? Otherwise would it be more Reasonable to allow Datastream with arbitrary Observationtypes, then the Observationtype should be really a property of Observation. Not of a datastream.

In STA there is Table 12 with all possible ObservationTypes. It is unclear to me, what should observationType be:

OM_Measurement
or
http://www.opengis.net/def/observationType/OGCOM/2.0/OM_Measurement

But, anyway, it would be good to check, what type of Observation, an client Application try to submitt into the Frost Database via RestAPI Request or MQTT Message. String or double.
It would be also nice to return Error, if "String" is submitted to double Datastream.

Would it be reasonable to save data in clean manner? So, if it is specified as double, then no URL or strings must be accepted?

Greetings.
Pavel

[hylkevds]

Indeed, currently FROST does not validate if the encoding of Observation fits the observationType in the Datastream. FROST also doesn't validate the observationType valuecode itself.

The spec states the that observationType valuecode should be the full url: https://docs.ogc.org/is/18-088/18-088.html#tab-value-codes-obstypes

In STA Version 2 this will change. The ObservationType will be removed and replaced with a resultType field that uses SWE-Common to exactly describe the result. This will allow much more flexibility and precision in the description of the result and obsolete MultiDatastream.

[paulau]

The spec states the that observationType valuecode should be the full url: https://docs.ogc.org/is/18-088/18-088.html#tab-value-codes-obstypes

Interesting!!!

1. Using "OM_Measurement" looks for me better as using some URL, however, using of word "double" would be even more clear.
   Using URL however would be possibly nice! Just klick on it and see, what does it mean. I have never seen, however, that this URL really works. At leat my browser returns Error:

Status
400
Message
The object with URI http://www.opengis.net/def/observationType/OGCOM/2.0/OM_Measurement is not of type skos:ConceptScheme, skos:Collection or skos:Concept and only these classes of object are understood by VocPrez

... and obsolete MultiDatastream.

There are only several basic types in Table 12. Multidatastream however supposes the usage of Custom Data. So I can decide how many and which columns and of which type, do I have in Multidatastream.

If, the Observation in future could be "custom" to obsolete MultiDatastream, then I can not imagine,, that I must define type of my records in some webpage, like www.opengis.net and then to use some URL, provided by www.opengis.net as value for "resultType".

Thank You.
Greetings.
P.

[hylkevds]

The URL http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement resolves for me, and redirects to http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement
You seem to be missing the - in OGC-OM

SWE-Common is a powerful schema definition for describing scientific result values.
How it will probably be used in STAv2 you can see in the early draft. It has some examples too.

[paulau]

Yes, Thank You. URL works now. I used really wrong URL(without '-').
:). I do not really understand however, the content of the URLS. One word "double" or "float" would be clear for me. The URL with a Schema with arrows etc seems unclear for me.
Also Type OM_Observation - so "any"! It could be potentially String with json. So could replace Multidatastream already in v1.

I was trying other URLs in https://docs.ogc.org/is/18-088/18-088.html and they did not work. For example like this one:

http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel

Now, all(or at least many) different URLs redirect to the main URL of the Dokument. Possibly, it was a reason, why I thought, that also ObservationType URL did not work.

Regarding SWE-Common, Yes. If it will not be URL anymore and the type of record - described using some tool, like SWE-Common, then Yes, Multidatastream could be eliminated from STA.

Thank You.