Editor’s note – Geoawesomeness Guest Features is an on-going series that spotlights the thoughts, experiences and expertise of our guest writers. We want to encourage a broad set of writers to inform, delight and challenge us all. Together, let’s build a more diverse, inclusive and welcoming Geospatial community. 

Give Me a Standard, Any Standard

I’ve spent the last year or so doing very little with geospatial technology, but I find myself missing it tremendously. Of course “in my blood” and “how I’m wired” and similar aphorisms apply to how I’m feeling, but that’s not what really has me missing geospatial. In a shocking (for me) turn of events, I find myself missing the influence of OGC on the geospatial technology community.

I’ve spent the last year working on integrating several SaaS systems, including Stripe, Salesforce, NetSuite, and others. I’ve touched upon this in previous posts. All of them implement some form of REST API, but fostering interoperability doesn’t seem to be a primary purpose of those APIs as much as is the enablement of a proprietary partner/strategic-alliance ecosystem. As a result, these APIs, while generally well-documented, are essentially arbitrary. They implement the HTTPS+JSON pattern in the same way that many written languages implement the Roman alphabet. I can sound out the words, but I don’t really have any idea what I’m saying.

In the geospatial field, the work of OGC gives us a bit more shared understanding. Because of the Simple Features Specification, we have GeoJSON, GML, GeoPackage, and various similar implementations across multiple open-source and proprietary database systems and data warehouses. Each of those implementations has benefits and shortcomings, but their common root shortens the time to productivity with each. The same can be said of interfaces, such as WxS. I have often been critical of WxS, but, for all the inefficiencies across the various specs, they do provide a level of predictability across implementing technologies which frees a developer to focus on higher-level issues. I include Esri here, which does a good job of implementing simple features and makes some WxS interfacing available, even if they keep their more compelling capabilities behind a proprietary curtain.

Outside of geospatial, there seem to only be proprietary curtains, which you cannot part without an NDA, or a partner agreement, or a strategic alliance or some other piece of paper which serves to ensure that the walls around the garden are both high and well-guarded. Feature-completeness takes a back seat to lock-in. As a result, API-to-API integrations are fragile, IPaaS solutions generally don’t expose everything from platforms they “support,” and data integration strategies are limited by whatever the proprietary APIs choose to expose.

Among all of this, there’s the additional issue of understanding. The content itself is fully bespoke from the top down, turning each integration project into an exercise where every API and its content must be approached as though it is the first API we have ever seen.

Venturing through the wilderness of mainstream tech has made me appreciate the efforts of OGC a little more. It’s easy, when focused heavily on only geospatial tasks, to overindex on the gaps and shortcomings of OGC specifications and their various implementations. Viewed in relief, against the backdrop of arbitrary and proprietary technologies outside of geospatial, the value of the baseline standardization established by OGC, and the expectation of such in the geospatial community, becomes much more apparent.

Header image: Mark Turner from Plymouth, England, CC BY 2.0 https://creativecommons.org/licenses/by/2.0, via Wikimedia Commons. 

This article was originally published by Bill on his blog “Geomusings” and has been republished here with permission. 

Did you like the article? Read more and subscribe to our monthly newsletter!