Consistentie Bestuurlijke Gebieden Datasets

Datasets Bestuurlijke Gebieden
#1

In het kader van de consistentie (en hopelijk toekomstige integratie) van de Bestuurlijke Gebieden dataset, wilde ik graag het volgende nog even onder de aandacht brengen. Op dit moment kunnen de Bestuurlijke gebieden gedownload worden als GML en als GPKG. Als ik vervolgens kijk naar de properties van de elementen dan kom ik volgende verschillen tegen:

GML:
property ‘code’ is numeriek
properties zijn CamelCase (e.g. ligtInProvincieCode)

GPKG:
property ‘code’ is alphanumeriek (gaat een ‘0’ aan vooraf)
properties zijn snake_case (e.g. ligt_in_provincie_code)

Het lijkt me zinvol om dat gelijk te trekken.

Misschien hebben anderen hier ook nog een mening over. Mijn persoonlijke voorkeur gaat uit naar:

  • een numerieke code
  • snake_case (vanwege potentiële niet-hoofdletter-gevoelige zoek acties, en vanwege gebruikersperspectief.)

En als ik dan toch bezig ben zou ik de ligt_in properties sowieso laten vervallen omdat het voornamelijk leidt tot onnodige samenhang die door een beetje zichzelf respecterend GIS systeem zo ook wel opgelost wordt. Wat je nu krijgt is dat de provinciegrenzen niet overeen hoeven komen met de gemeente-properties, en die kruisverbanden wil ik in een dataset eigenlijk niet tegenkomen.

Er zou natuurlijk wel een samenhang kunnen zijn qua bestuur en die mag uiteraard best weergegeven worden, maar een dergelijke property moet dan wel geabstraheerd worden, dus liefst ook overdraagbaar zijn naar (en zin hebben voor) alle elementen in de dataset. Ik zie dus liever een property als:

valt_onder_gebied_code

En als we op (korte?) termijn bijvoorbeeld ook Waterschapgebieden gaan toevoegen dan kan een ligt_in property weer hele andere overwegingen met zich meebrengen. Misschien moet een ligt_in property dan een (komma-gesepareerde?) lijst zijn?

#2

Die “ligt in provincie” is wel handig omdat er gemeente namen zijn die dubbel voorkomen. Bergen in Noord-Holland en Bergen in Limburg dacht ik zo uit mijn hoofd .

Me dunkt dat er een nummerieke nul voorafgaat in de code in geopackage. Geen letter O. Wel vreemd als ie daardoor(?) een alfanumeriek veld is.

Verdere consistentie tussen verschillende bestanden is natuurlijk alleen maar te prijzen!

#3

Het verschil tussen casing van de properties / kolommen in GML en GPKG is bewust. Dit maakt deel uit van de Geopackage en de GML standaard. Zie OGC en de GML standaard, paragraaf 7.1.2 Lexical conventions:

There are several lexical conventions used in the GML schema for the names of elements and complex types to assist in human comprehension of GML instances and schemas:

  • objects are instantiated as XML elements with a conceptually meaningful name in UpperCamelCase;
  • properties are instantiated as XML elements whose name is in lowerCamelCase;
  • …

En de Geopackage specificatie:

…
For maximum interoperability, all user-defined GeoPackage table, view, column, trigger, and constraint name values SHOULD start with a lowercase character and only include lowercase characters, numbers 0-9, and underscores (_ ).
…

1 like
#4

Om te synchroniseren met de BGT of een toekomstig SOR model zal lowerCamelCase wel de gewenste vorm zijn.
GML is wat dat betreft restrictief. GPKG snake_case is overigens slechts een aanbeveling (geen eis) ten behoeve van uitwisseling, en juist voor die uitwisseling vind ik uniformiteit belangrijk omdat externe scriptjes en SQL statements dan blijven werken ongeacht bronformaat.

