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!)