| 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:
- aaime +1
- Ian Turton +0
- Justin Deoliveira +0
- jgarnett +1
- Martin Desruisseaux +1 with comments (see below)
- Simone Giannecchini +0
Community support:
- Gabriel Roldán +1
- Jesse Eichar +1
Tasks
| no progress | |
done | |
impeded | |
lack mandate/funds/time | |
volunteer needed |
|---|
Move catalog stuff out of the way to an unsupported/module to prevent confusion
Add org.geotools.data.ServiceInfo and org.geotools.data.ResourceInfo (remove a few stray getTile methods)
Add getInfo methods to WFSDataStore for gabriel to review
Add getInfo methods to ShapefileDataSTore for Jesse to review
Add getInfo method to AbstractGridCoverage2DReader
Add getInfo method to DataStore and stub at the AbstractDataStore, JDBCDataStore, ContentDataStore, Implement for stand alone implementations like ArcSDE- Take the best of geotools or udig getInfo code as the implementation
- Cut over uDig to use this code as the final sanity check
- 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
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.
Some work in the wfs plugin shows another motivation for this proposal: