View profile

SpatialTau - Archiving Cartography is Impossible

Thank you so much for reading my newsletter. If you enjoyed reading it, please forward it on to your friends and colleagues. Feedback is important and all you must do is reply to this message to let me know what you think. Remember, if you are tired of seeing my face every week, scroll to the bottom of this message and click unsubscribe. Don’t forget to follow me on Twitter, my blog or my podcast.

Taking some time off to choose your next adventure does give you time to think about things. Some people might take this time to catch up on reading or pick that hobby you dropped back up, but I cannot. I just need to work with geospatial data and the project I’m working on right now is cleaning up my GIS data repository. As I said in a blog post Monday I am moving a lot of spatial data off of Dropbox and into a better solution. I’ve simplified by dropping Dropbox (unintentional joke) and using iCloud for my cloud data store. There isn’t much to that of course, cloud storage is really a commodity at this point. I’m also migrating older data to Amazon S3 Glacier which seems like a great choice for long term storage.
The one thing that really worries me is cartography. I think we can probably agree on spatial data formats for archival, there are multiple choices for different data types. But cartography is one that baffles me. I have data in MXDs, QGIS projects and even Adobe Illustrator. I have always been good at using PDF as a storage medium because I think it does a great job of snapshotting the visualization as it was released. But the raw cartography is in some files that could be bad choices for long term archival.
I tilted at this windmill way back in 2009:
There are tons of ways to store spatial data, but sharing cartography is much harder.
The whole blog post is very much a period piece with references to SLD, CSS and uDig, but maybe there is something to this. I liked the idea of WKT/WKB as a good archival format so in concert with this, maybe SLD is a great choice. Of course, if I lamented that SLD was not well supported in 2009, you can pretty much be assured that it is even worse in 2020 not to mention that SLD is as ugly as it gets. I felt like OGC would be a great place to get a standard for cartography, but I don’t think there is much there because OGC is more focused on data sharing rather than data visualization
This map is almost 130 years old.  What will happen to our data in 100+ years?
This map is almost 130 years old. What will happen to our data in 100+ years?
A friend mentioned vector tiles as a archival format but I’m not sure that is in any way a good idea given that you are converting the data into yet another format, only to protect the cartography, PDF does this and is much more supported than the other formats. I’ve thought about documentation of the layers, describe how they are visualized with line types and the such, we used to do this years ago inside of ARC/INFO so why not do it here. But that is very verbose and probably not very helpful.
My idea in 2009 was a CSS sidecar full of the cartography, much like an Esri LYR file works. But CSS is probably the worst answer to this question as it really is just a pain to work with and isn’t supported by most tools. Some people are telling me to just convert to QGIS:
I think this is probably not a bad idea, but I worry that QGIS files (formats change, not the program) will be dead in 10 years given that technology changes so much. But these are well documented, even if they are XML. While I do hate XML, I could save off this documentation with the files so that future James could at worst case, look at the structure of the files and convert them into whatever styling needs he had.
This solves my micro use case and doesn’t address that any true long term data storage model needs to be supported by Esri. Otherwise it just because a silo on it’s own. Open silos are still silos.
Google Knew We Didn’t Want to Kill Spreadsheets. We Wanted A Billion Rows
Let's rethink what datasets can do
Did you enjoy this issue? Yes No
James Fee
James Fee @jamesmfee

Spatial, workflows and technology

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
8220 E Sage Dr, Scottsdale, AZ 85250