Datamodellen en geopackage, hoe werkt dat?

Standaarden
#1

Heeft iemand slimme tips voor het valideren en of afdwingen van specifieke invoer bij geopackages?
Ik heb een datamodel-beschrijving dat voornamelijk op attribuutniveau (niet op geometrie) verschillende beperkingen oplegt. Deze wil ik graag in een geopackage implementeren en dan zodanig dat derden met de geopackage data kunnen invoeren, muteren en weer terugsturen als geopackage.

Ik heb ooit geleerd dat een geopackage niet bedoeld is als uitwissel-bestand en dat datavalidatie daarom 'minder belangrijk is, maar het grote voordeel is natuurlijk wel dat een geopackage ‘gewoon’ in GIS kan worden ingelezen, gevisualiseerd, bewerkt en weer opgeslagen kan worden.
En een geopackage wordt in Nederland wel als open standaard beschouwt en daarmee als een van de preferred bestandsformaten om mee te communiceren.

Veldtype en veldlengte zijn makkelijk in te stellen, hoewel veldlengte alleen kan bij tekstvelden (GPKG ondersteunt geen veldlengte bij getallen).

In QGIS kun je allerlei constraints instellen met een QGIS projectbestand (via formulier-attributen kun je onder andere waardenkaarten/keuzelijstjes maken, of ranges voor hele getallen en voor komma’s). Maar heel erg hard is zo’n formulier ook niet; als je nieuwe objecten toevoegt via een een join bijvoorbeeld, dan kunnen er prima foutieve waarden ingevoerd en opgeslagen worden.
En als je een gpkg ‘buiten het project’ bewerkt, werken die constraints ook niet meer.

Op gpkg-database-niveau kun je sinds enige tijd ook domeinwaarden (keuzelijsten en getallenranges) instellen, maar ook daar zitten beperkingen op, zo werken getallenranges nog niet bij decimal-veldtypen.

En als dit allemaal al lukt, kan ik het gpkg datamodel dan overnemen in bijvoorbeeld een PostgreSQL database en van daaruit weer terug naar een geopackage? Zijn veldtypen als een DATE in geopackage hetzelfde als een datumveld in postgresql?

Ik ben dus vooral op zoek naar een goede manier om een datamodel te koppelen aan een geopackage.
Ik heb in de QGIS-plugins wel iets gezien over een Interlis datamodel (QGIS Model Baker), maar ik heb geen idee of Interlis een in Nederland bekend\gebruikt systeem is.

En voordat er basisregistratie-achtige oplossingen met jaren ontwikkel-tijd worden geost, ik heb het over kleinere toepassingen, een beperkt aantal externe gebruikers, beperkt aantal objecten (paar duizend op z’n hoogst) per gebruiker :slight_smile:

Wie heeft er tips en trucs?

#2

Goede vraag. Een paar jaar geleden kwam dit ter sprake in onze werkgroep ‘lichte uitwisselformaten’. Destijds was de conclusie dat Geopackage zelf geen validatie ondersteunt. In de praktijk werd dit toen bijvoorbeeld opgelost door het datamodel in een GML schema uit te drukken, en dan het te valideren bestand te converteren naar GML en dan tegen het GML schema te valideren.

Of er nu meer mogelijk is in Geopackage zelf weet ik niet direct. Ik heb een collega die hier meer van weet de link naar dit topic gestuurd.

#3

Allereerst: er is een extensie mogelijk op geopackages waarin het mogelijk is om schemas vast te leggen. Sinds gdal 3.3. wordt dit ook door gdal ondersteund. Dit maakt het dus mogelijk om op een standaard manier een schema vast te leggen in een geopackage. Ik ben alleen niet bekend met een validator die daar gebruik van maakt.

Bij PDOK maken wij gebruik van Geopackage als uitwissel formaat. Daarbij maken wij (nu in iedergeval) geen gebruik van die extensie. Wij stellen wel een aantal eisen aan geopackages, waaronder afspraken over het database schema. Dit valideren wij ook middels een door ons onderhouden geopackage validator. Die validator maakt gebruik van een met die validator te genereren database schema. Zie ook op PyPi. Let wel: deze validator is opinionated en bevat een vaste default set met validaties die bij versie bumps kan wijzigen. Daarnaast werkt deze buiten QGIS en is deze alleen aan te roepen op de commandline / met python. We zullen echter nooit validaties verwijderen maar alleen updaten, waarbij er nieuwe regels bij komen en het is sowieso mogelijk om aan te geven op basis van welke regels je de geopackage wenst te valideren. Dus mocht je behoefte hebben aan validatie is dat een mogelijkheid.

#4

Bovenstaande gaat er vanuit dat je dus wel gebruik maakt van de commandline of evt. python (en dat je gdal hebt geinstalleerd). QGIS maakt onder water gebruik van gdal (OGR). OGR maakt onder water gebruik van eigen data typen waar mee een omzetting gemaakt (die eigen data typen gebruiken wij in de bovengenoemde geopackage validator). Dus met QGIS overzetten van geopackage naar PostGIS zou in principe goed moeten gaan.

#5

