Elevation Grids - value-is-corner vs. value-is-center #112
Replies: 1 comment
-
A short follow-up: the contradiction mentioned above is also contained in the IR on datasets. How can one best align the following contradicting requirements: Geographical Grids Elevation |
Beta Was this translation helpful? Give feedback.
-
Dear all,
we've run into some logical issue in the provision of Elevation Grids, pertains to the exact location for which the value is provided, value-is-corner vs. value-is-center. I'm aware that this has long been a point of confusion when dealing with Coverage models, with the more data-affine folks tending towards value-is-corner (cleanly nailed down location) while the visualization end is convinced these values are pixels, thus insist on value-is-center. For Themes such as OrthoImagery, value-is-center makes total sense, as the values are actually pixels (so apply for the entire cell). For Elevation, value-is-center would only make sense if we lived in a MineCraft or Lego based world.
However, this logical approach is at odds with the following:
IR Requirement Annex II Section 6.2.1.2 Constraints of the spatial object type RectifiedGridCoverage
Grid points of a RectifiedGridCoverage shall coincide with the centres of cells of the geographical grids defined in Section 2.2 of Annex II of the Commission Regulation on Interoperability of Spatial Data Sets and Services at the same resolution level.
I'd be interested how other MS are providing their elevation data, following the technical SOTA (value-is-corner), or just bowing to the legal requirements (value-is-center)?
:?
Kathi
Beta Was this translation helpful? Give feedback.
All reactions