7th Framework Programme ENV.2010.4.1.2-2 Integrating new ...geoviqua.org/Docs/SubmittedDeliverables/D3_1_GeoViQua.pdf · GeoViQua as well in WP6, Task 6.1 (Encodings for data quality).

7th Framework Programme

ENV.2010.4.1.2-2 Integrating new data visualisation approaches of

earth Systems into GEOSS development

Project Nr: 265178

QUAlity aware VIsualisation for the Global Earth Observation system of systems

Deliverable D3.1 Metadata extraction quality component

Version 1.3

Due date of deliverable: 01/01/2012 Actual submission date: 30/05/2012

FP7 Project Nr: 265178 Project start date: 01 Feb 2011 Acronym: GeoViQua Project title: QUAlity aware VIsualisation for the Global Earth Observation system of systems Theme: ENV.2010.4.1.2‐2 Theme title: Integrating new data visualisation approaches of earth Systems into GEOSS development

Document control page

Title D3.1 Metadata extraction quality component

Creator IS_CREAF

Editor IS_CREAF , PD_CREAF and JM_CREAF

Description

Publisher GeoViQua Consortium

Contributors CREAF, UAB, CNR, S&T

Type Text

Format MS-Word

Language EN-GB

Creation date 12/01/2012

Version number 1.0

Version date 06/07/2012

Last modified by

Rights Copyright © 2011, GeoViQua Consortium

Dissemination level

CO (confidential, only for members of the consortium) X PU (public) PP (restricted to other programme participants) RE (restricted to a group specified by the consortium) When restricted, access granted to:

Nature

X R (report) P (prototype) D (demonstrator) O (other)

Review status

X Draft Where applicable:

WP leader accepted Accepted by the PTB

PMB quality controlled XAccepted by the PTB as public document

Coordinator accepted

Action requested

to be revised by all GeoViQua partners X for approval of the WP leader for approval of the PMB X for approval of the Project Coordinator X for approval of the PTB

Requested deadline


Revision history

Version Date Modified by Comments 0.1 19-01-2012 IS_CREAF Created the basic content of the deliverable

0.2 27-01-2012 JM_IS_CREAF

Structuring the content

0.3 07-02-2012 IS_CREAF Adding content

0.4 26-02-2012 IS_CREAF Adding content

0.5 07-03-2012 IS_CREAF Reviewing the introduction

0.6 19-03-2012 OG_CREAF Adding content on quality indicators derived from EO metadata formats

0.7 18-04-2012 PD_CREAF Adding content about Metadata punctuation for quality

0.8 24-04-2012 JM_CREAF Reviewing the contributions

0.9 24-04-2012 IS_CREAF Adding changes from collaborators and reviewing the hole document

0.95 08-05-2012 JS_S&T

1.0 15-05-2012 PD_CREAF Reviewing the contributions

1.1 22-05-2012 OG_UAB Reviewing the contributions

1.2 26-05-2012 LB_CNR Adding NetCDF and SOS information

1.3 29-05-2012 AR_CREAF Adding section 3 on citation Copyright © 2011, GeoViQua Consortium

The GeoViQua Consortium grants third parties the right to use and distribute all or parts of this document, provided that the GeoViQua project and the document are properly referenced.

THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Table of Contents

Abstract ............................................................................................................................................................. 6

INTRODUCTION ................................................................................................................................................ 6

Dataset oriented approach: ISO quality indicators encoding ......................................................................... 7

Pixel/Feature oriented approach: UncertML quality indicators encoding .................................................... 10

Lineage/provenance ISO encoding .............................................................................................................. 12

QUALITY AND PROVENANCE INDICATORS RETRIEVAL ......................................................................... 13

Quality and provenance indicators derived from other capacity catalogues using the EUROGEOSS broker ..................................................................................................................................................................... 13

Visualizing quality metadata on the GEO Portal ...................................................................................... 17

Quality and provenance indicators derived from EO metadata formats ...................................................... 18 Metadata Embedded in Data files ............................................................................................................ 19

CEOS................................................................................................................................................... 19 HDF ..................................................................................................................................................... 21 NetCDF ................................................................................................................................................ 24

Metadata from associated files ................................................................................................................ 29 NDF ..................................................................................................................................................... 29 Landsat GloVis/Earth Explorer Format ................................................................................................ 30 SPOT DIMAP ...................................................................................................................................... 32 ESA EO File Formats (satellite based, level 2) ................................................................................... 34

Transversal Formats ................................................................................................................................ 36 Content Standard for Digital Geospatial Metadata .............................................................................. 37 Dublin Core .......................................................................................................................................... 40 THREEDS ........................................................................................................................................... 40

Workflow and contributions ...................................................................................................................... 41 Extraction and encoding of quality information embedded within datasets ........................................ 41

2.2.5. Metadata from data ................................................................................................................ 42

Metadata punctuation for quality .................................................................................................................. 43 The rubric tool developed by NOAA ........................................................................................................ 44 Representing ISO metadata documents using rubric XSL style sheet .................................................... 45

XSL style sheet .................................................................................................................................... 46 The Rubric extension of quality ............................................................................................................... 47

Rubric metadata quality punctuation ................................................................................................... 54

SCIENTIFIC PUBLICATION CITATION .......................................................................................................... 56

Dataset-Publication Relationship ................................................................................................................. 59 Examples of publications sorted by data reference purpose ................................................................... 59 Examples on Categories .......................................................................................................................... 61 Some thoughts on the design .................................................................................................................. 62

CONCLUSIONS ............................................................................................................................................... 63

GLOSSARY ..................................................................................................................................................... 64

REFERENCES ................................................................................................................................................. 66

Annex A ........................................................................................................................................................... 69

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. ...................................................... 70

Annex A.2: Crosswalk between the THREDDS format and the ISO 19115. ............................................... 84

Annex A.3: Crosswalk between the NDF format and the ISO 19115. ....................................................... 111


Annex A.4: Crosswalk between the GloVis format and the ISO 19115. .................................................... 115

Annex A.5: Crosswalk between the DIMI format and the ISO 19115. ....................................................... 123

Annex A.6: Crosswalk between the DCMI format and the ISO 19115. ..................................................... 129

Annex B ......................................................................................................................................................... 131

B.1 NetCDF Uncertainty Conventions ................................................................................................. 132 B.1.1 Global provisions ...................................................................................................................... 132

B.1.1.1 Identification of Conventions ............................................................................................ 132 B.1.1.2 Primary and ancillary variables ........................................................................................ 132

B.1.2 Uncertain concepts ................................................................................................................... 133 B.1.2.1 Concept parameters ......................................................................................................... 134 B.1.2.2 Concepts without values .................................................................................................. 134

B.1.3 Encoding of Samples ................................................................................................................ 135 B.1.4 Encoding of Summary Statistics ............................................................................................... 136 B.1.5 Encoding of Distributions .......................................................................................................... 137

Annex C ......................................................................................................................................................... 138

C.1 Examples of publications related to GEOSS datasets .................................................................. 139 C.1.1 DESCRIPTIVE .......................................................................................................................... 139 C.1.2 METHODOLOGY TO GET THE RESOURCE (ALGORITHMS, MODELS,...) ........................ 139 C.1.3 EVALUATION OF PERFORMANCE ........................................................................................ 141 C.1.4 VALIDATION/QUALITY ASSESSMENT .................................................................................. 142 C.1.5 APPLICATION (MD_USAGE) .................................................................................................. 144 C.1.6 DERIVATED PRODUCTS ........................................................................................................ 145 C.1.7 COMPARATIVE (INTERCOMPARISON) ................................................................................. 147 C.1.8 DATASETS COMBINATION .................................................................................................... 148

C.2 Some examples of XML documents ............................................................................................. 149 C.2.1 Book .......................................................................................................................................... 149 C.2.2 CD/DVD .................................................................................................................................... 152 C.2.3 Manual ...................................................................................................................................... 154 C.2.4 Poster ........................................................................................................................................ 158 C.2.5 Online Video ............................................................................................................................. 161 C.2.6 Journal Article ........................................................................................................................... 163 C.2.7 Atlas Paper Map ....................................................................................................................... 165 C.2.8 Magazine or Newspaper ........................................................................................................... 167 C.2.9 WebSite .................................................................................................................................... 170


6

Abstract This is the first deliverable of the Work Package 3 (WP3) “Data quality elicitation mechanisms” in the GeoViQua 7th Framework Programme ENV.2010.4.1.2-2. WP3 activities are based on the provision of efficient tools to extract the quality information coming from metadata including quality and provenance information, and the user feedback in terms of knowledge and comments. The main goal of WP3 is to link all this quality information to data stored in catalogues using a specific encoding developed by GeoViQua as well in WP6, Task 6.1 (Encodings for data quality). This deliverable, directly coming from the Task 3.1 (Metadata extraction quality component), develops a tool to identify quality indicators from existing metadata documents in an integrated manner. On one side, quality metadata is extracted from the pure GEOSS catalogue but this approach has been extended to other catalogues that can be related to GEOSS by means of using the EUROGEOSS broker. On the other side, quality information is extracted as well from the main EO metadata formats such as HDF (4, 5, EOS), CEOS, NDF (NLAPS Data Format for USGS Landsat imagery), GeoTiff + MTL + Meta (USGS Landsat imagery), Tiff + Dimap (SPOT imagery), JPEG2000, NetCDF, and WCS-THREDDS. With all these information, a comprehensive quality metadata analysis has been performed. Since quality parameters are left open in ISO 19115, this tool integrates several quality descriptors found into the unified model from the task 6.1 and transformed into an XML file regardless of its original format. Related to this, Rubric system is used to punctuate metadata in terms of quality obtaining a quality rating HTML file. Provenance information in ISO 19115 (lineage) is also used to infer quality coming from either sources or processes of GEOSS and non GEOSS datasets. Finally, scientific publication citation is explored to be incorporated into GCI metadata records.

INTRODUCTION The Global Earth Observation System of Systems (GEOSS), coordinated by the Group on Earth Observations (GEO) (GEO, 2005), is a public infrastructure that interconnects a diverse and growing array of data, instruments and systems to allow monitoring and forecasting changes in the global environment. GEOSS gives support to policy-makers, resource managers, scientific researchers and many other experts and decision makers in their daily work with Earth Observation (EO) data. The Geoss Common Infrastructure (GCI) consists of a web-based portal, a Clearinghouse for searching data, information and services, and registries containing information about GEOSS components, standards, and best practices. This is to say, the GCI Clearinghouse was the GEOSS registry and metadata catalogue. Now, the EuroGEOSS broker has been added to the GCI: a search engine that aggregates the clearinghouse and other catalogues in a single service.


7

The goals of GCI in 2011 seek a facilitated access to datasets and other resources supporting the Earth Observation Priorities identified in the User Interface Committee UIC report, enabling discovery and facilitating access to data-core contributions. Other actions intended are the adaptation of interfaces in order to allow effective data finding and downloading (‘fewer clicks to the data’), and in the end improving usability/user experience (Masó et al., 2011). The GCI is subjected to continuous development and improvement of its functionality, from infrastructure and back-end services to context-driven applications and human-computer interfaces. A major target for this development is the wide variety of Societal Benefit Areas (SBA) that GEOSS addresses: Health, Disasters, Weather, Energy, Water, Climate, Agriculture, Ecology and Biodiversity. In turn, the GEO Portal is aimed at the discovery and visualization of EO data in an integrated, standardized and interactive way, enabling a wide use by the scientific community when dealing with representation and modelling of Earth Systems. Under the GEO umbrella several tasks approach the dynamic architectural implementations in GEOSS, including components and tools development guaranteeing multidisciplinary interoperability in addition to quality elicitation and awareness, such as the recent creation of the GEOSS Science and Technology Service Suite. GeoViQua treats GEOSS data regarding its quality information. However, apart from the study on the quality indicators that currently exist in the GCI, there’s the necessity to retrieve all the several sources of metadata that feed the GCI. This goal will help on the definition of the GeoViQua Quality Data Model to be developed in the deliverable 6.1: Data quality encoding as a best practice paper (Yang et al., 2012a). That is the purpose of the present deliverable: extract any quality metadata of the GCI and simultaneously propose tools to enrich GCI with ISO quality metadata encoding. There are two approaches to encode metadata, and thus quality, in a standard way: - Dataset oriented approach: ISO encoding. - Pixel oriented approach: UncertML encoding.

Dataset oriented approach: ISO quality indicators encoding For geospatial datasets, the most widely used standards include the Dublin-Core Metadata Initiative (DCMI), the Federal Geographic Data Committee- Content Standard for Digital Geospatial Metadata (FGDC-CSDGM) and, predominantly in the GEOSS GCI, the ISO 19100 series standards for Geospatial metadata. In particular, the ISO 19115:2003 (ISO/TC211, 2003) is related to data products, the ISO 19119:2005 (ISO/TC211, 2005) refers to services, and the ISO 19139:2007 (ISO/TC211, 2007) contains a specific implementation in XML format. This format and some others are supported by the GCI architecture enabling the extraction of metadata records from the Clearinghouse. The standard records include quality elements organized in a hierarchic model. In this sense, ISO 19139:2007 contains the specifications for writing or translating the UML model in ISO 19115:2003 in XML format. In other words, ISO 19139:2007 can be regarded as the


8

realization of ISO 19115:2003 in a XML format. Thus, other formats (e.g., excel files, external documents) must be converted to ISO19139:2007. On the current ISO standards, it must be remarked that the ISO 19138 (ISO-TC211 2006) is being revised. The ISO 19157 (ISO-TC211 2011), currently under development, is prone to provide updated insights in this context. In this sense, and under the deliverable 7.2 from the WP7 entitled “Report on current GCI and identification of issues in integration with GEOSS”, quality parameters available in GCI ISO datasets of GEOSS have been exhaustively analysed. To this end, lists of typified common quality parameters (defined as "quality elements" in ISO standards –ISO 19113-) for geographical datasets have been revised. In this case, ISO 19115:2003 “Geographic information – Metadata” is the main reference (ISO TC-211). These standards define quality parameters related to datasets such as positional accuracy, logical consistency, temporal accuracy and thematic accuracy (see Table 1).

Table 1. Classification and definition of quality parameters and indicators Quality parameter

Quality indicator Definition

Completeness Commission Excess data present in a dataset Omission Data absent from a dataset

Logical consistency

Conceptual consistency Adherence to rules of the conceptual schema Domain consistency Adherence of values to the value domains

Format consistency Degree to which data is stored in accordance with the physical structure of the dataset

Topological consistency Correctness of the explicitly encoded topological characteristics of a dataset

Positional accuracy

Absolute or external accuracy

Closeness of reported coordinate values to values accepted as or being true

Relative or internal accuracy

Closeness of the relative positions of features in a dataset to their respective relative positions accepted as or being true

Gridded data position accuracy

Closeness of gridded data position values to values accepted as or being true

Temporal accuracy

Accuracy of a time measurement

Correctness of the temporal references of an item (reporting of error in time measurement)

Temporal consistency Correctness of ordered events or sequences Temporal validity Validity of data with respect to time

Thematic accuracy

Classification correctness Comparison of the classes assigned to features or their attributes to a universe of discourse (e.g., ground truth or reference dataset)

Non-quantitative attribute correctness

Correctness of non-quantitative attributes

Quantitative attribute accuracy

Accuracy of quantitative attributes

The clearinghouse metadata content up to November 2011 was automatically extracted and analyzed in terms of their quality information. The clearinghouse follows the Open Geospatial Consortium (OGC) Catalogue Services for the Web (CSW) standard specification, whereas the metadata retrieved follows the ISO 19115 standard (ISO/TC211, 2003) and is thus encoded in the ISO 19139:2007 standard (ISO/TC211, 2007).


9

The total number of GEOSS clearinghouse metadata records harvested in this previous deliverable 7.2 is 97203. In this particular case, GeoViQua focused on the results of the two main aspects emphasized in ISO19115:2003 as data quality information: the quality indicator (DQ_Element) and the lineage (LI_Lineage). Additionally, the usage information (MD_Usage) was also considered. Finally, and as for user requirements, the standard specifications contain a MD_Usage class. This element is intended for a brief description of the ways in which the product is being used or has been used for. From this previous deliverable can be extracted that the overall number of metadata records with quality indicators is 19107 which represents 19.66% of the total sample. In turn, the 19107 metadata records contain a total of 52187 quality indicators which results in a mean of 2.7 quality indicators per document. This results show that, among the generic indicators, positional accuracy and completeness are the ones most widely used, with a quite similar importance (37.19% and 35.72%, respectively), and adding up to a high percent of the total, 72.91% (see Table 2). The third quality indicator in number is logical consistency, reaching around a 20%, whereas the fourth is temporal accuracy, adding up to a 6.81%. Thematic accuracy is below a 1% in the sample of generic quality indicator classes. Absolute external positional accuracy is the most significant subclass, with a total number of 17767 and explaining most part of the relevance of positional accuracy in the sample of metadata with quality indicators (34.04%). Remarkably, an interesting finding is the 1364 number corresponding to gridded data positional accuracy, which is a much demanded quality indicators both for users and experts in geospatial datasets.

Table 2. Classification of quality indicators in classes and subclasses in the GEOSS Clearinghouse

Generic quality indicator Specific quality indicator Number %

Positional accuracy Absolute external positional accuracy 17767 34.04Gridded data positional accuracy 1364 2.61Relative internal positional accuracy 280 0.54

19411 37.19

Completeness Completeness commission 9815 18.81Completeness omission 8823 16.91

18638 35.72

Logical consistency

Conceptual consistency 9454 18.12Domain consistency 857 1.64Topological consistency 12 0.02Format consistency 0 0.00

10323 19.78

Temporal accuracy Accuracy of a time measurement 2870 5.50Temporal consistency 682 1.31Temporal validity 0 0.00

3552 6.81

Thematic accuracy Quantitative attribute accuracy 261 0.50Non-quantitative attribute accuracy 2 0.01Thematic classification correctness. 0 0.00

263 0.51 Total quality indicators 52187


10

More detailed information is available on the Deliverable 7.2: Report on current GCI and identification of issues in integration with GEOSS and in the published paper by Yang et al. (2012b).

Pixel/Feature oriented approach: UncertML quality indicators encoding In the case of the pixel/feature oriented approach, an ISO encoding is not feasible as it will represent too many information associated to each pixel/feature. Here the concept of pixel/feature refers to a geolocated region in space (that can be described by 2, 3 or even more dimensions, such as time,…) that can be identifier and can carry some values or attributes. Depending on the data model, this can be a pixel in a raster, a polygon in a vector layer etc. Examination of the typical spatial data holdings reveals a technical requirement. Many datasets are very large and hierarchical in nature. Quality information may apply at different levels in the hierarchy: for example, in an Earth Observation scenario, quality information can be given for a whole platform series (e.g. Landsat-5 image series), for a single dataset (e.g. a specific scene of a Landsat-5 image), for a single band (e.g. the near infrared Landsat-5 band) or even for a specific pixel of the image (e.g. if a quality indicator is spatialized in a pixel-based approach, e.g. a quality flag coverage). This brings us to the important question: should uncertainty be considered as metadata, or is it more realistic to recognise the inherent uncertainty of all data and to treat the uncertain value (whether it is a distribution, an interval or a sample) as the data itself? To avoid this huge pixel based metadata and to better express the quality of a single value in a dataset, a new standard to express uncertainty associated to a pixel was developed: UncertML (Williams, et al., 2008). This language will be applied in GeoViQua to define this kind of uncertainty. UncertML is a conceptual model and an XML encoding designed for encapsulating probabilistic uncertainties and to quantify and exchange complex uncertainties in data. This interoperable model can be used to describe uncertainty in a variety of ways, including:

- Samples. In some situations you may not fully understand the uncertainties of the data you are working with. Typically, in such a situation you may provide a sample of the data which allows the uncertainties to be described implicitly. Unfortunately, a sufficiently large sample of data is required for calculating the uncertainties, introducing the issue of encapsulating large amounts of data efficiently. The following element is available within UncertML for describing a sample of data through realizations. The following elements are available: Random Sample, Unknown Sample, Systematic Sample, and Realization.

- Statistics including mean, variance, standard deviation and quantile. There is

an extensive range of options available in UncertML for describing 'summary statistics'. Such statistics are used to provide a summary of a variable ranging from measures of location (mean, mode, median, etc) to measures of dispersion (range, standard deviation, variance, etc). While certain statistics do not provide any information about uncertainty


11

they are often used in conjunction with other statistics to provide a concise but detailed summary. The following elements are available: Centred Moment, Coefficient Of Variation, Confidence Interval, Confusion Matrix, Correlation, Covariance Matrix, Credible Interval, Decile, Discrete Probability, Interquartile Range, Kurtosis, Mean, Median, Mode, Moment, Percentile, Probability, Quantile, Quartile, Range, Skewness, Standard Deviation, and Variance.

- Probability distributions including marginal and joint distributions and

mixture models. When the uncertainties of your data are more clearly understood it may be desirable to describe them through the use of probability distributions. The elements listed below are specifically designed to allow a concise encapsulation of many distributions without sacrificing the simplicity of UncertML: Bernoulli Distribution, Beta Distribution, Binomial Distribution, Cauchy Distribution, ChiSquare Distribution, Dirichlet Distribution, Exponential Distribution, F Distribution, Gamma Distribution, Geometric Distribution, Hypergeometric Distribution, Inverse Gamma Distribution, Laplace Distribution, Log Normal Distribution, Logistic Distribution, Mixutre Model, Multinomial Distribution, Multivariate Normal Distribution, Multivariate Student T Distribution, Negatibe Binomial Distribution, Normal Distribution, Normal Inverse Gamma Distribution, Pareto Distribution, Poisson Distribution, Student T Distribution, Uniform Distribution, Weibull Distribution, and Wishart Distribution. An example of the UncertML XML encoding can be seen in the case of the mean statistic: XML schema:  <xs:element name="Mean" substitutionGroup="un:AbstractSummaryStatistic"> <xs:complexType> <xs:complexContent> <xs:extension base="un:MeanType"/> </xs:complexContent> </xs:complexType> </xs:element>  <xs:complexType name="MeanType"> <xs:complexContent> <xs:extension base="un:AbstractSummaryStatisticType"> <xs:sequence> <xs:element name="values" type="un:ContinuousValuesType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> XML example:  <un:Mean xmlns:un="http://www.uncertml.org/2.0"> <un:values>3.14</un:values> </un:Mean> 


12

<un:Mean xmlns:un="http://www.uncertml.org/2.0"> <un:values>3.14 6.28 9.42</un:values> </un:Mean> UncertML is quite complete regarding quantitative values. However, under GeoViQua Quality Model (D 6.1) categorical uncertainties will be deepened in order to include other categorical common statistics such as kappa index (currently in UncertML categorical variables can be expressed with: “realisation” as a single instance of a random variable that can be used to mean an observed value, “mode” as the value that occurs the most frequently in a dataset, “multinomial distribution”, “systematic sample” as a set of chosen realisations taken from a probability distribution, and “random sample” as a set of independent realisations drawn from a probability distribution). These qualitative descriptions will be consistent with ISO 19138 and the revisions being considered in ISO 19157, 19158 and 19159. Image formats that inform about uncertainty at a pixel level is, basically, NetCDF-U. Alternatively, U-O&M 2.0 format (a data model and encoding for observation data defined by the OGC) is used to encode vector-based model in- and outputs with spatial and/or temporal support.

Lineage/provenance ISO encoding Regarding the lineage, ISO 19115 distinguishes between production processes (LI_ProcessStep) and the sources used in elaborating the dataset (LI_Source) that can be combined in several ways. Therefore, metadata records can contain a direct list of the data sources, a direct list of the processes, or can link data sources to each process (complete provenance). In this way, each new resource accumulates the processes and sources history of the previous resources by repeating the previous history. The GEOSS clearinghouse metadata study done by GeoViQua revealed that some datasets accumulate more than one thousand processes and sources in their metadata records and that provenance information is provided in 12% of the resources. Provenance is the capacity to annotate the sources and processes that were used in the creation of a resource (e.g. datasets and operations involved in the creation of a particular dataset). It provides traceability and trust in the resource by knowing its origins and giving credit to the processors of the resource. If it is complete and has access to the same sources and processes, it potentially allows recreating the resource. It is considered a component of the quality description of the dataset. The need for a metadata file identifier was also pointed in section 4.6.2 GEOSS Common Record from the Data Harmonization Working Group (DHWG) Engineering Report GEOSS Architecture Implementation Pilot, Phase 3. Despite all these efforts, provenance descriptions are mainly textual and, when sources are mentioned, link to the local data that was used (using local file system notations); they are not providing provenance linked to distributed data resources in catalogues. The origin of this problem is that provenance is generated automatically in local computers by the software accessing local files and not in a distributed environment. When the metadata was made public, nobody cared about redirecting local files to public resources in catalogues (if available).


13

There is a need for providing an encoding and recommendations on how to provide provenance information in a way that GEOSS resources can point to other GEOSS resources. Even if a producer wants to fix provenance metadata to link to public resources in GEOSS, the main difficulty to achieve this purpose is the lack of a clear schema for global and persistent identifier for each GEOSS resource. Also, the clearinghouse catalogue is complicating the problem by providing new identifiers to pre-existing resources (with other identifiers in the original catalogues; currently the EuroGEOSS broker is using its own solution for global identifier that could be enough if adopted as the selected one). In a scenario where someone is willing to create a system to generate and edit feedback for a GEOSS resource in a GEOSS catalogue, the lack of a global and persistent identifier in GEOSS makes it also difficult. In the experimental portal GEOSSBack (www.ogc.uab.es/geossback) we use the GEOSS clearinghouse identifier to link user comments to GEOSS resources but this strategy is only valid for the clearinghouse (e.g. for the EuroGEOSS broker, we need to use another solution as discussed in the previous paragraph).

QUALITY AND PROVENANCE INDICATORS RETRIEVAL

Quality and provenance indicators derived from other capacity catalogues using the EUROGEOSS broker A relevant component introduced into the GCI architecture is the EuroGEOSS Broker, which now links the GEO Portal and the Clearinghouse. This is to say, it is now an intermediate step between the GCI and the Portal, which in the end means the access point for clients (Nativi et al., 2009). The GEO Portal interaction with the broker is made via Catalogue Service Web CSW 2.0.2. The portal data display will depend on results provided by catalogues federated in the broker, whereas the portal functionality will depend on the metadata organization in the database, the catalogue service interfaces allowing specific queries, and results provided by catalogues integrated in broker. GeoViQua is also directly involved: the EuroGEOSS broker continuous development is a core component particularly in Work Package 4 “Enhanced geosearch components”. Among its virtues, the broker shall improve search capabilities within GEOSS by allowing quality aware queries. All these results in a new GCI architecture are represented in the following figure.


14

Figure 1. New GCI architecture as presented in GeoViQua 3rd Project Technical Board Meeting (Reading, United Kingdom, December 2011). Sapienza Consulting presentation/ESA

Apart from the GEOSS Clearinghouse, the broker is linked to several federated capacity catalogues. The list of capacity catalogues accessible through the brokered GCI up to date as reported in the EuroGEOSS “Advancing the vision for GEOSS” symposia includes: GENESI-DEC, CWIC, NASA GCMD, Sea Data Net, EuroGEOSS, NASA GSFC-DAAC, EEA-SDI, SAEOS, IODE, One Geology, Enviro GRIDS/WaterML and INPE. Only the INPE and Enviro Grids/Water ML catalogues architecture have required the adoption of new access protocols. These other catalogues will be analysed in other deliverable in GeoViQua. An important difference between the Clearinghouse and these other catalogues is that the harvesting process is expected to extract Metadata from the Catalogue Services for the Web (CSW) catalogues and incorporate everything in a single clearinghouse. In order to enable quality metadata retrieval, standardization of quality parameters has been identified as an essential step. Accordingly, the Clearinghouse and the broker shall be able to implement the relevant standards for quality description. To this end, a Quality Extension for the ISO Profile of the Catalogue Service for the Web specification (CSW-ISO-Q) is being investigated in Work Package 4. It must be remarked that, as is shown in a figure above, the portal is at the bottom of the chain. Thus, the search and visualization of quality information will depend on the availability and search capabilities of information from the other GCI components (i.e., EuroGEOSS broker, Clearinghouse, Community Catalogues), as well as from the actual availability of appropriate quality information from the data sources. For Milestone 6: “Prototype quality geo-search component ready to validate in pilot case studies”, WP4 is currently investigating the extraction of quality information from data providers implementing an appropriate quality extension of the OGC Sensor Observation Service standard (SOS-Q).

GEOPortal

EuroGEOSS

GEOSS

GEOSS resources

GEO

GEOSS


15

The following XML fragment from a SOS 1.0 Capabilities document and the table below show the current mapping between items of the SOS 1.0 Capabilities and the respective Broker data model items. <sos:ObservationOffering gml:id="rain">

<gml:name>Rain precipitation in meteo stations</gml:name> <gml:boundedBy>

<gml:Envelope srsName="urn:ogc:def:crs:EPSG:4326"> <gml:lowerCorner>45.777841 7.992608</gml:lowerCorner> <gml:upperCorner>5129736.0 469645.0</gml:upperCorner>

</gml:Envelope> </gml:boundedBy> <sos:time>

<gml:TimePeriod xsi:type="gml:TimePeriodType"> <gml:beginPosition>1971-01-31T13:00:00.000+01:00</gml:beginPosition> <gml:endPosition>2010-09-08T05:27:00.000+02:00</gml:endPosition> </gml:TimePeriod>

</sos:time> <sos:procedure xlink:href="urn:ogc:object:feature:Sensor:ISE:6CD1353A-A5DF-11DF-8175-7003DFD72085"/> <sos:procedure xlink:href="urn:ogc:object:feature:Sensor:ISE:71588CEC-A5EA-11DF-93A9-5113DFD72085"/> <sos:observedProperty xlink:href="urn:ogc:def:property:OGC:1.0.30:5_minutes_continuous_rain"/> <sos:featureOfInterest xlink:href="AlpeMottac"/> <sos:featureOfInterest xlink:href="Candoglia"/> <sos:featureOfInterest xlink:href="Cicogna"/> <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat> <sos:responseFormat>application/zip</sos:responseFormat> <sos:resultModel xmlns:ns="http://www.opengis.net/om/1.0">ns:Measurement</sos:resultModel> <sos:resultModel xmlns:ns="http://www.opengis.net/om/1.0">ns:Observation</sos:resultModel> <sos:responseMode>inline</sos:responseMode> <sos:responseMode>resultTemplate</sos:responseMode>

</sos:ObservationOffering> Each ObservationOffering is modelled as a dataset collection, containing one dataset per valid feature of interest. Other components of the SOS Capabilities are mapped to specific metadata of the datasetCollection and/or of each of the contained dataset, as reported in the second table below.

Table 3. components of the SOS Capabilities SOS Capabilities item Broker data model item

sos:ObservationOffering datasetCollection

sos:featureOfInterest (with valid @xlink:href attribute) dataset

SOS Capabilities item ISO 19115‐2 item Broker data model

item

sos:oservedProperty gmi:MI_Metadata/gmi:acquisitionInformation/gmi:MI_AcquisitionInformation/gmi:objective/gmi:MI_Objective/gmi:function

datasetCollection

dataset


16

sos:procedure gmi:MI_Metadata/gmi:acquisitionInformation/gmi:MI_AcquisitionInformation/gmi:objective/gmi:MI_Objective/gmi:sensingInstrument

datasetCollection

dataset

sos:featureOfInterest

href/@href

gmi:MI_Metadata/gmi:acquisitionInformation/gmi:objective/gco:CharacterString

dataset

As indicated in the table, the observedProperty and the procedure information are replicated in each dataset (corresponding to a featureOfInterest). This is due to a well known ambiguity of the SOS 1.0 model, which has been addressed in SOS 2.0. WP4 is defining a quality extension for ObservationOffering, based on the GeoViQua Quality Model. The broker will harvest this information and map it to the Broker model. Being the latter based on the GeoViQua Quality Model as well, we anticipate the mapping will be straightforward. WP4 will identify a number of relevant quality indicators and define corresponding additional queriable properties of the CSW-ISO interface, realizing the CSW-ISO-Q extension, which will enable quality-enabled discovery and access to data. Considering visualization of data quality in the portal, alternatives include in first instance, statements about quality information availability (e.g., via icons), and when available, 2D charts, intercomparison maps, or quality/error flags on the user’s query result list, metadata description or 3D globe. Also, when the data is part of a time series, trends in the data and its quality can be represented. Peer-review inclusion requires features such as decoupling of metadata results from where they are stored, editing metadata (with the compulsory regard to access rights), external linking of metadata with related reviews and comments (e.g., free-text comment, data rating, user details –identity, company/agency, contacts-, automatic recording of date/time comments, interactive links) or creating directs links between portal and source database. The broker, as presented in EuroGEOSS in Madrid (January 2012), understands the diversity of services and standards across disciplines and thus implements components that account for quality and tagging, discovery, access, semantics and composition. Another relevant feature would be the versatility in its internal data model that is flexible enough to be able to incorporate the evolution of standards that the GeoViQua quality model requires. The current implementation of the EuroGEOSS broker already preserves quality and lineage information when the original metadata records in the federated catalogues are ISO19115 metadata records. The new challenge is to be able to better integrate other catalogues in the federation and to extend the EuroGEOSS internal metadata model to include the new GeoViQua requirements for the producers and the consumer model. With the incorporation of capacity catalogues that the EuroGEOSS broker integrates, the clearinghouse contains only a part of the metadata available from the GCI. This activity proposes to extend the quality elements in metadata records assessment of the


17

clearinghouse to the other capacity catalogues to find out how much quality information can be extracted and the best way to harmonize metadata records in the EuroGEOSS broker without losing quality information. The list of capacity catalogues that are currently connected to the EuroGEOSS broker are at least:

EEA SDI Catalogue One Geology IODE SeaDataNet Catalogue NOAA Unified Access Framework Catalogue EuroGEOSS Discovery Broker NASA Global Change Master Directory Observations from IIA South Africa Environmental Observation Network INPE EnviroGRID some Web Accessible Folders some Web 2.0 resources

