TODO

Drone.io

• Setup Drone.io for GOST
• Add buid status badge to readme
• Configure Drone.io

Main

• Build/installation guide
• Test for every OGC SensorThings requirement
• More tests
• Read a config including HTTP and Database parameters
• Rest service
• In code endpoint configuration and feeding to the router
• Serve static page on home dir, going to be used for the frontend later on
• Connection to a PostgreSQL database
• Schema creation script
• Optimize database
• Parsing rest query parameters (http://www.sensorup.com/docs/#query-parameters)
• Implement all GET, POST, PATCH, DELETE operations as described by the OGC SensorThings spec
• MQTT support
• Authentication support

TODO OGC SensorThings spec

• Req 1 Each entity SHALL have the following common control information listed in (page 19) Table 8-1.
• Req 2 Each Thing entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-2.
• Req 3 Each Thing entity SHALL have the direct relation between a Thing entity and other entity types listed in Table 8-3.
• Req 4 Each Location entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-4.
• Req 5 Each Location entity SHALL have the direct relation between a Location entity and other entity types listed in Table 8-5.
• Req 6 Each HistoricalLocation entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-7.
• Req 7 Each HistoricalLocation entity SHALL have the direct relation between a Location entity and other entity types listed in Table 8-8.
• Req 8 When a Thing has a new Location, a new HistoricalLocation SHALL be created and added to the Thing automatically by the service. The current Location of the Thing SHALL only be added to HistoricalLocation automatically by the service, and SHALL not be created as HistoricalLocation directly by user.
• Req 9 Each Datastream entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-9.
• Req 10 Each Datastream entity SHALL have the direct relation between a Datastream entity and other entity types listed in Table 8-10.
• Req 8 Each Sensor entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-12.
• Req 9 Each Sensor entity SHALL have the direct relation between a Sensor entity and other entity types listed in Table 8-13.
• Req 10 Each ObservedProperty entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-15.
• Req 11 Each ObservedProperty entity SHALL have the direct relation between a ObservedProperty entity and other entity types listed in Table 8-16.
• Req 12 Each Observation entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-17.
• Req 13 Each Observation entity SHALL have the direct relation between an Observation entity and other entity types listed in Table 8-18.
• Req 14 Each FeatureOfInterest entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 8-19.
• Req 15 Each FeatureOfInterest entity SHALL have the direct relation between a FeatureOfInterest entity and other entity types listed in Table 8-20.
• Req 16 An OGC SensorThings API service SHALL support all the resource path usages listed in Section 9.2.
• Req 17 OGC SensorThings API services are hypermedia driven services that return URLs to the client. If a client subsequently requests the advertised resource and the URL has expired, then the service SHOULD respond with 410 Gone. If this is not feasible, the service SHALL respond with 404 Not Found.
• Req 18 An OGC SensorThings API service SHALL evaluate the system query options following the order specified in Section 9.3.1.
• Req 19 The usage of the $select query option SHALL be as defined in Section 9.3.2.1.
• Req 20 The usage of the $select query option SHALL be as defined in Section 9.3.2.2
• Req 21 If a service does not support a system query option, it SHALL fail any request that contains the unsupported option and SHOULD return 501 Not Implemented.
• Req 22 The usage of the $orderby query option SHALL be as defined in Section 9.4.1.
• Req 23 The usage of the $top query option SHALL be as defined in Section 9.4.2.
• Req 24 The usage of the $skip query option SHALL be as defined in Section 9.4.3.
• Req 25 The usage of the $count query option SHALL be as defined in Section 9.4.4.
• Req 26 The usage of the $filter query option SHALL be as defined in Section 9.4.5
• Req 27 The built-in filter operators SHALL be as defined in Table 9-1.
• Req 28 The built-in query functions SHALL be as defined in Table 9-2.
• Req 29 An OGC SensorThings API service SHOULD support the server-driven paging mechanism listed in section 9.4.6.
• Req 30 To create an 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.
• Req 31 A SensorThings API service, that supports entity creation, SHALL support linking new 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.
• Req 32 A request to create an entity that includes related entities, represented using the appropriate inline representation, is referred to as a "deep insert". A SensorThings service that supports entity creation SHALL support deep insert.
• Req 33 Upon successfully creating an 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. Regarding all the HTTP status code, please refer to the HTTP Status Code section.
• Req 34 A SensorThings service SHALL support reading resources as defined in Section 10.3.
• Req 35 To update an entity in a collection a SensorThings service SHALL follow the requirements as defined in Section 10.4.
• Req36 To delete an entity in a collection a SensorThings service SHALL follow the requirements as defined in section 10.5.
• Req 37 The batch-processing of the SensorThings service SHALL be as defined in Section 11.
• Req 38 Each MultiDatastream entity SHALL have the mandatory properties and MAY have the optional properties listed in Table 12-1.
• Req 39 Each MultiDatastream entity SHALL have the direct relation between a Datastream entity and other entity types listed in Table 12-2.
• Req 40 The size and the order of each element of a MultiDatastream’s unitOfMeasurements array (i.e., MultiDatastream(id)/unitOfMeasurements) SHALL match the size and the order of each element of the related ObservedProperties collection (i.e., MultiDatastreams(id)/ObservedProperties). The size and the order of each element of a MultiDatastream’s unitOfMeasurements array (i.e., MultiDatastreams(id)/unitOfMeasurements) SHALL match the size and the order of each element of all related Observations’ result (i.e., MultiDatastreams(id)/Observations?$select=result). The size and the order of each element of a MultiDatastream’s unitOfMeasurements array (i.e., MultiDatastreams(id)/unitOfMeasurements) SHALL match the size and the order of each element of the MultiDatastream’s multiObservationDataTypes array (i.e., MultiDatastreams(id)/multiObservationDataTypes). When a complex result’s element does not have a unit of measurement (e.g., a OM_TruthObservation type), the corresponding unitOfMeasurement element SHALL have null values.
• Req 41 To support the SensorThings data array extension, a service SHALL support the retrieval and creation of observations as defined in Section 13.
• Req 42 To allow clients to create entities with MQTT Publish, a service SHALL support the creation of entities with MQTT as defined in Section 14.1.
• Req 43 To allow clients to update SensorThings entities with MQTT Publish, a service SHALL support the updates of entities with MQTT as defined in Section 14.2.
• Req 44 To allow clients to receive notifications for the updates of SensorThings entities with MQTT, a service SHALL support the receiving updates with MQTT Subscribe as defined in Section 14.3.

Frontend

• Show, Add, Delete, Patch all possible entities
• Show MQTT status including traffic
• Map showing all Things that have a location
• Show live sensor observations in a dashboard and on the map