2.1.  Introduction

The STAplus 1.0 standard defines an extension to the OGC Standards OGC SensorThings API Part 1: Sensing (SensorThings API v1.0) and OGC SensorThings API Part 1: Sensing Version 1.1 (SensorThings API v1.1) by adding additional entity types to the data model. Access to the STAplus entities via HTTP is defined in the Read, Create, Update, and Delete Requirements Classes. The use of MQTT for STAplus entities is defined in the MQTT Requirements Class. A default default-CRS is defined via the Default-CRS Requirements Class and additional geometry encodings are defined in the Geometry FG and Geometry WKT Requirements Class. The Authentication Requirements Class supports the unique identification of acting users. The Business Logic Requirements Class supports the textual description of the implemented business logic. An example of such a Business Logic is described in the OGC Best Practice for using SensorThings API with Citizen Science.

2.2.  STAplus 1.0 Conformance Classes

This OGC Standard defines one mandatory and several optional conformance classes.

Conformance with this Standard shall be checked using all the relevant tests specified in Annex A of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC Standard, a software implementation shall choose to implement:

• The one mandatory conformance class Core;

• Any one of the optional conformance classes; and

• Pass all applicable tests as defined in Annex A.

This is the list of STAplus Conformance Classes.

• Core (mandatory): This Conformance Class incorporates the capabilities to support the Read of STAplus entities via HTTP. It also includes the Default-CRS Requirements Class to ensure interoperability with geometry encodings in the feature and location properties.

• Create (optional): This Conformance Class supports to create STAplus entities via HTTP.

• Update (optional): This Conformance Class supports to update STAplus entities via HTTP.

• Delete (optional): This Conformance Class supports to delete STAplus entities via HTTP.

• Authentication (optional): This Conformance Class supports user authentication and their unique identification.

• Geometry-FG (optional): This Conformance Class supports the alternative geometry encoding for the feature and location properties based on Features and their Geometries.

  NOTE:    This Conformance Class remains informative until OGC Features and Geometries JSON - Part 1: Core is an adopted OGC Standard.

• Geometry-WKT (optional): This Conformance Class supports the alternative geometry encoding for the feature and location properties based on Well Known Text (WKT) as defined in Geographic information - Simple features access - Part 1: Common architecture.

• MQTT Subscribe STA v1.0 (optional): This Conformance Class supports a client to receive STAplus entity changes via MQTT as defined in OGC SensorThings API Part 1: Sensing.

• MQTT Subscribe STA v1.1 (optional): This Conformance Class supports a client to receive STAplus entity changes via MQTT as defined in OGC SensorThings API Part 1: Sensing Version 1.1.

• Business Logic (optional): This Conformance Class supports that the implementation’s business logic is described in English text to help developers understand the details of CRUD access.

4.1.  Terms and definitions

4.1.1. Campaign

An event or an activity that results in or is linked to a collection of MultiDatastream, Datastream, and/or ObservationGroup. A campaign is commonly limited in space and time and can be managed by one party.

4.1.2. License

An agreement between a party and other parties to gain access and use primarily observations but also groups of observations and campaigns. The agreement can include, among others, clauses about how to share data with others not involved in the licensing agreement, the capability to execute commercial activities, the authorization to share modified versions of the data, and the need for attributing the original authors. Associating a license with a MultiDatastream, Datastream expresses re-use conditions for all associated observations. Associating a license to an ObservationGroup or a Campaign expresses their re-use conditions.

4.1.3. ObservationGroup

A collection of observations that are grouped together for a particular purpose.

4.1.4. Ownership

The right of possession over entities such as things, campaigns, observation groups, and other entities related to them. Ownership is required to properly manage create, update, and delete operations in a multi-user environment.

4.1.5. Party

A user, interacting with the service facilitating the creation of observations and managing owned resources. A party can own a thing, decide on the license of a datastream of observations, manage a campaign, be responsible of an observation group, etc.

4.1.6. Relation

A relationship established between two observations or an observation and an external resource for a particular reason.

4.2.  Abbreviated terms

API

Application Programming Interface

CC

Creative Commons

CRUD

Create Read Update Delete

DID

Decentralized Identifier

GDPR

European General Data Protection Regulation

MQTT

Message Queuing Telemetry Transport

STA

Sensor Things API

STAplus

Sensor Things API PLUS extension

5.1.  Identifiers

The normative provisions in this standard are denoted by the URI

http://www.opengis.net/spec/sensorthings-staplus/1.0

All requirements and conformance tests that appear in this document are denoted by absolute URIs which are compliant to this base.

6.1.  Concept of Ownership

In Citizen Science, users participate in campaigns or projects, offered by different Citizen Science portals. These portals, typically operated by different organizations, have one feature in common: Contributions, uploaded by users are associated with the user and the ownership does not change. There is an explicit relationship between the observation (resource) and the user. Expressed as ownership, users can undertake certain actions on their resources.

