This is about much more than *public* access to data. It's also about *official* access to data -- an issue that local, state, and federal officials have complained.
You don't really know what you *aren't* seeing on that map, do you? What about contaminated wildlife? What about broken or drifted boom that is no longer providing an adequate defense? I will again reiterate a vital question: Who calls the shots? Is the true spirit of collaboration -- as required by NIMS -- being applied, to address concerns about official and public access to meaningful data? Note that the copyright on the bottom of the map viewer is © 1999 - 2010 BP p.l.c. Does BP have an interest in preventing access to data that might help tally up its liability? Would an independent, trustworthy third party be a better choice to make decisions about data stewardship and access? As for the "well documented API published as a core part of publishing the service" -- well, that was just a good guess, wasn't it? It isn't apparent where those services are located from the page, or from its source without doing a little hacking -- yes, "hacking." I chose the word very carefully. You have to view source a couple of times to figure out how the page is constructed. And no, parish names as an attribute is hardly useful for determining booming strategy. And yes, one of my lessons from Katrina -- when politicians were saying that the time to criticize would come later, while people were dying for the lack of a drink of water -- was that criticism is appropriate whenever it's appropriate. Right now, it's appropriate. Unless you live here, or have seen things firsthand, you may not really appreciate how serious and legitimate the complaints are. On Wed, Jun 16, 2010 at 12:36 PM, <[email protected]> wrote: > > 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
