PostGIS - ook voor ArcGIS gebruikers - the sequel

Op de GeoBuzz op 17 november en via LinkedIn kreeg ik verrassend veel respons op mijn eerdere blogpost over Postgres, Postgis en Arcgis. Daarom had ik eigenlijk op PostGIS dag (20 november) een korte presentatie willen houden, maar een forse verkoudheid stak daar een stokje voor.
Bij deze daarom alsnog een vervolg op die blogpost.

Ten eerste de functionaliteit vanuit ArcGIS perspectief. Die is voor de ST_Geometry (de Esri opslagwijze) iets anders dan wanneer je voor "echt" PostGIS (PG_Geometry in ArcGIS termen) kiest.
ST_Geometry dwingt namelijk af dat a) een geometry valide moet zijn (geen self-intersections etc.). PostGIS (PG_Geometry) laat qua opslag alles toe, en laat het aan de client (web, desktop) over om te zorgen dat een geometrie valide is. Al kun je dat zelf met een trigger in de database wel forceren, zie dit voorbeeld.

Een tweede aspect is het type geometrie. PostGIS (PG_Geometry datatype, in Esri terminologie) staat verschillende geometrie-typen (punt, lijn, vlak) toe in één kolom in een databasetabel. ArcGIS vind dat niet leuk en kan daar over struikelen, vandaar dat de ESRI-eigen opslag (als Esri ST_Geometry) al "aan de voorkant", dus bij invoeren en wijzigen kijkt of een geometrie wel van het juiste type is.

Ook dit kun je aan de PostGIS kant oplossen, namelijk door de geo-column als een expliciet geometrietype aan te maken, dus geen "ALTER TABLE mytable ADD geom geometry(;" maar "ALTER TABLE mytable ADD geom geometry(point, 28992);" (met zoals je ziet er gelijk even het SRID 28992, voor ons Rijksdriehoekstelsel expliciet aan toegevoegd).

Daarnaast kreeg ik nog wat opmerkingen waarom Esri zo verwarrend is in haar naamgeving door ST_Geometry te gebruiken voor haar eigen datatype, en dat wat in PostGIS alom bekend staat als ST_Geometry juist als PG_Geometry aan te duiden.
Tja, dat kun je Esri nauwelijks kwaad nemen. ST_Geometry is immers geen door PostGIS uitgevonden naam, het stamt uit de definitie van de ISO SQL/MM standaard ("for multi-media and spatial") uit begin deze eeuw. Daarop voortbordurend is in zowat alle RDBMS-en met spatial opslag en functies deze naamgeving overgenomen. Zelfde vlag, met in ieder RDBMS een iets andere lading dus.
(terzijde: die prefix "ST_" blijkt oorspronkelijk voor Spatial and Temporal te staan)

Overigens kan het nooit kwaad om bij mix van ArcGIS spullen met andere spullen het virtuele "Esri-woordenboek voor anderstaligen" er even bij te pakken;
Een Esri geodatabase is echt wat anders dan een willekeurige  database met spatial mogelijkheden (want meer intelligentie, maar daarmee ook meer afhankelijkheden tussen systeemtabellen).
En een ArcGIS Map Package of Project Package (.ppkx) waarmee je een heel project inclusief data met de buren kunt uitwisselen heeft weinig van doen met een (OGC) Geopackage. Nog sterker, in zo'n Project Package (eigenlijk een 7Z gecomprimeerde folder) wordt de data juist niet als OGC Geopackage, maar als Esri's eigen file geodatabase uitgewisseld.

Over dat uitwisselen meer in een volgende blogpost.

20 nov. 2025: PostGIS day - óók voor ArcGIS gebruikers

Begin van deze eeuw vroegen ArcGIS gebruikers keer op keer aan Esri wanneer er -naast support voor de grote commerciële enterprise RDBMS-en Oracle, SQL Server, IBM DB2 en Informix nou ook eens ondersteuning voor PostgreSQL zou komen. In 2010 was het met ArcGIS 9.3 eindelijk zover, en schreef Alex Tereshenkov er een mooie "introductie postgresql voor arcgis-ers" voor.

15 jaar later is de combinatie ArcGIS en Postgres zo ingeburgerd dat Esri het zelf als back-end gebruik voor haar ArcGIS Datastore (oneerbiedig gezegd de plek waar ArcGIS enterprise eindgebruikers hun geo-analyseresultaten kunnen opslaan zonder zich te hoeven bekommeren over datamodellen, indexen etc.)

Los van die klik-klak-klaar Datastore wordt PostgreSQL door Esri meer en meer omarmd als enterprise geodatabase, om het in ArcGIS termen te zeggen. Van oudsher levert Esri daarvoor een stukje middleware dat er voor zorgt dat geodata als eigen datatype in een database (Oracle, Postgresql, SQL Server) kan worden opgeslagen, en er spatial functies ("buffer" etc.) op kunnen worden losgelaten. Dat was en is een eigen Esri geometrie-type (ST_Geometry), los van Oracle Spatial of PostGIS geometrie-typen. Unique selling point was dat de implementatie in Oracle, Postgresql, DB2, Informix en SQL Server (vrijwel) gelijk was.

Toch kon je in plaats van die ST_Geometry er ook altijd al voor kiezen om PG_Geometry als opslagtype te kiezen, het geo-datatype dat met PostGIS meekomt (PostGIS is geen core Postgresql, maar een postgres-extensie!). Dat biedt meer mogelijkheden om geodata generiek naar verschillende clients, ArcGIS en niet-ArcGIS (QGis, GeoServer en nog heel veel meer) te ontsluiten. 

Kiezen voor PG_Geometry (en dus voor PostGIS) heeft nog een groot voordeel. De installatie van de DLL/shared library die de ST_Geometry functionaliteit bevat is erg ArcGIS en RDBMS-versie afhankelijk. Nog belangrijker: in cloud omgevingen (Microsoft Azure, AWS etc.) is het vrijwel nooit mogelijk om even een DLL naast je cloud-database te kopiëren.
PostGIS is hierin veel gemakkelijk; iedere zichzelf respecterende PostgreSQL-cloud aanbieder heeft óf PostGIS daar al standaard bij geïnstalleerd óf biedt dit via een eenvoudig aanklikbare optie aan.

Dat geldt trouwens niet alleen voor PostGIS, maar ook voor aanverwante extensies als PG_Routing, PG_Raster en zelfs Postgres FDW en nog veel meer.

Terug naar de titel van deze blogpost: PostGIS is dus zeker ook een aanrader voor ArcGIS-ers. Op 20 november 2025 organiseert OSGeo.nl ter gelegenheid van PostGIS day een studiedag, in Utrecht. Zie https://postgisdag.nl/ voor de details (s.v.p. wél even aanmelden!)

Temporele datakwaliteit: een Topotijdreis langs Amsterdamse stadions

10 jaar Topotijdreis! Dat is allereerst een felicitatie aan het Kadaster die samen met Esri Nederland het aloude op een regenachtige zondagmiddag met een beker warme chocolademelk en de poes op schoot door een atlas bladeren nieuw digitaal leven inbliezen door de topografische kaartcollectie via een eenvoudige en daardoor doeltreffende online viewer beschikbaar te maken.

Ook bij die digitale variant is de warme chocolademelk een fijn gezelschap. En de poes wandelt gezellig mee over het toetsenbord.

Als datakwaliteitscriticus kijk ik wel scherp naar de temporele kwaliteit van het aangeboden topografische snoepgoed. Tot begin van deze eeuw was de updatefrequentie van de topografische kaarten laag (minimaal 5 jaar, soms 10 jaar) waardoor we bij het Ministerie van VROM ons af en toe genoodzaakt zagen de ontbrekende snelweg of stadsuitbreiding zelf met de hand aan het kaartbeeld toe te voegen, om onze Minister en zijn/haar kompanen in het Kabinet een actueel beeld van Nederland voor te schotelen. 

Nu gaat het bij TopoTijdreis per definitie niet perse om een actueel beeld (het gaat immers om historische data), maar wel om een temporeel correct beeld, en als het kan ook een beetje consistent. 

Dat betekent drie dingen. Ten eerste dat het getoonde kaartbeeld moet kloppen met het in de viewer gekozen jaartal, ten tweede dat bij in en uitzoomen het kaartbeeld een weergave is van het geselecteerde jaar en ten derde dat het kaartbeeld ook waar 2 of 4 gedigitaliseerde kaartbladen aan elkaar raken een samenhangend beeld opleveren.

Dat is niet eenvoudig, want de oudere kaartbladen (zeker die uit de eerste helft van de 20e eeuw) kenden een nog veel lagere updatefrequentie, soms zelf maar om de 20 jaar (en de Tweede Wereldoorlog gooide dan ook nog eens roet in het "update-eten") en tussen inwinning/verkenning en jaar van uitgifte van een kaartblad kon ook een paar jaar zitten. In Topotijdreis kies je met de jaarschuifbalk dan ook eigenlijk dat jaar van uitgifte, en niet het jaar van inwinning. 

Dat die temporele marge groot is kun je mooi zien aan de hand van de bouw van grote voetbalstadions. Daarvan is bouw en opleverjaar vaak wel bekend. De bouw van het Olympische Stadion in Amsterdam-Zuid van architect Jan Wils is gestart in mei 1927, en een krap jaar later is het opgeleverd, 17 dagen voor de start van de Spelen. Er stond voor die tijd al een stadion aan de overkant van de Amstelveense weg. "Het Stadion", want er was in heel Nederland maar één stadion. Bouw gestart in 1913, opgeleverd in 1914, en slechts 15 jaar later, in 1929 (na tijdens de Spelen als hulpstadion te hebben gediend) alweer afgebroken.

Hoe ziet dat er op Topotijdreis uit?

In 1914 was er nog geen stadion te zien:

Pas in 1929 (een jaar ná de Spelen) komt er een stadion tevoorschijn.

Maat wacht eens, dat is het "oude" Stadion, dat in 1929 juist werd afgebroken!

Pas in 1952 komt het Olympisch Stadion op de kaart. Zo te zien mét de in 1937 aangebrachte en in 1998 weer verwijderde tweede ring:

Het beeld van 1951 is heel divers: met nog wel het in 1929 afgebroken "Oude Stadion". We zien echter rechts een veel actueler beeld met oa. het Beatrixpark van 1938. Dat het linkeronderkwadrant anders oogt lijkt een visueel dingetje; het wat fletse, onscherpe kaartbeeld lijkt inhoudelijk in ieder geval hetzelfde als het wel scherpe beeld van de voorafgaande jaren.

Met die eerder genoemde tweede ring is ook wat vreemds aan de hand.

In 1999 lijkt deze verwijderd (gezien de dunnere stadionovaal):

maar 2 jaar later is die tweede ring weer terug!

Pas vanaf 2008 is die ring definitief weg.

En de Rotterdamse Kuip dan? Heel saai: die verschijnt in 1938 (twee jaar na de oplevering) al op de kaart, en blijft dat ook. Vooralsnog tot in de eeuwigheid, want over die nieuwe Kuip wordt al 20 jaar gesproken, maar er wordt nog niets gebouwd ...

Moraal van dit verhaal: Topotijdreis is en blijft een heerlijk digitaal bladerboek, maar denk even goed na voordat je harde conclusies verbindt aan de getoonde jaartallen. 

En mocht je meer willen weten over niet alleen temporele maar allerlei aspecten van (geo-)datakwaliteit dan kan ik een blik op het datakwaliteitsraamwerk van Rijkswaterstaat aanraden. Zeer compleet, en toch makkelijk behapbaar.

15.000 Miljoen: poen waar je veel mee kunt doen!

Op aandringen van "de sinaasappel uit het Witte Huis" zijn de NAVO landen deze zomer zowat allemaal akkoord gegaan met een verhoging van hun defensiebudget ("oorlogsbudget, als het aan Trump zou liggen) naar 5% van het BBP. Ook in ons land is daar brede steun voor, slechts SP en FvD zijn tegen deze verhoging. 

Daarbij is afgesproken dat 3,5 procent echte om "harde" defensie-uitgaven moet gaan, en 1,5% met defensie-gerelateerde uitgaven mag worden ingevuld.

Wat een kans voor de geo-sector!

Voor de jongere lezers: de Topografische Dienst (15 jaar geleden opgegaan in Kadaster) is in 1815 als Dienst Militaire Verkenningen begonnen als onderdeel van het toenmalige Departement van Oorlog (inderdaad: een Trumpiaanse naam!). 

Geheel in die traditie van topografische kaarten ("topografische-militaire kaarten") zouden we die 1,5%, dat is 15 miljard euro!, per jaar!!,  zonder blikken of blozen aan de Nationale Geografische Infrastructuur (NGII) kunnen besteden.

Om het in perspectief te plaatsen: de "brede kosten" van de huidige NGII worden op circa € 350 miljoen geraamd (prijspeil 2024)
(bron: https://www.algemenebestuursdienst.nl/binaries/abd/documenten/publicatie/2024/04/15/naar-een-goed-geodata-ecosysteem/Naar+een+goed+geodata-ecosysteem.pdf)

Natuurlijk kunnen we wat van die 15 miljard ook besteden aan verbetering van onze fysieke infrastructuur, zodat de onze jongens en meisjes op weg naar de IJssellinie niet nog vóór Apeldoorn door een door betonrot aangevreten viaduct storten. Dan nog blijft er een leuk bedrag over.

En misschien kunnen we met een héél klein deeltje van die 15 miljard het onvolprezen onderzoek naar post-militaire landschappen uit 2004 (met het ministerie van VROM als opdrachtgever) een handgenaaide heruitgave met goudband bezorgen.

Tot die tijd doen we het met:

• het rapport bij Kenniscentrum waterlinies
• de bijbehorende kaarten met linies, forten en inundatiegebieden (helaas is de legenda niet te vinden, maar let wel even op de bronvermelding rechtsonder op iedere kaart)
• de vermelding van de onderliggende geodataset in het NGR
• en niet verder vertellen: volgens mij heb ik de bijbehorende shapefiles (jakkes!) hier nog op een 3,5 inch floppy (huh?) in een laatje liggen.