Opslagformaat geometrie

Inleiding

In het geval van enterprise geodatabases is er de keuze voor ST_GEOMETRY of POSTGIS (GEOMETRY voor 2D of GEOGRAPHY voor 3D) als het opslagformaat. ST_GEOMETRY is een proprietary formaat van Esri, waarvoor Esri tooling / license benodigd is om het uit te kunnen lezen en weg te kunnen schrijven. Het kan overigens wel door SQL functies omgezet worden in Well Known Text (WKT) en Well Known Binary (WKB), maar ook daarvoor is een licentie benodigd (zie o.a. de enigszins oude Oracle discussie hier).

Het POSTGIS opslag formaat is beschreven middels liblwgeom. Dit betekent ook dat er geen speciale/proprietary tooling nodig is om het geometrie formaat te kunnen uitlezen en wegschrijven. Zie ook comment van Paul Ramsey hieronder:

Tweede link over extended WKB staat hier.

Dit document zal de voors en tegens beschrijven van beide opslagformaten, en proberen te beargumenteren waarom het voor Rijkswaterstaat beter is om in de data laag geen afhankelijkheid te hebben.

FME

Vanuit FME bekeken zijn er een aantal overwegingen. In het geval van Esri’s ST_GEOMETRY wordt normaal gesproken het formaat “ArcSDE Geodb” gebruikt. Dit formaat is echter alleen beschikbaar op Windows, en heeft een afhankelijkheid naar ArcGIS Server Basic. Zie ook: Using FME Flow with Esri ArcGIS Software – FME Support Center. Er kan ook middels ArcPy gewerkt worden.

Per FME Flow engine server is een licentie van ArcGIS Server Basic benodigd. Dit betekent in het geval van RWS (OTAP) in totaal 8 licenties om het ST_GEOMETRY te kunnen lezen en schrijven.

Het betekent ook dat er bij de migratie naar OpenShift een probleem is, en dat de Remote Engine Service de enige workaround is. Voor details zie de FME Flow en Kubernetes FAQ: FME Flow and Kubernetes FAQ – FME Support Center.

In het geval dat de geometrie in PostGIS opgeslagen is, zijn er geen ArcGIS Server Basic licenties benodigd, en is er ook Linux support voor de driver wat het makkelijker maakt in de OpenShift omgeving.

Overigens is misschien nog een tussenoplossing de SQLExecutor gebruik makend van sde.ST_AsBinary().

Het zou ook interessant zijn om zicht te verkrijgen in de meest gebruikte drivers binnen de FME omgeving.

Het database argument

Een argument wat soms gebruikt wordt, is dat ST_GEOMETRY van Esri in meerdere databases gebruikt kan worden. Alhoewel dit waar is, is de kans dat een organisatie van database verandert niet zo heel groot.

Feedback vanuit Esri Nederland

De vraag is ook voorgelegd aan Peer Molenaar van Esri Nederland en dit was zijn antwoord:

“Voor wat er wordt ondersteund kan je hetzelfde doen als met de ST-Geometry types. Je moet dan natuurlijk wel via een SDE verbinding werken (dus de Esri hulptabellen zijn dan wel aanwezig). Werk je via een Query layer, dan zijn er veel minder mogelijkheden. Er kunnen wat kleine performance verschillen in zitten, omdat de geometrie anders wordt opgeslagen. Die zijn bij PostgreSQL echter niet groot. 

Het grootste risico is het gebruik van de data in andere applicaties. Als je van buiten ArcGIS de data bekijkt, gaat dat prima, maar als je gaat editen op die data, omdat het toch Postgis data types zijn, dan kan dat veel ellende opleveren, omdat je de SDE hulptabellen niet bij werkt. Dat kan corruptie in de database opleveren en alle bijbehorende ellende. Editen dus altijd via de API, en niet direct op de database.”

Conclusie

Om een quote aan te halen van de provincie Zeeland: “Nee, Ook SDE zijn we uit de databases aan het halen. Gewoon Postgis native schema’s die voldoen aan de standaarden. Juist in de database wil je geen levanciers afhankelijkheid.”.

Voor geavanceerde edit use cases middels Esri software zal je echter niet ontkomen aan de SDE hulptabellen, dus voor Rijkswaterstaat ligt dit net wat anders. Maar het opslagformaat van de geometrie aanpassen zou een goede eerste stap zijn. ArcSDE versioning is dan nog wel een aandachtspunt, maar met branch versioning zou de SQL WHERE clause eenvoudiger moeten worden, in ieder geval vergeleken met traditional versioning (losse add/delete tabellen).

De voordelen om geen leveranciers afhankelijkheid in de database laag te hebben zijn m.i. evident. Bijvoorbeeld er zijn legio meer tools in de markt die PostGIS geometrie kunnen lezen dan Esri enterprise geodatabases met ST_GEOMETRY. Helaas is het zo dat in de huidige situatie (IST) er behoorlijk wat enterprise geodatabases draaien met ST_GEOMETRY als geometrie formaat. De migratie hiervan zal behoorlijk wat pijn kosten. Een overzicht maken van de huidige situatie lijkt een nuttige eerste stap. Het is sowieso verstandig om voor nieuwe databases PostGIS de standaard te maken, en een goed beargumenteerde exceptie nodig te hebben om hiervan af te mogen wijken.

Om het risico dat Peer Molenaar beschrijft, namelijk niet editen direct op de geodatabase met andere tooling, te mitigeren, zal je ervoor moeten zorgen dat er duidelijke richtlijnen en werkprocessen zijn en dat de credentials waarmee gewijzigd kan worden bij zo min mogelijk mensen bekend zijn.

Hieronder staat een beslisboom om te helpen bij de keuze voor het geometrie opslag formaat: