23 januari
Op 23 januari organiseerden we een online vragenuur in het kader van de consultatie van IMX Geo. Aanwezig waren Gemeente Rotterdam, ministerie van BZK, KOOP, Anteagroep en Gemeente Zwolle.
De volgende vragen en antwoorden zijn de revue gepasseerd.
Wat is de reden dat Gemeentegebied geen kenmerk (attribuut) van (burgerlijke) gemeente, maar objecttype is?
Idem voor Waterschapsgebied voor waterschap en Bestuurlijk gebied voor Rijk, provincie en veiligheidsregio.
Dit komt vanuit het model DiSGeo bestuurlijke gebieden en is overgenomen in IMX-Geo. Meer informatie over disgeo bestuurlijke gebieden model: https://geonovum.github.io/disgeo-im/
Bekeken door een informatie-analytische bril is een gemeente een openbaar lichaam. Dat openbaar lichaam heeft een grondgebied. Beide hebben hun eigen kenmerken. Een gemeentegebied ligt in een provinciegebied, maar een gemeente ligt niet letterlijk in een provincie. Daarnaast is er een praktische reden dat dit uit elkaar is gehaald. Grenzen van bestuurlijke gebieden worden bijgehouden door het Kadaster. De officiële naam van bestuurlijke gebieden wordt bijgehouden door KOOP. Dat is een bijkomstige reden dat ze als twee objecten zijn opgenomen. In IMX Geo is de redenatie: De gemeente bestuurt het gemeentegebied en die ligt in een provinciegebied.
Als je gegevens uit verschillende registraties gaat combineren is het belangrijk dit uit elkaar te houden. Bijvoorbeeld administratieve wijzigingen van een gemeente hebben geen gevolgen voor het gemeentegebied, en wijzigingen van de gemeentegrens zoals grenscorrecties hebben geen gevolgen voor het openbaar lichaam gemeente.
Waar in het model vind ik stand- en ligplaats (artikel 1 onder g en l Wet bag)? Ofwel ‘benoemde plaats’? Het is een adresseerbaar object. Dat mis ik in het model. Vanuit praktijk hebben we heel veel problemen als gevolg van relateren van objecten aan adres. De sor ziet verblijfsobjecten en benoemde plaats en dan is nummeraanduiding een kenmerk. De RvIG heeft dat ook erkend en heeft het logisch ontwerp van BRP gekoppeld aan identificatie adresseerbaar object.
In de stelselplaat is ook gekozen voor adres als centraal object, maar is het een kenmerk van adresseerbaar object.
Stand en ligplaats zijn niet meegenomen. Die zijn buiten beeld gebleven. We hadden daar nog geen use case voor. In het model zeggen we een gebouw heeft een of meer adressen en zijn er traces aangelegd naar nummering. Maar er is geen link gelegd met verblijfsobject.
Hoe werkt dit in de orkestratie: Als je kijkt naar een doelobject specificeer je bij de mapping van dat objecttype de source root. Dat is het primaire object van waaruit je gaat mappen. Dat gebruik je als identificeerbaar object. In IMX heeft object als source root de nummeraanduiding genomen. Maar dat kan ook anders. Dan moet je wel de mapping van je paden aanpassen omdat er dan een andere route nodig is.
Mogelijk is er dan nog wel een beperking dat je geen nevenadres kunt opnemen, maar wij denken zelf dat dat wel kan. Voordeel kan zijn dat je kan zien dat er meerdere adressen zitten aan een adresseerbaar object.
Wat zijn Registratiegegevens?
Registratiegegevens zijn technische constructen die je zou kunnen zien als 'begin geldigheid en einde geldigheid'. Het zijn metadata die niet gaan over het object in de werkelijkheid maar over gegevens die betrekking hebben op het registreren van het object : wanneer is iets opgenomen in de registratie, welke versie van registratie is gebruikt. Deze modelleerkeuze komt uit NEN3610. IMX is een informatiemodel dat van NEN3610 is afgeleid.
In relatie tot IMX-Geo zijn registratiegegevens wel ingewikkeld omdat IMX niet zelf iets registreert. IMX-geo leidt alleen maar gegevens af.
Maar dan is een registratiegegeven dan niet een kenmerk?
Dat is informatiekundige discussie waar niet iedereen het over eens is.
Er ligt een model voor de SOR. Waarom is dat niet als leidend genomen?
De SOR richtte zich vooral op bijhouding van de bron. Het IMX richt zich op het bij elkaar brengen van bestaande bronnen en doet geen wijzigingen of toevoegingen aan de bestaande bronmodellen zoals de SOR wel voorstelde. Het IMX gaat over de vertaling, het raapt dingen bij elkaar. We proberen een beetje weg te blijven bij de hele technische termen om het wat laagdrempeliger te maken. De stelselcatalogus is hierbij als uitgangspunt genomen.
In hoeverre is IMX geo uitbreidbaar? Bijvoorbeeld zodat je vragen kunt stellen als: geef me de wegen waarlangs picknicktafels en eiken voorkomen. De picknicktafel staat in de BGT, de boom in de bomenregistratie maar kan ik mijn eigen model hier ook aan koppelen?
Het korte antwoord is: ja dat kan, we hebben aan een uitleg daarvoor gewerkt maar we hebben dat nog niet gepubliceerd. Je moet hiervoor de extra informatie modelleren, en vertaalregels opstellen voor je mapping. Het belangrijkste daarbij is dat het orkestreren stapelbaar is. Je kunt IMX-geo als een basismodel hergebruiken en daar bovenop dan weer een nieuwe orkestratie bouwen. Je maakt dan eerst een informatiemodel voor je use case en vervolgens de vertaalspecificatie (mapping) schrijven. IMX geo is daarbij dan een van je bronmodellen. En dan heb je nog een orkestratie engine nodig.
Er wordt geopperd om deze use case te gebruiken om de uitbreidbaarheid in de praktijk te beproeven. Daar gaan we naar kijken. Een van de vervolgstappen die we nog willen zetten is het bouwen van een proefimplementatie in Digilab. Hierin kunnen we uitzoeken hoe je sectordata kunt koppelen bijvoorbeeld. Daar zou misschien ook een demonstrator in gebouwd kunnen worden.
In het algemeen is de vraag: Komen de use cases beschikbaar? Komt er een interface waarin je dit soort vragen kan stellen en dat je hier verschillende productmodellen op beschikbaar stellen?
Dit laten we over aan de markt. Het model stellen we beschikbaar. Ontwikkeling van toepassingen op basis hiervan, laten we over aan anderen.
Hoeveel mensen kunnen UML lezen? Dat is wel een belemmering voor implementatie.
Dit wordt herkend, maar we hebben hier nog niet direct een oplossing voor.
Een van de aanwezigen had een case gezien om hoogte pand uit het AHN te halen, maar kon dit niet terugvinden in het informatiemodel.
Deze use case vonden we niet direct terug. Gaan we uitzoeken.