Skip to content

Spec initial draft #65

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Spec initial draft #65

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
28ee68b
Initial draft of unified data model specification
christophenoel Apr 24, 2025
cd62def
Add initial normative sections for GeoZarr Standard: Preface, Abstrac…
christophenoel Apr 24, 2025
e8fdb2f
Update standard/template/sections/clause_4_terms_and_definitions.adoc
christophenoel Apr 29, 2025
32337f7
Update standard/template/sections/clause_9_zarr_encoding_core.adoc
christophenoel Apr 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions .github/workflows/generate.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
name: generate

on:
push:
branches: [ main ]
pull_request:
paths-ignore:
- .gitlab-ci.yml
- .github/workflows/create_swg_report.yml
workflow_dispatch:

jobs:
generate-html:
name: Generate site with Metanorma container
runs-on: ubuntu-latest
container:
image: metanorma/metanorma:latest

steps:
- uses: actions/checkout@v4
with:
token: ${{ github.token }}
submodules: true # ❓ Set to 'false' if submodules are not used

# Optional: cache Fontist fonts (used by Metanorma for PDF generation)
- uses: actions/cache@v3
with:
path: /root/.fontist
key: fontist-${{ runner.os }}
restore-keys: fontist-${{ runner.os }}

- name: Generate site
env:
METANORMA_DEBUG: "1"
run: |
metanorma site generate --agree-to-terms

# Optional: deploy to GitHub Pages if needed
- name: Deploy to GitHub Pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./_site
12 changes: 12 additions & 0 deletions metanorma.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
---
metanorma:
source:
plantuml:
enabled: true
format: svg
files:
- standard/template/geozarr-spec.adoc

collection:
organization: "OGC"
name: "OGC GeoZarr Specification"
22 changes: 14 additions & 8 deletions standard/template/document.adoc → standard/template/geozarr-spec.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,18 +10,20 @@
:received-date: 2029-03-30
:issued-date: 2029-03-30
:published-date: 2029-03-30
:fullname: Editor One
:fullname_2: Editor Two
:docsubtype: Interface
:fullname: Christophe Noël
:fullname_2: Brianna Pagán
:docsubtype: Format
:keywords: ogcdoc, OGC document, API, openapi, html
:submitting-organizations: Organization One; Organization Two
:mn-document-class: ogc
:mn-output-extensions: xml,html,doc,pdf
:local-cache-only:
:plantuml-format: svg
:plantuml-opts: debug
:data-uri-image:
:pdf-uri: ./document.pdf
:xml-uri: ./document.xml
:doc-uri: ./document.doc
:pdf-uri: ./geozarr-spec.pdf
:xml-uri: ./geozarr-spec.xml
:doc-uri: ./geozarr-spec.doc
:edition: 1.0

////
Expand All @@ -41,9 +43,13 @@ include::sections/clause_5_conventions.adoc[]

include::sections/clause_6_informative_text.adoc[]

include::sections/clause_7_normative_text.adoc[]
include::sections/clause_7_unified_data_model.adoc[]

include::sections/clause_8_media_types.adoc[]
include::sections/clause_8_conformance.adoc[]

include::sections/clause_9_zarr_encoding.adoc[]

include::sections/clause_10_geotiff_encoding.adoc[]

////
add or remove annexes after "A" as necessary
Expand Down
75 changes: 15 additions & 60 deletions standard/template/sections/clause_0_front_material.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,77 +1,32 @@
.Preface

[NOTE]
====
Insert Preface Text here. Give OGC specific commentary: describe the technical content, reason for document, history of the document and precursors, and plans for future work.
====
The GeoZarr Unified Data Model and Encoding Standard defines a layered, standards-based framework for representing and encoding geospatial and scientific datasets in the Zarr format. It integrates foundational specifications such as the Unidata Common Data Model (CDM), the CF Conventions, and selected OGC and community standards to enable semantic, structural, and operational interoperability across Earth observation platforms and geospatial ecosystems.

////
*OGC Declaration*
////
This Standard introduces a unified model that harmonises metadata structures, array-based data representations, coordinate referencing, and multiscale tiling semantics. It provides a coherent framework that facilitates encoding into Zarr v2 and v3, supporting scalable, cloud-native workflows.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
The purpose of this document is to provide implementation guidance and normative structure for consistent, interoperable adoption of GeoZarr across tools, platforms, and services. This work extends prior standardisation efforts within the OGC, including OGC API – Tiles, the Tile Matrix Set Standard, and EO metadata conventions, and anticipates integration with catalogue systems such as STAC.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

////
NOTE: Uncomment ISO section if necessary

*ISO Declaration*

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
////
This Standard has been developed in collaboration with contributors from Earth observation, climate science, geospatial analysis, and cloud-native geodata infrastructure communities. Future work may extend this model to additional storage formats, API services, and semantic layers.

[abstract]
== Abstract

<Insert Abstract Text here>



== Preface

[NOTE]
====
Insert Preface Text here. Give OGC specific commentary: describe the technical content, reason for document, history of the document and precursors, and plans for future work. >
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
====

== Security considerations

//If no security considerations have been made for this Standard, use the following text.

No security considerations have been made for this Standard.

////
If security considerations have been made for this Standard, follow the examples found in IANA or IETF documents. Please see the following example.
“VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
NOTE: The security measures discussed in the following sections only provide various kinds of authentication. No confidentiality is provided at all. This should be explicitly described as outside the scope....”
////
The GeoZarr Unified Data Model and Encoding Standard specifies a conceptual and implementation framework for representing multidimensional, geospatial datasets using the Zarr format. This Standard builds upon the Unidata Common Data Model (CDM) and the Climate and Forecast (CF) Conventions, and introduces interoperable constructs for tiling, georeferencing, and metadata integration.

The model defines core elements—dimensions, coordinate variables, data variables, attributes—and optional extensions for multi-resolution overviews, affine geotransforms, and STAC metadata. Encoding guidance is provided for Zarr Version 2 and Zarr Version 3, including chunking, group hierarchy, and metadata conventions.

GeoZarr aims to bridge scientific and geospatial communities by enabling round-trip transformations with formats such as NetCDF and GeoTIFF, and supporting compatibility with tools in the scientific Python and geospatial ecosystems. This Standard enables scalable, standards-compliant, and semantically rich data structures for cloud-native Earth observation applications.

== Submitters

All questions regarding this submission should be directed to the editor or the submitters:

.Table of submitters
[%unnumbered]
|===
|*Name* |*Affiliation*
| |
|===

== Contributors

//This clause is optional.

Additional contributors to this Standard include the following:

Individual name(s), Organization
| *Name* | *Affiliation*
|Christophe Noël _(editor)_ | Spacebel
|Brianna Pagán _(editor)_ | DevSeed
|Ryan Abernathey| EarthMover
| TBD | TBD
|===
3 changes: 3 additions & 0 deletions standard/template/sections/clause_10_geotiff_encoding.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
== Unified Data Model Encoding for GeoTiff

TIP: This is a very preliminary draft. The content is primarily for demonstrating the purpose of the proposed sections.
10 changes: 6 additions & 4 deletions standard/template/sections/clause_1_scope.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
== Scope
[NOTE]
====
Insert Scope text here. Give the subject of the document and the aspects of that scope covered by the document.
====

The GeoZarr Unified Data Model and Encoding Standard defines a conceptual and implementation framework for representing and encoding geospatial and scientific datasets using the Zarr format. The scope of this Standard includes the definition of a format-agnostic unified data model, the specification of its encoding into Zarr Version 2 and Version 3, and the establishment of extension points to support interoperability with external metadata and tiling standards.

This Standard addresses the needs of Earth observation, environmental monitoring, and geospatial analysis applications that require efficient, scalable access to multidimensional datasets. It enables the harmonisation of existing data models, such as the Unidata Common Data Model (CDM) and the Climate and Forecast (CF) Conventions, with operational encoding formats suitable for cloud-native storage and analysis.

Typical use cases include the storage, transformation, discovery, and processing of raster and gridded data, data cubes with temporal or vertical dimensions, and catalogue-enabled datasets integrated with metadata standards such as STAC and OGC Tile Matrix Sets.
51 changes: 42 additions & 9 deletions standard/template/sections/clause_2_conformance.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,49 @@
== Conformance
This standard defines XXXX.

Requirements for N standardization target types are considered:
The GeoZarr Unified Data Model is structured around a modular set of requirements classes. These classes define the conformance criteria for datasets and implementations adopting the GeoZarr specification. Each class provides a distinct set of structural or semantic expectations, facilitating interoperability across a broad spectrum of geospatial and scientific use cases.

* AAAA
* BBBB
The *Core* requirements class defines the minimal compliance necessary to claim conformance with the GeoZarr Unified Data Model. It is intentionally open and permissive, supporting incremental adoption and broad compatibility with existing Zarr tools and data models based on the Unidata Common Data Model (CDM).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 well said


Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
Additional requirements classes are defined to support enhanced functionality, semantic richness, and interoperability with established geospatial conventions and systems. These include extensions for time series, coordinate systems, affine transformations, and multiscale tiling.

In order to conform to this OGC® interface standard, a software implementation shall choose to implement:
.Requirements Classes Overview
[cols="30,40,30", options="header"]
|===
|Requirements Class | Description | Identifier

* Any one of the conformance levels specified in Annex A (normative).
* Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).
|Core Model
|Specifies minimum conformance for encoding multidimensional datasets in Zarr using CDM-aligned constructs. Includes dimensions, variables, attributes, and groups.
|`http://www.opengis.net/spec/geozarr/1.0/conf/core`

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.
|Time Series Support
|Defines conventions for temporal dimensions and time coordinate variables to support time-aware arrays.
|`http://www.opengis.net/spec/geozarr/1.0/conf/time`

|Coordinate Reference Systems
|Specifies use of CF-compliant CRS metadata, including `grid_mapping`, `standard_name`, and EPSG codes.
|`http://www.opengis.net/spec/geozarr/1.0/conf/crs`

|GeoTransform Metadata
|Enables affine spatial referencing via GDAL-compatible `GeoTransform` metadata and optional interpolation hints.
|`http://www.opengis.net/spec/geozarr/1.0/conf/geotransform`
Comment on lines +26 to +28
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should start with a translation of the OGC GeoTIFF standard rather than basing GeoZarr v1.0 on GDAL's internal data structure (i.e., ModelTiepoint, ModelPixelScale, ModelTransformation).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree on thiis point, and I think you're not referring GDAL data model, but the encoding in GeoTiff (ModelTiepoint, ModelPixelScale, ModelTransformation) which complexifies the 6 points of affine transform.

I think the current approach with the greatest support is the extension/adaptation of CF to support also affine transformation.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is indeed complexifying on GDAL, when it's not just a bounding box it is sparse coordinates. Besides the special case of skew/rotation with six fig transform, Max has explained well how this is getting out of hand. Don't reinvent the warper API here 🙏

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why we would adopt an in-memory representation that only supports a subset of use-cases when we're dealing with serializing metadata and there is a long-established and widely used standard for serializing this information that works for a broader set of use cases. I'm arguing for GeoTIFF tags over GDAL.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I said similar here before I understood the landscape much: https://discourse.pangeo.io/t/example-which-highlights-the-limitations-of-netcdf-style-coordinates-for-large-geospatial-rasters/4140/16?u=michael_sumner I'll try to put together examples. Maybe I'm off base but tie points are a small case of non redundant coordinate arrays, it's not a raster so very cleanly out of scope imo.

Copy link

@geospatial-jeff geospatial-jeff May 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree on thiis point, and I think you're not referring GDAL data model, but the encoding in GeoTiff (ModelTiepoint, ModelPixelScale, ModelTransformation) which complexifies the 6 points of affine transform.

This is not true from my practical experience. I've been using the following code to convert GeoTIFF tags into a GDAL compliant affine transformation for 5+ years and it hasn't broken once (and no issues/bugs reported either).

        gt = affine.Affine(
            self.ifds[0].ModelPixelScaleTag[0],
            0.0,
            self.ifds[0].ModelTiepointTag[3],
            0.0,
            -self.ifds[0].ModelPixelScaleTag[1],
            self.ifds[0].ModelTiepointTag[4],
        )

