Skip to end of metadata
Go to start of metadata

Contact:

Jody Garnett, 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

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. (tick) Move catalog stuff out of the way to an unsupported/module to prevent confusion
  2. (tick) Add org.geotools.data.ServiceInfo and org.geotools.data.ResourceInfo (remove a few stray getTile methods)
  3. (tick) Add getInfo methods to WFSDataStore for gabriel to review
  4. (tick) Add getInfo methods to ShapefileDataSTore for Jesse to review
  5. (tick) Add getInfo method to AbstractGridCoverage2DReader
  6. (tick) Add getInfo method to DataStore and stub at the AbstractDataStore, JDBCDataStore, ContentDataStore, Implement for stand alone implementations like ArcSDE
  7. (tick) Take the best of geotools or udig getInfo code as the implementation
  8. (tick) Cut over uDig to use this code as the final sanity check
    This was done to communicate WFS GetCapabilities information 
  9. (tick) Provide an example use in the user guide: http://docs.geotools.org/latest/userguide/library/api/datastore.html

API Changes

BEFORE

AFTER

Move ServiceInfo to org.geotools.data.ServiceInfo

Move GeoResourceInfo to org.geotools.data.ResourceInfo:

ServiceInfo can be accessed from DataStore:

ResourceInfo can be accessed from FeatureSource:

ServiceInfo and ResourceInfo can be accessed from AbstractGridCoverageReader2DReader:

ServiceInfo and ResourceInfo can be accessed from WebMapServer:

Documentation Changes

list the pages effected by this proposal

Labels
  • None

4 Comments

Hide/Show Comments

  1. Jan 17, 2008

    Jody Garnett

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

  2. Jan 21, 2008

    Martin Desruisseaux

    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.

  3. Jan 21, 2008

    Martin Desruisseaux

    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).

  4. Jan 21, 2008

    Jody Garnett

    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.