Ontsluiting van sensordata

[frisopenninga]

Voor het ontsluiten zijn op verschillende plaatsen standaarden in ontwikkeling. Zo wordt er gewerkt aan OGC standaarden (SOS, SensorThings API), maar ook aan W3C standaarden (o.a. SSN). Voor deze standaarden geldt dat ze -voor zover ze voldoende gereed zijn- nog maar zeer beperkt toegepast worden. Hiermee is het voor ons nu nog te vroeg om een uitspraak te doen over de vermoedelijke richting van deze ontwikkeling.

[thijsbrentjens]

@frisopenninga een richting aangeven hoeft / kan misschien inderdaad nog niet, maar je opmerking lijkt me relevant om te noemen in paragraaf 2.3, over sensoren.

Overigens, wat je wel ziet is dat voor sensorstandaarden de lichtgewicht protocollen belangijker lijken te worden. Dus minder de verbose XML berichten ("OGC stijl XML geo service"), maar meer web met o.a. JSON of nog compacter (op byte niveau), omdat sensoren andere uitdagingen met zich meebrengen. Zoals: zo compact mogelijk voor minimale belasting van accu en/of minimale datacommunicatie. Ook efficientie voor opslag en verwerking is belangrijker voor sensorstandaarden, omdat er heel veel data mee gemoeid kan zijn.

[wisze]

Ik ken de W3C standaarden niet. Maar dat er meer dan één protocol is voor sensordata in OGC kader lijkt me logisch aangezien je voor verschillende toepassingen verschillende protocollen kunt toepassen. Een protocol als SOS kan worden toegepast voor het ontsluiten van een sensordata van een netwerk van sensoren terwijl SensorThings meer op zijn plek lijkt voor de sensoren (eigenlijk de processor van de sensor). Het is dus niet onlogisch om meerdere protocollen naast elkaar te blijven gebruiken. Ik ken één waterschap wat alle sensorgegevens met SOS ontsluit, RWS is er ook mee bezig. Dus de acceptatie van SOS neemt wel toe.

[Naisunev]

Ik zie verschillende lagen in standaarden voor sensordata, lijkt me goed om dat onderscheid te blijven maken. Denk onder andere aan meta-data over de sensor zelf (locatie, accuratie, soort meting, etc etc etc) en de harde ruwe data. Voor deze data geldt dat het vaak afhankelijk is van de toepassing hoe deze kan worden ontsloten. Denk aan traditionele CSV bestanden, matrices en standaarden als Protobuf waar in getypeerde binary arrays data verstuurd wordt. Ik werk zelf met datasets waar de ruwe data in binaire vorm al snel terrabytes kan zijn en dan is iets als XML echt ondoenlijk, zelfs CSV/JSON wordt dan al groot. Al bleek recentelijk wel na wat testen dat wanneer de server de data compressed over de lijn stuurt er geen tot weinig verschil is tussen ProtoBuf of JSON, dan lijkt encoding/decoding snelheid aan de server/client side relevanter te zijn in plaats van het gekozen formaat. Ook is het vaak zeer afhankelijk van de analyse die gedaan moet worden of de orientatie zoals deze aangeleverd wordt geschikt is. Ik zie daarom vaak data driedubbel aangeboden worden om aan de verschillende soorten behoeftes te kunnen voldoen.