Visualizing quality metadata on the GEO Portal XSL Transformations (XSLT) also can be used for generate HTML, so that is useful to visualize quality in the web. A GeoViQua study on the metadata in the GEOSS Clearinghouse (Sevillano et al., 2012), reveals that approximately 20% of the records contain some reference to quality indicators formalized following ISO 19115 in XML form, and at least a DQ_Element is provided (http://geoinfo.dlsi.uji.es/eurogeoss/pdfs/43.pdf). This evidence that many resources in the clearinghouse are following the QA4EO principles and particularly, QA4EO-QAEO-GEN-DQK-002. The need to assign to all data / information products a Quality Indicator (QI). This information is provided to the users but no effort has been made to make it more visible in the GEO Portal. In order to make quality elements more visible in ISO metadata records in the GEO Portal, such as quality indicators, lineage and usage, we propose to use XSLT transformations to make quality elements more apparent to users. Quality indicators will be classified into the 5 categories that ISO 19115 declares: positional accuracy, thematic accuracy, temporal accuracy, completeness and logical consistency. Also non quantitative soft knowledge such as lineage/provenance and usage information will be included. Additionally, a metadata comparison tool that will make it possible to compare quality indicators between 2 or more metadata records coming from different datasets is proposed.


18

Quality and provenance indicators derived from EO metadata formats Nowadays, there is a large quantity of Earth Observation (EO) data distribution sources. This available data comes not only from government agencies but from private entities or directly from final users (in case of derived products of the EO data). The distribution of these data is carried out in different formats according to the content, the source, the processing level, etc. therefore, this variety in the data involves a variety of formats in which they are stored and also a variety of formats for the corresponding associated metadata distributed. This activity will explore the possibility of being able to create tools to automatically extract quality parameters for these metadata formats and generate independent metadata records that can be easily harvested by the GEOSS Clearinghouse or the EuroGEOSS broker. This work continues the activities of the section 2.3.2 Data, Metadata and Products Harmonization from the Data Harmonization Working Group (DHWG) Engineering Report GEOSS Architecture Implementation Pilot, Phase 3. All imported metadata will fill a common GeoViQua metadata model for quality that is based on ISO19115 metadata model with some extensions and described in D 6.1. When possible this deliverable provides complete crosswalks for each case relating the quality metadata in the original format and the ISO19115 as a tool for future automation in metadata mining. In the next sections, these metadata formats are analyzed:

Metadata embedded in data files CEOS HDF NetCDF

Metadata from files associated to data NDF Landsat GloVis/Earth Explorer Format SPOT DIMAP ESA EO formats (satellite based, L2)

Transversal formats Content Standard for Digital Geospatial Metadata Dublin Core THREEDS

First of all, it is necessary to know that the formats chosen have been provided by different sources and encode information differently. Examples of data formats with embedded metadata and with metadata in associated files have been chosen, and also files in some typical metadata formats for the distribution through the Internet. From a general perspective, the richest metadata content is found in the CEOS format. This format contains a large amount of information documenting metadata from the


19

moment when the image was taken till the last process applied. Other formats such as the distribution format used by GloVis or Earth Explorer for the Landsat imagery or the NDF are much more simplified and easily accessible to the user since they are encoded in text files. Furthermore, HDF and NetCDF give freedom to the data provider for the metadata documentation making building a generic metadata import tool difficult. Thus, different formats and approaches give different emphasis to the documented attributes. It is interesting to see how some of these formats take a pixel level approach (e.g. DIMAP) while, in general, the most used is a dataset approach. However, the most common metadata for all formats give emphasis to the data creators and its processing (having rich lineage), and it's difficult to find quantitative measures of the error of a layer (poor quality indicators). As will be seen bellow, the content of metadata referred to quality is quite irregular depending on the format.

Metadata Embedded in Data files Several Earth Observation images are distributed in binary formats with embedded metadata. The metadata content in this distributed data depends directly on data providers. A flexible data format may favor the emergence of data providers using it but also becomes a source of heterogeneity in the metadata content. On the other hand, closed formats will be used in an exclusive way for a data producer distribution but continuity on the metadata content is almost guaranteed. In this section some of these data formats with embedded metadata are described.

CEOS CEOS (Committee on Earth Observation Satellites) defines an standard format used by the European Spatial Agency (ESA) for the distribution of the Landsat TM and ETM+ (Thematic Mapper and Enhanced Thematic Mapper) optical sensor products (CEOS format specification, 2003). A CEOS image is a multiband format composed by different binary files organized in volumes. At least a volume contains the volume directory file (VDF) which describes the structure of the volume:

· Imagery Logical Volume · Volume Directory File (VDF) · Leader File (LEA) · Imagery File (DAT) · Trailer File (TRA)

· Supplemental Logical Volume · Volume Directory File (VDF) · Supplemental File (SUP)

· Calibration Logical Volume


20

· Volume Directory File (VDF) · Calibration File (CAL)

· Null Logical Volume · Volume Directory File (VDF)

The imagery logical volume, contains the imagery data itself and related image-synchronized information, plus only that support data related to the scene. In other words, such orbital information such as ephemeris and attitude data is specifically excluded from this volume, as it is station-specific. If no supplemental information is required, then the data set may consist of an imagery logical volume only. The supplemental logical volume is defined in general terms to contain station-related processing data, such as annotation, ephemeris, attitude data, and raw or processed Payload Correction Data (PCD). The ESA supplemental logical volume consists of one data file only, whose content is raw PCD and mission telemetry data relevant to the image data supplied. The content of each PCD record is defined in relation to one major frame of PCD data, which, in turn, can be linked to the video data by means of the satellite time code. The number of PCD records included in the supplemental file is dependent on the application of the product. The calibration logical volume contains calibration data acquired from the Landsat satellites within the Landsat data stream. The role of the null logical volume is to end the set of volumes. Annex A1 contains the crosswalk between the CEOS format and the ISO 19115. This crosswalk gives information of the byte, length and description of the different metadata records related with quality in the CEOS format and its equivalence in the ISO 19115. We were not able to find neither quality indicators nor information about usage but several aspects related to 19115-2 (ISO/TC211, 2009) acquisition parameters were found. Also, there are 39 fields that describe different image processing steps that can be assimilated to lineage and process steps metadata records. An example of these records is shown below: Table 4. Example of acquisition parameters that describe different image processing steps in CEOS format.

LEADER FILE Geometric correction designator

Id Byte Length Type, Encoding

Description

39 1525 1 string(A)

Forward/reverse alignment. Part of the geometric correction designator, which is a set of 16 1-byte codes, each specifying whether the identified correction has been applied (value='Y')


21

or not (value='N')

39 1526 1 string(A) Detector placement and delay 39 1526 1 string(A) Mirror scan profile 39 1528 1 string(A) Line length information 39 1529 1 string(A) Gyro data

39 1530 1 string(A) Angular displacement sensor (ADS) data

39 1531 1 string(A) attitude correction system (ACS) data 39 1532 1 string(A) Ephemeris data 39 1533 1 string(A) Scan gap 39 1534 1 string(A) ground control points. 'Y' in case of L1T 39 1535 1 string(A) Earth rotation

39 1536 1 string(A) sensor altitude and panoramic distortion

39 1537 1 string(A) Digital terrain model (DTM). 'Y' in case of L1T

39 1538 1 string(A) PCD available or not

39 1539 2 string(A) Ephemeris used. Set to 'P' for PCD, 'D' for Definitive or blank if unknown.

Summarizing, the metadata content can be considered dataset oriented. Moreover, the major quality related metadata documents the data provenance and basically refers to processes, processors and providers.

HDF The Hierarchical Data Format, or HDF, is a multiobject file format for sharing scientific data in a distributed environment. HDF was created at the National Center for Supercomputing Applications (www.ncsa.illinois.edu), and is now developed and maintained by the HDF Group (www.hdfgroup.org), to serve the needs of diverse groups of scientists working on projects in various fields. HDF was designed to address many requirements for storing scientific data, including:

Support for the types of data and metadata commonly used by scientists. Efficient storage of and access to large data sets. Platform independence. Extensibility for future enhancements and compatibility with other standard formats.

Mainly there are 2 version of the HDF: HDF4 and HDF5. The internal structure is completely different and they require a different set of tools for accessing. Nevertheless, they share a set of common concepts. The HDF format allows storing metadata elements in them but most of the EO products do not use this approach but one based on the HDF-EOS dialect. HDF-EOS is a data format extended from the HDF2 by NASA’s EOS project group. An HDF-EOS file contains metadata that conform to the self-describing ECS metadata model


22

(Taaheri, 2001). This kind of files contain three families of global attributes, called ‘‘coremetadata.X’’, ‘‘archivemetadata.X’’, and ‘‘productmetadata.X’’, where ‘‘.X’’ is a sequence number beginning at 0 and running as high as 9. The file also contains a family of granule level attributes called ‘‘StructMetadata.X’’. The metadata in ‘‘coremetadata.X’’ are core metadata defined by Earth Observing System Data and Information System (EOSDIS) and common to most EOSDIS products. The core metadata consists of basic data attributes, such as spatial and temporal information. The attributes ‘‘archivemetadata.X’’ and ‘‘productmetadata.X’’, contain product-specific metadata that consists of information such as instrumental and archiving information on individual or specific data products. A third type of metadata, called structural metadata, is contained in ‘‘StructMetadata.X’’ and is used to describe the Point, Swath, and/or Grid data structures. These metadata can adequately describe an individual HDF-EOS data file at both the collection level and granule level, cataloging the HDF-EOS data for user search and retrieving core metadata and part of the product specific metadata. There are many kinds of HDF-EOS data products with also many subtypes. The global attributes in an HDF-EOS data file contain metadata, in ECS format, that describe the file itself at both the collection and granule levels. The heterogeneity in the metadata format of the different kinds and sub-kinds of HDF files makes difficult to analyze this format in a generic way in order to transform their metadata to the ISO 19115 (Wei et al., 2007). Different American government bodies use this format for their data distribution. Some of the most popular Earth Observation data distributed in HDF are the images, and its derived products, from the MODIS sensor. One of the peculiarities in the distribution of these derived products (e.g. Cloud Mask product or Snow product) is that, a part of the metadata embedded in the header file (which can be considered dataset oriented), a quality raster band is found in the dataset as pixel oriented quality information. As an example of the previous explanation, next figure shows a screenshot of the quality band of a MODIS Snow Product (MOD10A1).


23

Figure 2. Example of a Snow Spatial QA band. MOD10A1 2004256.

Each pixel in this quality band can acquire a value between 0 and 15 corresponding to the different combinations of the values on the 4 bits that encode the information. Bit 0 an bit 1 have a common meaning across all MODIS land products and give information about the general quality of each pixel (nominal/abnormal, cloudy/invalid). Bit 2 flags the occurrence of observations that lie in the viewing azimuth range of 150 to 210 degrees. Bit 3 flags the occurrence of theobservations in a cell that fall below the minimal coverage threshold of 20% considered to be a good observation. - State of bits 0 and 1:

00=nominal 01=abnormal 10=cloud 11=invalid

- State of bit 2: 0=within azimuth limit 1=beyond azimuth limit

- State of bit 3: 0=over observation coverage minimum 1=under observation coverage minimum


24

The detailed description of each value can be found at the National Snow And Ice Data Center (NSIDC) website: http://nsidc.org/data/docs/daac/mod10_modis_snow/snowcover_qa.html An additional metadata standard that includes a HDF implementation is the Generic Earth Observation Metadata (GEOMS) standard (http://avdc.gsfc.nasa.gov/GEOMS).

NetCDF The Network Common Data Form (netCDF) is one of the primary methods of self-documenting data storage and access in the international geosciences research and education community and beyond. NetCDF was designed for use in a networked environment. A few of the earth science studies institutions that use netCDF are: NOAA’s Climate Diagnostics Center (CDC), NASA’s Halogen Occultation Experiment (HALOE), The global ocean modeling effort at Los Alamos National Laboratory (LANL), Lamont-Doherty Earth Observatory (LDEO) of Columbia University, the National Center for Atmospheric Research (NCAR), the Commonwealth Scientific and Industrial Research Organization (CSIRO) Division of Atmospheric Research in Australia, The Earth Scan Lab, a High-Resolution Picture Transmission (HRPT) ground station at the Coastal Studies Institute, Scripps Institution of Oceanography (SIO), and Sandia National Laboratory. There are four netCDF format variants:

the classic format the 64-bit offset format the netCDF-4 format the netCDF-4 classic model format

The classic format was the only format for netCDF data created between 1989 and 2004 by the reference software from Unidata (www.unidata.ucar.edu). It is still the default format for new netCDF data files, and the form in which most netCDF data is stored. In 2004, the 64-bit offset format variant was added. Nearly identical to netCDF classic format, it allows users to create and access far larger datasets than were possible with the original format. (A 64-bit platform is not required to write or read 64-bit offset netCDF files.) In 2008, the netCDF-4 format was added to support per-variable compression, multiple unlimited dimensions, more complex data types, and better performance, by layering an enhanced netCDF access interface on top of the HDF5 format. At the same time, a fourth format variant, netCDF-4 classic model format, was added for users who needed the performance benefits of the new format (such as compression) without the complexity of a new programming interface or enhanced data model. With each additional format variant, the C-based reference software from Unidata has continued to support access to data stored in previous formats transparently, and to also support programs written using previous programming interfaces.


25

Again, the heterogeneity in the content of the header and the lack of information makes difficult to analyze the metadata. However, an initiative to extend the metadata of this format for the geographic data has been proposed: the NetCDF Markup Language (NcML) and its GML-based extension (NcML-GML). Thus NcML is a natural augmentation of NetCDF objects in an XML form. There also exist different conventions proposed by user communities in order to standardize the metadata content in the netCDF files. These conventions consist in instructions to improve the hierarchical structure of the content and proposals for the homogenization of metadata attributes in different working fields. Then, if present in a netCDF file, ‘Conventions' is a global attribute that is a character array for the name of the conventions followed by the file and it is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. At the following link, at the Unidata website, all the currently available conventions can be found: http://www.unidata.ucar.edu/software/netcdf/conventions.html An additional metadata standard that includes a netCDF implementation is the Generic Earth Observation Metadata (GEOMS) standard (http://avdc.gsfc.nasa.gov/GEOMS). The importance of using these conventions is that it makes easier to generate tools to work with minimal intervention on the datasets by the user. Its purpose is to restrict the metadata representation helping the development of software that automatically read and relate them to dataset. One of the most used convention is the Climate and Forecast (CF) convention (http://cf-pcmdi.llnl.gov/). The conventions for CF metadata are designed to promote the processing and sharing of files created with the NetCDF API. The CF conventions are increasingly gaining acceptance and have been adopted by a number of projects and groups as a primary standard. The conventions define metadata that provide a definitive description of what the data in each variable represents, and the spatial and temporal properties of the data. This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities. In general, conventions have been thought basically for climate and forecast datasets, this constrains their potential uses. Even so, the netCDF format allows adding any attribute out of these guides, but this procedure will difficult the processing automation. Any of the currently in use conventions are specifically designed for Earth Observation data, but there are conventions designed for gridded dataset, as the case of the CDC (NOAA’s Climate Diagnostic Center) convention. Conventions are basically focused on metadata defining measure units and spatial references. Attributes referred to quality have only been found in the CDC and the Dataset Discovery NetCDF Attribute (ACDD) conventions.


26

The CDC convention provides the opportunity to document the attribute “History”. This attribute is designed for documenting the processes applied to the data:

History -- brief description on multiple lines of the procedures used to generate the file. The description should include:

- an attribution for CDC and the initials (in reverse order if privacy is desired)

of the individual that generated the file. - the source dataset and name(s) or range of the input file(s) - the date the file was generated - the name of the software package or a description of the custom source

code used to create the file.

Here's an example of a history attribute:

Created by NOAA-CIRES Climate Diagnostics Center Data Management Group (SAC, [email protected]) from the NCEP Reanalysis data set on 1997/07/03 by ltmmaker using /Datasets/ncep.reanalysis/surface_gauss/air.sfc.73.nc thru /Datasets/ncep.reanalysis/surface_gauss/air.sfc.96.nc When a file is updated, the original history attribute contents should be retained and prefixed with information about the changes

The ACDD convention also supports the “History” attribute and adds some attributes for the documentation of metadata related to responsible parties (creator name, url, email,…), data identifiers, data processing level, etc. Many of the attributes defined in this convention are included in the ISO Core specification, and a crosswalk exists between these attributes and the ISO 19115 and also with the THREDDS metadata format. This crosswalk can be found here: https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery and in Annex A2 It’s also relevant to mention that a recently approved OGC Discussion Paper (Bigagli, 2011) specifies the netCDF-U Conventions, whose intended use is to formally qualify the uncertainty information intrinsic in geospatial data encoded in the netCDF-3 format, by means of concepts from the UncertML best practice of the UncertWeb project (UW-D1.2, 2011). As uncertainty is an aspect of quality, netCDF-U may be relevant to GeoViQua, e.g. for data sources implementing OGC standards that make use of the netCDF3 data format, e.g. the netCDF Encoding Format Extension of the Web Coverage Service Interface standard (under discussion). The NetCDF-U Conventions are designed to be fully compatible with the netCDF Climate and Forecast Conventions, the de-facto standard for a large amount of data in the Fluid Earth Science community.


27

The NetCDF-U approach uses appropriate attributes within the netCDF file to associate UncertML dictionary definitions to netCDF variables. The relevant excerpt from the specification document is reported in Annex B. This is a format used by different partners in the GeoViQua project; so many data involved in the different proposed scenarios are encoded in NetCDF. Moreover, it must be take in to account that some partners are involved in the creation of the extension for documenting the uncertainty in this kind of files (NetCDF-U). Due to its condition an open source format file, and because it gives strength and freedom to encode metadata, it seems necessary for GeoViQua to program software tools for reading and writing NetCDF files in order to facilitate the exchange of data between the different centres involved in this project. Regarding this point, CREAF is working in an import and export tool between netCDF and other raster formats. This tool is being programmed in C and uses the HDF group SD (Scientific Data) API functions for an automatic access to the netCDF data and also other libraries from the MiraMon GIS&RS software. These functions allow the access to the data through it index number. The following functions of the SD API are being considered:

1. SDstart : Initializes the SD interface. 2. SDfileinfo : Retrieves information about the contents of a file. 3. SDselect: Selects an existing SDS using its index. 4. SDgetinfo: Retrieves information about a data set. 5. SDattrinfo: Gets information about an attribute. 6. SDreadattr : Reads the values of an attribute specified by its index. 7. SDreaddata : Reads data from a data set.

At this moment, the workflow for reading, accessing and importing netCDF files is designed:


28

Figure 3. Workflow schema for reading, accessing and importing netCDF files.

The code is also capable to read the metadata documented in these files. The tool being developed is now allowing us to import netCDF files to the MiraMon format. However, some parts of the existing code must be enhanced in order to obtain a properly geolocation of the data sets.

Figure 4. The figure on the right shows a netCDF file opened with the NASA software Panoply, in the left side the same file has been opened with the new developed tool.

In an immediate future CREAF will develop the exporting part of the code in order to really complete these tool for interchanging data. It also will be necessary to find ways for adapting the existing conventions in order to include the quality elements described in the


29

ISO 19115 and the modifications proposed by GeoViQua, and if necessary, these conventions will be extended.

Metadata from associated files Previously we have seen how information relative to data can be embedded in the same file that contains the data. There also exist alternatives to this model of data distribution. Many providers use generic data formats for their Earth Observation images adding text files to the distribution package containing the metadata. Next sections will describe some examples of this strategy for data distribution.

NDF NDF is the acronym for NLAPS (National Landsat Archive Production System) Data Format. This format was primarily used by the USGS (EROS Data Center, http://eros.usgs.gov) for distribution of geometrically and radiometrically corrected Earth Observation images. The NDF format contains:

- Image files with extension .I <band #>, where <band #> is an integer ranging from 1 to the number of bands in the product for BSQ.

- Header file (.h1) - History and processing parameters file (.hi) - Work Order report file (.wo)

The header file describes the product delivered and provides necessary information for further processing. It’s an ASCII file where different parameters and metadata appears listed to complement the image information. This file contains information about the acquired image (bands, wavelength of each band and gain and bias applied, number of lines and columns per band, bytes per pixel, path and row, etc.), information about the reference system (map projection, map zone, projection parameters, ellipsoid parameters, corners coordinates, etc.), information about the mission (platform and sensor id, acquisition time and date) and also information about sun position in the moment of the acquisition. Each NLAPS data product contains a processing history file. This ASCII-text file provides documentation about the original customer request and the processing parameters used to produce the NLAPS digital product.


30

Figure 5. First lines of a Processing History File.

Finally, the Work Order Report file is an ASCII-text file that contains information related to the specific order for the data processing at the processing center. The processing history file and the Work Order Report are not the typical tagged metadata files. The content of both files is presented in text format and includes valuable information related to the lineage of the image. All metadata in the NDF format can be considered dataset oriented Annex A3 contains the crosswalk between the NDF format and the ISO 19115

Landsat GloVis/Earth Explorer Format USGS Global Visualization Viewer (http://glovis.usgs.gov) and USGS Earth Explorer image catalogues (http://earthexplorer.usgs.gov/) allows the download of different satellite images all around the world. In the Landsat imagery case, these data is offered in GeoTiff format (one GeoTiff for each band) and is followed by some ASCII metadata files. Basically three metadata files are found:


31

- The *.MTL file - The *.Meta file - The *.GCP file The MTL and the Meta files are tagged files containing dataset oriented metadata. The first one, the *.MTL file, is an ASCII file that comes together with the downloaded image. This file contains the major metadata related with the captured scene as the calibration parameters, the reference system, product identifiers and also some quality metadata depending on the version of the software used to process the image (in some cases, e.g. RMS error relative to the geometric correction can be found).

Figure 6. Part of an MTL file where lineage information can be detected. The *.Meta File is not included with the downloaded package. It must be obtained directly from the GloVis server. This file has a similar structure to the MTL file and contains some redundant information about the scene that also appears in the MTL file. However, there is some metadata that only can be found here like the cloud cover information or the image quality code. Finally, the *.GCP file is only available for images in L1T processing level. It is a text file containing tabulated information about the geometric correction process. Specifically, it contains the list of ground control points used for correction of the image, offering the X, Y, Z position of the every point as well as it residual in x and y directions. Positional accuracy can be calculated using this information. Annex A4 contains the crosswalk between the GloVis format and the ISO 19115


32

Figure 7. Example of the first lines of a GCP file.

SPOT DIMAP SPOT imagery (www.spotimage.com) is distributed in Tiff format (a unique Tiff file containing all image bands) and accompanied by a Dimap file containing the metadata. Dimap metadata is implemented as a XML file and uses the ‘.dim’ extension. The distributed package contains the following files:

- VOL_LIST.DIM: XML file describing the contents of each folder - VOL_STYL.XSL: stylesheet used to apply HTML formatting to VOL_LIST.DIM file - VOL_LIST.PDF: Acrobat file describing all the dataset - LOGO.JPG: Spot Image logo used with the stylesheet file - At least one folder named SCENE01

The SCENE01 folder contains:

- The Dimap product (GeoTIFF and XML files) - Three additional files needed for automatic display of the accompanying metadata (image icon, quicklook and stylesheet for applying HTML formatting to the XML file). SCENEXX folder contents: - METADATA.DIM: XML file describing the image part - IMAGERY.TIF: image file in GeoTIFF format - ICON.JPG: image icon - PREVIEW.JPG: quicklook - STYLE.XSL: stylesheet used to apply HTML formatting to METADATA.DIM file


33

The information contained in the Dim (XML) files is also summarized in a PDF file in a user friendly format. This XML file is not an ISO 19139, it follows an own format designed by SPOT Image. These files contain the major metadata related with the captured scene as the calibration parameters, the reference system, product identifiers and also some quality metadata. As an example of this type of file, some lines are showed below:

Figure 8. Example summary of a Dim (XML) file. Most metadata is related to the whole dataset, but there is also a section in the Dim file with pixel oriented metadata. In this section the aberrant pixels of the image are listed.


34

Annex A5 contains the crosswalk between the DIM format and the ISO 19115

ESA EO File Formats (satellite based, level 2) This section discusses quality metadata and provenance information in file formats for ESA satellite-based EO missions that have been operational over the past decade or will become operational within the next decade, including ENVISAT, the ESA Earth Explorer missions, and Sentinel missions. This section focuses on so-called Level-2 datasets that contain measured or processed quantities that are of primary interest to the end user. Examples of such quantities are concentration of trace gases in the earth atmosphere (ENVISAT-GOMOS/MIPAS/SCIAMACHY mission), atmospheric ground elevation altitude (ENVISAT-RA2, CRYOSAT-2 mission), ice freeboard height (CRYOSAT-2 mission), soil moisture and sea surface salinity (SMOS mission), or wind speeds (ADM-AEOLUS mission) These quantities result from data processing that process raw Level-0 data packets as received from the satellite down-link into Level-1 data containing calibrated physical quantities, which are then processed into the Level-2 data mentioned. Level-2 datasets are typically organized as a sequence of individual data products each covering a specific time period, such as an orbit, a day, or the time corresponding to a single measurement mode. Each product itself consists of individual measurement records that contain the measured quantity value(s) for the measurement as well as several annotation data, such as a specification of the applicable geolocation area, measurement time (or time period) and quality information (which is explained further on). The time period and geolocation area that is covered by a single measurement varies between missions. Measurement time periods can be as short as seconds/minutes and associated geolocation areas can be as small as meters/kilometres. For datasets involving atmospheric quantities, such as ozone concentrations, annotation data often includes the measurement altitude (range). Product formats used have evolved over time and include:

Dedicated binary file formats. Example: ENVISAT core product formats (ref. http://envisat.esa.int/support-docs/productspecs/).

Formats that include 2 physical files, one containing product metadata in XML-

format, and the other containing the actual measurement data in a dedicated format (which may for example include binary formats, or XML-ASCII). Example: Earth Explorer File Formats include an XML-header (.HDR) file, and a measurement Datablock file (.DBL) (ref. http://earth.esa.int/pub/ESA_DOC/GOCE/Format-Standard-1.4.pdf). The inclusion of a separate meta-data file facilitates queries on the dataset.

Formats that target a generic approach for including (often XML-formatted)

annotation data and measurement data. Example: SAFE format (ref. http://earth.esa.int/SAFE), which cite: “conforms to the ISO 14721:2003 OAIS (Open Archival Information System) reference model and related standards such as


35

the emerging CCSDS/ISO XFDU (XML Formatted Data Units) packaging format”. The SAFE format will be used for the Sentinel EO missions.

Quality information related to satellite based EO missions is reported for different scopes:

Mission/instrument scope: Extensive documentation is available that describes the mission quality objectives, for example required accuracies on measured quantities, and the flow-down of these objectives into a realisation of the instrument, all hardware and software necessary to operate the instrument in-flight, and all hardware and software necessary to process the instrument “raw” measurement data into the quantities that are of primary interest to the end user. This flow-down also includes analyses of instrument design and adjustment procedures (calibration) to ensure a required data quality. The overall performance of the mission is often analysed by validation of instrument measurements using independent datasets, such as ground based measurements or other missions/instruments measuring the same quantity. Results of such analysis are compiled into scientific publications.

Dataset scope: in addition to the aforementioned dataset validation, several initiatives on providing quality information on dataset level to users exist or are being developed, such as:

o Quality Disclaimer reports that are made available to the end user community as a “readme” to the dataset, or through web pages and/or e-mail.

o Envisaged (quality) metadata information to be provided on datasets through the GMES Space Component (GSC) Data Access (GSCDA) component (http://gmesdata.esa.int/web/gsc/data_access), where GMES stands for Global Monitoring for Environment and Security. This may include information disseminated through the GMES Coordinated Quality Control (CQC) service.

o The ESA Generic Environment for CalVal Analysis (GECA) project includes the definition and implementation of a Quality Information and Action Protocol targeted at obtaining and providing information on data quality from/to end users.

Data product (file) scope: Data products include quality information as annotation data that is either part of the product header, or as a quality information recorded inside the file. Such quality information may include:

o Information on the time period covered by the product o Processing software/hardware information o A verdict on the overall product quality, e.g. “ok” or “product has errors” o Statistics on the reported quantities in the product, such as number of

successfully processed values, number of range check violations, etc. o Provenance information (see also below)

Measurement scope: Level-2 products typically include several quality indicators for each measurement, such as:

o An overall quality flag, indicating whether the measurement result is fit for use. Examples of cases where this flag is set to invalid are an instrument or data anomaly leading to a corrupt measurement, or a failure of a processing algorithm to converge.


36

o Several statistics and quality flags indicating special conditions related to the processing of the value, such as number of iterations of the processing algorithm, chi-square values, saturation flags, dusk/dawn conditions that may affect data quality, cloud conditions etc.

o Estimates on the errors associated to the measured quantities, which include standard deviations and in some cases even covariance matrices.

Full traceability on reported values is a standard requirement for L2 datasets, and as such various provenance informations is provided with the datasets, such as:

References to the mission/instrument corresponding to a dataset. For the SAFE and earth explorer file formats, this occurs through mission/instrument fields in the product header annotation. For ENVISAT mission and instrument are indicated by the product file name, which requires additional knowledge on file naming conventions. These conventions are documented in product format specification documents (see also below).

References to the measurement raw data value(s): this is provided by the annotated measurement time (measurement scope) and a file name reference to the source Level-1 product (product scope) which itself contains a file name reference to the raw data Level-0 product.

References to the instrument configuration corresponding to a measurement. This is often handled by including measurement mode information and housekeeping data in the raw-data products corresponding to the measurement (see also previous item).

References to the data processing hardware, software and data processing configuration used in generation of the measurement value:. File formats typically include references to:

o a processing facility ID (Processing station, Source ID) o the data processor software and/or data processor software version o an overall data processing configuration ID or processing stage ID, such as

“near-real-time” processing, “off-line processing”, or “reprocessing campaign 1”

o Individual configuration files that contain processing parameters. A very common type of configuration file is the Auxiliary Data File that contain instrument calibration parameters resulting from calibration measurements performed with the instrument during the mission

Documentation on how the measurement value is calculated from the raw data, including a description of processing algorithms (Algorithm Theoretical Baseline documents, Detailed Processing Module documents), input/output files (Product Format Specifications), and operational scenarios.

Note that information included in L2 datasets often adheres to standards that are specific to a mission (ENVISAT) or a set of missions (Earth Explorer Missions, Sentinel). On the other hand, several initiatives for generalizing quality information concepts over missions exist, such as the aforementioned GMES GSCDA, CQC and GECA projects.

Transversal Formats


37

Finally, there are metadata files published in catalogs and created by various sources according to different coding standards. These files, which in the next section some examples will be discussed, have been included in what have been called transversal data formats.

Content Standard for Digital Geospatial Metadata The Content Standard for Digital Geospatial Metadata (CSDGM), often referred to as the Federal Geographic Data Committee (FGDC) Metadata Standard, is a publication authored by the FGDC that specifies the information content for digital geospatial datasets. The purpose of the standards is to provide a common set of terminology and definitions for concepts related to the metadata. All U.S. government agencies (federal, state and local) that receive federal funds to create metadata must follow this standard. The information included in the standard was selected based on four roles that metadata play:

Availability -- data needed to determine the sets of data that exist for a geographic location.

Fitness for use -- data needed to determine if a set of data meets a specific need. Access -- data needed to acquire an identified set of data. Transfer -- data needed to process and use a set of data.

This standard is intended to support the collection and processing of geospatial metadata. It is intended to be useable by all levels of government and the private sector. The standard is not intended to reflect an implementation design. An implementation design requires adapting the structure and form of the standard to meet application requirements. The standard is organized in a hierarchy of data elements and compound elements that define the information content for metadata to document a set of digital geospatial data. The starting point is "metadata". The compound element "metadata" is composed of other compound elements representing different concepts about the data set. Each of these compound elements has a numbered section in the standard. In each numbered section, these compound elements are defined by other compound elements and data elements. The section "contact information" is a special section that specifies the data elements for contacting individuals and organizations. This section is used by other sections, and is defined once for convenience.


38

Figure 9. General structure of the FGDC Metadata Standard.

As it can be appreciated in the figure above, this standard contains three main sections (1, 2 and 6) and two supporting sections (8 and 10) that are interesting for GeoViQua. Section 1 is dedicated to the identification of the dataset. Some elements that must be highlighted are the Citation element (information used to reference the dataset), the Status (the state of and maintenance information for the dataset), Access and Use Constraints (restrictions and legal prerequisites for accessing and using the dataset), Point of Contact (contact information for an individual or organization), Native Dataset Environment (a description of the dataset in the producer’s processing environment, including items like the software, the operating system, the file name or the file size). Section 2 refers to data quality information. The next figure shows the general structure of this section:


39

Figure 10. Section 2. Data Quality Information.

Section 6 covers the distribution information. Information about the distributor and options for obtaining the data set must be provided, and also the distribution liability (statement of the liability assumed by the distributor). This section also includes the possibility to document the order process, the technical prerequisites that the user must take into account the time period when the dataset will be available from the distributor. The supporting sections 8 and 10 provide a means of stating the citation of a dataset and of identifying individuals and organizations, and are used by other sections of the metadata standard. These sections are never used alone. A complete crosswalk between this standard and ISO 19115 can be found in; http://www.fgdc.gov/metadata/documents/FGDC_Setions_V40.xls


40

Dublin Core The Dublin Core is a simple set of metadata elements thought for the description and cataloguing of different type of resources found on the Internet (files, maps, books, catalogues, papers, websites, services, etc.). This set of metadata is composed by 15 elements defined by the Dublin Core Metadata Initiative (DCMI, http://dublincore.org), an open organization supporting innovation in metadata design and best practices across a broad range of purposes and business models. The 15 elements defined by the DCMI are all optional and can be repeated (they have n cardinality). Moreover, they have a limited set of attributes that can be optionally used to refine the exact meaning of an element. Of these 15 items, the Source element must be highlighted, designed to document the lineage of the layer, and also 6 elements related with the citation of the layer itself (eg title, creator, identifier, etc.). The Dublin Core allows:

Creating and maintaining in a simplified way a reduced set of metadata that makes possible an effective search of resources on the Internet.

Unifying the meaning of its elements among all users worldwide. Extending the basic set of metadata elements for the correct definition of newly

emerging resources and solving their description needs. For the purposes of the GeoViQua project, the Dublin Core metadata model is too simple and will not be used. Annex A6 contains the crosswalk between the DCMI format and the ISO 19115

THREEDS THREDDS (Thematic Realtime Environmental Distributed Data Services) is middleware to bridge the gap between data providers and data users. Catalogs are the heart of the THREDDS concept. They are XML documents that describe on-line datasets. Catalogs can contain arbitrary metadata, and also there is described a standard set of metadata. The standard set of metadata is given in XML format following de ISO models. Almost all the data sets in these catalogs present complete metadata information, however some of them not. The current focus of the THREDDS development is the THREDDS Data Server (TDS), a web server that provides catalog, metadata, and data access services for scientific datasets.


41

The TDS uses the Common Data Model to read datasets in various formats, and serves them through OPeNDAP, OGC Web Coverage Service (WCS), OGC Wep Map Service (WMS), NetCDF subset service, and bulk HTTP file transfer services. Currently, the next groups of datasets are available:

- NCEP Model Data - FNMOC Model Data - Radar Data - Station Data - Point feature collections - Satellite Data - Unidata Real-time Regional Model - Unidata GALEON Experimental Web Coverage Service (WCS) datasets.

The fact that the metadata at THREDDS follows the ISO model makes that potentially it could be the most complete metadata in terms of quality. The problem, then, are the data sources that feeds this catalogue. It is not enough to follow a standard if the documented metadata is not complete.

Workflow and contributions

Extraction and encoding of quality information embedded within datasets This section discusses the access by GeoViQua to quality metadata that is embedded into datasets. As has become clear from Section <*>, it is common practice to include such quality information as part of the data records within a dataset. Note that this information therefore can be sub-dataset level oriented, and even apply to individual pixel values (pixel-oriented), which introduces a requirement on GEOSS/GeoViQua to be able to handle quality metadata on a sub-dataset level. Options for extracting and encoding these data include:

1. Extraction, encoding and submission of quality information by the data provider: When registering a dataset within GEOSS, the data provider may include Quality information (meta-) data records in a standard encoding that can be interpreted (and possibly stored) by the GeoViQua system. These records must then have been previously generated by the data provider from the dataset. An advantage is the simplified architecture of the GeoViQua system. However this requires endorsement of the GeoViQua data quality encoding standard by the data provider (community).

2. Extraction and storage of quality information by GeoViQua into a quality metadata

database: this approach differs from the first option in the sense that the GeoViQua system rather than the data provider is responsible for the extraction and encoding. Quality data are harvested from the dataset, followed by encoding using a suitable encoding scheme, and storage of the quality data into a metadata database that can then be used for querying, analysis and visualization. Advantages include:


42

Increased acceptance by data providers due to less encoding effort from

their side. Once the quality data has been stored into the metadata database, the

GeoViQua system does not require further access to the dataset, which simplifies the system architecture.

GeoViQua can control and maintain the quality encoding standard used for storing quality metadata.

Disadvantages include:

The need for accessing the actual dataset files by GeoViQua at least once. The copying of quality metadata that has already been described within the

dataset. Especially for pixel oriented quality information such as uncertainties, this leads to increased usage of network and storage resources.

The required inclusion of traceability of quality information to data elements within the dataset upon storage in the GeoViQua metadata database: Unless the information applies to the full dataset scope, a reference of the sub-dataset items (such as pixels)to which the quality metadata apply must be accompany the metadata upon storage. This yields complications in terms of how to reference data values within the dataset.

Implementation of the extraction and encoding by the GeoViQua system may take considerable effort, depending on the compliance of the dataset to existing data (quality) encoding standards.

3. Extraction and encoding of quality information upon GeoViQua user request: quality

data are harvested from the dataset as soon as a GeoViQua user requests quality information on the selected (parts of the) dataset such as uncertainties from a dataset. This approach differs from the first option in the sense that the GeoViQua system rather than the data provider is responsible for the extraction and encoding, and that from the second option in the sense that no metadata database is used. Advantages include:

No replication of information: data is harvested “on-the-fly” from the actual dataset files.

Direct traceability of quality information such as uncertainties to the associated data elements within the dataset.

Disadvantages include: The need for data providers to provide a service that provides access to

the dataset files or at least the quality information on-line. The need for development of the quality information exchange

interfaces.

2.2.5. Metadata from data As described in the previous sections various file formats include metadata or associated metadata files that contain information on data quality or dataset quality. Often such


43

information is added to the measurement data by processing software or researchers when the dataset is created. However information on data quality may also be derived a-posteriori from the data, i.e. after the dataset has been created and/or published to the user community. Examples include:

Additional information published by data providers as a result from additional data analysis. In many Earth Observation missions operational Quality Control is applied to measurement data that can yield new information on data quality. The generation of such metadata is performed both automatically by data analysis hardware/software, or by quality engineers responsible for monitoring instrument data quality. Examples of such derived quality metadata are:

o Flagging of data that is found to violate some quality checks, such as threshold checks, outlier detection etc.

o Improvements on data uncertainty by analysing and correcting instrument trends over months of measurement data

o Improvements on measurement data itself by using new analysis algorithms. Results from scientific studies that use the dataset, such as comparison to other

datasets

The ESA Generic Environment for CalVal Analysis (GECA) project includes the definition and implementation of a Quality Information and Action Protocol that provides a standard encoding mechanism for such metadata. For remote sensing missions numerous hardware/software systems exist for extracting and calculating quality parameters based on the data streams they get. However as currently standards are lacking, it requires dedicated reading and processing routines to do the extraction, which is out of scope of the GeoViQua project. An approach that GeoViQua will follow in the next month to come is to infer quality by intercomparison, between different datasets particularly those that represent the same parameter using different modelization strategies.

Metadata punctuation for quality Understanding the global environment depends on the ability of people around the world to share observations and, more importantly, to understand observations made by many users. This understanding depends critically on the documentation of those observations. If detailed documentation is readily accessible and understandable, the data will be trusted and understood, and integrated into the international data system, otherwise, the data will be collected, but not used. Since the beginning of the current century, time of the publication of ISO/TR 19121:2000 Geographic information -- Imagery and gridded data (26/10/2012), a series of international (ISO) metadata standards have emerged that will form the foundation for this understanding. The adoption of these standards in the United States will involve a significant transition in the way the U.S. environmental community documents data and in the ways documentation is used by people and applications. The impacts will extend significantly beyond the data discovery role that has motivated metadata developments abroad over the last several decades to include detailed documentation of lineage, processing and data quality. The focus will be on ensuring that observations are independently understandable by many diverse users.


44

In this section, a new extension of quality data extraction and punctuation tool is described. To help providers to assess the completeness of their metadata records in general and on quality aspects in particular, we propose to extend the rubric system (CORS, 2012) (http://www.ngdc.noaa.gov/metadata/published/NOAA/NESDIS/CLASS/iso) to help them to evaluate how many metadata elements related to quality are provided. This evaluation system incorporated in the rubric will use a criterion that helps producers on improving their quality metadata for better visualization and comparison in the GEO Portal. Moreover, this rubric tool of metadata representation provides a mechanism of better understanding of metadata for data users.

The rubric tool developed by NOAA The software engineering community has recently been very successful by envisioning and implementing the software development process as a series of spirals, each of which addresses a small set of user requirements. Each spiral involves several phases: requirements collection and prioritization, implementation, testing, and, most importantly, on-going interaction with users. Each spiral builds on previous work and requirements are addressed through a series of on-going iterations, each of which results in a more capable system. Like a multi-spiral software development process, the creation of high-quality, complete documentation is an on-going interaction between several groups. It is an end-to-end process that encompasses the complete data life cycle (GEO-IDE, 2012). The rubric quality punctuation is based on the version: 1.0.3 (Rubric, 2012). This is a project under the NOAA (National Geodetic Survey, National Ocean Service, NOAA, U.S. Department of Commerce) development. The rubric tool identifies ISO metadata elements [3]. These elements are classified in groups following the ISO 19115 schema (ISO 19139 [4]) and the information is represented in tables. These tables are called “spirals of documentation” (classes of elements in the ISO 19115 schemas) that visually describe the good documentation. The spirals build a strong foundation for high-quality documentation. Moreover, the ISO Standard includes a number of options for building on that foundation by addressing specific scientific needs. The total results are summarized in a table at the top of the report, called Total Spiral Score. Each spiral is represented by a row in the rubric. The information in rows is classified in the following eight groups: Identification, Connection, Extent, Distribution, Description, Content, Lineage and Acquisition Information. The columns show the percentage of the included elements in the metadata records. There are five groups of percentage (None, 1-33%, 34-66%, 67-99% and All) represented as accumulative results, i.e., a pink bar will appear in the fourth column when the total amount of an specific spiral information is covered about the 67-99%. Following the total spiral score table that acts as a summary, we can find the “Total ISO Core Score” table. This tool uses the ISO 19115 Standard Core Elements in order to test conformance with ISO recommendations. This table, as indicated in the rubric tool, does not count toward the total spiral score. Here, the three ISO categories are represented: ISO Core Mandatory, ISO Core Conditional, ISO Core Optional; plus the Total Core Score.


45

Each of the 8 spirals of information contained in the total spiral score, and the three ISO core groups are extended and represented in separated tables. All the table titles are followed by the score that represents the number of described ISO metadata elements over the total amount of ISO metadata elements (e.g., 22/41). The tables describing each spiral group have 5 columns: Score, Attribute (Count), Description, Best Practice and Path. As has been aforementioned, the rubric tool represents the metadata information following the ISO schemas, so that each of the table columns follows the ISO information and best practices. First, the score information is shown in two different ways, by number and colour. When certain metadata information is provided, a number “1” appears and the background is green. Instead, when there is no metadata information provided, a number “0” appears and the background is red. Second, the Attribute column contains the name of the evaluated element. These elements are listed by name and are followed by M, C, or O if they are Mandatory, Conditional or Optional respectively, as is described in the ISO core metadata schema (ISO 19115). They are followed by UDD (attribute name) if they are included in the netCDF Attribute Convention for Dataset Discovery (https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery). Finally, the Description, Best Practice and Path columns show information extracted from the ISO standard specifications, in some cases, a link to the NOAA twiki page (GEO IDE) is provided in order to redirect the user that wants to receive more information related to best practices.

Representing ISO metadata documents using rubric XSL style sheet In order to have a complete knowledge of the benefits related with the rubric development, it must be said that the XML language defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.

In the first stage of the quality extraction procedure, a sort of points was evaluated in order to decide which method to follow. Some crucial advantages were considered for the final decision. First of all, the main point considered was the previous rubric tool available lacking quality information. Furthermore, other decisive advantages were encountered. The rubric tool is configured as a XSL style sheet that can consequently be added to any XML in ISO metadata records to be visualized. One important characteristics of using the XSL sheets is the application of styles to XML files avoiding its modification. This point merit important consideration when managing big number of data, as is the case in the data contained in the GEOSS catalogues. Another important point to highlight is the possibility of managing all the XML documents in a mechanical and automatic way, which allows reducing the processing time for big data catalogues. In addition, XSL sheets allow interoperable representations, meaning that long number of producers can create their data in a common way obtaining the same style for the result. Finally, users can easily access to the information and visualize it under the same representation, fact that allows data comparison.

In order to better understand how the rubric works, the XSL functionalities are described in the next section.


46

XSL style sheet The Extensible Stylesheet Language (XSL) is a family of recommendations for defining XML document transformation and presentation; this includes all the ISO metadata records following the ISO 19139 schemas. The main difficulty of the XSL language lays on the conjunction of three different languages, these are:

1. XSL Transformations (XSLT) is a language with an XML-based syntax that is used

to transform XML documents into other XML documents, HTML, or other, unstructured formats such as plain text or RTF. It is developed by the W3C XSLT Working Group. One of the transformations allowed is from XML to HTML, supported by several web browsers, including Internet Explorer (using the MSXML engine), Opera (native engine) and Safari. Support in Firefox, Mozilla, and Netscape (all using the TransforMiiX engine) is incomplete. Support of disable-output-escaping does not work which is why HTML Fragments are not rendered properly.

2. The XML Path Language (XPath). It is an expression language used by XSLT, and many other languages, to access or refer to parts of an XML document. XPath is developed jointly by the XQuery and XSLT Working Groups.

3. XSL Formatting Objects (XSL-FO) is an XML vocabulary for specifying formatting semantics. An XSLT style sheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses a formatting vocabulary, such as (X)HTML or XSL-FO. XSL-FO is now developed by the XML Print and Page Layout Working Group.

The rubric development was done using the first two languages described above, the XSLT and the XPath. The later defines a syntax named XPath expressions which identifies one or more of the internal components (elements, attributes, and so on) included in an XML document. It is widely used in other core-XML specifications and in programming libraries for accessing XML-encoded data. This brings the possibility of developing tools like rubric that can be potentially used for a wide number of final users. XSLT is very tightly coupled with XPath, which is used to address components of the input XML document, mainly elements and attributes. Internally, the XSL sheets use the HTML language to apply a style to the information in the XML. In order to be visualized, the desired information is pointed and extracted by XPath expressions, for example, to extract the metadata title the XPath added to the XSL is: “//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title/gco:CharacterString”. The XSL sheets allow the inclusion of external XSL sheets to visualize specific parts of the information. In that case, the external XSL sheet must be pointed from the primary sheet. In our case, the rubric XSL sheet contains an extra sheet for the spiral representation. Thus, the XSL points the external sheet in order the two first tables (spiral scores) could be properly visualized. The following sentence must be included at the beginning of the rubric XSL: “ <xsl:include href="isoRubricStars.xsl"/>”. It is important to highlight that the rubric XLS was created to be always accompanied by the XSL that describes the two Spiral table


47

descriptions, if the external style sheet is lacking, then the primary sheet could not be visualized properly. Once the XSL sheet includes all the elements to be shown and these have been given the desired style. It is needed to add a style sheet to the XML documents that are going to be visualized with the created style, the rubric tool in our case. The final transformation will be done by including in the XML a declaration like this: <?xml version='1.0' encoding='xxx'?> <?xml-stylesheet type="text/xsl" href=" GeoViQua_ISO_Rubric.xsl"?> Finally, once all the previous steps have been followed, the users and producers could be able to visualize and compare the metadata records in a standard, quick and easy way. It has been selected two metadata XML files from NOAA catalogue (NOAA, 2012) as examples to demonstrate how the rubric version 1.0.3 depicts the XML in HTML, at is shown bellow. In next sections these two XML will be compared with the rubric quality extension and other examples extracted from GEOSS Clearinghouse.

Figure 11. The rubric tool used to compare two metadata files from NOAA. As you can see the sheet

transfer the style to the XML to be equality visualized.

The Rubric extension of quality The rubric extension has been developed as an extension for the eight information groups depicted in the NOAA rubric tool (Identification, Connection, Extent, Distribution, Description, Content, Lineage and Acquisition Information). Two new information groups related with ISO quality have been added to the initial sheet, they are Quality and Usage. These two groups have been designed to increase the information available for users and producers, to be represented and consequently visualized in the rubric tools. The original information in rubric have not been modified, all new information is designed as complementary and self understandable. Other addition made in rubric tool is related to


48

lineage information. In ISO 19115:2003 standards the lineage information is a class pending from DQ_DataQuality, thus we have extended the rubric previous information to include all the lineage details related with data quality. Moreover, in order to proportionate a coherent and unified structure to all the information provided in the rubric tool, the new information groups have been also added to the “Total Spiral Score” table. Therefore, all the original and new information is fully summarized at the top of the HTML page, as you can see in the figure bellow. In order to maintain cohesion amongst the GEOSS components, the GEOSS style has been applied to the rubric tables. The scoring method will be explained in the section “2.3.3.1 Rubric metadata quality punctuation”.

Figure 12. This figure shows the two examples of the rubric tool quality extension. The quality information has been added to the spiral score table, acting as a summary of all the information contained in the XML.

Metadata extracted from the NOAA repository.

The new spiral group directly descendent from DQ_Element appears in the HTML page named as “quality” under the Acquisition Information. This quality table is divided into two parts, the first one containing the two main quality items: score and report; and the second one is a detailed description of the quality elements, this represents an extension of the report. The first part shows the attribute, the attribute description, a best practice explanation and finally the path (XPath) used to determine the element harvested. The


49

attribute is accompanied, in parentheses, by the count of the attribute‘s multiple cardinality, as respect to report.

The second table contains a detailed list of all the elements over the DQ_Element class, which appears in the second row of the quality main table. This has one specific table for each one of the elements contained in the XML file, under ISO 19115 standard. In the next figure you can see an example of the quality table extracted from a GEOSS metadata from the Clearinghouse.

Quality Score: 2/2 The Quality Spiral provides information about data quality. Score

Attribute (Count)

Description

Best Practice

Path

1 Scope Quality

Scope. TBD /gmi:MI_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:sco

pe

1 Report (6)

Quality report.

TBD /gmi:MI_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report

DQ_Element (6)

DQ_AbsoluteExternalPositionalAccuracy Scope:

Score Description Content

4/6

Measure Horizontal Positional AccuracyResolution as reported

Evaluation Method Approximate horizontal accuracy is 40 feet, assuming source data meets National Map Accuracy Standards.

Date and Time null

Quantitative Unit meters meters http://www.bipm.org/en/si/

Quantitative Error Statistic

null

Quantitative Value 40 feet

Comments for punctuation: There is result information for the quality element, the document gets 3 points for each result type completely filled.

DQ_AbsoluteExternalPositionalAccuracy Scope:


3/6

Measure Vertical Positional Accuracy

Evaluation Method None

Date and Time null

Quantitative Unit meters meters http://www.bipm.org/en/si/

Quantitative Error Statistic null

Quantitative Value null


DQ_CompletenessCommission Scope:



50

1/6

Measure null

Evaluation Method Data set is complete

Date and Time null

Comments for punctuation: There is no result information for the quality element, three points missing.

DQ_CompletenessOmission Scope:


1/6

Measure null

Evaluation Method Data set is complete

Date and Time null


DQ_ConceptualConsistency Scope:


1/6

Measure Polygon and chain-node topology present.

Evaluation Method null

Date and Time null


DQ_QuantitativeAttributeAccuracy Scope:


3/6

Measure Quantitative Attribute Accuracy Assessment

Evaluation Method See Entity_Attribute_Information

Date and Time null

Quantitative Unit null

Quantitative Error Statistic null

Quantitative Value See Explanation


Figure 13. Example of the quality metadata table in the rubric quality extension. It shows all the quality elements contained in the metadata file under ISO 19115. Metadata extracted from the GEOSS Clearinghouse. This quality table contains, as you can see in the example above, one subdivision per each quality element included in the metadata XML represented. A specific punctuation method that will be explained above has been created. Each of the quality elements can contain the following information: the name of measure, the name of the method, the method description, the evaluation procedure, the date and time and the result. For the result, the next information can be detailed: the conformance specification, the conformance explanation, the conformance pass, the quantitative unit, the quantitative error, the quantitative value, the coverage type, the link to the coverage file and the coverage description. All the quality elements mentioned above are accompanied by the information provided by the producer, thus contained in the XML file, under the “content” column, it is not just an explanation, as is the case for the rest of the rubric tables apart from the quality related ones. When the information is not provided in the XML, a “null” is shown. The results of the quality element can be explained in three ways; first, under a


51

conformance result; second, by a quantitative result and third, using a coverage result (ISO 19115-2:2009). In order to differentiate and make clear evidence in the representation of each one of these three results, it has been applied a different background colour for each one of them. The blue has been applied for the conformance results, the green for the quantitative results and the yellow for the coverage results. DQ_TopologicalConsistency Scope: dataset Localities in Victoria (VMADMIN.LOCALITY_POLYGON)


5/6

Measure Overlapping polygonThis measure identifies overlapping polygons

Evaluation Method null

Date and Time 2006-11-14T00:00:00

Conformance Specification

Overlapping polygon Test 2005-05-15 revision Five (5) overlapping polygons exist

Conformance Explanation

Five (5) overlapping polygons exist

Conformance Pass 1


Figure 14. Figure representing the different background colour used to depict the conformance result.

Metadata extracted from the GEOSS Clearinghouse. In the example above you can see an extraction of a metadata file, under rubric quality extension style, containing conformance results for the quality element “TopologicalConsistency”, the background is depicted in blue. Other table developed in the rubric quality extension was the Usage. In this case two tables were also designed, the first one containing the elements description and path (Usage, date and time, limitations and contact) and the second one showing these elements information from the XML file (content). The next figure shows the specific usage table in the rubric quality extension. Usage Score: 2/4 The Usage Spiral provides information about data usage. Score

Attribute (Count)

Description Best Practice

Path

1 Usage (1)

Specific Usage.

TBD /gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceSpecificUsage/gmd:MD_Usage/gmd:specificUsage/gco:CharacterString

0

Date and Time (0)

Usage Date and Time.

TBD /gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceSpecificUsage/gmd:MD_Usage/gmd:usageDateTime/gco:DateTime

0 Limitations (0)

Usage Limitations.

TBD /gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceSpecificUsage/gmd:MD_Usage/gmd:userDeterminedLimitations/gco:CharacterString


52

1

Contact (1)

Usage Contac informationt.

TBD /gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceSpecificUsage/gmd:MD_Usage/gmd:userContactInfo/gmd:CI_ResponsibleParty

MD_Usage (2)


2/4

Specific usage exist

Die topographischen Karten sind vielseitig nutzbar, da kein spezielles Thema hervorgehoben dargestellt ist. Sie werden u.a. benötigt: in der Landes- und Regionalplanung, in der Bauleitplanung, für den Natur- und Landschaftsschutz, für den Tourismus, als Grundlage für thematische Karten, zur Orientierung und Übersicht.

Usage Date and Time exist

null

Usage Limitations Exist

null

Usage Contact info. Exist

Landesvermessung und Geobasisinformation Brandenburg (LGB) +49-331-8844-123 +49-331-8844-16123 Heinrich-Mann-Allee 103 Potsdam Brandenburg 14473 Deutschland [email protected] http://www.geobasis-bb.de information pointOfContact

Figure 15. This figure shows a usage table part of the quality extension in rubric tool. Metadata extracted from the GEOSS Clearinghouse.

As you can see in the figure above, the information between the two tables is consistent, meaning that all the usage elements described in the first table are lately extracted and showed in the second table. This is a clear example, as the metadata information contained in the second table is written in the original language, German. The rubric tool version 1.0.3 contains a lineage spiral in which the source and process steps are explained and scored. Nevertheless, the table has no quality extraction on it. The quality extension has included the Statement element into the lineage, also an extra table has been constructed extracting the lineage content from the XML metadata file, as you can see in the next figure. Lineage Score: 2/3 The Lineage Spiral begins the description of how the data have been measured and processed. Score

Attribute (Count)

Description Best Practice Path

0

Statement (0) UDD (history)

General explanation of the data producer's knowledge about the lineage of a dataset

Using xml ids for sources and processSteps makes it possible to refer to them from one another: <gmd:LI_Source id="src_AVHRR_GAC.1074123.65352"> More...

/gmi:MI_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:lineage/gmd:LI_Lineage/gmd:statement/gco:CharacterString

1

Source (1)

Information on the sources used in the development of the dataset.

/gmi:MI_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:lineage/gmd:LI_Lineage/gmd:source/gmd:LI_Source


53

1

Process Step (1) UDD (history)

The events in the development of the dataset. More...

/gmi:MI_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:lineage/gmd:LI_Lineage/gmd:processStep/gmd:LI_ProcessStep

MD_Lineage (3)

1. Direct list of Sources (1)


3/5

Source Description Source Contribution:

Source Scale Denominator 24000

Source Reference System null

Source Citation publication resourceProvider

Source Extent null

2. Direct list of Process Steps (1)


1/4

Process Step Description See Supplemental Information, Procedures Used

Process Step Rationale null

Source Date and Time null

Process Step Responsible Party null

Sources associated with this process step (1)


1/5

Source Description null

Source Scale Denominator null

Source Reference System null

Source Citation None

Source Extent null

Figure 16. This figure contains the lineage table with all the associated information extracted from the metadata file in XML. Metadata extracted from the GEOSS Clearinghouse.

The lineage table, MD_Lineage, contains the information related to the sources and processes. As there are several ways to describe the possible lineage (direct list of sources, direct list of or processes, or sources through processes and processes through sources) we have divided the information into two general groups containing more specific information. The first group is the direct list of sources, in which users can find the different resources used to elaborate the data. The second group contains the direct list of processes, also accompanied by the sources associated with the process step, as you can see in the figure above. The multiple tables of quality extension explained in the current section have been given a special punctuation system, separated from the original rubric method. This has been done this way in order to do not detract from the original punctuation; moreover, the quality scores has been attributed to benefit the metadata files containing quality information, whereas not penalizing those metadata lacking quality. Regarding the application of the rubric style, the way rubric works is adding a simple link, to the XSL style sheet, in the XML to be represented. Also, recently, some other CSS have


54

been linked in order to transfer the GEOSS style to the tool. In that way, the user could supply a URL which point to the metadata styled using the rubric. That means that using a catalogue URL, it is a useful way to make publish the rubric tool and embed it with the GeoViQua quality model. For example, we have provided an URL in the twiki (http://www.geoviqua.org/Eng/MetadataVisualization.htm), to allow anyone to use the rubric, if the user have the catalogue URL to the cited metadata (in bold), he/she could represent the metadata in an rubric styled way, and reference it as an onlineResource in the publication that’s in the discoveredIssue in the GeoViQua producer metadata quality model. This is, in fact, an easy way to connect GeoViQua components: the rubric tool and the model. http://www.ogc.uab.cat/cgi-bin/geossback/GEOSSBack.cgi?accio=EstilXML&AfegirEstil=rubric&URL=http://clearinghouse.cisc.gmu.edu/geonetwork/srv/en/iso19139.xml?id=491540 The quality scoring method is explained in the next section.

Rubric metadata quality punctuation The rubric scoring method is based on the presence or absence of the information, attributing one point to metadata that contain certain information, but not penalizing those metadata which does not have some information, although this information could be mandatory under the ISO 19115 schemas. The two summary tables located at the beginning of the rubric HTML page, the total spiral score table and the total ISO core score, show the accumulated percentage of positive elements. These positive elements are marked with a green background throughout the HTML page, the red elements indicate lacking information. The rubric quality extension has ten groups of information in the total spiral score table, arriving the maximum score to 48; seven points over the rubric 1.0.3. The total ISO core score table has not been changed, as the quality information added is not contained in the ISO core; so the maximum score remains in 23 points.

Relating to the quality, usage and lineage tables, the first rows of each one, showing the elements description has the same rubric punctuation described above. For the rows showing the quality content other specific punctuation has been given, these points are not included in the two spiral tables.

Table 5. Punctuation parameters followed in the Rubric quality table (DQ_Element).

Each group bellow is

considered 1 point

Information contained in each group (complementary)

Subelements

Measure name of measure

measure description

measure identification Method evaluation method type


55

When the metadata contain result information, the denominator of the score has been increased 3 point for each one of the result types; for example, a metadata without result is scored 1/3, meanwhile the same metadata with one element of quantitative result will be given 2/6. This is because each of the result type has three quality elements, not understandable without the other two. For example, for a conformance result, it must be given the specification, the explanation and the pass in order to be fully informed and get the 3/3 points.

Table 6. Punctuation parameters followed in the Rubric usage table (MD_Usage).

Each element bellow is considered 1 point

Specific usage

Date and Time

Limitations

Contact In the usage case, it has been scored the presence of each of the elements in the table with one point per element. Contrary to the DQ_Element table, there are no group of elements. Table 7. Punctuation parameters followed in the Rubric for the complementary lineage table (MD_Lineage).

Each element bellow is considered 1 point

1. Direct list of Sources 2. Direct list of Process Steps

Source Description Process Step Description

Source Scale Denominator Process Step Rationale

Source Reference System Source Date and Time

Source Citation Process Step Responsible Party

Source Extent

evaluation method description

evaluation procedure Date and time dateTime

Result

conformanceSpecification Citation of the specification

conformanceExplanation Explanation

conformancePass Pass (Boolean)

quantitativeUnit Value Unit

quantitativeError Error statistic

quantitativeValue Value, value type

CoverageType Spatial representation type, result spatial representation, result format

CoverageFile Result file

CoverageDescription Result content description


56

In the lineage table there are two different punctuation groups, as ways in which to inform about processes and sources: direct list of sources and direct list of process steps. Each one of the elements enumerated in the table gets one point. When the direct list of process steps (second group) has complementary information related with sources associated with this process step, then the metadata gets one point per each element belonging to the direct list of sources (group 1).

SCIENTIFIC PUBLICATION CITATION A scientific publication is usually applied to text, images, or other audio-visual content on any medium, including paper (newspapers, magazines, catalogs, etc.) or electronic publishing forms such as websites, wikies e-books, Compact Discs and MP3s. Under the term of scientific publication we are going to evaluate all the categories mentioned above, as well as its relationship with a dataset catalogue, and all of this by means of citation of publications. The relation between a dataset and a scientific publication is a 2 way link:

A dataset needs to cite external publications that uses the dataset A publication needs to cite a dataset used in its elaboration.

Figure 17. Relation between publications, datasets and

metadata records in the GCI. In many scientific studies, the data is produced by the scientist that is willing to find out something that can be published in a scientific paper. The publication of the data and the paper can be simultaneous. In this case, Pangea proposes a workflow to relate both based on connecting the publication chains of both data and articles.

GCI

Publications

Dataset

Metadata

Dataset Id, URL…

DOI, URL…


57

Figure 18: Diagram that represents a workflow that enfasizes the publications

of data and the publication of papers simultaneously and mechanism for linking both. (From: PANGAEA® Using DOI names to link earth & environmental

data with scientific literature, Uwe Schindler, PANGAEA [email protected]

(MARUM, University of Bremen)

In GEOSS the situation is not so simple because main data producers release their products with their metadata and then, scientist public research about this products in a disconnected way. Furthermore, it has to be given some thought on the relationship between publication-dataset as well as on how a publication can be linked to a GEOSS dataset (the second scenario). The immediate answer is by using the reference to the data in the reference/bibliography section of the document (with all the other normal references to other publication) as suggested by the International Polar Year (IPY) citation standard. The former GEO task ST-09-02 (also supported by the EGIDA project) did some work on how to build a citation standard. This work is now being continued by the ID-03 group. When this work is finished, they will also provide a univocal way on how a publication should cite data. They are using the classical expanded approach, but currently they do not consider to link unique identifier for publication with data identifiers. Through all this process


58

GeoViQua is collaborating with these groups. Parallel efforts to deal with this problem are being undertaken by DataCite and Pangaea projects. In fact Elsevier has recently adopted a way to cite data as can be seen in the following example: http://www.sciencedirect.com/science/article/pii/S0967063708001805. While some effort has been done to identify datasets, GEOSS catalogues has other mechanisms to identify metadata records in the clearinghouse that are different from this approach. Please, note that a metadata identifier is not necessarily a data identifier. Citation has been addressed for some time now through several initiatives, some projects such as CLADDIER [CLADDIER, 2005] (aimed at establishing methodologies for data citation as well as designing a system to link publications held in two repositories with datasets hold in the British Atmospheric Data Centre), have been working on the importance of data citation and on how to link datasets and publications; other projects concentrate their effort on establishing a unique number for identifying datasets and parts of it, such as the DataCite organisation [DataCite,2009] (helping researchers to find, to access, and to reuse data through internet in an easy way, by promoting and providing a Digital Object Identifier [DOI] number for the datasets); there is also Centre for Environmental Data Archival [CEDA, 2011] repository (which provides a unique identification number to identify earth data acquired on field campaigns); and finally, some initiatives try to address the issue on how to view publications that cite a particular dataset (OJDC, which is a repository for grey literature). All of these are just mentioned as examples of initiatives that have been taking place. In this section of the deliverable we are going to focus on the first case scenario, where a dataset can be related to a certain number of publications by implementing a model designed in the GeoViQua project which is called the Producer Quality Metadata Model, described in detail in the deliverable 6.1. The existence of a unique identification value such as a DOI, a Uniform Resource Locator (URL), an ISBN number or an ISSN number, which identifies a particular publication, can be used to link a scientific publication to a specific dataset within a catalogue. The DOI reference has been used for scientific publications since 1994, as well as the ISBN and ISSN identification used for books back in the seventies, but recently, with the use of the Internet, new categories of publications have appear (web-pages, wikis,…) which require a unique identifier number. ISO 690-2010 interpretation on web publications, states that URLs should be written in the same place where DOIs are. If the information location changes from time to time, the URL also changes accordingly, and thus it can be difficult to retrieve the resource. This is why accompanying the URL, it has to be documented as much information as possible regarding the web. This can also be solved by the use of persistent URL’s (PURL) redirectors. But not all scientific publications have a unique identification number, in some cases a publication can be a manual, or an article from a journal which is not indexed, or a CD/DVD from an official institution. All of which are lacked of a unique identification number, and thus the need for a holistic approach to link data and complete citations has to be solved. In the GeoViQua project we need a corpus of publications that reference datasets for different purposes in order to test the reference publication model that is going to be included in the Producers Quality Metadata Model. Since this is a new topic in GEOSS, it


59

is not possible to extract publications form metadata about the data. Despite efforts have been made to define a data citation standard for scientific publications, currently it is not possible to automatically extract this information from the publications. In order to have a small set of examples, we have manually extracted some publications that are related to datasets registered in GEOSS. This material will be input to test the models developed for the producer quality metadata model (Task 6.1), as well as for the user feedback system (task 3.5). To that aim, a producer quality metadata model has been designed taking into consideration all the guidelines stated in ISO 19115:2006, ISO 19115-2, ISO 19157, ISO 690-2010 and from additions made by GeoViQua group based on the requirements phase (deliverable 2.1). These additions have been introduced to meet the needs observed, and thus to correctly link datasets to publication through the citation of the publication.

Dataset-Publication Relationship ISO 19115:2006 defines the elements that conform the entity “Citation and responsible party information: CI_Citation” class that can be used for citing external resources. GeoViQua finds necessary to add some more attributes to this class to be able to reuse it as a way to cite publications, this is why a specialized class has been designed (GVQ_Publication) with some additional attributes such as DOI, URL, volume, issue, pages, purpose, relatedResource, target, scope and category. By doing this, any CI_Citation in the metadata model can be substituted by a GVQ_Publication. Also, the possibility to add a GVQ_Publication has been included in several different metadata classes that had no previous CI_citation attribute depending on the purpose of the publication. Publications have evolved from paper publications to an extended variety of sources, having experimented a huge increase in number and sources on the last decades due to the on-line access. This is why a wide variety of publications have been gathered and studied in order to have a wide scope of the different kind of publications now available, from paper map documents to articles and wikis, among other, as well as defining the kind of information that is needed to reach a particular publication.

Examples of publications sorted by data reference purpose One of the needs detected has been to establish the purpose of each publication. With the aim to provide as much information and as clear and easy to reach as possible, the following purposes have been suggested. As we already stated, the purpose of the publication depends on where the GVQ_publication element is used in the “tree” of metadata classes. Nevertheless, there is also a purpose attribute in the GVQ_Publication class that includes in a codelist that is used as an attribute in the GVQ_Publication class.

<<CodeList>> GVQ_PublicationPurposeCode

+ Descriptive + Methodology to get the resource (Algorithms, models,...)


60

+ Evaluation of performance + Validation/quality assessment + Application (MD_usage) + Derivated products + Comparative (inter-comparison) + Datasets Combination

Figure 19. Purpose of the publication included in the GeoViQua producer metadata quality model. Below we present some publication examples with different purpose types. Each of the example refers to a publication and it is documented by a unique identifying number (when existing), the title, the link to the dataset (or datasets) to which the publication cites, and finally some information on Quality assessment when mentioned in the text. Some of the links to the original data are no longer valid, and no redirection is given. This problem is quite common at the moment. Once the new producer quality metadata model is adopted, publications usually will cite the dataset directly (that is outside of the GCI) while datasets are represented by metadata records in the clearinghouse that will contain references to publications (see figure above). For that reason publications will continue not recognizing the GEOSS infrastructure. DESCRIPTIVE See Annex C.1

METHODOLOGY TO GET THE RESOURCE (ALGORITHMS, MODELS,...)

See Annex C.1 EVALUATION OF PERFORMANCE See Annex C.1 VALIDATION/QUALITY ASSESSMENT See Annex C.1 APPLICATION (MD_USAGE) See Annex C.1 DERIVATED PRODUCTS See Annex C.1 COMPARATIVE (INTERCOMPARISON) See Annex C.1


61

DATASETS COMBINATION See Annex C.1

Examples on Categories In the GeoViQua project we propose a new element to group all citations depending on the publication category (on the UML model the GVQ_PublicationCategoryCode codelist is added). The following codelist contains the list of Categories set:

<<CodeList>> GVQ_PublicationCategoryCode

+ bookChapter + book + report + journalArticle + magazineNewspaper + atlasPaperMap + applicationProgram + conferenceProceedings + cdDvd + blogWiki + website + webpage - onlineVideo

Figure 20. Element proposed in the GeoViQua producer metadata quality model to group all citations depending on the publication category.

Examples on some categories are illustrated with examples. Validating with the.xsd (XML schema) designed when elaborating the Producer Quality Metadata Model in task 6.1, the .xml files for the following categories have been done validating with the .xsd. The XML documents can be found in the ANNEX C.2. book See Annex C.2 manual

See Annex C.2 journalArticles

See Annex C.2 magazineNewspaper

See Annex C.2 atlasPaperMap

See Annex C.2 poster


62

See Annex C.2 cdDvd

See Annex C.2 website

See Annex C.2 webpage

See Annex C.2 onlineVideo

See Annex C.2

Some thoughts on the design While elaborating this section, some thoughts came up that need further consideration:

- Visualization: We propose that within the Geobroker/GEOcatalogue interface, there could be a place referring to the publications/citations, providing a link to a page that contained the list of publications where the dataset has been used/cited. The list of publications could be grouped into the publication categories defined in GeoViQua Producer Quality Model (GVQ_PublicationCategoryCode) in order to facilitate the access to the different information that cite the data. From the publication lists it would be possible to find other datasets related to this publication. This will be solved in tasks from the Work Package 4.

- Some publications use a unique identifier, sometimes in the form of “PII” (Personally Identifiable Information), which has been encountered in few cases, others in the form of DOI or ISBN. The PII is a concept which is quite old, and its use in publications has been found to be scarce. In order to correctly identify a publication, it should be stored the unique identifier number that it has. Even though some of these identifier types are already contemplated in the ISOs, identifier types have been found which do not correspond with those that are actually on the ISOs. This is why we suggest having an Object Identifier (OI) that could include DOI, PII, as well as any other unique identified number that has not formally a place in the MODEL. Nevertheless, we recommend using a prefix to categorize the identifier type (e.g.: all DOI number shall start with “doi:” and all PII shall start with “pii:”) that correspond to that particular publication.


63

Figure 21. GVQ_Publication element proposed in the GeoViQua producer metadata quality model

- In some cases the publication is related to more that one dataset. The first dataset identifier is the one included in the metadata root element. The other additional datasets are referenced to by using the relatedResources (MD_Identifier type)

- Regarding embedded elements, it has to be noted that this has to be specified (case of videos in youtube, ISO 690:2010), and the URL is thought as its unique identification number, and therefore, may be it could be included under the Object Identifier. An other option could be to open a new category for Online source. We think that the second option should be considered as the best option. Then a URL could be included in the producer quality metadata model as a URL, just after the ISBN term, being the URL a form of uniquely identification for the Video citation.

- While elaborating this document, it has also been found that publications sometimes may have two ISBN numbers that do not coincide, one for paper publication and one for on-line publication of the same publication. This could lead to errors when trying to reach the publication, so may be It should be specified which one is being used on the registry, or may be to specify the user which ISBN has to be edited.

- Also in the feedback model we suggest that there is a section where a person that wants to use a particular dataset, and before the actual dataset download, the user takes on a compromise that when ever this data is finally used in a publication, it will be notified to the GEOSS community by filling in all the information required to correctly link the dataset with the publication derived. And therefore, it should always be notified the need of data citation and of reporting it when citing.

CONCLUSIONS This deliverable runs in parallel with deliverable 6.1 “Quality encoding”. In 6.1 the focus is on establish the right data quality model (both for produced and consumer quality) and to generate the encodings for them. In this deliverable we concentrate on the effort of collecting data quality indicators from different sources and analyzing their different origins. One of these origins is the current clearinghouse but this has already been analyzed in D7.2 “Report on current GCI and identification of issues in integration with GEOSS”. Recently, other catalogues have been incorporated to GEOSS by the addition of the EuroGEOSS broker. The GEOSS current status has been analyzed to repeat the study on D7.2 and extend it to all federated catalogues. Currently the project is working on the addition of SOS services and this document also describes the first steps done in this direction that will be extended in WP4 in the month to come. This document analyzes the many formats used by different agencies and data producers. Some data formats support embedding metadata and quality indicators; while others need an extra file (sometimes based on XML, others on plane text files). The study concludes that generating an import tool to cover them all is almost impossible to develop in the project timeframe and we must concentrate in a transversal format that can include most of the characteristics that the project is going to analyze. The chosen format is the NetCDF for the following reasons:

It is a transversal format not linked to any particular data agency


64

NetCDF is going to be an OGC standard This format has been used for more that a decade and now we see a growth in use. It supports raster, vector and tabular formats It is an extendable format and there are libraries to read/write the format. It supports dataset level metadata and pixel based uncertainty (also an OGC

discussion paper: NetCDF-U) NetCDF is registered in the GEOSS SIF: http://seabass.ieee.org/groups/

geoss/index.php?option=com_sir_200&Itemid=157&operator=AND&general=NetCDF&do_search=Search

There are 2 partners experts in NetCDF file standardization and visualization

We have just explored the possibility of directly extracting data quality from the data itself, concluding that this is possible but out of scope. The only effort included in this project is the possibility of extracting metadata by intercomparison between datasets coming form different modelization strategies. Another important aspect in the project is being able to explore different textual manipulation strategies for metadata documents. Since metadata documents are XML files they can be transformed in other XML documents by applying a XSL transformation to them and particularly transforming it into XHTML (a flavour of HTML that follows strict XML rules). There is already a XSL that focus on metadata completeness developed by NOAA called “rubric” that associates a punctuation number to a metadata document based on how much information it contains. This XSL has been extended to include the current quality elements that ISO contains, i.e. quality measures, lineage and usage. These elements are punctuated but also they are shown on the screen for better understanding and presentation. The adoption of this system could stimulate data providers to generate better and more complete quality metadata documents. The rubric will be extended again when the new producer quality model is completed to include the new elements or even extended to include the user feedback model (both elaborated in D6.1). One of the important new things in the producer quality model is the possibility to include references to scientific publications to the metadata records. A need for having a set of examples for scientific publications that could be useful in the near future to test the new producer’s quality model was identified. This examples where extracted form scientific literature and related to datasets currently included in the GEOSS clearinghouse. This material has been included here as a reference and will be used in the WP 5 (quality visualization) for testing purposes. While collecting these examples we have also to test the GVQ_Publication element of the new metadata model. The work done on this deliverable collects the necessary information to have enough materials to test the prototypes that will be developed in the project soon.

GLOSSARY ACDD - Attribute Convention for Dataset Discovery for netCDF API – Application Programming Interface


65

ASCII - The American Standard Code for Information Interchange is a character-encoding scheme originally based on the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that use text. CEOS – Committee on Earth Observation Satellites. Defines an standard format used by the ESA for the distribution of EO data. CDC - NOAA’s Climate Diagnostics Center. CF - Climate and Forecast attribute convention for netCDF. CSIRO - The Commonwealth Scientific and Industrial Research Organization Division of Atmospheric Research in Australia. CSDGM - Content Standard for Digital Geospatial Metadata. DHWG - Data Harmonization Working Group CSW - Catalogue Services for the Web DOI - Digital Object Identifier. DCMI - Dublin-Core Metadata Initiative, Dublin Core – A simplified standard for metadata documentation promoted by DCMI Earth Explorer – USGS image server for EO data. EO data - Earth Observation data. EOS - EO metadata format EOSDIS - Earth Observing System Data and Information System. EROS – Earth Resources Observation and Sciences ESA – European Spatial Agency EUROGEOSS broker - The EuroGEOSS project adopted a Brokering Approach to implement multi-disciplinary interoperability and lower entry barriers for both Users and Data in GEOSS. FGDC - Federal Geographic Data Committee GCI - Geoss Common Infrastructure. consists of a web-based portal, a Clearinghouse for searching data, information and services, and registries containing information about GECA - ESA Generic Environment for CalVal Analysis project. CSR - The GEOSS Components and Services Registry provides a formal listing and description of all the Earth observation systems, data sets, models and other services and tools that together constitute the Global Earth Observation System of Systems. GEO - Group on Earth Observation. GEOMS - Generic Earth Observation Metadata. GEOSS - Global Earth Observation System of Systems GEO Portal - The GEO portal is a gateway to global Earth Observation data, information and services developed by the European Space Agency (ESA) in collaboration with the Food and Agriculture Organization of the United Nations (FAO) as contribution to Global Earth Observation System of Systems (GEOSS). GeoTiff + MTL + Meta - Files distributed by USGS GloVis and Earth Explorer servers for Landsat imagery. GloVis – USGS image server for EO data. GSC - GMES Space Component. GSCDA - GMES Space Component Data Access. HALOE - NASA’s Halogen Occultation Experiment. HDF – Hierarchical Data Format. EO data format. HTML - HyperText Markup Language is the main markup language for displaying web pages and other information that can be displayed in a web browser. HRPT - High-Resolution Picture Transmission ground station at the Coastal Studies Institute.


66

JPEG2000 - EO product format LANL - The global ocean modeling effort at Los Alamos National Laboratory. LDEO - Lamont-Doherty Earth Observatory of Columbia University. NCAR - The National Center for Atmospheric Research. NcML - NetCDF Markup Language. NCEP – National Center for Environment Prediction NDF - NLAPS Data Format for USGS Landsat imagery. NetCDF – Network Common Data Form. EO data format. NetCDF-U - Image formats that inform about uncertainty at a pixel level. NLAPS – National Landsat Archive Production System NSIDC – US National Snow and Ice Data Center NOAA – National Oceanic and Atmospheric Administration OGC - Open Geospatial Consortium PCD - Payload Correction Data PURL - persistent URL’s. SBA - Societal Benefit Areas that GEOSS addresses: Health, Disasters, Weather, Energy, Water, Climate, Agriculture, Ecology and Biodiversity. SIO - Scripps Institution of Oceanography. SOS-Q - OGC Sensor Observation Service standard with Quality. SPOT DIMAP – SPOT imagery distribution data format. THREEDS - Thematic Realtime Environmental Distributed Data Services. Transversal metadata format. UncertML - U-O&M - Data model and encoding for observation data defined by the OGC. USGS – United States Geological Survey WCS - Web Coverage Service of OGC. EO metadata format WMS - Wep Map Service of OGC. XML - Extensible Markup Language is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards. XSLT - XSL Transformations

REFERENCES Austrtalian National Data Service – ANDS http://www.ands.org.au http://ands.org.au/cite-data/resources.html#What_is_Data_Citation (accessed on February 2012) Centre for Environmental Data Archival-CEDA, (2011) http://www.ceda.ac.uk/ CLADDIER (2005) CLADDIER Project http://www.jisc.ac.uk/whatwedo/programmes/digitalrepositories2005/claddier http://home.badc.rl.ac.uk/lawrence/blog/2005/12/22/data_citation CORS (2012) NOAA CLASS archive: Continuously Operating Reference Stations. Accessible on 23/01/2012

in: http://www.ngdc.noaa.gov/metadata/published/NOAA/NESDIS/CLASS/iso Bigagli L., Nativi S. NetCDF Uncertainty Conventions (NetCDF-U). OGC Discussion Paper, 2011. DataCite (2009) http://datacite.org/ (accessed on February 2012)


67

GEO (2005) The Global Earth Observation System of Systems, 10-Year Implementation Plan. Accessible on 06/06/2012 in: www.earthobservations.org/docs/10-Year%20Implementation%20Plan.pdf Integrated Earth Data Applications (2011) http://www.iedadata.org/ ISO/TC211, ISO 19115:2003, Geographic information-Metadata, 2003 ISO/TC211, ISO 19115-2:2009, Metadata pre-standard extension for imagery and gridded data, 2009 ISO/TC211, ISO 19119:2005, Geographic information – Services, 2005 ISO/TC211, ISO 19139:2007, Geographic information-Metadata-XML schema implementation, 2007 ISO/TC211, ISO 690:2010, Information and documentation – Guidelines for bibliographic references and

citations tp information resources. Third edition 2010-06-15. Landsat TM/ETM+ ESA Products. CEOS Format Specifications (Issue 3.0 18/4/2003). Accessible on

07/06/2012 in: earth.esa.int/pub/ESA_DOC/GAEL-P157-DOC-003-03-00.SpecCEOS.pdf GEOSS Citation Standard, DRAFT for Discussion by ST-09-02, March 20, 2011 http://www.earthobservations.org/documents/committees/stc/201104_16thSTC/draft_geoss_citation_standard_ST0902.pdf GEO-IDE (2012) NOAA’s Integrated Data Environment Guidelines and Best Practices Wiki. Accessible on 23/01/2012 in https://geo-ide.noaa.gov/wiki/index.php?title=Main_Page Javier Bezos (March 3, 2011) Bibliografías y su ortotipografía. Versión 0.17.2011-03-05. Guía pr´catica para la aplicación de la norma ISO 690:2010. Masó J., Serral I., Pons X., GeoViQua: a FP7 scientific project to promote spatial data quality usability: metadata, search and visualization, 7th International Symposium on Spatial Data Quality, Coimbra, 2011 Nativi S., Craglia M., Bertrand F., EuroGEOSS: building inter-disciplinary interoperability for the global

community, EGU General Assembly, Vienna, pp. 3440, 2009 NOAA (2012) NOAA Metadata repository, Accessible on 14/02/2012 in: http://www.ngdc.noaa.gov/metadata Peter Buneman, University of Edinburg (2006). How to cite curated databases and how to make them citable. Proceedings of the 18th International Conference on Scienti_c and Statistical Database Management, Vienna, July 2006. Rubric (2012) Rubric ISO 19115 SpiralTracker Report. Accessible on 19/01/2012 in:

http://www.ngdc.noaa.gov/nmmrview/metadata.jsp?xml=NOAA/NESDIS/CLASS/iso/xml/CORS.xml&view=isoRubricHTML&altview=none

Sevillano E., Díaz P., Ninyerola M., Masó J., Zabala A., Pons X. (2011) Analysis of the quality metadata in

GEOSS Clearinghouse, EuroGEOSS “Advancing the vision for GEOSS”, Madrid 24-27th January 2012. Taaheri, E.M. (Ed.), 2001. “An HDF-EOS and data formatting primer for the ECS project”. White Paper,

Raytheon Company, 01 March, 107pp Tim Killeen, GEO (March 29th, 2012) National Science Foundation. Subject: DataCitation in the Geosciences. Wilson Boulevard Arlington, Virginia 22230. USGS. Landsat Thematic Mapper TM Level 1 (L1) Data Format Control Book (DFCB). Version 3.0, January

2009. Accessible on 07/06/2012 in: http://landsat.usgs.gov/documents/LS_DFCB_20_TM_Level_1_DFCB.pdf


68

UW-D1. UncertWeb Consortium, UncertML best practice proposal, Deliverable 1.2, 2011. Wei, Y., Di, L., Zhao, B., Liao, G., Chen, A. (2007) “Transformation of HDF-EOS metadata from the ECS

model to ISO 19115-based XML”. Computers & Geosciences 33, 238-247 Williams M., Cornford D., Bastin L., Ingram B. R., UncertML: an XML schema for exchanging uncertainty, Geographical Information Science Research, 2008 Yang X., Blower J.D., Cornford D., Lush V., Masó J., Zabala A., Nüst D. (2011) “GEOSS Quality Framework and Quality Information Encoding”, EuroGEOSS “Advancing the vision for GEOSS”, Madrid 24-27th January 2012a Yang X., Blower J.D., Cornford D., Bastin L., Zabala A., Masó J., Lush V., Díaz P. (2012) “An integrated view

of Data Quality in Earth Observation” Philosophical Transactions of the Royal Society, 2012b (accepted for publication)


69

Annex A

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. VolumeDirectoryFile

ISO 19115

Id Byte LenType, Encoding

Description

13 45 3 String(A) /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/identifier/MD_Identifier/code

13 48 2 short(A) YY': year of acquisition /MD_Metadata/dateStamp13 50 3 int (A) DDD': Day of acquisition /MD_Metadata/dateStamp

13 53 3 int(A) PPP': path in WRS /MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

13 56 3 int (A) RRR': row in WRS /MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

13 59 2 string(A) AA': Acquisition station identifier /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/resourceProvider

14 61 2 string(A)AA': Processing station identifier.Part of the physical volumeidentifier

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/processor

14 63 1 string(A) Q':Quadrant number

14 64 2 short(A) YY':Year of product generation/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

14 66 3 int(A) DDD': Day of product generation/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

MNS': Mision, number and sensor type (e.g. 'L7E for

Landsat 7 ETM). Part of the logical volume identifier

CEOS

Volume Descriptor Record

VOLUME DIRECTORY FILE

Logical volume id

Physical volume id


ISO 19115CEOS

14 69 6 dateTime(A) HHMMSS': hour, minute, secondof product generation

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

15 77 8 string(A) Satellite name.Part of thevolume set identifier

/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/citation/CI_citation/title

15 85 1 string(A) Satellite number /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code

15 86 7 string(A) Instrument /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/citation/CI_Citation/title

10 21 6 string(A)

Satelline name. Part of thereferenced file name, wich is theunique identification providedwhen the volume directory iscreated in order to specify thefile referenced by this pointer

/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code

10 27 2 short(A) correction level /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/code10 29 4 string(A) File name

10 33 3 string(A) Interleaving indicator (e.g. 'BSQ')

10 36 1 byte(A) Band number associated to filename

Referenced file name

File Pointer Record

Volume set id


ISO 19115CEOS

10 67 39 string(A) Creation location. Part of theproduct creation description /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/otherCitationDetails

10 106 19 dateTime(A) Creation date /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

11 125 1 byte(A) Mission number. Part of thescene identification

11 126 5 int(A) Day number since launch at timeof observation

11 131 6 dateTime(A)GMT time at wich the centerpoint was imaged. Format is'HHMMSS' /MD_Metadata/dateStamp

15 157 2 string(A) Processing station identifier. Part of the tape id

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/processor

15 159 1 string(A)

Quadrant number. F for fullscene, E for floating full scene,1to 4 for standard quarterquadrant, Q for floatingquadrant, M for miniscene and Ofor microscene

15 160 2 short(A) year of generation /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

15 162 3 int(A) Day in year of generation /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

15 165 6 dateTime(A) Time of generation. Format is'HHMMSS'

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

Product creation

Scene identification

Tape reel id

Text Record

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. LeaderFile

ISO 19115

Id Byte Len Type, Encoding Description

9 21 3 string(A)SSS' sensor type (e.g. 'ETM'. Part of theproduct identifier (format'SSS$LSNXPPPRRRYYDDDCC$').

/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/identifier/MD_Identifier/code

9 24 1 string(A) $': Blank

9 25 3 string(A) LSN': Landat Mission (e.g.'LS7') /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code

9 28 1 string(A)

X': Quadrant Number. F for full scene, Efor floating full scene, 1 to 4 for standardquarter quadrant, Q for floating quadrant,M for miniscene and O for microscene

9 29 3 int(A) PPP': Path number/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

9 32 3 int(A) RRR': row number/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

9 35 2 short(A) YY':last two digits of year9 37 3 int(A) DDD' day of year

9 40 2 short(A) CC':correction applied /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

CEOS

File Descriptor Record

Scene Header Record

Product id

input_scene_id

LEADER FILE


ISO 19115CEOS

10 43 1 byte(A) L': Mission number. Part of the inputidentifier (format 'LDDDDHHMM$').

10 44 4 int (A) DDDD': Day number since launch

10 48 4 dateTime(A) HHMM': Time of center point. Where 'HH'are hours and 'MM' minutes

36 1477 1 string(A)

internal calibration source. Part of theradiometric calibration designator, whichis a set of 16 1-byte codes, eachspecifying whether the identifiedcorrection has been applied (value='Y') ornot (value='N'). For radiometriccorrections of TM products based onlifetime model, this field is set to 'N'

36 1478 1 string(A)

Pre-flight data. (based on heuristic LUTfor calibration). For radiometriccorrections of TM products based onlifetime models, this field is set to 'N'

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1479 1 string(A) Histogram equalization /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1480 1 string(A) Sun elevation correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1481 1 string(A) Film gamma correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1482 1 string(A) Scenic correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1483 1 string(A) Histogram mean and standard deviation /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

36 1486 1 string(A)ETM+ Gain seeting rules. 'L' for low gain,'H' for high gain. For TM products, thefield valued is blank

Radiometric calibration designator


ISO 19115CEOS

36 1487 1 x6 string(A)Agency codes. May be used by otheragencies codes to store radiometricprocessing codes.

37 1493 16 int(A)

Radiometric resolution designator. Thenumber of bits required to store themaximum data range will always been 8.This value is rigth justified in the field

38 1509 1 string(A)

Completly raw data. Part of the scenicradiometric correction designator, whichis a set of 16 1-byte codes, eachspecifying whether the identifiedcorrection has been aplied (value='Y') ornot (value='N')

38 1510 1 string(A) Linear representation /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1511 1 string(A) Logarithmic representation /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1512 1 string(A) other non-linear representation /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1514 1 string(A) sun illumination angle corretion /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1515 1 string(A) Haze correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1516 1 string(A) Sun illumniation and haze correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1517 1 string(A) standard radiometric enhancement /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1518 1 string(A) Rangeland enhancement /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1519 1 string(A) Foresty enhancement /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

38 1520 1 string(A) custom enhancement /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

Scenic radiometric correction designator


ISO 19115CEOS

38 1521 1 string(A) atmospheric correction /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1525 1 string(A)

Forward/reverse alignment. Part of thegeometric correction designator, which isa set of 16 1-byte codes, each specifyingwhether the identified correction hasbeen applied (value='Y') or not(value='N')

39 1526 1 string(A) Detector placement and delay /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1526 1 string(A) Mirror scan profile /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1528 1 string(A) Line length information /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1529 1 string(A) Gyro data /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1530 1 string(A) Angular displacement sensor (ADS) data /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1531 1 string(A) attitude correction system (ACS) data /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1532 1 string(A) Ephemeris data /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1533 1 string(A) Scan gap /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1534 1 string(A) ground control points. 'Y' in case of L1T /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1535 1 string(A) Earth rotation /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1536 1 string(A) sensor altitude and panoramic distortion /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1537 1 string(A) Digital terrain model (DTM). 'Y' in case ofL1T


Geometric correction designator


ISO 19115CEOS

39 1538 1 string(A) PCD available or not /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

39 1539 2 string(A) Ephemeris used. Set to 'P' for PCD, 'D'for Definitive or blank if unknown.


40 1541 1 string(A)

No resampling. Part of the mapresampling algorithm designator, which isa set of 1-byte codes, each specifyingwhether the identified algorithm has beenapplied (value='Y') or not (value='N')

40 1542 1 string(A) Resampling along line only /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

40 1543 1 string(A) Two-dimension resampling /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_processStep/description

40 1553 4 string(A)

XXX':resampling method identification.'NONE' for None (always applicable onraw products), 'NN$$' for Nearestneightbour, 'CC$$' for Cubic Convolution,'S8$$' for 8-point sin(x)/x, 'DS8$' for 8-point damped sin(x)/x, 'S16$' for 16-pointsin(x)/x, 'DS16' for 16-point dampedsin(x)/x, 'BLI$' for Bilinear interpolationand 'PSD$' for Pixel stuff/delete /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_pro

cessStep/description

42 1573 16 int(A)

Product processing level. It is stored astwo numerical characters representingthe overall level of corrections aplied.04:Syscorrected (L1Gpath), 05: Georeferenced (L1GMap), 07: Terraincorrected (L1T)

/MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/code

Map projection identifier

Map resampling designator

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. ImageryFile

ISO 19115

Id Byte Len Type, Encoding Description

13 1 1 unsignedByte(B)Synchro loss flag. It is the sync lossindicator for the current line. It is set to 1 ifsynchronisation is lost and to 0 otherwise /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_p

rocessStep/description

14 2 1 unsignedByte(B)Local use quality code. It is a qualitycontrol flag, set to 0 under normalconditions and 1 if error occurs.


15 2 1 unsignedByte(B)Detector substituition indicator is set to 1,if the video data for the line wassubstituted for another detector.


16 4 1x5 unsignedByte(B)Local use quality code, quality control flag,set to 0 under normal conditions and 1 iferror occurs.


Suffix data

CEOSIMAGERY FILE


Image Record


ISO 19115CEOS

19 17 2 unsignedShort(B)

Time error from line start to midscan orfirst half scan errors (FHSERR). The timeerror in clock counts from nominal linestart to midscan count of 161,164 can beconverted to time error in microsecondsby multiplying by R=1/(dataRate/16).Where dataRate=84.903 Mbps. A clockpulse is equal to 0.18845 microseconds,thus by multiplying with 161,164, it givest1=30371.41 microseconds. Finally,dividing by a pixel sample rate equal to9,611 microseconds, the result is 3160pixels, the thorical middle line of L5/TMVNIR bands.


ISO 19115CEOS

20 19 2 unsignedShort(B)

Time error from midscan to line end orsecond half scan error (SHSERR). Thetime error in clock counts from nominalmidscan to line stop count of 161,165 canbe converted to time error inmicroseconds by multiplying byR=1/(DataRate/16). The active scna timecan be computed using the followingformula ((161,164+161,165)-Field17+Field18))+R. Since pixels foreach detector within a line are sampledevery 9.611 microsenconds. The linelength is given by (Active ScanTime)/9611. Both scan error fields arecomprised of a sign bit and 11 binaryweighted bits, most significant bit first.Negative magnitudes (sign=1) are two'scomplement. When scan mirror assemblyoperates on scan angle monitors mode,three optical sensors give feedback tokeep the first half and the second halfscans as identical as possible. FHSERRans SHSERR result from this process.

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. TrailerFile

ISO 19115


Description

8 17 4 int (A)

Sequence number of trailer record withinband - Since one record of 4320 bytes canhold the histograms of only 4 detectors, fortraile records are required for each mirrorscan direction of each spectral band. Forband 6, full scans are replicated four times.Hence 16 histograms will be provided foreach mirror scan direction of band 6.

9 21 4096 string (B)

Histograms for 5 detectors within the band -This fields contains the histogram of the rawimage area for 4 detectors of the band.Histogram describes grey levels repartition,thus one grey level (between 0 and 255) isassociated with his number of detectors ofthe band 1 through 5 and 7, 8 trailer recordsfor band 8 and 2 trailer records for band 6.Histogram computation is made by step of 10pixels in order to speed up processingwithout loosing meaningful information.

10 4117 4 int (A) Parity errors count

CEOS


Trailer Record

TRAILER FILE

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. TrailerFile

11 4121 200 string (B)Quality summary, and local use - this fieldmay be used for a free format description ofthe data quality.

Annex A.1: Crosswalk between the CEOS format and the ISO 19115. SupplementalFile

ISO 19115


Description

12 33 12 string(A)Software release number - TMFR-VRX.X.X; where X.X.X is the softwareversion

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/LE_ProcessStep/processingInformation/LE_Processing/identifier/RS_Identifier/version

33 205 6 int(A) Number of processed ephemeris datarecords

34 211 6 int(A) Processed Ephemeris data record length

37 229 6 int(A) Number of scene quality data records38 235 6 int(A) Scene quality data record length

CEOSSUPPLEMENTAL FILE


Annex A.2: Crosswalk between the THREDDS format and the ISO 19115.

THREDDS ISO 19115<?xml version="1.0" encoding="UTF-8"?><gmi:MI_Metadata xmlns:gsr="http://www.isotc211.org/2005/gsr"xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmi="http://www.isotc211.org/2005/gmi" xmlns:srv="http://www.isotc211.org/2005/srv" xmlns:gmx="http://www.isotc211.org/2005/gmx" xsi:schemaLocation="http://www.ngdc.noaa.gov/metadata/published/xsd/schema.xsd"> <gmd:fileIdentifier> <gco:CharacterString>NWS/NEXRAD/NationalComposite/Unidata/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini</gco:CharacterString> /MD_Metadata/fileIdentifier </gmd:fileIdentifier> <gmd:language> <gmd:LanguageCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:LanguageCode" codeListValue="eng">eng</gmd:LanguageCode> /MD_Metadata/language </gmd:language> <gmd:characterSet> <gmd:MD_CharacterSetCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:MD_CharacterSetCode" codeListValue="UTF8">UTF8</gmd:MD_CharacterSetCode> /MD_Metadata/characterSet </gmd:characterSet> <gmd:hierarchyLevel> <gmd:MD_ScopeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode> /MD_Metadata/hierarchyLevel </gmd:hierarchyLevel> <gmd:hierarchyLevel> <gmd:MD_ScopeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:MD_ScopeCode" codeListValue="service">service</gmd:MD_ScopeCode> /MD_Metadata/hierarchyLevel </gmd:hierarchyLevel> <gmd:contact> <gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>UNIDATA</gco:CharacterString> </gmd:individualName> <gmd:organisationName gco:nilReason="missing"/> /MD_Metadata/contact/CI_ResponsibleParty/organisationName/


THREDDS ISO 19115 <gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:electronicMailAddress> <gco:CharacterString>[email protected]</gco:CharacterString> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/address/CI_Address/electronicMailAddress </gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.unidata.ucar.edu/</gmd:URL> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/linkage </gmd:linkage> <gmd:protocol> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/protocol <gco:CharacterString>http</gco:CharacterString> </gmd:protocol> <gmd:applicationProfile>

<gco:CharacterString>web browser</gco:CharacterString>/MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/applicationProfile

</gmd:applicationProfile> <gmd:name> <gco:CharacterString/> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/name </gmd:name> <gmd:description> <gco:CharacterString/> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/description </gmd:description> <gmd:function> <gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_OnLineFunctionCode" codeListValue="information">information</gmd:CI_OnLineFunctionCode> /MD_Metadata/contact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/function </gmd:function> </gmd:CI_OnlineResource> </gmd:onlineResource> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role>

<gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="pointOfContact">pointOfContact</gmd:CI_RoleCode> /MD_Metadata/contact/CI_ResponsibleParty/role </gmd:role> </gmd:CI_ResponsibleParty> </gmd:contact> <gmd:dateStamp> <gco:Date>2012-03-01</gco:Date> /MD_Metadata/dateStamp </gmd:dateStamp>


THREDDS ISO 19115 <gmd:metadataStandardName> <gco:CharacterString>ISO 19115-2 Geographic Information - Metadata Part 2 Extensions for imagery and gridded data</gco:CharacterString> /MD_Metadata/metadataStandardName </gmd:metadataStandardName> <gmd:metadataStandardVersion> <gco:CharacterString>ISO 19115-2:2009(E)</gco:CharacterString> /MD_Metadata/metadataStandardVersion </gmd:metadataStandardVersion> <gmd:spatialRepresentationInfo gco:nilReason="missing"/> /MD_Metadata/spatialRepresentationInfo <gmd:identificationInfo> <gmd:MD_DataIdentification id="DataIdentification"> <gmd:citation> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>RADAR-MOSIAC Composite Image</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/title </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:DateTime>2012-02-22T20:36:01Z</gco:DateTime> /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/date/DateTime </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode> /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:identifier> <gmd:MD_Identifier> <gmd:authority> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>UCAR/UOP</gco:CharacterString>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/authority/CI_Citation/title

</gmd:title>

<gmd:date gco:nilReason="inapplicable"/>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/authority/CI_Citation/date

</gmd:CI_Citation> </gmd:authority> <gmd:code> <gco:CharacterString>NWS/NEXRAD/NationalComposite/Unidata/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/code </gmd:code> </gmd:MD_Identifier> </gmd:identifier>


THREDDS ISO 19115 <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName>

<gco:CharacterString>UNIDATA</gco:CharacterString>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/individualName

</gmd:individualName>

<gmd:organisationName gco:nilReason="missing"/>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/organisationName

<gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:electronicMailAddress>

<gco:CharacterString>[email protected]</gco:CharacterString>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/address/CI_Address/electronicMailAddress

</gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.unidata.ucar.edu/</gmd:URL>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/linkage

</gmd:linkage> <gmd:protocol>

<gco:CharacterString>http</gco:CharacterString>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/protocol

</gmd:protocol> <gmd:applicationProfile> <gco:CharacterString>web browser</gco:CharacterString>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/applicationProfile

</gmd:applicationProfile> <gmd:name>

<gco:CharacterString/>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/name

</gmd:name> <gmd:description>

<gco:CharacterString/>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/description

</gmd:description> <gmd:function>

<gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_OnLineFunctionCode" codeListValue="information">information</gmd:CI_OnLineFunctionCode>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </gmd:onlineResource> </gmd:CI_Contact>


THREDDS ISO 19115 </gmd:contactInfo> <gmd:role> <gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="originator">originator</gmd:CI_RoleCode>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role

</gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> </gmd:CI_Citation> </gmd:citation> <gmd:abstract> <gco:CharacterString>Nexrad Level 3 1 hour precipitation National Composition at Resolution 2 km</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/abstract </gmd:abstract> <gmd:pointOfContact> <gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>UNIDATA</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/individualName </gmd:individualName> <gmd:organisationName gco:nilReason="missing"/> /MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/organisationName <gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:electronicMailAddress> <gco:CharacterString>[email protected]</gco:CharacterString>

/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/address/CI_Address/electronicMailAddress

</gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>http://www.unidata.ucar.edu/</gmd:URL>/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/linkage


<gco:CharacterString>http</gco:CharacterString>/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/protocol


/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/applicationProfile


<gco:CharacterString/>/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/name



THREDDS ISO 19115

<gco:CharacterString/>/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/description

</gmd:description> <gmd:function> <gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_OnLineFunctionCode" codeListValue="information">information</gmd:CI_OnLineFunctionCode>

/MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </gmd:onlineResource> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role>

<gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="pointOfContact">pointOfContact</gmd:CI_RoleCode> /MD_Metadata/identificationInfo/MD_DataIdentification/pointOfContact/CI_ResponsibleParty/role </gmd:role> </gmd:CI_ResponsibleParty> </gmd:pointOfContact> <gmd:descriptiveKeywords> <gmd:MD_Keywords> <gmd:keyword> <gco:CharacterString>UCAR/UNIDATA</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/descriptiveKeywords/MD_Keywords/keyword </gmd:keyword> <gmd:type> <gmd:MD_KeywordTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:MD_KeywordTypeCode" codeListValue="dataCenter">dataCenter</gmd:MD_KeywordTypeCode> /MD_Metadata/identificationInfo/MD_DataIdentification/descriptiveKeywords/MD_Keywords/type </gmd:type> <gmd:thesaurusName gco:nilReason="unknown"/> /MD_Metadata/identificationInfo/MD_DataIdentification/descriptiveKeywords/MD_Keywords/thesaurusName </gmd:MD_Keywords> </gmd:descriptiveKeywords> <gmd:resourceConstraints> <gmd:MD_LegalConstraints> <gmd:useLimitation> <gco:CharacterString/> /MD_Metadata/identificationInfo/MD_DataIdentification/resourceConstraints/MD_LegalConstraints/useLimitation </gmd:useLimitation> </gmd:MD_LegalConstraints> </gmd:resourceConstraints> <gmd:aggregationInfo> <gmd:MD_AggregateInformation> <gmd:aggregateDataSetIdentifier> <gmd:MD_Identifier> <gmd:authority> <gmd:CI_Citation> <gmd:title>


THREDDS ISO 19115 <gco:CharacterString>Unidata Common Data Model</gco:CharacterString>

/MD_Metadata/identificationInfo/MD_DataIdentification/aggregationInfo/MD_AggregateInformation/aggregateDataSetIdentifier/MD_Identifier/authority/CI_Citation/title

</gmd:title>

<gmd:date gco:nilReason="inapplicable"/>/MD_Metadata/identificationInfo/MD_DataIdentification/aggregationInfo/MD_AggregateInformation/aggregateDataSetIdentifier/MD_Identifier/authority/CI_Citation/date

</gmd:CI_Citation> </gmd:authority> <gmd:code>

<gco:CharacterString>GRID</gco:CharacterString>/MD_Metadata/identificationInfo/MD_DataIdentification/aggregationInfo/MD_AggregateInformation/aggregateDataSetIdentifier/MD_Identifier/code

</gmd:code> </gmd:MD_Identifier> </gmd:aggregateDataSetIdentifier> <gmd:associationType> <gmd:DS_AssociationTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:DS_AssociationTypeCode" codeListValue="largerWorkCitation">largerWorkCitation</gmd:DS_AssociationTypeCode> /MD_Metadata/identificationInfo/MD_DataIdentification/aggregationInfo/MD_AggregateInformation/associationType </gmd:associationType> <gmd:initiativeType>

<gmd:DS_InitiativeTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:DS_InitiativeTypeCode" codeListValue="project">project</gmd:DS_InitiativeTypeCode> /MD_Metadata/identificationInfo/MD_DataIdentification/aggregationInfo/MD_AggregateInformation/initiativeType </gmd:initiativeType> </gmd:MD_AggregateInformation> </gmd:aggregationInfo> <gmd:language> <gco:CharacterString>eng</gco:CharacterString> /MD_Metadata/identificationInfo/MD_DataIdentification/language </gmd:language> <gmd:topicCategory> <gmd:MD_TopicCategoryCode>climatologyMeteorologyAtmosphere</gmd:MD_TopicCategoryCode> /MD_Metadata/identificationInfo/MD_DataIdentification/topicCategory </gmd:topicCategory> <gmd:extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode>

<gco:Boolean>1</gco:Boolean>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/extentTypeCode/Boolean

</gmd:extentTypeCode> <gmd:westBoundLongitude>

<gco:Decimal>-120.02283</gco:Decimal>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/westBoundLongitude

</gmd:westBoundLongitude> <gmd:eastBoundLongitude>


THREDDS ISO 19115

<gco:Decimal>-63.5105</gco:Decimal>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/eastBoundLongitude

</gmd:eastBoundLongitude> <gmd:southBoundLatitude>

<gco:Decimal>23.0132</gco:Decimal>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/southBoundLatitude

</gmd:southBoundLatitude> <gmd:northBoundLatitude>

<gco:Decimal>47.30635</gco:Decimal>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/northBoundLatitude

</gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="d566647">

<gml:description>seconds</gml:description>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/temporalElement/EX_TemporalExtent/extent/TimePeriod/description

<gml:beginPosition>2012-02-22T20:33:00Z</gml:beginPosition>

/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/temporalElement/EX_TemporalExtent/extent/TimePeriod/beginPosition

<gml:endPosition>2012-02-22T20:33:00Z</gml:endPosition>

/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/temporalElement/EX_TemporalExtent/extent/TimePeriod/endPosition

</gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> <gmd:verticalElement> <gmd:EX_VerticalExtent> <gmd:minimumValue>

<gco:Real>0.0</gco:Real>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/minimumValue/Real

</gmd:minimumValue> <gmd:maximumValue>

<gco:Real>0.0</gco:Real>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/maximumValue/Real

</gmd:maximumValue>

<gmd:verticalCRS gco:nilReason="missing"/>/MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/verticalCRS

</gmd:EX_VerticalExtent> </gmd:verticalElement> </gmd:EX_Extent> </gmd:extent> </gmd:MD_DataIdentification> </gmd:identificationInfo> <gmd:identificationInfo> <srv:SV_ServiceIdentification id="OPeNDAP"> <gmd:citation> <gmd:CI_Citation> <gmd:title>


THREDDS ISO 19115 <gco:CharacterString>RADAR-MOSIAC Composite Image</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/title </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2012-02-22</gco:Date> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/date </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/dateType </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName>

<gco:CharacterString>UNIDATA</gco:CharacterString>/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/individualName


<gmd:organisationName gco:nilReason="missing"/>/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/organisationName



/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/address/CI_Address/electronicMailAddress


/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/linkage


<gco:CharacterString>http</gco:CharacterString>/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/protocol


/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/applicationProfile



THREDDS ISO 19115

<gco:CharacterString/>/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/name


<gco:CharacterString/>/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/description


/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </gmd:onlineResource> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role> <gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="originator">originator</gmd:CI_RoleCode>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role

</gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> </gmd:CI_Citation> </gmd:citation> <gmd:abstract> <gco:CharacterString>Nexrad Level 3 1 hour precipitation National Composition at Resolution 2 km</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/abstract </gmd:abstract> <srv:serviceType> <gco:LocalName>THREDDS OPeNDAP</gco:LocalName> /MD_Metadata/identificationInfo/SV_ServiceIdentification/serviceType </srv:serviceType> <srv:extent> <gmd:EX_Extent> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox> <gmd:extentTypeCode>

<gco:Boolean>1</gco:Boolean>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/extentTypeCode


<gco:Decimal>-120.02283</gco:Decimal>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/westBoundLongitude


<gco:Decimal>-63.5105</gco:Decimal>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/eastBoundLongitude



THREDDS ISO 19115

<gco:Decimal>23.0132</gco:Decimal>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/southBoundLatitude


<gco:Decimal>47.30635</gco:Decimal>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/northBoundLatitude

</gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent> <gmd:extent> <gml:TimePeriod gml:id="d566647e60"> <gml:beginPosition>2012-02-22T20:33:00Z</gml:beginPosition>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/temporalElement/EX_TemporalExtent/extent/TimePeriod/beginPosition


/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/temporalElement/EX_TemporalExtent/extent/TimePeriod/endPosition


<gco:Real>0.0</gco:Real>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/minimumValue


<gco:Real>0.0</gco:Real>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/maximumValue

</gmd:maximumValue>

<gmd:verticalCRS gco:nilReason="missing"/>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/verticalElement/EX_VerticalExtent/verticalCRS

</gmd:EX_VerticalExtent> </gmd:verticalElement> </gmd:EX_Extent> </srv:extent> <srv:couplingType> <srv:SV_CouplingType codeList="http://www.tc211.org/ISO19139/resources/codeList.xml#SV_CouplingType" codeListValue="tight">tight</srv:SV_CouplingType> /MD_Metadata/identificationInfo/SV_ServiceIdentification/couplingType </srv:couplingType> <srv:containsOperations> <srv:SV_OperationMetadata> <srv:operationName> <gco:CharacterString>OPeNDAPDatasetQueryAndAccess</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/operationName </srv:operationName> <srv:DCP gco:nilReason="unknown"/> <srv:connectPoint>


THREDDS ISO 19115 <gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>http://motherlode.ucar.edu:8080/thredds/dodsC/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini</gmd:URL>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP/connectPoint/CI_OnlineResource/linkage

</gmd:linkage> <gmd:name>

<gco:CharacterString>OPeNDAP</gco:CharacterString>/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP/connectPoint/CI_OnlineResource/name

</gmd:name> <gmd:description> <gco:CharacterString>THREDDS OPeNDAP</gco:CharacterString>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP/connectPoint/CI_OnlineResource/description

</gmd:description> <gmd:function> <gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="download">download</gmd:CI_OnLineFunctionCode>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP/connectPoint/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </srv:connectPoint> </srv:SV_OperationMetadata> </srv:containsOperations> <srv:operatesOn xlink:href="#DataIdentification"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/operatesOn </srv:SV_ServiceIdentification> </gmd:identificationInfo> <gmd:identificationInfo> <srv:SV_ServiceIdentification id="OGC-WCS"> <gmd:citation> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>RADAR-MOSIAC Composite Image

</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/title </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2012-02-22</gco:Date> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/date </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/dateType </gmd:dateType>


THREDDS ISO 19115 </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName>



















</gmd:function> </gmd:CI_OnlineResource>


THREDDS ISO 19115 </gmd:onlineResource> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role> <gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="originator">originator</gmd:CI_RoleCode>


</gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> </gmd:CI_Citation> </gmd:citation> <gmd:abstract>

<gco:CharacterString>Nexrad Level 3 1 hour precipitation National Composition at Resolution 2 km</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/abstract </gmd:abstract> <srv:serviceType> <gco:LocalName>Open Geospatial Consortium Web Coverage Service (WCS)</gco:LocalName> /MD_Metadata/identificationInfo/SV_ServiceIdentification/serviceType </srv:serviceType> <srv:extent> <gmd:EX_Extent> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox> <gmd:extentTypeCode>










</gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent> <gmd:extent>


THREDDS ISO 19115 <gml:TimePeriod gml:id="d566647e61"> <gml:beginPosition>2012-02-22T20:33:00Z</gml:beginPosition>








</gmd:maximumValue>


</gmd:EX_VerticalExtent> </gmd:verticalElement> </gmd:EX_Extent> </srv:extent> <srv:couplingType> <srv:SV_CouplingType codeList="http://www.tc211.org/ISO19139/resources/codeList.xml#SV_CouplingType" codeListValue="tight">tight</srv:SV_CouplingType> /MD_Metadata/identificationInfo/SV_ServiceIdentification/couplingType </srv:couplingType> <srv:containsOperations> <srv:SV_OperationMetadata> <srv:operationName> <gco:CharacterString>GetCapabilities</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/operationName </srv:operationName> <srv:DCP gco:nilReason="unknown"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP <srv:connectPoint> <gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>http://motherlode.ucar.edu:8080/thredds/wcs/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini?service=WCS&version=1.0.0&request=GetCapabilities</gmd:URL>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/linkage


<gco:CharacterString>OGC-WCS</gco:CharacterString>/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/name


THREDDS ISO 19115 </gmd:name> <gmd:description> <gco:CharacterString>Open Geospatial Consortium Web Coverage Service (WCS)</gco:CharacterString>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/description


/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </srv:connectPoint> </srv:SV_OperationMetadata> </srv:containsOperations> <srv:operatesOn xlink:href="#DataIdentification"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/operatesOn </srv:SV_ServiceIdentification> </gmd:identificationInfo> <gmd:identificationInfo> <srv:SV_ServiceIdentification id="OGC-WMS"> <gmd:citation> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>RADAR-MOSIAC Composite Image</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/title </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2012-02-22</gco:Date> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/date </gmd:date> <gmd:dateType>

<gmd:CI_DateTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/dateType </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName>




<gmd:contactInfo> <gmd:CI_Contact>


THREDDS ISO 19115 <gmd:address> <gmd:CI_Address> <gmd:electronicMailAddress>

















</gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty>


THREDDS ISO 19115 </gmd:CI_Citation> </gmd:citation> <gmd:abstract> <gco:CharacterString>Nexrad Level 3 1 hour precipitation National Composition at Resolution 2 km</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/abstract </gmd:abstract> <srv:serviceType> <gco:LocalName>Open Geospatial Consortium Web Map Service (WMS)</gco:LocalName> /MD_Metadata/identificationInfo/SV_ServiceIdentification/serviceType </srv:serviceType> <srv:extent> <gmd:EX_Extent> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox> <gmd:extentTypeCode>
















THREDDS ISO 19115




</gmd:maximumValue>


</gmd:EX_VerticalExtent> </gmd:verticalElement> </gmd:EX_Extent> </srv:extent> <srv:couplingType>

<srv:SV_CouplingType codeList="http://www.tc211.org/ISO19139/resources/codeList.xml#SV_CouplingType" codeListValue="tight">tight</srv:SV_CouplingType> /MD_Metadata/identificationInfo/SV_ServiceIdentification/couplingType </srv:couplingType> <srv:containsOperations> <srv:SV_OperationMetadata> <srv:operationName> <gco:CharacterString>GetCapabilities</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/operationName </srv:operationName> <srv:DCP gco:nilReason="unknown"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/DCP <srv:connectPoint> <gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>http://motherlode.ucar.edu:8080/thredds/wms/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini?service=WMS&version=1.3.0&request=GetCapabilities</gmd:URL>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/linkage


<gco:CharacterString>OGC-WMS</gco:CharacterString>/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/name

</gmd:name> <gmd:description> <gco:CharacterString>Open Geospatial Consortium Web Map Service (WMS)</gco:CharacterString>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/description


/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMetadata/connectPoint/CI_OnlineResource/function

</gmd:function>


THREDDS ISO 19115 </gmd:CI_OnlineResource> </srv:connectPoint> </srv:SV_OperationMetadata> </srv:containsOperations> <srv:operatesOn xlink:href="#DataIdentification"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/operatesOn </srv:SV_ServiceIdentification> </gmd:identificationInfo> <gmd:identificationInfo> <srv:SV_ServiceIdentification id="THREDDS_NetCDF_Subset"> <gmd:citation> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>RADAR-MOSIAC Composite Image</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/title </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2012-02-22</gco:Date> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/date </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode> /MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/date/CI_Date/dateType </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName>







</gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage>


THREDDS ISO 19115 <gmd:URL>http://www.unidata.ucar.edu/</gmd:URL>













/MD_Metadata/identificationInfo/SV_ServiceIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode

</gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> </gmd:CI_Citation> </gmd:citation> <gmd:abstract> <gco:CharacterString>Nexrad Level 3 1 hour precipitation National Composition at Resolution 2 km</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/abstract </gmd:abstract> <srv:serviceType> <gco:LocalName>THREDDS NetCDF Subset Service</gco:LocalName> /MD_Metadata/identificationInfo/SV_ServiceIdentification/serviceType/LocalName </srv:serviceType> <srv:extent> <gmd:EX_Extent> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox>


THREDDS ISO 19115 <gmd:extentTypeCode>















<gco:Real>0.0</gco:Real>/MD_Metadata/identificationInfo/SV_ServiceIdentification/extent/EX_Extent/verticalElement/EX_VerticalEtent/minimumValue



</gmd:maximumValue>


</gmd:EX_VerticalExtent> </gmd:verticalElement> </gmd:EX_Extent> </srv:extent> <srv:couplingType>


THREDDS ISO 19115 <srv:SV_CouplingType codeList="http://www.tc211.org/ISO19139/resources/codeList.xml#SV_CouplingType" codeListValue="tight">tight</srv:SV_CouplingType> /MD_Metadata/identificationInfo/SV_ServiceIdentification/couplingType/SV_CouplingType </srv:couplingType> <srv:containsOperations> <srv:SV_OperationMetadata> <srv:operationName> <gco:CharacterString>NetCDFSubsetService</gco:CharacterString> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/operationName </srv:operationName> <srv:DCP gco:nilReason="unknown"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/DCP <srv:connectPoint> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://motherlode.ucar.edu:8080/thredds/ncss/grid/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini/dataset.html</gmd:URL>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/connectPoint/CI_OnlineResource/linkage

</gmd:linkage> <gmd:name> <gco:CharacterString>THREDDS_NetCDF_Subset</gco:CharacterString>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/connectPoint/CI_OnlineResource/name


<gco:CharacterString>THREDDS NetCDF Subset Service</gco:CharacterString>

/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/connectPoint/CI_OnlineResource/description


/MD_Metadata/identificationInfo/SV_ServiceIdentification/containsOperations/SV_OperationMatedata/connectPoint/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </srv:connectPoint> </srv:SV_OperationMetadata> </srv:containsOperations> <srv:operatesOn xlink:href="#DataIdentification"/> /MD_Metadata/identificationInfo/SV_ServiceIdentification/operatesOn </srv:SV_ServiceIdentification> </gmd:identificationInfo> <gmd:contentInfo> <gmi:MI_CoverageDescription> <gmd:attributeDescription gco:nilReason="unknown"/> /MD_Metadata/contentInfo/MI_CoverageDescription/attributeDescription <gmd:contentType>


THREDDS ISO 19115

<gmd:MD_CoverageContentTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:MD_CoverageContentTypeCode" codeListValue="physicalMeasurement">physicalMeasurement</gmd:MD_CoverageContentTypeCode> /MD_Metadata/contentInfo/MI_CoverageDescription/contentType/MD_CoverageContentTypeCode </gmd:contentType> <gmd:dimension> <gmd:MD_Band> <gmd:sequenceIdentifier> <gco:MemberName> <gco:aName> <gco:CharacterString>Precipitation</gco:CharacterString> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/sequenceIdentifier/MemberName/aName </gco:aName> <gco:attributeType> <gco:TypeName> <gco:aName>

<gco:CharacterString>float</gco:CharacterString>/MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/sequenceIdentifier/MemberName/attributeType/TypeName/aName

</gco:aName> </gco:TypeName> </gco:attributeType> </gco:MemberName> </gmd:sequenceIdentifier> <gmd:descriptor> <gco:CharacterString>2 km National 1-hour Precipitation (Unidata)</gco:CharacterString> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/descriptor </gmd:descriptor> <gmd:units xlink:href="http://someUnitsDictionary.xml#IN"/> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/units </gmd:MD_Band> </gmd:dimension> <gmd:dimension> <gmd:MD_Band> <gmd:sequenceIdentifier> <gco:MemberName> <gco:aName> <gco:CharacterString>LambertConformal</gco:CharacterString> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/sequenceIdentifier/MemberName/aName </gco:aName> <gco:attributeType> <gco:TypeName> <gco:aName>

<gco:CharacterString>char</gco:CharacterString>/MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/sequenceIdentifier/MemberName/attributeType/TypeName/aName

</gco:aName> </gco:TypeName> </gco:attributeType> </gco:MemberName> </gmd:sequenceIdentifier> <gmd:descriptor> <gco:CharacterString/> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/descriptor


THREDDS ISO 19115 </gmd:descriptor> <gmd:units xlink:href="http://someUnitsDictionary.xml#"/> /MD_Metadata/contentInfo/MI_CoverageDescription/dimension/MD_Band/units </gmd:MD_Band> </gmd:dimension> </gmi:MI_CoverageDescription> </gmd:contentInfo> <gmd:distributionInfo> <gmd:MD_Distribution> <gmd:distributor> <gmd:MD_Distributor> <gmd:distributorContact> <gmd:CI_ResponsibleParty>

<gmd:individualName gco:nilReason="missing"/>/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorContact/CI_ResponsibleParty/individualName

<gmd:organisationName> <gco:CharacterString>UCAR/UNIDATA</gco:CharacterString>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorContact/CI_ResponsibleParty/organisationName

</gmd:organisationName> <gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:electronicMailAddress>


/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorContact/CI_ResponsibleParty/contactInfo/CI_Contact(address/CI_Address/electronicMailAddress

</gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role> <gmd:CI_RoleCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#gmd:CI_RoleCode" codeListValue="publisher">publisher</gmd:CI_RoleCode>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorContact/CI_ResponsibleParty/role/CI_RoleCode

</gmd:role> </gmd:CI_ResponsibleParty> </gmd:distributorContact> <gmd:distributorFormat> <gmd:MD_Format> <gmd:name> <gco:CharacterString>OPeNDAP</gco:CharacterString> /MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorFormat/MD_Format/name </gmd:name> <gmd:version gco:nilReason="unknown"/> /MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorFormat/MD_Format/version </gmd:MD_Format> </gmd:distributorFormat> <gmd:distributorTransferOptions> <gmd:MD_DigitalTransferOptions> <gmd:onLine> <gmd:CI_OnlineResource>


THREDDS ISO 19115 <gmd:linkage>

<gmd:URL>http://motherlode.ucar.edu:8080/thredds/dodsC/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini.html</gmd:URL>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/linkage

</gmd:linkage> <gmd:name> <gco:CharacterString>File Information</gco:CharacterString>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/name


<gco:CharacterString>This URL provides a standard OPeND/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/description

for selecting data from this dataset. Change the extension to .info for a description of the dataset.</gco:CharacterString> </gmd:description> <gmd:function> <gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="download">download</gmd:CI_OnLineFunctionCode>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </gmd:onLine> </gmd:MD_DigitalTransferOptions> </gmd:distributorTransferOptions> <gmd:distributorTransferOptions> <gmd:MD_DigitalTransferOptions> <gmd:onLine> <gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>http://www.ncdc.noaa.gov/oa/wct/wct-jnlp-beta.php?singlefile=http://motherlode.ucar.edu:8080/thredds/dodsC/nexrad/composite/gini/n1p/2km/20120222/Level3_Composite_n1p_2km_20120222_2033.gini</gmd:URL>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/linkage

</gmd:linkage> <gmd:name> <gco:CharacterString>Viewer Information</gco:CharacterString>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/name

</gmd:name> <gmd:description> <gco:CharacterString>This URL provides an NCDC climate and weather toolkit view of an OPeNDAP

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/description

resource.</gco:CharacterString> </gmd:description> <gmd:function>


THREDDS ISO 19115 <gmd:CI_OnLineFunctionCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#CI_PresentationFormCode" codeListValue="mapDigital">mapDigital</gmd:CI_OnLineFunctionCode>

/MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/MD_DigitalTransferOptions/onLine/CI_OnlineResource/function

</gmd:function> </gmd:CI_OnlineResource> </gmd:onLine> </gmd:MD_DigitalTransferOptions> </gmd:distributorTransferOptions> </gmd:MD_Distributor> </gmd:distributor> </gmd:MD_Distribution> </gmd:distributionInfo> <gmd:metadataMaintenance> <gmd:MD_MaintenanceInformation> <gmd:maintenanceAndUpdateFrequency gco:nilReason="unknown"/> /MD_Metadata/metadataMaintenance/MD_MaintenanceInformation/maintenanceAndUpdateFrequency <gmd:maintenanceNote> <gco:CharacterString>This record was translated from NcML using UnidataDD2MI.xsl Version 2.2</gco:CharacterString> /MD_Metadata/metadataMaintenance/MD_MaintenanceInformation/maintenanceNote </gmd:maintenanceNote> </gmd:MD_MaintenanceInformation> </gmd:metadataMaintenance></gmi:MI_Metadata>

Annex A.3: Crosswalk between the NDF format and the ISO 19115. H1

NDF H1 file ISO 19115NDF_REVISIONDATA_SET_TYPEPRODUCT_NUMBER /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/codePIXEL_FORMATPIXEL_ORDERBITS_PER_PIXEL /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/bitsPerValuePIXELS_PER_LINELINES_PER_DATA_FILEDATA_ORIENTATIONNUMBER_OF_DATA_FILESDATA_FILE_INTERLEAVINGTAPE_SPANNING_FLAGSTART_LINE_NUMBERSTART_DATA_FILELINES_PER_VOLUMEBLOCKING_FACTORRECORD_SIZEUPPER_LEFT_CORNERUPPER_RIGHT_CORNERLOWER_RIGHT_CORNERLOWER_LEFT_CORNERREFERENCE_POINTREFERENCE_POSITIONREFERENCE_OFFSETORIENTATIONMAP_PROJECTION_NAME /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpaceUSGS_PROJECTION_NUMBER /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpaceUSGS_MAP_ZONE /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpace

USGS_PROJECTION_PARAMETERSHORIZONTAL_DATUM /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpaceEARTH_ELLIPSOID_SEMI-MAJOR_AXISEARTH_ELLIPSOID_SEMI-MINOR_AXISEARTH_ELLIPSOID_ORIGIN_OFFSETEARTH_ELLIPSOID_ROTATION_OFFSET


NDF H1 file ISO 19115PRODUCT_SIZEPIXEL_SPACING /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/DistancePIXEL_SPACING_UNITS /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/units/UomLengthRESAMPLING /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/descriptionPROCESSING_DATE/TIME /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/dateTime

PROCESSING_SOFTWARE/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/LI_ProcessStep/processingInformation/LE_Processing/identifier/MD_Identifier/code

NUMBER_OF_BANDS_IN_VOLUME

WRS/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

ACQUISITION_DATE/TIME /MD_Metadata/dateStampSATELLITE /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/codeSATELLITE_INSTRUMENT /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/identifier/MD_Identifier/codePROCESSING_LEVEL /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/MD_Identifier/codeSUN_ELEVATION /MD_Metadata/contentInfo/MD_ImageDescription/illuminationElevationAngleSUN_AZIMUTH /MD_Metadata/contentInfo/MD_ImageDescription/illuminationAzimuthAngleBAND1_NAMEBAND1_FILENAMEBAND1_WAVELENGTHSBAND1_RADIOMETRIC_GAINS/BIASBAND2_NAMEBAND2_FILENAMEBAND2_WAVELENGTHSBAND2_RADIOMETRIC_GAINS/BIASBAND3_NAMEBAND3_FILENAMEBAND3_WAVELENGTHSBAND3_RADIOMETRIC_GAINS/BIASBAND4_NAMEBAND4_FILENAMEBAND4_WAVELENGTHSBAND4_RADIOMETRIC_GAINS/BIASBAND5_NAMEBAND5_FILENAMEBAND5_WAVELENGTHS


NDF H1 file ISO 19115BAND5_RADIOMETRIC_GAINS/BIASBAND6_NAMEBAND6_FILENAMEBAND6_WAVELENGTHSBAND6_RADIOMETRIC_GAINS/BIASBAND7_NAMEBAND7_FILENAMEBAND7_WAVELENGTHSBAND7_RADIOMETRIC_GAINS/BIASEND_OF_HDR;

Annex A.3: Crosswalk between the NDF format and the ISO 19115. HI and WO

NDF HI file

This ASCII-text file provides documentation about the original customer request and the processing parameters used to produce the NLAPS digital product.

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/processStep/LE_processStep/report/LE_ProcessStepReport/name/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/processStep/LE_processStep/report/LE_ProcessStepReport/fileType

NDF WO file

NLAPS corrections processing report. The Work Order Report file is an ASCII-text file that contains information related to the specific order for the data processing at the processing center.


Annex A.4: Crosswalk between the GloVis format and the ISO 19115. MTL

GLOVIS MTL file ISO 19115GROUP = L1_METADATA_FILE GROUP = METADATA_FILE_INFO

ORIGIN/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/originator

REQUEST_ID /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/code

PRODUCT_CREATION_TIME/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

STATION_ID/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/resourceProvider

LANDSAT7_XBAND

GROUND_STATION/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/processor

LPS_PROCESSOR_NUMBER DATEHOUR_CONTACT_PERIOD SUBINTERVAL_NUMBER END_GROUP = METADATA_FILE_INFO GROUP = PRODUCT_METADATA PRODUCT_TYPE /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/MD_Identifier/code ELEVATION_SOURCE /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/title

PROCESSING_SOFTWARE/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/LE_ProcessStep/processingInformation/LE_Processing/identifier/RS_Identifier/version

EPHEMERIS_TYPE SPACECRAFT_ID /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code SENSOR_ID /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/identifier/MD_Identifier/code SENSOR_MODE /MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/typer ACQUISITION_DATE /MD_Metadata/dateStamp SCENE_CENTER_SCAN_TIME /MD_Metadata/dateStamp

WRS_PATH/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

STARTING_ROW/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

ENDING_ROW/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

BAND_COMBINATION PRODUCT_UL_CORNER_LAT /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeft PRODUCT_UL_CORNER_LON /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeft PRODUCT_UR_CORNER_LAT /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRight PRODUCT_UR_CORNER_LON /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRight PRODUCT_LL_CORNER_LAT /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeft PRODUCT_LL_CORNER_LON /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeft PRODUCT_LR_CORNER_LAT /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRight PRODUCT_LR_CORNER_LON /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRight PRODUCT_UL_CORNER_MAPX /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeft PRODUCT_UL_CORNER_MAPY /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeft


PRODUCT_UR_CORNER_MAPX /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRight PRODUCT_UR_CORNER_MAPY /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRight PRODUCT_LL_CORNER_MAPX /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeft PRODUCT_LL_CORNER_MAPY /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeft PRODUCT_LR_CORNER_MAPX /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRight PRODUCT_LR_CORNER_MAPY /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRight PRODUCT_SAMPLES_PAN PRODUCT_LINES_PAN PRODUCT_SAMPLES_REF PRODUCT_LINES_REF PRODUCT_SAMPLES_THM PRODUCT_LINES_THM BAND1_FILE_NAME BAND2_FILE_NAME BAND3_FILE_NAME BAND4_FILE_NAME BAND5_FILE_NAME BAND61_FILE_NAME BAND62_FILE_NAME BAND7_FILE_NAME BAND8_FILE_NAME GCP_FILE_NAME METADATA_L1_FILE_NAME

CPF_FILE_NAME/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/processStep/LE_processStep/report/LE_ProcessStepReport/name

END_GROUP = PRODUCT_METADATA GROUP = MIN_MAX_RADIANCE LMAX_BAND1 LMIN_BAND1 LMAX_BAND2 LMIN_BAND2 LMAX_BAND3 LMIN_BAND3 LMAX_BAND4 LMIN_BAND4 LMAX_BAND5 LMIN_BAND5 LMAX_BAND61 LMIN_BAND61 LMAX_BAND62 LMIN_BAND62 LMAX_BAND7 LMIN_BAND7 LMAX_BAND8 LMIN_BAND8


END_GROUP = MIN_MAX_RADIANCE GROUP = MIN_MAX_PIXEL_VALUE QCALMAX_BAND1 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND1 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND2 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND2 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND3 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND3 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND4 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND4 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND5 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND5 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND61 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND61 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND62 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND62 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND7 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND7 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue QCALMAX_BAND8 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue QCALMIN_BAND8 /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue END_GROUP = MIN_MAX_PIXEL_VALUE GROUP = PRODUCT_PARAMETERS CORRECTION_METHOD_GAIN_BAND1 CORRECTION_METHOD_GAIN_BAND2 CORRECTION_METHOD_GAIN_BAND3 CORRECTION_METHOD_GAIN_BAND4 CORRECTION_METHOD_GAIN_BAND5 CORRECTION_METHOD_GAIN_BAND61 CORRECTION_METHOD_GAIN_BAND62 CORRECTION_METHOD_GAIN_BAND7 CORRECTION_METHOD_GAIN_BAND8 CORRECTION_METHOD_BIAS BAND1_GAIN BAND2_GAIN BAND3_GAIN BAND4_GAIN BAND5_GAIN BAND6_GAIN1 BAND6_GAIN2 BAND7_GAIN BAND8_GAIN BAND1_GAIN_CHANGE BAND2_GAIN_CHANGE BAND3_GAIN_CHANGE BAND4_GAIN_CHANGE

Related with CPF_FILE_NAME


BAND5_GAIN_CHANGE BAND6_GAIN_CHANGE1 BAND6_GAIN_CHANGE2 BAND7_GAIN_CHANGE BAND8_GAIN_CHANGE BAND1_SL_GAIN_CHANGE BAND2_SL_GAIN_CHANGE BAND3_SL_GAIN_CHANGE BAND4_SL_GAIN_CHANGE BAND5_SL_GAIN_CHANGE BAND6_SL_GAIN_CHANGE1 BAND6_SL_GAIN_CHANGE2 BAND7_SL_GAIN_CHANGE BAND8_SL_GAIN_CHANGE SUN_AZIMUTH /MD_Metadata/contentInfo/MD_ImageDescription/illuminationAzimuthAngle SUN_ELEVATION /MD_Metadata/contentInfo/MD_ImageDescription/illuminationElevationAngle OUTPUT_FORMAT /MD_Metadat/MD_DataIdentification/spatialRepresentationType/grid END_GROUP = PRODUCT_PARAMETERS GROUP = CORRECTIONS_APPLIED STRIPING_BAND1 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND2 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND3 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND4 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND5 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND61 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND62 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND7 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description STRIPING_BAND8 /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description BANDING /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description COHERENT_NOISE /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description MEMORY_EFFECT /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description SCAN_CORRELATED_SHIFT /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description INOPERABLE_DETECTORS /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description DROPPED_LINES /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description END_GROUP = CORRECTIONS_APPLIED GROUP = PROJECTION_PARAMETERS REFERENCE_DATUM /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpace REFERENCE_ELLIPSOID /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpace GRID_CELL_SIZE_PAN /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/Distance GRID_CELL_SIZE_THM /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/Distance GRID_CELL_SIZE_REF /MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/Distance ORIENTATION /MD_Metadata/spatialRepresentationInfo/MD_Georeferenceable/orientationParameterDescription RESAMPLING_OPTION /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description SCAN_GAP_INTERPOLATION /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description MAP_PROJECTION /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpace


END_GROUP = PROJECTION_PARAMETERS GROUP = UTM_PARAMETERS ZONE_NUMBER /MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/codeSpace END_GROUP = UTM_PARAMETERS GROUP = GEOMETRIC_VERIFY

UL_QUAD_RMSE/MD_Metadata/dataQualityInfo/DQ_DataQuality/report/DQ_GriddedDataPositionalAccuracy/result/DQ_QuantitativeResult/value

UR_QUAD_RMSE/MD_Metadata/dataQualityInfo/DQ_DataQuality/report/DQ_GriddedDataPositionalAccuracy/result/DQ_QuantitativeResult/value

LR_QUAD_RMSE/MD_Metadata/dataQualityInfo/DQ_DataQuality/report/DQ_GriddedDataPositionalAccuracy/result/DQ_QuantitativeResult/value

LL_QUAD_RMSE/MD_Metadata/dataQualityInfo/DQ_DataQuality/report/DQ_GriddedDataPositionalAccuracy/result/DQ_QuantitativeResult/value

SCENE_RMSE/MD_Metadata/dataQualityInfo/DQ_DataQuality/report/DQ_GriddedDataPositionalAccuracy/result/DQ_QuantitativeResult/value

END_GROUP = GEOMETRIC_VERIFYEND_GROUP = L1_METADATA_FILEEND

Annex A.4: Crosswalk between the GloVis format and the ISO 19115. META

GLOVIS Meta file ISO 19115entityID /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/identifier/MD_Identifier/codelinessamples

path/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

row/MD_Metadata/identificationInfo/MD_MetadataIdentification/extent/Ex_extent/geographicElement/Ex_GeographicDescription/geographicIdentifier/MD_Identifier/code

cloud_cover tadata/contentInfo/MD_ImageDescription/cloudCoverPercentagecloud_cover_quad_ul tadata/contentInfo/MD_ImageDescription/cloudCoverPercentagecloud_cover_quad_ur tadata/contentInfo/MD_ImageDescription/cloudCoverPercentagecloud_cover_quad_ll tadata/contentInfo/MD_ImageDescription/cloudCoverPercentagecloud_cover_quad_lr tadata/contentInfo/MD_ImageDescription/cloudCoverPercentagescene_center_lat /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/centerscene_center_lon /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/centercorner_ul_lat /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeftcorner_ul_lon /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperLeftcorner_ur_lat /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRightcorner_ur_lon /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/upperRightcorner_lr_lat /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeftcorner_lr_lon /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerLeftcorner_ll_lat /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRightcorner_ll_lon /MD_Metadata/spatialRepresentationInfo/MD_Georectified/pointInPixel/MD_PixelOrientationCode/lowerRightsun_azimuth /MD_Metadata/contentInfo/MD_ImageDescription/illuminationAzimuthAnglesun_elevation /MD_Metadata/contentInfo/MD_ImageDescription/illuminationElevationAnglescene_center_scan_time /MD_Metadata/dateStampLocalBrowseName /MD_Metadata/identificationInfo/MD_Identification/graphicOverview/MD_BrowseGraphic/fileNameday_nightbrowse_existsdate_acquired /MD_Metadata/dateStampfull_partial_scenesensor_mode

scene_source/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/resourceProvider

station_id/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/processor

Annex A.4: Crosswalk between the GloVis format and the ISO 19115. META

GLOVIS Meta file ISO 19115start_time /MD_Metadata/dateStampstop_time /MD_Metadata/dateStampsensor_anomalies /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/descriptionimage_quality_vcid_ /MD_Metadata/contentInfo/MD_ImageDescription/imageQualityCode/codeimage_quality_vcid_2 /MD_Metadata/contentInfo/MD_ImageDescription/imageQualityCode/codegain_band_1gain_band_2gain_band_3gain_band_4gain_band_5gain_band_6_vcid_1gain_band_6_vcid_2gain_band_7gain_band_8gain_change_band_1gain_change_band_2gain_change_band_3gain_change_band_4gain_change_band_5gain_change_band_6_vcid_1gain_change_band_6_vcid_2gain_change_band_7gain_change_band_8landsat_interval_idproduct_file_sizeproduct_locationgap_phase_statistic /MD_Metadata/dataQualityInfo/DQ_DataQuality/report/QE_Usability/result/DQ_QuantitativeResult/valuegap_phase_source /MD_Metadata/dataQualityInfo/DQ_DataQuality/report/QE_Usability/evaluationProcedure/data_categoryfull_aperture_calibration /MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/description

Annex A.4: Crosswalk between the GloVis format and the ISO 19115. GCP

Point_ID Latitude Longitude Height Across Along Residual ResidualScan Scan In y in xResidual Residual dir dir

(deg) (deg) (meters) (meters) (meters) (meters) (meters)

1970310002 41.88448 2.502214 912.084 5.012 -0.684 5.041 0.2941970310006 41.2556 1.650462 145.11 -11.463 1.201 -11.474 -1.0361970310007 41.95131 2.594719 319.297 9.039 -6.644 10.143 -4.7731970310008 41.67462 2.800452 53.07 -10.32 1.362 -10.384 -0.657

The GCP file is an ASCII file containing a list of the ground control points used during thegeometric correction process of the Landsat GloVis L1T images.This file documents the coordinate of every control point as well as it positional accuracy.


GLOVIS GCP file

ISO 19115

Annex A.5: Crosswalk between the DIMI format and the ISO 19115.

DIMAP ISO 19115<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href='STYLE.XSL' type='text/xsl'?><Dimap_Document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Spot_Scene.xsd" name="METADATA.DIM"> <Metadata_Id> <METADATA_FORMAT version="1.1">DIMAP</METADATA_FORMAT> <METADATA_PROFILE></METADATA_PROFILE> </Metadata_Id> <Dataset_Id>

<DATASET_NAME></DATASET_NAME> /MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/title

<COPYRIGHT></COPYRIGHT>

/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/originator

<DATASET_QL_PATH href=""/>/MD_Metadata/identificationInfo/MD_Identification/graphicOverview/MD_BrowseGraphic/fileName

<DATASET_QL_FORMAT version=""></DATASET_QL_FORMAT> <DATASET_TN_PATH href=""/>

<DATASET_TN_FORMAT></DATASET_TN_FORMAT>/MD_Metadata/identificationInfo/MD_Identification/graphicOverview/MD_BrowseGraphic/fileType

</Dataset_Id>

<Coordinate_Reference_System> <GEO_TABLES version=""></GEO_TABLES> <Horizontal_CS>

<HORIZONTAL_CS_CODE></HORIZONTAL_CS_CODE>/MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/RS_Identifier/codeSpace

<HORIZONTAL_CS_TYPE></HORIZONTAL_CS_TYPE>

<HORIZONTAL_CS_NAME></HORIZONTAL_CS_NAME>/MD_Metadata/referenceSystemInfo/MD_ReferenceSystem/referenceSystemIdentifier/RS_Identifier/codeSpace

</Horizontal_CS> </Coordinate_Reference_System>


DIMAP ISO 19115

<JOB_ID></JOB_ID>

/MD_Metadata/dataQualityInfo/DQ_Quality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/identifier/MD_Identifier/code

<PRODUCT_TYPE></PRODUCT_TYPE> /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/code

<PRODUCT_INFO></PRODUCT_INFO>/MD_Metadata/dataQualityInfo/DQ_Quality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/title

<DATASET_PRODUCER_NAME></DATASET_PRODUCER_NAME>

/MD_Metadata/dataQualityInfo/DQ_Quality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/organisationName

<DATASET_PRODUCER_URL href="http://www.spotimage.fr"/>

/MD_Metadata/dataQualityInfo/DQ_Quality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_contact/onlineResource

<DATASET_PRODUCTION_DATE></DATASET_PRODUCTION_DATE>

/MD_Metadata/dataQualityInfo/DQ_Quality/lineage/Ll_Lineage/source/sourceCitation/CI_Citation/date/CI_Date/dateType/CI_DateTypeCode/creation

<Production_Facility>

<SOFTWARE_NAME></SOFTWARE_NAME>

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/LE_ProcessStep/processingInformation/LE_Processing/softwareReference/CI_Citation/title

<SOFTWARE_VERSION></SOFTWARE_VERSION>

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/LE_ProcessStep/processingInformation/LE_Processing/identifier/RS_Identifier/version

<PROCESSING_CENTER></PROCESSING_CENTER>/MD_Metadata/identificationInfo/MD_DataIdentification/citation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/role/CI_RoleCode/processor

</Production_Facility> </Production> <Dataset_Sources> <Source_Information>

<SOURCE_TYPE></SOURCE_TYPE>/MD_Metadata/lineage/Ll_Lineage/source/Ll_Source/sourceCitation/CI_Citation/title

<SOURCE_ID></SOURCE_ID>/MD_Metadata/lineage/Ll_Lineage/source/Ll_Source/sourceCitation/CI_Citation/identifier/MD_Identifier/code


DIMAP ISO 19115 <SOURCE_DESCRIPTION></SOURCE_DESCRIPTION> /MD_Metadata/lineage/Ll_Lineage/source/Ll_Source/description <Scene_Source> <GRID_REFERENCE></GRID_REFERENCE> <SHIFT_VALUE></SHIFT_VALUE>

<IMAGING_DATE></IMAGING_DATE>/MD_Metadata/lineage/Ll_Lineage/source/Ll_Source/sourceCitation/CI_Citation/date/CI_Date/date

<IMAGING_TIME></IMAGING_TIME>/MD_Metadata/lineage/Ll_Lineage/source/Ll_Source/sourceCitation/CI_Citation/date/CI_Date/date

<MISSION></MISSION>/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/citation/CI_citation/title

<MISSION_INDEX></MISSION_INDEX>/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/platform/MI_Platform/identifier/MD_Identifier/code

<INSTRUMENT></INSTRUMENT>/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/citation/CI_Citation/title

<INSTRUMENT_INDEX></INSTRUMENT_INDEX>/MI_Metadata/acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrumet/identifier/MD_Identifier/code

<SENSOR_CODE></SENSOR_CODE> <SCENE_PROCESSING_LEVEL></SCENE_PROCESSING_LEVEL> /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/code <INCIDENCE_ANGLE></INCIDENCE_ANGLE> <SUN_AZIMUTH></SUN_AZIMUTH> /MD_Metadata/contentInfo/MD_ImageDescription/illuminationAzimuthAngle <SUN_ELEVATION></SUN_ELEVATION> /MD_Metadata/contentInfo/MD_ImageDescription/illuminationElevationAngle <Imaging_Parameters> <REVOLUTION_NUMBER></REVOLUTION_NUMBER> <COMPRESSION_MODE></COMPRESSION_MODE> <DIRECT_PLAYBACK_INDICATOR></DIRECT_PLAYBACK_INDICATOR> <COUPLED_MODE_FLAG></COUPLED_MODE_FLAG> <SWATH_MODE></SWATH_MODE> <REFOCUSING_STEP_NUM></REFOCUSING_STEP_NUM> </Imaging_Parameters> </Scene_Source> </Source_Information> </Dataset_Sources>

<Raster_Encoding>


DIMAP ISO 19115

<NBITS></NBITS>/MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/bitsPerValue

<DATA_TYPE></DATA_TYPE> <BYTEORDER></BYTEORDER> <COMPRESSION_NAME></COMPRESSION_NAME> </Raster_Encoding>

<Data_Processing> <PROCESSING_LEVEL></PROCESSING_LEVEL> /MD_Metadata/contentInfo/MD_ImageDescription/processingLevelCode/code

<GEOMETRIC_PROCESSING></GEOMETRIC_PROCESSING>/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description

<RADIOMETRIC_PROCESSING></RADIOMETRIC_PROCESSING>/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description

<Processing_Options> <MEAN_RECTIFICATION_ELEVATION></MEAN_RECTIFICATION_ELEVATION>

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description

<Dynamic_Stretch> <Thresholds> <BAND_INDEX></BAND_INDEX>

<LOW_THRESHOLD></LOW_THRESHOLD>/MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/minValue

<HIGH_THRESHOLD></HIGH_THRESHOLD>/MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MD_Band/maxValue

</Thresholds> <Thresholds> <BAND_INDEX></BAND_INDEX>





DIMAP ISO 19115






</Thresholds> </Dynamic_Stretch> <LINE_SHIFT></LINE_SHIFT>

<RESAMPLING_METHOD></RESAMPLING_METHOD>/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description

<Sampling_Step>

<SAMPLING_STEP_X></SAMPLING_STEP_X>/MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/Distance

<SAMPLING_STEP_Y></SAMPLING_STEP_Y>/MD_Metadata/contentInfo/MD_CoverageDescription/dimension/MI_Band/nominalSpatialResolution/Distance

</Sampling_Step> <SWIR_BAND_REGISTRATION_FLAG></SWIR_BAND_REGISTRATION_FLAG>

/MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/processStep/Ll_ProcessStep/description

</Processing_Options> </Data_Processing>

<Dead_Detectors> <VALIDITY_DATE></VALIDITY_DATE> <Bad_Pixels> <Bad_Pixel> <PIXEL_INDEX></PIXEL_INDEX>


DIMAP ISO 19115

<BAD_PIXEL_STATUS></BAD_PIXEL_STATUS>/MD_Metadata/dataQualityInfoDQ_DataQuality/report/QE_Usability/result/DQ_ConformanceResult/explanation

<PIXEL_VALUE></PIXEL_VALUE> </Bad_Pixel> </Bad_Pixels> </Dead_Detectors>

Annex A.6: Crosswalk between the DCMI format and the ISO 19115. Dublin Core

DUBLIC CORE ISO 19115DC.TITLE MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/titleDC.CREATOR MD_Metadata/identificationInfo/MD_Identification/credit

MD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/individualNameMD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/organisationName

DC.SUBJECT MD_Metadata/identificationInfo/MD_DataIdentification/topicCategory/MD_TopicCategoryCodeMD_Metadata/identificationInfo/MD_Identification/descriptive/MD_Keywords/keyword

DC.DESCRIPTION MD_Metadata/identificationInfo/MD_Identification/abstractDC.PUBLISHER MD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/individualName

MD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/organisationNameDC.CONTRIBUTOR MD_Metadata/identificationInfo/MD_Identification/credit

MD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/individualNameMD_Metadata/identificationInfo/MD_Identification/pointOfContact/CI_ResponsibleParty/organisationName

DC.DATE MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/date/CI_Date/date/DateDC.TYPE MD_Metadata/hierarchyLevel/MD_ScopeCodeDC.FORMAT MD_Metadata/distributionInfo/MD_Distribution/distributionFormat/MD_Format/name

MD_Metadata/distributionInfo/MD_Distribution/distributionFormat/MD_Format/versionDC.IDENTIFIER MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/identifier/MD_Identifier/code

MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/isbnMD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/issn

DC.SOURCE MD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/statementMD_Metadata/dataQualityInfo/DQ_DataQuality/lineage/Ll_Lineage/source/Ll_Source/description

DC.LANGUAGE MD_Metadata/identificationInfo/MD_DataIdentification/language

DC.RELATIONMD_Metadata/identificationInfo/MD_DataIdentification/aggregateInfo/MD_AggregateInformation/associationType/DS_AssociationTypeCodeMD_Metadata/identificationInfo/MD_ServiceIdentification/aggregationInfo/MD_AggregateInformation/associationType/DS_AssociationTypeCode

DC.COVERAGE MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/descriptionMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/westBoundLongitude/AngleMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/eastBoundLongitude/AngleMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/southBoundLatitude/AngleMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicBoundingBox/northBoundLatitude/Angle

Annex A.6: Crosswalk between the DCMI format and the ISO 19115. Dublin Core

DUBLIC CORE ISO 19115MD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_GeographicDescription/geographicIdentifier/MD_Identifier/codeMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_VerticalExtent/minimumValueMD_Metadata/identificationInfo/MD_DataIdentification/extent/EX_Extent/geographicElement/EX_VerticalExtent/maximumValue

DC.RIGHTSMD_Metadata/identificationInfo/MD_Identification/metadataConstraints/MD_LegalConstraints/accessConstraints/MD_RestrictionCodeMD_Metadata/identificationInfo/MD_Identification/metadataConstraints/MD_LegalConstraints/useConstraints/MD_RestrictionCodeMD_Metadata/identificationInfo/MD_Identification/metadataConstraints/MD_LegalConstraints/otherConstraints/MD_RestrictionCode


131

Annex B


132

B.1 NetCDF Uncertainty Conventions This annex is an excerpt from the NetCDF Uncertainty Conventions (NetCDF-U) for capturing uncertainty in netCDF-encoded data. NetCDF files compliant with these conventions may be indicated as “netCDF-U files” in the following.

B.1.1 Global provisions

B.1.1.1 Identification of Conventions NetCDF-U files shall declare the global attribute Conventions1 with the string value “UW-1.0” (see the example in the next section).

B.1.1.2 Primary and ancillary variables A netCDF file typically contains several variables. Some of these may depend on others, i.e. contain ancillary information referred to or qualifying concepts encoded by other variables (e.g., netCDF-CF introduces the concepts of coordinate variable, boundary variable, flag variable.)

Similarly to netCDF-CF, netCDF-U variables may declare an ancillary_variables attribute for expressing dependency relationships among variables.

Dually, netCDF-U files may declare a primary_variables global attribute, whose value is a white-separated list of variable identifiers.

The intended use of the primary_variables attribute is to support applications in directly accessing their presumable data of interest, particularly since netCDF-U files are likely to contain a large number of ancillary variables, as in the example below.

netcdf biotemperature { // global attributes: :Conventions = "CF-1.5 UW-1.0"; :primary_variables = "biotemperature"; dimensions: lon = 240 ; lat = 163 ; variables: double lon(lon) ; lon:long_name = "longitude"; lon:units = "degrees_east"; lon:standard_name = "longitude"; double lat(lat); lat:long_name = "latitude"; lat:units = "degrees_north"; lat:standard_name = "latitude"; double biotemperature_mean(lat, lon); biotemperature_mean:missing_value = -999.; biotemperature_mean:ref = "http://www.uncertml.org/distributions/normal#mean";

1 Lower-case “conventions” attribute name should be acceptable. However, netCDF-CF specify the uppper-case form.


133

double biotemperature_variance(lat, lon); biotemperature_variance:missing_value = -999.; biotemperature_variance:ref = "http://www.uncertml.org/distributions/normal#variance"; double biotemperature(lat, lon); biotemperature:units = "degC"; biotemperature:ancillary_variables = "biotemperature_mean biotemperature_variance"; biotemperature:ref = "http://www.uncertml.org/distributions/normal"; }

B.1.2 Uncertain concepts The main mechanism for capturing uncertain concepts in netCDF-U files consists of encoding them (and their possible values) in netCDF data variables annotated with uncertainty-related semantics.

To this end, a netCDF variable referring to uncertain concepts shall declare a ref attribute, whose value is a list of space-separated URIs of UncertML 2.0 dictionary entries (see the conceptual model in Figure 1).

Figure 1 – UncertML 2.0 conceptual model

For the sake of generality, we allow for multiple URIs: this could support the expression of compound UncertML concepts (although this use-case is probably not so relevant, within the current version of the UncertML dictionary).


134

Besides, anticipating a general support to semantic annotations in netCDF, an uncertain variable may also declare a rel attribute, whose value is a list of space-separated identifiers of the relationships between the variable and the corresponding URI in the ref attribute. In particular, the identifier for the above relationship shall be the string value “uncertainty”. If the rel attribute is missing, all the URIs are considered uncertainty-related annotations.

An uncertainty-related URI shall be resolvable to appropriate human-readable documentation of the respective dictionary concept. The syntax and semantics of the URI should be compliant to [IETF 3986].

B.1.2.1 Concept parameters The typical concept in the UncertML 2.0 dictionary is parameterized, with parameters of disparate types, from single scalar values to complex structures.

A complex parameter shall be encoded in a separate variable, to be declared in the ancillary_variables attribute of the referring concept variable, and annotated with the concept URI and the parameter name as a fragment part2, as in the following example:

variables: float prob_greater_than_limit(Lat=163, Lon=240); prob_greater_than_limit:ref = "http://www.uncertml.org/statistics/probability"; prob_greater_than_limit:ancillary_variables = "limits"; float limits(Lat=163, Lon=240); limits:ref = "http://www.uncertml.org/statistics/probability#gt"; For space optimization, a scalar parameter may be encoded as a variable attribute with the corresponding name, as in the following example:

variables: float second_order_moment(Lat=163, Lon=240); second_order_moment:ref = "http://www.uncertml.org/statistics/moment"; second_order_moment:order = "2";

B.1.2.2 Concepts without values Since the current implementation of the netCDF library seems to allocate space for variables as soon as they are defined (even when no data have been written), concepts whose values are irrelevant or undefined (e.g. distributions characterized by parameters only) may be encoded as scalar variables, for the sake of space optimization.

In this case, the information about the intended shape of the variable shall be preserved in the attribute shape, as in the example below:

2 Note that the semantics of the fragment part should be compliant to [IETF 3986]. In particular, if the referenced resource is an HTML document, the semantics of the fragment should be that of HTML anchors.


135

double biotemperature; biotemperature:ref = "http://www.uncertml.org/distributions/normal"; biotemperature:shape = “lat lon”; biotemperature:ancillary_variables = "biotemperature_mean biotemperature_variance";

B.1.3 Encoding of Samples A sample is defined as a set of realizations. Hence, it shall be encoded as a concept without values (§B.1.2.2) annotated with the related concept URI, linked to data variables corresponding to its related realizations by means of the ancillary_variables attribute, as in the example below.

netcdf file:/Users/bigagli/Downloads/biotemperature_randomSamples.nc { dimensions: lon = 240; lat = 163; variables: double biotemperature(); biotemperature:missing_value = -999.0; // double biotemperature:shape = “lat lon”; biotemperature:units = "degC"; biotemperature:ref = "http://www.uncertml.org/samples/random"; biotemperature:ancillary_variables = "realisation1 realisation2"; double lon(lon=240); lon:units = "degrees_east"; double lat(lat=163); lat:units = "degrees_north"; double realisation1(lat=163, lon=240); realisation1:missing_value = -999.0; // double realisation1:units = "degC"; realisation1:ref = "http://www.uncertml.org/samples/realisation"; realisation1:ID = "#12345"; double realisation2(lat=163, lon=240); realisation2:missing_value = -999.0; // double realisation2:units = "degC"; realisation2:ref = "http://www.uncertml.org/samples/realisation"; realisation2:ID = "#12346"; :Conventions = "CF-1.5 UW-1.0"; :primary_variables = "biotemperature"; }

For reducing the number of variables, especially when the single realizations have the same attributes, the sample variable may group all the realizations, indexing them along an extra additional dimension. In this case, the dimension variable corresponding to the additional dimension shall be annotated as a realization, as in the example below:

netcdf file:/Users/bigagli/Downloads/biotemperature_randomSamples.nc { dimensions: lon = 240; lat = 163;


136

realisation = 10; variables: double biotemperature(realization=10, lat=163, lon=240); biotemperature:missing_value = -999.0; // double biotemperature:shape = “lat lon”; biotemperature:units = "degC"; biotemperature:ref = "http://www.uncertml.org/samples/random"; double lon(lon=240); lon:units = "degrees_east"; double lat(lat=163); lat:units = "degrees_north"; double realisation(realisation=10); realisation:ref = "http://www.uncertml.org/samples/realisation"; :Conventions = "CF-1.5 UW-1.0"; :primary_variables = "biotemperature"; }

B.1.4 Encoding of Summary Statistics A summary statistics shall be encoded as a data variable annotated with the related concept URI. Summary statistics referring to the same stochastic variable shall be declared in the ancillary_variables attribute of a data variable annotated with the concept URI of a statistics collection, which may be declared in the primary_variables global attribute, as in the example below:

netcdf biotemperature { // global attributes: :Conventions = "CF-1.5 UW-1.0"; :primary_variables = "biotemperature"; dimensions: lon = 240 ; lat = 163 ; variables: double lon(lon) ; lon:long_name = "longitude"; lon:units = "degrees_east"; lon:standard_name = "longitude"; double lat(lat); lat:long_name = "latitude"; lat:units = "degrees_north"; lat:standard_name = "latitude"; double biotemperature_mean(lat, lon); biotemperature_mean:missing_value = -999.; biotemperature_mean:ref = "http://www.uncertml.org/statistics/mean"; double biotemperature_variance(lat, lon); biotemperature_variance:missing_value = -999.; biotemperature_variance:ref = "http://www.uncertml.org/statistics/variance"; double biotemperature(lat, lon); biotemperature:units = "degC"; biotemperature:ancillary_variables = "biotemperature_mean biotemperature_variance"; biotemperature:ref = "http://www.uncertml.org/statistics/statistics-collection"; }


137

B.1.5 Encoding of Distributions A distribution may be encoded as a concept without values (§B.1.2.2) annotated with the related concept URI, linked to data variables corresponding to its parameters, which shall be declared in its ancillary_variables attribute. The distribution data variable may be declared in the primary_variables global attribute, as in the example below:

netcdf biotemperature { // global attributes: :Conventions = "CF-1.5 UW-1.0"; :primary_variables = "biotemperature"; dimensions: lon = 240 ; lat = 163 ; variables: double lon(lon) ; lon:long_name = "longitude"; lon:units = "degrees_east"; lon:standard_name = "longitude"; double lat(lat); lat:long_name = "latitude"; lat:units = "degrees_north"; lat:standard_name = "latitude"; double biotemperature_mean(lat, lon); biotemperature_mean:missing_value = -999.; biotemperature_mean:ref = "http://www.uncertml.org/distributions/normal#mean"; double biotemperature_variance(lat, lon); biotemperature_variance:missing_value = -999.; biotemperature_variance:ref = "http://www.uncertml.org/distributions/normal#variance"; double biotemperature(); biotemperature:units = "degC"; biotemperature:ancillary_variables = "biotemperature_mean biotemperature_variance"; biotemperature:shape = “lat lon”; biotemperature:ref = "http://www.uncertml.org/distributions/normal"; }


138

Annex C


139

C.1 Examples of publications related to GEOSS datasets

C.1.1 DESCRIPTIVE PII: S0034-4257(02)00095-0

“MODIS snow-cover products” Dataset: National Snow and Ice Data Center (http://www.nsidc.org/NASA/MODIS/) moved to http://nsidc.org/daac/modis/index.html http://www.snowmelt.gsfc.nasa.gov/MODIS_Snow/modis.html (http://nsidc.org/data/g02158.html) Distributor: DOC/NOAA/NESDIS/NCDC > National Climatic Data Center, NESDIS, NOAA, U.S. Department of Commerce MD_identifier: [GCMD]MOD10_L2V5, [GCMD]LANDSAT_ETM_PLUS. QA: Quality assurance information ISSN: 1578-5157 “Posibilidades esteroscópicas de los datos espaciales” Dataset: http://spot5.cnes.fr/gb/satellite/satellite.htm http://www.spaceimaging.com/products/ikonos/ 13 http://www.orbimage.com/corp/orbimage_system/ov3/ http://kuroshio.eorc.jaxa.jp/ADEOS/index.html, http://www.imagesatintl.com/ http://www.fas.org/spp/guide/taiwan/earth/, http:/www.nz.dlr.de/moms2p/techdat/ http://tes.jpl.nasa.gov/mission/index.cfm http://www.bharatrakshak.com/SPACE/space-satellite4.html, http://www.cbers.inpe.br/en/programas/cbers1-2.htm http://www.digitalglobe.com/about/quickbird.html http://alos.jaxa.jp/index-e.html http://asterweb.jpl.nasa.gov/ http://www.bilten.metu.edu.tr/bilsat/en/root/ http://www.itc.nl/research/products/sensordb/getsat.aspx?name=Kompsat-1 http://www.isro.org/pslvc5/index.html MD_identifier: da76c00c-7451-494b-bb55-e64bdd00ccf9, 736343D8-A180-B918-B9E72D82461692E9, 79f171e5-b6e8-4320-b2bf-d7bfd007f7cd GMES_Sentinel-2_MRD_issue_2.1_mdru_08032010 “GMES Sentinel-2 Mission Requirements Document” Dataset: dataset catalogue not published MD_identifier: [GCMD]ESA_SENTINEL_PLACEHOLDER

C.1.2 METHODOLOGY TO GET THE RESOURCE (ALGORITHMS, MODELS,...) doi:10.1016/j.cageo.2010.10.016 “Comparing three methods for modelling the uncertainty in knowledge discovery from area-class soil maps”


140

Dataset: Data Mining Tools See5 and C5.0. http://www.rulequest.com/see5-info.html. QA: using three indices: MAE, RMSE, and agreement coefficient (AC) doi: 10.1080/01431160903130960 “Geostatistical approaches to conflation of continental snow data” Dataset: Snow depth (SD) data derived from the Advanced Microwave Scanning Radiometer for EOS (AMSR-E): http://coastwatch.pfel.noaa.gov/ http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle&keywords=AE_MoSno http://nsidc.org/data/ae_mosno.html MD_Identifier: c6662bcb-662e-4609-b6ba-f7d24820d3cf QA: Accuracy estimation: RMS

doi: 10.2747/1548-1603.48.3.416 “A New Method to Correct Pushbroom Hyperspectral Data Using Linear Features and Ground Control Points” Dataset: Orthoimage Utah AGRC; 2006 NAIP, AISA+ hyperspectral (not published) MD_identifier: [GCMD]AGRC_LandCover

doi: 10.1007/s00190-008-0254-5 “Forecasting sea level anomalies from TOPEX/Poseidon and Jason-1 satellite altimetry” Dataset: Center for Space Research, University of Texas at Austin, USA as gridded fields with the grid size of 1◦ × 1◦. http://www.aviso.oceanobs.com/en/data/products/index.html http://smsc.cnes.fr/JASON/ MD_identifier: GeoDataPortal_ 1933, b1de2511-b5b9-4746-a190-0666990f72b2

doi: 10.1080/01431160903130911 “A realistic structure model for large-scale surface leaving radiance simulation of forest canopy and accuracy assessment” Dataset (in the article): http://rami-benchmark.jrc.it http://6s.ltdri.org/ http://water.westgis.ac.cn/english/Introduction.asp http://www-misr.jpl.nasa.gov/mission/data/localmode.html http: //eosweb.larc.nasa.gov/PRODOCS/misr/tools/envi_tool.html MD_identifier: [GCMD]MI1B2E2 QI: RMS and Correlation Coefficient Hence, the new RGM has the capability to participate in the ongoing RAMI-IV exercise and will contribute to evaluating the accuracy of the simulating BRF of actual forests (http://rami-benchmark.jrc.ec.europa.eu/HTML/RAMI-IV/RAMI-IV.php)


141

C.1.3 EVALUATION OF PERFORMANCE

doi: 10.1016/j.jag.2010.07.002 “Spatio-temporal evaluation matrices for geospatial data” Dataset: http://www.teleatlas.com www.tomtom.com/page/mapshare http://www.mapreporter.navteq.com http://www.maps.nokia.com http://www.bing.com/maps http://www.wikimapia.org http://www.openstreetmap.org MD_identifier: doi: 10.1109/TGRS.2003.814625 “Classification and Feature Extraction for Remote Sensing Images From Urban Areas Based on Morphological Transformations” Dataset: IRS (Indian Remote Sensing Satellites) http://www.isro.org/scripts/currentprogrammein.aspx#IRS MD_identifier: 736343D8-A180-B918-B9E72D82461692E9 doi: 10.1016/j.rse.2009.05.005 “The North American ASTER Land Surface Emissivity Database (NAALSED) Version 2.0” Dataset:http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle MD_identifier: [GCMD]NAALSED3

doi:10.1016/j.jag.2010.09.005 “Impact of DEM source and resolution on topographic seismic amplification” Dataset: LiDAR, ASTER and SRTM DEMs, but no web sited http://www.gdem.aster.ersdac.or.jp/ MD_identifier: urn:geoss:csr:component:urn:uuid:44ee1774-5f45-40a6-96b7-f8ae30cbabd3, 79f171e5-b6e8-4320-b2bf-d7bfd007f7cd, dd1576f3-ba1b-49d2-bba3-259cad6cca8a Qality: R2 dx.doi.org/10.1021/es201308x “Evaluation of Process- and Input_Output-based Life Cycle Inventory Data with Regard to Truncation and Aggregation Issues” Dataset: https://www.lcacommons.gov/nrel/search MD_identifier:

doi:10.1016/j.jag.2010.06.001 “Detection and estimation of mixed paddy rice cropping patterns with MODIS data” Dataset: http://sedac.ciesin.columbia.edu/


142

http://www.GEO Portal.org/web/guest/geo_resources_details?p_p_id=vrdPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_vrdPortlet_WAR_GEO Portal_uuid=98281a4c-f6eb-4ca1-9953-7964ecd23f56&sourceType=USGSGN https://lpdaac.usgs.gov/lpdaac/products/modis product table/land cover/yearly l3 global 500m/v5/combined. MD_identifier: (QA) information http://lpdaac.usgs.gov/modis/mod09a1v5.asp DEM: http://www.landcover.org/data/srtm/ MD_identifier: [GCMD]MYD09A15, dd1576f3-ba1b-49d2-bba3-259cad6cca8a doi: 10.1080/01431160903130903 “Scale effect and scale correction of land-surface albedo in rugged terrain” Dataset: radiation (albedo) MODIS and AVHRR, and Landsat TM5 MD_identifier: 73638B17-A862-E1CB-8D58987073AA24DB, [GCMD]MCD43A15

doi: 10.2747/1548-1603.48.3.324 “Mapping Plant Functional Types at Multiple Spatial Resolutions Using Imaging Spectrometer Data” Dataset: Digital orthophotography http://earthexplorer.usgs.gov/ MD_identifier: 73638E64-97FD-293B-80038608955ACE3E Own AVIRIS image Accuracy: Kappa coefficient

doi: 10.1007/s11119-009-9120-6 “Evaluating high resolution SPOT 5 satellite imagery to estimate crop yield” Dataset: 1 single SPOT image from the 19 May 2006 MD_identifier: da76c00c-7451-494b-bb55-e64bdd00ccf9

QA: R2

C.1.4 VALIDATION/QUALITY ASSESSMENT

DataFlow FromSpaceToEarth “Digital Elevation Models of Sr: Quality Measures and Metadata” Dataset: http://www.geonet.sk/main_sk.htm, DEM3: http://topu.army.sk/projekty/DEM.htm MD_identifier: QE: absolute vertical error, absolute horizontal error and absolute spatial error. http://www.blackwell-science.com/geb “Agricultural land-use in China: a comparison of area estimates from ground-based census and satellite-borne remote sensing” Dataset: http://www.pecad.fas.usda.gov/cropexplorer/ CIESIN polygon coverage HTTP://sedac.ciesin.org/ch- ..0ina/admin/bnd90/bnd90.html


143

http://www.GEO Portal.org/web/guest/geo_map_viewer?p_p_id=gmvPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_gmvPortlet_WAR_GEO Portal_mapViewerContext=wms=http%3A%2F%2Fpublic.GEO Portal-geoportail.gc.ca%2Fwms%2Fcascader MD_identifier: 73638A8C-CD6C-8C4D-95EBFFE5138C3CBF PII: S0034-4257(02)00095-0 “MODIS snow-cover products” Dataset: Landsat ETM+: http://www.edcsns17.cr.usgs.gov/EarthExplorer/ http://stratus.ssec.wisc.edu/db/ http://www.nohrsc.noaa.gov/ http://www.snowmelt.gsfc.nasa.gov/MODIS_Snow/modis.html http://www.nsidc.org/NASA/MODIS/ http://www.nsidc.org/imswelcome MD_identifier: [GCMD]MOD10A23, 340f8c58-df7a-42f8-b0ec-0084d8b2eddf, [GCMD]NOHRSC_SNOW QA: on algorithm results for each pixe doi:10.1016/S0034-4257(03)00097-X “Validation of daily MODIS snow cover maps of the Upper Rio Grande River Basin for the 2000–2001 snow year” Dataset: http://www.ncdc.noaa.gov/oa/ncdc.html http://www.nohrsc.noaa.gov/nsa/http://www.wcc.nrcs.usda.gov/snow/ http://www.wcc.nrcs.usda.gov/factpub/sntlfct1.html MD_identifier: [GCMD]MOD10A2 , [GCMD]MOD10A1, [GCMD]MOD12Q14, 73638E64-97FD-293B-80038608955ACE3E, [GCMD]MOD10_L2, [GCMD]MOD02HKM, MOD03, [GCMD]MOD09GHK4

doi:10.1016/j.cageo.2011.04.011 “Quality assessment of Landsat surface reflectance products using MODIS data” Dataset: http://earthdata.nasa.gov/data/nrt-data/data-products/modis http://rda.ucar.edu/datasets/ds090.0/ QA: inear regresión snd RMSD MD_identifier: [GCMD]MOD09GA5

doi: 10.1080/01431160903439924 (very well documented) “Validation of MODIS snow cover products using Landsat and ground measurements during the 2001–2005 snow seasons over northern Xinjiang, China” Dataset: http://nsidc.org/data/mod10a1.html MODIS/Terra Snow Cover Daily L3 Global 500 m SIN GRID V004 , http://nsidc.org/data/mod10a1.html http://nsidc.org/daac/modis MODIS/Terra Snow Cover8-day L3 Global 500 m SIN GRID V004 http://nsidc.org/data/mod10a2.html


144

MOD12Q1 (MODIS/Terra Land Cover Type Yearly L3 Global 1 km SIN Grid product) https://lpdaac.usgs.gov/ MD_identifier: MOD12Q14, [GCMD]MYD10A2, MOD10A1, [GCMD]MOD10A2, [GCMD]MOD10_L2 http://w3.avignon.inra.fr/valeri/ “A Web Service-Based Tool To Disseminate Satellitederived Water Quality Maps Of Lake Garda” Dataset: https://lpdaac.usgs.gov/ https://earth.esa.int/web/guest/content?p_r_p_564233524_assetIdentifier=eoli-stand-alone-5035 MD_identifier: 9dfb09e0-2aee-4c6f-9dbd-0136e3e51a01, 57ee4936-86ac-40af-8dd2-cdbaf817bb3e, [GCMD]MOD11A141

C.1.5 APPLICATION (MD_USAGE)

doi: 10.1109/TGRS.2010.2102041 “Assessment of ALOS PALSAR 50 m Orthorectified FBD Data for Regional Land Cover Classification by Support Vector Machines” Dataset: http://www.eorc.jaxa.jp/ALOS/en/ipy/ipy_index.htm MD_identifier: 006e3ffc-31f1-403f-9776-a75f5302b565

doi:10.1016/j.rse.2005.07.008 “Vegetation water content estimation for corn and soybeans using spectral indices derived from MODIS near- and short-wave infrared bands” Dataset: http://edcdaac.usgs.gov/tools/modis/

http://edcimswww.cr.usgs.gov/pub/imswelcome/ QA: R2 MD_identifier: [GCMD]NSIDC-0278, [GCMD]NSIDC-0203 http://dx.doi.org/10.1080/014311699212452 “MERIS potential for land applications” Dataset: http://portal.genesi-dec.eu/gwp/?q=MERIS_L3_MGVI&bbox=-180,-90,180,90&start=2002-03-31&end=2011-03-17 MD_identifier: da76c00c-7451-494b-bb55-e64bdd00ccf9, 736391D3-A996-9760-FC03A6CA1F6EB739, 71ce420d-e4cf-4175-8b06-c06520649989 http://ppg.sagepub.com/content/33/4/568 “Applications of remote sensing in geomorphology” Dataset: http://landsat7.usgs.gov http://www.gdem.aster.ersdac.or.jp http://wwwpds.wustl.edu/missions/mgs/mola.html http://eoweb.dlr.de http://www.dmcii.com http://www.rapideye.de


145

http://eros.usgs.gov/products/satellite/declass1.php http://iceds.ge.ucl.ac.uk http://www.kcl.ac.uk/schools/sspp/geography/research/emm/geodata http://www.landcover.org http://www.opentopography.org http://srtm.csi.cgiar.org and the USGS HydroSHEDS http://hydrosheds.cr.usgs.gov MD_identifier: 31172be3-01ae-4d4d-b500-8e734a1d5432, http://dx.doi.org/10.1080/01431160903130978 “Scale transformation of Leaf Area Index product retrieved from multiresolution remotely sensed data: analysis and case studies” Dataset: SPOT, MODIS LAI MD_identifier: [GCMD]MOD02QKM, [GCMD]MOD02HKM

“COSMO-SkyMed mission: risk management applications over China, Myanmar and Haiti conducted during 2008” Dataset: http://www.cosmo-skymed.it/en/index.htm MD_identifier: 7363517B-DDAF-4618-9B8983641E715C00, [GCMD]COSMO-SkyMed

C.1.6 DERIVATED PRODUCTS

doi:10.1016/j.jag.2010.06.001 “Detection and estimation of mixed paddy rice cropping patterns with MODIS data” Dataset: http://www.GEO Portal.org/web/guest/geo_resources_details?p_p_id=vrdPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_vrdPortlet_WAR_GEO Portal_uuid=[CANADA-CGDI]Canada_GeoGratis_SPOTVEGETATION&sourceType=USGSGN http://geogratis.cgdi.gc.ca/download/EO_Data/Spot_Veget/ http://nsidc.org http://www.GEO Portal.org/web/guest/geo_resources_details?p_p_id=vrdPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_vrdPortlet_WAR_GEO Portal_uuid=[GCMD]MOD13A34&sourceType=USGSGN http://modis-land.gsfc.nasa.gov/ https://lpdaac.usgs.gov/ MD_identifier: 71ce420d-e4cf-4175-8b06-c06520649989,

doi:10.1016/j.jag.2010.06.004 “Directional effects on NDVI and LAI retrievals from MODIS: A case study in Brazil with soybean” Dataset: MODIS/Terra Surface Reflectance 8-Day L3 Global 500m


146

MD_identifier: [GCMD]MOD15A25, [GCMD]MOD09GA5, [GCMD]MYD09GQ5, MOD09A15, [GCMD]USDA_FAS_MODIS_1KM

http://www.ciesin.columbia.edu/indicators/ESI “2002 Environmental Sustainability Index An Initiative of the Global Leaders of Tomorrow Environment Task Force, World Economic Forum Annual Meeting 2002” Dataset: http://www.landcover.org MD_identifier: 03b1ba80-6a0d-4aca-a6f0-a3500de8b9c6, 5e06d316-9fd8-45a7-9566-a0ac37aaabad, 408e3979-8095-4073-aa8a-278ea91ec739, c7af864b-2546-4258-bf14-dde416d43530

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05714009 “Assessment of ALOS PALSAR 50 m Orthorectified FBD Data for Regional Land Cover Classification by Support Vector Machines” Dataset: http://www.eorc.jaxa.jp/ALOS/en/ MD_identifier: e17404f4-d9ab-4623-a3b5-161c1832ba17, urn:geoss:csr:component:urn:uuid:69d0c589-28b0-472c-844c-91f95271969b:1.3 doi:10.1016/j.rse.2003.10.021 “Vegetation water content mapping using Landsat data derived normalized difference water index for corn and soybeans” Dataset: http://aeronet.gsfc.nasa.gov/ http://nsidc.org/data/nsidc-0278.html MD_identifier: NSIDC-0238, 73638E64-97FD-293B-80038608955ACE3E doi:10.1016/j.jag.2010.06.004 “Directional effects on NDVI and LAI retrievals from MODIS: A case study in Brazil with soybean” Dataset: http://data.nasa.gov/warehouse-inventory-search-tool/ https://lpdaac.usgs.gov/products/modis_products_table/surface_reflectance/daily_l2g_global_1km_and_500m/mod09ga MD_identifier: 8d75bac9-3773-4c1e-97dc-3a4825a601f0, MOD09GA5, MOD15A25

http://dx.doi.org/10.1080/0143116031000115265 “VEGETATION/SPOT: an operational mission for the Earth monitoring; presentation of new standard products” Dataset: http://www.cesbio.ups-tlse.fr/ http://free.vgt.vito.be/ http://www.spot-vegetation.com MD_identifier: Flemish Institute for Technological Research (VITO) http://dx.doi.org/10.1080/17538940902951401 “A new global raster water mask at 250 m resolution” Dataset: http://modis-land.gsfc.nasa.gov/ http://landcover.org MD_identifier: dd1576f3-ba1b-49d2-bba3-259cad6cca8a, MOD44W5


147

C.1.7 COMPARATIVE (INTERCOMPARISON) doi: 10.1080/01431160500168686//ISSN 0143-1161 print / ISSN 1366-5901 online “An extended AVHRR 8-km NDVI dataset compatible with MODIS and SPOT vegetation NDVI data” Dataset: http://nsidc.org/data/g02156.html MD_identifier: 2d85088b-2520-4bcc-8bb6-5b71cc047462, [NOAA-

NMMR]gov.noaa.class.SBUVPMF, [NOAA-NMMR]gov.noaa.ngdc.G00542 “Agricultural land-use in China: a comparison of area estimates from ground-based census and satellite-born remote sensing” Dataset: http://english.cas.cn/Re/SD/ http://www.data.ac.cn/zy/english/database.asp MD_identifier: 73638A8C-CD6C-8C4D-95EBFFE5138C3CBF

doi:10.1016/j.rse.2009.04.004 “Evaluation of Earth Observation based long term vegetation trends — Intercomparing NDVI time series trend analysis consistency of Sahel from AVHRR GIMMS, Terra MODIS and SPOT VGT data” Dataset: http://free.vgt.vito.be/origin http://geogratis.cgdi.gc.ca/download/EO_Data/Spot_Veget/ http://nsidc.org/ http://www.GEO Portal.org/web/guest/geo_resources_details?p_p_id=vrdPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_vrdPortlet_WAR_GEO Portal_uuid=[GCMD]MOD13C15&sourceType=USGSGN http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle&keywords=MOD13C15 MD_identifier: ISLSCP_II_GIMMS_NDVI, MOD13C14, f088f9d5-b10b-4c4a-84c2-c01341c51a15

ISSN: 1578-5157 “Posibilidades Estereoscópicas De Los Datos Espaciales” Dataset: http://spot5.cnes.fr/gb/satellite/satellite.htm http://www.spaceimaging.com/products/ikonos/ http://www.orbimage.com/corp/orbimage_system/ov3/ http://kuroshio.eorc.jaxa.jp/ADEOS/index.html http://www.imagesatintl.com/ http://www.fas.org/spp/guide/taiwan/earth/ http://www.nz.dlr.de/moms2p/techdat/ http://tes.jpl.nasa.gov/mission/index.cfm http://www.bharat-rakshak.com/SPACE/space-satellite4.html http://www.cbers.inpe.br/en/programas/cbers1-2.htm


148

http://www.digitalglobe.com/about/quickbird.html http://alos.jaxa.jp/index-e.html http://asterweb.jpl.nasa.gov/ http://www.bilten.metu.edu.tr/bilsat/en/root/ http://www.itc.nl/research/products/sensordb/getsat.aspx?name=Kompsat-1 http://www.isro.org/pslvc5/index.html MD_identifier: AMSR-L1A, INPE_CBERS2B_HRC, INPE_IRS_AWIFS doi: 10.5721/ItJRS20124416 “CO emission datasets and maps from Remote Sensing: spatial and statistical comparison at different levels” Dataset: ATSR http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle&keywords=s2k_one_deg_biomass MODIS http://daac.ornl.gov/cgi-bin/dsviewer.pl?ds_id=754 PETRON http://www.GEO Portal.org/web/guest/geo_resources_details?p_p_id=vrdPortlet_WAR_GEO Portal&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_vrdPortlet_WAR_GEO Portal_uuid=[GCMD]GEIA_POET&sourceType=USGSGN MD_identifier: GeoDataPortal_ 1848, 4cf50a1c-17c0-4278-99f2-656f17527261, 73635420-B966-DCB6-27F1D79C0456648E, GEIA_POET

C.1.8 DATASETS COMBINATION

doi: 10.1029/2001GB001425,2002 “Combining remote sensing and ground census data to develop new maps of the distribution of rice in China” Dataset: http://gcmd.nasa.gov/KeywordSearch/Metadata.do?Portal=GCMD&KeywordPath=Parameters|HUMAN+DIMENSIONS&NumericId=12092&MetadataView=Data&MetadataType=0&lbnode=mdlb2 ftp://ftp.ciesin.columbia.edu/pub/data/China/CITAS/census_agr/ MD_identifier: GeoDataPortal_ 306, 73638A8C-CD6C-8C4D-95EBFFE5138C3CBF

doi:10.1016/j.jag.2010.06.007 “Generation and evaluation of gross primary productivity using Landsat data through blending with MODIS data” Dataset: MODIS: http://redhook.gsfc.nasa.gov Landsat 7: http://glovis.usgs.gov/ MD_identifier: MYD09A15, efb21571-ab24-47fc-843e-beab435dca9a, 56b6a645-91e3-4b2d-913e-d4296c5e06dc http://dx.doi.org/10.1080/01431160500168686


149

“An extended AVHRR 8km NDVI dataset compatible with MODIS and SPOT vegetation NDVI data” Dataset: http://glcf.umiacs.umd.edu/data/gimms/ MD_identifier: EO:EUM:DAT:MULT:EARS-AVHRR, a44ec6a6-b8c4-4b21-b3e4-2d950f0f688f

C.2 Some examples of XML documents Some examples of XML documents regarding the different Publication Categories. We have highlighted some parts we find interesting for the category which is being described, as well as some parts we fins relevant for the whole.

C.2.1 Book <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>Principles of Modeling Uncertainties in Spatial Data and Spatial Analyses</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2010</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">book</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:edition> <gco:CharacterString>CRC Press</gco:CharacterString> </gmd:edition> <gmd:editionDate> <gco:Date>2010</gco:Date> </gmd:editionDate> <gmd:citedResponsibleParty>


150

<gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>Wenzhong Shi</gco:CharacterString> </gmd:individualName> <gmd:organisationName> <gco:CharacterString>Hong Kong Polytechnic Univ</gco:CharacterString> </gmd:organisationName> <gmd:positionName> <gco:CharacterString>Dr.</gco:CharacterString> </gmd:positionName> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty>

<gmd:ISBN> <gco:CharacterString>978-1-4200-5927-4</gco:CharacterString> </gmd:ISBN>

 <gvq:target> <updated19115:MD_Identifier uuid="jrc.europa.eu:GLC2000"> <code> <gco:CharacterString></gco:CharacterString> </code> <codeSpace> <gco:CharacterString></gco:CharacterString> </codeSpace>  </updated19115:MD_Identifier> </gvq:target>

<gvq:pages> <gco:CharacterString>429</gco:CharacterString> </gvq:pages> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>

<gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent">


151

<gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>-180</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>180</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>-90</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>90</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition></gml:beginPosition> <gml:endPosition></gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope>

<gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="book">book</gvq:GVQ_PublicationCategoryCode> </gvq:category> </gvq:GVQ_Publication>


152

C.2.2 CD/DVD <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>Argentina 500k</gco:CharacterString> </gmd:title> <gmd:date>

<gmd:CI_Date> <gmd:date> <gco:Date>2010</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">CD/DVD</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date>

</gmd:date> <gmd:citedResponsibleParty>

<gmd:CI_ResponsibleParty> <gmd:organisationName> <gco:CharacterString>Instituto Geográfico Nacional</gco:CharacterString> </gmd:organisationName> <gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:administrativeArea> <gco:CharacterString>Avda. Cabildo</gco:CharacterString> </gmd:administrativeArea> <gmd:postalCode>


153

<gco:CharacterString>C1426-AAD</gco:CharacterString> </gmd:postalCode> <gmd:country> <gco:CharacterString>República Argentina</gco:CharacterString> </gmd:country> <gmd:electronicMailAddress> <gco:CharacterString>[email protected]</gco:CharacterString> </gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> <gmd:ISSN> <gco:CharacterString>978-987-25448-3-6</gco:CharacterString> </gmd:ISSN>

<gvq:target> <updated19115:MD_Identifier>

<code>13dac26f-c4c8-4aca-a8b1-0e06c3d56310</code> </updated19115:MD_Identifier> </gvq:target> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>  <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude>


154

<gco:Decimal>53</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>74</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>-54</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>-22</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>2000</gml:beginPosition> <gml:endPosition>2000</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="CD/DVD">CD/DVD</gvq:GVQ_PublicationCategoryCode> </gvq:category> </gvq:GVQ_Publication>

C.2.3 Manual <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts"


155

xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>ALGORITHM AND DATA USER MANUAL (ADUM) FOR THE SPECIAL SENSOR MICROWAVE IMAGER/SOUNDER (SSMIS)</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2002</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">manual</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:editionDate> <gco:Date>2010</gco:Date> </gmd:editionDate> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>Northrop Grumman Corporation</gco:CharacterString> </gmd:individualName> <gmd:organisationName> <gco:CharacterString>Northrop Grumman Corporation, Space Systems Division</gco:CharacterString> </gmd:organisationName> <gmd:positionName> <gco:CharacterString></gco:CharacterString> </gmd:positionName> <gmd:contactInfo> <gmd:CI_Contact> <gmd:address> <gmd:CI_Address> <gmd:deliveryPoint> <gco:CharacterString>P.O. Box 296, 1100 West Hollyvale Street</gco:CharacterString> </gmd:deliveryPoint> <gmd:administrativeArea> <gco:CharacterString>Azusa, California</gco:CharacterString> </gmd:administrativeArea> <gmd:postalCode>


156

<gco:CharacterString>91702-0296</gco:CharacterString> </gmd:postalCode> <gmd:country> <gco:CharacterString>USA</gco:CharacterString> </gmd:country> </gmd:CI_Address> </gmd:address> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> <gmd:otherCitationDetails> <gco:CharacterString>Report 12621/Contract NºF04710-00-C-0001</gco:CharacterString> </gmd:otherCitationDetails> <gvq:target>

<updated19115:MD_Identifier> <code>EO:EUM:SW:DMSP:038</code> </updated19115:MD_Identifier> </gvq:target> <gvq:pages> <gco:CharacterString>69</gco:CharacterString> </gvq:pages>

<gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="Technical Report">Technical Report</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>

 <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode>


157

<gmd:westBoundLongitude> <gco:Decimal>-180</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>180</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>-90</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>90</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition></gml:beginPosition> <gml:endPosition></gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="Manual">Manual</gvq:GVQ_PublicationCategoryCode> </gvq:category>

<gvq:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://lwf.ncdc.noaa.gov/oa/rsad/ssmi/adum-ssmis-description.pdf</gmd:URL> </gmd:linkage>

</gmd:CI_OnlineResource> </gvq:onlineResource>

</gvq:GVQ_Publication>


158

C.2.4 Poster <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>Opportunities of the automatic geometric correction of the historical series of Landsat imagery (1972-2011) for the accurate analysys of Catalan delta changes</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">publication</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date>

<gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>Gerard Moré</gco:CharacterString> </gmd:individualName> <gmd:organisationName> <gco:CharacterString>Centre de recerca Ecològica y Aplicacions Forestals</gco:CharacterString> </gmd:organisationName> <gmd:positionName> <gco:CharacterString>researcher</gco:CharacterString> </gmd:positionName> <gmd:contactInfo> <gmd:CI_Contact> <gmd:address>


159

<gmd:CI_Address> <gmd:administrativeArea> <gco:CharacterString>Catalunya</gco:CharacterString> </gmd:administrativeArea> <gmd:postalCode> <gco:CharacterString>08193</gco:CharacterString> </gmd:postalCode> <gmd:country> <gco:CharacterString>Spain</gco:CharacterString> </gmd:country> <gmd:electronicMailAddress> <gco:CharacterString>[email protected]</gco:CharacterString> </gmd:electronicMailAddress> </gmd:CI_Address> </gmd:address> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty>

<gvq:target> <updated19115:MD_Identifier>

<code>714d1e3fe7db0b94d88b9feb7cdd2e0fc01d7655</code> </updated19115:MD_Identifier> </gvq:target>

<gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>

 <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox">


160

<gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>3.33</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>0.16</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>42.86</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>40.52</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent">

<gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>1972</gml:beginPosition> <gml:endPosition>2011</gml:endPosition> </gml:TimePeriod> </gmd:extent>

</gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="poster">poster</gvq:GVQ_PublicationCategoryCode> </gvq:category> </gvq:GVQ_Publication>


161

C.2.5 Online Video <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>Arctic Ozone Loss 2010-2011</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">video</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:individualName> <gco:CharacterString>Rob Simmon</gco:CharacterString> </gmd:individualName> <gmd:organisationName> <gco:CharacterString>Ozone Hole Watch, NASA GSFC</gco:CharacterString> </gmd:organisationName> <gmd:contactInfo> <gmd:CI_Contact>

<gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage><gmd:URL>http://www.youtube.com/user/NASAEarthObservatory</gmd:URL> </gmd:linkage>


162

</gmd:CI_OnlineResource>

</gmd:onlineResource> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty> <gvq:target>

<updated19115:MD_Identifier> <code> GES_DISC_ML2O3_V002</code> </updated19115:MD_Identifier> </gvq:target> <gvq:purpose>

<gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="product"></gvq:GVQ_PublicationPurposeCode> </gvq:purpose> 

<gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>-180</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>180</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>66.5</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>90</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement>


163

<gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>201003</gml:beginPosition> <gml:endPosition>201103</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="Video">Video</gvq:GVQ_PublicationCategoryCode> </gvq:category>

<gvq:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>'http://www.youtube.com/watch?v=aNNRjbBK1Ns&NR=1&feature=endscreen'</gmd:URL> </gmd:linkage> </gmd:CI_OnlineResource> </gvq:onlineResource>


C.2.6 Journal Article <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title>


164

<gco:CharacterString>Detection and estimation of mixed paddy rice cropping patterns with MODIS data</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">publication</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gvq:target>

<updated19115:MD_Identifier> <code> 350d64b7-374d-4b92-bb3a-376a532aba1a</code> </updated19115:MD_Identifier> </gvq:target>

<gvq:doi> <gco:CharacterString>doi:10.1016/j.jag.2010.06.001</gco:CharacterString> </gvq:doi> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>

 <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>108.784</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude>


165

<gco:Decimal>114.25</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>24.64</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>30.14</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent">

<gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>2000</gml:beginPosition> <gml:endPosition>2007</gml:endPosition> </gml:TimePeriod> </gmd:extent>

</gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category>

<gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="journalArticle">journalArticle</gvq:GVQ_PublicationCategoryCode> </gvq:category>


C.2.7 Atlas Paper Map

<?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


166

xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>The spatial distribution of Plasmodium falciparum entomological inoculation rate in 2010 World </gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.map.ox.ac.uk/” codeListValue="http://www.example.com/">PaperMap</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gvq:target> <updated19115:MD_Identifier uuid="http://www.map.ox.ac.uk/"> <code> <gco:CharacterString>urn:geoss:csr:component:urn:uuid:b94d6151-36ce-47cd-96f6-a21630d321d2</gco:CharacterString> </code> <codeSpace> <gco:CharacterString>paper.mapPM:2010</gco:CharacterString> </codeSpace>  </updated19115:MD_Identifier> </gvq:target> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>  <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode>


167

<gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>-180</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>180</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>-90</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>90</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>2010</gml:beginPosition> <gml:endPosition>2010</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> <levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="PaperMap">PaperMap</gvq:GVQ_PublicationCategoryCode> </gvq:category> </gvq:GVQ_Publication>

C.2.8 Magazine or Newspaper <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2"


168

xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>La UAB lanza un banco de imágenes por satélite de Catalunya iniciado hace 40 años</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2012</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">magazineNewspaper</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty> <gmd:CI_ResponsibleParty> <gmd:contactInfo>

<gmd:CI_Contact> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.lavanguardia.com/</gmd:URL> </gmd:linkage> </gmd:CI_OnlineResource> </gmd:onlineResource> </gmd:CI_Contact>

</gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty></gmd:citedResponsibleParty> <gvq:target> <updated19115:MD_Identifier uuid="la.vanguardia.MZ:2012"> <code> <gco:CharacterString>urn:geoss:csr:component:urn:uuid:19f1fd61-b912-466b-afa8-b15e05e6baa2 </gco:CharacterString> </code> <codeSpace> <gco:CharacterString>la.vanguardia.eu</gco:CharacterString> </codeSpace> </updated19115:MD_Identifier>


169

</gvq:target> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="describe">describe</gvq:GVQ_PublicationPurposeCode> </gvq:purpose>  <gvq:scope> <gmd19157:DQ_Scope> <level> <gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>3.33</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>0.16</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>42.86</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>40.52</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>1972</gml:beginPosition> <gml:endPosition>2011</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent>


170

<levelDescription></levelDescription> </gmd19157:DQ_Scope> </gvq:scope> <gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="magazinenewspaper">magazinenewspape</gvq:GVQ_PublicationCategoryCode> </gvq:category>

<gvq:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.lavanguardia.com/vida/20120217/54256037490/uab-imagenes-satelite-catalunya.html</gmd:URL> </gmd:linkage> </gmd:CI_OnlineResource> </gvq:onlineResource>


C.2.9 WebSite <?xml version="1.0" encoding="utf-8"?> <gvq:GVQ_Publication xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmd19157="http://www.geoviqua.org/schemas/gmd19157" xmlns:updated19115="http://www.geoviqua.org/schemas/19115_updates" xmlns:gvq="http://www.geoviqua.org/schemas/ProducerModel/2.2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geoviqua.org/schemas/ProducerModel/2.2 ../schemas/GeoViQua/GeoViQua_DataQuality.xsd"> <gmd:title> <gco:CharacterString>MAP Malaria AtlasProject</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.example.com/" codeListValue="http://www.example.com/">video</gmd:CI_DateTypeCode> </gmd:dateType>


171

</gmd:CI_Date> </gmd:date> <gmd:citedResponsibleParty>

<gmd:CI_ResponsibleParty> <gmd:organisationName> <gco:CharacterString>MAP Malaria AtlasProject</gco:CharacterString> </gmd:organisationName> <gmd:contactInfo> <gmd:CI_Contact> <gmd:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.map.ox.ac.uk/</gmd:URL> </gmd:linkage> </gmd:CI_OnlineResource> </gmd:onlineResource> <gmd:contactInstructions> <gco:CharacterString>http://www.map.ox.ac.uk/contact-us/</gco:CharacterString> </gmd:contactInstructions> </gmd:CI_Contact> </gmd:contactInfo> <gmd:role></gmd:role> </gmd:CI_ResponsibleParty> </gmd:citedResponsibleParty>

<gvq:target> <updated19115:MD_Identifier uuid="maap.malaria"> <code> <gco:CharacterString>MM:2010</gco:CharacterString> </code> <codeSpace> <gco:CharacterString>m.global.gl</gco:CharacterString> </codeSpace>  </updated19115:MD_Identifier> </gvq:target> <gvq:purpose> <gvq:GVQ_PublicationPurposeCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationPurposeCode" codeListValue="product"></gvq:GVQ_PublicationPurposeCode> </gvq:purpose>  <gvq:scope> <gmd19157:DQ_Scope> <level>


172

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode" codeListValue="dataset"/> </level> <extent> <gmd:EX_Extent id="boundingExtent"> <gmd:geographicElement> <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox"> <gmd:extentTypeCode> <gco:Boolean>true</gco:Boolean> </gmd:extentTypeCode> <gmd:westBoundLongitude> <gco:Decimal>-180</gco:Decimal> </gmd:westBoundLongitude> <gmd:eastBoundLongitude> <gco:Decimal>180</gco:Decimal> </gmd:eastBoundLongitude> <gmd:southBoundLatitude> <gco:Decimal>-90</gco:Decimal> </gmd:southBoundLatitude> <gmd:northBoundLatitude> <gco:Decimal>90</gco:Decimal> </gmd:northBoundLatitude> </gmd:EX_GeographicBoundingBox> </gmd:geographicElement> <gmd:temporalElement> <gmd:EX_TemporalExtent id="boundingTemporalExtent"> <gmd:extent> <gml:TimePeriod gml:id="someTimeID"> <gml:beginPosition>2007</gml:beginPosition> <gml:endPosition>2012</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </extent> </gmd19157:DQ_Scope> </gvq:scope>

<gvq:category> <gvq:GVQ_PublicationCategoryCode codeList="http://www.geoviqua.org/schemas/ProducerModel_v2/resources/codeList.xml#GVQ_PublicationCategoryCode" codeListValue="WebSite">WebSite</gvq:GVQ_PublicationCategoryCode> </gvq:category> <gvq:onlineResource> <gmd:CI_OnlineResource> <gmd:linkage>


173

<gmd:URL>http://www.map.ox.ac.uk/browse-resources/</gmd:URL> </gmd:linkage> </gmd:CI_OnlineResource> </gvq:onlineResource>

7th Framework Programme ENV.2010.4.1.2-2 Integrating new ...geoviqua.org/Docs/SubmittedDeliverables/D3_1_GeoViQua.pdf · GeoViQua as well in WP6, Task 6.1 (Encodings for data quality).

Documents