The current section mentions using NetCDF exclusively for non-geographical array data, but wanted to mention that the base spec (and particularly, with the CF conventions), NetCDF supports a handful of the most common projections and should be considered fair game for interchange of geographic data -- it's widely used in the oceanographic and climatic worlds without issue for interchanging multidimensional sets of geographically referenced data.

Hello,
First thanks for the great write-up and introduction to open data. May I suggest the best and simplest way to share open data (according to my opinion, of course ;-), that is, use single-file SQLite files. Why? The single-file SQLite file works on any machine (e.g. Linux, Mac, Windows, etc.). It includes an SQL schema for "free" and includes by definition "structured" data in tables. For examples, see the open beer database (e.g. beer.db) or open football database (e.g. football.db) or open world database (e.g. world.db). No need to reinvent schemas in JSON and relations and types etc. - use "plain old vanilla" SQL. Just a thought. It's a great and simple alternative for sharing open data online. Cheers. PS: Note: The SQLite code is public domain e.g. no "vendor" lock-in etc..

@danabauer rightfully mentions that fear is a big factor in terms of open data releases. We should address this:

• Are you responsible for misuse of your data?
• How do you make sure people use the authentic version?

Any other fear-related topics?

Certain Esri data types like FileGDB, .lyr, and .zlas are intentionally encrypted and only supported by expensive Esri products, so they aren’t recommended for open data distribution.

.lyr files encode style rules, not data itself, so not sure if it's really relevant here (there isn't a section mentioning open styling alternatives, and presumably this is primarily about data, not data plus presentation).

FileGDB has a freely available API and works easily with GDAL/OGR, so I don't think its accurate to claim they are only supported "by expensive Esri products".

There isn't a section about LAS right now -- I think that'd be a good section to add, and I'd include information about the base LAS spec which is interoperable between many (all?) implementations. Mentioning that .zlas isn't interoperable seems fine, but it should be contextualized to tell someone what they should be doing, and what data formats are best for interchange of point cloud data.

In the section describing geographic information hints it is said that GeoJSON requires WGS84 but it is only the default and it is possible to assign various CRSs.

• http://sunlightfoundation.com/opendataguidelines/

Maybe there's enough for a bunch of links here? Only link the good stuff.

Just a quick observation, there is mention of GeoTIFF but not of NetCDF (which is probably more appropriate for most cases of large data).

I read well-written and upbeat blurb at http://simpleopendata.com/
and have a comment from the down-in-the-weeds perspective of a software developer working with the google map API and open geospatial data.

The current version of simpleopendata neglects to mention the most common open format that government agencies at all levels already use for open geospatial data. All kinds of agencies are already publishing a staggering quantity of open data in this format. Although there might be a better name, I will call this format “ArcGIS services on a public facing server”.

This is an open format for two reasons.

First, anyone can use the ESRI REST API to formulate an http command that can be entered into a browser and download data in various formats. This API is powerful and includes SQL ‘where’ capability.
Here is the documentation for ‘query’ which will let you download data as json or kmz files: http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#/Query_Map_Service_Layer/02r3000000p1000000/
Yes, there is a learning curve.

Second, anyone with GIS client software can likely read this data.

Data in this format is arranged in an inverted tree just like the folders and files on a PC. What corresponds to the ‘root’ folder is called an “endpoint” and is a url. Here is an example of an endpoint from the USGS: http://hdds.usgs.gov/ArcGIS/rest/services
You can drill down on those links and fairly quickly find metadata about each layer of data available via this endpoint. Note - By definition, an ArcGIS endpoint url always ends in “rest/services”.

Recommendation: Please consider adding something like “ArcGIS services on a public facing server” to the list of open data formats.

Three final points.

First, I say public facing server since it is also possible for an agency to have data in the exact same data format on a non-public server. An example is the national park service. They have what they call “atlas” data for many national parks on non-public ArcGIS servers. Why they refuse to disclose geospatial data for picnic areas etc is a mystery to me.

Second, agencies need to publish their ArcGIS endpoints. Most do not. Most agencies also do not place their ArcGIS endpoints on data.gov. And to complicate matters, data.gov does not seem to provide a way to search just for ArcGIS endpoints. Life would be so much easier for open data advocates if there was an easy way to find the 4 or 5 ArcGIS endpoints used by an agency.

Third, with some creative google searching I have complied a list of a bunch of ArcGIS endpoints for federal agencies. That list is at:
http://www.mappingsupport.com/p/gmap4_gis_more_help.html#source_federal

And here is a very small example of maps that can be produced with the existing open federal ArcGIS data (scroll down for the links). To learn how to turn ArcGIS layers on/off, click “About this map” in the upper left corner of any map.
http://www.propertylinemaps.com/p/public_land_map.html

Joseph Elfelt
Redmond, WA