My Google Summer of Code 2017 project. This is just development part. Intended GRASS GIS modules and final code will be at https://svn.osgeo.org/grass/grass-addons/
For SOS 2.0.0, OM 2.0 [1] is the (only) mandatory response format (see the corresponding doc from [2]). Although querying the response in this format could be a bit slower than querying it in some ad hoc server-depending format, every service must provide it and we will save time and memory needed to reformat the response into the JSON we are using currently (see this function).
For SOS 1.0.0, alas, there is no mandatory format. There is a default format (OM 1.0.0 [2]), but as it is not mandatory, there is no assurance that the service will provide that (even though I haven't seen any service not doing so so far).
Parsing all 2.0.0 requests in the OM 2.0 and all 1.0.0 requests in OM 1.0.0 would give us the chance to save some reformatting time, memory and drop one attribute from the modules (=> fewer parameters make it always more user-friendly). However, I'm not sure if it's fair to SOS 1.0.0. We also cannot keep the attribute with default value depending on the SOS version as the format name differs (text/xml;subtype="om/1.0.0" vs. http://www.opengis.net/om/2.0).
@ninsbl @lucadelu: Some opinions? Some ideas on how to handle it the best way?
For SOS 2.0.0, OM 2.0 [1] is the (only) mandatory response format (see the corresponding doc from [2]). Although querying the response in this format could be a bit slower than querying it in some ad hoc server-depending format, every service must provide it and we will save time and memory needed to reformat the response into the JSON we are using currently (see this function).
For SOS 1.0.0, alas, there is no mandatory format. There is a default format (OM 1.0.0 [2]), but as it is not mandatory, there is no assurance that the service will provide that (even though I haven't seen any service not doing so so far).
Parsing all 2.0.0 requests in the OM 2.0 and all 1.0.0 requests in OM 1.0.0 would give us the chance to save some reformatting time, memory and drop one attribute from the modules (=> fewer parameters make it always more user-friendly). However, I'm not sure if it's fair to SOS 1.0.0. We also cannot keep the attribute with default value depending on the SOS version as the format name differs (
text/xml;subtype="om/1.0.0"vs.http://www.opengis.net/om/2.0).@ninsbl @lucadelu: Some opinions? Some ideas on how to handle it the best way?
[1] http://schemas.opengis.net/om/2.0/observation.xsd
[2] https://www.ogc.org/standards/sos
[3] http://schemas.opengis.net/om/1.0.0/observation.xsd