User:Markf129/Earth sciences data format interoperability: Difference between revisions

Revision as of 18:02, 9 September 2010

Latest revision as of 18:23, 14 August 2022

(4 intermediate revisions by 4 users not shown)

Line 1:

{{Userspace draft|date=July 2010}}

When studying the Earth sciences throughby observation or analytical [[model (abstract)|models]], it is often a challenge for both the user and collector on how to best organize and store the vast amount of information available. Different organizations may have specific technical goals, timeline constraints, or model constraints that outoften of necessity derivedrive new unique file conventions, distributions techniques, and architectures. While developing new solutions sometimes solves short term goals, it often causes more complex long term problems when standards are not adhered to<ref>{{cite articlenews

| title = Model Data Interoperability for the United States Integrated Ocean Observing System

| author = Richard P. Signell

Line 6:

| url = http://www.usnfra.org/committees/modeling/signell_final%20report_mar8.pdf

}}

</ref>. In some cases, science data has been migrating less rapidly to a standards-based approach<ref>{{cite articlenews

| title = Standards-based data interoperability in the climate sciences

| author = AndrewWoolf, Ray Cramer, Marta Gutierrez, Kerstin Kleese van Dam, Siva Kondapalli,

Line 13:

| url = http://journals.cambridge.org/action/displayFulltext?type=1&fid=296181&jid=MAP&volumeId=12&issueId=01&aid=296180

}}

</ref>. Because of these issues, interoperability of data for collaboration is critical in building a continued quantitative understanding of the sciences<ref>{{cite articlenews

| title = Achieving interoperability of spatial data

| author = Clemens Portele, Freddy Fierens, Eva Klien

Line 21:

</ref>.

Interoperability allowsof dataobservational usersor to view, process, and analyze observationalmodel data ormust sciencebe model output easilyeasy and transparentlytransparent, without having to reformat the

data, write special tools to read or extract the data, or rely on specific proprietary software. If common formats wereare adhered to, many benefits would occur. First, it would promote the exchange of models and relevant science data. Second, observational data could be scaled and compared more easily to models. And third, it would eliminate confusion and unnecessary format conversions. Perhaps the most important reason is the latter, as considerable time can be spent converting between the different data formats<ref>{{cite articlenews

| title = Background on BUFR and GRIB Formats

| author = Doug McLain

Line 31:

==Overview and definition==

A [[data model]] (e.g. [[NetCDF]]) describes structured data by providing an unambiguous and neutral view on how the data is organized<ref>{{cite articlenews

| title = DIFFERENCES AMONG THE DATA MODELS USED BY THE GEOGRAPHIC INFORMATION SYSTEMS AND ATMOSPHERIC SCIENCE COMMUNITIES

| author = Stefano Nativi, University of Florence, Prato, Italy and M. B. Blumenthal, J. Caron, B. Domenico, T. Habermann, D. Hertzmann, Y. Ho, R. Raskin, and J. Weber

Line 42:

A [[file format]] defines how data is encoded for storage using a defined structure such as chunk, directory based, or unstructured. Usually the file format is easily identified by the file name extension (e.g. .jpg, .bufr). Thus, the data model describes how the data is organized, and the file format how the data is stored. Furthermore, conventions are used to describe what data types, formats, and design principles are applied for a given data model and/or format (e.g. [[Climate and Forecast Metadata Conventions]]). By identifying these three elements, data can be accurately described.

For example, data models contain datasets such as dimensions, variables, types, and attributes. Some models have the ability to even logically put these sets into groups. These components can be used together to capture the meaning of data and relations among data fields in an array-oriented dataset. In contrast to variables, which are intended for bulk data, attributes are intended for ancillary data, or information about the data<ref>{{cite articlenews

| title =

| url = http://www.unidata.ucar.edu/software/netcdf/docs/netcdf/index.html

Line 212:

{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"

|-

!

! [[File:srcdest.jpg|120px]]

! NetCDFclassic<br>classic<br>CF

! NetCDFenhanced<br>netCDF-4<br>CF

Line 231:

|-

| <b>HDF5<br>HDF5<br>HDF5</b> || No || Yes, but limited<ref>

{{cite articlenews

| url = http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#fv15

}}</ref> || Yes, but limited<ref>

{{cite articlenews

| url = http://www.hdfgroup.org/h5h4-diff.html

}}</ref> || || || || || || ||

|- valign="top" style="background: #cccccc;"

| <b>HDFEOS2<br>HDF4<br>HDF4</b> || || || || || || || Convert<ref>{{cite articlenews

| url = http://newsroom.gsfc.nasa.gov/sdptoolkit/HEG/HEGHome.html

}}</ref> || || ||

Line 249:

|- valign="top" style="background: #cccccc;"

| <b>GRIB2<br>GRIB2<br>GRIB2</b> || || || || || || || || Yes, but limited<ref>

{{cite articlenews

| url = http://www.ecmwf.int/publications/manuals/grib_api/conversion.html

}}</ref> || ||

Line 260:

{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"

|-

!

! [[File:srcdest.jpg|120px]]

! NetCDFclassic<br>classic<br>CF

! NetCDFenhanced<br>netCDF-4<br>CF

Line 294:

==Data type representations==

For any given data stream there may be ambiguities regarding the appropriate structural data type to be used. As a general rule, the best way to resolve this ambiguity is to choose the most highly ordered data type that could describe the data.<ref>{{cite articlenews

| author = U.S. Department of Commerce

| year = 2006

Line 303:

The table below lists some of the structural data types, and their respective recommended data formats. The data formats are defined in three lines: the data model, file format, and convention.

{|type= class="wikitable sortable"

{{Table

|+ Structural data types and formats

|type=class="wikitable sortable"

|title=! Structural dataData typesClass!!Descriptions and subclasses!!Common formats

|-

|hdrs= Structural Data Class!!Descriptions and subclasses!!Common formats

|row1= Grids{{!!}} || rectilinear grids, curvilinear grids, finite element meshes outputs, “unstructured” grids (variable numbers of vertices)

||

{{!!}}

|-

|row2= Moving-sensor multidimensional fields{{!!}} || swaths, radials{{!!}} ||

|row3=Time series{{!!}}time-ordered sequence of records associated with a point in space or a more complex spatial feature{{!!}}

|-

|row4=Profiles{{!!}}height-or depth-ordered sequence of records at a fixed (or approximately fixed) point in time and position in lat/long{{!!}}

|row5=Trajectories{{!!}} Time series || time-ordered sequence of records alongassociated with a pathpoint throughin space{{!!}} or a more complex spatial feature ||

|-

|row6=Geospatial Framework Data{{!!}}lines, polygonal regions, map annotations{{!!}}

|row4= Profiles{{!!}} || height-or depth-ordered sequence of records at a fixed (or approximately fixed) point in time and position in lat/long{{!!}} ||

|row7=Point Data{{!!}}scattered points{{!!}}

|-

|row8=Metadata{{!!}}“data about data” – context information needed for the interpretation of data{{!!}}

| Trajectories || time-ordered sequence of records along a path through space ||

}}

|-

|row6= Geospatial Framework Data{{!!}} || lines, polygonal regions, map annotations{{!!}} ||

|-

|row7= Point Data{{!!}} || scattered points{{!!}} ||

|-

|row8= Metadata{{!!}} || “data about data” – context information needed for the interpretation of data{{!!}} ||

}|}

==Interoperability guidelines==

Data interoperability is critical to integrate different models, tools, and perspectives in order to collaborate effectively. Data must be taken from multiple sources in order to study the Earth sciences as a system rather than individual components. In many cases the chosen data types are the natural consequence of the manner in which the data is collected. However, without some sort of strict standard or policy, the ability to utilize observations and model data diminishes. The next best alternative is to incorporate best practices or established conventions (such as in climatology the [[Climate and Forecast Metadata Conventions]]). For example, the Hierarchical Data Format (HDF) is the standard data format for all NASA Earth Observing System (EOS) data products<ref>{{cite articlenews

| title = Hierarchical Data Format - Earth Observing System (HDF-EOS)

| url = http://nsidc.org/data/hdfeos/

Line 341 ⟶ 348:

<!--

[[:Category:Data types]]

[[:Category:Computer file formats]]

[[:Category:Science software]]

-->