Als je je datamodel bij de bron al wil afdwingen, zou ik voor deze uitwisseling GML gebruiken. Je kunt dan gemakkelijk via de XSD je datamodel afdwingen (“niet terugsturen als 't niet valideert”). Verder zijn er vrijwel geen gegevens formaten die geschikt zijn voor uiitwisseling waarin je een datamodel kunt “afdwingen”, je kunt altijd buitenom gaan en er rubbish in stoppen. Tenzij je een volledig gesloten gegevensformat ontwikkeld, dat alleen door jouw applicatie te lezen en schrijven is.
Het scenario zoals je dat schetst, laat altijd en overal ruimte voor vervuiling op welke manier dan ook. Het is naar mijn mening beter om er voor te zorgen dat teruggestuurde data eerst tot in detail gevalideerd word, voordat je het in je database zet - liefst op het moment dat het aangeboden word, zodat de aanbieder meteen feedback kan krijgen over wat er mis is met zijn/haar aangeleverde gegevens. En dat soort validatie kan met allerlei tools gedaan worden.

Dit vind ik een interessante. Naar mijn mening is een geopackage juist uitermate geschikt voor uitwisseling, omdat het veel informatie kan bevatten, 1 bestand is, (eventueel gezipt) gezipt heel goed te versturen is, en vrijwel iedereen kan er tegenwoordig goed mee om gaan. Dus wie je dit geleerd heeft, zou ik graag om uitleg willen vragen waarom hij/zij dit zegt, want het verbaast me nogal.

#6

In 2022 en 2023 is er zowel voor FGDB als GPKG betere ondersteuning gekomen in GDAL en QGIS. Dit om beide formaten bruikbaar te maken voor eenvoudige data-uitwisseling tussen organisaties.

QGIS ondersteunt dit in de user interface, zie bijvoorbeeld deze post van de ontwikkelaar:

Ik heb net zelf een domeintabel met 3 waarden toegevoegd aan een gpkg en dat ging prima. Helaas kon ik die niet aan een veld koppelen, waarschijnlijk omdat mijn gdal 3.5 is en je 3.7 nodig hebt. Kwestie van tijd dus, maar probeer het vooral zelf.

Gml’s met xsd-validatie is natuurlijk de perfecte manier, maar ook VEEL te ingewikkeld voor de gemiddelde gebruiker. Daarom zie je ook nog zoveel uitwisseling in FGDB-formaat (proprietary) en wordt dat binnenkort hopelijk in GPKG-formaat (open).

1 like
#7

Ik bedoel hier precies mee wat jullie ook teruggeven in deze post, dat een gpkg niet (heel) geschikt is voor data-validatie en dat dit vaak een belangrijk onderdeel is van data-uitwisseling.
Een geopackage is inderdaad heel prettig om data te delen (te geven of te ontvangen), maar dus minder voor het over en weer data-uitwisselen die steeds gemuteerd wordt en moet voldoen aan een datamodel. Dan kom je dus op externe oplossingen voor validatie. Ik ga zeker eens kijken naar de PDOK geopackage validator.

#8

Ja, daar maak ik al gebruik van, maar de functionaliteit is nog beperkt zoals ik in mijn opening al even aangaf. Een domein tabel kan, en die kan ik ook koppelen aan een tekstveld (QGIS 3.28 windows versie heeft gdal 3.8.x), maar een getallenrange kan op dit moment alleen integers aan en geen kommagetallen. En de user interface van QGIS kan alleen domeinwaarden maken en koppelen aan een veld, maar niet domeinwaarden aanpassen, domeinen verwijderen of weer loskoppelen van een veld. Dat werkt overigens wel prima met een extern programma als DB Browser (sqlite) waarmee ik in de systeemtabellen van een geopackage kan editen.

Precies dit. Daarom deze vraag om tips en trucs.

Is het bijvoorbeeld aan te raden om bij een geopackage altijd een QGIS-project mee te leveren? Zodat je met formulier-attributen kunt werken? En bijvoorbeeld controle velden inbouwt met berekeningen, of een styling die bijvoorbeeld objecten rood kleurt als ze waarden hebben die niet aan het datamodel voldoen?
Of roep je dan weer allerlei nieuwe problemen op, omdat er zoveel versies van QGIS zijn en project-bestanden niet per definitie goed functioneren tussen versies?

Zijn er trouwens buiten QGIS en de ESRI producten nog toepassingen die gpkg gebruiken (maken, editen)? Of is dit in de Nederlandse praktijk verwaarloosbaar en mag je er van uitgaan dat wanneer iemand een gpkg gebruikt dit ook altijd in QGIS is?

#9

Misschien kan de functionaliteit verder uitgebreid worden. De huidige functionaliteit is door een aantal partijen gezamenlijk ontwikkeld en betaald, dat zou voor een volgende fase weer kunnen.

Ik zou geen QGIS-project in de gpkg stoppen,. Het mooie van een gpkg is dat het een open formaat is, onafhankelijk van de software (nou ja, wel van sqlite zelf natuurlijk) en dat zou ik zo houden. Zo kunnen alle applicaties er potentieel gebruik van maken.

Geen idee wat ze allemaal precies kunnen, maar hier een lijst met applicaties waarin gpkg is geimplementeerd:
http://www.geopackage.org/implementations.html

1 like