From 7218f9657f31e4bc0c8641582212506497618921 Mon Sep 17 00:00:00 2001 From: Gobe Hobona Date: Wed, 11 Oct 2023 19:58:56 +0100 Subject: [PATCH 1/2] move to concept schemes folder --- definitions/conceptschemes/geoxacml3.ttl | 519 +++++++++++++++++++ definitions/conceptschemes/interpolation.ttl | 65 +++ definitions/conceptschemes/standards.ttl | 456 ++++++++++++++++ 3 files changed, 1040 insertions(+) create mode 100644 definitions/conceptschemes/geoxacml3.ttl create mode 100644 definitions/conceptschemes/interpolation.ttl create mode 100644 definitions/conceptschemes/standards.ttl diff --git a/definitions/conceptschemes/geoxacml3.ttl b/definitions/conceptschemes/geoxacml3.ttl new file mode 100644 index 00000000..5ae01a09 --- /dev/null +++ b/definitions/conceptschemes/geoxacml3.ttl @@ -0,0 +1,519 @@ + . + "GeoXACML Identifier Register" . + . + . + "2023-04-20"^^. + "2023-06-04"^^. + "GeoXACML Identifier Register"@en . + . + "GeoXACML Identifier Register" . + . + "2023-04-20"^^. + "2023-06-04"^^. + . + "GeoXACML Identifier Register"@en . + . + "dataType"@en . + "The dataType identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "dataType"@en . + . + . + "geometry"@en . + "The geometry identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "geometry"@en . + . + . + "CRSError"@en . + "The CRSError identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CRSError"@en . + . + . + "GeometryError"@en . + "The GeometryError identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GeometryError"@en . + . + . + "CollectionError"@en . + "The CollectionError identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CollectionError"@en . + . + . + "PrecisionError"@en . + "The PrecisionError identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "PrecisionError"@en . + . + . + "SubjectLocation"@en . + "The SubjectLocation identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "SubjectLocation"@en . + . + . + "ResourceLocation"@en . + "The ResourceLocation identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ResourceLocation"@en . + . + . + "DeviceLocation"@en . + "The DeviceLocation identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "DeviceLocation"@en . + . + . + "ResourceExtend"@en . + "The ResourceExtend identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ResourceExtend"@en . + . + . + "ResourceBBOX"@en . + "The ResourceBBOX identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ResourceBBOX"@en . + . + . + "DIMENSION"@en . + "The DIMENSION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "DIMENSION"@en . + . + . + "GEOMETRY_TYPE"@en . + "The GEOMETRY_TYPE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GEOMETRY_TYPE"@en . + . + . + "SRID"@en . + "The SRID identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "SRID"@en . + . + . + "IS_EMPTY"@en . + "The IS_EMPTY identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "IS_EMPTY"@en . + . + . + "IS_SIMPLE"@en . + "The IS_SIMPLE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "IS_SIMPLE"@en . + . + . + "SRID_EQUALS"@en . + "The SRID_EQUALS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "SRID_EQUALS"@en . + . + . + "ENSURE_SRID"@en . + "The ENSURE_SRID identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ENSURE_SRID"@en . + . + . + "ENSURE_PRECISION"@en . + "The ENSURE_PRECISION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ENSURE_PRECISION"@en . + . + . + "LENGTH"@en . + "The LENGTH identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "LENGTH"@en . + . + . + "AREA"@en . + "The AREA identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "AREA"@en . + . + . + "DISTANCE"@en . + "The DISTANCE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "DISTANCE"@en . + . + . + "HAS_DISTANCE"@en . + "The HAS_DISTANCE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "HAS_DISTANCE"@en . + . + . + "IS_WITHIN_DISTANCE"@en . + "The IS_WITHIN_DISTANCE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "IS_WITHIN_DISTANCE"@en . + . + . + "EQUAL"@en . + "The EQUAL identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "EQUAL"@en . + . + . + "EQUALS"@en . + "The EQUALS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "EQUALS"@en . + . + . + "DISJOINT"@en . + "The DISJOINT identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "DISJOINT"@en . + . + . + "INTERSECTS"@en . + "The INTERSECTS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "INTERSECTS"@en . + . + . + "TOUCHES"@en . + "The TOUCHES identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "TOUCHES"@en . + . + . + "CROSSES"@en . + "The CROSSES identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CROSSES"@en . + . + . + "WITHIN"@en . + "The WITHIN identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "WITHIN"@en . + . + . + "CONTAINS"@en . + "The CONTAINS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CONTAINS"@en . + . + . + "OVERLAPS"@en . + "The OVERLAPS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "OVERLAPS"@en . + . + . + "RELATE"@en . + "The RELATE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "RELATE"@en . + . + . + "GEOMETRY_ONE_AND_ONLY"@en . + "The GEOMETRY_ONE_AND_ONLY identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GEOMETRY_ONE_AND_ONLY"@en . + . + . + "GEOMETRY_BAG_SIZE"@en . + "The GEOMETRY_BAG_SIZE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GEOMETRY_BAG_SIZE"@en . + . + . + "GEOMETRY_IS_IN"@en . + "The GEOMETRY_IS_IN identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GEOMETRY_IS_IN"@en . + . + . + "GEOMETRY_BAG"@en . + "The GEOMETRY_BAG identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GEOMETRY_BAG"@en . + . + . + "GeometryBagToCollection"@en . + "The GeometryBagToCollection identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GeometryBagToCollection"@en . + . + . + "GeometryBagFromCollection"@en . + "The GeometryBagFromCollection identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GeometryBagFromCollection"@en . + . + . + "GeometryBagSRID"@en . + "The GeometryBagSRID identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GeometryBagSRID"@en . + . + . + "GeometryBagSRIDEquals"@en . + "The GeometryBagSRIDEquals identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "GeometryBagSRIDEquals"@en . + . + . + "BAG_AT_LEAST_ONE_MEMBER_OF"@en . + "The BAG_AT_LEAST_ONE_MEMBER_OF identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BAG_AT_LEAST_ONE_MEMBER_OF"@en . + . + . + "BAG_INTERSECTION"@en . + "The BAG_INTERSECTION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BAG_INTERSECTION"@en . + . + . + "BAG_UNION"@en . + "The BAG_UNION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BAG_UNION"@en . + . + . + "BAG_SUBSET"@en . + "The BAG_SUBSET identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BAG_SUBSET"@en . + . + . + "SET_EQUALS"@en . + "The SET_EQUALS identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "SET_EQUALS"@en . + . + . + "ENVELOPE"@en . + "The ENVELOPE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "ENVELOPE"@en . + . + . + "BOUNDARY"@en . + "The BOUNDARY identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BOUNDARY"@en . + . + . + "BUFFER"@en . + "The BUFFER identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "BUFFER"@en . + . + . + "CONVEX_HULL"@en . + "The CONVEX_HULL identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CONVEX_HULL"@en . + . + . + "INTERSECTION"@en . + "The INTERSECTION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "INTERSECTION"@en . + . + . + "UNION"@en . + "The UNION identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "UNION"@en . + . + . + "DIFFERENCE"@en . + "The DIFFERENCE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "DIFFERENCE"@en . + . + . + "SYM_DIFFERNECE"@en . + "The SYM_DIFFERNECE identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "SYM_DIFFERNECE"@en . + . + . + "CENTROID"@en . + "The CENTROID identifier from the GeoXACML 3.0 Standard."@en . + "2023-05-25"^^ . + "2023-05-26"^^ . + . + . + "CENTROID"@en . + . + . diff --git a/definitions/conceptschemes/interpolation.ttl b/definitions/conceptschemes/interpolation.ttl new file mode 100644 index 00000000..59ca69c6 --- /dev/null +++ b/definitions/conceptschemes/interpolation.ttl @@ -0,0 +1,65 @@ + . + . + . + "bicubic interpolation" . + . + "2023-10-11T16:24:36.243418"^^ . + "nearest-neighbor interpolation method" . + . + . + "2023-10-11T16:24:36.243091"^^ . + "2023-10-11T16:24:36.243982"^^ . + . + . + . + . + "nearest-neighbor interpolation" . + . + . + . + . + "cubic interpolation" . + . + "cubic interpolation" . + "linear interpolation" . + "lost area interpolation method" . + "2023-10-11T16:24:36.243553"^^ . + . + . + . + "linear interpolation" . + "Interpolation Method Register" . + "cubic interpolation method" . + "2023-10-11T16:24:36.243276"^^ . + "barycentric interpolation method" . + "linear interpolation method" . + . + "bicubic interpolation" . + . + "quadratic interpolation" . + "Interpolation Method Register" . + . + . + . + "Interpolation Method Register" . + "Interpolation Method Register" . + . + "quadratic interpolation" . + . + . + "bicubic interpolation method" . + "quadratic interpolation method" . + . + . + . + "nearest-neighbor interpolation" . + "2023-10-11T16:24:36.243705"^^ . + "lost area interpolation" . + "lost area interpolation" . + "barycentric interpolation" . + . + "barycentric interpolation" . + "2023-10-11T16:24:36.243843"^^ . + . + . + . diff --git a/definitions/conceptschemes/standards.ttl b/definitions/conceptschemes/standards.ttl new file mode 100644 index 00000000..da1f085c --- /dev/null +++ b/definitions/conceptschemes/standards.ttl @@ -0,0 +1,456 @@ + "This specification applies to the creation and use of documents which unambiguously describe the state, or "@en . + . + "Simple Features OLE/COM"@en . + "Geospatial User Feedback (GUF)" . + . + . + "CDB"@en . + . + "Styled Layer Descriptor"@en . + "2021-10-14T12:27:08.804790"^^ . + . + . + "Sensor Model Language"@en . + "OpenSearch for EO" . + . + . + . + . + . + "OGC API - Processes" . + "SensorThings"@en . + . + "Filter Encoding" . + "GeoSciML"@en . + . + "The LAS file is intended to contain LIDAR (or other) point cloud data records. The data will generally be put into this format from software (e.g. provided by LIDAR hardware vendors) which combines GPS, IMU, and laser pulse range data to produce X, Y, and Z point data. The intention of the data format is to provide an open format that allows different LIDAR hardware and software tools to output data in a common format. "@en . + "This OGC® Standard defines the Augmented Reality Markup Language 2.0 (ARML 2.0). ARML 2.0 allows users to describe virtual objects in an Augmented Reality (AR) scene with their appearances and their anchors (a broader concept of a location) related to the real world. Additionally, ARML 2.0 defines ECMAScript bindings to dynamically modify the AR scene based on user behavior and user input."@en . + "Geospatial eXtensible Access Control Markup Language (GeoXACML)" . + "Open GeoSMS"@en . + "Simple Features SQL" . + "GeoRSS is designed as a lightweight, community driven way to extend existing RSS feeds with simple geographic information. The GeoRSS standard provides for encoding location in an interoperable manner so that applications can request, aggregate, share and map geographically tag feeds. "@en . + "PubSub" . + . + . + "OGC API - Features" . + . + . + "Geospatial User Feedback (GUF)"@en . + "Web Map Tile Service"@en . + . + . + . + "Information Assurance (IA) Controls for OGC Web Services (OWS) have been implemented for years. However, these implementations break interoperability, as they are not standardized by OGC Web Service standards. Interoperability between secured OGC Web Services and clients is limited to systems custom built to work with an IA implementation. The goal of the OWS Common Security Standard is to allow the implementation of IA controls and to advertise their existence in an interoperable way with minimal impact to existing implementations using a backwards-compatible approach. That goal is being pursued in two ways: Identify and document IA Controls for supporting authentication in a register maintained through the OGC. Specify how a service can advertise their IA controls through the Service Capabilities Document. This OGC standard applies to OWS deployed on HTTPS. It specifies how conformant OWS Services shall advertise their IA Controls and additional security features. The advertisement uses XML elements that are already part of the Capabilities document structure. This ensures that existing client implementations will not break. The standard also describes the governance process for the IA Control registers, examples of register contents, and descriptions on how this information should be used. Next, this standard defines conformance classes and requirements classes to be used for reaching compliance and their validation via conformance tests. Finally, this standard defines client behavior to ensure interoperable processing of advertised security controls."@en . + "3D Portrayal Service"@en . + "WaterML"@en . + . + "Publish/Subscribe 1.0 is an interface specification that supports the core components and concepts of the Publish/Subscribe message exchange pattern with OGC Web Services. The Publish/Subscribe pattern complements the Request/Reply pattern specified by many existing OGC Web Services. This specification may be used either in concert with, or independently of, existing OGC Web Services to publish data of interest to interested Subscribers. Publish/Subscribe 1.0 primarily addresses subscription management capabilities such as creating a subscription, renewing a subscription, and unsubscribing. However, this standard also allows Publish/Subscribe services to advertise and describe the supported message delivery protocols such as SOAP messaging, ATOM, and AMQP. Message delivery protocols should be considered to be independent of the Publish/Subscribe 1.0 standard. Therefore, OGC Publish/Subscribe only includes metadata relating to message delivery protocols in sufficient detail to allow for different implementations of Publish/Subscribe 1.0 to interoperate. This specification defines Publish/Subscribe functionality independently of the binding technology (e.g., KVP, SOAP, REST). Extensions to this specification may realize these core concepts with specific binding technologies. "@en . + "IndoorGML"@en . + . + . + . + "The OGC SensorThings API provides an open, geospatial-enabled and unified way to interconnect the Internet of Things (IoT) devices, data, and applications over the Web. At a high level the OGC SensorThings API provides two main functionalities and each function is handled by a part. The two parts are the Sensing part and the Tasking part. The Sensing part provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems. The Tasking part is planned as a future work activity and will be defined in a separate document as the Part II of the SensorThings API. "@en . + . + "This standard describes a conceptual and logical model for the exchange of groundwater data, as well as a GML/XML encoding with examples."@en . + . + . + "The OGC Standards Baseline is the complete set of OGC Member approved Abstract Specifications, Standards including profiles and extensions, and Community Standards."@en . + "2021-10-14T12:27:08.804790"^^ . + "2021-10-14T12:27:08.804790"^^ . + "ARML2.0"@en . + . + . + "2023-10-11T12:27:08.804790"^^ . + . + . + . + . + . + "OGC API - Processes provides a standard interface that simplifies the task of making simple or complex computational geospatial processing services accessible on the Web."@en . + "The purpose of the Open Modelling Interface (OpenMI) is to enable the runtime exchange of data between process simulation models and also between models and other modelling tools such as databases and analytical and visualization applications. Its creation has been driven by the need to understand how processes interact and to predict the likely outcomes of those interactions under given conditions. A key design aim has been to bring about interoperability between independently developed modelling components, where those components may originate from any discipline or supplier. The ultimate aim is to transform integrated modelling into an operational tool accessible to all and so open up the potential opportunities created by integrated modelling for innovation and wealth creation. This document defines the requirements that a component must meet to achieve OpenMI compliance. These comprise: 1) a very thin core set of requirements covering the information and functions needed to establish a link and make an exchange between two components and 2) a set of optional extensions for handling more complex situations. The document does not describe how to implement the standard. This information together with a range of software tools for creating and running OpenMI-­‐compliant components are provided by the OpenMI Association and third-­‐party software vendors – visit www.openmi.org for further documentation."@en . + . + . + "KML" . + . + "A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing the following within a SQLite database: vector features tile matrix sets of imagery and raster maps at various scales extensions To be clear, a GeoPackage is the SQLite container and the GeoPackage Encoding Standard governs the rules and requirements of content stored in a GeoPackage container. The GeoPackage standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. The required and supported content of a GeoPackage is entirely defined in the standard."@en . + "LAS"@en . + . + "OGC API - Records" . + "Sensor Planning Service" . + . + . + "GeoPose" . + . + "OGC API - Common"@en . + . + . + . + . + . + . + . + . + "OGC API - 3D Geovolumes provides API building blocks to create, modify and query 3d-geovolumes on the Web. "@en . + "This jointly developed OGC and ISO TC/211 International Standard describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. These components are modular and intended to be used together or individually by other standards which reference this International Standard."@en . + . + "Web Map Tile Service" . + . + "Moving Features"@en . + . + . + . + . + . + . + "CDB" . + . + . + "OGC API - 3D Geovolumes"@en . + "GeoSciML is a model of geological features commonly described and portrayed in geological maps, cross sections, geological reports and databases. The model was developed by the IUGS CGI (Commission for the Management and Application of Geoscience Information) and version 4.1 is the first version officially submitted as an OGC standard. This specification describes a logical model and GML/XML encoding rules for the exchange of geological map data, geological time scales, boreholes, and metadata for laboratory analyses. It includes a Lite model, used for simple map-based applications; a basic model, aligned on INSPIRE, for basic data exchange; and an extended model to address more complex scenarios. The specification also provides patterns, profiles (most notably of Observations and Measurements - ISO19156), and best practices to deal with common geoscience use cases. "@en . + "The 3D Portrayal Service Standard is a geospatial 3D content delivery implementation specification. It focuses on what is to be delivered in which manner to enable interoperable 3D portrayal. It does not define or endorse particular content transmission formats, but specifies how geospatial 3D content is described, selected, and delivered. It does not prescribe how aforementioned content is to be organized and represented, but provides a framework to determine whether 3D content is interoperable at the content representation level. More details are available in Design of this standard. "@en . + . + "PubSub"@en . + "The CDB standard defines a standardized model and structure for a single, “versionable”, virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB is plug-and-play interoperable between CDB-compliant simulators. A CDB can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time. The application of CDB to future simulation architectures will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines. With the addition of the High Level Architecture - -Federation Object Model (HLA/FOM) and DIS protocols, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment. The CDB standard defines an open format for the storage, access and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. SE allows visualization of and immersion into the environment being simulated . This standard defines the organization and storage structure of a worldwide synthetic representation of the earth as well as the conventions necessary to support all of the subsystems of a full-mission simulator. The standard makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry. A series of associated OGC Best Practice documents define rules and guidelines for data representation of real world features."@en . + "This document describes the mapping of Earth Observation Products – defined in the OGC® GML 3.1.1 Application schema for Earth Observation products [OGC 06-080r4] (version 0.9.3) – to an ebRIM structure within an OGC® Catalogue 2.0.2 (Corrigendum 2 Release) [OGC 07-006r1]"@en . + "NetCDF"@en . + . + "3D Tiles" . + . + "This OGC standard specifies the Geo and Time extensions to the OpenSearch query protocol. OpenSearch is a collection of simple formats for the sharing of search results. The OpenSearch description document format can be used to describe a search engine so that it can be used by search client applications. The OpenSearch description format allows the use of extensions that allow search engines to request a specific and contextual query parameter from search clients. The OpenSearch response elements can be used to extend existing syndication formats, such as RSS and Atom, with the extra metadata needed to return search results. Services that support the OpenSearch Specification, the Geo and Time extensions defined in this document are called OpenSearch GeoTemporal Services. "@en . + "LandInfra/InfraGML"@en . + . + "The OpenGIS® Geography Markup Language Encoding Standard (GML) The Geography Markup Language (GML) is an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. As with most XML based grammars, there are two parts to the grammar – the schema that describes the document and the instance document that contains the actual data. A GML document is described using a GML Schema. This allows users and developers to describe generic geographic data sets that contain points, lines and polygons. However, the developers of GML envision communities working to define community-specific application schemas [en.wikipedia.org/wiki/GML_Application_Schemas] that are specialized extensions of GML. Using application schemas, users can refer to roads, highways, and bridges instead of points, lines and polygons. If everyone in a community agrees to use the same schemas they can exchange data easily and be sure that a road is still a road when they view it. "@en . + . + "The OGC Standards Baseline is the complete set of OGC Member approved Abstract Specifications, Standards including profiles and extensions, and Community Standards."@en . + "Web Service Common"@en . + . + "OGC API - Maps" . + "Symbology Encoding" . + "The OpenGIS® Sensor Planning Service Interface Standard (SPS) defines interfaces for queries that provide information about the capabilities of a sensor and how to task the sensor. The standard is designed to support queries that have the following purposes: to determine the feasibility of a sensor planning request; to submit and reserve/commit such a request; to inquire about the status of such a request; to update or cancel such a request; and to request information about other OGC Web services that provide access to the data collected by the requested task. This is one of the OGC Sensor Web Enablement (SWE) suite of standards. "@en . + "GeoRSS"@en . + . + . + . + "Sensor Planning Service"@en . + . + "This OGC® IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC® GML 3.2.1. While there are several 3D building modelling standards such as CityGML, KML, and IFC, which deal with interior space of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes. 2) Additional Resources - Public Site For more information on IndoorGML including developer resources and information on in-progress work, please visit http://www.indoorgml.net/ . For the official OGC member approved versions of the standard, see the Download information below. "@en . + . + "The OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent so that layers from multiple servers can be combined or not."@en . + . + . + . + "The OGC Open GeoSMS Standard provides developers with an extended Short Message Service (SMS) encoding and interface to facilitate communication of location content between different LBS (Location-Based Service) devices or applications. SMS is the open text communication service standard most commonly used in phone, web and mobile communication systems for the exchange of short text messages between fixed line or mobile phone devices. The lightweight and easy to implement Open GeoSMS Standard facilitates interoperability between mobile applications and the rapidly expanding world of geospatial applications and services that implement OGC standard interfaces, encodings and best practices."@en . + "OGC API - Coverages establishes how to access coverages as defined by the Coverage Implementation Schema (CIS) through a Web API such as those described by the OpenAPI specification."@en . + . + . + "OWS Security" . + . + . + "i3s" . + "TimeseriesML (tsml)"@en . + . + . + "TimeseriesML (tsml)" . + "A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers are designed to be used in mobile, desktop, and server-based workflows and can be accessed over the web or as local files. The delivery format and persistence model for Scene Layers, referred to as Indexed 3d Scene Layer (I3S) and Scene Layer Package (SLPK) respectively, are specified in detail in this OGC Community Standard. Both formats are encoded using JSON and binary ArrayBuffers (ECMAScript 2015). I3S is designed to be cloud, web and mobile friendly. I3S is based on JSON, REST and modern web standards and is easy to handle, efficiently parse and render by Web and Mobile Clients. I3S is designed to stream large 3d datasets and is designed for performance and scalability. I3S is designed to support 3D geospatial content and supports the requisite coordinate reference systems and height models in conjunction with a rich set of layer types. The open community GitHub version of this standard is here: https://github.com/Esri/i3s-spec ."@en . + "GeoAPI" . + "OpenSearch Geo" . + "OWS Context"@en . + . + "This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Standards. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Standard must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses."@en . + "GeoTIFF"@en . + . + . + "GeoSciML" . + . + . + . + . + . + . + . + . + "Styled Layer Descriptor" . + "OGC Standards Baseline"@en . + "This document is the specification for a Table Joining Service (TJS). This OGC standard defines a simple way to describe and exchange tabular data that contains information about geographic objects."@en . + "Simple Features" . + "3D Portrayal Service" . + . + "GeoSPARQL"@en . + . + "Geography Markup Language" . + "LAS" . + "Location Services (OpenLS)"@en . + "OGC API - Styles"@en . + . + . + . + . + . + . + . + "The GeoAPI Implementation Standard defines, through the GeoAPI library, a Java language application programming interface (API) including a set of types and methods which can be used for the manipulation of geographic information structured following the specifications adopted by the Technical Committee 211 of the International Organization for Standardization (ISO) and by the Open Geospatial Consortium (OGC). This standard standardizes the informatics contract between the client code which manipulates normalized data structures of geographic information based on the published API and the library code able both to instantiate and operate on these data structures according to the rules required by the published API and by the ISO and OGC standards. "@en . + "OGC API - Features provides API building blocks to create, modify and query features on the Web. OGC API Features is comprised of multiple parts, each of them is a separate standard. This part, the 'Core', specifies the core capabilities and is restricted to fetching features where geometries are represented in the coordinate reference system WGS 84 with axis order longitude/latitude. "@en . + . + . + "The OpenGIS® Styled Layer Descriptor (SLD) Profile of the OpenGIS® Web Map Service (WMS) Encoding Standard [http://www.ogc.org/standards/wms] defines an encoding that extends the WMS standard to allow user-defined symbolization and coloring of geographic feature[http://www.ogc.org/ogc/glossary/f]"@en . + . + "GeoTIFF" . + . + "The Web Feature Service (WFS) represents a change in the way geographic information is created, modified and exchanged on the Internet. Rather than sharing geographic information at the file level using File Transfer Protocol (FTP), for example, the WFS offers direct fine-grained access to geographic information at the feature and feature property level. This International Standard specifies discovery operations, query operations, locking operations, transaction operations and operations to manage stored, parameterized query expressions. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Query operations allow features or values of feature properties to be retrieved from the underlying data store based upon constraints, defined by the client, on feature properties. Locking operations allow exclusive access to features for the purpose of modifying or deleting features. Transaction operations allow features to be created, changed, replaced and deleted from the underlying data store. Stored query operations allow clients to create, drop, list and described parameterized query expressions that are stored by the server and can be repeatedly invoked using different parameter values. This International Standard defines eleven operations: GetCapabilities (discovery operation), DescribeFeatureType (discovery operation), GetPropertyValue (query operation), GetFeature (query operation), GetFeatureWithLock (query and locking operation), LockFeature (locking operation), Transaction (transaction operation), CreateStoredQuery (stored query operation), DropStoredQuery (stored query operation), ListStoredQueries (stored query operation), DescribeStoredQueries (stored query operation). In the taxonomy of services defined in ISO 19119, the WFS is primarily a feature access service but also includes elements of a feature type service, a coordinate conversion/transformation service and geographic format conversion service."@en . + "The OpenGIS® Coordinate Transformation Service Standard (CT) provides a standard way for software to specify and access coordinate transformation services for use on specified spatial data. This standard addresses a key requirement for overlaying views of geodata (“maps”) from diverse sources: the ability to perform coordinate transformation in such a way that all spatial data are defined relative to the same spatial reference system. "@en . + . + . + "Web Map Context" . + "Sensor Model Language" . + . + . + "A Web Coverage Service (WCS) offers multi-dimensional coverage data for access over the Internet. WCS Core specifies a core set of requirements that a WCS implementation must fulfill."@en . + . + . + "This standard specifies an XML implementation for the OGC and ISO Observations and Measurements conceptual model (OGC Observations and Measurements v2.0 also published as ISO/DIS 19156), including a schema for Sampling Features. This encoding is an essential dependency for the OGC Sensor Observation Service (SOS) Interface Standard. More specifically, this standard defines XML schemas for observations, and for features involved in sampling when making observations. These provide document models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. "@en . + . + . + "The Sensor Web Enablement (SWE) Common Data Model Encoding Standard defines low level data models for exchanging sensor related data between nodes of the OGC® Sensor Web Enablement (SWE) framework. These models allow applications and/or servers to structure, encode and transmit sensor datasets in a self describing and semantically enabled way. SWE Common 1.0 was defined in the OGC SensorML 1.0 Standard available at http://www.ogc.org/standards/sensorml."@en . + "The OGC GeoSPARQL standard supports representing and querying geospatial data on the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data. In addition, GeoSPARQL is designed to accommodate systems based on qualitative spatial reasoning and systems based on quantitative spatial computations."@en . + "This standard consists of the following parts, under the general title Geographic information — Simple feature access, consisting of Part 1: Common architecture, and Part 2: SQL option. This version supersedes all previous versions of OpenGIS® Simple Features Implementation Standard for SQL, including OGC 99-049 "@en . + . + "The primary focus of the Sensor Model Language (SensorML) is to provide a robust and semantically-tied means of defining processes and processing components associated with the measurement and post-measurement transformation of observations. This includes sensors and actuators as well as computational processes applied pre- and postmeasurement. The main objective is to enable interoperability, first at the syntactic level and later at the semantic level (by using ontologies and semantic mediation), so that sensors and processes can be better understood by machines, utilized automatically in complex workflows, and easily shared between intelligent sensor web nodes. This standard is one of several implementation standards produced under OGC’s Sensor Web Enablement (SWE) activity. This standard is a revision of content that was previously integrated in the SensorML version 1.0 standard (OGC 07-000). "@en . + . + "OGC Standards Baseline"@en . + . + . + . + "KML"@en . + . + . + "NetCDF" . + "This standard defines a protocol for RS232 and Ethernet connected instruments. PUCK addresses installation and configuration challenges for sensors by defining a standard instrument protocol to store and automatically retrieve metadata and other information from the instrument device itself. Most sensor networks require careful manual installation and configuration by technicians to assure that software components are properly associated with the physical instruments that they represent. Instrument driver software, configuration files, and metadata describing the instrument and its capabilities must be manually installed and associated with a physical instrument port. Sometimes these manual procedures must be performed under physically challenging conditions, increasing the chances of human error. PUCK addresses these challenges by defining a standard instrument protocol to retrieve metadata and other information from the device itself. This information can include OGC SWE SensorML and IEEE 1451 Transducer Electronic Data Sheet (TEDS) documents, as well as actual instrument driver code. Computers on the network can use the PUCK protocol to retrieve this information from installed instruments and utilize it appropriately, e.g. to automatically identify, configure and operate the instruments. Thus PUCK enables automatic self-configuring plug-and-work sensor networks. The PUCK standard is relatively simple, and several manufacturers have already implemented the protocol in their instruments' firmware. PUCK augments but doesn't replace existing instrument command sets, so it can be implemented without abandoning existing firmware and software applications. PUCK was originally developed by the Monterey Bay Aquarium Research Institute (MBARI) for oceanographic applications, but is useful in any sensor network containing RS232 or Ethernet-connected instruments. PUCK-enabled instruments have been deployed on ocean observatories in the USA and Europe, and the protocol is being considered for adoption by other projects as well. With the approval by the OGC membership of the OGC PUCK Protocol Standard, and with the OGC Technical Committee's PUCK Standards Working Group in place to provide future support, the PUCK standard is expected to be adopted by an even wider sensor community."@en . + "WaterML" . + "netCDF is a set of software libraries and self-describing, machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. The conventions for climate and forecast (CF) metadata are designed to promote the processing and sharing of netCDF files. The conventions define metadata that provide a definitive description of what the data represents, and the spatial and temporal properties of the data. The OGC CF-netCDF standard consists of a suite of standards that support encoding of digital geospatial information representing space/time-varying phenomena. Although it was originally developed for the Earth science community, netCDF can be used to communicate and store a wide variety of multidimensional data. The netCDF data model and encodings are particularly well suited to providing data in forms familiar to atmospheric and oceanic scientists, specifically, as sets of related arrays. The OGC CF-netCDF standards and related documents (primer, best practices, engineering reports, etc.) are accessible from the table below. Additional Extensions to the Core standard may be specified in the future. The CF-netCDF Core and Extensions Primer provides an overview of the many possible components of the CF-netCDF suite and explains how those components fit together into a coherent whole. "@en . + . + . + . + "GeoSPARQL" . + "OGC API - Records provides a way to browse or search a curated collection of Records known as a catalogue."@en . + "Google submitted KML (formerly Keyhole Markup Language) to the Open Geospatial Consortium (OGC) to be evolved within the OGC consensus process with the following goal: KML Version 2.2 has been adopted as an OGC implementation standard. Future versions may be harmonized with relevant OGC standards that comprise the OGC standards baseline. There are four objectives for this standards work: That there be one international standard language for expressing geographic annotation and visualization on existing or future web-based online and mobile maps (2d) and earth browsers (3d). That KML be aligned with international best practices and standards, thereby enabling greater uptake and interoperability of earth browser implementations. That the OGC and Google will work collaboratively to ensure that the KML implementer community is properly engaged in the process and that the KML community is kept informed of progress and issues. That the OGC process will be used to ensure proper life-cycle management of the KML Standard, including such issues as backwards compatibility. "@en . + "OGC API - Environmental Data Retrieval" . + "OWS Context" . + . + "Coordinate Transformation" . + "GeoPose is an OGC Implementation Standard for exchanging the location and orientation of real or virtual geometric objects (Poses) within reference frames anchored to the surface of planet Earth or within other astronomical coordinate systems. "@en . + . + "This OGC® Standard specifies standard encoding representations of movement of geographic features. The primary use case is information exchange."@en . + "The scope of the Land and Infrastructure Conceptual Model is land and civil engineering infrastructure facilities. Anticipated subject areas include facilities, projects, alignment, road, railway, survey, land features, land division, and “wet” infrastructure (storm drainage, wastewater, and water distribution systems). The initial release of this standard is targeted to support all of these except wet infrastructure. Land provides the environment upon which infrastructure facilities exist. This standard includes division of land based on administrative (jurisdictions and districts) as well as interests in land (e.g., land parcels, easements, and condominiums). The standard also includes support for topography (terrain) as well as subsurface information. Finally, this standard regards the surveying needed to locate infrastructure facilities on the terrain in compliance with interests in land. This OGC InfraGML Encoding Standard presents the implementation-dependent, GML encoding of concepts supporting land and civil engineering infrastructure facilities specified in the OGC Land and Infrastructure Conceptual Model Standard (LandInfra), OGC 15-111r1. Conceptual model subject areas include land features, facilities, projects, alignment, road, railway, survey (including equipment, observations, and survey results), land division, and condominiums. InfraGML is published as a multi-part standard. Part 0 addresses the Core Requirements Class from LandInfra. Part 1 addresses the LandFeature Requirements Class from LandInfra. Part 2 addresses the Facility and Project Requirements Classes from LandInfra. Part 3 addresses the Alignment Requirements Class from LandInfra. Part 4 addresses the Road and RoadCrossSection Requirements Classes from LandInfra. Part 5 addresses the Railway Requirements Class from LandInfra. Part 6 addresses the Survey, Equipment, Observations and Survey Results Requirements Classes from LandInfra. Part 7 addresses the Land Division and Condominium Requirements Classes from LandInfra."@en . + . + . + . + . + "The three OpenGIS® Simple Features Implementation Specifications (one each for OLE/COM, CORBA, and SQL) define interfaces that enable transparent access to geographic data held in heterogeneous processing systems on distributed computing platforms. The Simple Feature Specification application programming interfaces (APIs) provide for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point, etc). The purpose of these specifications is to describe interfaces to allow GIS software engineers to develop applications that expose functionality required to access and manipulate geospatial information comprising features with 'simple' geometry using different technologies."@en . + . + "GeoRSS" . + "OGC API - Environmental Data Retrieval"@en . + "OGC API - Tiles" . + "Moving Features" . + . + . + . + . + "The OpenGIS® Open Location Services Interface Standard (OpenLS) specifies interfaces that enable companies in the Location Based Services (LBS) value chain to “hook up” and provide their pieces of applications such as emergency response (E-911, for example), personal navigator, traffic information service, proximity service, location recall, mobile field service, travel directions, restaurant finder, corporate asset locator, concierge, routing, vector map portrayal and interaction, friend finder, and geography voice-graphics. These applications are enabled by interfaces that implement OpenLS services such as a Directory Service, Gateway Service, Geocoder Service, Presentation (Map Portrayal) Service and others."@en . + . + . + "This Specification defines Symbology Encoding, an XML language for styling information that can be applied to digital Feature and Coverage data. This document is together with the Styled Layer Descriptor Profile for the Web Map Service Implementation Specification the direct follow-up of Styled Layer Descriptor Implementation Specification 1.0.0. The old specification document was split up into two documents to allow the parts that are not specific to WMS to be reused by other service specifications."@en . + "The purpose of the OGC API - Common Standard is to define those fundamental building blocks and requirements which are applicable to all OGC Web API Standards."@en . + "3D Tiles"@en . + "OWS Security"@en . + . + . + . + . + . + . + . + "This part of OpenGIS® Simple Features Access (SFA), also called ISO 19125, describes the common architecture for simple feature geometry. The simple feature geometry object model is Distributed Computing Platform neutral and uses UML notation. The base Geometry class has subclasses for Point, Curve, Surface and GeometryCollection. Each geometric object is associated with a Spatial Reference System, which describes the coordinate space in which the geometric object is defined."@en . + "OGC API - Processes"@en . + . + . + "OGC API - Styles provides API building blocks to create, modify and query styles on the Web. "@en . + . + "Simple Features OLE/COM" . + . + . + "The SOS standard is applicable to use cases in which sensor data needs to be managed in an interoperable way. This standard defines a Web service interface which allows querying observations, sensor metadata, as well as representations of observed features. Further, this standard defines means to register new sensors and to remove existing ones. Also, it defines operations to insert new sensor observations. This standard defines this functionality in a binding independent way; two bindings are specified in this document: a KVP binding and a SOAP binding."@en . + . + "PUCK"@en . + . + . + . + "OGC API - Tiles describes an API building block that can enable other OGC API implementations to serve map tiles or tiled feature data divided into individual tiles."@en . + . + "OGC Standards Baseline" . + "GeoPackage" . + . + . + "3D Tiles is designed for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds. It defines a hierarchical data structure and a set of tile formats which deliver renderable content. 3D Tiles does not define explicit rules for visualization of the content; a client may visualize 3D Tiles data however it sees fit. A 3D Tiles data set, called a tileset, contains any combination of tile formats organized into a spatial data structure. 3D Tiles are declarative, extendable, and applicable to various types of 3D data. The following tile formats have been specified as part of this document: Batched 3D Model, Instanced 3D Model, Point Cloud, and Composite. This document also describes 3D Tile Styles, a declarative styling specification which may be applied to tilesets. The 3D Tiles specification for tilesets, associated tile formats, and the associated styling specification are open formats that are not dependent on any vendor-specific solution, technology, or products. The majority of the content in this OGC document is a direct copy of the content contained at"@en . + . + "GeoPackage"@en . + "WKT CRS" . + . + "SWE Common Data Model" . + . + "2021-10-14T12:27:08.804790"^^ . + "OpenSearch Geo"@en . + . + "Coordinate Transformation"@en . + . + . + . + . + . + "OGC Standards Baseline" . + "The Policy Language introduced in this document defines a geo-specific extension to the XACML Policy Language, as defined by the OASIS standard “eXtensible Access Control Markup Language (XACML), Version 2.0” [1]. Due to the similarity of XACML version 2.0 to it’s predecessor versions (e.g. 1.0 or 1.1), the extension described in this document also represents a valid extension for earlier XACML versions. As being an extension to OASIS eXtensible Access Control Markup Language (XACML), GeoXACML provides support for spatial data types and spatial authorization decision functions. Those data types and functions can be used to define additional spatial constraints for XACML based policies."@en . + . + . + . + . + "WaterML 2.0 is a standard information model for the representation of water observations data, with the intent of allowing the exchange of such data sets across information systems. Through the use of existing OGC standards, it aims at being an interoperable exchange format that may be re-used to address a range of exchange requirements, some of which are described later in this document. "@en . + "SWE Service Model" . + . + "This Standard provides an updated version of WKT representation of coordinate reference systems that follows the provisions of ISO 19111:2007 and ISO 19111-2:2009. It extends the earlier WKT to allow for the description of coordinate operations. This International Standard defines the structure and content of well-known text strings. It does not prescribe how implementations should read or write these strings. The jointly developed draft has also been submitted by ISO TC211 for publication as an International Standard document. The version incorporates comments made during both the OGC Public Comment Period as well as the ISO ballot for DIS (ISO TC211 document N3750). "@en . + . + "Web Map Context"@en . + . + . + "OGC API - Coverages" . + . + "Table Joining Service"@en . + . + "GroundwaterML"@en . + . + . + "Web Coverage Processing Service" . + . + "GeoAPI"@en . + "IndoorGML" . + "2020-02-16T12:27:08.804790"^^ . + . + "CityGML" . + . + "TimeseriesML 1.0 defines an XML encoding that implements the OGC Timeseries Profile of Observations and Measurements [OGC 15-043r3], with the intent of allowing the exchange of such data sets across information systems. Through the use of existing OGC standards, it aims at being an interoperable exchange format that may be re-used to address a range of data exchange requirements. "@en . + . + . + "Catalogue services support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent resource characteristics that can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community. OGC Catalogue interface standards specify the interfaces, bindings, and a framework for defining application profiles required to publish and access digital catalogues of metadata for geospatial data, services, and related resource information. Metadata act as generalised properties that can be queried and returned through catalogue services for resource evaluation and, in many cases, invocation or retrieval of the referenced resource. Catalogue services support the use of one of several identified query languages to find and return results using well-known content models (metadata schemas) and encodings. "@en . + "This standard defines a conceptual Geospatial User Feedback (GUF) data model (OGC 15-097) and a practical XML encoding of the conceptual model (OGC 15-098). Geospatial User Feedback is metadata that is predominantly produced by the consumers of geospatial data products as they use and gain experience with those products. The standard allows for documenting feedback items such as ratings, comments, quality reports, citations, significant events, etc. about the usage of the data. Feedback items can be aggregated in collections and summaries of the collections can also be described. This standard complements existing metadata conventions whereby documents recording dataset characteristics and production workflows are generated by the creator, publisher, or curator of a data product. As a part of metadata, the GUF data model reuses some elements of ISO 19115-1:2014 (the updated version of the OGC Abstract Specification Topic 11) but not the general structure. This selective use of ISO metadata elements prioritizes interoperability with developing ISO metadata models. The conceptual encoding is designed to be used combination with an encoding standard. Initially an XML encoding following the ISO 19139 encoding rules is specified in a separate OGC implementation standard (OGC 15-098). In the future other encodings may be defined, including examples such as the use of JSON-LD based on parts of"@en . + . + "The GeoTIFF format was initially developed during the early 1990’s (N. Ritter "@en . + . + "This document is the specification for the OpenSearch extension for Earth Observation collections and products search. This standard is intended to provide a very simple way to make queries to a repository that contains Earth Observation information and to allow syndication of repositories. "@en . + "The OpenGIS® Web Processing Service (WPS) Interface Standard provides rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services, such as polygon overlay. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server."@en . + . + "ARML2.0" . + "2021-10-14T12:27:08.804790"^^ . + "The three OpenGIS® Simple Features Implementation Specifications (one each for OLE/COM, CORBA, and SQL) define interfaces that enable transparent access to geographic data held in heterogeneous processing systems on distributed computing platforms. The Simple Feature Specification application programming interfaces (APIs) provide for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point, etc). The purpose of these specifications is to describe interfaces to allow GIS software engineers to develop applications that expose functionality required to access and manipulate geospatial information comprising features with 'simple' geometry using different technologies. "@en . + . + . + "Filter Encoding"@en . + "OGC API - Styles" . + "Geography Markup Language"@en . + . + . + "Simple Features SQL"@en . + . + . + . + . + . + "OpenSearch for EO"@en . + "The OGC® Web Coverage Processing Service (WCPS) defines a protocol-independent language for the extraction, processing, and analysis of multi-dimensional coverages representing sensor, image, or statistics data."@en . + . + . + "This document defines an OGC standard for a Web Map Tile Service (WMTS) interface standard. A WMTS enabled server application can serve map tiles of spatially referenced data using tile images with predefined content, extent, and resolution."@en . + . + . + "2021-10-14T12:27:08.804790"^^ . + "CityGML"@en . + "Table Joining Service" . + . + "LandInfra/InfraGML" . + . + "SWE Service Model"@en . + "Location Services (OpenLS)" . + "OGC API - 3D Geovolumes" . + . + . + "CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is an application schema for the Geography Markup Language version 3.1.1 (GML3), the extendible international standard for spatial data exchange issued by the Open Geospatial Consortium (OGC) and the ISO TC211. The aim of the development of CityGML is to reach a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields. "@en . + "2021-10-14T12:27:08.804790"^^ . + "SWE Common Data Model"@en . + . + . + . + . + "Web Coverage Processing Service"@en . + . + . + "Simple Features"@en . + "OpenMI"@en . + "Symbology Encoding"@en . + . + "OpenMI" . + . + . + . + "OGC API - Maps describes an API that can serve spatially referenced and dynamically rendered electronic maps."@en . + "OGC API - Maps"@en . + . + . + . + "Open GeoSMS" . + "Web Service Common" . + . + . + . + "This OGC® standard specifies the interfaces, bindings, requirements, conformance classes, and a framework for implementing extensions that enable complete workflows for ordering of Earth Observation (EO) data products. "@en . + "This standard describes the use cases, requirements and conceptual model for the OWS Context encoding standard. The goal of this standard is to provide a core model, which is extended and encoded as defined in extensions to this standard. A ‘context document’ specifies a fully configured service set which can be exchanged (with a consistent interpretation) among clients supporting the standard. The OGC Web Services Context Document (OWS Context) was created to allow a set of configured information resources (service set) to be passed between applications primarily as a collection of services. OWS Context is developed to support in-line content as well. The goal is to support use cases such as the distribution of search results, the exchange of a set of resources such as OGC Web Feature Service (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Coverage Service (WCS) and others in a ‘common operating picture’. Additionally OWS Context can deliver a set of configured processing services (Web Processing Service (WPS)) parameters to allow the processing to be reproduced on different nodes."@en . + "OGC API - Environmental Data Retrieval provides a family of lightweight interfaces to access Environmental Data resources. Each resource addressed by this standard maps to a defined query pattern."@en . + . + "This standard currently defines eight packages with data types for common use across OGC Sensor Web Enablement (SWE) services. Five of these packages define operation request and response types. The packages are: 1.) Contents – Defines data types that can be used in specific services that provide (access to) sensors; 2.) Notification – Defines the data types that support provision of metadata about the notification capabilities of a service as well as the definition and encoding of SWES events; 3.) Common - Defines data types common to other packages; 4.) Common Codes –Defines commonly used lists of codes with special semantics; 5.) DescribeSensor – Defines the request and response types of an operation used to retrieve metadata about a given sensor; 6.) UpdateSensorDescription –Defines the request and response types of an operation used to modify the description of a given sensor; 7.) InsertSensor – Defines the request and response types of an operation used to insert a new sensor instance at a service; 8.) DeleteSensor – Defines the request and response types of an operation used to remove a sensor from a service. These packages use data types specified in other standards. Those data types are normatively referenced herein, instead of being repeated in this standard."@en . + . + . + "GeoPose"@en . + "OGC API - Coverages"@en . + . + . + . + "OGC API - Common" . + . + "Simple Features CORBA" . + . + "GroundwaterML" . + "PUCK" . + "i3s"@en . + "WKT CRS"@en . + . + "OGC API - Records"@en . + . + "GML in JPEG 2000"@en . + "2023-10-11T12:27:08.804790"^^ . + . + . + . + . + . + . + "Geospatial eXtensible Access Control Markup Language (GeoXACML)"@en . + "The OpenGIS® GML in JPEG 2000 for Geographic Imagery Encoding Standard defines the means by which the OpenGIS® Geography Markup Language (GML) Standard http://www.ogc.org/standards/gml is used within JPEG 2000 http://www.jpeg.org/jpeg2000/ images for geographic imagery. The standard also provides packaging mechanisms for including GML within JPEG 2000 data files and specific GML application schemas to support the encoding of images within JPEG 2000 data files. JPEG 2000 is a wavelet-based image compression standard that provides the ability to include XML data for description of the image within the JPEG 2000 data file. "@en . + . + . + "GML in JPEG 2000" . + . + "OGC API - Features"@en . + . + "SensorThings" . + "Simple Features CORBA"@en . + . + . + "OGC API - Tiles"@en . + . + . From 80c9a4e5558137c4dd43b5bb7d401ed5db40ea01 Mon Sep 17 00:00:00 2001 From: Gobe Hobona Date: Wed, 11 Oct 2023 19:59:55 +0100 Subject: [PATCH 2/2] moved folders to source archive --- incubation/{ => SourceArchive}/geoxacml3/geoxacml3.csv | 0 incubation/{ => SourceArchive}/geoxacml3/geoxacml3.ttl | 0 incubation/{ => SourceArchive}/geoxacml3/process.py | 0 incubation/{ => SourceArchive}/interpolation/interpolation.csv | 0 incubation/{ => SourceArchive}/interpolation/interpolation.ttl | 0 incubation/{ => SourceArchive}/interpolation/process.py | 0 incubation/{ => SourceArchive}/standards-baseline/README.txt | 0 incubation/{ => SourceArchive}/standards-baseline/process.py | 0 incubation/{ => SourceArchive}/standards-baseline/standards.ttl | 0 .../standards-baseline/standards_input copy.ttl | 0 .../{ => SourceArchive}/standards-baseline/standards_input.ttl | 0 incubation/{ => SourceArchive}/standards-baseline/test.txt | 0 12 files changed, 0 insertions(+), 0 deletions(-) rename incubation/{ => SourceArchive}/geoxacml3/geoxacml3.csv (100%) rename incubation/{ => SourceArchive}/geoxacml3/geoxacml3.ttl (100%) rename incubation/{ => SourceArchive}/geoxacml3/process.py (100%) rename incubation/{ => SourceArchive}/interpolation/interpolation.csv (100%) rename incubation/{ => SourceArchive}/interpolation/interpolation.ttl (100%) rename incubation/{ => SourceArchive}/interpolation/process.py (100%) rename incubation/{ => SourceArchive}/standards-baseline/README.txt (100%) rename incubation/{ => SourceArchive}/standards-baseline/process.py (100%) rename incubation/{ => SourceArchive}/standards-baseline/standards.ttl (100%) rename incubation/{ => SourceArchive}/standards-baseline/standards_input copy.ttl (100%) rename incubation/{ => SourceArchive}/standards-baseline/standards_input.ttl (100%) rename incubation/{ => SourceArchive}/standards-baseline/test.txt (100%) diff --git a/incubation/geoxacml3/geoxacml3.csv b/incubation/SourceArchive/geoxacml3/geoxacml3.csv similarity index 100% rename from incubation/geoxacml3/geoxacml3.csv rename to incubation/SourceArchive/geoxacml3/geoxacml3.csv diff --git a/incubation/geoxacml3/geoxacml3.ttl b/incubation/SourceArchive/geoxacml3/geoxacml3.ttl similarity index 100% rename from incubation/geoxacml3/geoxacml3.ttl rename to incubation/SourceArchive/geoxacml3/geoxacml3.ttl diff --git a/incubation/geoxacml3/process.py b/incubation/SourceArchive/geoxacml3/process.py similarity index 100% rename from incubation/geoxacml3/process.py rename to incubation/SourceArchive/geoxacml3/process.py diff --git a/incubation/interpolation/interpolation.csv b/incubation/SourceArchive/interpolation/interpolation.csv similarity index 100% rename from incubation/interpolation/interpolation.csv rename to incubation/SourceArchive/interpolation/interpolation.csv diff --git a/incubation/interpolation/interpolation.ttl b/incubation/SourceArchive/interpolation/interpolation.ttl similarity index 100% rename from incubation/interpolation/interpolation.ttl rename to incubation/SourceArchive/interpolation/interpolation.ttl diff --git a/incubation/interpolation/process.py b/incubation/SourceArchive/interpolation/process.py similarity index 100% rename from incubation/interpolation/process.py rename to incubation/SourceArchive/interpolation/process.py diff --git a/incubation/standards-baseline/README.txt b/incubation/SourceArchive/standards-baseline/README.txt similarity index 100% rename from incubation/standards-baseline/README.txt rename to incubation/SourceArchive/standards-baseline/README.txt diff --git a/incubation/standards-baseline/process.py b/incubation/SourceArchive/standards-baseline/process.py similarity index 100% rename from incubation/standards-baseline/process.py rename to incubation/SourceArchive/standards-baseline/process.py diff --git a/incubation/standards-baseline/standards.ttl b/incubation/SourceArchive/standards-baseline/standards.ttl similarity index 100% rename from incubation/standards-baseline/standards.ttl rename to incubation/SourceArchive/standards-baseline/standards.ttl diff --git a/incubation/standards-baseline/standards_input copy.ttl b/incubation/SourceArchive/standards-baseline/standards_input copy.ttl similarity index 100% rename from incubation/standards-baseline/standards_input copy.ttl rename to incubation/SourceArchive/standards-baseline/standards_input copy.ttl diff --git a/incubation/standards-baseline/standards_input.ttl b/incubation/SourceArchive/standards-baseline/standards_input.ttl similarity index 100% rename from incubation/standards-baseline/standards_input.ttl rename to incubation/SourceArchive/standards-baseline/standards_input.ttl diff --git a/incubation/standards-baseline/test.txt b/incubation/SourceArchive/standards-baseline/test.txt similarity index 100% rename from incubation/standards-baseline/test.txt rename to incubation/SourceArchive/standards-baseline/test.txt