Draft: [PROPOSAL] SensorThings conformity #132
Description
What/Why
What are you proposing?
Conformity with the OGC SensorThings data model and eventually expose an API. For better standardization and interoperability with existing systems.
What users have asked for this feature?
N/A
What problems are you trying to solve?
- When an analysis of IoT Things is required, an end user wants to create a map of their Things with - for example - colour based on water level, so that they can use it in visualizations, analysises or presentations. QGIS now supports SensorThings natively which would make the connection between QGIS and SensorBucket seamless.
- When talking about the context of SensorBucket, having distinct and well defined terminology makes communicating more robust and easier to understand. Using a standard defines these terms for us.
Summarize the core use cases and user problems and needs you are trying to solve. Describe the most important user needs, pain points and jobs as expressed by the user asks above. Template: When <a situation arises> , a <type of user> wants to <do something>, so they can <expected outcome> (e.g. When searching by postal code, a buyer wants to be required to enter a valid code so they don’t waste time searching for a clearly invalid postal code.).
What is the developer experience going to be?
- Model names and terminology in the SensorBucket ecosystem will change to comply with the OGC definitions. For example a Device will become a Thing and a Measurement will become an Observation.
Does this have a REST API? If so, please describe the API and any impact it may have to existing APIs. In a brief summary (not a spec), highlight what new REST APIs or changes to REST APIs are planned. as well as any other API, CLI or Configuration changes that are planned as part of this feature.
Are there any security considerations?
- The SensorThings API is rather broad by allowing many user inputs in the API, including custom filtering query language and model relation expansion without well defined limitations. This acts as a larger-than-usual attack surface (for example for Denial-of-Service).
Are there any breaking changes to the API
- Current APIs will have to change their terminology.
If this feature will require breaking changes to any APIs, outline what those will be and why they are needed. What is the path to minimizing impact? (e.g. add new API and deprecate the old one).
What is the user experience going to be?
Describe the feature requirements and or user stories. You may include low-fidelity sketches, wireframes, APIs stubs, or other examples of how a user would use the feature via CLI, OpenSearch Dashboards, REST API, etc. Using a bulleted list or simple diagrams to outline features is okay. If this is net new functionality, call this out as well.
Are there breaking changes to the User Experience?
Will this change the existing user experience? Will this be a breaking change from a user flow or user experience perspective?
- The WIP FEWS Importer might break.
Why should it be built? Any reason not to?
- Pro: The current datamodel has many similarities to the SensorThings datamodel and opting to go for a standardization will not only broaden the available information, but also increase interoperability.
- Con: requires breaking changes
What will it take to execute?
Describe what it will take to build this feature. Are there any assumptions you may be making that could limit scope or add limitations? Are there performance, cost, or technical constraints that may impact the user experience? Does this feature depend on other feature work? What additional risks are there?
Any remaining open questions?
What are known enhancements to this feature? Any enhancements that may be out of scope but that we will want to track long term? List any other open questions that may need to be answered before proceeding with an implementation.
- SensorThings 2.0 is a Work in Progress.