Open Geospatial Consortium |
Submission Date: 2018-07-05 |
Approval Date: 2018-09-05 |
Publication Date: 2019-10-31 |
External identifier of this OGC® document: http://www.opengis.net/doc/POL-NTS/Sensor/1.0 |
Internal reference number of this OGC® document: 18-042r4 |
Version: 1.0 |
Category: OGC® Policy |
Editor: Gobe Hobona, Simon Cox |
OGC Name Type Specification - Sensor Models and Parameters |
Copyright notice |
Copyright © 2019 Open Geospatial Consortium |
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/ |
Warning |
This document defines an OGC Policy. It is subject to change without notice. This document is an official position of the OGC membership on this particular topic.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Document type: OGC® Policy |
Document subtype: Name Type Spec |
Document stage: Approved |
Document language: English |
License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
i. Abstract
A wide variety of sensors have historically been used to collect geospatial data. In order to enable systems to transform the data collected by the sensors into observations that can be processes and exploited, it is often necessary to understand the characteristics of the sensors. Unfortunately, to date there has not been an industry-wide open register of sensor models and their components. To address this issue, the 2018 Orleans Technical Committee passed a motion for the OGC Naming Authority (OGC-NA) to establish a sensor model register.
The motion passed by the 2018 Orleans Technical Committee (TC) meeting read as follows: "The D&I DWG recommends that the OGC Naming Authority consider a mechanism to allow the creation of a well-defined, on-line registry capability to support registers which are recommended by a SWG or DWG. These need to be standardized and publicized in a machine-readable form with persistent identifiers. Register management will be within the scope of the OGC Naming Authority. A workflow/approval mechanism for creating and updating a Register needs to also be defined. The DWG recommends the first register considered for this registry is the Sensor Model and parameters in order to take it under the control of a standards body".
This document presents OGC policy on the registration of sensor models and their parameters. A sensor model register provides an authoritative lookup of identifiers of sensor models and their associated components such as sensor properties, transformation polynomials, and so on.
ii. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, policy, naming authority, definitions, sensor model, parameters
iii. Preface
This document specifies a rule for constructing OGC names that may be used for identifying definitions of sensor models and their parameters. This document is formally a profile of the OGC policy 'OGC-NA Name type specification - definitions: Part 1 - basic name' (OGC 09-048r5).
iv. Submitting organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
Organization name(s)
-
CSIRO
-
IGN
-
Metalinkage
-
WiSC
-
OGC
v. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation |
|---|---|
Gobe Hobona |
OGC |
Simon Cox |
CSIRO |
Emmanuel Devys |
IGN |
Rob Atkinson |
Metalinkage |
Charles Heazel |
WiSC |
Scott Simmons |
OGC |
1. Scope
This OGC policy applies to sensor models and their parameters. A sensor model is a type of Location Model that allows one to georegister or co-register observations from a sensor (particularly remote sensors) (OGC 12-000).
2. Conformance
This document presents OGC policy on the registration of sensor models and their parameters.
Conformance with this policy shall be checked using the naming rule and naming assignment policy defined in this document.
3. References
IETF: RFC 2141 URN Syntax, http://tools.ietf.org/html/rfc2141 (1997)
IETF: RFC 2616 Hypertext Transfer Protocol — HTTP/1.1, http://tools.ietf.org/html/rfc2616 (1999)
IETF: RFC 3986 Uniform Resource Identifier (URI): Generic Syntax, http://tools.ietf.org/html/rfc3986 (2005)
IETF: RFC 4395 Guidelines and Registration Procedures for New URI Schemes, http://tools.ietf.org/html/rfc4395 (2006)
IETF: RFC 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO), http://tools.ietf.org/html/rfc5141 (2008)
IETF: RFC 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC), http://tools.ietf.org/html/rfc5165 (2008)
IETF: RFC 5234 Augmented BNF for Syntax Specifications: ABNF, http://tools.ietf.org/html/rfc5234 (2008)
OGC: OGC 05-020r25, Technical Committee Policies and Procedures, http://docs.opengeospatial.org/pol/05-020r25/05-020r25.html (2017)
OGC: OGC 09-046r5, OGC Naming Authority – Procedures, http://www.opengeospatial.org/standards/na (2018)
OGC: OGC 09-048r5, OGC-NA Name type specification - definitions: Part 1 - basic name', http://www.opengeospatial.org/standards/na (2010)
OGC: OGC 12-000, OGC® SensorML: Model and XML Encoding Standard, https://portal.opengeospatial.org/files/?artifact_id=55939
W3C: Simple Knowledge Organization System (SKOS), https://www.w3.org/TR/2009/REC-skos-reference-20090818 (2009)
4. Terms and Definitions
This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.
For the purposes of this document, the following additional terms and definitions apply.
4.1. Observation
Act of observing a property or phenomenon [ISO 19156, definition 4.10] Note: The goal of an observation may be to measure, estimate or otherwise determine the value of a property.
4.2. Sensor
An entity capable of observing a phenomenon and returning an observed value. Type of observation procedure that provides the estimated value of an observed property at its output. Note: A sensor uses a combination of physical, chemical or biological means in order to estimate the underlying observed property. At the end of the measuring chain electronic devices often produce signals to be processed. (OGC 12-000)
4.3. Sensor Model
A geopositioning mathematical description of the relationship between the three-dimensional object space and the two-dimensional plane of the associated image produced by a sensor (ISO/TS 19130)
4.4. (Sensor) Platform
An entity to which can be attached sensors or other platforms. A platform has an associated local coordinate reference frame that can be referenced relative to an external coordinate reference frame and to which the reference frames of attached sensors and platforms can be referenced.(OGC 12-000)
5. Conventions
This document uses the normative terms (SHALL, SHOULD, etc) defined in Subclause 5.3 of [OGC 06-121r3], which is based on the ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards. In particular, the word 'shall' (not 'must') is the verb form used to indicate a requirement to be strictly followed to comply with this specification.
Name production rules in this document are expressed using ABNF (IETF RFC 5324).
The namespaces and prefixes used in this document are introduced in the following table.
| Prefix | Namespace |
|---|---|
owl |
|
rdf |
|
skos |
|
dcterms |
|
rdfs |
|
dc |
|
status |
|
policy |
6. Naming Rule
This section describes the naming rule. The section is taken from the OGC policy 'OGC-NA Name type specification - definitions: Part 1 - basic name' (OGC 09-048r3).
6.1. OGC name schemes
Two URI schemes [IETF RFC 3986] are defined by OGC to provide persistent names for resources of interest in geographic information infrastructures. These include schemas for URNs and HTTP URIs. The register of sensor models and parameters uses HTTP URIs as identifiers. The URIs are grounded on the www.opengis.net domain to ensure OGC is able to provide persistent resolvability of the URIs. The identifiers can be used across OGC standards to refer to parameters that have the same semantics.
The generic syntax for OGC http URIs is
URI = "http://www.opengis.net/" OGCResource "/" ResourceSpecificPath
The following ABNF adapted from [IETF RFC 3986] provides some basic definitions required in the rest of this document.
segment = *pchar
segment-nc = *pchar-nc
segment-nz = 1*pchar
segment-nz-nc = 1*pchar-nc
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
6.2. Production rule for specification element names
The basic form for an OGC name that identifies a definition shall be produced using the following rule:
OGCResource = "def" ResourceSpecificPath = definition-type "/" authority "/" version "/" code ResourceSpecificString = definition-type ":" authority ":" versionURN ":" codeURN definition-type = segment-nz-nc ; a token from the register of OGC definition types authority = segment-nz-nc ; a token from the register of OGC authorities version = segment-nz-nc / "0" ; use 0 for un-versioned names code = segment-nz-nc *( "/" segment-nz-nc ) versionURN = segment-nc ; this may be a zero-length string codeURN = segment-nz-nc *( ":" segment-nz-nc )
"version" or "versionURN" is a required field. For un-versioned definitions:
-
within the http URI form the version field shall be "0"
-
within the URN form versionURN shall be a zero-length string—so an un-versioned definition can be detected by a pair of colons "::".
The actual code may be composed of a sequence of fields delimited by "/" in the http URI form, or ":" in the URN form.
6.3. Additional rules specific to sensor models
The following additional rules apply to sensor models:
-
The definition-type in a URI identifying a sensor model shall be set as "sensor-model"
-
The code segment of a URI identifying a sensor model shall begin with the acronym or UpperCamelCase name of the specification to which the sensor model belongs (e.g. NITF)
An example URI conforming to the rules listed above is http://www.opengis.net/def/sensor-model/NTB/2.1/NITF/RPC00B
The example is based on the National Imagery Transmission Format (NITF)[MIL-STD-2500C] and its Rapid Positioning Capability extension (RPC00B) [STDI-0002 App E]. In the example URI above, the NTB (NITF Technical Board) is the authority, the version number is 2.1, the specification is NITF and the sensor model name is RPC00B (in this case, the name of the NITF extension).
|
Note
|
The RPC00B contains rational function polynomial coefficients and normalization parameters that define the physical relationship between image coordinates and ground coordinates. That is, the extension is based on Rational Polynomial Coefficients (RPC). |
6.4. Additional rules specific to sensor model parameters
The following additional rules apply to sensor model parameters:
-
The definition-type in a URI shall be set as "sensor-model-param"
-
The code segment of a URI shall begin with the acronym or UpperCamelCase name of the specification to which the sensor model parameter belongs (e.g. NITF)
-
The last sub-segment of the code segment shall be a name unique within the sensor model
-
The code segment of a URI may optionally include a sub-segment identifying the sensor model and/or other containers of the sensor model parameter.
An example URI conforming to the rules listed above is http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/RPC00B/LINE_OFF
In the example URI above, the NTB is the authority, the version number is 2.1, the specification is NITF, the sensor model is RPC00B, the sensor model parameter is LINE_OFF.
7. Name Assignment Policy
7.1. Sensor Models
The register of sensor models http://www.opengis.net/register/ogc-na/sensor-model is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority names@opengeospatial.org.
Any relevant stakeholder (OGC member or non-OGC member) may submit proposals for changes.
7.2. Sensor Model Parameters
The register of sensor model parameters http://www.opengis.net/register/ogc-na/sensor-model-param is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority names@opengeospatial.org.
Any relevant stakeholder (OGC member or non-OGC member) may submit proposals for changes.
7.3. Description
Each sensor model parameter shall be described using the Simple Knowledge Organization System (SKOS) vocabulary of the World Wide Web (W3C) consortium. Other vocabularies may also be used in addition to SKOS, for example the OGC Semantic Registry Information Model (SRIM) [1].
The following predicates are mandatory for describing sensor model and parameter resources:
-
skos:prefLabel for providing a human-readable version of a resource’s name
-
dcterms:created for stating the date the resource was created in the register
-
dcterms:modified for stating the date the resource was modified in the register (mandatory if the resource has been modified)
-
policy:status for indicating whether the resource is valid, retired, superseded, or under consideration
-
skos:definition for providing a human-readable description of the resource
-
skos:inScheme for stating the Concept Scheme to which the resource belongs
-
rdfs:label for providing a human-readable version of a resource’s name (used for compatibility with non-SKOS systems)
An example of the use of the above-listed predicates is presented below in the Turtle format of the Resource Description Framework (RDF). Note that individual sensor model parameters are described as instances of the SKOS Concept class, whereas sensor models are described as instances of the SKOS ConceptScheme class.
<http://www.opengis.net/def/sensor-model/NTB/2.1/NITF/RPC00B>
a skos:ConceptScheme ;
rdfs:label "NITF Rapid Positioning Capability" ;
dcterms:created "2018-03-13"^^<http://www.w3.org/2001/XMLSchema#date> ;
dcterms:modified "2018-04-16"^^<http://www.w3.org/2001/XMLSchema#date> ;
policy:status status:valid ;
skos:definition "The sensor model supported by the RPC00B extension of the NITF standard contains rational function polynomial coefficients and normalization parameters that define the physical relationship between image coordinates and ground coordinates." ;
skos:prefLabel "NITF Rapid Positioning Capability" ;
skos:broader <http://www.opengis.net/def/sensor-model/OGC/0/RationalPolynomialCoefficients> .
<http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/RPC00B/LINE_OFF>
a skos:Concept ;
rdfs:label "Line Offset" ;
dcterms:created "2018-03-13"^^<http://www.w3.org/2001/XMLSchema#date> ;
dcterms:modified "2018-04-16"^^<http://www.w3.org/2001/XMLSchema#date> ;
policy:status status:valid ;
skos:definition "Line Offset" ;
skos:inScheme <http://www.opengis.net/def/sensor-model/NTB/2.1/NITF/RPC00B> ;
skos:prefLabel "Line Offset" .Note the use of the SKOS broader predicate to represent the relationship of the sensor model adopted by RPC00B to the Rational Polynomial Coefficients model [2].
8. Examples
http URI form:
This policy has been designed to be able to support registration of models such as the: Community Sensor Model (CSM) [3], Generic Point Cloud Model (GPM) [4], Frame Sensor Model [5], Pushbroom/Whiskbroom Sensor Model [6], Light Detection and Ranging (LiDAR) Sensor Model [7], Spotlight Synthetic Aperture Radar (SAR) Sensor Model [8] and others defined in ISO/TS 19130-2 [9] and extensions of the National Imagery Transmission Format (NITF) standard [10].
The following examples use ISO 19130 [11] and NITF sensor model parameters [12] to illustrate how to construct an http URI based on this OGC policy. The NITF examples are based on the SENSRB extension [13]. The examples have been informed by lessons learnt from the OGC Testbed series [14].
Example 1, below, illustrates an http URI value for the ISO 19130 True Replacement Model:
Example 2, below, illustrates an http URI value for the NITF RPC00B model:
Example 3, below, illustrates the http URI value for the 'region of validity' parameter of the ISO 19130 True Replacement Model:
Example 4, below, illustrates the http URI value for the LAT_OFF parameter of the NITF RPC00B model [10].
|
Note
|
SENSRB is a NITF tagged record extension for imaging electro-optical sensors [STDI-0002 App Z]. It was developed to enable the storage and use of geometric parameters from electro-optical sensor systems. It provides an encoding scheme to support implementation of the Community Sensor Model (CSM) Working Group’s guidance on geopositioning from frame, pushbroom, and whiskbroom sensors. |
Example 5, below, illustrates the http URI value for the REFERENCE_ROW field of the NITF SENSRB extension:
Example 6, below, illustrates where the field is nested inside other objects and the hierarchy of nesting objects is identified as separate sections of the URI. The http URI value for the PLATFORM_HEADING field, contained inside a ATTITUDE_EULER_ANGLES object of the NITF SENSRB extension is:
Annex A: Usage with SensorML (Informative)
A.1. Introduction
The OGC Sensor Model Language (SensorML) standard provides the means of semantically defining processes and their associated components with the measurement and post-measurement transformation of observations. Whereas the standard provides the means to describe sensor characteristics, it allows implementations to use their own identifiers for referencing their sensor characteristics. This enables interoperability by allowing the sensor characteristics to be described in a consistent syntax, however it also requires that applications attempting to interpret the sensor model descriptions understand the meaning of the identifiers before hand.
A.2. Examples
The following is an example of how to use OGC-registered ISO URIs with SensorML.
<sml:SimpleProcess gml:id="example.1"
xmlns:sml="http://www.opengis.net/sensorml/2.0"
xmlns:swe="http://www.opengis.net/swe/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xsi:schemaLocation="http://www.opengis.net/sensorml/2.0 http://schemas.opengis.net/sensorML/2.0/sensorML.xsd"
definition="http://www.opengis.net/def/sensor-model/ISO/0/ISO-19130/SD_SensorModel/trueReplacementModel/SD_TrueReplacementModel">
<sml:parameters>
<sml:ParameterList>
<sml:parameter name="regionOfValidity">
<swe:DataRecord definition="http://www.opengis.net/def/sensor-model-param/ISO/0/ISO-19130/SD_TrueReplacementModel/regionOfValidity">
<swe:label>True Replacement Model regionOfValidity</swe:label>
<swe:field name="gridPoints">
<swe:Vector referenceFrame="http://www.opengis.net/def/cs/OGC/0/CartesianIndexed2D">
<swe:coordinate name="gridPoint1">
<swe:Quantity definition="http://www.opengis.net/ont/gml#Point">
<swe:uom code="GridSpacing"/>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="gridPoint2">
<swe:Quantity definition="http://www.opengis.net/ont/gml#Point">
<swe:uom code="GridSpacing"/>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="gridPoint3">
<swe:Quantity definition="http://www.opengis.net/ont/gml#Point">
<swe:uom code="GridSpacing"/>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="gridPoint4">
<swe:Quantity definition="http://www.opengis.net/ont/gml#Point">
<swe:uom code="GridSpacing"/>
</swe:Quantity>
</swe:coordinate>
</swe:Vector>
</swe:field>
</swe:DataRecord>
</sml:parameter>
</sml:ParameterList>
</sml:parameters>
</sml:SimpleProcess>The following is an example of how to use OGC-registered NITF URIs with SensorML.
<sml:SimpleProcess gml:id="example.2"
xmlns:sml="http://www.opengis.net/sensorml/2.0"
xmlns:swe="http://www.opengis.net/swe/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xsi:schemaLocation="http://www.opengis.net/sensorml/2.0 http://schemas.opengis.net/sensorML/2.0/sensorML.xsd"
definition="http://www.opengis.net/def/sensor-model/NTB/2.1/NITF/SENSRB">
<sml:parameters>
<sml:ParameterList>
<sml:parameter name="sensrbParams">
<swe:DataRecord definition="http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/SENSRB/">
<swe:label>NITF SENSRB Sensor Model Parameters (subset of)</swe:label>
<swe:field name="referenceRow">
<swe:Quantity definition="http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/SENSRB/REFERENCE_ROW">
<swe:label>Reference Row</swe:label>
<swe:uom code="pixel"/>
</swe:Quantity>
</swe:field>
<swe:field name="SENSOR_CALIBRATION_DATA">
<swe:DataRecord>
<swe:label>Sensor Calibration Data</swe:label>
<swe:field name="PRINCIPAL_POINT_OFFSET_X">
<swe:Quantity definition="http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/SENSRB/SENSOR_CALIBRATION_DATA/PRINCIPAL_POINT_OFFSET_X">
<swe:label>PRINCIPAL_POINT_OFFSET_X</swe:label>
<swe:uom code="pixel"/>
</swe:Quantity>
</swe:field>
<swe:field name="PRINCIPAL_POINT_OFFSET_Y">
<swe:Quantity definition="http://www.opengis.net/def/sensor-model-param/NTB/2.1/NITF/SENSRB/SENSOR_CALIBRATION_DATA/PRINCIPAL_POINT_OFFSET_Y">
<swe:label>PRINCIPAL_POINT_OFFSET_Y</swe:label>
<swe:uom code="pixel"/>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</swe:field>
</swe:DataRecord>
</sml:parameter>
</sml:ParameterList>
</sml:parameters>
</sml:SimpleProcess>Annex B: Revision History
| Date | Release | Editor | Primary clauses modified | Description |
|---|---|---|---|---|
2018-04-13 |
0.1 |
G. Hobona |
all |
Initial draft document |
2018-04-27 |
0.2 |
G. Hobona |
all |
Revised based on feedback from contributors |
2018-05-14 |
0.3 |
G. Hobona |
annex a |
Schema validated SensorML examples |
2018-05-17 |
0.4 |
G. Hobona |
all |
Automated bibliography added. Cited additional GWG resources. |
2018-07-05 |
1.0 |
G. Hobona |
iii |
Included statement that any relevant stakeholder (OGC member or non-OGC member) may submit proposals for changes. Also included declaration of this policy as a profile of OGC-NA definitions policy (as per Fort Collins TC motion) |
Annex C: Bibliography
-
Fellah, S.: OGC Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report, OGC 16-059, http://docs.opengeospatial.org/per/16-059.html, (2017).
-
Guo, Z., Xiuxiao, Y.: On RPC model of satellite imagery, (2010).
-
Geospatial Intelligence Standards Working Group: Community Sensor Model (CSM) Technical Requirements Document (TRD), Version 3.0.3, NGA.STND.0017_3.0.3, (2017).
-
Geospatial Intelligence Standards Working Group: The Generic Point-Cloud (GPM): Implementation and Exploitation, Version 1.0, NGA.STND.0046_1.0_GPM, (2015).
-
Geospatial Intelligence Standards Working Group: Frame Sensor Model Metadata Profile Supporting Precise Geopositioning, Version 2.1, NGA.SIG.0002_2.1, (2011).
-
Geospatial Intelligence Standards Working Group: Pushbroom/Whiskbroom Sensor Model Metadata Profile Supporting Precise Geopositioning, Version 1.0, NGA.SIG.0003_1.0, (2009).
-
Geospatial Intelligence Standards Working Group: Light Detection and Ranging (LiDAR) Sensor Model Supporting Precise Geopositioning, Version 1.1, NGA.SIG.0004_1.1, (2011).
-
Geospatial Intelligence Standards Working Group: Spotlight Synthetic Aperture Radar (SAR) Sensor Model Supporting Precise Geopositioning, Version 1.0, NGA.SIG.0005_1.0, (2010).
-
International Organization for Standardization: Geographic information — Imagery sensor models for geopositioning — Part 2: SAR, InSAR, lidar and sonar, ISO/TS 19130-2, (2014).
-
NITFS Technical Board: Appendix E - Airborne Support Data Extensions (ASDE) VERSION 2.1, STDI-0002 App E (2000), (2000).
-
International Organization for Standardization: Geographic information - Imagery sensor models for geopositioning, ISO/TS 19130, (2010).
-
NITFS Technical Board: NITF 2.1., National Imagery Transmission Format Version 2.1 MIL-STD-2500C).
-
NITFS Technical Board: APPENDIX Z - General Electro-Optical (Visible, Infrared, Multi- and Hyperspectral) Sensor Parameters (SENSRB) Tagged Record Extension (TRE) VERSION 2.1, STDI-0002, (2013).
-
Androsevic, D.: OGC® OWS-9 OWS Innovations GMLJP2 for National Imagery Transmission Format (NITF) Engineering Report, OGC 12-154, https://portal.opengeospatial.org/files/?artifact_id=51889, (2013).