Opened 11 years ago
Closed 9 years ago
#678 closed enhancement (fixed)
Evaluate the use of gml:EnvelopeWithTimePeriod when time axes are present
Reported by: | Piero Campalani | Owned by: | Peter Baumann |
---|---|---|---|
Priority: | minor | Milestone: | 9.2 |
Component: | petascope | Version: | development |
Keywords: | envelopewithtimeperiod bbox | Cc: | Peter Baumann, abeccati |
Complexity: | Medium |
Description
When a coverage contains a time axis, it might be convenient to display the BBOX through a gml:EnvelopeWithTimePeriod, to additionally specify the temporal extent with ISO timestamps.
A couple of things need to be evaluated before implementing it:
- should the time period replace the lower/upper corner information of time numerical coordinates in the usual
gml:Envelope
? (I suggest to keep both) - what happens if 2+ time axes are present? Which time axis should be taken? (I suggest we use
gml:EnvelopeWithTimePeriod
only when 1 and only 1 time axis is found in the dimensions of the (output) CRSs)
Change History (5)
comment:1 by , 11 years ago
comment:2 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
A possible solution (eg called gml:EnvelopeByAxisType
):
<gml:EnvelopeByAxis srsDimension=4 axisLabels="Lat Long h unix" uomLabels="degree degree m s" srsName="http://www.opengis.net/def/crs-compound? 1=http://www.opengis.net/def/crs/EPSG/0/4327& 2=http://www.opengis.net/def/crs/OGC/0/UnixTime"> <gml:crsAxis axisLabel="Lat" uomLabel="degree"> <gml:lowerBound>40</gml:lowerBound> <gml:upperBound>45</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="Long" uomLabel="degree"> <gml:lowerBound>10</gml:lowerBound> <gml:upperBound>15</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="h" uomLabel="m"> <gml:lowerBound>20</gml:lowerBound> <gml:upperBound>50</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="unix" uomLabel="s"> <gml:lowerBound>978303600</gml:lowerBound> <gml:upperBound>1291158000</gml:upperBound> <gml:beginPosition>2001-01</gml:beginPosition> <gml:endPosition>2010-12</gml:endPosition> </gml:crsAxis> </gml:EnvelopeByAxis>
The xsd would be kind of:
<!-- CRSAxisExtentType --> <complexType name="CRSAxisExtentType"> <sequence> <element name="lowerCorner" type="xsd:double"/> <element name="upperCorner" type="xsd:double"/> <sequence minOccurs="0"> <element name="beginPosition" type="gml:TimePositionType"/> <element name="endPosition" type="gml:TimePositionType"/> </sequence> </sequence> <attribute name="axisLabel" type="xsd:NCName"/> <attribute name="uomLabel" type="xsd:NCName" minOccurs="0"/> </complexType> <!-- EnvelopeByAxisType --> <complexType name="EnvelopeByAxisType"> <sequence maxOccurs="unbounded"> <element name="crsAxis" type="gml:CRSAxisExtentType"/> </sequence> <attributeGroup ref="gml:SRSReferenceGroup"/> </complexType> <element name="EnvelopeByAxis" type="gml:EnvelopeByAxisType" substitutionGroup="gml:AbstractObject">
An additional schematron could also let gml:TimePositionType
extensions only if the related CRS is temporal.
comment:3 by , 10 years ago
next version: some redundancy removed; better time CRS name (not important); ISO 8601 time coordinates; "Corner" → "Bound" in xsd; choice of time / space; etc:
<gml:EnvelopeByAxis srsDimension="4" axisLabels="Lat Long h unixtime" uomLabels="degree degree m s" srsName="http://www.opengis.net/def/crs-compound? 1=http://www.opengis.net/def/crs/EPSG/0/4327& 2=http://www.opengis.net/def/crs/OGC/0/UnixTime"> <gml:crsAxis axisLabel="Lat"> <gml:startPos>40</gml:lowerBound> <gml:endPos>45</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="Long"> <gml:startPos>10</gml:lowerBound> <gml:endPos>15</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="h"> <gml:startPos>20</gml:lowerBound> <gml:endPos>50</gml:upperBound> </gml:crsAxis> <gml:crsAxis axisLabel="unixtime"> <gml:startTime>2001-01</gml:beginPosition> <gml:endTime>2010-12</gml:endPosition> </gml:crsAxis> </gml:EnvelopeByAxis>
The xsd would be kind of:
<!-- CRSAxisExtentType --> <complexType name="CRSAxisExtentType"> <sequence> <choice> <sequence> <element name="startPos" type="xsd:double"/> <element name="endPos" type="xsd:double"/> </sequence> <sequence> <element name="startTime" type="gml:TimePositionType"/> <element name="endTime" type="gml:TimePositionType"/> </sequence> <choice> </sequence> <attribute name="axisLabel" type="xsd:NCName"/> </complexType> <!-- EnvelopeByAxisType --> <complexType name="EnvelopeByAxisType"> <sequence maxOccurs="unbounded"> <element name="crsAxis" type="gml:CRSAxisExtentType"/> </sequence> <attributeGroup ref="gml:SRSReferenceGroup"/> </complexType> <element name="EnvelopeByAxis" type="gml:EnvelopeByAxisType" substitutionGroup="gml:AbstractObject">
This still is limited: once we will have ordinal names, such as "red", "green", "blue" this won't work again. I am still for full generality = strings in coordinates, together with xsd or schematron rules for the proper syntax. The original problem in GML with strings originated from a sloppy modelling (several coordinate items in one element, whitespace separated - instead of isolation in separate elements) which has been remedied here.
comment:4 by , 9 years ago
Milestone: | 9.1 → 9.2 |
---|
comment:5 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
superseded by CIS 1.1 which can handle multiple time axes etc.
FYI, Max Martinez has suggested this roadmap once which GMLCOV development has followed in its development:
…are we approaching the last step now?