Geodata Repository

From OSGeo
Jump to navigation Jump to search

The notes on the Talk:Geodata_Repository Talk page for this page describe the background to this effort

A full list of suggestions for public domain data sets that are nice-to-haves is maintained at Geodata Discovery Working Group.

Getting involved

The geodata repository has a dedicated blade server at telascience - cf SAC Service Status. Right now this is geodata.telascience.org ; we need to get an osgeo.org domain pointed to it. The plan is to have something very much up, running and demoable by FOSS4G.

How you can help

  • Offer feedback on the Geodata Metadata Requirements - if you have a dataset you would like to contribute, does this model express it adequately?
  • Write or contribute an example Simple Catalog Interface
  • If you would like to install software and/or data on the repository machine, please talk to the good people at SAC or visit #osgeo and #telascience on irc.freenode.net to find out how to get an account and get started

Who is involved now

  • Jo Walsh is working on the backend data store and machine level metadata interfaces (also presenting this material at FOSS4G 2006)
  • Chris Schmidt is helping with an OpenLayers-based browsing interface
  • Schuyler Erle is helping with web service / application glue
  • Sean Gillies' OWSLib is, half-beknownst to him, a big part of all these applications - see the OWSLib API user stories at http://trac.gispython.org/projects/PCL/wiki/OwsCapabilitiesUserStory
  • Markus Neteler is contributing data processing code and resources as part of the GRASS data packaging effort
  • Norm Vine is providing a point of contact for administering the system and general reality-checking to all involved.

Interface Design

In order to be useful to people, a geodata repository needs a way for users to become quickly + easily informed as to what kind of data they're getting: metadata about the data, and the quality/quantity of data involved.

For Raster images, one way to do this is to include an extent-wide image of the data -- http://openlayers.org/gallery/ has screenshots which show some of what I mean where, although more directed towards applications. By having a whole-extent screenshot overview, users can quickly and easily see what they're getting. Additionally, assuming this data is to be made available as WMS, setting up an OpenLayers instance to allow users to browse the rasters and see at a more detailed level would be beneficial.

Vector data/attribute data would also need to be described, in text or some other way. http://freemap.in/world/ is an example of a browsable map which displays attribute data -- clicking on a country fills the sidebar with data. This interface was set up in about 20 minutes, and given decent map files, this kind of set up could be largely automated, allowing users to (again) get an overview of the data they're looking at before they download it or set it up on their own servers.

Data sources

Sources of public geodata for initial setup in a repository.


Data at SDSU

  • plus we have a PostGIS, GeoServer and MapServer installation running at
zuluvis.sdsu.edu  says NHV with VMap0 in it?


VMap0

  • PostGIS storage for vector data.
  • Geoserver as a WFS
  • Ongoing generation of per-country and per-region shapefiles; distribution via HTTP and via geotorrents.org

Status

Blue Marble NG

  • Mapserver as WMS

Status

SRTM

Status

Landsat-7

Status

  • Waiting for disk space to finish unpacking the raw data on zuluviz.sdsu.edu
  • Interim plan is to write a simple WMS wrapper script that generates a GDAL VRT to assemble composites on the fly

Metadata

See Also