11

In the past, I have released data as zipped Shapefiles (for the professional GIS crowd) and KML/KMZ (viewable by anyone using Google Earth). Are there other formats that would be especially helpful?

Improve this question
2
  • It might depend on your data. Are you releasing for instance sources (individual points), or water pipes (lines), or lake borders (areas), or water tables (3D volumes), or something else?
    – Nicolas Raoul ♦
    Apr 7, 2015 at 2:17
  • Mostly points and polygons (areas).
    – nicksuch
    Apr 10, 2015 at 1:20

3 Answers 3

Reset to default
10

You can find a list of GIS file formats on Wikipedia. Here is a decent overview of open source GIS servers from the gis.se site, these are the servers people who use open data will most likely be using, so target the formats that those servers use. I would consider some kind of open vector/raster format (I like geoJSON for personal projects because it works well with openlayers, I also know people who use netCDF and JPEG2000). As a side note I've used this tool before to convert between different formats.

Improve this answer
3
  • 4
    +1 for GeoJSON. GML is a more appropriate (open) format than Shapefile in theory, though I'd continue to supply Shapefiles as well as they tend to be more accessible to GIS users.
    – Jack Harrison
    May 13, 2013 at 9:23
  • 4
    I agree with johnthexii about geoJSON. Not only is it easy to parse in virtually any language, it makes it easy to extract simpler components for beginning users to play with and understand.
    – JBecker
    May 13, 2013 at 12:59
  • 2
    +1 to providing shapefiles first, and then others like KML, GeoJSON as requested. The tools for working with shapefiles are still way ahead of those for other formats.
    – James McKinney
    May 22, 2013 at 1:37
6

My experience, making maps from quite a few government datasets:

For point data, CSV is the best, with "lat" and "lon" columns. Very easy to work with in a wide range of tools, including text editors, spreadsheets, etc. The only downside I've come across so far is that GDAL sometimes requires you to make a .vrt companion file. (EDIT: Another downside is there's no universal standard for what to call the lat/lon columns.)

For lines and polygons, in decreasing order of preference:

  1. GeoJSON. Easy to work with, and the ability to edit in a text editor is a real bonus, if you need to do search/replace, remove a couple of weird objects or copy and paste from one file to another. Another benefit is that non-GIS developers can make sense of it. Only issues I've run into is when someone provides data as say MultiPoint instead of Point.
  2. Shapefile. Very widely supported, but with two inconvenient points. First, it's a collection of files, so you have to pass around a .zip and extract it. Second, field names are limited to 10 characters. They're hard to edit for your average non-GIS person.
  3. KML/KMZ. These often have a lot of irrelevant cruft (styling, icons, etc), and attributes are often (always?) encoded as mini HTML tables, which are really hard to work with. At least you can edit them easily with Google tools.

Honestly, though, the best answer is probably "all of them". Do everyone a favour and release the data in CSV (if point), GeoJSON, zipped Shapefile and KMZ.

Improve this answer
6
  • I suspect that any useful geographic dataset will make your text editor cry uncle before it's finished loading.
    – Ian Turton
    Apr 7, 2015 at 14:54
  • Not true at all. Just loaded a 50MB, 373,000 row geo CSV file in Sublime. It loaded in about a second. Replace a string occurring 21,000 times? Less than a second.
    – Steve Bennett
    Apr 8, 2015 at 1:44
  • try several million for serious data
    – Ian Turton
    Apr 8, 2015 at 5:30
  • Hmm. I don't think the number of points makes one dataset more "serious" than another, but, sure, your point is made.
    – Steve Bennett
    Apr 8, 2015 at 8:58
  • 1
    love this idea. i convert everything to as many formats as possible...save kml. i hate proprietary ;)
    – albert
    Apr 9, 2015 at 4:42
3

Geospatial Data Standardization No more KML, KMZ, SHP files!

I will make the somewhat bold and possibly controversial statement that geospatial data should always be available in two single standardized, non-proprietary and text-based formats depending upon the nature of the data:

  • Polygonal Geospatial Data - GeoJSON (an extension of vanilla JSON, which stands for JavaScript Object Notation) should be the default standard for all geospatial data protocol, and KML (keyhole-markup language), SHP (shapefile) and KMZ (Google Earth) should be abandoned in any new projects in favor of GeoJSON. This is because (a) GeoJSON is universally understood, and based upon web standards, not software standards and (b) GeoJSON is a flat plain-text file that is lightweight and doesn't require multiple files to be understood by a machine (i.e., Shapefiles usually need to be archived as a .zip to render properly). It is extensible, convertible and universally compatible. It also plays well with JavaScript.
  • Coordinate Point Geospatial Data - While GeoJSON can also theoretically store point data, for a simple list of points on a map, it would create needless complexity. A simple CSV (comma-separated value) file with two separate columns at the beginning of each array or row for the values 'lat' and 'long' (latitude and longitude) should always be the de facto storage format for point data. No .xls, .xlsx or .tsv files.

So, GeoJSON for shapes, CSV for points.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.