I. Abstract
Methane (CH4) is one of the most potent greenhouse gases, and the comparative impact of methane is 25 times greater than CO2 over a 100-year period. Methane is an invisible and odorless gas, and it is very labor intensive and time consuming in order to detect and repair leaks. Regulations play a critical role in methane emissions reduction, and how methane emissions are detected, repaired, and managed is highly dependent on local regulations. This OGC Best Practice document defines a SensorThings API for fugitive methane emissions management.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, sensor web, API, methane, methane emissions, Internet of Things, SensorThings, climate change
III. Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
IV. Security considerations
No security considerations have been made for this document.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- SensorUp Inc.
- the University of Calgary
- TC Energy
- Fraunhofer IOSB
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affliation |
|---|---|
| Steve Liang | SensorUp Inc./University of Calgary |
| John Tang | TC Energy |
| Patrick Kelly | TC Energy |
| Sara Saeedi | University of Calgary |
| Sina Kiaei | University of Calgary |
| Hylke van der Schaaf | Fraunhofer IOSB |
The editor would like to acknowledge that this work is the result of collaboration and review of many organizations and would like to thank for the comments and contributions from:
GeoConnections, Natural Resources Canada
Cenovus Energy
Canadian Natural Resources (CNRL)
Alberta Innovates
Note: this does not imply a complete endorsement by these organizations.
OGC Integrated Methane Sensor Web for Emissions Management Best Practice - Part I - Fugitive Emissions Management based on AER Directive 60
1. Scope
Methane (CH4) is one of the most potent greenhouse gases, and the comparative impact of methane is 25 times greater than CO2 over a 100-year period [9]. Methane is an invisible and odorless gas, and it is very labor intensive and time consuming in order to detect and repair leaks. Current methane emission management solutions are fragmented and developed without standards, ultimately leading to a complex network of incompatible sensing solutions that need to interrelate but do not. However, no single methane sensing technology can meet the accuracy, spatio-temporal resolution, and low-cost requirements. There is a need to interconnect the heterogeneous existing and emerging methane sensing technologies, ranging from satellites, drones, fixed-wing aircraft, vehicle-based systems, and continuous in-situ monitoring stations to handheld Optical Gas Imaging (OGI) devices. An effective methane emissions management solution requires an integrated methane sensor web. OGC Sensor Web Enablement (SWE) provides the fundamental standard building blocks for the integrated methane sensor web [13].
Figure 1 — Examples of methane measurement platforms operating across a variety of spatial and temporal scales. (After: National Academies of Sciences, Engineering, and Medicine [1])
This OGC Best Practice (OGC BP) document defines a SensorThings API for fugitive methane emissions management. Regulations play a critical role in methane emissions reduction, and how methane emissions are detected, repaired, and managed is highly dependent on local regulations. This OGC BP is designed based on the Alberta Energy Regulator’s regulatory requirement for fugitive emissions management AER Directive 60 [2].
This Best Practice document provides a data model and API for the exchange of fugitive emissions observation data and the necessary metadata, both within and between different organizations. For example, it can be used for leak detection and to enable repair service providers to prepare and exchange fugitive emissions observation data with facility operators. Facility operators can also use this Best Practice to facilitate the exchange of fugitive emissions data within their organizations and with regulators.
Venting and combustion methane emissions are out of scope of this OGC Best Practice document. The development of an OGC Best Practice document for venting emissions and combustion emissions is on the roadmap.
1.1. Roadmap
This OGC Best Practice document is the first part of the OGC Integrated Methane Sensor Web for Emissions Management Series of Best Practice documents. The editors plan to publish a series of Best Practice documents for methane emissions management, ranging from data sources (e.g., different types of sensing systems) to data destinations (e.g., fugitive and venting emissions for regulatory reporting). The goal is to develop the building blocks for an integrated Methane Emissions Sensor Web, enabling seamless flows of observation data between various nodes: from SensorThings nodes with heterogeneous sensing sources (i.e., multiple disparate methane observation systems), to SensorThings nodes with analytics-ready data (i.e., an aggregated methane emissions datalake), and eventually to SensorThings nodes with compliance-ready data (i.e., data compliant to various regulatory organizations in different jurisdictions).
The figure below shows the roadmap of the different OGC Best Practice documents to be developed and their relationship.
Figure 2 — Integrated Methane Sensor Web Best Practice Roadmap
1.2. Design Goals
This OGC Best Practice document and its series have the following design goals:
Modularity: different parts of a methane emissions management system can be separated and reassembled, benefiting flexibility, future-proof, and variety in use;
Simplicity: the design is concise, easily testable, easy to implement, and developer-friendly;
Interoperability: whenever possible, it follows international open standards;
Scalability: it is able to grow in terms of the number of sensors, types of sensors, and volume of data without sacrificing performance.
2. Conformance
This OGC Best Practice document defines a SensorThings API for fugitive methane emissions management based on the Alberta Energy Regulator’s regulatory requirement for fugitive emissions management AER Directive 60 (2021).
Conformance with this OGC Best Practice document shall be checked using all the relevant tests specified in Annex A (normative) of this document.
All requirements classes and conformance classes described in this document are owned by the document(s) identified.
The following table lists the requirements classes defined in this OGC Best Practice document.
NOTE The text in the Requirements class id and Requirements columns in the following table is the path fragment that, when appended to the URI: http://www.opengis.net/spec/imsw-fm-aer60/1.0, provides the URI that can be used to unambiguously identify the requirement and the conformance class.
Table 1 — List of the requirements classes defined in this OGC Best Practice document
| Requirements class id | Requirements | Description |
|---|---|---|
/req/datamodel/thing |
|
Thing entity |
/req/datamodel/location |
|
Location entity |
/req/datamodel/datastream |
|
Datastream entity |
/req/datamodel/observed-property |
|
ObservedProperty entity |
/req/datamodel/observation |
|
Observation entity |
/req/datamodel/feature-of-interest |
|
FeatureOfInterest entity |
/req/datamodel/sensor |
|
Sensor entity |
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO: ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of dates and times. International Organization for Standardization, Geneva (2004). https://www.iso.org/standard/40874.html
Simon Cox: OGC 10-004r3, Topic 20 — Observations and Measurements. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact_id=41579
Steve Liang, Tania Khalafbeigi, Hylke van der Schaaf: OGC 18-088, OGC SensorThings API Part 1: Sensing Version 1.1. Open Geospatial Consortium (2021). https://docs.ogc.org/is/18-088/18-088.html
OASIS: OData Version 4.0 Part 1: Protocol Plus Errata 02. Organization for the Advancement of Structured Information Standards (2014). https://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-protocol/odata-v4.0-errata02-os-part1-protocol-complete.html
OASIS: OData Version 4.0 Part 2: URL Conventions Plus Errata 02. Organization for the Advancement of Structured Information Standards (2014). https://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html
OASIS: OData JSON Format Version 4.0 Plus Errata 02. Organization for the Advancement of Structured Information Standards (2014). https://docs.oasis-open.org/odata/odata-json-format/v4.0/errata02/os/odata-json-format-v4.0-errata02-os-complete.html
OASIS: OData ABNF Construction Rules Errata 02. Organization for the Advancement of Structured Information Standards (2014)
N. Freed, N. Borenstein: RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. Internet Engineering Task Force (1996). https://www.rfc-editor.org/info/rfc2046
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: RFC 2616, Hypertext Transfer Protocol — HTTP/1.1. Internet Engineering Task Force (1999). https://www.rfc-editor.org/info/rfc2616
D. Crockford: RFC 4627, The application/json Media Type for JavaScript Object Notation (JSON). Internet Engineering Task Force (2006). https://www.rfc-editor.org/info/rfc4627
H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub: RFC 7946, The GeoJSON Format. Internet Engineering Task Force (2016). https://www.rfc-editor.org/info/rfc7946
UCUM: Unified Code for Units of Measure (UCUM) – Version 1.9, April 2015
4. Terms, definitions and abbreviated terms
This document uses the terms defined in OGC Policy Directive 49, 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 document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
4.1. Terms and definitions
4.1.1. Facility ID
A unique facility identification code, with 4 letters and 7 numbers (e.g., ABWP1234567), assigned by Petrinex to each facility (Source: AER Directive 60 [2]).
4.1.2. Fugitive Emissions
Unintentional releases of hydrocarbons to the atmosphere (Source: AER Directive 60 [2]).
4.1.3. Fugitive Emissions Screenings
Site-wide evaluations where the primary purpose is to identify fugitive emissions (e.g., from open thief hatches). These are less comprehensive than fugitive emission surveys (Source: AER Directive 60 [2]).
4.1.4. Fugitive Emission Surveys
Site-wide evaluations that use equipment-based methods to detect and identify sources of fugitive emissions for repair. These surveys are considered comprehensive evaluations that can assist in reducing both small volumes and large volumes of fugitive emissions (Source: AER Directive 60 [2]).
4.1.5. Petrinex
Canada’s Petroleum Information Network
4.1.6. Site
The area defined by the boundaries of a surface lease for upstream oil and gas facilities and wells (pads counted as one lease) (Source: AER Directive 60 [2]).
4.1.7. Leak
A release of hydrocarbons from an equipment component is a leak if:
(a) the release consists of at least 500 ppmv of hydrocarbons, as determined by an inspection conducted by means of an eligible portable monitoring instrument in accordance with EPA Method 21; or
(b) the release is detected
(i) during an inspection conducted by means of an eligible optical gas-imaging instrument, or
(ii) by means of an auditory method, an olfactory method or a visual method, including the observation of the dripping of hydrocarbon liquids from the equipment component.
(Source: Government of Canada [14])
4.1.8. Local Regulation
The federal regulations that apply to methane in the upstream oil and gas sector aim to control methane emissions and also reduce the amount of volatile organic compounds (VOCs) released into the air (Source: Environment and Climate Change Canada [6]).
4.1.9. Fugitive Emissions Management Program
A plan and supporting systems to systematically detect and manage fugitive emissions. Fugitive Emissions Management Programs are intended to complement a duty holder’s overall emissions reduction strategy (Source: AER Directive 60 [2]).
4.1.10. Vent Emission
The intentional controlled release of un-combusted gases directly to the atmosphere (Source: BC Oil and Gas Commission [5]).
4.2. Abbreviated terms
AER
Alberta Energy Regulator
API
Application Programming Interface
ATS
Alberta Township Survey
BP
Best Practice
- CH4
Methane
CNRL
Canadian Natural Resources
EPA
Environmental Protection Agency
FEM-STA
Fugitive Emissions Management — SensorThings API
FEMP
Fugitive Emissions Management Program
GPS
Global Positioning System
IANA
Internet Assigned Numbers Authority
ID
Identity
JSON
JavaScript Object Notation
LDAR
Leak Detection and Repair
LSD
Legal Subdivisions
OGC
Open Geospatial Consortium
OGI
Optical Gas Imaging
STA
SensorThings API
SWE
Sensor Web Enablement
URI
Uniform Resource Identifier
VOC
Volatile Organic Carbon
5. Conventions
This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.
5.1. Identifiers
The normative provisions in this document are denoted by the URI
http://www.opengis.net/spec/imsw-fm-aer60/1.0
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6. Methane Emissions
Methane (CH4) is one of the most potent greenhouse gases, and the comparative impact of methane is 25 times greater than CO2 over a 100-year period [9]. Global anthropogenic methane emissions by 2020 are estimated to be 9,390 million metric tons of CO2 equivalent [17]. Approximately 50~60% of the anthropogenic methane emissions come from the following five sources: (1) agriculture (enteric fermentation-27% and manure management-3%), (2) oil and gas (24%), (3) municipal solid waste (11%), (4) coal mining (9%), and (5) wastewater (7%). Figure below shows a pie chart of the global estimated methane emissions sources in 2020.
Figure 3 — Anthropogenic methane emissions by source 2020 [Gobal Methane Initiative 2020]
In the oil and gas industry vent gas and fugitive emissions are the two major sources of methane emissions. Vent gas is un-combusted gas, that is released into the atmosphere. Fugitive emissions are the unintentional releases of hydrocarbons into the atmosphere. This OGC Best Practice document focuses on the detection and quantification of fugitive methane emissions in the oil and gas industry.
Methane is an invisible and odorless gas, as a result it is very labor intensive and time consuming in order to detect and repair the leaks. Current methane emissions management solutions are fragmented and being developed without standards, ultimately leading to a complex network of incompatible sensing solutions that need to interrelate but are not possible. However there is no single methane sensing technology that can meet the accuracy, spatio-temporal resolution, and low-cost requirements. There is a need to interconnect the heterogeneous existing and emerging methane sensing technologies, ranging from satellites, drones, fixed-wing aircraft, vehicle-based systems, continuous in-situ monitoring stations, to handheld OGI devices. An effective methane emissions management solution needs an integrated methane sensor web. OGC SWE provides the fundamental standard building blocks for the integrated methane sensor web.
6.1. Methane Emissions Sensing Technologies
Methane emissions sensing technologies can be categorized by the methane sensor types or by the methane sensing platforms. Based on its sensing principles, methane sensors can be categorized into the following types: (1) optical sensors, (2) calorimetric sensors, (3) pyroelectric sensors, (4) semiconducting metal oxide sensors, and (5) electrochemical sensors. Readers interested in the details of different methane sensing principles can refer to [15], and it provides a comprehensive review of methane gas detection sensors, including the recent development and future perspectives. For the leak detection and repair applications, optical sensors, either laser spectroscopy or imaging spectrometry, are the most common sensor type being used. The following table summarize their advantages and disadvantages.
Table 2 — Methane sensor types, their advantages and disadvantages [adapted from [Aldhafeeri [15] Table 1]
| Methane Sensor Types | Advantages | Disadvantages |
|---|---|---|
| Optical sensors | Non-destructive; immune to electromagnetic interference; operate without oxygen | Expensive; high power consumption; lack of significance and distinctiveness of methane optical absorption region |
| Calorimetric sensors | Low cost; simple; portable; easy to manufacture; good selectivity for methane; can operate in harsh environmental conditions | Low detection accuracy; susceptible to cracking, catalyst poisoning and oversaturation; high power consumption; short lifespan; require high temperature |
| Pyroelectric sensors | Non-destructive; operate without oxygen; good sensitivity and responsivity; wide measuring range; operate at room temperature | High cost; high power consumption; immobile; difficult to manufacture |
| Semiconducting metal oxide sensors | Low cost; lightweight and robust; long lifespan; resistant to poisoning | Poor selectivity; small and high operational temperature range; slow recovery rate; significant addictive dependency; affected by temperature; susceptible to degradation; sensitive to changes in humidity |
| Electrochemical sensors | Three different sub-types: AE, IL, and SE. AE-based: low cost. IL-based: non-hazardous materials; high boiling points and low volatility; good selectivity for methane; can detect small leaks. SE-based: no leakage; safe; robust; good selectivity for methane; can detect small leaks | AE-based: susceptible to leakage and evaporation; hazardous materials; slow response time. IL-based: susceptible to leakage; slow response time. SE-based: require high temperature; unable to detect low gas concentrations; susceptible to degradation or loss of electrolyte. |
In terms of the methane sensing platforms, it can be categorized into the following types: (1) handheld instruments, (2) stationary in-situ or remote sensing sensors, (3) terrestrial mobile methane mapping systems , (4) airborne remote sensing systems, and (5) spaceborne remote sensing satellites. The following sections briefly introduce each methane sensing platform.
6.1.1. Handheld Instruments
For many years the standard leak detection practice has been EPA method 21: Determination of Volatile Organic Carbon Leaks [12]. EPA Method 21 requires that components be surveyed using a Method 21 compliant portable instrument that can measure the volatile organic carbon (VOC) concentration near each component with high accuracy. However, Method 21 is the most labor-intensive and time-consuming method. For example, it may take four to eight hours to complete surveying the components of a well pad. As a result, there are multiple attempts to develop new sensing technologies/platforms to replace Method 21. Optical gas-imaging (OGI) cameras are the other type of handheld instrument, and they has been approved by many regulatory bodies. OGI cameras are a type of close-range remote sensing camera that provide images and videos of methane leaks that are invisible to the human eye. OGI cameras are intuitive to communicate through, and easy to document and report. OGI cameras are also twice more efficient than Method 21. It is worth noting that Method 21 and OGI cameras are the only methods that are able to accurately locate methane leaks at the component level. Locating leaking components is critical because the leaks can only be stopped by either repairing or replacing the components.
Figure 4 — A field technician performs methane emission survey with an optical gas imaging camera (Source: Zimmerle et al. [16])
6.1.2. Stationary methane sensing systems
Stationary sensors are deployed near the potential methane emissions sources, and provide continuous methane concentration observations. Based on the sensor type, it can be further categorized into close-range remote sensing systems and in-situ sensing systems. Examples of close-range methane remote sensing systems include Rebellion Photonics (acquired by Honeywell), Kuva systems, etc. Examples of in-situ methane sensing systems include Aeris Sensors, Project Canary, Eco-esolutions, Quanta3, Scientific Aviation, Teledyne, Troposphere and more. Low-cost in-situ methane sensor networks have the potential to be the future of methane leak detection technology, because they can potentially operate at a cost comparable to or even lower than currently periodic, manual inspections that typically use the handheld instruments described in the section above. However, peer-reviewed research and validation studies of the existing commercial systems are currently missing. There are multiple research projects, such as Project Astra of the University of Texas at Austin, and the University of Calgary’s Emissions Testing Centre, that are focusing on validating the performances of these low-cost sensing systems.
Compared to other sensing platforms, one unique advantage of stationary sensors is their high temporal resolution. A network of methane stationary sensor networks has the potential to detect fugitive emissions almost instantaneously, and that means leaks can potentially be repaired before the regular visits (typically three times a year, depending on site types and regulations). Stationary methane sensing systems are well suited for facilities with high component density, such as refineries, gas plants, compressor stations, and multi-well pads.
6.1.3. Terrestrial mobile methane mapping systems
Terrestrial vehicles equipped with methane sensors and anemometers to account for atmospheric conditions can be used to screen methane emissions over a large area very efficiently. For example, Atherton et al. [4] demonstrated that over 1600 well pads were surveyed across nearly 8000 km of roads. Compared to other sensing platforms, terrestrial mobile methane mapping systems have the following advantages: (1) they do not require site access, (2) less time spent at each site, (3) minimal coordination with facility operators is required, and (4) they provide an efficient approach for regulators to audit the reports submitted by facility operators. However, these systems are constrained by road access and weather conditions, especially wind directions. Without sufficient wind or if wind is blowing in the wrong direction, methane plumes may not reach the roads and thus methane leaks cannot be detected by the terrestrial mobile methane mapping systems.
Figure 5 — A methane measurement mobile ground lab system [8]
6.1.4. Airborne methane remote sensing systems
Airborne methane remote sensing systems can be further categorized into two types: (1) piloted aircraft, including helicopter and fixed wing aircraft, and (2) Unmanned Aerial Vehicles (UAVs). Different types of methane sensors can be mounted on airborne vehicles to detect emissions over large areas in a short period of time. Some airborne systems, such as Scientific Aviations [7], use in-situ sensors, that are similar or identical to terrestrial systems, to process air samples for methane concentrations. Some airborne systems, such as Bridger Photonics [10], use remote sensing technologies such as LiDAR, to detect emissions on the ground. The main advantage of piloted airborne systems is that they are able to cover a large area very efficiently, and unlike terrestrial systems airborne systems they are not constrained by roads. However, the operational cost is higher compared to that of terrestrial systems.
Figure 6 — Example data of Bridger Photonics [10]
Compared to piloted airborne systems, UAV-based systems can perform observations very close to the potential emissions sources, as a result they can detect methane emissions with much lower emissions rates. However, many methane sensors are power-hungry and not suitable for UAVs, as UAVs are constrained by their battery capacity and weight. Further innovations, such as lightweight and power-efficient sensors, are required in order for UAVs to become a suitable methane sensing platform.
6.1.5. Methane Remote Sensing Satellites
Similar to all Earth Observation (EO) satellites, methane remote sensing satellites provide much larger spatial coverage compared to other sensing platforms. However, existing methane remote sensing satellites capture low-resolution images and cannot detect methane emissions with a low emissions rate. Methane remote sensing satellites are well suited for detecting large emission sources. Example methane remote sensing satellites includes GOSAT, TROPOMI, GHGSat, and Carbon Mapper.
Figure 7 — Example data of GHGSat [11]
7. Fugitive Emissions Management SensorThings API Specification — Part I — AER Directive 60
This chapter describes the entities, their properties and values, and their relations for fugitive emissions reporting requirements based on AER Directive 60.
The SensorThings API Entities of this Best Practice are depicted in the following figure.
Figure 8 — SensorThings API Entities for the Fugitive Emissions AER 60 Best Practice
7.1. Requirements Class: Thing
Requirements class 1 | |
|---|---|
/req/datamodel/thing | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.1, Conformance class A.1: /conf/datamodel/thing |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/thing |
Requirement 1 defines the mandatory properties of a reporting facility (as a Thing).
Requirement 2 defines the direct relation between the “Thing” entity and the “Location” and “Datastream” entities.
7.1.1. Requirement 1
This requirement defines the mandatory properties of a reporting facility (as a Thing).
Requirement 1 | |
|---|---|
/req/datamodel/thing/properties | |
The SensorThings SHALL have a “Thing” entity that has the properties with the corresponding value and multiplicity listed in Table 3. |
Table 3 — Properties of a reporting facility “Thing” entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The facility ID of the reporting facility | Character string type, and the value shall be a valid AER facility ID | One |
| description | A short description of the facility | Character string type | One |
| properties | The well ID or site ID that is associated with the facility ID | A JSON object that has a key of “well or site id” and the corresponding value shall be a valid AER well ID or site ID | One |
7.1.2. Requirement 2
This requirement defines the direct relation between the “Thing” entity and the “Location” and “Datastream” entities.
Requirement 2 | |
|---|---|
/req/datamodel/thing/relations | |
The “Thing” entity SHALL have the direct relation between the “Thing” entity and the entities listed in Table 4. |
Table 4 — Direct relation between a reporting facility “Thing” entity and other entity types
| Entity type | Relation | Description |
|---|---|---|
| Location | One mandatory | A reporting facility “Thing” SHALL have one Location. Multiple reporting facilities “Thing” MAY be located at the same “Location”. |
| Datastream | Three-to-many mandatory | A reporting facility “Thing” SHALL have three related Datastream entities, describing the number-of-fugitive-emissions, the fugitive-emissions-volume, and the fugitive-emissions-mass respectively. A reporting facility “Thing” MAY have additional “Datastreams”. |
7.2. Requirements Class: Location
Requirements class 2 | |
|---|---|
/req/datamodel/location | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.2, Conformance class A.2: /conf/datamodel/location |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/location |
Requirement 3 defines the mandatory properties of the “Location” entity of a reporting facility.
Requirement 4 defines the direct relation between the “Location” entity and the “Thing” entity.
7.2.1. Requirement 3
This requirement defines the mandatory properties and relations of the “Location” of the reporting facility.
Requirement 3 | |
|---|---|
/req/datamodel/location/properties | |
The SensorThings SHALL have a “Location” entity that has the properties with the corresponding value and multiplicity listed in Table 5. |
Table 5 — Properties of a reporting facility Location entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The reporting facility’s legal description of the Legal Subdivision (LSD) according to the Alberta Township Survey (ATS) system [3] | Character string type, and the value shall be a valid legal description of the LSD based on the ATS system | One |
| description | The description about the Location | Character string type | One |
| encodingType | The IANA media type for GeoJSON | Character string type, and the value shall be “application/geo+json” | One |
| location | The GeoJSON polygon [RFC7946] represents the area of the legal description LSD | A GeoJSON Polygon object, and the value of the GeoJSON Polygon coordinates shall be the boundary of the legal description LSD | One |
7.2.2. Requirement 4
This requirement defines the direct relation between the “Location” entity and the “Thing” entity.
Requirement 4 | |
|---|---|
/req/datamodel/location/relations | |
The “Location” entity SHALL have the direct relation between the “Location” entity and the entities listed in Table 6. |
Table 6 — Direct relation between a reporting facility Location entity and the Thing entity
| Entity type | Relation | Description |
|---|---|---|
| Thing | Many optional | Multiple reporting facilities “Thing” MAY be located at the same “Location”. A Location MAY not have a reporting facility “Thing”. |
7.3. Requirements Class: Datastream
Requirements class 3 | |
|---|---|
/req/datamodel/datastream | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.3, Conformance class A.3: /conf/datamodel/datastream |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/datastream |
Requirement 5 defines the mandatory properties of the number-of-fugitive-emissions “Datastream” entity of a reporting facility “Thing”.
Requirement 6 defines the direct relation between the number-of-fugitive-emissions “Datastream” entity and the “Thing”, “Sensor”, “ObservedProperty”, and “Observation” entity.
Requirement 7 defines the mandatory properties of the fugitive-emissions-volume “Datastream” entity of a reporting facility “Thing”.
Requirement 8 defines the direct relation between the fugitive-emissions-volume “Datastream” entity and the “Thing”, “Sensor”, “ObservedProperty”, and “Observation” entity.
Requirement 9 defines the mandatory properties of the fugitive-emissions-mass “Datastream” entity of a reporting facility “Thing”.
Requirement 10 defines the direct relation between the fugitive-emissions-mass “Datastream” entity and the “Thing”, “Sensor”, “ObservedProperty”, and “Observation” entity.
7.3.1. Requirement 5
This requirement defines the mandatory properties of the number-of-fugitive-emissions “Datastream” of the reporting facility.
Requirement 5 | |
|---|---|
/req/datamodel/datastream/number-of-fugitive-emissions-properties | |
The reporting facility “Thing” SHALL have a number-of-fugitive-emissions “Datastream” entity that has the properties with the corresponding value and multiplicity listed in Table 7. |
Table 7 — Properties of a number-of-fugitive-emissions Datastream entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | Number of identified sources of fugitive emissions | Character string type, and the value shall be “Number of identified sources of fugitive emissions” | One |
| description | A short description of the Datastream | Character string type | One |
| observationType | The observation type of the number-of-fugitive-emissions “Observation” is a ISO/OGC 19156 count observation | The value shall be compliant with OM_CountObservation | One |
| phenomenonTime | This “Datastream” SHOULD have a phenomenonTime, describes the temporal interval of the phenomenon times of all observations belonging to this Datastream | TM_Period (ISO 8601 Time Interval) | One |
7.3.2. Requirement 6
This requirement defines the direct relation between the “Datastream” entity and other entity types.
Requirement 6 | |
|---|---|
/req/datamodel/datastream/number-of-fugitive-emissions-relations | |
The number-of-fugitive-emissions “Datastream” entities SHALL have the direct relation between the “Datastream” entity and the entities listed in Table 8. |
Table 8 — Direct relation between a number-of-fugitive-emissions Datastream entity and other entity types
| Entity type | Relation | Description |
|---|---|---|
| Thing | One mandatory | Each number-of-fugitive-emissions “Datastream” SHALL have one and only one reporting facility “Thing”. A reporting facility “Thing” SHALL have one and only one number-of-fugitive-emissions “Datastream”. |
| Sensor | One mandatory | The “Observations” in a number-of-fugitive-emissions “Datastream” are performed by one “Sensor”. One “Sensor” MAY be used by different Datastreams. Note: A “Sensor” in this best practice is an observation process describing the Fugitive Emissions Management Program (FEMP) that generates the observation result. |
| ObservedProperty | One mandatory | The “Observations” of a number-of-fugitive-emissions “Datastream” SHALL observe the methane fugitive emissions “ObservedProperty” as defined in Requirement 11. |
| Observation | Many optional | A number-of-fugitive-emissions “Datastream” has zero-to-many “Observations”. One Observation SHALL occur in one-and-only-one “Datastream”. |
7.3.3. Requirement 7
This requirement defines the mandatory properties of the fugitive-emissions_volume “Datastream” of the reporting facility.
Requirement 7 | |
|---|---|
/req/datamodel/datastream/fugitive-emissions-volume-properties | |
A reporting facility “Thing” SHALL have a fugitive-emissions-volume “Datastream” entity that has the properties with the corresponding value and multiplicity listed in Table 9. |
Table 9 — Properties of a fugitive-emissions-volume Datastream entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The volume of fugitive emissions (m3) | Character string type, and the value shall be “Fugitive Emissions Volume (m3)” | One |
| description | A short description of the Datastream | Character string type | One |
| observationType | The observation type of the fugitive-emissions-volume “Observation” is a ISO/OGC 19156 measurement | The value shall be compliant with OM_Measurement | One |
| phenomenonTime | This “Datastream” SHOULD have a phenomenonTime, describes the temporal interval of the phenomenon times of all observations belonging to this Datastream | TM_Period (ISO 8601 Time Interval) | One |
| unitOfMeasurement | The unit of measurement of this Datastream is cubic meter | A SensorThings “unitOfMeasurement” JSON Object, with the following key-value pairs: {"uom":"m3","symbol":"Cubic Meter","definition":"http://qudt.org/vocab/unit/M3"} | One |
7.3.4. Requirement 8
This requirement defines the direct relation between the fugitive-emissions-volume “Datastream” entity and other entity types.
Requirement 8 | |
|---|---|
/req/datamodel/datastream/fugitive-emissions-volume-relations | |
The fugitive-emissions-volume “Datastream” entity SHALL have the direct relation between the “Datastream” entity and the entities listed in Table 10. |
Table 10 — Direct relation between a fugitive-emissions-volume Datastream entity and other entity types
| Entity type | Relation | Description |
|---|---|---|
| Thing | One mandatory | Each fugitive-emissions-volume “Datastream” SHALL have one and only one reporting facility “Thing”. A reporting facility “Thing” SHALL have one and only one fugitive-emissions-volume “Datastream”. |
| Sensor | One mandatory | The “Observations” in a fugitive-emissions-volume “Datastream” are performed by one “Sensor”. One “Sensor” MAY be used by different Datastreams. Note: A “Sensor” in this best practice is an observation process describing the Fugitive Emissions Management Program (FEMP) that generates the observation result. |
| ObservedProperty | One mandatory | The “Observations” of a fugitive-emissions-volume “Datastream” SHALL observe the methane fugitive-emissions”ObservedProperty” as defined in Requirement 11. |
| Observation | Many optional | A fugitive-emissions-volume “Datastream” has zero-to-many “Observations”. One Observation SHALL occur in one-and-only-one “Datastream”. |
7.3.5. Requirement 9
This requirement defines the mandatory properties of the fugitive-emissions-mass “Datastream” of the reporting facility.
Requirement 9 | |
|---|---|
/req/datamodel/datastream/fugitive-emissions-mass-properties | |
A reporting facility “Thing” SHALL have a fugitive-emissions-mass “Datastream” entity that has the properties with the corresponding value and multiplicity listed in Table 11. |
Table 11 — Properties of a fugitive-emissions-mass “Datastream” entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The mass of fugitive emissions (kg) | Character string type, and the value shall be “Fugitive Emissions Mass Methane (kg)” | One |
| description | A short description of the Datastream | Character string type | One |
| observationType | The observation type of the fugitive-emissions-mass “Observation” is a ISO/OGC 19156 measurement | The value shall be compliant with OM_Measurement | One |
| phenomenonTime | This “Datastream” SHOULD have a phenomenonTime, describes the temporal interval of the phenomenon times of all observations belonging to this Datastream | TM_Period (ISO 8601 Time Interval) | One |
| unitOfMeasurement | The unit of measurement of this Datastream is kilogram | A SensorThings “unitOfMeasurement” JSON Object, with the following key-value pairs: {"uom":"kg","symbol":"Kilogram","definition":"http://qudt.org/vocab/unit/KiloGM"} | One |
7.3.6. Requirement 10
This requirement defines the direct relation between the fugitive-emissions-mass “Datastream” entity and other entity types.
Requirement 10 | |
|---|---|
/req/datamodel/datastream/fugitive-emissions-mass-relations | |
The fugitive-emissions-mass “Datastream” entity SHALL have the direct relation between the “Datastream” entity and the entities listed in Table 12. |
Table 12 — Direct relation between a fugitive-emissions-mass “Datastream” entity and other entity types
| Entity type | Relation | Description |
|---|---|---|
| Thing | One mandatory | Each fugitive-emissions-mass “Datastream” SHALL have one and only one reporting facility “Thing”. A reporting facility “Thing” SHALL have one and only one fugitive-emissions-mass “Datastream”. |
| Sensor | One mandatory | The “Observations” in a fugitive-emissions-mass “Datastream” are performed by one “Sensor”. One “Sensor” MAY be used by different Datastreams. Note: A “Sensor” in this best practice is an observation process describing the Fugitive Emissions Management Program (FEMP) that generates the observation result. |
| ObservedProperty | One mandatory | The “Observations” of a fugitive-emissions-mass “Datastream” SHALL observe the methane fugitive-emissions “ObservedProperty” as defined in Requirement 11. |
| Observation | Many optional | A fugitive-emissions-mass “Datastream” has zero-to-many “Observations”. One Observation SHALL occur in one-and-only-one “Datastream”. |
7.4. Requirements Class: ObservedProperty
Requirements class 4 | |
|---|---|
/req/datamodel/observed-property | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.4, Conformance class A.4: /conf/datamodel/observed-property |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/observed-property |
7.4.1. Requirement 11
This requirement defines the mandatory properties of the fugitive emissions “ObservedProperty”.
Requirement 11 | |
|---|---|
/req/datamodel/observed-property/properties | |
The three mandatory “Datastream” entities (i.e., number-of-fugitive-emissions, fugitive-emissions-volume, and fugitive-emissions-mass) SHALL have a related fugitive-emissions “ObservedProperty” entity that has properties with the corresponding value and multiplicity listed in Table 13. |
Table 13 — Properties of a fugitive emissions “ObservedProperty” entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The term used in AER Directive 60 to describe fugitive emissions | Character string type, and the value shall be “Fugitive Methane Emissions” | One |
| description | A description about the ObservedProperty | The value shall be “Fugitive methane emissions are the unintentional releases of methane to the atmosphere.” | One |
| definition | This property is the URI of the ObservedProperty definition. Dereferencing this URI SHOULD result in a representation of the definition of the ObservedProperty. | The value shall be “http://www.opengis.net/def/integrated-methane-sensor-web/observed-properties/fugitive-methane-emissions” | One |
7.5. Requirements Class: Observation
Requirements class 5 | |
|---|---|
/req/datamodel/observation | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.5, Conformance class A.5: /conf/datamodel/observation |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/observation |
7.5.1. Requirement 12
This requirement defines the mandatory properties of the fugitive emissions “Observations”.
Requirement 12 | |
|---|---|
/req/datamodel/observation/properties | |
The “Observations” of the three mandatory “Datastream” entity SHALL have properties with the corresponding value and multiplicity listed in Table 14. |
Table 14 — Properties of a number-of-fugitive-emissions Observation entity
| Name | Definition | data types and values | Multiplicity and use |
|---|---|---|---|
| phenomenonTime | The time period of when the “Observation” happens. | TM_Period (ISO 8601 Time Interval) | One |
| result | The number-of-fugitive-emissions | Depending on Observation type | One |
| parameters | Key-value pairs describing an event-specifc parameter. | The value SHALL be a JSON object, with a key of “Survey or Screening Type”, and the corresponding value SHALL be one of the following: “ALTFEMP”, “SITESURVEY”, “TANKSURVEY”, “WELLSCREENING” | One |
7.6. Requirements Class: FeatureOfInterest
Requirements class 6 | |
|---|---|
/req/datamodel/feature-of-interest | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.6, Conformance class A.6: /conf/datamodel/feature-of-interest |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/feature-of-interest |
7.6.1. Requirement 13
This requirement defines the mandatory properties of the “FeatureOfInterest” entity related to the “Observations” of the three mandatory “Datastreams.” In the context of fugitive emissions, the “FeatureOfInterest” of fugitive emissions “Observation” is where the leaks occur. In AER Directive 60, the “FeatureOfInterest” is modelled as a site. In some cases, a reporting facility called “Thing” can have more than one site, such as wells, controlled tanks, process units, or wellhead [AER Manual015 Figure 1] and [AER Manual015 Figure 3]. The following figure describes the relationship between a reporting facility “Thing” and “FeaturesOfInterest.”
Figure 9 — Thing and FeatureOfInterest Relationship
An Observation results in a value that is being assigned to a phenomenon. The phenomenon is a property of a feature, the latter being the FeatureOfInterest of the Observation (OGC 10-004r3 and ISO 19156:2011). In the context of this best practice, the FeatureOfInterest is the site and can be identified by the site’s location. For example, the FeatureOfInterest of a wifi-connected thermostat can be the thermostat’s location (i.e., the living room where the thermostat is located). In the case of remote sensing, FeatureOfInterest can be the geographical area or volume that is being sensed.
Requirement 13 | |
|---|---|
/req/datamodel/feature-of-interest/properties | |
The “FeatureOfInterest” entity of the “Observations” of the three mandatory “Datastreams” SHALL have the properties with the corresponding value and multiplicity listed in Table 15. |
Table 15 — Properties of a FeatureOfInterest entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | The well ID or site ID that is associated with the facility ID | CharacterString, the value SHALL be a valid well or site ID | One |
| description | Site description | CharacterString | One |
| encodingType | The IANA media type for GeoJSON | Character string type, and the value shall be “application/geo+json” | One |
| feature | The GeoJSON polygon [RFC7946] represents the site boundary | A GeoJSON Polygon object, and the value of the GeoJSON Polygon coordinates shall be the boundary of the site or well | One |
7.7. Requirements Class: Sensor
Requirements class 7 | |
|---|---|
/req/datamodel/sensor | |
| Obligation | requirement |
| Target type | JSON Object Instance |
| Conformance test | Annex A.7, Conformance class A.7: /conf/datamodel/sensor |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/req/datamodel/sensor |
7.7.1. Requirement 14
This requirement defines the mandatory properties of the “Sensor” entity.
NOTE The “Sensor” entity in this best practice is not an instrument, but rather it SHALL be an observation process ISO/OGC 19156:2001 OM_Process described by the Fugitive Emissions Management Program (FEMP) that generates the observation result.
Requirement 14 | |
|---|---|
/req/datamodel/sensor/properties | |
The “Sensor” SHALL have the properties with the corresponding value and multiplicity listed in Table 16. |
Table 16 — Properties of a Sensor entity
| Name | Definition | Data types and values | Multiplicity and use |
|---|---|---|---|
| name | Provides a label for the “Sensor” entity, and it should be the descriptive name of the FEMP that generates the fugitive emissions observation results | CharacterString | One |
| description | The description of the FEMP | CharacterString | One |
| encodingType | The encoding type of the metadata property. | Character string type, and the value shall be “application/pdf” or “text/html” | One |
| metadata | This value depends on the value of the encodingType. The value SHALL be a resolvable URI, linking to either a PDF document or an HTML page, describing the FEMP used to generate the fugitive emissions observation results. | The value SHALL be a resolvable URI. | One |
Annex A
(informative)
Conformance Class Abstract Test Suite (Normative)
This section presents the conformance classes that specify the tests for assessing conformance of an implementation to the requirements specified in this OGC Best Practice document. An implementation of the OGC SensorThings API, that is compliant to this Best Practice document, needs to pass all the conformance tests defined in this section as well as the OGC SensorThings API Part 1: Sensing Version 1.1 Abstract Test Suite.
A.1. Conformance Class: Thing
Conformance class A.1 | |
|---|---|
/conf/datamodel/thing | |
| Requirements class | /req/datamodel/thing |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/thing |
Abstract test A.1 | |
|---|---|
/conf/datamodel/thing/properties | |
| Requirement | /req/datamodel/thing/properties |
| Test type | Conformance |
| Test purpose | Verify that the Thing entity has mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the entire JSON object of the Thing entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.2 | |
|---|---|
/conf/datamodel/thing/relations | |
| Requirement | /req/datamodel/thing/relations |
| Test type | Conformance |
| Test purpose | Verify that the Thing entity has mandatory relations as defined in this OGC Best Practice document. |
| Test method | Inspect the entire JSON object of each Thing entity set to determine if each entity has the mandatory relations defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.2. Conformance Class: Location
Conformance class A.2 | |
|---|---|
/conf/datamodel/location | |
| Requirements class | /req/datamodel/location |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/location |
Abstract test A.3 | |
|---|---|
/conf/datamodel/location/properties | |
| Requirement | /req/datamodel/location/properties |
| Test type | Conformance |
| Test purpose | Verify that the Location entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the Location entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.4 | |
|---|---|
/conf/datamodel/location/relations | |
| Requirement | /req/datamodel/location/relations |
| Test type | Conformance |
| Test purpose | Verify that the Location entity has the mandatory relations as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of each Location entity set to determine if each entity has the mandatory relations defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.3. Conformance Class: Datastream
Conformance class A.3 | |
|---|---|
/conf/datamodel/datastream | |
| Requirements class | /req/datamodel/datastream |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/datastream |
Abstract test A.5 | |
|---|---|
/conf/datamodel/datastream/number-of-fugitive-emissions-properties | |
| Requirement | /req/datamodel/datastream/number-of-fugitive-emissions-properties |
| Test type | Conformance |
| Test purpose | Verify that each number-of-fugitive-emissions Datastream entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the number-of-fugitive-emissions Datastream entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.6 | |
|---|---|
/conf/datamodel/datastream/number-of-fugitive-emissions-relations | |
| Requirement | /req/datamodel/datastream/number-of-fugitive-emissions-relations |
| Test type | Conformance |
| Test purpose | Verify that each number-of-fugitive-emissions Datastream entity has the mandatory relations as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of each number-of-fugitive-emissions Datastream entity set to determine if each entity has the mandatory relations defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.7 | |
|---|---|
/conf/datamodel/datastream/fugitive-emissions-volume-properties | |
| Requirement | /req/datamodel/datastream/fugitive-emissions-volume-properties |
| Test type | Conformance |
| Test purpose | Verify that each fugitive-emissions-volume Datastream entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the fugitive-emissions-volume Datastream entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.8 | |
|---|---|
/conf/datamodel/datastream/fugitive-emissions-volume-relations | |
| Requirement | /req/datamodel/datastream/fugitive-emissions-volume-relations |
| Test type | Conformance |
| Test purpose | Verify that each fugitive-emissions-volume Datastream entity has the mandatory relations as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of each fugitive-emissions-volume Datastream entity set to determine if each entity has the mandatory relations defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.9 | |
|---|---|
/conf/datamodel/datastream/fugitive-emissions-mass-properties | |
| Requirement | /req/datamodel/datastream/fugitive-emissions-mass-properties |
| Test type | Conformance |
| Test purpose | Verify that each fugitive-emissions-mass Datastream entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the fugitive-emissions-mass Datastream entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Abstract test A.10 | |
|---|---|
/conf/datamodel/datastream/fugitive-emissions-mass-relations | |
| Requirement | /req/datamodel/datastream/fugitive-emissions-mass-relations |
| Test type | Conformance |
| Test purpose | Verify that each fugitive-emissions-mass Datastream entity has the mandatory relations as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of each fugitive-emissions-mass Datastream entity set to determine if each entity has the mandatory relations defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.4. Conformance Class: ObservedProperty
Conformance class A.4 | |
|---|---|
/conf/datamodel/observed-property | |
| Requirements class | /req/datamodel/observed-property |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/observed-property |
Abstract test A.11 | |
|---|---|
/conf/datamodel/observed-property/properties | |
| Requirement | /req/datamodel/observed-property/properties |
| Test type | Conformance |
| Test purpose | Verify that the ObservedProperty entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the ObservedProperty entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.5. Conformance Class: Observation
Conformance class A.5 | |
|---|---|
/conf/datamodel/observation | |
| Requirements class | /req/datamodel/observation |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/observation |
Abstract test A.12 | |
|---|---|
/conf/datamodel/observation/properties | |
| Requirement | /req/datamodel/observation/properties |
| Test type | Conformance |
| Test purpose | Verify that the Observation entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the Observation entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.6. Conformance Class: FeatureOfInterest
Conformance class A.6 | |
|---|---|
/conf/datamodel/feature-of-interest | |
| Requirements class | /req/datamodel/feature-of-interest |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/feature-of-interest |
Abstract test A.13 | |
|---|---|
/conf/datamodel/feature-of-interest/properties | |
| Requirement | /req/datamodel/feature-of-interest/properties |
| Test type | Conformance |
| Test purpose | Verify that the FeatureOfInterest entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the FeatureOfInterest entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
A.7. Conformance Class: Sensor
Conformance class A.7 | |
|---|---|
/conf/datamodel/sensor | |
| Requirements class | /req/datamodel/sensor |
| Dependency | http://www.opengis.net/spec/iot_sensing/1.1/conf/datamodel/sensor |
Abstract test A.14 | |
|---|---|
/conf/datamodel/sensor/properties | |
| Requirement | /req/datamodel/sensor/properties |
| Test type | Conformance |
| Test purpose | Verify that the Sensor entity has the mandatory properties as defined in this OGC Best Practice document. |
| Test method | Inspect the full JSON object of the Sensor entity set to determine if each entity has the mandatory properties defined in the corresponding requirement. Pass if no errors are reported. Fail otherwise. |
Annex B
(informative)
Revision History
Table B.1
| Date | Release | Editor | Primary clauses modified | Description |
|---|---|---|---|---|
| 2021-11-19 | 0.1 | Steve Liang | all | initial version |
Bibliography
[1] National Academies of Sciences Engineering, and Medicine: Improving Characterization of Anthropogenic Methane Emissions in the United States. The National Academies Press (2018). https://doi.org/10.17226/24987.
[2] AER: Directive 60 — Upstream Petroleum Industry Flaring, Incinerating, and Venting. Alberta Energy Regulator (2022). https://static.aer.ca/prd/documents/directives/Directive060.pdf
[3] GoA: Alberta Township Survey (ATS) System. Government of Alberta (2022). https://www.alberta.ca/alberta-township-survey-system.aspx
[4] Atherton, E., Risk, D., Fougère, C., Lavoie, M., Marshall, A., Werring, J., Williams, J. P., and Minions, C.: Mobile measurement of methane emissions from natural gas developments in northeastern British Columbia, Canada. Atmospheric Chemistry and Physics, 17, 12405–12420 (2017). https://doi.org/10.5194/acp-17-12405-2017.
[5] BC Oil and Gas Commission: Oil & Gas Glossary and Definitions VERSION 1.11. Province of British Columbia (2020). https://www.bcogc.ca/files/publications/Factsheets/Documentation-Glossary-v1.12-Dec-Release-2020.pdf
[6] ECC: Canada’s methane regulations. Government of Canada (2018). https://www.canada.ca/en/environment-climate-change/services/canadian-environmental-protection-act-registry/proposed-methane-regulations-additional-information.html
[7] Conleyg, S., Francoi, G., Faloonad, I., R. Blakej. Peischland T. B.: Methane emissions from the 2015 Aliso Canyon blowout in Los Angeles, CA. Science, vol. 351, issue 6279, pp. 1317-1320 (2016). https://www.science.org/doi/10.1126/science.aaf2348
[8] Brantley, H.L., Thoma, E.D., Squier, W.C., Guven, B. B., Lyon, D.: Assessment of Methane Emissions from Oil and Gas Production Pads using Mobile Measurements. Environmental Science & Technology 48(24), 14508-14515 (2014)
[9] IPCC: IPCC- AR4 Climate Change. Intergovernmental Panel on Climate Change (2007). http://www.ipcc.ch/report/ar4/
[10] Johnson, M.R., Tyner, D. R., Szekeres, A.J.: . “Blinded evaluation of airborne methane source detection using Bridger Photonics LiDAR”. Carleton University (2021)
[11] Varon D. J., Jacob, D.J., Jervis, D., McKeever, J.: Quantifying Time-Averaged Methane Emissions from Individual Coal Mine Vents with GHGSat-D Satellite Observations, Environmental Science & Technology 54 (16), 10246-10253 (2020). https://doi.org/10.1021/acs.est.0c01213
[12] EPA: Method 21 — Volatile Organic Compound Leaks, https://www.epa.gov/emc/method-21-volatile-organic-compound-leaks, last accessed 2022/07/11.
[13] Reed, C., Botts, M., Percivall, G., Davidson, J.: OGC Sensor Web Enablement: Overview and High Level Architecture, OGC 07-165r1. Open Geospatial Consortium (2013). https://docs.ogc.org/wp/07-165r1/
[14] Regulations Respecting Reduction in the Release of Methane and Certain Volatile Organic Compounds, https://laws-lois.justice.gc.ca/eng/regulations/SOR-2018-66/FullText.html, last accessed 2022-07-11
[15] Aldhafeeri, T.; Tran, M.-K.; Vrolyk, R.; Pope, M.: A Review of Methane Gas Detection Sensors: Recent Developments and Future Perspectives. Inventions 5, no. 3: 28., MDPI Publishing (2020). https://doi.org/10.3390/inventions5030028
[16] Zimmerle, D., Vaughn, T., Bell, C., Bennett, K., Deshmukh, P., Thomas, E.: Detection Limits of Optical Gas Imaging for Natural Gas Leak Detection in Realistic Controlled Conditions. Environmental Science & Technology 54 (18), 11506-11514 (2020). https://doi.org/10.1021/acs.est.0c01285
[17] Global Methane Initiative: Global Methane Emissions and Mitigation Opportunities, https://www.globalmethane.org/documents/gmi-mitigation-factsheet.pdf, last accessed 2022-07-11