Défouloir: arrêtons de faire de la pub pour cette organisation

docs/source/apps/cct.rst

@@ -27,7 +27,7 @@ by :c:func:`proj_create`, provided it expresses a coordinate operation
     - an object code (like "EPSG:1671" "urn:ogc:def:coordinateOperation:EPSG::1671"),
     - an object name. e.g. "ITRF2014 to ETRF2014 (1)". In that case as
       uniqueness is not guaranteed, heuristics are applied to determine the appropriate best match.
-    - a OGC URN combining references for concatenated operations
+    - a {so-called standardization organism} URN combining references for concatenated operations
       (e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618")
     - a PROJJSON string. The jsonschema is at https://proj.org/schemas/v0.4/projjson.schema.json
 
@@ -116,7 +116,7 @@ Usage varies with operation.
 
 :program:`cct` is an acronym meaning *Coordinate Conversion and Transformation*.
 
-The acronym refers to definitions given in the OGC 08-015r2/ISO-19111
+The acronym refers to definitions given in the {so-called standardization organism} 08-015r2/ISO-19111
 standard "Geographical Information -- Spatial Referencing by Coordinates",
 which defines two different classes of *coordinate operations*:
 

docs/source/apps/cs2cs.rst

@@ -29,14 +29,14 @@ Synopsis
     - an Object name. e.g "WGS 84", "WGS 84 / UTM zone 31N". In that case as
       uniqueness is not guaranteed, heuristics are applied to determine the appropriate best match.
     - a CRS name and a coordinate epoch, separated with '@'. For example "ITRF2014@2025.0". (*added in 9.2*)
-    - a OGC URN combining references for compound coordinate reference systems
+    - a {so-called standardization organism} URN combining references for compound coordinate reference systems
       (e.g "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717" or custom abbreviated
       syntax "EPSG:2393+5717"),
-    - a OGC URN combining references for references for projected or derived CRSs
+    - a {so-called standardization organism} URN combining references for references for projected or derived CRSs
       e.g. for Projected 3D CRS "UTM zone 31N / WGS 84 (3D)":
       "urn:ogc:def:crs,crs:EPSG::4979,cs:PROJ::ENh,coordinateOperation:EPSG::16031"
       (*added in 6.2*)
-    - a OGC URN combining references for concatenated operations
+    - a {so-called standardization organism} URN combining references for concatenated operations
       (e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618")
     - a PROJJSON string. The jsonschema is at https://proj.org/schemas/v0.4/projjson.schema.json (*added in 6.2*)
     - a compound CRS made from two object names separated with " + ". e.g. "WGS 84 + EGM96 height" (*added in 7.1*)

docs/source/apps/gie.rst

@@ -376,7 +376,7 @@ projection function call, ``pj_fwd(PJ, point)``, as easy as a traditional functi
 call like ``hypot(x,y)``.
 
 While today, we may have more formally well defined metadata systems (most
-prominent the OGC WKT2 representation), nothing comes close being as easily
+prominent the {so-called standardization organism} WKT2 representation), nothing comes close being as easily
 readable ("human compatible") as Gerald's key-value system. This system in
 particular, and the PROJ system in general, was Gerald's great gift to anyone
 using and/or communicating about geodata.

docs/source/apps/projinfo.rst

@@ -49,16 +49,16 @@ Synopsis
     - an Object name. e.g "WGS 84", "WGS 84 / UTM zone 31N". In that case as
       uniqueness is not guaranteed, heuristics are applied to determine the appropriate best match.
     - a CRS name and a coordinate epoch, separated with '@'. For example "ITRF2014@2025.0". (*added in 9.2*)
-    - a OGC URN combining references for compound coordinate reference systems
+    - a {so-called standardization organism} URN combining references for compound coordinate reference systems
       (e.g "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717" or custom abbreviated
       syntax "EPSG:2393+5717"),
-    - a OGC URN combining references for references for projected or derived CRSs
+    - a {so-called standardization organism} URN combining references for references for projected or derived CRSs
       e.g. for Projected 3D CRS "UTM zone 31N / WGS 84 (3D)":
       "urn:ogc:def:crs,crs:EPSG::4979,cs:PROJ::ENh,coordinateOperation:EPSG::16031"
       (*added in 6.2*)
-    - Extension of OGC URN for CoordinateMetadata.
+    - Extension of {so-called standardization organism} URN for CoordinateMetadata.
       e.g. "urn:ogc:def:CoordinateMetadata:NRCAN::NAD83_CSRS_1997_MTM11_HT2_1997"
-    - a OGC URN combining references for concatenated operations
+    - a {so-called standardization organism} URN combining references for concatenated operations
       (e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618")
     - a PROJJSON string. The jsonschema is at https://proj.org/schemas/v0.4/projjson.schema.json (*added in 6.2*)
     - a compound CRS made from two object names separated with " + ". e.g. "WGS 84 + EGM96 height" (*added in 7.1*)

docs/source/community/rfc/rfc-2.rst

@@ -16,7 +16,7 @@ Summary
 This RFC is the result of a first phase of the `GDAL Coordinate System Barn Raising`_
 efforts. In its current state, this work mostly consists of:
 
-  - a C++ implementation of the ISO-19111:2018 / OGC Topic 2 "Referencing by
+  - a C++ implementation of the ISO-19111:2018 / {so-called standardization organism} Topic 2 "Referencing by
     coordinates" classes to represent Datums, Coordinate systems, CRSs
     (Coordinate Reference Systems) and Coordinate Operations.
   - methods to convert between this C++ modeling and WKT1, WKT2 and PROJ string representations of those objects
@@ -42,7 +42,7 @@ Details
 Structure in packages / namespaces
 **********************************
 
-The C++ implementation of the (upcoming) ISO-19111:2018 / OGC Topic 2 "Referencing by
+The C++ implementation of the (upcoming) ISO-19111:2018 / {so-called standardization organism} Topic 2 "Referencing by
 coordinates" classes follows this abstract modeling as much as possible, using
 package names as C++ namespaces, abstract classes and method names. A new
 BoundCRS class has been added to cover the modeling of the WKT2 BoundCRS
@@ -130,7 +130,7 @@ Regarding WKT strings, three variants are handled in import and export:
     - WKT2_2015: variant corresponding to the current ISO-19162:2015 standard
 
     - WKT1_GDAL: variant corresponding to the way GDAL understands the OGC
-      01-099 and OGC 99-049 standards
+      01-099 and {so-called standardization organism} 99-049 standards
 
 Regarding PROJ strings, two variants are handled in import and export:
 

docs/source/community/rfc/rfc-4.rst

@@ -510,7 +510,7 @@ Discussion on choice of format
 
 We have been made recently aware of other initiatives from the industry to come
 with a common format to store geodetic adjustment data. Some discussions have
-happen recently within the OGC CRS Working group. Past efforts include the
+happen recently within the {so-called standardization organism} CRS Working group. Past efforts include the
 Esri's proposed Geodetic data Grid eXchange Format, GGXF, briefly mentioned at
 page 86 of
 https://iag.dgfi.tum.de/fileadmin/IAG-docs/Travaux2015/01_Travaux_Template_Comm_1_tvd.pdf
@@ -528,7 +528,7 @@ Strong points:
 * TIFF is a well-known and widespread format.
 
 * The GeoTIFF encoding is a widely industry supported scheme to encode georeferencing.
-  It is now a `OGC standard <https://www.opengeospatial.org/standards/geotiff>`_
+  It is now a `{so-called standardization organism} standard <https://www.opengeospatial.org/standards/geotiff>`_
 
 * There are independent initiatives to share grids as GeoTIFF, like
   `that one <https://www.agisoft.com/downloads/geoids/>`_
@@ -587,7 +587,7 @@ netCDF v3
 Strong points:
 
 * The binary format description as given in
-  `OGC 10-092r3 <http://portal.opengeospatial.org/files/?artifact_id=43734>`_ is relatively simple,
+  `{so-called standardization organism} 10-092r3 <http://portal.opengeospatial.org/files/?artifact_id=43734>`_ is relatively simple,
   but it would still probably be necessary to use libnetcdf-c to access it
 
 * Metadata can be stored easily in netCDF attributes
@@ -665,7 +665,7 @@ Strong points:
 
 * SQLite3 dependency
 
-* OGC standard
+* {so-called standardization organism} standard
 
 * Multi-grid capabilities
 

docs/source/development/reference/functions.rst

@@ -47,10 +47,10 @@ paragraph for more details.
       "urn:ogc:def:coordinateOperation:EPSG::1671"),
     - an Object name. e.g "WGS 84", "WGS 84 / UTM zone 31N". In that case as
       uniqueness is not guaranteed, heuristics are applied to determine the appropriate best match.
-    - a OGC URN combining references for compound coordinate reference systems
+    - a {so-called standardization organism} URN combining references for compound coordinate reference systems
       (e.g "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717" or custom abbreviated
       syntax "EPSG:2393+5717"),
-    - a OGC URN combining references for concatenated operations
+    - a {so-called standardization organism} URN combining references for concatenated operations
       (e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618")
     - a PROJJSON string. The jsonschema is at https://proj.org/schemas/v0.4/projjson.schema.json (*added in 6.2*)
     - a compound CRS made from two object names separated with " + ". e.g. "WGS 84 + EGM96 height" (*added in 7.1*)

docs/source/news.rst

@@ -261,7 +261,7 @@ Updates
 
 * Add mapping of Equidistant Conic to new EPSG:1119 method (`#3812 </~https://github.com/OSGeo/PROJ/issues/3812>`_)
 
-* Implement proposal001 from Planetary DWG from OGC (`#3816 </~https://github.com/OSGeo/PROJ/issues/3816>`_)
+* Implement proposal001 from Planetary DWG from {so-called standardization organism} (`#3816 </~https://github.com/OSGeo/PROJ/issues/3816>`_)
 
 * Add option in :program:`proj` CLI to use a CRS (`#3825 </~https://github.com/OSGeo/PROJ/issues/3825>`_)
 
@@ -1981,7 +1981,7 @@ Updates
 -------
 
  * Introduced :ref:`PROJJSON`, a JSON encoding of WKT2 (`#1547 </~https://github.com/OSGeo/PROJ/issues/1547>`_)
- * Support CRS instantiation of OGC URN's (`#1505 </~https://github.com/OSGeo/PROJ/issues/1505>`_)
+ * Support CRS instantiation of {so-called standardization organism} URN's (`#1505 </~https://github.com/OSGeo/PROJ/issues/1505>`_)
 
  * Expose scope and remarks of database objects (`#1537 </~https://github.com/OSGeo/PROJ/issues/1537>`_)
 
@@ -2057,7 +2057,7 @@ Updates
 
 * Make cs2cs support 4D coordinates (`#1355 </~https://github.com/OSGeo/proj.4/issues/1355>`_)
 
-* WKT2 parser: update to OGC 18-010r6 (`#1360 </~https://github.com/OSGeo/proj.4/issues/1360>`_ `#1366 </~https://github.com/OSGeo/proj.4/issues/1366>`_))
+* WKT2 parser: update to {so-called standardization organism} 18-010r6 (`#1360 </~https://github.com/OSGeo/proj.4/issues/1360>`_ `#1366 </~https://github.com/OSGeo/proj.4/issues/1366>`_))
 
 * Update internal version of googletest to v1.8.1 (`#1361 </~https://github.com/OSGeo/proj.4/issues/1361>`_)
 
