Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Coverage data
open-in-new
<h2 id="standards">Standards</h2> <p>Coverages represent digital geospatial information representing space/time-varying phenomena. OGC Abstract Topic 6<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> - which is identical to <a href="/facts/International_Organization_for_Standardization/IacYR7Yg">ISO</a> 19123 - defines an abstract model of coverages. Many implementations are conceivable which all conform to this abstract model while not being interoperable. This abstract coverage model is concretized to the level of interoperability by the OGC standard GML 3.2.1 Application Schema - Coverages<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> (often referred to as GMLCOV) which in turn is based on the Geography Markup Language (GML) 3.2,<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> an <a href="/facts/XML/clNgUfWk">XML</a> grammar written in XML Schema for the description of application schemas as well as the transport and storage of geographic information. </p><p>The European legal framework for a unified Spatial Data Infrastructure, INSPIRE, in its Annex II and III relies on the OGC definitions of coverages as well, but modifies them in places in a way making them less compatible and interoperable with the OGC standard. For example, components of the coverage concept are selectively recombined into new, different definitions of a coverage. </p> <h2 id="coverage-model">Coverage model</h2> <p>Formally, in GMLCOV AbstractCoverage is a subtype of AbstractFeature (indicating its close relation). An abstract coverage consists of the following components: </p> <ul><li>coverage domain: the extent where valid values are available;</li> <li>range set: the set of values ("<a href="/facts/Pixel/UzwBvXBV">pixels</a>", "<a href="/facts/Voxel/xo077lPE">voxels</a>") the coverage consists of, together with their locations</li> <li>range type: a type definition of the range set values</li> <li>metadata: a slot where any kind of metadata can be added</li></ul> <p>This abstract coverage is refined into several concrete coverage types, which can be instantiated, for example: </p> <ul><li>gridded coverages: <ul><li>GridCoverage: a regular, equispaced grid which is not spatially referenced (like a raster image which has no geo coordinates associated)</li> <li>RectifiedGridCoverage: a regular, equispaced grid which is spatially referenced (like a satellite image which does have geo coordinates associated)</li> <li>ReferenceableGridCoverage: a grid which is not necessarily equispaced (like satellite image time series where images do not arrive at regular time intervals, or curvilinear grids following river estuaries)</li></ul></li> <li>multi-feature coverages: <ul><li>MultiPointCoverage: sets of values associated with points located in space/time ("point clouds")</li> <li>MultiCurveCoverage: sets of values associated with curves located in space/time (such as trajectories)</li> <li>MultiSurfaceCoverage: sets of values associated with surfaces located in space/time (such as iso-surfaces)</li> <li>MultiSolidCoverage: sets of values associated with solids located in space/time (such as CAD objects)</li></ul></li></ul> <p>Among the special cases which can be modeled by coverages are </p> <ul><li>set of <a href="/facts/Thiessen_polygon/AhQY5LD8">Thiessen polygons</a>, used to analyse spatially distributed data such as rainfall measurements</li> <li>triangulated irregular network (TIN), often used for terrain models</li></ul> <h3>Relationship to Features</h3> <p>A coverage is a special kind of <a href="/facts/Feature_data/bTzAlll5">geographic feature</a>, with the distinguishing characteristics that other features have one particular value associated (such as a road number, which remains constant over all the road's extent) whereas a coverage typically conveys different values at different locations within its domain. <a href="/facts/ISO_19109/ca8yqGD3">ISO 19109</a> (2nd Ed.) explains the relationship between features and coverages as follows (clause 7.2.2): </p> <ul><li><i>Many aspects of the real-world may be represented as features whose properties are single-valued and static. These conventional features provide a model of the world in terms of discrete objects located in it. However, in some applications it is more useful to use a model focussing on the variation of property values in space and time, formalized as coverages. </i></li></ul> <p>Both viewpoints are required since they each express a fundamental meta-model of the world: as a space populated by things, or as a space within which properties vary. Furthermore, requirements relating to both viewpoints may occur in a single application, typically matching a data-flow: from observation through interpretation, and then elaboration and simulation.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> </p> <h2 id="coverage-encoding">Coverage encoding</h2> <p>The format-independent logical structure of coverages can be mapped to GML (such as for sensor time series) or to any of a series of data formats, such as <a href="/facts/GeoTIFF/l1TxVEM7">GeoTIFF</a>, <a href="/facts/NetCDF/DUwTEW7n">NetCDF</a>, <a href="/facts/HDF-EOS/IaIFvRP1">HDF-EOS</a>, or <a href="/facts/National_Imagery_Transmission_Format/NqnrX3sL">NITF</a>. </p><p>As some of these encoding formats are not capable of incorporating all metadata making up a coverage, the coverage model foresees a <a href="/facts/MIME/P8PDYuts">multipart</a> <a href="/facts/MIME/P8PDYuts">MIME</a> encoding (see Figure) where the first component encodes the coverage description (domain extent, range type, metadata, etc.) and the second part consists of the range set "payload" using some encoding format. </p> <h2 id="services">Services</h2> <p>In Web services following the open <a href="/facts/Open_Geospatial_Consortium/uDKbX6Cl">OGC</a> standards, coverages can be used by various service types: </p> <ul><li><a href="/facts/Web_Coverage_Service/5qnKgpkl">Web Coverage Service</a> which offers a simple access protocol for coverage subsetting, as well as optional advanced functionality</li> <li><a href="/facts/Web_Coverage_Processing_Service/82UgFLv3">Web Coverage Processing Service</a> which offers a multi-dimensional coverage query language for ad hoc processing, fusion, aggregation, and filtering</li> <li><a href="/facts/Web_Feature_Service/kwh86hzn">Web Feature Service</a> (although coverages can only be served as a whole, making it unwieldy in face of the often high-volume coverages, like satellite maps)</li> <li><a href="/facts/Web_Processing_Service/MLgIazlo">Web Processing Service</a> which allows publishing any kind of algorithm through an advanced remote procedure call style protocol</li></ul> <h2 id="industry-terminology-gis-format">Industry Terminology: GIS format</h2> <p>Early GIS systems were often characterised as either 'raster' or 'vector' systems, depending on the underlying approach to handling geometry. Raster GIS could be interpreted as using a regular discrete coverage model, while Vector GIS are more feature-oriented. The term "coverage" was most notably applied to the legacy <a href="/facts/ARC%2fINFO/ThQrMgs1">ARC/INFO</a> (ArcInfo) format developed by <a href="/facts/Environmental_Systems_Research_Institute/FP8cJykD">ESRI</a>. At that time this was a novel concept, extending <a href="/facts/Computer-aided_design/5gSXrmmN">CAD</a> formats into more spatially aware data that featured linked <a href="/facts/Attribute_(computing)/EpQSmn02">attributes</a>. This usage was consistent with the coverage concept discussed here, in the sense that an ArcInfo coverage provided a one-to-one mapping from space to the thematic value or classification for each layer or coverage. However, ArcInfo coverages had a particular topological approach to ensure completeness and uniqueness, processed using the BUILD and CLEAN commands are 2D <a href="/facts/Planar_(computer_graphics)/v4U9TFIn">planar</a> datasets that maintain <a href="/facts/Geospatial_topology/NKQtdEqa">topological</a> information, thus a polygon "knows" which segments of its perimeter it shares with adjacent polygons. Due to the lack of processing power in computing at the time of its development[<i>when?</i>], the Coverage model employs indexed <a href="/facts/Binary_file/ysttM8hh">binary files</a> to store spatial and attribute data separately as opposed to utilizing a <a href="/facts/RDBMS/pEKGmJLy">RDBMS</a>.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p><p>This has changed with the advent of raster database technology like <a href="/facts/Rasdaman/qoeuJWfv">rasdaman</a> which makes efficient ad hoc filtering and processing feasible.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a><a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Topic 6 - Schema for coverage geometry and functions, OGC 07-011 <a href="http://portal.opengeospatial.org/files/?artifact_id=19820" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=19820</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>OGC GML Application Schema - Coverages, OGC 09-146r2 <a href="https://portal.opengeospatial.org/files/?artifact_id=48553" target="_blank">https://portal.opengeospatial.org/files/?artifact_id=48553</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>OpenGIS Geography Markup Language (GML) Encoding Standard, OGC 07-036 <a href="http://portal.opengeospatial.org/files/?artifact_id=20509" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=20509</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>A Woolf; S J D Cox; C Portele (2010). "Data Harmonization - GEOSS AIP-3 Contribution" (PDF). doi:10.13140/RG.2.1.1840.4569. Archived from the original (PDF) on 2015-10-17. Retrieved 2016-01-27. <a href="https://web.archive.org/web/20151017225529/http://www.thegigasforum.eu/cgi-bin/download.pl?f=545.pdf" target="_blank">https://web.archive.org/web/20151017225529/http://www.thegigasforum.eu/cgi-bin/download.pl?f=545.pdf</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Zeiler, Michael. Modeling Our World, The ESRI Guide to Geodatabase Design. ESRI Press, 1999. ISBN 1-879102-62-5 <a href="/wiki/Geodatabase" target="_blank">/wiki/Geodatabase</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Baumann, P.; Jucovschi, C.; Stancu-Mara, S.: Efficient Map Portrayal Using a General-Purpose Query Language (A Case Study). DEXA 2009, August 31 - September 04, 2009, Vienna, Austria, Springer Berlin/Heidelberg, LNCS 5690, pp. 153-163 <a href="https://doi.org/10.1007%2F978-3-642-03573-9_12" target="_blank">https://doi.org/10.1007%2F978-3-642-03573-9_12</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Jucovschi, C., Baumann, P., Stancu-Mara, S.: Speeding up Array Query Processing by Just-In-Time Compilation. IEEE Intl Workshop on Spatial and Spatiotemporal Data Mining (SSTDM-08), Pisa, Italy, 15 December 2008, pp. 408 - 413 <a href="http://www.informatik.uni-trier.de/~ley/db/conf/icdm/icdmw2008.html#JucovschiBS08" target="_blank">http://www.informatik.uni-trier.de/~ley/db/conf/icdm/icdmw2008.html#JucovschiBS08</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> </ol>