RangeType encoding

[KathiSchleidt]

The encoding of the Coverage RangeType is defined at a very abstract level, utilizing the RecordType defined in OGC SWE Common.

SWE Common RecordType is in turn an implementation of ISO-11404 Record datatype. This allows grouping (sequence) of data components which can themselves be simple types, records, arrays or choices. While the syntax is well defined, how to encode the semantics of different domains has not been well reflected upon; the current examples are exceedingly technocratic, stipulating the quantity definition in a very generic manner as http://www.opengis.net/def/dataType/OGC/0/float32 with a UoM code of 10^0.

Upon reflection of both the data model and the requirements ensuing from elevation coverages, the following approach has been proposed, allowing for provision of both the vertical CRS (EPSG::9390) as well as the UoM for the vertical component:

<gmlcov:rangeType>
    <swe:DataRecord>
        <swe:field name="Elevation">
            <swe:Quantity definition="EPSG::9390" axisID="Z">
                <swe:label>Elevation</swe:label>
                <swe:description>EVRF2019 mean-tide height - EPSG:9390</swe:description>
                <swe:nilValues>
                    <swe:NilValues>
                        <swe:nilValue reason="">1000000.0</swe:nilValue>
                    </swe:NilValues>
                </swe:nilValues>
                <swe:uom code="m"/>
            </swe:Quantity>
        </swe:field>
    </swe:DataRecord>
</gmlcov:rangeType>

However, this option is not yet available from existing WCS servers, hopefully soon.

[pebau]

@KathiSchleidt : first, I claim myself guilty for the awesome "10^0" - when we had to define uoms in coverages (~2011) the SWE experts just shrugged shoulders, and so I ended up suggesting UCUM for the syntax and semantics of "uom". In UCM, "10^0" simply means "1" meaning: no physically related unit. Of course this should not be used when there are physical units indeed (such as "Watt per square meters" for optical data), but seems like everybody just copied the magic string ever since and nobody cares about the uom attribute anyway :) Recently discussion on uom has started again in OGC:

Action: @ghobona to prepare a draft PR on the policy document, after discussing CURIEs with @rob-metalinkage .

I was always hoping that the experts in the field would come up with clear guidance, but that did not happen. Maybe now is the right time. CURIE seems to be the fad of today, superseding UCUM. Maybe not a big issue because I am not aware that anybody has interpreted uom yet.

I like your proposal above:

• in Quantity, the uom attribute keeps to contain a data type = backwards compatibility (and useful information anyway)
• relevant information is added.

CAVEAT: the EPSG:xxxx syntax you suggest I have suggested as well (implementation evidence by GDAL, ESRI) but OGC-NA went a slightly different way, see https://github.com/opengeospatial/NamingAuthority/issues/92 .

[pebau]

PS: note that the abovementioned action is in its infancy, I have not seen much progress. So not sure we want to codify this at the moment, maybe we continue using good old URIs and anticipate an additional syntax option?

[KathiSchleidt]

UoM: where is the note pertaining to CURIEs from?

While I know that UCUM seems to be being superseded by QUDT, I'm not aware of a UoM System named CURIE (google couldn't find anything either. Could it be that this discussion was on how to represent the Unit Curie?

CRS Syntax: I used "EPSG::9390" for brevity as I remember it having been valid at some time in some context, have no issues replacing with a full URI, whereby I'm currently challenged by the question of which URIs are definitive? Following options:

• http://www.opengis.net/def/crs/EPSG/0/9390
• https://epsg.org/crs_9390/EVRF2019-mean-tide-height.html

epsg.io doesn't yet provide 9390

suggestions?

[pebau]

UoM: where is the note pertaining to CURIEs from?

https://github.com/opengeospatial/NamingAuthority/issues/92

While I know that UCUM seems to be being superseded by QUDT, I'm not aware of a UoM System named CURIE (google couldn't find anything either. Could it be that this discussion was on how to represent the Unit Curie?

AFAICR Clemens Portele first brought it up, I have no knowledge here

CRS Syntax: I used "EPSG::9390" for brevity as I remember it having been valid at some time in some context, have no issues replacing with a full URI, whereby I'm currently challenged by the question of which URIs are definitive? Following options:

• http://www.opengis.net/def/crs/EPSG/0/9390
• https://epsg.org/crs_9390/EVRF2019-mean-tide-height.html epsg.io doesn't yet provide 9390 suggestions?

IMHO http://www.opengis.net/def/crs/EPSG/0/9390 is the best we can have now. OGP sometimes changes things out of blue sky without informing. That said, opengis.net with the EPSG branch also references epsg.org...so my point is just that we have one common reference point with opengis.net which also contains URIs that EPSG does not care about (yet).

Did I mention it's shifting sands? ;-)

[KathiSchleidt]

CURIE - the W3C Spec cited in opengeospatial/NamingAuthority#92 pertains to URI encoding, nothing to do with UoM (except if you want to encode your UoM URI): CURIE Syntax 1.0 - A syntax for expressing Compact URIs: https://www.w3.org/TR/curie/

http://www.opengis.net/def/crs/EPSG/0/9390 - I'm happy with it, just need to get it on the list of INSPIRE compliant CRS (that list is still static, thus only contains what was valid back then: https://github.com/inspire-eu-validation/data/blob/master/reference-systems/spatial.md

At that time, EVRF2000 height (http://www.opengis.net/def/crs/EPSG/0/5730) was the most current EVRF version, but was then superseded by EVRF2007 (EPSG::5621), that now in turn by EVRF2019 (EPSG::9390)

And yes, the elevation levels shift together with the sands, does kinda make sense, doesn't it? ;)

[HerzovanderWal]

Don't forget the zero-tide variant (EPSG:9389)

[KathiSchleidt]

For completeness - the current variants on EVRF spanning 2000 - 2019:

• EVRF2000 height
• EVRF2007 height
• EVRF2019 height
• EVRF2019 mean-tide height

However, the issue here is how to encode any of these options in the RangeType once we've got them accepted by INSPIRE - the INSPIRE half is over in #10

[HerzovanderWal]

Aha. Thank you ;-) The last one is where the most of us and the dutch partners, with RD-NAP, are heading for.