Difference between revisions of "Geodata Committee Sixth Meeting"

From OSGeo
Jump to navigation Jump to search
m
 
(6 intermediate revisions by 5 users not shown)
Line 6: Line 6:
 
   Date: 2006-Jun-30 (at least in the Americas and Europe)
 
   Date: 2006-Jun-30 (at least in the Americas and Europe)
 
   Time: ([http://timeanddate.com/worldclock/fixedtime.html?month=6&day=29&year=2006&hour=15&min=0&sec=0&p1=0 fixed time])
 
   Time: ([http://timeanddate.com/worldclock/fixedtime.html?month=6&day=29&year=2006&hour=15&min=0&sec=0&p1=0 fixed time])
 
== People ==
 
* David Bitner
 
* Christopher Schmidt, http://crschmidt.net/
 
* Perry Nacionales
 
* Dave Sampson http://cemml.carleton.ca:8080/OGUG/Members/drsampson/emp/
 
  
 
== Agenda ==
 
== Agenda ==
Line 30: Line 24:
  
 
== Minutes ==
 
== Minutes ==
 +
 +
People: David Bitner, Christopher Schmidt (http://crschmidt.net/), [[User:Pnaciona|Perry Nacionales]], Dave Sampson (http://cemml.carleton.ca:8080/OGUG/Members/drsampson/emp/), Dan Putler, [[User:JoWalsh|zool]], [[User:Neteler|Markus Neteler]], Arnulf Christl
 +
 +
also f0urtyfive + T_Servo from the [http://www.freeearthfoundation.org/ Free Earth Foundation]
 +
 +
 +
http://logs.qgis.org/osgeo/%23osgeo.2006-06-29.log
 +
 
In the meeting, we discussed:
 
In the meeting, we discussed:
  
* Current Status of Telescience hosting. The infrastructure is
+
* Current Status of Telescience hosting. The infrastructure is set up, and users who are looking to contribute to the effort should be able to get accounts -- talk to the System Administration Committee for access.
  set up, and users who are looking to contribute to the effort should
+
* What kind of Data display framework is necesary for the geodata repository to start with? Wiki was discussed: In the backend, structured metadata will be stored, but the wiki-nature will allow for descriptive (non-normative) content to be added, which may later migrate to metadata storage when a more permanent solution arises.
  be able to get accounts -- talk to the System Administration
+
* Data storage should have three 'levels' of data:
  Committee for access.
+
# Raw files. (Shapefiles, images, etc.) These would be designed for use in cases where the default styling is 'not good enough' for users who are attempting to use the data, or cases where data processing is required, or whatever.
* What kind of Data display framework is necesary for the geodata
+
# WMS Server: For cases when you need to have the full WMS support, there should be WMS servers available for datasets where it is applicable. (WFS, and other similar OGC web services, would also fit here.)
  repository to start with? Wiki was discussed: In the backend,
+
# Tiled Server: Datasets where tiling is applicable would have support for making fast, cached requests against tiled-on-disk datasets. nhv and others express an interest in getting a standard for tile caching set up before we do too much work on this aspect of it.
  structured metadata will be stored, but the wiki-nature will allow
 
  for descriptive (non-normative) content to be added, which may later
 
  migrate to metadata storage when a more permanent solution arises.
 
* Data storage should have three 'levels' of data:
 
  * Raw files. (Shapefiles, images, etc.) These would be designed for
 
    use in cases where the default styling is 'not good enough' for
 
    users who are attempting to use the data, or cases where data
 
    processing is required, or whatever.
 
  * WMS Server: For cases when you need to have the full WMS support,
 
    there should be WMS servers available for datasets where it is
 
    applicable. (WFS, and other similar OGC web services, would also
 
    fit here.)
 
  * Tiled Server: Datasets where tiling is applicable would have
 
    support for making fast, cached requests against tiled-on-disk
 
    datasets. nhv and others express an interest in getting a standard
 
    for tile caching set up before we do too much work on this aspect
 
    of it.
 
  
 
On the agenda, but not covered, were some visual suggestions for how
 
On the agenda, but not covered, were some visual suggestions for how
 
data should be exposed from the geodata repository browsing interface:
 
data should be exposed from the geodata repository browsing interface:
  
  * OpenLayers for Raster/Vector data? Easy to set up, might not be
+
* OpenLayers for Raster/Vector data? Easy to set up, might not be full featured enough for some people?
    full featured enough for some people?
+
* Perhaps Ka-Map's tile.php as cached layer to feed both kamap and openlayers?
  * Perhaps Ka-Map's tile.php as cached layer to feed both kamap and
+
* Single-image screenshots for Raster data as overviews
    openlayers?
+
* Vector dataset descriptions: What various attributes are/mean (better metadata)
  * Single-image screenshots for Raster data as overviews
+
* GeoRSS out to get updates, with bounding boxes -- need to get some way to display this data, does anything do GeoRSS rendering with
  * Vector dataset descriptions: What various attributes are/mean
+
bounding boxes right now?
    (better metadata)
 
  * GeoRSS out to get updates, with bounding boxes -- need to get some
 
    way to display this data, does anything do GeoRSS rendering with
 
    bounding boxes right now?
 
  
 
This was tabled until the next meeting.
 
This was tabled until the next meeting.
Line 74: Line 55:
 
Jo offered
 
Jo offered
  
https://geodata.osgeo.org/source/browse/geodata/trunk/metadata/
+
https://geodata.osgeo.org/source/browse/geodata/trunk/metadata/
  
as her work on a MetaData client, to collect data from shapefiles, etc.
+
as her work on a MetaData client, to collect data from shapefiles, etc. and put it into a database.
and put it into a database.
 
  
At approximately this time, we reviewed the content of the meeting, and
+
At approximately this time, we reviewed the content of the meeting, and adjourned for two weeks, same bat time, same bat channel.
adjourned for two weeks, same bat time, same bat channel.
 
  
 
== Next Meeting ==
 
== Next Meeting ==
 +
 +
[[Category:Public Geospatial Data Committee]]

Latest revision as of 08:33, 23 August 2007

Meeting Info

 Chair: Jo Walsh
 Minutes: 
 IRC: #osgeo channel on irc.freenode.org
 Date: 2006-Jun-30 (at least in the Americas and Europe)
 Time: (fixed time)

Agenda

  • What more is needed to get OSGeo's Geodata Repository running at Telascience
    • User accounts to ask SAC for if needed
    • Responsibilities for different data sets
  • What kind of portal is needed - is wiki enough?
  • Some type of browsing interface for the data neccesary:
    • OpenLayers for Raster/Vector data? Easy to set up, might not be full featured enough for some people?
    • Perhaps Ka-Map's tile.php as cached layer to feed both kamap and openlayers?
    • Single-image screenshots for Raster data as overviews
    • Vector dataset descriptions: What various attributes are/mean (better metadata)
    • GeoRSS out to get updates, with bounding boxes -- need to get some way to display this data, does anything do GeoRSS rendering with bounding boxes right now?
  • Free Earth Foundation working on distributed open geodata services targeted at WorldWind - how can we help?
  • Feedback appreciated on metadata client
  • Please feel free to add items here

Minutes

People: David Bitner, Christopher Schmidt (http://crschmidt.net/), Perry Nacionales, Dave Sampson (http://cemml.carleton.ca:8080/OGUG/Members/drsampson/emp/), Dan Putler, zool, Markus Neteler, Arnulf Christl

also f0urtyfive + T_Servo from the Free Earth Foundation


http://logs.qgis.org/osgeo/%23osgeo.2006-06-29.log

In the meeting, we discussed:

  • Current Status of Telescience hosting. The infrastructure is set up, and users who are looking to contribute to the effort should be able to get accounts -- talk to the System Administration Committee for access.
  • What kind of Data display framework is necesary for the geodata repository to start with? Wiki was discussed: In the backend, structured metadata will be stored, but the wiki-nature will allow for descriptive (non-normative) content to be added, which may later migrate to metadata storage when a more permanent solution arises.
  • Data storage should have three 'levels' of data:
  1. Raw files. (Shapefiles, images, etc.) These would be designed for use in cases where the default styling is 'not good enough' for users who are attempting to use the data, or cases where data processing is required, or whatever.
  2. WMS Server: For cases when you need to have the full WMS support, there should be WMS servers available for datasets where it is applicable. (WFS, and other similar OGC web services, would also fit here.)
  3. Tiled Server: Datasets where tiling is applicable would have support for making fast, cached requests against tiled-on-disk datasets. nhv and others express an interest in getting a standard for tile caching set up before we do too much work on this aspect of it.

On the agenda, but not covered, were some visual suggestions for how data should be exposed from the geodata repository browsing interface:

  • OpenLayers for Raster/Vector data? Easy to set up, might not be full featured enough for some people?
  • Perhaps Ka-Map's tile.php as cached layer to feed both kamap and openlayers?
  • Single-image screenshots for Raster data as overviews
  • Vector dataset descriptions: What various attributes are/mean (better metadata)
  • GeoRSS out to get updates, with bounding boxes -- need to get some way to display this data, does anything do GeoRSS rendering with

bounding boxes right now?

This was tabled until the next meeting.

Jo offered

https://geodata.osgeo.org/source/browse/geodata/trunk/metadata/

as her work on a MetaData client, to collect data from shapefiles, etc. and put it into a database.

At approximately this time, we reviewed the content of the meeting, and adjourned for two weeks, same bat time, same bat channel.

Next Meeting