Gemeente Tilburg: verschijningsvormen van Camera

[wjtmollema]

Melding De gemeente Tilburg constateert dat Camera in de openbare ruimte veel verschillende soorten toepassingen kent, maar dat IMBOR die niet uit kan drukken.

Voorgestelde verwerking

• Definiëren van meerdere domeinwaarden binnen CameraType o.b.v. onderzoek;
• Het toevoegen van camerafunctie als attribuut om (gelijk de modellering van kabelfunctie bij Voedingskabel, Datakabel etc.) de aard van de toepassing of plaatsing van de Camera vast te leggen. Zie ook #645

Motivatie In het kader van SensRNet en de proliferaties van Camera's in de openbare ruimte, is een betere subtaxonomie van een Camera duidelijk gewenst.

[RiX012]

Kunnen we hier een bestaande taxonomie adopteren?

[wjtmollema]

Binnen Nederland ben ik alleen op de hoogte van het onderscheid dat RWS maakt tussen camera (vast) en camera (beweegbaar) . Dit zou toegevoegd kunnen worden aan type, waarmee 360 graden camera opschuift naar type gedetailleerd. Dit alles lijkt voor optie 2 twee te spreken.

[RiX012]

Binnen Nederland ben ik alleen op de hoogte van het onderscheid dat RWS maakt tussen camera (vast) en camera (beweegbaar) . Dit zou toegevoegd kunnen worden aan type, waarmee 360 graden camera opschuift naar type gedetailleerd. Dit alles lijkt voor optie 2 twee te spreken.

Onder aan deze pagina: https://kadaster-labs.github.io/sensrnet-home/Definitions/ staat een Excel met een hele lijst sensorentypes. Zoiets bedoel ik.

[wjtmollema]

Er valt veel voor te zeggen om een dergelijke lijst te volgen. Dit zou de toevoeging van 312 verschijningsvormen gedistribueerd over de 38 bestaande ObjectTypen inhouden. Bijgevoegd een preliminaire projectie van die verschijningsvormen naar IMBOR-verschijningsvormen om uit te wijzen waar beide classificatielijsten elkaar raken. Deze lijst moet onderdeel worden van het gesprek in #645 . Daarnaast wijst de preliminaire projectie uit dat ObjectTypen zoals Detector, Lichtsensor, Warmtecamera, Afvalsensor en Parkeerbeheersensor op dit moment onlogisch gemodelleerd zijn of tenminste logischer gemodelleerd zouden kunnen worden. unafact_Projectie_Waardelijst_Sensortypes_naar_IMBOR_Sensor.xlsx

[RiX012]

Nice. Ik zou eigenlijk zeggen dat we alleen degene in IMBOR kern opnemen die nodig zijn. En vanuit daar de mapping leggen. Dan kunnen we altijd meer opnemen indien nodig.

[wjtmollema]

De SensRNet-indeling kent de volgende hoofdindeling (grammaticale correcties van mijn hand :)):

• Geluidssensor
• Chemiesensor
• Elektriciteitssensor
• Klimaatsensor
• Vloeistof- en gaststroomsensor
• Positie- of verplaatsingssensor
• Optische sensor
• Druksensor
• Dichtheidssensor
• Temperatuursensor
• Aanwezigheids- of nabijheidsensor
• Overig (kan geen ObjectType worden vanwege onderbepaaldheid)

We zouden de bestaande IMBOR-verschijningsvormen kunnen invoegen in die hoofdtypering (zie bijgevoegde voorzet), waarbij de zaken die echt niet passen IMBOR-ObjectTypen blijven. De 300 sensortypes die zijn opgenomen in de lijst zouden als Referentielijst in IMBOR opgenomen kunnen worden bij een attribuut sensortype dat enumeratiecombinaties per bovenstaande hoofdindeling bevat. De 300 sensortypes die SensRNet onderscheidt lijken mij te contingent om permanent in IMBOR op te nemen en daarnaast vallen er inderdaad een aantal buiten de BOR-scope. Aanvullend onderzoek moet uitwijzen welke van de 300 sensortypes wel binnen de IMBOR-scope zouden vallen. Dat onderzoek kan volgen na acceptatie van deze basisprojectie. 20230329_Voorzet IMBOR taxonomie Sensor.xlsx

[RiX012]

Reactie van @HarroVerhoeven:

• Het sensorregister lijkt me een goeie standaard om bij aan te sluiten
• We hoeven geen complete ontologie van het sensorregister aan IMBOR Kern toe te voegen maar kunnen ons beperken tot de informatie die naar onze inschatting voor beheerders relevant is.
• We kunnen altijd nog meer toevoegen als onze gebruikers van IMBOR dat willen.
• Het is goed dat we een explicite mapping (in de vorm van een alignment) naar het sensorregister aanbrengen zodat zichtbaar is waar deze objecttypen en attributen vandaar komen.

Daarnaast moeten er nog twee dingen gebeuren:

• Kijken of zaken die wij nu 'aanvullen' wel echt ‘sensoren’ zijn
• Navraag doen bij het Kadaster of we niet iets verkeerd interpreteren en zodoende de mapping vragen voorleggen