On August 10, 1846, Congress established the Smithsonian Institution with a simple mission: “the increase and diffusion of knowledge,” and gave it “perpetual succession.” One hundred eighty years later, the Smithsonian is still here, though almost everything about how it carries out that mission has changed. (siarchives.si.edu)
The people who established the Smithsonian couldn’t have anticipated photography as we know it, electronic databases, satellite imagery, the web, cloud computing, or whatever comes next. They didn’t need to, because the mission was broad enough to survive repeated changes in the machinery used to accomplish it. The Industrial Revolution was well under way in the United States. Railroads and factories existed, so the Smithsonian was established with ready object lessons in how quickly technology and society could change.
We discuss history a lot in our household and I think about the rapid advances of the Industrial Revolution a lot in comparison to the pace of technological change since I began my career in 1992. As we have iterated and re-iterated on geospatial infrastructure design, one thing has become abundantly clear: we have to assume the technology will change.
When we design systems expected to last for years or decades, we tend to ask which technologies will still be around. Will PostGIS still matter in 2046? What about GeoPackage/GeoParquet/PMTiles? Will S3 still be a thing? Will APIs even matter?
I’m increasingly convinced these are the wrong kinds of questions. We should be thinking about how to build infrastructure that doesn’t require us to know the answers.
The recovery tax
I was reminded of this repeatedly in my consulting, most recently by the Personal Geodatabase (PGDB). For a long time, in the Esri ecosystem, the Personal Geodatabase was a perfectly reasonable place to put geospatial data. It fit naturally into the ArcGIS world of its day, stored everything in a convenient Microsoft Access database and supported capabilities beyond what a pile of shapefiles could provide.
It never quite became the shapefile replacement that Esri hoped it would, but it was useful. Long column names alone made it attractive. But it was still dependent on the Microsoft Jet database engine, and it was still terrible for multi-user access. It also never saw the interoperability uptake that the shapefile did. Eventually, the world moved on. Microsoft dropped support for Jet and Esri introduced the file geodatabase, which was simultaneously less open and more useful. Nice trick.
I was working on a project where much of the historical data was in PGDB format. I had ArcGIS Pro, which did not read them at the time, and I could no longer get ArcMap. That may not have even solved my problem because Microsoft never shipped a 64-bit driver. I ended up writing a small utility called pgdb_recovery to extract feature data from old PGDBs. The script connects to the MDB through ODBC, examines the geodatabase metadata and converts the stored geometry into WKT that can be used by current GIS software. Getting at the geometry required working from the old Esri Shapefile technical description and the GDAL PGeo implementation because PGDBs store geometry in what GDAL describes as “essentially Shapefile geometry fragments.” (github.com)
It works, within limits. Topology, networks, annotation, relationship classes and some other geodatabase constructs don’t make the trip (github.com). That historical data didn’t disappear, but it came with a pretty steep recovery tax paid in old drivers, reverse engineering, unplanned conversion code, and lost semantics.
Personal Geodatabases aren’t unusual in that respect. Every generation of computing leaves things like this behind. By the time shapefiles were becoming a de facto standard, the DBF which it relied on for storing attribute data was already considered obsolete.
Proprietary isn’t really the dividing line, either. The shapefile itself is an interesting counterexample. It has plenty of technical limitations, yet its published specification and enormous implementation base have made it extraordinarily difficult to kill and replace. My recovery code for a newer Esri data format depends in part on documentation Esri published for an older one. The long-term risk isn’t simply proprietary technology. It’s layered dependency on implementations that future users can’t readily understand, reproduce, or escape.
Boring has a pretty good track record
Some parts of the geospatial stack have already been around long enough to be instructive. PostGIS turned 25 this year, with its first version released in May 2001. More important than its age is what sits underneath it. It rides on PostgreSQL and SQL, and encapsulates a collection of spatial concepts shaped in part around OGC Simple Features. PostGIS is now supported by a large mix of open-source and commercial software rather than being tied to a single application. (postgis.net)
OGC specifications provide another example. WMS dates to the beginning of this century and Simple Features to just prior. Newer OGC APIs are now providing more web-native ways to expose geospatial resources, but the underlying idea of publishing well-defined interfaces between producers and consumers has held up quite well. (docs.ogc.org)
Despite their longevity, none of this means that WMS or PostGIS will be the right answer forever, but they have characteristics worth noticing. They are well-documented. In the case of OGC, the documentation is the primary product. Implementation is left to industry. Both have independent implementations and integrations around them and they layer on top of broadly understood computing concepts. Data can be moved into them and, more importantly, moved back out.
That last property doesn’t get enough attention. We can spend a lot of time evaluating how easily a new platform can ingest our data. We should probably spend more time testing how easily we can leave. It was a primary feature and selling point at a SaaS platform I worked for earlier in my career. Prospective customers always, and I mean always, asked about getting their data out. We’d show them our exporter, which was quite robust. We learned that demonstrating it was easy to leave often reduced the chance that they would.
As bad as vendor lock-in may be, obsolescence lock-in can be a much more intractable problem but it can be avoided with good design.
What I would bet on today
So what would I do if I were building geospatial data infrastructure with a 20-year horizon? I’d still use plenty of modern technology. In my experience, all technology goes obsolete, so you should start with the latest you can, within reason. Future-proofing shouldn’t mean freezing things in amber. I would also bake change management into the lifecycle from the very beginning. Change will happen, plan for it.
GeoParquet is a strong candidate for vector data. It is the strongest candidate to replace the shapefile that I have seen in years and offers genuine functional advantages, such as columnar storage, which should get the attention of even the most ardent shapefile fan.
The current GeoParquet specification builds geospatial conventions on top of Apache Parquet, an open columnar format with implementations across multiple languages and analytical systems. (geoparquet.org) GeoTIFF and Cloud Optimized GeoTIFF fill a similar role for much raster data. OGC has been working for years to bring cloud-native formats, APIs and access patterns into the broader standards ecosystem. (ogc.org)
For enterprise data, I’d be comfortable putting PostGIS at the center of a system where its transactional and query capabilities make sense. For analysis, Python, GeoPandas, DuckDB, GDAL and similar tools give us several ways to work with the same underlying information. PostgreSQL and DuckDB WASM make a particularly compelling combination right now.
For large collections of files, object storage is attractive precisely because it separates the objects from most of the applications consuming them. S3 happens to be the dominant model today, and AWS exposes it through documented APIs used for storing and retrieving objects. (docs.aws.amazon.com) I care somewhat less whether the particular object store in 2046 is Amazon S3 than whether I can still get the objects out of whatever replaces it.
I want a dataset to exist independently of the application used to edit it. I want the enterprise database to be replaceable without reconstructing its source from scratch. I want services sitting above the data rather than defining the only way the data can be accessed. And I want documentation outside the heads of the people who built it.
A GeoParquet file full of columns named VAL1, VAL2 and CODE7 isn’t much of an archive. Neither is an exquisitely preserved collection without lineage, coordinate reference information, definitions or enough context to figure out what the numbers meant. Readable data is necessary, but not sufficient.
The institution is part of the stack
This brings me around to HIFLD. The Homeland Infrastructure Foundation-Level Data effort began in 2002 as a multi-organization effort to improve the collection and sharing of infrastructure geospatial information. HIFLD Open eventually made a substantial catalog of those data publicly accessible. That public-facing service was decommissioned in 2025. In March 2026, the FGDC HIFLD Subcommittee itself was retired, although DHS continues to operate a HIFLD program. (napsgfoundation.org)
There are archived copies of HIFLD data. Some have even been converted to Parquet and stored in modern object stores. (source.coop) So a version of the ones and zeroes survives. What didn’t survive in the same form was the public institution around those bits. The governance, coordination, stewardship and access model that made HIFLD Open useful in the first place is gone. Third parties are trying to restore some semblance of it, but they will always lack the imprimatur of the official HIFLD program.
Those efforts will need to find the data where it lives, scrape it and prepare it in order to keep it up to date and useful. That’s a far cry from a data sharing mandate that ensured cooperation between the lead agencies responsible for the many datasets in HIFLD Open.
That’s a different, and harder, kind of dependency. We tend to talk about infrastructure architecture in terms of databases, file formats, APIs, compute and storage. But a data infrastructure also depends on people deciding what gets collected, who maintains it, how often it is updated, who can use it and who pays for all of that. No file format solves those problems.
Which brings me back to the Smithsonian. Its technology stack has presumably been replaced more times than anyone could reasonably count. One can only imagine what servers they were using in 1846.
The institution kept going because the mission was able to survive those replacements. The original legislation didn’t attempt to specify a 180-year implementation. It established what the institution was supposed to accomplish and created a structure intended to keep doing it. (siarchives.si.edu)
That’s probably a better model for long-lived geospatial infrastructure. I’m comfortable making bets on GeoParquet, PostGIS, object storage, OGC APIs and the rest of the tools we have available today, but I wouldn’t bet the mission on any of them. The goal isn’t to choose technology that will still be here in 20 years, but to make choices today that don’t require it to be.
Header image: Gryffindor, Public domain, via Wikimedia Commons
