On Jun 16, 2010, at 1:03 PM, ext Brian Denzer wrote:

> Competent hacking does not an open data policy make.

"Hacking"? This is a well-documented API, with a UI, and usable
functionality (like, you know, maps) for users who are not 
comfortable working with things like shapefiles. 

This is not some 'hacking' of an API. This is a well documented
API published as a core part of publishing the service. 
I strongly disagree that this is any less open than any other 
potential attempt to publish data that I have seen given the 
likely limited number of resources devoted to this aspect
of the effort.

> Access to the data services is, of course, great. This stuff could -- and 
> should -- have been made available weeks ago. 

The domain was registered weeks ago. Do we know that
this site didn't exist then?

> The question to ask is, has BP (and/or TRG) been calling the shots with 
> respect to strategic vision for how the public sees data? Has Unified Command 
> had the appropriate vision -- unadulterated by BP's influence -- to implement 
> an open data strategy that improves public -- and official -- access to 
> critical data? 

Doubtful, but this is not the time to berate people over a
lack of public data; it is a time to request that data
(and stick to that request). After an emergency is over
(or at least at a steady state of badness) is the time to encourage
the appropriate parties to learn from their mistakes. In
the meantime, just encourage and request. Criticism is more
appropriate later.

> Whether deliberate or not, the GulfofMexicoResponseMap.com viewer doesn't 
> look like an intentional open data policy to me. 

... What does it look like? The default on ESRI services 
is closed; having them available at all is a decision someone
had to make.

> Another issue is one of *meaningful* data. For those who are able to hack the 
> site to get data, do you see any useful attributes in those KML and KMZ 
> files? 

The attributes that *exist* on the data files -- as described by
the Metadata -- can be queried (as well as filtered) and 
exported in the KML:

      <description><![CDATA[<html><body><table border="1"><tr><th>Field 
Name</th><th>Field 
Value</th></tr><tr><td>State</td><td>Alabama</td></tr><tr><td>Name</td><td>Baldwin
 County Division 1</td></tr></table></body></html>]]></description>

(Whether the data collected is sufficient is another question,
but not collecting sane data and not publishing data are two
different questions.)

The data is also available via JSON, if you would rather a 
programatic UI.

> Do you know what the Louisiana Protection Strategy is (KMZ)? Can you 
> differentiate between types of defenses (boom, tiger dams, Hesco baskets)? 
> More importantly, can public officials who need to see what the planned 
> strategies are in bayous and beaches differentiate between types of defenses? 

This is all orthogonal to the discussion of whether data *which
exists* is being deliberately (or even unintentionally) hidden. 
Organizations that are used to working with limited geo information
inside a GIS are not the ideal candidate to change these types of 
policy or behavior: Working to publish data so that the community 
can make progress in changing the over.

> The casual appearance of transparency is not the same as deliberate, 
> meaningful transparency. 

Sure. I'm not arguing there, but solving 'deliberate, meaningful
transparency' is a different problem than solving "Get the data out
of the people who have it".

Regards,
-- 
Christopher Schmidt
Nokia


_______________________________________________
Geowanking mailing list
[email protected]
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org

Reply via email to