Change Request A GMLCOV ReferenceableGrid Element for Remote Sensing Systems

18 Copyright © 2015 Open Geospatial Consortium.

6.4 Extend Usability of Coverage Identifiers

6.4.1 Analysis

As per GML 3.2.1, coverage identifiers are of type xml:ID which as per W3C definition is based on NCName which restricts them essentially to variable names in programming languages digits, alphabetic characters, underscore. However, users frequently want to have coverage names that convey some meaning in the context and, therefore, demand punctuation such as “:”, blanks, and national char- acters. Therefore, the coverage identifier type should be extended to allow for any type of string.

6.4.2 Change Request

Recommendation: Change the coverage identifier type from NCName to xs:string. However, it is unclear at this time how to achieve this in a backwards compatible way and without revising GML 3.2.1.

6.5 Integrated Handling of SpaceTime and Other Axes

6.5.1 Analysis

In GML, handling of space and time is separated. This concerns not only the place where coordinates are stored in an XML document, but also affects fundamental modeling; for example, the Coordinate Reference System CRS does not include time. Further, GML supports time coordinates in a separate place, but only as a single time dimension – hence, multiple time axes, something repeatedly required by atmospheric and oceanographic modelers, is not possible. Here is the relevant GML 3.2.1 schema: complexType name=EnvelopeType choice sequence element name=lowerCorner type=gml:DirectPositionType element name=upperCorner type=gml:DirectPositionType sequence element ref=gml:pos minOccurs=2 maxOccurs=2“ element ref=gml:coordinates choice attributeGroup ref=gml:SRSReferenceGroup complexType Shortcomings: ฀ Envelope addresses only spatial coordinates; time is handled elsewhere. In fact, GML treats space and time independently. Maintaining different coordinate components in different places obviously is error prone. ฀ CRSs in GML 3.2.1 relate only to the spatial part such as EPSG and do not include time axes. ฀ Only one time axis is foreseen by GML. GMLCOV, therefore, uses a more general approach. The gml:pos elements can be any type of coordinates, be they spatial horizontal or vertical, temporal, or any other “ab- stract” axis. An example for a LatLongtime datacube is described by the following GMLCOV snippet 9 : gmlcov:GridCoverage … gml:boundedBy gml:Envelope srsName= http:www.opengis.netdefcrs-compound? 1=http:www.opengis.netdefcrsEPSG04326 2=http:www.opengis.netdefcrsOGC0AnsiDate“ axisLabels=Lat Long Time uomLabels=deg deg sec srsDimension=“3 gml:lowerCorner1 1 123456890gml:lowerCorner gml:upperCorner3 10 123456899 gml:upperCorner gml:Envelope gml:boundedBy … gmlcov:GridCoverage This spacetime modeling makes use of a compound CRS as standardized in the OGC CRS Name Type Specification [OGC 11-135]. The value of the srsName attribute is a URI that combines, by concatenation, the Lat and Long axes provided by EPSG 4326 with the time axis provided by AnsiDate; each of those are CRSs in turn, their definition can be obtained by accessing the OGC CRS resolver listening at http:www.opengis.netdef . This way, any CRSs and axes can be combined into a new ad-hoc CRS. WCS allows subsetting on all coordinate axes. Further attributes in the gml:Envelope are redundant, as the CRSs referenced provide this information. For efficiency reasons, though, some relevant information is provided locally in the coverage, thereby easing the life of applications. These are the list of axis labels needed, e.g., for subsetting through WCS, the units of measure for each axis, and a count of the number of dimensions this coverage spans. GML elements gml:lowerCorn- er and gml:upperCorner provide the boundary coordinates of the coverage. Obviously, gml:axisLabels unambiguously specifies coordinate sequence in lower and upper corner coordinates, and gml:srsDimension specifies how many coordinate items the lower and upper corner elements must contain. While this allows for a concise description of spacetime coverages, and even covers the case of multiple time axes, another issue remains: Listing time coordinates only in the unit of measure given such as seconds since epoch, i.e.: January 1, 1970 is unwieldy. Preferably, a human-readable calendar syntax as given by ISO 8601 should be possible, 9 gml:pos and gml:coordinate are deprecated, leaving only the lowerupper corner approach. This is not relevant for the discussion at hand.