Skip to content

Functional Advisory Board session - 24 februari 2021

(Dutch only)

De notes van het Functional Advisory Board.

Volgende FAB-overleg is op 10 maart

Attendees

(in alfabetische volgorde)

  • Gemeente Den Bosch
  • Gemeente Eindhoven
  • Gemeente Helmond
  • Gemeente Nijmegen
  • Gemeente Utrecht
  • Kadaster (initiator)

Notes

Onderwerpen:

  1. Mededelingen

    • Kadaster heeft een uitnodiging ontvangen om mee te doen aan de Summit van BrabantStad op 16 maart a.s. Kadaster zal daaraan meedoen.

    Vragen

    • Vraag over SensRNet functionaliteit: bulkimport met een csv bestand via de API

      Antw: We hebben een voorbeeld ontwikkeld om aan te tonen dat het kan.

    • Vraag wanneer het beste moment is om data te gaan verzamelen in SensRNet

      Antw: De verwachting is dat over ongeveer 3 weken (midden maart 2021) het datamodel stabiel is en de productieomgeving is opgezet om dit te faciliteren. Daarna gaan we ook datamigraties ondersteunen bij datamodelwijzigingen.

  2. Stand van zaken huidige en komende sprint (zie bord)

    Het bord is bijgewerkt.

    In de komende 2 weken zal wederom de meeste aandacht gaan naar het datamodel en het bijwerken van de code rond de afspraken die zijn neergelegd in het datamodel.

  3. Stand van zaken rond het Datamodel (Kadaster en Nijmegen)

    Kadaster presenteert (zie ook het datamodel in GitHub) Er wordt nog eens ingegaan op de vraag wat een sensor nou precies is. Er is voor gekozen om het datamodel zó op te stellen dat het enerzijds zoveel mogelijk raakt aan de SensorThingsAPI (en ook andere bestaande modellen, zie hier) en anderzijds het niet willen vóórschrijven van wat er precies onder een sensor verstaan wordt en de software zó te maken dat de eindgebruiker de vrijheid heeft om meerdere interpretaties van het berip te hanteren.

    Vraag Utrecht: Is er bewust gekozen voor het niet opnemen van het veld FeatureOfInterest uit de SensorThingsAPI?

    Antw: Ja en Nee; op dit moment vinden wij dit buiten de scope van het MVP vallen voor een sensorenregistratie waarin we willen registreren en niet direct heel veel technische informatie willen vastleggen. Voor nu lijkt het 'Obervatiedoel' voldoende voor het MVP van een registratie. Ook ObservedProperty uit SensorThingsAPI wordt door ons op dit moment niet relevant geacht. In een later stadium kunnen we eventueel nog terugkomen op deze zienswijzen.

    Verbeteringen / aanpassingen

    N.a.v. een vraag van Den Bosch: In het gepresenteerde model kunnen meerdere datastromen maar aan 1 ObservatieDoel gekoppeld zijn maar in de praktijk kan 1 datastroom meerdere Observatiedoelen hebben, bijvoorbeeld camerabeelden kunnen beveiliging én druktemeting als doel hebben. Dit is aangepast in het model, zie datamodel in GitHub.

    N.a.v. een vraag van Eindhoven over de koppeling aan BGT-objecten - In de "Location" van een sensor was een veld in het datamodel opgenomen die gebruikt kan worden om te koppelen aan een BGT-object, het baseObjectId. Dit is uitgebreid met subtypen: 1. xyH-type, 2. BaseObjectLocation (gekoppeld aan BGT-object) en voor later 3. MobileLocation (ook in xyH), zie datamodel in GitHub.

  4. Wvttk en Afsluiting

    Vraag van den bosch: Hoe gaat het verder na de Common Ground Hackathon, andere gemeenten worden daar enthousiast van en willen weten waar we staan?

    Antw: we zijn nog bezig om de installatie van SensRNet verder te automatiseren maar een volledig automatische installatie volgens Common Ground principes is er nog niet. De wedervraag is in hoeverre we dit als onderdeel van het MVP zien. Op dit moment heeft dit in ieder geval niet de hoogste prioriteit.

    Opmerking Kadaster: De Privacy Impact Analyse (PIA) is uitgevoerd en het rapport wordt nog opgesteld. Dit rapport zal later worden gedeeld met de FAB.