Added by jgarnett, last edited by jgarnett on Feb 27, 2008  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
Contact: jgarnett, Johann Sorel
Tracker: http://jira.codehaus.org/browse/GEOT-1657
Tagline: What is this? No really...

This page represents the current plan; for discussion please check the tracker link above.

Description

We need to access a description of what a spatial resources is. The goal is to make this information available to GeoTools developers:

  • will give widgets swing pending some more information to display and describe;
  • will allow uDig to back port some code. In some cases it will allow uDig to close up some anonymous subclasses: JDBC DataStores often subclassed for connection, WFSDataStore subclassed for capabilities information.

This is NOT catalog

Previous work focused on making the description available for searching, this proposal is about making the description available on the classes directly.

What is the Description

What the description is is well understood; it is: "Dublin Core plus a little bit more" (ie bounds and crs). In GeoTools 2.4.x this ideas is represented as GeoResourceInfo and ServiceInfo.

ServiceInfo shapefile postgis wms wfs description
title    
for display in user interface
keywords
 
description
 
publisher    
 
schema
type of service
source
 
icon
for display in user interface
  shapefile postgis wms wfs additions
access fees         do not care
ResourceInfo shapefile postgis wms wfs notes
title    
for display in user interface
keywords    
 
description
 
name         already part of data access api?
schema
type of data
source
 
icon
for display in user interface
bounds
 
crs         matches bounds crs
  shapefile postgis wms wfs additions
latlonextent    
do we care?

These info classes will be moved into org.geotools.data as part of the proposal (see This is NOT catalog above).

There have been two suggestions on how to extend this core set:

  • add a Map of some kind to the data structure, with static final constants for known keys
  • extend the interface specifically

Status

This proposal has been accepted:

Community support:

Tasks

  no progress done impeded lack mandate/funds/time volunteer needed
  1. Move catalog stuff out of the way to an unsupported/module to prevent confusion
  2. Add org.geotools.data.ServiceInfo and org.geotools.data.ResourceInfo (remove a few stray getTile methods)
  3. Add getInfo methods to WFSDataStore for gabriel to review
  4. Add getInfo methods to ShapefileDataSTore for Jesse to review
  5. Add getInfo method to AbstractGridCoverage2DReader
  6. Add getInfo method to DataStore and stub at the AbstractDataStore, JDBCDataStore, ContentDataStore, Implement for stand alone implementations like ArcSDE
  7. Take the best of geotools or udig getInfo code as the implementation
  8. Cut over uDig to use this code as the final sanity check
  9. Provide an example use in the user guide

API Changes

BEFORE

package org.geotools.catalog;
interface ServiceInfo {
   ...
}
package org.geotools.catalog;
interface GeoResourceInfo {
   ...
}

AFTER

Move ServiceInfo to org.geotools.data.ServiceInfo

package org.geotools.data;
interface ServiceInfo {
   String getTitle();
   String getDescription();
   Icon getIcon();
   Set<String> getKeywords();
   URI getPublisher();
   URI getSchema();
   URI getSource();
}

Move GeoResourceInfo to org.geotools.data.ResourceInfo:

package org.geotools.data;
interface ResourceInfo {
  // Dublin Core
  String getName();
  String getTitle();
  String getDescription();
  Icon getIcon();
  Set<String> getKeywords();
  URI getSchema();

  // And a little bit more
  ReferencedEnvelope getBounds();
  CoordinateReferenceSystem getCRS();
}

ServiceInfo can be accessed from DataStore:

import org.geotools.data.ServiceInfo;
interface DataStore {
    ServiceInfo getInfo();
}

ResourceInfo can be accessed from FeatureSource:

import org.geotools.data.ResourceInfo;
interface FeatureSource {
    ResourceInfo getInfo();
}

ServiceInfo and ResourceInfo can be accessed from AbstractGridCoverageReader2DReader:

import org.geotools.data.ServiceInfo;
import org.geotools.data.ResourceInfo;
interface AbstractGridCoverageReader2DReader{
   ServiceInfo getInfo();
   ResourceInfo getInfo( String subname );
}

ServiceInfo and ResourceInfo can be accessed from WebMapServer:

class WebMapServer extends AbstractOpenWebService {
  ServiceInfo getInfo();
}
class Layer {
  ResourceInfo getInfo();
}

Documentation Changes

list the pages effected by this proposal

Some work in the wfs plugin shows another motivation for this proposal:

interface WFSDataStore extends DataStore {
 getAbstract()
 getAbstract(typeName)
 getKeywords()
 getLatLonBoundingBox(String)
 getTitle()
 getTitle(typeName)
}

Its look fine but I would appreciate the following:

ResourceInfo

  • getBounds() should returns the GeoAPI Envelope interface, not the JTS Envelope class.
  • getCRS() could be renamed getCoordinateReferenceSystem() if we want to be consistent with usage in other classes.
  • getDescription() and getName() should returns InternationalString instead of String.
  • getKeywords() should returns Collection<String> (which may be List or Set at implementor choice) instead of String[] array.

ServiceInfo

  • getAbstract(), getDescription() and getName() should returns InternationalString instead of String.
  • getKeywords() should returns Collection<String> instead of String[] array.

I noticed that the some of the suggested changes are already applied on trunk. In the new version, getBounds() now returns a ReferencedEnvelope which is both a JTS and a GeoAPI envelope. I wonder... would it be reasonable to return only the GeoAPI Envelope interface? Otherwise we are bound to JTS implementation, which is nice but restricted to 2.5D (no time dimension for example). The GeoTools Implementation would returns a ReferencedEnvelope so user can cast to JTS Envelope if they wish and if there is no extra dimension like time (which is likely to be the common case, but not all cases).

Right now the entire data api is making use of ReferencedEnvelope; lets jump off the BoundingBox bridge as part of integrating ISO Geometry everything into GeoTools, even then for concepts like Bounds we are likely stuck with ReferencedEnvelope in order not to favour JTS or ISO Geometry over each other.

Now if you want to look at the osgeo data mailing list we can hunt down this "dublin core and a little bit more" idea and press it into a GeoAPI interface. They had a few extra concerns (like fees) that we dont see as part of the ResourceInfo and ServiceInfo contract.