That's not to say that this will never break, there are definitely cases where this wouldn't work, some of these have already been covered in the thread:

since the relationship between the Raster space and the model space will often be an exact, affine transformation, this relationship can be defined using one set of tiepoints and the "ModelPixelScaleTag", described below, which gives the vertical and horizontal raster grid cell size, specified in model units. If possible, the first tiepoint placed in this tag shall be the one establishing the location of the point (0,0) in raster space. However, if this is not possible (for example, if (0,0) is goes to a part of model space in which the projection is ill-defined), then there is no particular order in which the tiepoints need be listed. For orthorectification or mosaicking applications a large number of tiepoints may be specified on a mesh over the raster image. However, the definition of associated grid interpolation methods is not in the scope of the current GeoTIFF spec.

The key here is that the definition and interpretation of multiple tie points is not defined by the GeoTIFF spec. GDAL does have its own logic to interpret images with multiple (more than 6) tie points, I'm sure other libraries have slightly different logic. I believe we should be building GeoZarr to cover the highest surface area possible; not to cover all potential use cases. Because it is impossible to provide a representation of an affine transform that satisfies all potential edge cases that may appear across CF / GDAL / GeoTiff (and w/e other data formats people load into GeoZarr).

I think we should start with a translation of the OGC GeoTIFF standard rather than basing GeoZarr v1.0 on GDAL's internal data structure (i.e., ModelTiepoint, ModelPixelScale, ModelTransformation).

Back to the original question; I don't think it does anyone justice to debate whether or not we should be in compliance with GeoTIFF or GDAL's internal data model. The reality is the concept of an "affine transform" was developed over the course of the 18th-19th century and far pre-dates the notion of raster data, geotiff, or the GDAL data model. Let's just call it what it is! Translating to GeoZarr from both GeoTIFF and GDAL is valuable to see how well they map over.

I think the current approach with the greatest support is the extension/adaptation of CF to support also affine transformation.

Why do we have to extend CF to add support for affine transforms to GeoZarr? Why can't we just say "geozarr should use affine transforms, and this is how the affine transform should be structured".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true from my practical experience. I've been using the following code to convert GeoTIFF tags into a GDAL compliant affine transformation

You just confirm that ModelTiepointTag, ModelPixelScaleTag are GeoTiff, not GDAL.

Yes basically the logic is:

  • If ModelTransformationTag exists → derive affine from matrix.

  • Else:

    • Use ModelTiepointTag for origin.
    • Use ModelPixelScaleTag for pixel size.
    • Adjust origin if PixelIsPoint (shift by ½ pixel).

What I'm arguing for is that the GeoZarr encoding should be formatted closer to GDAL syntax (below) than using GeoTiff attributes.

Affine = [a0, a1, a2, a3, a4, a5]

Where:
a0 = top left x (origin X)
a1 = pixel width (scale X)
a2 = rotation (typically 0)
a3 = top left y (origin Y)
a4 = rotation (typically 0)
a5 = pixel height (scale Y, usually negative)

I'm in favor of the draft proposed by CF recently: https://github.com/orgs/cf-convention/discussions/411

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is just a semantics issue then. a0 a1 a2 (as you mention above) are not related to GDAL (or GeoTIFF). That is the definition of an affine transform, which GDAL happens to implement. While it's true to say this aligns with the GDAL data model, it's more accurate to say that "this is an affine transform".

To state that differently; GDAL did not come up with the idea of an affine transformation. The concept of an affine transform exists outside of GDAL/CF/GeoTIFF, or any of the other implementations that have been discussed here. Why not just call it what it is?

As I said in my earlier comments, I don't think it does the community any justice to spend our time debating whether or not an affine transform is more like GeoTIFF or more like GDAL when there is a lower level definition for an "affine transform" which existed long before either of these two implementations exist.


|Multiscale Overviews
|Specifies multiscale tiled layout using zoom levels and Tile Matrix Sets as per OGC API – Tiles.
|`http://www.opengis.net/spec/geozarr/1.0/conf/overviews`
Comment on lines +30 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think a conformance class for OGC API - Tiles should be included in GeoZarr v1.0 because it may be more complicated than necessary. The community is requesting support for simple factor of two downsampling, which would be provided by a Zarr translation of the OGC COG standard, but not storing OGC TMS (e.g., https://cloudnativegeo.slack.com/archives/C06HCP0KAA2/p1746035679500189). So I think we should start with the COG-translated conformance class (cc @vincentsarago @geospatial-jeff)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maxrjones from my point of view, this only means not reinventing the wheel, and in line with the OGC spec. This has been already mostly covered in draft clause_7d_format_pyramiding.adoc (and discussions such as : #30)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think a conformance class for OGC API - Tiles should be included in GeoZarr v1.0 because it may be more complicated than necessary.

I strongly agree with this. While overviews are used mostly in geospatial use cases for visualization purposes; there is nothing inherently geospatial about overviews. There is not a specification for overviews as far as I'm aware, but I'd argue (geo)TIFF is the reference example for overviews/tiling. GeoTIFF only stores geospatial information (geotiff tags) on the IFD holding native resolution data. GeoTIFF does not store any spatial information on IFDs that contain reduced resolution overviews.

I believe the community simply needs more time to figure out how overviews (in the geospatial sense) apply more generally to the zarr data model, and pushing this OGC API - Tiles conformance class into GeoZarr before it's well thought through is not beneficial to anyone. Overviews are also not important enough to block the release of GeoZarr v1.0.

I'd much rather give the community something to build off of by releasing an initial GeoZarr v1.0 spec without overview support. Then see how the tooling evolves to support overviews against the broader zarr visualization use-case (through projects like https://github.com/carbonplan/ndpyramid). It's much easier to circle back to add a tiling conformance class after the fact than refactor an existing conformance class that wasn't well thought through to begin with 😄

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A conformance class is only the advertisement (conformTo: overview) that overview are provided in the dataset. The abstract representation of overviews/multiscales should be defined in the abstract data model, and the concrete representation in the zarr encoding of the model.

The overviews/ multiscaling indeed would probably reuse exisitng specification (GeoTiff, or Tile Matrix Set doesn't matter which one wins). A few draft and demonstration have been proposed, so I don't se why the community would need more time: as any other topic, we should progress on this topic during the year, provide examples, and see what suits the best. The initial TMS based draft looks great to me: #44


|STAC Metadata Integration
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is someone currently owning the STAC integration?

|Allows embedding or referencing of STAC Collection/Item metadata for discovery and indexing.
|`http://www.opengis.net/spec/geozarr/1.0/conf/stac`

|Projection Coordinates
|Supports encoding of data in projected coordinate systems and association with spatial reference metadata.
|`http://www.opengis.net/spec/geozarr/1.0/conf/projected`

|Spectral Bands
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we becoming too specific by starting to spell out attributes for spectral bands?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is too specific. Naming conventions for spectral bands is an issue across communities rather than just for Zarr. I think it would be better to define the standard outside GeoZarr and then provide references.

|Defines conventions for encoding multi-band imagery, including band identifiers, wavelengths, and metadata attributes.
|`http://www.opengis.net/spec/geozarr/1.0/conf/bands`
|===

Each requirements class is independently defined. Implementations may declare conformance with any subset of classes appropriate to their use case. All classes build upon the Core model.

Associated conformance tests for each class are detailed in Annex A.
55 changes: 19 additions & 36 deletions standard/template/sections/clause_3_references.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,49 +5,32 @@ The following normative documents contain provisions that, through reference in

[NOTE]
====
Insert References here. If there are no references, leave this section empty.

References are to follow the Springer LNCS style, with the exception that optional information may be appended to references: DOIs are added after the date and web resource references may include an access date at the end of the reference in parentheses. See examples from Springer and OGC below.
References follow the Springer LNCS citation style. DOIs and persistent URLs are provided where applicable.
====

* [[[Smith81,Identification of Common Molecular Subsequences]]],
_Identification of Common Molecular Subsequences_.
Smith, T.F., Waterman, M.S., J. Mol. Biol. 147, 195–197 (1981)

* [[[May06,ZIB Structure Prediction Pipeline]]],
_ZIB Structure Prediction Pipeline: Composing a Complex Biological Workflow through Web Services_.
May, P., Ehrlich, H.C., Steinke, T. In: Nagel, W.E., Walter,
W.V., Lehner, W. (eds.) Euro-Par 2006. LNCS, vol. 4128, pp. 1148–1158. Springer,
Heidelberg (2006)

* [[[Grid,The Grid]]], _The Grid: Blueprint for a New Computing Infrastructure._,
Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).

* [[[Czajkowski01,Grid Information Services for Distributed Resource Sharing]]],
_Grid Information Services for Distributed Resource Sharing._
Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C. In: 10th IEEE International Symposium on High
Performance Distributed Computing, pp. 181–184. IEEE Press, New York (2001)

* [[[Foster02,The Physiology of the Grid]]],
_The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration._
Foster, I., Kesselman, C., Nick, J., Tuecke, S. Technical report, Global Grid Forum (2002)

* [[[NCBI,NCBI]]], _National Center for Biotechnology Information_, http://www.ncbi.nlm.nih.gov

* [[[ISO19101-1,ISO 19101-1:2014]]], Geographic information -- Reference model -- Part 1: Fundamentals
* [[[ZarrV2, Zarr Specification v2]]],
Miles, A., et al.: _Zarr Specification Version 2_. Zarr Developers. https://zarr.readthedocs.io/en/stable/spec/v2.html

* [[[ISO19115-1,ISO 19115-1:2014]]], _Geographic information -- Metadata -- Part 1: Fundamentals_
* [[[ZarrV3, Zarr Specification v3]]],
Zarr Community: _Zarr Specification Version 3_. https://zarr-specs.readthedocs.io/en/latest/v3.0

* [[[ISO19157,ISO 19157:2013]]], _Geographic information -- Data quality_
* [[[CDM, Unidata Common Data Model]]],
Unidata: _The Common Data Model_. https://docs.unidata.ucar.edu/netcdf-java/5.0/userguide/common_data_model_overview.html

* [[[ISO19139,ISO 19139:2007]]], _Geographic information -- Metadata -- XML schema implementation_
* [[[NetCDFClassic, NetCDF Classic Format]]],
Rew, R., Davis, G.: _NetCDF: An Interface for Scientific Data Access_. IEEE Computer Graphics and Applications, 10(4), 76–82 (1990). https://doi.org/10.1109/38.56302

* [[[ISO19115-3,ISO 19115-3]]], _Geographic information -- Metadata -- Part 3: XML schemas_ (2016)
* [[[CFConventions, CF Metadata Conventions]]],
CF Community: _Climate and Forecast (CF) Metadata Conventions, Version 1.10_. https://cfconventions.org/

* [[[OGC15-097,OGC 15-097]]], _OGC Geospatial User Feedback Standard: Conceptual Model_ (2016)
* [[[GDAL, GDAL – Geospatial Data Abstraction Library]]],
GDAL Developers: _GDAL/OGR Version 3.8 Documentation_. Open Source Geospatial Foundation. https://gdal.org

* [[[OGC12-019,OGC 12-019]]], _OGC City Geography Markup Language (CityGML) Encoding Standard_ (2012)
* [[[OGCTMS, OGC Two Dimensional Tile Matrix Set]]],
Open Geospatial Consortium: _OGC Two Dimensional Tile Matrix Set and Tile Pyramid_ (OGC 17-083r2). https://docs.ogc.org/is/17-083r2/17-083r2.html

* [[[OGC14-005r3,OGC 14-005r3]]], _OGC IndoorGML_ (2014)
* [[[STAC, SpatioTemporal Asset Catalog (STAC) Specification]]],
STAC Community: _STAC Specification v1.0.0_. https://stacspec.org/en/

* [[[OGC06121r9,OGC 06-121r9]]], _OGC Web Service Common Implementation Specification_, April 7, 2010. http://portal.opengeospatial.org/files/?artifact_id=38867
* [[[OGCCTPP, OGC Compliance Testing Policies and Procedures]]],
Open Geospatial Consortium: _OGC Compliance Testing Policies and Procedures_, OGC 08-134r10. https://portal.ogc.org/files/?artifact_id=55184
Loading