book/en/introduction/ConceptualModels.html - sis-site - Git at Google

 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE html>

 <!--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
 -->

 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
   <head>
     <title>ConceptualModels</title>
     <meta charset="UTF-8"/>
     <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
       Content below this point is copied in "../../content/book/en/developer-guide.html"
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
         <h2 id="ConceptualModels">Sources of conceptual models used by Apache SIS</h2>
       </header>
       <p>
         Most standards used by Apache <abbr>SIS</abbr> have been devised by the <a href="https://www.ogc.org/">Open Geospatial Consortium</a> (<abbr>OGC</abbr>),
         sometimes in collaboration with the <a href="https://www.iso.org/">International Organization for Standardization</a> (<abbr>ISO</abbr>).
         Some <abbr>ISO</abbr> standards themselves become European standards via the <a href="http://inspire.jrc.ec.europa.eu">INSPIRE Directive</a>.
         These standards offer two key features:
       </p>
       <ul>
         <li>
           Allowing a community to make its information public in such a way that outside individuals or systems can discover it.
         </li>
         <li>
           Transferring information from one community to another while preserving its semantics,
           even if the two communities use very different internal representations.
         </li>
       </ul>
       <p>
         These standards are made available to the international community for free,
         as <a href="https://www.ogc.org/standards/is">specifications (<abbr title="Portable Document Format">PDF</abbr> files)</a> or
         as <a href="http://schemas.opengis.net/gml/3.3/">schemas (<abbr title="XML Schema Definition">XSD</abbr> files)</a>.
         Standardization organizations do not create software; to obtain an implementation of these specifications,
         users must choose one of the compliant products available on the market, or develop their own solutions.
         Such voluntary compliance with these specifications allow independent communities to more easily exchange geographic information.
       </p>


       <details>
         <summary>More about standardization process</summary>
         <article id="OGC-process">
           <header>
             <h2><abbr>OGC</abbr> standardization process</h2>
           </header>
           <p>
             The work of the <abbr title="Open Geospatial Consortium">OGC</abbr> is done by email, teleconferences, and at <a href="https://www.ogc.org/event?category=ogctcpc">in-person meetings</a>.
             The <abbr>OGC</abbr> organizes four meetings per year, each lasting five days, and hosted by member organizations that sponsor the event (companies, universities, research centres, <i>etc</i>).
             The host continent alternates between Europe and North America, with a growing presence in Asia since 2011.
             These meetings are usually attended by between 50 and 100 participants from among the hundreds of members of the <abbr>OGC</abbr>.
             Some participants are present at almost all the meetings, forming the pillars of the organization.
             The meetings of the <abbr>OGC</abbr> offer opportunities for exchange among members from diverse backgrounds.
           </p><p>
             The creation of a <abbr>OGC</abbr> standard begins with a gathering of organizations or individuals with a common interest in an issue.
             A working group is proposed as a <i>Domain Working Group</i> (<abbr>DWG</abbr>) or as a <i>Standard Working Group</i> (<abbr>SWG</abbr>).
             <abbr>DWG</abbr>s are open to all members of the <abbr>OGC</abbr>,
             while <abbr>SWG</abbr>s require that their participants enter into an agreement not to hinder the distribution of the standard through intellectual property claims.
           </p>

           <h3 id="OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) procedures</h3>
           <p>
             In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
             These founding members draft a charter defining the objectives of the <abbr>SWG</abbr>,
             which must be approved by the Technical Committee of the <abbr>OGC</abbr>.
             Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
             Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
             and receives on request the right to vote after several months of observation.
           </p><p>
             A <abbr>SWG</abbr> may contain several dozen members, but the volunteers performing the bulk of the work are usually fewer.
             Their proposals are submitted to the entire membership of the group, who may accept them by unanimous consent.
             Any objections must be debated, and an alternative proposed.
             <abbr>SWG</abbr>s usually try to debate an issue until a consensus emerges rather than move ahead despite negative votes,
             even if those opposed are in a minority.
             The decisions of the group are then integrated into the specifications by a member who assumes the role of editor.
           </p><p>
             As far as possible, the working group must structure the specifications as a core around which various extensions might be built.
             A series of tests must accompany the standard, allowing implementations to be classified by the level of test passed.
             There must be at least one <i>reference implementation</i> that passes all the tests in order to demonstrate that the standard is usable.
           </p><p>
             When the standard is considered ready, the <abbr>SWG</abbr> votes on a motion proposing its submission to a vote by the higher authorities of the <abbr>OGC</abbr>.
             This process takes several months. There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
           </p>

           <h3 id="OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</h3>
           <p>
             All proposals for standards are first examined by the <abbr>OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
             This board ensures that the standard conforms to the requirements of the <abbr>OGC</abbr> in form,
             modularization, and in terms of integration with other standards.
             If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr>TC</abbr>).
             This committee consists of the principal members of the <abbr>OGC</abbr>, and only they are capable of granting final approval.
             If approved, the standard is made publicly available for comments during a period of several months.
             At the end of this period, the <abbr title="Standard Working Group">SWG</abbr> must examine and respond to each comment.
             The eventual modifications of the standard are submitted to the <abbr>OAB</abbr>, then the standard is published in its final form.
             This distribution is announced in a press release by the <abbr>OGC</abbr>.
           </p><p>
             Certain members of the <abbr title="Open Geospatial Consortium">OGC</abbr> and the <abbr title="Technical Committee">TC</abbr>
             also act as liaisons with the International Organization for Standardization (<abbr>ISO</abbr>).
             Cooperation between the two organizations goes two ways:
             the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
             and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
           </p>

           <h3 id="OGC-RFC">Procedure for the submission of proposals for modification</h3>
           <p>
             All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr>OGC</abbr> standards.
             A list of current proposals for changes, along with a form for submitting new proposals, is <a href="https://www.ogc.org/standards/cr">available online</a>.
             Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
           </p><p>
             Some working groups use other parallel systems for submissions, for example GitHub merge requests, hosted outside of the structures of the <abbr>OGC</abbr>.
           </p>
         </article>
       </details>


       <p>
         Besides these formal standardization organizations, there are organizations that are not officially dedicated
         to the creation of standards, but whose work has largely been adopted as <i>de facto</i> standards.
         In particular, the <a href="https://epsg.org/">EPSG repository</a> offers numeric codes which allow the easy identification of a
         Coordinates Reference System (<abbr>CRS</abbr>) among <a href="../../tables/CoordinateReferenceSystems.html">several thousand</a>.
         This database is offered by petroleum companies that have an interest in ensuring their explorations are conducted in the correct place,
         even when using map produced by another party.
         Other examples of <i>de facto</i> standards include <a href="http://geotiff.osgeo.org">GeoTIFF</a> for data distributed on a grid (such as images),
         and <a href="http://en.wikipedia.org/wiki/Shapefile">Shapefile</a> for vector data (such as geometric shapes).
       </p><p>
         <abbr>OGC</abbr> standards are specified in several dozen documents.
         Each document outlines a service — for example, the transformation of coordinates.
         The function of each service is described by a collection of object classes and their interactions.
         These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language) diagrams in specifications called “abstracts”.
         <a href="https://www.ogc.org/standards/as">Abstract specifications</a> do not refer to any specific computer language.
         Their concepts may be applied more or less directly to a programming language, a database or an <abbr>XML</abbr> schema.
         There is always an element of arbitrariness in the method of applying an abstract specification,
         given that adjustments are often necessary to take into account the constraints or conventions of the target language.
         Certain data structures only exist in a few languages — for example, unions that exist in C/C++ but not in Java.
       </p>


       <details>
         <summary>More about “implementation specifications”</summary>
         <article id="implementation-standard">
           <header>
             <h2>Historical note</h2>
           </header>
           <p>
             At the turn of the millennium, the abstract specifications were explicitly concretized in <i>implementation specifications</i>.
             The term “implementation” is used here in the sense of all types of interfaces (Java or others) derived from
             <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not implementations in the Java sense.
             Such specifications existed for <abbr title="Structured Query Language">SQL</abbr>,
             <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr>, and Java languages.
             As these languages are capable of executing procedures, the specifications of this period define not only data structures,
             but also operations that apply to these structures.
           </p><p>
             Thereafter, enthusiasm for “Web 2.0” increased interest for <abbr>XML</abbr> over other languages.
             Older implementation specifications were deprecated,
             and <abbr title="XML Schema Definition">XSD</abbr> schemas became the main concretization of abstract specifications.
             Even the way abstract specifications are designed has evolved: they are less likely to define operations, and so what remains is closer to descriptions of database schemas.
             Some operations that were defined in older standards now appear, in another form, in web service specifications.
             Finally, the term “implementation specification” has been deprecated, to be subsumed under the term “<abbr>OGC</abbr> standard.”
             But despite their depreciation, <a href="https://www.ogc.org/docs/retired">old implementation specifications</a> remain useful to programs in Java, because:
           </p>
           <ul>
             <li>Their simpler models, applied to the same concepts, are helpful in understanding new specifications.</li>
             <li>They sometimes define easy ways to perform common tasks, where the newer specifications limit themselves to general cases.</li>
             <li>As operations are more often omitted from the newer specifications, the old ones remain a useful supplement when defining <abbr>API</abbr>s.</li>
           </ul>
           <p>
             The Apache <abbr>SIS</abbr> project is based on the most recent specifications,
             drawing from the archives of the <abbr>OGC</abbr> to complete certain abstract standards or make them more usable.
             Some old definitions are preserved as “convenience methods”, not always bringing new functionality, but facilitating the practical use of a library.
           </p>
         </article>
       </details>
       <p>
         The following table lists the main norms used by the project.
         Many norms are published both as <abbr>ISO</abbr> standards and as <abbr>OGC</abbr> standards,
         and their corresponding names are listed next to one another in the first two columns.
         The “implementation specifications” section lists specifications that bring few new concepts compared to abstract specifications,
         but detail how to represent those concepts in specific environments like <abbr>XML</abbr> documents.
         Standards that are deprecated but still partially used appear <s>struck through</s>.
         Finally, GeoAPI packages will be introduced in upcoming chapters.
       </p>
       <table>
         <caption>Main Standards Related to the Apache <abbr>SIS</abbr> project</caption>
         <tr>
           <th><abbr>ISO</abbr> Norm</th>
           <th><abbr>OGC</abbr> Norm</th>
           <th>Titre</th>
           <th>GeoAPI package</th>
           <th>Apache SIS package</th>
         </tr><tr>
           <td class="separator" colspan="5">Abstract Specifications</td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19103</td>
           <td></td>
           <td><i>Conceptual schema language</i></td>
           <td><code class="GeoAPI">….util</code></td>
           <td><code class="SIS">….util.iso</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19115-1</td>
           <td>Topic 11</td>
           <td><i>Metadata</i></td>
           <td><code class="GeoAPI">….metadata</code></td>
           <td><code class="SIS">….metadata.iso</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19115-2</td>
           <td></td>
           <td><i>Metadata — extensions for imagery and gridded data</i></td>
           <td><code class="GeoAPI">….metadata</code></td>
           <td><code class="SIS">….metadata.iso</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19111</td>
           <td>Topic 2</td>
           <td><i>Spatial referencing by coordinates</i></td>
           <td><code class="GeoAPI">….referencing</code></td>
           <td><code class="SIS">….referencing</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19111-2</td>
           <td></td>
           <td><i>Referencing — extension for parametric values</i></td>
           <td><code class="GeoAPI">….referencing</code></td>
           <td><code class="SIS">….referencing</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19112</td>
           <td></td>
           <td><i>Spatial referencing by geographic identifier</i></td>
           <td><code class="GeoAPI">….referencing.gazetteer</code></td>
           <td><code class="SIS">….referencing.gazetteer</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19108</td>
           <td></td>
           <td><i>Temporal Schema</i></td>
           <td><code class="GeoAPI">….temporal</code></td>
           <td></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19107</td>
           <td>Topic 1</td>
           <td><i>Feature geometry</i></td>
           <td><code class="GeoAPI">….geometry</code></td>
           <td><code class="SIS">….geometry</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19109</td>
           <td>Topic 5</td>
           <td><i>Rules for application schema</i></td>
           <td><code class="GeoAPI">….feature</code></td>
           <td><code class="SIS">….feature</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19123</td>
           <td>Topic 6</td>
           <td><i>Schema for coverage geometry and functions</i></td>
           <td><code class="GeoAPI">….coverage</code></td>
           <td><code class="SIS">….coverage</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19156</td>
           <td>Topic 20</td>
           <td><i>Observations and measurements</i></td>
           <td><code class="GeoAPI">….observation</code></td>
           <td></td>
         </tr><tr>
           <td class="separator" colspan="5">Implementation Specifications</td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19139</td>
           <td></td>
           <td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
           <td></td>
           <td><code class="SIS">….xml</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19136</td>
           <td>OGC 07-036</td>
           <td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
           <td></td>
           <td><code class="SIS">….xml</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19162</td>
           <td>OGC 12-063</td>
           <td><i>Well-known text representation of coordinate reference systems</i></td>
           <td></td>
           <td><code class="SIS">….io.wkt</code></td>
         </tr><tr>
           <td></td>
           <td><s><abbr>OGC</abbr> 01-009</s></td>
           <td><s><i>Coordinate Transformation Services</i></s></td>
           <td><code class="GeoAPI">….referencing</code></td>
           <td><code class="SIS">….referencing</code></td>
         </tr><tr>
           <td></td>
           <td><s><abbr>OGC</abbr> 01-004</s></td>
           <td><s><i>Grid Coverage</i></s></td>
           <td><code class="GeoAPI">….coverage</code></td>
           <td><code class="SIS">….coverage</code></td>
         </tr><tr>
           <td></td>
           <td><abbr>OGC</abbr> 10-092</td>
           <td><i>NetCDF binary encoding: classic and 64-bit offset format</i></td>
           <td></td>
           <td><code class="SIS">….storage.netcdf</code></td>
         </tr><tr>
           <td></td>
           <td><abbr>OGC</abbr> 14-084</td>
           <td><i>Moving features Comma Separated Values (CSV) encoding</i></td>
           <td></td>
           <td><code class="SIS">….storage</code></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 13249</td>
           <td></td>
           <td><i><abbr>SQL</abbr> spatial</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>SLD</abbr></td>
           <td><i>Styled Layer Descriptor</i></td>
           <td><code class="GeoAPI">….style</code></td>
           <td></td>
         </tr><tr>
           <td class="separator" colspan="5">Web Services</td>
         </tr><tr>
           <td></td>
           <td><abbr>CSW</abbr></td>
           <td><i>Catalog Services</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19128</td>
           <td><abbr>WMS</abbr></td>
           <td><i>Web Map Service</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>WMTS</abbr></td>
           <td><i>Web Map Tile Service</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td><abbr>ISO</abbr> 19142</td>
           <td><abbr>WFS</abbr></td>
           <td><i>Web Feature Service</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>WCS</abbr></td>
           <td><i>Web Coverage Service</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>WPS</abbr></td>
           <td><i>Web Processing Service</i></td>
           <td></td>
           <td></td>
         </tr>
         <tr>
           <td></td>
           <td>Open<abbr>LS</abbr></td>
           <td><i>Location Services</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>SWE</abbr></td>
           <td><i>Sensor Web Enablement</i></td>
           <td></td>
           <td></td>
         </tr><tr>
           <td></td>
           <td><abbr>SOS</abbr></td>
           <td><i>Sensor Observation Service</i></td>
           <td></td>
           <td></td>
         </tr>
       </table>
     </section>
   </body>
 </html>
	<?xml version="1.0" encoding="UTF-8" ?>
	<!DOCTYPE html>

	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->

	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
	<title>ConceptualModels</title>
	<meta charset="UTF-8"/>
	<link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
	</head>
	<body>
	<!--
	Content below this point is copied in "../../content/book/en/developer-guide.html"
	by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
	-->
	<section>
	<header>
	<h2 id="ConceptualModels">Sources of conceptual models used by Apache SIS</h2>
	</header>
	<p>
	Most standards used by Apache <abbr>SIS</abbr> have been devised by the <a href="https://www.ogc.org/">Open Geospatial Consortium</a> (<abbr>OGC</abbr>),
	sometimes in collaboration with the <a href="https://www.iso.org/">International Organization for Standardization</a> (<abbr>ISO</abbr>).
	Some <abbr>ISO</abbr> standards themselves become European standards via the <a href="http://inspire.jrc.ec.europa.eu">INSPIRE Directive</a>.
	These standards offer two key features:
	</p>
	<ul>
	<li>
	Allowing a community to make its information public in such a way that outside individuals or systems can discover it.
	</li>
	<li>
	Transferring information from one community to another while preserving its semantics,
	even if the two communities use very different internal representations.
	</li>
	</ul>
	<p>
	These standards are made available to the international community for free,
	as <a href="https://www.ogc.org/standards/is">specifications (<abbr title="Portable Document Format">PDF</abbr> files)</a> or
	as <a href="http://schemas.opengis.net/gml/3.3/">schemas (<abbr title="XML Schema Definition">XSD</abbr> files)</a>.
	Standardization organizations do not create software; to obtain an implementation of these specifications,
	users must choose one of the compliant products available on the market, or develop their own solutions.
	Such voluntary compliance with these specifications allow independent communities to more easily exchange geographic information.
	</p>



	<details>
	<summary>More about standardization process</summary>
	<article id="OGC-process">
	<header>
	<h2><abbr>OGC</abbr> standardization process</h2>
	</header>
	<p>
	The work of the <abbr title="Open Geospatial Consortium">OGC</abbr> is done by email, teleconferences, and at <a href="https://www.ogc.org/event?category=ogctcpc">in-person meetings</a>.
	The <abbr>OGC</abbr> organizes four meetings per year, each lasting five days, and hosted by member organizations that sponsor the event (companies, universities, research centres, <i>etc</i>).
	The host continent alternates between Europe and North America, with a growing presence in Asia since 2011.
	These meetings are usually attended by between 50 and 100 participants from among the hundreds of members of the <abbr>OGC</abbr>.
	Some participants are present at almost all the meetings, forming the pillars of the organization.
	The meetings of the <abbr>OGC</abbr> offer opportunities for exchange among members from diverse backgrounds.
	</p><p>
	The creation of a <abbr>OGC</abbr> standard begins with a gathering of organizations or individuals with a common interest in an issue.
	A working group is proposed as a <i>Domain Working Group</i> (<abbr>DWG</abbr>) or as a <i>Standard Working Group</i> (<abbr>SWG</abbr>).
	<abbr>DWG</abbr>s are open to all members of the <abbr>OGC</abbr>,
	while <abbr>SWG</abbr>s require that their participants enter into an agreement not to hinder the distribution of the standard through intellectual property claims.
	</p>

	<h3 id="OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) procedures</h3>
	<p>
	In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
	These founding members draft a charter defining the objectives of the <abbr>SWG</abbr>,
	which must be approved by the Technical Committee of the <abbr>OGC</abbr>.
	Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
	Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
	and receives on request the right to vote after several months of observation.
	</p><p>
	A <abbr>SWG</abbr> may contain several dozen members, but the volunteers performing the bulk of the work are usually fewer.
	Their proposals are submitted to the entire membership of the group, who may accept them by unanimous consent.
	Any objections must be debated, and an alternative proposed.
	<abbr>SWG</abbr>s usually try to debate an issue until a consensus emerges rather than move ahead despite negative votes,
	even if those opposed are in a minority.
	The decisions of the group are then integrated into the specifications by a member who assumes the role of editor.
	</p><p>
	As far as possible, the working group must structure the specifications as a core around which various extensions might be built.
	A series of tests must accompany the standard, allowing implementations to be classified by the level of test passed.
	There must be at least one <i>reference implementation</i> that passes all the tests in order to demonstrate that the standard is usable.
	</p><p>
	When the standard is considered ready, the <abbr>SWG</abbr> votes on a motion proposing its submission to a vote by the higher authorities of the <abbr>OGC</abbr>.
	This process takes several months. There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
	</p>

	<h3 id="OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</h3>
	<p>
	All proposals for standards are first examined by the <abbr>OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
	This board ensures that the standard conforms to the requirements of the <abbr>OGC</abbr> in form,
	modularization, and in terms of integration with other standards.
	If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr>TC</abbr>).
	This committee consists of the principal members of the <abbr>OGC</abbr>, and only they are capable of granting final approval.
	If approved, the standard is made publicly available for comments during a period of several months.
	At the end of this period, the <abbr title="Standard Working Group">SWG</abbr> must examine and respond to each comment.
	The eventual modifications of the standard are submitted to the <abbr>OAB</abbr>, then the standard is published in its final form.
	This distribution is announced in a press release by the <abbr>OGC</abbr>.
	</p><p>
	Certain members of the <abbr title="Open Geospatial Consortium">OGC</abbr> and the <abbr title="Technical Committee">TC</abbr>
	also act as liaisons with the International Organization for Standardization (<abbr>ISO</abbr>).
	Cooperation between the two organizations goes two ways:
	the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
	and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
	</p>

	<h3 id="OGC-RFC">Procedure for the submission of proposals for modification</h3>
	<p>
	All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr>OGC</abbr> standards.
	A list of current proposals for changes, along with a form for submitting new proposals, is <a href="https://www.ogc.org/standards/cr">available online</a>.
	Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
	</p><p>
	Some working groups use other parallel systems for submissions, for example GitHub merge requests, hosted outside of the structures of the <abbr>OGC</abbr>.
	</p>
	</article>
	</details>



	<p>
	Besides these formal standardization organizations, there are organizations that are not officially dedicated
	to the creation of standards, but whose work has largely been adopted as <i>de facto</i> standards.
	In particular, the <a href="https://epsg.org/">EPSG repository</a> offers numeric codes which allow the easy identification of a
	Coordinates Reference System (<abbr>CRS</abbr>) among <a href="../../tables/CoordinateReferenceSystems.html">several thousand</a>.
	This database is offered by petroleum companies that have an interest in ensuring their explorations are conducted in the correct place,
	even when using map produced by another party.
	Other examples of <i>de facto</i> standards include <a href="http://geotiff.osgeo.org">GeoTIFF</a> for data distributed on a grid (such as images),
	and <a href="http://en.wikipedia.org/wiki/Shapefile">Shapefile</a> for vector data (such as geometric shapes).
	</p><p>
	<abbr>OGC</abbr> standards are specified in several dozen documents.
	Each document outlines a service — for example, the transformation of coordinates.
	The function of each service is described by a collection of object classes and their interactions.
	These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language) diagrams in specifications called “abstracts”.
	<a href="https://www.ogc.org/standards/as">Abstract specifications</a> do not refer to any specific computer language.
	Their concepts may be applied more or less directly to a programming language, a database or an <abbr>XML</abbr> schema.
	There is always an element of arbitrariness in the method of applying an abstract specification,
	given that adjustments are often necessary to take into account the constraints or conventions of the target language.
	Certain data structures only exist in a few languages — for example, unions that exist in C/C++ but not in Java.
	</p>



	<details>
	<summary>More about “implementation specifications”</summary>
	<article id="implementation-standard">
	<header>
	<h2>Historical note</h2>
	</header>
	<p>
	At the turn of the millennium, the abstract specifications were explicitly concretized in <i>implementation specifications</i>.
	The term “implementation” is used here in the sense of all types of interfaces (Java or others) derived from
	<abbr title="Unified Modeling Language">UML</abbr> diagrams, and not implementations in the Java sense.
	Such specifications existed for <abbr title="Structured Query Language">SQL</abbr>,
	<abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr>, and Java languages.
	As these languages are capable of executing procedures, the specifications of this period define not only data structures,
	but also operations that apply to these structures.
	</p><p>
	Thereafter, enthusiasm for “Web 2.0” increased interest for <abbr>XML</abbr> over other languages.
	Older implementation specifications were deprecated,
	and <abbr title="XML Schema Definition">XSD</abbr> schemas became the main concretization of abstract specifications.
	Even the way abstract specifications are designed has evolved: they are less likely to define operations, and so what remains is closer to descriptions of database schemas.
	Some operations that were defined in older standards now appear, in another form, in web service specifications.
	Finally, the term “implementation specification” has been deprecated, to be subsumed under the term “<abbr>OGC</abbr> standard.”
	But despite their depreciation, <a href="https://www.ogc.org/docs/retired">old implementation specifications</a> remain useful to programs in Java, because:
	</p>
	<ul>
	<li>Their simpler models, applied to the same concepts, are helpful in understanding new specifications.</li>
	<li>They sometimes define easy ways to perform common tasks, where the newer specifications limit themselves to general cases.</li>
	<li>As operations are more often omitted from the newer specifications, the old ones remain a useful supplement when defining <abbr>API</abbr>s.</li>
	</ul>
	<p>
	The Apache <abbr>SIS</abbr> project is based on the most recent specifications,
	drawing from the archives of the <abbr>OGC</abbr> to complete certain abstract standards or make them more usable.
	Some old definitions are preserved as “convenience methods”, not always bringing new functionality, but facilitating the practical use of a library.
	</p>
	</article>
	</details>
	<p>
	The following table lists the main norms used by the project.
	Many norms are published both as <abbr>ISO</abbr> standards and as <abbr>OGC</abbr> standards,
	and their corresponding names are listed next to one another in the first two columns.
	The “implementation specifications” section lists specifications that bring few new concepts compared to abstract specifications,
	but detail how to represent those concepts in specific environments like <abbr>XML</abbr> documents.
	Standards that are deprecated but still partially used appear <s>struck through</s>.
	Finally, GeoAPI packages will be introduced in upcoming chapters.
	</p>
	<table>
	<caption>Main Standards Related to the Apache <abbr>SIS</abbr> project</caption>
	<tr>
	<th><abbr>ISO</abbr> Norm</th>
	<th><abbr>OGC</abbr> Norm</th>
	<th>Titre</th>
	<th>GeoAPI package</th>
	<th>Apache SIS package</th>
	</tr><tr>
	<td class="separator" colspan="5">Abstract Specifications</td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19103</td>
	<td></td>
	<td><i>Conceptual schema language</i></td>
	<td><code class="GeoAPI">….util</code></td>
	<td><code class="SIS">….util.iso</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19115-1</td>
	<td>Topic 11</td>
	<td><i>Metadata</i></td>
	<td><code class="GeoAPI">….metadata</code></td>
	<td><code class="SIS">….metadata.iso</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19115-2</td>
	<td></td>
	<td><i>Metadata — extensions for imagery and gridded data</i></td>
	<td><code class="GeoAPI">….metadata</code></td>
	<td><code class="SIS">….metadata.iso</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19111</td>
	<td>Topic 2</td>
	<td><i>Spatial referencing by coordinates</i></td>
	<td><code class="GeoAPI">….referencing</code></td>
	<td><code class="SIS">….referencing</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19111-2</td>
	<td></td>
	<td><i>Referencing — extension for parametric values</i></td>
	<td><code class="GeoAPI">….referencing</code></td>
	<td><code class="SIS">….referencing</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19112</td>
	<td></td>
	<td><i>Spatial referencing by geographic identifier</i></td>
	<td><code class="GeoAPI">….referencing.gazetteer</code></td>
	<td><code class="SIS">….referencing.gazetteer</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19108</td>
	<td></td>
	<td><i>Temporal Schema</i></td>
	<td><code class="GeoAPI">….temporal</code></td>
	<td></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19107</td>
	<td>Topic 1</td>
	<td><i>Feature geometry</i></td>
	<td><code class="GeoAPI">….geometry</code></td>
	<td><code class="SIS">….geometry</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19109</td>
	<td>Topic 5</td>
	<td><i>Rules for application schema</i></td>
	<td><code class="GeoAPI">….feature</code></td>
	<td><code class="SIS">….feature</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19123</td>
	<td>Topic 6</td>
	<td><i>Schema for coverage geometry and functions</i></td>
	<td><code class="GeoAPI">….coverage</code></td>
	<td><code class="SIS">….coverage</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19156</td>
	<td>Topic 20</td>
	<td><i>Observations and measurements</i></td>
	<td><code class="GeoAPI">….observation</code></td>
	<td></td>
	</tr><tr>
	<td class="separator" colspan="5">Implementation Specifications</td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19139</td>
	<td></td>
	<td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
	<td></td>
	<td><code class="SIS">….xml</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19136</td>
	<td>OGC 07-036</td>
	<td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
	<td></td>
	<td><code class="SIS">….xml</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19162</td>
	<td>OGC 12-063</td>
	<td><i>Well-known text representation of coordinate reference systems</i></td>
	<td></td>
	<td><code class="SIS">….io.wkt</code></td>
	</tr><tr>
	<td></td>
	<td><s><abbr>OGC</abbr> 01-009</s></td>
	<td><s><i>Coordinate Transformation Services</i></s></td>
	<td><code class="GeoAPI">….referencing</code></td>
	<td><code class="SIS">….referencing</code></td>
	</tr><tr>
	<td></td>
	<td><s><abbr>OGC</abbr> 01-004</s></td>
	<td><s><i>Grid Coverage</i></s></td>
	<td><code class="GeoAPI">….coverage</code></td>
	<td><code class="SIS">….coverage</code></td>
	</tr><tr>
	<td></td>
	<td><abbr>OGC</abbr> 10-092</td>
	<td><i>NetCDF binary encoding: classic and 64-bit offset format</i></td>
	<td></td>
	<td><code class="SIS">….storage.netcdf</code></td>
	</tr><tr>
	<td></td>
	<td><abbr>OGC</abbr> 14-084</td>
	<td><i>Moving features Comma Separated Values (CSV) encoding</i></td>
	<td></td>
	<td><code class="SIS">….storage</code></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 13249</td>
	<td></td>
	<td><i><abbr>SQL</abbr> spatial</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>SLD</abbr></td>
	<td><i>Styled Layer Descriptor</i></td>
	<td><code class="GeoAPI">….style</code></td>
	<td></td>
	</tr><tr>
	<td class="separator" colspan="5">Web Services</td>
	</tr><tr>
	<td></td>
	<td><abbr>CSW</abbr></td>
	<td><i>Catalog Services</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19128</td>
	<td><abbr>WMS</abbr></td>
	<td><i>Web Map Service</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>WMTS</abbr></td>
	<td><i>Web Map Tile Service</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td><abbr>ISO</abbr> 19142</td>
	<td><abbr>WFS</abbr></td>
	<td><i>Web Feature Service</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>WCS</abbr></td>
	<td><i>Web Coverage Service</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>WPS</abbr></td>
	<td><i>Web Processing Service</i></td>
	<td></td>
	<td></td>
	</tr>
	<tr>
	<td></td>
	<td>Open<abbr>LS</abbr></td>
	<td><i>Location Services</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>SWE</abbr></td>
	<td><i>Sensor Web Enablement</i></td>
	<td></td>
	<td></td>
	</tr><tr>
	<td></td>
	<td><abbr>SOS</abbr></td>
	<td><i>Sensor Observation Service</i></td>
	<td></td>
	<td></td>
	</tr>
	</table>
	</section>
	</body>
	</html>