Probleeem: volgens de XSD definities van bg0310 dd 2013-09-20 patch 17, zijn in het bericht braBOR in de restrictie OPR-bag-toevoegen de elementen gor.type en gor.identificatie optioneel. Mijns inziens is dit foutief verstuffed vanuit het RSGB. Immers, volgens RSGB, versie 2.0 deel II pagina 174, is dit element uitkomstig uit de BAG (en niet van KING/RSGB), authentiek en met een kardinaliteit 1-1. Daarnaast is zowel theoretisch als in de praktijk de combinatie gemeente en openbareruimtenaam niet uniek maar de combinatie van gemeente, openbareruimtenaam en type wel. Er zijn namelijk gemeenten waar een water en een weg of een park en een weg dezelfde naam. Door deze foute verstuffing is bij verstek van de gor.type en gor.identificatie geen eenduidige matching mogelijk met bestaande StUF 02.04 objecten of daarvan afgeleide platgeslagen informatie.
Voorstel: maak gor.type en gor.identificatie verplicht in de restrictie OPR-bag-toevoegen.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR306.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ik ben het hier niet mee eens, op verschillende punten. Het type is inderdaad een BAG-attribuut. De gor.identificatie is dat niet: de BAG kent helemaal geen GOR. Binnen het RSGB heeft de OPR een eigen ID, die wél uit de BAG is afgeleid. Daarmee zou ik zeker gor.identificatie niet verplicht willen stellen. Het verplicht stellen van het type op basis van het argument dat gemeente, naam en type een GOR uniek zouden identificeren zou ik niet doen. Dat is namelijk niet het geval. denk aan een voorbeeld van een gemeente met twee woonplaatsen die elk een eigen kerkstraat hebben. Dit levert dan twee gor's op met de naam kerkstraat, dezelfde gemeentecode en hetzelfde type (weg). Dus niet uniek. Omdat het twee losse openbare ruimtes zijn en niet één door woonplaatsgrenzen opgesplitste ruimte, is er geen sprake van éénzelfde GOR. Volgens mij is er dus geen sprake van een foute verStUFfing, maar van (al dan niet) bewuste keuzes om het type van de openbare ruimte niet verplicht te stellen. Ik zou de GOR-ID niet verplicht willen stellen omdat veel systemen geen GOR kennen.
Tijdens de StUF Expertgroep van 18 december 2013 is geconcludeerd dat voor het uniek identificeren van een openbare ruimte naam de elementen 'woonplaatsnaam', 'openbareruimtenaam' en 'type' nodig zijn.
Bijgaand een voorstel voor de oplossing van dit issue. In het schema 'bg0310_ent_basis.xsd' is aan het complexType 'OPR-kerngegevens' het element 'gor.type' als optioneel element toegevoegd. Deze wijziging heeft gevolgen voor de berichten 'oprSa03', 'oprSa04', 'oprSh03' en 'oprSh04'.
Daarnaast is in het schema 'bg0310_ent_bag.xsd' in de complexTypes 'OPR-bag-hernoemen', 'OPR-bag-hernoemenBuurgemeente', 'OPR-bag-inOnderzoek', 'OPR-bag-intrekken', 'OPR-bag-muterenCorrigeren', 'OPR-bag-toevoegen', 'OPR-bag-wijzigenWoonplaats', 'OPR-bag-herindeling' het element 'gor.type' verplicht gemaakt. Deze wijziging heeft gevolgen voor de berichten 'braBOR_Lk03', 'braBOR_Lk04', 'braGHO_Lk03', 'braGHO_Lk04', 'braHOR_Lk03', 'braHOR_Lk04', 'braHWP_Lk03', 'braHWP_Lk04', 'bagIO_Lk03', 'bagIO_Lk04', 'bagOA_Lk03', 'bagOA_Lk04', 'braIOR_Lk03', 'braIOR_Lk04', 'bagMUT_Lk03', 'bagMUT_Lk04', 'braWGW_Lk03', 'braWGW_Lk04', 'bagHER_Lk03', 'bagHER_Lk04'.
Bijlage
Tijdens de StUF Expertgroep van 20 april 2016 werd alleen een backwards compatibility probleem onderkent in die complexTypes waarin het element 'gor.type' is toegevoegd. Tijdens de discussie bleek dat nog niet voor iedereen de consequenties duidelijk waren en daarom is besloten dit onderhoudsverzoek nog even aan te houden en er in de volgende StUF Expertgroep op terug te komen.
Het opnemen van het element gor.type in de OPR-kerngegevens heeft niet alleen gevolgen voor de berichten 'oprSa03', 'oprSa04', 'oprSh03' en 'oprSh04'. Doordat het gegeven kerngegeven is geworden, moet het ook worden opgenomen in alle OPR-wijzigingsberichten, ongeacht of dit element wijzigt of niet (tenzij er een sleutelOntvangend is opgenomen). Dit betekent dus aanpassing in de BAG-applicaties (voor zover zij nu ongewijzigde niet-kerngegevens weglaten in wijzigingsberichten en niet werken met sleutelOntvangend).
De wijzigingen in de tweede alinea van post #5 zie ik niet terug in de bijgevoegde ZIP-file. Waarschijnlijk was het de bedoeling om daar (door het element verplicht te maken) expliciet op te nemen dat het een kernelement is geworden en dus verplicht. Feitelijk is dit niet correct, omdat bij het wijzigen van bijvoorbeeld de naam in een bericht met daarin een sleutelOntvangend voor de betreffende OPR de andere kerngegevens (en dus de gor.type) niet hoeven te zijn opgenomen.
Het element gor.type zie ik nu niet terug in de nieuwe berichten, terwijl het juist verplicht zou zijn gemaakt. Ik snap het dus niet goed. In ieder geval kan ik het nu niet goed beoordelen.
Tijdens de StUF Expertgroep van 18 mei 2016 heeft Sid nogmaals aangegeven het niet eens te zijn met de conclusie van Robert. Ton deelde die mening. Het issue lijkt een downwards compatibility probleem op te leveren. De StUF Expertgroep heeft daarop besloten het erratum om te zetten naar een RFC (RFC306).
De zip die ik in post #5 heb bijgevoegd bevat inderdaad niet alle beschreven wijzigingen.
Het erratum is inmiddels omgezet naar een RFC maar voor de goede orde heb ik alsnog de juiste zip bij deze post gevoegd.
Bijlage