Monday, July 26, 2010

Data.gov Adds Geoviewer

Today, Data.gov added a new capability to its growing arsenal of tools that allow for using the data the website makes accessible. The so-called Data.gov GEO Viewer has some interesting capabilities:
  • Data loaded into viewer in Real-time through web URLs – the viewer downloads data directly from the authoritative source. An ArcGIS Server Geoprocessing service uncompresses data if needed (.zip, .gz, .tar), transforms data to JSON, and streams this back to the flex viewer.
  • The GEO Viewer loads data in Web Mercator (if data or service supports it).Otherwise the GEO Viewer changes its basemap projection to Geographic Coordinate System and loads the data.
  • The viewer supports the following data types:
    • Map Services: OGC WMS, ArcGIS
    • Feeds: GeoRSS
    • Files: KML/KMZ, Shapefile
  • The GEO Viewer allows for mashing up multiple datasets, map services, and feeds in one view. It supports basic navigation using the keyboard (without the need to use the "shift+alt+F7+drag the mouse+release alt and mouse button at the same time"-like features...).
  • Set a basic color for the added data layer, set transparency for the layers, and use a swipe/see-through feature.
  • Basic identify operation on the added data.
  • Switching the basemap.
There are some limitations with this viewer, most of which are due to the fact that it downloads data from the source every time someone wants to see it:
  • File size limit of 10MB – Shapefiles and KML files can have large compression ratios. While the registered file in Data.gov may be an under 10MB KMZ file, this can easily expand into a 100MB KML that then is streamed as JSON features to the client. This simply takes time.
  • The information about the files is not enough to make an upfront assessment of whether the file is viewable or not. Almost every file in Data.gov is a .zip file. The GEO Viewer has to determine if it's dealing with an Esri Shapefile, OGC KML, Arc/Info Export (e00, remember these?), Microsoft Excel, CSV, or whatever format(s) until after it downloads the file. The metadata in neither raw data catalog nor geodata catalog includes this information. A result is that sometimes users will only be notified that the file type is not supported until after the viewer is launched.
  • Registration of content is not readily usable by an application (James Fee found one of these...). There are several registrations of content that link to web pages or web applications, rather than the actual data. In this case, the content is however also available as an ArcGIS Server Map Service (although that's not in the registration in Data.gov).
 Are we there yet?

No. This GEO Viewer is not the end point. It's another step towards allowing users to interact and understand the data discoverable through Data.gov. The viewer illustrates the need to include more map services in Data.gov. Even registering map services alone may not be enough. In this world of service architectures, platforms, and such, we become more and more dependent on each other. Offering a service means signing up to a responsibility to keep this service running and available for an extended period of time.


Oh! And the proof of the pudding is in the eating! Here some samples:
  1. My most favorite dataset on Data.gov: the locations and characteristices of world copper smelters.
  2. For the patient folks: Active Mines and Mineral Plants in the US
  3. My next house location: Geophysical Surveys of Bear Lake, Utah-Idaho
  4. The dataset James was looking for: USGS Oil and Gas Assessment Database

Give it a whirl and provide your feedback to Data.gov.

2 comments:

  1. Thanks for the links and write up. I think the concept of this application is very good - a data window into the datasets/services contributed from interested parties. What I have a real problem with is the UI and user interaction for this application. I am by no means a casual user and I struggled with just looking at the information details window when a location was clicked after expanding the view details widget... it was partially obscured by the details widget. This is not acceptable behavior for app with this level of potential exposure. It is also very slow - you address this in the post but what about smart caching, where you take the information that people are using often and cache copies of that with periodic queries for updates, that way the users are not cooling their heels on popular datasets. It would also give you insight into the interests of the users coming to the site...
    I don't mean to be critical but I am tired of developers not considering good ui design over what I call the 'cool' factor. As a map geek, I can appreciate the cool fly out effects and other behaviors, once or twice, but in the end these are novelties. End users will eventually be annoyed that they are waiting for these effects that happen again and again.
    I am sorry for sounding harsh - I do appreciate your posts and the blog. Remember, good healthy opinionated debates should never be feared!
    -OC

    ReplyDelete
  2. @webbotter - thanks for this constructive feedback. I will forward this to the project team. The viewer is backed by a geoprocessing service that downloads the data and transforms it to JSON for the viewer. We have started to enhance this with the capability to cache datasets. This hasn't made it into the public prototype yet.

    ReplyDelete