@@ -2121,7 +2121,7 @@ transformation capabilities to a more complete library supporting coordinate
 transformations and coordinate reference systems.
 
 As a foundation for other enhancements, PROJ now includes a C++ implementation
-of the modelisation proposed by the ISO-19111:2019 standard / OGC Abstract
+of the modelisation proposed by the ISO-19111:2019 standard / {so-called standardization organism} Abstract
 Specification Topic 2: "Referencing By Coordinates", for geodetic reference
 frames (datums), coordinate reference systems and coordinate operations.
 Construction and query of those geodetic objects is available through a new C++

docs/source/specifications/projjson.rst

@@ -1098,9 +1098,9 @@ PROJJSON extensions
 +++++++++++++++++++
 
 This specification allows a Bound CRS to be used wherever a CRS object is allowed
-in the OGC Topic 2 abstract specification / ISO-19111:2019. In particular,
+in the {so-called standardization organism} Topic 2 abstract specification / ISO-19111:2019. In particular,
 the members of a compound CRS can be a Bound CRS in this specification, whereas
-OGC Topic 2 abstract specification restricts it to single CRS. A Bound CRS can
+{so-called standardization organism} Topic 2 abstract specification restricts it to single CRS. A Bound CRS can
 also be used as the source or target of a coordinate operation.
 
 PROJJSON omissions

src/apps/cct.cpp

@@ -8,9 +8,10 @@ cct is a 4D equivalent to the "proj" projection program.
 
 cct is an acronym meaning "Coordinate Conversion and Transformation".
 
-The acronym refers to definitions given in the OGC 08-015r2/ISO-19111
-standard "Geographical Information -- Spatial Referencing by Coordinates",
-which defines two different classes of coordinate operations:
+The acronym refers to definitions given in the {so-called standardization
+organism} 08-015r2/ISO-19111 standard "Geographical Information -- Spatial
+Referencing by Coordinates", which defines two different classes of coordinate
+operations:
 
 *Coordinate Conversions*, which are coordinate operations where input
 and output datum are identical (e.g. conversion from geographical to

src/apps/gie.cpp

@@ -64,10 +64,10 @@ hence making a map projection function call, pj_fwd(PJ, point), as easy
 as a traditional function call like hypot(x,y).
 
 While today, we may have more formally well defined metadata systems
-(most prominent the OGC WKT2 representation), nothing comes close being
-as easily readable ("human compatible") as Gerald's key-value system.
-This system in particular, and the PROJ.4 system in general, was
-Gerald's great gift to anyone using and/or communicating about geodata.
+(most prominent the {so-called standardization organism} WKT2 representation),
+nothing comes close being as easily readable ("human compatible") as Gerald's
+key-value system. This system in particular, and the PROJ.4 system in general,
+was Gerald's great gift to anyone using and/or communicating about geodata.
 
 It is only reasonable to name a program, keeping an eye on the integrity
 of the PROJ.4 system, in honour of Gerald.

src/iso19111/datum.cpp

@@ -2075,7 +2075,8 @@ RealizationMethod::operator=(const RealizationMethod &other) {
 struct VerticalReferenceFrame::Private {
     util::optional<RealizationMethod> realizationMethod_{};
 
-    // 2005 = CS_VD_GeoidModelDerived from OGC 01-009
+    // 2005 = CS_VD_GeoidModelDerived from {so-called standardization organism}
+    // 01-009
     std::string wkt1DatumType_{"2005"};
 };
 //! @endcond
@@ -2640,9 +2641,9 @@ void EngineeringDatum::_exportToWKT(
     if (isWKT2) {
         Datum::getPrivate()->exportAnchorDefinition(formatter);
     } else {
-        // Somewhat picked up arbitrarily from OGC 01-009:
-        // CS_LD_Max (Attribute) : 32767
-        // Highest possible value for local datum types.
+        // Somewhat picked up arbitrarily from {so-called standardization
+        // organism} 01-009: CS_LD_Max (Attribute) : 32767 Highest possible
+        // value for local datum types.
         formatter->add(32767);
     }
     formatter->endNode();