With the SensorThings API, observations are linked to a data stream that is linked to a sensor which belongs to a thing. The data model does not provide a class that supports explicitly linking a user to an observation. This limits the use of the STA data model and API to a simple use case: One operator can create data objects and all other users have read-only access. This limits the options for applications to interact with the API.

Even though the STA v1.1 data model offers the generic use of properties, expressing ownership buried in properties is not wise. Storing personal data in those properties makes compliance with the European General Data Protection Regulation (GDPR) difficult. This is because it is unclear if properties store personal data and therefore fall under GDPR. Also, this decreases interoperability tremendously as an application developer would need to know which attribute can be used to express ownership. Lastly, querying observations based on unstructured properties is extremely complex and difficult.

Therefore, the STAplus extension defines the class Party for expressing the association from a Datastream or MultiDatastream to a user. All uploaded observations, associated to a Datastream instance belong to the party associated to the Datastream. Parties can also own Things and ObservationGroups, and participate in Campaigns.

6.2.  Improving F A I R

In general, there are many aspects when it comes to ensuring the reusability of (existing) data. Licensing is a fundamental aspect, not just in the context of Citizen Science. Very many users contribute to Citizen Science with the motivation of doing meaningful things for the common good. At the same time, users like to be credited when it comes to re-use of their contribution(s). Therefore, most contributions in Citizen Science are freely accessible (open access) and the re-use is “open” but restrictions may apply. In order to get credited, users might associate a license like CC-BY (Creative Commons Attribution License). Even though the data is still freely accessible, there is a condition that must be followed as expressed in the license.

6.3.  Licensing

Applying licensing is a difficult task. In particular in a deployment like Citizen Science, where users may decide which license gets applied to their contributions. Too many different and perhaps incompatible licenses exist which may risk a proper re-use. STAplus supports licensing in a flexible way by only demanding that a license has unique URI based identifier (definition property). Even though STAplus does not constraint which license types to use, an implementation should constraint the proliferation of licenses via the Business Logic. As illustrated in the OGC Best Practice for using SensorThings API with Citizen Science, an implementation may create all License entities and disallow that users create their own licenses. For the Creative Commons licensing framework, this leads to the existence of seven recommended licenses which ensures a proper re-use as license compatibility can easily be computed.

When it comes to attribution licenses, the re-use requires the provision of a citation to name the original author. For the Creative Commons licensing framework, best practices exist that do not need any additional consideration in the STAplus data model. However, a user may want to be able to express an individual attribution to be used with the license. Such information — the actual attribution text — could be stored in the properties of the License entity. But this would require that the business logic allows creation of License entities. To make sure that still only a particular licensing framework can be used, the Business Logic could allow a user to create a License entity and store the individual citation into a property like attributionText but constrain the definition property to those URIs that include the attribution license building block.

6.4.  Creating Observation Groups

When contributing to Citizen Science, the relevant information is often a set or bag of individual observations that belong together — i.e., may belong to the same observation event. For example, a camera trap event consists of a picture, a textual observation expanding the likelihood of species prediction and sensor readings for environmental context (temperature, humidity, luminance, air pressure, GPS location). All of these observations potentially created by different sensors could be grouped when created at the same time/location.

Another use case for applying grouping to existing observations is to create a package of observations for the purpose of building the fundamentals for research or to be used in workflows. For researching and later evaluation of a particular phenomenon, the same group of observations could be exchanged via the grouping concept.

Also, over time a user community might link other observations and even provide cross links to other databases. These can be semantically tagged with the Relation entity which is described next in this document.

The STAplus extension defines a flexible grouping concept by adding the ObservationGroup entity to the STA data model.

6.5.  Expressing Relations

Supporting search based on explicit relations is important for Citizen Science. While the STA ObservedProperty entity supports links to external resources, the Observation entity does not. The STAplus Relation entity adds external linking support to Observation entities.

The Relation entity supports creating generic “– to” relation from an Observation entity. The “to” can point to another observation or to any external resource. This allows the generic expression of meaning, leveraging existing semantic concepts that exist elsewhere, for example Dublin or Darwin Core. Adding relations to an ObservationGroup entity helps to reason how observations are related even if they were not observed in a same observation event, but instead were linked later to a particular community process (as linking to other databases).

The use of Relation entities as defined in STAplus can be applied to already existing SensorThings deployments to semantically enrich the data.

6.6.  Data Model Extension

The STAplus data model extension allows expressing the following additional characteristics.

• Party: The Party entity supports linking a user to a Datastream, MultiDatastream, Campaign or ObservationGroup and Thing.

• License: The License entity supports expressing reuse conditions by linking a License to a Datastream, MultiDatastream, and / or to a ObservationGroup. A License on a Datastream has the result that all Observation entities of that Datastream or MultiDatastream (as well as entities of the Thing, Sensor, and ObservedProperty) have the associated license. A License on an ObservationGroup gives the bag or set of Observations (represented by the ObservationGroup) a license for reuse. Note that the license for each Observation must still be followed.

• Union: The ObservationGroup entity supports packaging individual Observations as a bag or set either as deep copy or via linking

• Semantics: The Relation entity supports expressing relationships between Observation entities using the “-to” role type. It is also possible to create relations between Observation entities and external resources using the URI scheme. This allows in particular expressing a relation to any entity of the database (via their external URI). Relation entities can exist on their own or be included into an ObservationGroup to enrich a bag or set of Observation entities.

• Campaign: The Campaign entity is a container of Datastream, MultiDatastream and ObservationGroup entities that supports organizing a campaign or project and to provide metadata as well as legal information such as terms of use and a privacy statement, in case it is relevant.

7.1.  Requirements Class Entity Control Information

Requirements class 1: Entity Control Information
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/core
Prerequisite	OGC SensorThings API Part 1: Sensing or OGC SensorThings API Part 1: Sensing Version 1.1
Normative statement	Requirement 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/common-control-information

Requirement 1
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/common-control-information
Included in	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Statement	Each STAplus entity SHALL have the following common control information listed in Table 1.

Table 1 — Common control information

Name	Definition	Data type	Multiplicity and use
id	id is the system-generated identifier of an entity that is unique among the entities of the same entity type in a SensorThings API service instance.	Any	One (mandatory)
selfLink	selfLink is the absolute URL of an entity that is unique among all other entities.	URL	One (mandatory)
navigationLink	navigationLink is the relative or absolute URL that retrieves content of related entities.	URL	One-to-many (mandatory)

7.2.  Requirements Class Party

The Party entity can be used to represent acting users and to model ownership.

One example for ownership is that a satellite Thing is owned by a space agency. This ownership may entitle the space agency to be the only party that can update the thing’s location. Other parties can then mount their sensor on the satellite and provide Datastream, or MultiDatastream entities to upload observations generated by their sensors. Via the association to the Datastream resp. MultiDatastream their ownership of the observations is guaranteed. By associating a license to the (multi)datastream, they could also define re-use conditions.

Requirements class 2: Party
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/party
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 2: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/party/properties Requirement 3: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/party/relations

Requirement 2
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/party/properties
Included in	Requirements class 2: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/party
Statement	Each Party entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 2.

Table 2 — Properties of a Party entity

Name	Definition	Data type	Cardinality and use
role	This is the role of the party	CharacterString [‘individual’, ‘institutional’]	One (mandatory)
description	This is a short description of the party	CharacterString	Zero or One (optional)
displayName	A property commonly used for saluting the party	CharacterString	Zero or One (optional)
authId	A system wide unique property (e.g., REMOTE_USER or SUB from authentication) to uniquely identify the party	CharacterString	Zero or One (optional)

Requirement 3
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/party/relations
Included in	Requirements class 2: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/party
Statement	An implementation SHALL allow each Party to have direct associations to other entity types listed in Table 3 and Table 4.

Table 3 — Direct relation from a Party entity to other entity types

Relation name	Entity type	Cardinality	Description
Datastreams	Datastream	Zero to Many	A Party has zero-to-many Datastreams.
MultiDatastreams (optional)	MultiDatastream	Zero to Many	A Party has zero-to-many MultiDatastreams.
Things	Thing	Zero to Many	A Party has zero-to-many Things.
ObservationGroups	ObservationGroup	Zero to Many	A Party has zero-to-many ObservationGroups.
Campaigns	Campaign	Zero to Many	A Party has zero-to-many Campaigns.

Table 4 — Direct relation from a SensorThings entity type to Party

Relation name	Source Entity type	Cardinality	Description
Party	Datastream	Zero or One	A Datastream has zero-to-one Party.
Party (optional)	MultiDatastream	Zero or One	A MultiDatastream has zero-to-one Party.
Party	Thing	Zero or One	A Thing has zero-to-one Party.

7.3.  Requirements Class License

The License entity can be used to associate a re-use condition to observations via a Datastream or MultiDatastream. It can also be used to express re-use conditions for an ObservationGroup or Campaign.

Requirements class 3: License
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/license
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 4: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/license/properties Requirement 5: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/license/relations

Requirement 4
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/license/properties
Included in	Requirements class 3: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/license
Statement	Each License entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 5.

Table 5 — Properties of a License entity

Name	Definition	Data type	Cardinality and use
name	A property provides a label for License entity, commonly a descriptive name.	CharacterString	One (mandatory)
description	This is a short description of the corresponding License entity.	CharacterString	Zero or One (optional)
definition	This is a URI referencing the License entity.	URI	One (mandatory)
logo	This is the URI of the logo for the License entity.	CharacterString	Zero or One (optional)
attributionText	The text to be used as attribution when mandated by the license.	CharacterString	Zero or One (optional)

Requirement 5
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/license/relations
Included in	Requirements class 3: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/license
Statement	An implementation SHALL allow each License to have direct associations to other entity types listed in Table 6 and Table 7.

Table 6 — Direct relation from a License entity to other entity types

Relation name	Entity type	Cardinality	Description
Datastreams	Datastream	Zero to Many	A License has zero-to-many Datastreams.
MultiDatastreams (optional)	MultiDatastream	Zero to Many	A License has zero-to-many MultiDatastreams.
Campaigns	Campaign	Zero to Many	A License has zero-to-many Campaigns.
ObservationGroups	ObservationGroup	Zero to Many	A License has zero-to-many ObservationGroups.

Table 7 — Direct relation from a SensorThings entity type to License

Relation name	Source Entity type	Cardinality	Description
License	Datastream	Zero or One	A Datastream MAY have zero-to-one License.
License (optional)	MultiDatastream	Zero or One	A MultiDatastream MAY have zero-to-one License.

7.4.  Requirements Class ObservationGroup

The ObservationGroup entity is a bag of observations and/or relations that can be shared and re-used.

Requirements class 4: ObservationGroup
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/group
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 6: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/group/properties Requirement 7: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/group/relations

Requirement 6
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/group/properties
Included in	Requirements class 4: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/group
Statement	Each ObservationGroup entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8.

Table 8 — Properties of a ObservationGroup entity

Name	Definition	Data type	Cardinality and use
name	A property provides a label for ObservationGroup entity, commonly a descriptive name.	CharacterString	One (mandatory)
description	This is a short description of the corresponding ObservationGroup entity.	CharacterString	One (mandatory)
purpose	This is a short description of the purpose for the ObservationGroup entity.	CharacterString	Zero or One (optional)
creationTime	This is the time when the ObservationGroup was created.	TM Instant	One (mandatory)
endTime	This is the end time of the ObservationGroup entity. The exact semantics depend on the business logic.	TM Instant	Zero or One (optional)
termsOfUse	Express the term of use for the ObservationGroup entity.	CharacterString	Zero or One (optional)
privacyPolicy	Express the term of use for personal data that are contained in the ObservationGroup entity.	CharacterString	Zero or One (optional)
dataQuality	The quality information of the observations in the group	JSON Object	Zero or One (optional)
properties	The SensorThings API definition applies	JSON Object	Zero or One (optional)

Requirement 7
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/group/relations
Included in	Requirements class 4: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/group
Statement	An implementation SHALL allow each ObservationGroup to have direct associations to other entity types listed in Table 9 and Table 10.

Table 9 — Direct relation from a ObservationGroup entity to other entity types

Relation name	Entity type	Cardinality	Description
License	License	Zero or One	A ObservationGroup has zero-to-one License.
Observations	Observation	Zero to Many	A ObservationGroup has zero-to-many Observations.
Relations	Relation	Zero to Many	A ObservationGroup has zero-to-many Relations.
Party	Party	Zero or One	A ObservationGroup has zero-to-one Party.
Campaigns	Campaign	Zero to Many	A ObservationGroup has zero-to-many Campaigns.

Table 10 — Direct relation from a SensorThings entity type to ObservationGroup

Relation name	Source Entity type	Cardinality	Description
ObservationGroups	Observation	Zero to Many	An Observation has zero-to-many ObservationGroups.

7.5.  Requirements Class Relation

The Relation entity can either be used to describe relationships between two observations, or one observation and a resolvable external resource identified by a URI.

Requirements class 5: Relation
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/relation
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 8: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/relation/properties Requirement 9: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/relation/relations

Requirement 8
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/relation/properties
Included in	Requirements class 5: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/relation
Statement	Each Relation entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 11.

Table 11 — Properties of a Relation entity

Name	Definition	Data type	Cardinality and use
role	This URI references the definition of the Relation entity.	URI	One (mandatory)
description	This is a short description of the corresponding Relation entity.	CharacterString	Zero or One (optional)
externalResource	This URI references the external resource for the Relation entity.	URI	Zero or One (optional)
properties	The SensorThings API definition applies	JSON Object	Zero or One (optional)
NOTE:    The subject of a relation entity is always an observation. For expressing the object of a relation, the Object relation XOR externalResource property must be used.

Requirement 9
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/relation/relations
Included in	Requirements class 5: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/relation
Statement	An implementation SHALL allow each Relation to have direct associations to other entity types listed in Table 12.

Table 12 — Direct relation from a Relation entity to other entity types

Relation name	Entity type	Cardinality	Description
Subject	Observation	Zero or One	A Relation SHALL have one Subject.
Object	Observation	Zero or One	A Relation has zero-to-one Object.
ObservationGroups	ObservationGroup	Zero to Many	A Relation has zero-to-many ObservationGroups.
NOTE:    For expressing the object of a relation, the following constrain applies: Object relation XOR externalResource property.

Table 13 — Direct relation from a SensorThings entity type to Relation

Relation name	Source Entity type	Cardinality	Description
Objects	Observation	Zero to Many	An Observation/Subject has zero-to-many Relation/Objects.
Subjects	Observation	Zero to Many	An Observation/Object has zero-to-many Relation/Subjects.

7.6.  Requirements Class Campaign

The Campaign entity is a container of Datastream or MultiDatastream entities. A Campaign can have a particular purpose and a managing party.

Requirements class 6: Campaign
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/campaign
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 10: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/campaign/properties Requirement 11: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/campaign/relations

Requirement 10
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/campaign/properties
Included in	Requirements class 6: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/campaign
Statement	Each Campaign entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 14.

Table 14 — Properties of a Campaign entity

Name	Definition	Data type	Cardinality and use
name	A property provides a label for Campaign entity, commonly a descriptive name.	CharacterString	One (mandatory)
description	This is a short description of the corresponding Campaign entity.	CharacterString	One (mandatory)
classification	Determines if the data stream(s), multi data stream(s) or group(s) of the Campaign entity contain sensitive information.	ValueCode	Zero or One (optional)
termsOfUse	Express the term of use for the Campaign entity.	CharacterString	One (mandatory)
privacyPolicy	Express the terms of use for personal data that are contained in the Campaign entity.	CharacterString	Zero or One (optional)
url	This is the URL for the Campaign entity that provides additional information that cannot be captured in this entity alone.	URL	Zero or One (optional)
creationTime	This is the time when the Campaign entity was created.	TM Instant	One (mandatory)
startTime	This is the starting time of the Campaign entity. The exact semantics depend on the business logic.	TM Instant	Zero or One (optional)
endTime	This is the ending time of the Campaign entity. The exact semantics depend on the business logic.	TM Instant	Zero or One (optional)

Requirement 11
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/campaign/relations
Included in	Requirements class 6: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/campaign
Statement	An implementation SHALL allow each Campaign to have direct associations to other entity types listed in Table 15 and Table 16.

Table 15 — Direct relation from a Campaign entity to other entity types

Relation name	Entity type	Cardinality	Description
Datastreams	Datastream	Zero to Many	A Campaign has zero-to-many Datastreams.
MultiDatastreams (optional)	MultiDatastream	Zero to Many	A Campaign has zero-to-many MultiDatastreams.
Party	Party	Zero or One	A Campaign has zero-to-one Party.
ObservationGroups	ObservationGroup	Zero to Many	A Campaign has zero-to-many ObservationGroup.
License	License	Zero or One	A Campaign MAY have zero-to-one License.

Table 16 — Direct relation from a SensorThings entity type to Campaign

Relation name	Source Entity type	Cardinality	Description
Campaigns	Datastream	Zero to Many	A Datastream has zero-to-many Campaigns.
Campaigns (optional)	MultiDatastream	Zero to Many	A MultiDatastream has zero-to-many Campaigns.

8.1.  Overview

As many IoT devices are resource-constrained, the SensorThings API adopts the efficient REST web service style. That means the Read, Create, Update, Delete actions can be performed on a STAplus entity type.

8.2.  Requirements Class Read

Requirements class 7: Read
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/read
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statement	Requirement 12: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/read/entity

Requirement 12
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/read/entity
Included in	Requirements class 7: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/read
Statement	To read a STAplus entity or a collection of STAplus entities, the client SHALL send a HTTP GET request to that entity or the collection’s URL. If the target URL for the collection is a navigationLink, the entity is automatically linked to the entity or entities represented by the navigationLink. Upon successful completion, the response SHALL contain the representation of the entity or entities.

8.3.  Requirements Class Create

Requirements class 8: Create
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/create
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 2: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/create
Prerequisite	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information
Normative statements	Requirement 13: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/entity Requirement 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/link-to-existing-entities Requirement 15: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/deep-insert Requirement 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/deep-insert-status-code

Requirement 13
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/entity
Included in	Requirements class 8: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/create
Statement	To create a STAplus entity in a collection, the client SHALL send a HTTP POST request to that collection’s URL. The POST body SHALL contain a single valid entity representation. If the target URL for the collection is a navigationLink, the new entity is automatically linked to the entity containing the navigationLink. Upon successful completion, the response SHALL contain a HTTP location header that contains the selfLink of the created entity. Upon successful completion the service SHALL respond with either 201 Created, or 204 No Content. Adapted from OData Version 4.01. Part 1: Protocol, §11.4.2 Create an Entity

Requirement 14
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/link-to-existing-entities
Included in	Requirements class 8: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/create
Statement	A STAplus implementation that supports entity creation SHALL support linking new STAplus entities to existing entities upon creation. To create a new entity with links to existing entities in a single request, the client SHALL include the unique identifiers of the related entities associated with the corresponding navigation properties in the request body.

Requirement 15
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/deep-insert
Included in	Requirements class 8: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/create
Statement	A request to create a STAplus entity that includes related entities, represented using the appropriate inline representation, is referred to as a “deep insert”. A STAplus implementation that supports entity creation SHALL support deep insert. If the inline representation contains a value for a computed property (i.e., id), the service SHALL ignore that value when creating the related entity. On success, the service SHALL create all entities and relate them. On failure, the service SHALL NOT create any of the entities. Adapted from OData Version 4.01. Part 1: Protocol, §11.4.2.2 Create Related Entities When Creating an Entity

Requirement 16
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/create/deep-insert-status-code
Included in	Requirements class 8: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/create
Statement	Upon successfully creating a STAplus entity, the service response SHALL contain a Location header that contains the URL of the created entity. Upon successful completion the service SHALL respond with 201 Created.

8.4.  Requirements Class Update

Requirements class 9: Update
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/update
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 3: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/update
Prerequisites	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity-put https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity-jsonpatch
Normative statements	Requirement 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity Requirement 18: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity-put Requirement 19: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity-jsonpatch

Requirement 17
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity
Included in	Requirements class 9: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/update
Statement	To update a STAplus entity in a collection a STAplus implementation SHALL follow the requirements as defined in https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity.

Requirement 18
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity-put
Included in	Requirements class 9: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/update
Statement	A STAplus implementation that supports updates with PUT SHALL follow the requirements as defined in https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity.

Requirement 19
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/update/entity-jsonpatch
Included in	Requirements class 9: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/update
Statement	A STAplus implementation that supports updates with the JSON PATCH format SHALL follow the requirements as defined in https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-update-entity-jsonpatch

8.5.  Requirements Class Delete

Requirements class 10: Delete
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/delete
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 4: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/delete
Prerequisites	Requirements class 1: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/entity-control-information https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-delete-entity
Normative statement	Requirement 20: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/delete/entity

Requirement 20
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/delete/entity
Included in	Requirements class 10: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/delete
Statement	To delete a STAplus entity in a collection a STAplus implementation SHALL follow the requirements as defined in https://docs.ogc.org/is/18-088/18-088.html#req-create-update-delete-delete-entity.

9.1.  Overview

In the context of MQTT, all STAplus entities as defined in this Standard are equivalent to the STA entities. Therefore, the implementation of MQTT capabilities must be compliant with the SensorThings API Part 1: Sensing and Sensing v1.1 Standard.

9.2.  Requirements Class MQTT Subscribe STA v1.0

Requirements class 11: MQTT Subscribe STA v1.0
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/mqtt-subscribe-sta-10
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance test 8-2: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/mqtt-subscribe-sta-10
Prerequisite	http://www.opengis.net/spec/iot_sensing/1.0/req/receive-updates-via-mqtt
Normative statement	Requirement 21: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/mqtt-subscribe-sta-10

Requirement 21
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/mqtt-subscribe-sta-10
Included in	Requirements class 11: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/mqtt-subscribe-sta-10
Statement	For the entities defined in STAplus, a STAplus implementation SHALL support the receiving of entity updates with MQTT Subscribe as defined in http://www.opengis.net/spec/iot_sensing/1.0/req/receive-updates-via-mqtt.

9.3.  Requirements Class MQTT Subscribe STA v1.1

Requirements class 12: MQTT Subscribe STA v1.1
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/mqtt-subscribe-sta-11
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance test 9-2: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/mqtt-subscribe-sta-11
Prerequisite	http://www.opengis.net/spec/iot_sensing/1.1/req/receive-updates-via-mqtt
Normative statement	Requirement 22: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/mqtt-subscribe-sta-11

Requirement 22
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/mqtt-subscribe-sta-11
Included in	Requirements class 12: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/mqtt-subscribe-sta-11
Statement	For the entities defined in STAplus, a STAplus implementation SHALL support the receiving of entity updates with MQTT Subscribe as defined in http://www.opengis.net/spec/iot_sensing/1.1/req/receive-updates-via-mqtt.

10.1.  Overview

The STAplus extension is defined based on requirements from the Citizen Science community. One major requirement from the Citizen Science community is that an implementation of STAplus can be used by many users simultaneously to read, create, update, and delete observations. To ensure integrity of all entities and to prevent inconsistencies in the observations, it is important that an implementation is not only compliant with this Standard but also has functionality that ensures entity consistency.

