Skip to content
This repository has been archived by the owner on Apr 20, 2020. It is now read-only.

tutorial on publishing geodata as a data package #52

Open
danfowler opened this issue Aug 10, 2016 · 8 comments
Open

tutorial on publishing geodata as a data package #52

danfowler opened this issue Aug 10, 2016 · 8 comments

Comments

@danfowler
Copy link
Contributor

From @rgrp on November 24, 2013 17:40

Basics are easy here.

Real question is whether there is a recommendation on data types. Main options afaict:

  • geojson (+ topojson)
  • shapefiles
  • csv (with lon / lat columns or similar ...)
  • spatialite / sqlite style

Copied from original issue: frictionlessdata/frictionlessdata.io#90

@danfowler
Copy link
Contributor Author

From @rgrp on June 8, 2014 14:11

@peterdesmet have a question here that i'd welcome your input on. In preparing the tutorial should we say:

  • You can publish any type of geodata as a data package (which is true in that you can have any type of data in a data package)
  • Focus on defining / pushing a "Geo" Data Package where the data is only of one (or a few) types e.g. geojson (and possibly geocsv)

@danfowler
Copy link
Contributor Author

From @peterdesmet on June 10, 2014 15:12

I would choose the latter (few types) for several reasons:

  • The geo data package should be similar to the tabular data format, i.e. a specific kind of data package, which focuses on one (or more) specific types or use cases.
  • The advantage of focusing on one type is that it keeps things simple (including documentation), which is a strong suit of data packages (e.g. the simple data package). There are numerous other ways to publish geospatial data (e.g. INSPIRE metadata), but these are often complex and a barrier to publishing.
  • Data packages should focus on open formats, as that is what we want to see more of. Shapefiles (and maybe KML?) are not open.
  • For anyone who wants to publish in other formats, there is still the standard data package which allows to do so.

So I would focus on geojson and topojson, as these are well-defined, open and geospatial. I'm not familiar with geocsv, but if these can be covered as tabular data packages, I would just reference that specification. Regarding sqlite: not familiar either, but maybe a specific data package for these (not necessarily geo) could be useful.

My 2 cents.

@danfowler
Copy link
Contributor Author

From @rgrp on August 14, 2014 8:56

@peterdesmet I agree about few types (and only one perhaps). I've even start some work in this direction (focus on geojson maybe in first instance). Would welcome your help!

@danfowler
Copy link
Contributor Author

From @peterdesmet on August 14, 2014 15:49

@rgrp where does this documentation/tutorial live (here?). What should the documentation/tutorial include (do you have an existing example)?

@danfowler
Copy link
Contributor Author

From @rgrp on August 14, 2014 15:56

@peterdesmet that's where it lives http://data.okfn.org/doc/publish-geo

Re what it could look like we could follow http://data.okfn.org/publish (i don't think it matters than we repeat stuff).

@danfowler
Copy link
Contributor Author

From @rgrp on October 16, 2014 10:3

@peterdesmet any thoughts on what we could / should improve here: http://data.okfn.org/doc/publish-geo ?

@danfowler
Copy link
Contributor Author

From @peterdesmet on November 11, 2014 19:12

@rgrp Sorry, caught up in a lot of work the last few months. Will take some time until I can get back to this.

@danfowler
Copy link
Contributor Author

From @rgrp on February 16, 2015 8:44

@peterdesmet any more time?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
No open projects
Development

No branches or pull requests

3 participants