TLDR; I am not suggesting the the burden of reprojection be shifted to the causal consumer. I am suggesting that it be shifted to the person writing the tool that loads spatial data packages.

My apologies for failing to communicate clearly. Hopefully in addressing your points my perspective will become a little more clear.

stevage: stevage: Someone publishing data cares about reuse and interoperability, and decides to invest more time and effort than simply dumping some files on the web, so uses some existing tools (or builds their own) to bundle their data into well described Data Packages, uploads them somewhere.

It is reasonable to expect some additional investment from data providers, but in my experience every additional hurdle that you put between a data provider and them releasing their data decreases the chance that they will share it at all and increases the chance that if they do they will dump completely uncurated and undocumented data on the web. I think it’s fair to say that this perspective is basically consensus among folks involved in getting scientists to share data in useful ways. E.g., it serves at the core of Dryad’s philosophy on this. One of the key things I like about the frictionless data approach is that it is also relatively low friction on the providers part relative to more complex metadata standards.

stevage: stevage: A casual user who has never heard of Data Package comes across one of these things, and finds the metadata format fairly simple to understand, or can simply access the files inside as expected. By virtue of it being a Spatial Data Package, the files inside are in a very reusable format, life is easy.

My impression is that this is not the primary use case based on the emphasis on developing tooling across languages and the use of JSON (instead of something more human readable and writeable, e.g., YAML). That said, I’m currently also a bit confused by the user example of someone who knows nothing about projecting but will be able to actively use spatial data. Making simple maps is great (though it’s not ideal to do even this in EPSG:4326 in most cases), but presumably most folks will want to analyze the data in ways that will require more useful projects. It seems to me that part of frictionless here is “the data easily ends up in the projection I need”.

stevage: stevage: Or, a user of some tool that is hooked into the Data Package ecosystem makes the data available to them, and they’re barely aware that it was ever a Data Package to begin with. Perhaps they use R, or some downstream website.

My impression is that this is the primary use case with packages being developed to allow loading the packages into the appropriate formats in different languages. Hence the effort to develop libraries for lots of languages: http://frictionlessdata.io/software/

stevage: stevage: In these cases, I don’t see the benefit of shifting the burden of reprojection etc from the publisher (1) to the casual consumer (2).

I am not suggesting the the burden of reprojection be shifted to the causal consumer. I am suggesting that it be shifted to the person writing the tool that loads spatial data packages.

stevage: stevage: Can you explain why projections are “fundamental to spatial data”? I’d also be curious what you think about GeoJSON’s total lack of support for anything other than EPSG:4326 - do you see this as seriously compromising GeoJSON’s usefulness?

See my point above about friction for data providers This is isn’t as straightforward with rasters The question about GeoJSON is a good one. It does in the sense that it doesn’t support raster data. It’s great for default map making on the web, but I see the ease of GeoJSON as being for the tools as much as for the user.

More generally I like thinking about GeoJSON here in the sense of “what will this standard bring to the table that GeoJSON doesn’t already provide.” My impression of the really simple version being discussed at the moment is that it’s basically a little bit of metadata on top of GeoJSON, except storing the data in csv. If that’s the case I guess I’m confused as to why the best approach isn’t just to use GeoJSON (a well established standard) and the package could be a few lines of metadata and a link to a GeoJSON file. That would be valuable, it just wouldn’t be useful for us and so we’d just work with what we’ve already developed for the more general geospatial use case.