De waarde van sensor data, deel 4

Andere delen uit deze serie:

• De waarde van sensor data, deel 1
• De waarde van sensor data, deel 2
• De waarde van sensor data, deel 3
• De waarde van sensor data, deel 5

In deel 1, 2 en 3 hebben we de sensoren onder de loep genomen, data van de eerste test metingen in grafieken omgezet en een low-level kalibratie uitgevoerd. De kennis die we daarbij hebben opgedaan is waardevol maar we zijn er daarmee nog niet. Nu gaan we de data centraal brengen ofwel een plek in de cloud geven.

Data naar de cloud

Om de meetwaarden in de cloud te krijgen heeft Scapeler een REST-service ontwikkeld die vanuit de Raspberry PI wordt aangeroepen. Nodejs scripts verzorgen die aanroep met een POST-request waarmee we de meetwaarden aangevuld met enige metadata de cloud insturen.

Shinyei data

Voor dit project beperken we de Shinyei meetdata tot één getal per minuut welke een gemiddelde voorstelt over alle kanalen van al de aangesloten Shinyei sensoren.

Dylos data

De Dylos geeft meetwaarden per minuut dus daar zal geen (extra) middeling plaatsvinden. Wel zal er voordat het naar de cloud wordt gestuurd, eerst een omrekening naar PM2.5 en PM10 worden uitgevoerd.

Meta data

Bij de meetwaarde worden ook gegevens over de gemeten waarde (meta data) meegegeven zoals het tijdstip van de meting en de lokatie. Lokatie kan in dit geval een xy-coordinaat zijn of CBS wijk- of buurtcode (zie “Sensor data en privacy”).

Sensor data en privacy

Het centraal brengen van sensor data kan (bedoeld of onbedoeld) privacy consequenties met zich meebrengen. Voor dit project wordt de meetdata daarom op minimaal CBS-buurtniveau in de cloud opgeslagen. Aangezien we voor dit project geen GPS gebruiken zullen we de locatie handmatig moeten configureren. Dat kan middels een CBS wijk- of buurtcode of een coördinaat (latitude/longitude WGS84). Indien een coördinaat wordt gebruikt dan zal deze door de REST-service worden omgezet naar een CBS buurtcode.

Data gestandaardiseerd in de cloud

De REST-service ontvangt de data en vervolgens wordt deze data omgezet naar “InsertObservation” SOS berichten (OGC SOS 2.0 Transactional Extension). Voor deze SOS (Sensor Observation Services) heeft Scapeler de versie van 52North geïmplementeerd.

De standaard is mooi maar (te) complex?

Dit is het punt waar veel mensen afhaken. Een standaard is mooi en natuurlijk van belang wanneer het aankomt op gegevensuitwisseling of gebruik in applicaties. Maar als het te complex wordt dan is de drempel om de standaard te gebruiken te hoog. En de SOS standaard is niet eenvoudig. De standaard is goed doordacht en opgezet om een grote diversiteit aan sensor data aan te kunnen. Maar dat laatste is misschien ook gelijk een nadeel omdat het door de flexibiliteit en alle mogelijkheden ondoorzichtig wordt. Want wat wordt bedoeld met ‘feature of interest’, ‘procedure’, ‘observed property’, ‘series’, etc.. Er is werkelijk een studie voor nodig om enige inzicht te krijgen en dan nog, hoe pas je de standaard toe?

Scapeler schermt een groot deel van de complexiteit voor de gebruiker van de data af maar het is goed om toch wat kretologie te vertalen naar het project voor een beter begrip.

Feature of interest

De ‘feature of interest’ staat voor het object wat een geolocatie heeft en het onderwerp is van de observaties. Voor dit project hebben we gekozen voor de CBS buurtindeling. De buurt als geografisch vlak is het object waar onze interesse naar uitgaat en waar we onze observaties aan koppelen. De buurt is de ‘feature of interest’.

Een ander voorbeeld van een ‘feature of interest’ is het ILM systeem van AiREAS waar we de ‘airbox’, de kast met sensoren op een bepaalde locatie, als ‘feature of interest’ beschouwen.

Feature of interest ID

Voor dit project is een feature of interest dus een CBS-buurt en krijgt als identificatie een referentie dat verwijst naar een wiki pagina. Als voorbeeld de buurt met CBS buurtcode ‘BU04390603’ krijgt als ID:

‘http://wiki.aireas.com/index.php/Sensor_buurt_BU04390603‘

Deze referentie biedt dus de mogelijkheid om in de wiki pagina informatie op te nemen van deze feature of interest zoals specifieke kenmerken of andere (ongestructureerde) data.

Procedure

De ‘procedure’ beschrijft de wijze waarop het resultaat (meetwaarde of anders) tot stand komt. Wat is de input, wat de output en welke bewerkingen vinden plaats.

Voor de Shinyei is er een andere procedure dan voor de Dylos. De sensoren werken anders, de ruwe meetwaarde is anders en het omzetten naar het eindresultaat (berekenen µg/m3) is anders.

Procedure ID

Ook de procedure krijgt een ID. Als voorbeeld:

‘http://wiki.aireas.com/index.php/ILM0102VH01‘

De wiki pagina waarnaar deze url verwijst bevat een experimentele beschrijving van een procedure.

Observed property

‘Observed property’ of ‘observable property’ is de sensor, bijvoorbeeld ‘PM1’, ‘PM2.5’, ‘NO2’, etc.. Ook hier een ID zoals de vorige voorbeelden.

Observation

De ‘observation’ of waarneming bevat het tijdsmoment, de waarde van de waarneming en de eenheid (bv. µg/m3). Ook hier een ID zoals de vorige voorbeelden.

Offering

De ‘offering’ zien we terug in het plaatje met een schets van een deel van het datamodel zoals in de SOS implementatie wordt toegepast. De ‘offering’ is door Scapeler vertaald en gebruikt in de betekenis van project. Een offering of project geeft een bepaald aandachtsgebied of focus weer en maakt het mogelijk om specifieke observaties te kaderen of groeperen. Bijvoorbeeld de observaties van Eindhoven, Breda en Helmond in het aandachtsgebied (offering) van de betreffende stad.

OGC/SOS-service transacties

Om de data in de SOS service te krijgen gebruiken we twee transactie soorten, de ‘InsertSensor‘ en de ‘InsertObservation‘. Met de InsertSensor registreren we o.a. de feature of interest (buurt), procedure, observable property (de sensor zoals PM1, PM10). Met de InsertObservation wordt het resultaat, de meetwaarde van de observatie (of eigenlijk de output van de procedure) geregistreerd. Iedere keer dat de sensor een meetwaarde afgeeft wordt een InsertObservation transactie op de SOS-service losgelaten om de resultaten te registreren.

Om de data weer uit de SOS omgeving te halen gebruiken we de ‘GetObservation‘ transactie. Daarmee zijn diverse filters toe te passen zoals een filter op ‘offering’, ‘observerdProperty’ en ’temporalFilter’ om een bepaalde periode te kunnen kiezen. Zie het plaatje hieronder als voorbeeld in xml.

Ook is het mogelijk om met een ‘spatialFilter’ geografische gebieden te selecteren. Het is maar dat je het weet 😉

Data in de cloud als mijlpaal

We kunnen vanaf nu de sensoren en de infrastructuur hun werk laten doen, verzamelen van meetgegevens! Met recht kunnen we stellen dat het gestandaardiseerd in de cloud opnemen van de meetgegevens een belangrijke mijlpaal is.

Vervolg activiteiten

Zodra er voldoende meetgegevens beschikbaar is kunnen we daar ook werkelijk iets mee doen zoals vergelijken en visualiseren. Het is binnenkort weer oud en nieuw en met het traditionele vuurwerk hebben we een mooi moment om naar uit te kijken. Het fijn stof effect van vuurwerk is al eerder in het AiREAS project gevisualiseerd in 2014/2015 en 2015/2016. Hopelijk geeft dit experiment soortgelijke mooie resultaten.

Voor dit project werken we toe naar het onderstaande plaatje waarin de resultaten van onze eerste experimenten zijn te zien. Later natuurlijk meerdere buurten ingekleurd met de resultaten van de metingen van de betreffende buurt.

Wordt vervolgd.

Andere delen uit deze serie:

• De waarde van sensor data, deel 1
• De waarde van sensor data, deel 2
• De waarde van sensor data, deel 3
• De waarde van sensor data, deel 5

André van der Wiel
Scapeler partner van AiREAS