Even though the business logic can be very complex and most likely depend on many factors, it should be possible providing a hint to developers and guiding end users of the implementation in case a request results in an unexpected response.

As a machine readable and understandable description of the implemented business logic is preferred, the idea of the business logic requirements class is to allow the description of the logic in English text.

10.2.  Requirements Class Business Logic

Requirements class 13: Business Logic
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/business-logic
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 10: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/business-logic
Normative statements	Requirement 23: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/business-logic/definition Requirement 24: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/business-logic/location

Requirement 23
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/business-logic/definition
Included in	Requirements class 13: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/business-logic
Statement	The implementation’s business logic SHALL be described in English text.

Requirement 24
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/business-logic/location
Included in	Requirements class 13: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/business-logic
Statement	The STAplus implementation SHALL provide a JSON object in the serverSettings object on the root URI with the name http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/business-logic that contains a property href which value is the URL of the HTML page describing the business logic.

11.1.  Overview

To regulate access to entities using CRUD operations, implementations may wish to use information from user / client application authentication to make access control decisions.

In addition, some implementations may wish to link the authentication identifier (e.g., REMOTE_USER) with the Party/authId. Therefore, the STAplus authentication must provide service-wide unique user identifiers.

11.2.  Requirements Class Authentication

Requirements class 14: Authentication
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 5: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/authentication
Prerequisite	Requirements class 2: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/party
Normative statements	Requirement 25: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id Requirement 27: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-create Requirement 26: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-read Requirement 28: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-update Requirement 29: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-delete

Requirement 25
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id
Included in	Requirements class 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Statement	The STAplus authentication SHALL provide a user identifier permanent for same user but different for each user.

Requirement 26
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-read
Included in	Requirements class 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Statement	The STAplus implementation SHALL ensure that the Party/authId property is exposed in any response and can be used in STA operators such as $filter or $select.

Requirement 27
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-create
Included in	Requirements class 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Statement	The STAplus implementation SHALL overwrite any existing value and SHALL set the Party/authId property with the user’s identification value provided by the authentication (e.g., REMOTE_USER).

Requirement 28
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-update
Included in	Requirements class 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Statement	The STAplus implementation SHALL ensure that the Party/authId property cannot be changed (ensure read-only).

Requirement 29
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/authentication/id-delete
Included in	Requirements class 14: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/authentication
Statement	The STAplus implementation SHALL ensure that the Party/authId property cannot be deleted.

12.1.  Overview

The Location and FeatureOfInterest entities enable storing data objects with unspecified structure. Both entities potentially store geometry information. The STAplus extension supports multi-user interactions including the creation, updating, reading, and deletion of information. For example in Citizen Science, one service endpoint could accept that users can upload data using different applications. These applications might be developed by different parties and serve different purposes, and thus use different geometry structures and coordinate reference systems (CRS) to encode the coordinates of the geometries. This can result in the situation where the interoperability of uploaded geometry in the Location and FeatureOfInterest entities might become an issue.

For an implementation of STAplus, this situation becomes complicated when a $filter is leveraged that includes spatial conditions such as ST_Within. The filter expression does not carry any CRS information. Therefore, how does the implementation “know” how to apply a spatial filter to geometries stored in feature and location properties uploaded by different applications? Because the SensorThings data model does not define how to store CRS information inside the feature and location, it only recommends using GeoJSON. So, applying the $filter with spatial operators introduces two problems. First, the CRS data would need to be stored in a standardized location inside feature and location properties. Second, the implementation would need to apply coordinate transformation ‘on the fly’ when processing a spatial filter condition and stored geometries are encoded in different CRS. The first problem causes interoperability issues and the later inevitably causes performance issues.

To get out of this situation, the STAplus Standard defines a default-CRS based on WGS84 with axis-order longitude/latitude as defined in GeoJSON. Any uploaded geometry data encoded in the default-CRS will be stored as-is. Any uploaded geometry data encoded differently will be rejected.

To indicate that the default-CRS and GeoJSON geometry encoding is used, the encodingType property of the FeatureOfInterest and Location entity is to be used with the value application/geo+json.

In addition, the STAplus extension supports other (commonly used) encodings via the Geometry Encoding Requirements Class.

12.2.  Default-CRS Requirements Class

This Requirements Class defines the default-CRS with axis-order and its media-type.

Requirements class 15: Defaul-CRS
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/default-crs
Obligation	requirement
Target type	Target Type: Implementation
Prerequisite	GeoJSON
Normative statements	Requirement 30: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/crs-definition Requirement 31: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/axis-order Requirement 32: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/media-type Requirement 33: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/processing

Requirement 30
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/crs-definition
Included in	Requirements class 15: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/default-crs
Statement	The STAplus implementation SHALL use the GeoJSON CRS urn:ogc:def:crs:OGC::CRS84 as the default-CRS.

Requirement 31
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/axis-order
Included in	Requirements class 15: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/default-crs
Statement	The STAplus implementation SHALL use the GeoJSON axis-order with the default-CRS.

Requirement 32
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/media-type
Included in	Requirements class 15: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/default-crs
Statement	The STAplus implementation SHALL accept the media-type application/geo+json value for the encodingType property to indicate that the structuring of the FeatureOfInterest and Location entities geometry encoding is compliant with the RFC GeoJSON.

Requirement 33
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/default-crs/processing
Included in	Requirements class 15: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/default-crs
Statement	The STAplus implementation SHALL enforce the default-CRS to any geometry data contained in the FeatureOfInterest and Location entity. The STAplus implementation SHALL reject any geometry not encoded in the default-CRS without further processing.

12.3.  Geometry-FG Requirements Class

This Requirements Class defines the use of geometry encoding compliant with the OGC Draft Standard OGC Features and Geometries JSON - Part 1: Core

Requirements class 16: Geometry-FG
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 6: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/geometry-fg
Prerequisite	OGC Features and Geometries JSON - Part 1: Core
Normative statements	Requirement 34: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/media-type Requirement 35: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/default-crs Requirement 36: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/supported-crs Requirement 37: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/crs-error Requirement 38: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/processing Requirement 39: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/out

Requirement 34
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/media-type
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	The STAplus implementation SHALL accept the media-type application/vnd.ogc.fg+json as value to the encodingType property of the FeatureOfInterest and Location entities to indicate that the structuring of the geometry is be compliant with OGC Features and Geometries JSON - Part 1: Core

Requirement 35
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/default-crs
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	The STAplus implementation SHALL advertise the default-CRS on the conformance page.

Requirement 36
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/supported-crs
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	The STAplus implementation SHALL advertise the list of the supported CRS on the conformance page.

Requirement 37
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/crs-error
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	The STAplus implementation SHALL return an error if the geometry data inside feature or location properties is encoded in an unsupported CRS.

Requirement 38
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/processing
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	If necessary, the implementation SHALL apply a CRS transformation to the default-CRS if necessary before further processing or storing the geometry data.

Requirement 39
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-fg/out
Included in	Requirements class 16: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-fg
Statement	The STAplus implementation SHALL use the default-CRS to encode the feature and location geometries in a response.

12.4.  Geometry WKT Requirements Class

This Requirements Class defines the use of geometry encoding compliant with Well Known Text (WKT).

Requirements class 17: Geometry WKT
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Obligation	requirement
Target type	Target Type: Implementation
Conformance class	Conformance class 7: http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/geometry-wkt
Prerequisite	Geographic information - Simple features access - Part 1: Common architecture
Normative statements	Requirement 40: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/media-type Requirement 17-2: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/crs-defintion Requirement 42: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/default-crs Requirement 43: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/supported-crs Requirement 44: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/crs-error Requirement 45: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/value Requirement 46: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/processing Requirement 47: http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/out

Requirement 40
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/media-type
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL accept the media-type application/wkt as value for the encodingType property of the FeatureOfInterest and Location entities. NOTE:    Media type application/wkt is currently pending approval by IANA.

Requirement 41
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/crs-definition
Statement	If a non-default-CRS is used then either the CRS identifier SHALL be put into a property crs, or the CRS identifier (number) SHALL be put into a property srid of the properties property of the FeatureOfInterest or Location entity.

Requirement 42
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/default-crs
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL provide a JSON object in the serverSettings object on the root URI with the name http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/geometry-wkt that contains a property default-crs whose value represents the default-CRS identifier.

Requirement 43
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/supported-crs
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL provide a JSON object in the serverSettings object on the root URI with the name http://www.opengis.net/spec/sensorthings-staplus/1.0/conf/geometry-wkt that contains a property supported-crs of type Array which values represent the supported CRS identifiers.

Requirement 44
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/crs-error
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL return an error if the geometry data inside the FeatureOfInterest or Location is encoded in an unsupported CRS.

Requirement 45
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/value
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The WKT encoded geometry SHALL be the value of the feature or location property (the type Any is a String).

Requirement 46
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/processing
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL apply CRS transformation to the default-CRS if necessary before further processing or storing the geometry data.

Requirement 47
Identifier	http://www.opengis.net/spec/sensorthings-staplus/1.0/req/geometry-wkt/out
Included in	Requirements class 17: http://www.opengis.net/spec/sensorthings-staplus/1.0/req-class/geometry-wkt
Statement	The STAplus implementation SHALL use the default-CRS to encode the feature and location geometries in a response.