Sectie Bestand

Kies in het tabje ‘GML’ bij ‘Kies een laag’ de benodigde laag uit QGIS. Deze zal meestal al juist ingevuld zijn, maar mochten er al meerdere lagen in QGIS geopend zijn dan is hier de relevante laag te kiezen.

Blader via de puntjes bij ‘Kies gml bestand’ naar een locatie waar je de output van de plug-in op wil slaan en geef er een zinnige naam aan.

Sectie Identificatie

Het lastigste deel om in te vullen is ‘Identificatie / FRBRExpression’. Dit is een verwijzing naar de identificatie zoals die afgesproken is in de STOP 1.3 standaard, te vinden op https://koop.gitlab.io/STOP/standaard/1.3.0/data_xsd_Element_data_FRBRExpression.html.

Als je de muispointer over het invoerveld beweegt krijg je het format te zien hoe dit veld ingevuld moet worden:

/join/id/regdata/<overheid>/<datum_work>/<overig>[‘/’<taal>]’@’<datum_expr>[‘;’<versie>][‘;’<overig>]

Let op: In verreweg de meeste gevallen zal de FRBRExpression en andere gegevens al bekend zijn omdat deze met het grafisch bestand zijn meegeleverd of door de plansoftware al is bepaald. Het heeft ook erg sterk de voorkeur om die gegevens dan te gebruiken. Alleen als deze gegevens nog niet eerder gedefinieerd zijn, zullen deze opgebouwd moeten worden door de velden in te vullen. Documenteer alle stappen hierin, want de gegevens komen terug en een fout is makkelijk gemaakt.

<overheid>

Voor <overheid> dient een code ingevuld te worden voor het bevoegd gezag (eigenaar) over de geometrie. In principe zouden de mogelijk te kiezen codes gepubliceerd moeten worden in de STOP standaard op https://koop.gitlab.io/STOP/standaard/1.3.0/identificatie_wl_dt.html#overheid, maar dat is (nog) niet gebeurd. Het gaat overigens altijd om één van de onderdelen van de volgende vier overheden. De waarde voor de <overheid> is uit het XML-bestand te halen:

Gemeente: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/gemeente.xml

Ministerie: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/ministerie.xml

Provincie: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/provincie.xml

Waterschap: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/waterschap.xml

Dus bijvoorbeeld ‘Ministerie van Buitenlandse Zaken’ heeft code ‘mnre1013’. Gemeente Breda is dan ‘gm0758’.

<datum_work>

Een regeling wordt als elektronisch document opgenomen in het DSO. Binnen de STOP-standaard is bepaald dat dat document volgens de FRBR identificatie wordt aangeduid. Het gaat te ver om in deze gebruikershandleiding exact uit te leggen hoe dat werkt, maar een theoretische achtergrond hierachter is te vinden op https://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records , terwijl de STOP implementatie daarvan is beschreven op https://koop.gitlab.io/STOP/standaard/1.3.0/data_xsd_Element_data_WorkIdentificatie.html .

Praktisch: het gaat hier om de datum waarop het document is gemaakt. De datum wordt formeel volgens de ISO 8601-standaard (format is ‘YYYY-MM-DD’) ingevuld, maar in de praktijk wordt vaak alleen het jaartal ingevuld en alleen dat is ook al genoeg.
Maar let op!: Als er voor wordt gekozen om alleen het jaartal te gebruiken dient dat in alle overige plaatsen waar een datum voor het work wordt gevraagd ook op exact dezelfde manier te gebeuren. Want de datum maakt later onderdeel uit van de unieke identificatiecode voor het ‘work’ en daarmee ook voor de FRBRWork en de FRBRExpression identificaties. Dus documenteer voor uzelf voor welke notatie u heeft gekozen en blijf dat consequent volgen.

<overig>

Volgens https://koop.gitlab.io/STOP/standaard/1.3.0/quickstart_2_ExpressionIdentificatieBesluit.html kan voor het eerste veld <overig> ingevuld worden wat er maar gewenst is: ‘Overige kenmerken om de Expression (optioneel) of het Work (verplicht) te onderscheiden, bijvoorbeeld een dossiernummer of een afkorting gebaseerd op de naam. De kenmerken moeten compact zijn, het is niet de bedoeling om hiervoor een lange titel te gebruiken. ‘<overig>‘ bestaat uit een combinatie van cijfers, boven- en onderkast-letters, ‘_’ en ‘-’, te beginnen met een cijfer of letter (regex [a-zA-Z0-9][a-zA-Z0-9\_\-]*) met een maximale lengte van 128 karakters. Het bevoegd gezag is zelf verantwoordelijk voor uniciteit van dit ‘overig’ deel. Er is geen centrale service om de waarde voor ‘overig’ te genereren’.

Het veld is bedoeld om het voor de gebruiker makkelijker te maken om het unieke werk terug te kunnen vinden. Maar het veld is een verplicht veld volgens de STOP standaard, en dat heeft gevolgen:

Let op!: De keuze voor wat er hier ingevuld wordt is in principe vrij binnen de grenzen zaols die in de STOP-standaard bepaald zijn. Maar wat hier ingevuld wordt maakt later onderdeel uit van de unieke identificatiecode voor het ‘work’ en daarmee ook voor de FRBRWork en de FRBRExpression identificaties. Dus documenteer voor uzelf wat u voor tekst voor dit veld heeft gekozen en blijf dat consequent gebruiken.

<taal>

Voor het veld <taal> bestaan meerdere waardes die te vinden zijn op https://koop.gitlab.io/STOP/standaard/1.3.0/identificatie_wl_dt.html#overheid . Door de STOP-standaard is echter gedefiniëerd dat alleen de Nederlandse taal wordt geaccepteerd, wat betekent dat voor dit veld alleen ‘nld’ mag worden ingevuld. Dit veld is geen verplicht veld en mag ook (samen met de voorgaande slash) overgeslagen worden.

<datum_expr>

In dit veld gaat het om de datum waarop deze versie van de FRBRExpression is gemaakt. Deze datum moet gelijk zijn of later liggen dan <datum_work>. Verplicht voor een Besluit. Net als bij <datum_work> wordt de datum formeel volgens de ISO 8601-standaard (format is ‘YYYY-MM-DD’) ingevuld, maar in de praktijk wordt ook hier regelmatig alleen het jaartal ingevuld.

Maar let op!: Als er voor wordt gekozen om hier alleen het jaartal te gebruiken dient dat in alle overige plaatsen waar een datum voor de FRBRExpression wordt gevraagd ook op exact dezelfde manier te gebeuren. Want de datum staat in een verplicht veld en maakt later onderdeel uit van de unieke identificatiecode voor de FRBRExpression. Dus documenteer voor uzelf voor welke notatie u heeft gekozen en blijf dat consequent volgen.

<versie>

Dit is een door het bevoegd gezag zelfbepaald volgnummer om de verschillende versies expressions van één work te kunnen onderscheiden. Zie https://koop.gitlab.io/STOP/standaard/1.3.0/data_xsd_Element_data_versienummer.html voor de details. Het veld is niet verplicht en mag samen met de voorloop-; overgeslagen worden. Wordt het wél gebruikt, houd dan zelf bij welke versies er al verschenen zijn en hoog het volgnummer bij de volgende publicatie zelf op.

<overig>

Overige kenmerken om de Expression (optioneel) of het Work (verplicht) te onderscheiden, bijvoorbeeld een dossiernummer of een afkorting gebaseerd op de naam. De kenmerken moeten compact zijn, het is niet de bedoeling om hiervoor een lange titel te gebruiken. ‘<overig>‘ bestaat uit een combinatie van cijfers, boven- en onderkast-letters, ‘_’ en ‘-’, te beginnen met een cijfer of letter (regex [a-zA-Z0-9][a-zA-Z0-9\_\-]*) met een maximale lengte van 128 karakters. Het bevoegd gezag is zelf verantwoordelijk voor uniciteit van dit ‘overig’ deel. Er is geen centrale service om de waarde voor ‘overig’ te genereren.

Sectie Achtergrond

Ga vervolgens naar de sectie ‘Achtergrond’ en vul bij ‘Verwijzing’ een zinvolle verwijzing in (zoals een URL naar de bron, een IMRO nummer als het bestand uit IMRO gehaald is enz.).

Voor ‘Actualiteit’ wordt doorgaans de datum van vandaag ingevuld.

Sectie Locatie

De sectie ‘Locatie’ bevat normaal gesproken de ‘Naam’ die in de GIO wordt opgenomen. Deze wordt automatisch gegenereerd op basis van de bestandsnaam, maar is handmatig te wijzigen. Zet hier een zo beschrijvend mogelijke naam neer.

Overige velden

De optie ‘Features samensmelten’ zorgt ervoor dat features binnen een locatie samensmelten.

De optie ‘Filter’ (en daarbinnen ‘Attribuut’ en ‘Waarde’) kunnen gebruikt worden om te filteren op attributen en waardes. Op deze manier kan één bepaalde attribuut gekozen worden, die dan gebruikt wordt om op te groepen. Wordt daarnaast een specifieke waarde voor dat attribuut ingevuld, dan wordt daarop gefilterd.

Het kan zinvol zijn om ‘Losse GIO’s’ te selecteren indien van ieder attribuut / locatie een aparte GIO gewenst is.

Uiteraard heeft het selecteren van deze drie opties alleen zin als het bronbestand meerdere features / locaties bevat. Bovendien werken de drie bovenstaande opties samen; combinaties hiervan geven verschillende resultaten in de GIO(‘s). Een kort beschrijvend overzicht van wat welke combinatie oplevert is te zien in de tabel bij tabje ‘Uitleg’ (komt later nog aan bod).

Sectie Versie metadata

De sectie ‘Versie metadata’ geeft de mogelijkheid om een ‘Geboorteregeling’ op te geven. Dit gebeurt alleen voor consolideerbare informatieobjecten. Bij het maken van een consolideerbaar informatieobject is de geboorteregeling altijd bekend. Elke consolideerbare informatieobjectversie heeft een geboorteregeling. De geboorteregeling drukt de juridische relatie uit tussen de regeling en het informatieobject: ze vormen juridisch een samenhangend geheel. Als de geboorteregeling wordt ingetrokken, dan komt het informatieobject ook te vervallen.

Het format voor de geboorteregeling is: /akn/nl/act/<code BG>/<jaartal>/<nummer>. Hierbij is het veld:

<code BG> de code zoals hierna beschreven onder ‘Bevoegd Gezag’,

<jaartal> het jaar waarin de geboorteregeling is gestart / gepubliceerd.

<nummer> het nummer waaronder de betreffende geboorteregeling is gepubliceerd.

Sectie Metadata

Vervolgens wordt er nog ‘Metadata’ meegegeven aan de GIO:

Vul voor het veld ‘Eindverantwoordelijke’ de eindverantwoordelijke voor de te maken GIO in. Het format hiervoor is ‘/tooi/id/<code BG>‘, waarbij <code BG> de code is zoals hierna beschreven onder ‘Bevoegd Gezag’.

De ‘Maker’ wordt ingevuld in het format ‘/tooi/id/<code BG>‘. In veel gevallen zal deze string hetzelfde zijn als wat onder ‘Eindverantwoordelijke’ is ingevuld, maar dat hoeft niet altijd zo te zijn. Ook hier is <code BG> de code is zoals hierna beschreven onder ‘Bevoegd Gezag’.

De ‘Officiële titel’ is de titel die in het DSO boven de GIO komt te staan. Deze hoeft niet meer apart ingevuld te worden, want dat gebeurt automatisch als je de FRBRExpression in het eerste tabblad invult.

