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.
Geen opmerkingen:
Een reactie posten