I think we are making a mistake looking at all this through the lens of being Web developers.
Very few of the people deployed to deal with a disaster - earthquake, oil spill, hurricane are developers. The presence of a well documented API is not particularly helpful to most of the people responding. This is why when the World Bank wanted to provide open data in Haiti they sent terabyte thumb-drives with the raw data available, so it could be opened in multiple applications and repurposed, or if they did not have applications there was an OpenLayers viewer for the data. You could get the data on-line or off-line. If I'm out setting up a boom in Gulf I'm probably not going to have Internet access. I think what we should be debating is what is the right open data strategy for disasters, not who knows ArcGIS server the best. I fully concede Chris will win this contest. If someone builds an AGS map that allows me to download the data from it so I can use it off-line and in other applications - giddy up that is awesome. My concern is the default I see in the field is an AGS "map service" that just gives me a picture. I don't find it terribly surprising that AGS has a query function for their server. Bit embarrassed I missed the link for it, but does not change the concern for the disaster responder trying to get data to do their job. A disaster responder who will likely be without Internet, not know GIS, not know Web development, and could greatly benefit from something better than a paper map or a PNG/PDF. On Wed, Jun 16, 2010 at 1: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 > -- Sean P. Gorman PhD. FortiusOne Inc. 2200 Wilson Blvd. Suite 307 Arlington VA, 22201 Mobile: 202-321-3914 Office: 703-647-2151 @seangorman
_______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
