You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Question for @tmcw, @jfirebaugh following #188/#189
Is there a reason this index doesn't just use GeoJSON for everything?
GeoJSON has geometry and custom properties built into it, can be previewed directly in GitHub and constructed trivially with geojson.io, and has a wealth of tools that work with it, and can be validated with JSON schema.
All of this wasn't necessarily true a few years ago when this project started - but it seems like an obvious choice today.
We currently have a bunch of .json files containing geojson-like polygons (but not really, because holes) that we concatenate together with a python script. This is weird and I'd like to know if there's a good reason for it before I go changing things around.
My somewhat side goal for all the projects that I currently touch is to reduce as much development friction as possible, automate repetitive tasks, and rely on bots and CI tools to make less work for me where it makes sense to do so.
This issue is really a more pointed restatement of #168, so I'm going to close that one.
The text was updated successfully, but these errors were encountered:
This repo doesn't use GeoJSON because when I made it I didn't think we needed to store geometries. Clearly that assumption was wrong. I see no reason not to switch to GeoJSON as the "sources".
One small downside to using GeoJSON (or to treating geometry as the primary data rather than the metadata about that geometry) is that when there are multiple sources that cover the same area (e.g. lots of the national US data sources) we're going to have duplicate geometries in every GeoJSON file. We already have this, but I was hoping we could optimize that out.
Question for @tmcw, @jfirebaugh following #188/#189
Is there a reason this index doesn't just use GeoJSON for everything?
GeoJSON has geometry and custom properties built into it, can be previewed directly in GitHub and constructed trivially with geojson.io, and has a wealth of tools that work with it, and can be validated with JSON schema.
All of this wasn't necessarily true a few years ago when this project started - but it seems like an obvious choice today.
We currently have a bunch of .json files containing geojson-like polygons (but not really, because holes) that we concatenate together with a python script. This is weird and I'd like to know if there's a good reason for it before I go changing things around.
My somewhat side goal for all the projects that I currently touch is to reduce as much development friction as possible, automate repetitive tasks, and rely on bots and CI tools to make less work for me where it makes sense to do so.
This issue is really a more pointed restatement of #168, so I'm going to close that one.
The text was updated successfully, but these errors were encountered: