[gdal-dev] GML lat-lon coverages and interoperability
p.baumann at jacobs-university.de
Tue Apr 4 03:24:30 PDT 2017
introducing (outing) myself as the coverage standard / WCS editor.
To avoid the problems that other standards have with axis order, coverages
contain the axis order explicitly, in the axisLabels attribute. Here an example:
*axisLabels="Lat Long"* uomLabels="deg deg" srsDimension="2">
The sequence in axisLabels is indicative. So it is not necessary to use
GridFunctions for this purpose. My personal opinion is that such mechanisms are
not optimal for fiddling with coordinate positions as they make it unnecessarily
difficult to determine the final pixel position. This seems to be the case here
On a side note, GMLCOV (aka CIS) 1.0 carries along some burden from GML, the
price for backwards compatibility. CIS 1.1 (just adopted) introduces a more
orthogonal coverage model in addition . Among others, it allows a very
explicit modelling of the coordinate axes - see the examples.
You may want to take notice of the public Coverages.DWG OGC Wiki , we try to
provide useful information, and feedback / questions are possible, too.
PS: I wonder why nobody just asked earlier by contacting me, or some list like
the (open) coverages.dwg list .
On 04/03/2017 02:32 PM, Rahkonen Jukka (MML) wrote:
> Cross posting intentionally.
> I wonder if all projects under the OSGeo umbrella, starting from GDAL and
> Geoserver, could make a common agreement on not to use GridFunctions in GML
> coverages if they are not strictly needed. The other alternative would be to
> make all projects to support GML gridFunctions, and do it right.
> Long story:
> I have been trying to understand how GML coverages are used in JPEG 2000 and
> in WCS services. So far I have understood that coverages can be very complex
> and GMLCOV and next generation CIS specifications are complex so that even the
> most nasty coverage types can be modelled. What seems to be missing from the
> specifications is a simple and unified way to model simple coverages, like
> Not surprisingly my pain started from latitude-longitude or Northing-Easting
> axis order of some coordinate systems. The GDAL source code in
> https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdaljp2metadata.cpp is
> prepared to handle georeferencign by looking at
> - grid origin
> - offset vectors
> - EPSG database for handling the coordinate axis order in GML
> At least in this place GDAL does not seem to be prepared in seeing
> gridFunctions which are defined in GML 3.2.1. With GridFunction it is possible
> to slide the starting point of the coverage with “startPoint”, change the
> order and direction of grid axes with “axisOrder” and define weird sequences
> for data points
> With orthophoto coverages I believe that all cases could be handled with the
> default gridFunctions: startPoint at gml:Low, axisOrder +1 +2, sequence rule
> “Linear”. As far as I have understood GDAL trusts that this is also what the
> other partners do. However, it seems that GeoServer developers have decided to
> handle the latitude-longitude axis flip in WCS 2.0.1 by changing the order of
> grid axis with a function instead of writing the offsetVectors to suit with
> the default +1 +2 axis order.
> <gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>
> <gml:startPoint>0 0</gml:startPoint>
> -Jukka Rahkonen-
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
mail: p.baumann at jacobs-university.de
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baumann at rasdaman.com
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev