Geo Data Package

Frictionless Data
4

Wow, there is a lot of backstory here :slight_smile: Thanks so much for providing the links.

A couple of issues I’d like to discuss (ie, where my opinion maybe differs from that expressed in the Geo “profile” issue:

  1. should alternative SRSes/CRSes/projections be supported? My feeling is no. If my assumption that a purpose of Data Package is to ease the flow of information from experts to non-experts, then we just don’t need projections. We can force the data providers to convert to EPSG:4326, which has worked really well for GeoJSON. This simplifies life for the non-expert consumer enormously.

  2. Should raster data be supported? Again, my feeling is no - at least initially. My experience is that raster data is often enormous, and rarely consumed by non-experts other than for fairly trivial cases like a historical map image overlaid on Google Earth, which doesn’t really have a lot of “data” value. I see a lot of complexity in trying to support this use case, and much less value.

  3. Is CSV with two columns for point data ok? dr-shorthair argued pretty persuasively against it (in the Issue thread), but my own experience has been pretty positive. Two-column format makes intuitive sense to non-spatial people (who are aware of latitude and longitude, and that’s the extent of their knowledge). And it’s very easy to convert from that to other formats when required, especially swapping the order. Dealing with a format like “POINT(144.9 -37.8)” or “(144.9,37.8)” or whatever is, in my experience, harder work, and often error-prone due to the coordinate order issue.

So I’m still inclined to have a Spatial Data Package support:

  • GeoJSON for points, lines, polygons (and multi-X)
  • CSV for points, with “lon” and “lat” columns, expressed in decimal degrees.
  • maaaybe CSV with region-bound columns (administrative or statistical regions)
  • nothing else.
1 Like