Wat code betreft begin ik na wat zoekwerk wel te vermoeden dat we daar in een heel diep en donker konijnenhol terecht gaan komen. CBS is blijkbaar verantwoordelijk voor de codes, maar hanteert twee lijsten: de CBS code en de SiSa lijst. Deze codes lijken door elkaar gebruikt te worden, al dan niet voorzien van alphanumerieke toevoegingen.

Als we daar ooit iets éénduidigs van willen maken dan moeten daar goede afspraken over gemaakt worden. Misschien iets voor Geonovum om nog eens verder uit te diepen. De verwijzing naar “CBS codes” lijkt vooralsnog onvoldoende, maar kan zijn dat ik in de relatief korte zoektocht iets gemist heb. Vragen die bij me opkomen zijn:

1/ welke waarde zetten we exact in het veld ‘code’?
2/ op dit moment is dat zonder gebiedstype indicatie. Is dat wel wenselijk?

Het code-veld lijkt nu dus zowel numeriek als alphanumeriek voor te komen (maar zonder letters). De toevoeging 0 of 1 heeft blijkbaar relevantie. Daarmee is het inderdaad een code (zoals in pincode), en dus niet ook een getal. (Dat heeft bijv consequenties voor sql-statements of sorteervolgorde.)

Om eventuele bestuurlijke samenhang te kunnen duiden is het natuurlijk wel belangrijk dat de code uniek is binnen alle gebieden. Een valt_onder_gebied_code(s) werkt uiteraard alleen als ook het gebiedtype wordt benoemd.

Voor de cbsgebiedsindelingen2024.gpkg hebben ze onderstaande indeling bedacht. Maar dat doen ze dan weer niet voor andere gebieden dan gemeentes. Is waarschijnlijk ook een éénrichtingsprobleem. Maar als je iets dergelijks wilt toepassen voor bestuurlijke samenhang, en als je dan ook nog eens waterschapsgebieden en veiligheidsregios wilt toevoegen, of ooit wilt uitbreiden in de toekomst, waar eindigt dit dan?

Feature
    gm_code
        GM0014
    gm_naam
        Groningen
    cr_code
        CR03
    cr_naam
        Overig Groningen
    cs_code
        CS030
    cs_naam
        Overig Groningen
    cp_code
        CP0300
    cp_naam
        Overig Groningen
    pv_code
        PV20
    pv_naam
        Groningen
    ld_code
        LD01
    ld_naam
        Noord-Nederland
#5

Bij PDOK is voorspelbaarheid erg belangrijk. We voldoen om bovengenoemde reden aan de verwachting dat:

  • een dataset met snake_case wordt uitgeleverd bij Geopackages
  • en bij GML in (Upper/lower)CamelCase

Data die PDOK uitserveert is een halfproduct waarbij we zo voorspelbaar mogelijk de data willen uitleveren. Voldoen aan standaarden en conventies, of ze nu heel hard worden vereist of afgedwongen, of niet, hoort bij het voldoen aan die verwachting. Waarbij we zo veel mogelijk: 1) conformeren aan generiekere standaarden (bijvoorbeeld van het dataformaat); verkiezen boven: 2) specifieke standaarden (bijvoorbeeld van een dataset).

Dat er clientside nabewerking moet plaatsvinden om aan bepaalde usecases te voldoen is onontkomelijk, er zijn verschillende eisen/wensen vanuit gebruikers. PDOK services zijn te zien als halfproduct. Er is altijd een client nodig om de PDOK services te gebruiken. De PDOK viewer is een voorbeeld van zo’n client, net zoals bijvoorbeeld GIS tooling voor het uitlezen en bewerken van Geopackages. Er zijn veel gebruikers die snake_case verwachten bij geopackage. Daar voldoen we dus aan. Dus snake_case is de gekozen vorm in Geopackages en de [Upper|lower]CamelCase bij GML.

Als laatste: In principe is de data in Geopackages te vinden en in GML, waar eigen verwerking en updates mee mogelijk zijn op basis van die formaten, omzetten tussen die formaten is dus meestal niet nodig.

2 likes
#6

Bedankt voor de toelichting. Lijkt me een helder en logisch onderbouwd standpunt.

3 likes