De ‘Alternatieve titel’ is de tekst die in het DSO getoond wordt als de GIO om wat voor reden dan ook niet grafisch getoond kan worden. Het is ook standaard de noemer van de GIO. Deze titel mag wat uitgebreider zijn, maar moet vooral heel goed beschrijven wat de GIO zou tonen.

Het veld ‘Opvolger van’ hoeft niet verplicht ingevuld te worden, ook omdat de GIO niet altijd een opvolger van een eerdere GIO is. Het format voor de voorganger is ‘/join/id/regdata/<BG code>/<jaartal>/<naam>‘, waarbij:

<code BG> de code zoals hierna beschreven onder ‘Bevoegd Gezag’,

<jaartal> het jaar waarin de vorige GIO is gepubliceerd,

<naam> naam van de GIO die opgevolgd wordt.

Zie https://koop.gitlab.io/STOP/standaard/1.3.0/data_xsd_Element_data_opvolgerVan.html voor meer informatie

Bevoegd Gezag:

Voor <code BG> dient een code ingevuld te worden voor het bevoegd gezag (eigenaar) over de aangeleverde data of GIO. In principe zouden de mogelijk te kiezen codes gepubliceerd moeten worden in de STOP standaard op https://koop.gitlab.io/STOP/standaard/1.3.0/identificatie_wl_dt.html#overheid, maar dat is (nog) niet gebeurd. Het gaat overigens altijd om één van de onderdelen van de volgende vier overheden. De waarde voor <code BG> is heetzelfde als de waarde voor de <overheid> in één van de volgende XML-bestanden:

Gemeente: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/gemeente.xml

Ministerie: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/ministerie.xml

Provincie: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/provincie.xml

Waterschap: https://gitlab.com/koop/STOP/standaard/-/blob/1.3.0/waardelijsten/waterschap.xml

Dus bijvoorbeeld ‘Ministerie van Buitenlandse Zaken’ heeft code ‘mnre1013’. Gemeente Breda is dan ‘gm0758’.

Sectie Projectie

In de sectie ‘Projectie’ is het veld ‘Kies een projectie’ al standaard ingevuld met het Nederlandse Coördinaat Referentie Systeem voor het Rijksdriehoekstelsel (‘EPSG:28992 - Amersfoort / RD New)’. De data voor de GML zal in verreweg de meeste gevallen al in het RD-formaat aangeleverd worden, omdat dat de geldende standaard is voor geo-gerelateerde data in Nederland. Het is ook het formaat waarin de data aan het DSO standaard aangeleverd dient te worden. Hoewel er meer keuzes mogelijk zijn en er ook nog Coördinaat Referentie Systemen (CRS) toe te voegen zijn zal bijna altijd EPSG:28992 gekozen moeten worden.

Sectie Bewerkingen

In de sectie ‘Bewerkingen’ laten we ‘Afronden op 3 decimalen’ bijna altijd aan staan. Ook wijzigen we het aantal decimalen niet. Voor het DSO is afgesproken dat de RD coördinaten met 3 decimalen worden aangeleverd. Met de keuze onder ‘projectie’ voor EPSG:28992 betekent dit dat de coördinaten met een precisie van 1 mm opgenomen worden in de GML.

Het veld ‘Valide maken’ is standaard aangevinkt. Laat deze selectie staan, want hierdoor wordt de te creëren GML gevalideerd waardoor er actief naar bepaalde fouten gezocht wordt. Mochten deze fouten gevonden worden dan worden ze bij het genereren van de GIO gerapporteerd.

Het veld ‘Minimale afstand vertices: x mm’ laten we standaard gedeselecteerd. Als er gebruik gemaakt wordt van hele grote grafische bronbestanden, kan het zinvol zijn om dit veld aan te vinken en de waarde voor minimale afstand vertices op bijvoorbeeld 10-100 mm te zetten. Het gevolg hiervan is dat kromme lijnen en cirkels worden opgedeeld in lijnstukjes van 10-100 mm, waardoor minder data opgeslagen hoeft te worden en de geproduceerde GML kleiner wordt. De juiste setting zal in dat geval vaak door ‘trial and error’ bepaald moeten worden.