catalogapi
So you want something to manage your datastores (rather then use singletons), and do cross datastore opperations.
Summary:
- Backport the uDig Catalog API ...
Future Work:
- Drop in extensible metadata
- Use Filter 1.1 to bring it in line with the current OGC standards
Of couse only the first one is needed to get things going.
The backport is currently finished. There is a Catalog Tutorial for an in depth description of the API and a tutorial.
UDIG Catalog has a long history:
- started as GeoServer Data API
- and was turned into the GeoTools Repository Interface to allow GeoTools modules (like validation) to work directly against the GeoServer catalog (or any other application)
- attempt was made to port this to the Catalog standard for GeoAPI, a Catalog Interface was created and used to supplement GridCoverageExchange, the standards were not ready yet and org.opengis.catalog was withdrawn
A working Java 5 API that is a joy to use (written by David Zwiers):
This currently supports DataStores, WFS and WMS and GridCoverages in a unified manner. The API can easily be extended to reveal and query internal structure (WMS can display nested layers, a grid coverage can support multiple resolutions).
Docs:
-Catalog (Developers Guide)
-Tracking Changes (Developers
Guide)
We need to include an extention mechanism - see the following picture:
Basically we cannot assume as library designers what manager of class/interface client code wants to interact with the resource through. As an example a raster may be accessed through GeoTools GridCoverage or via JOSSIM. A less exterme example is Shapefile and IndexedShapefile.
The WMS Layer is a GeoResource, that is allowed other layers as children, while already accounted for in the API - the implementation on udig trunk does not make use of this.
Having a working example of this idea with WMSLayer will "head off" people making bad assumptions.
Related Idea: Databases group their contents into schemas - these almost act as a Folder for GeoResources, they are used to group data but are not data in themselves.
There has been one uDig request for "abstract" WMS Layers, I think they also represent the "folder" idea.
An idea on how to do metadata:
In short, udig IGeoResouceInfo and geosever FeatureTypeInfo are both based on a minimal take on dublin core. Above link explains how we can transition between Metadata standards as required, and more importantly flow an open ended set of metadata through our object based system. The technique supports XML or Object based systems, and is way cool.
An idea of how to move "Filter" forward ...
-<http://weblogs.java.net/blog/jive/archive/2005/07/xml_standards_a.html>
Filter is used as the query language for Features and Metadata (The Catalog 2 spec is expressed in terms of Filter 1.1). Right now the udig catalog support basic keyword, location lookup. Our filter implementation is only against Features. Both things are totally fixable.
Status:
The uDig Catalog API uses Eclipse's IProgressMonitor to signal progress of lengthy operations to interested classes or to the user. This very same task is done by org.geotools.util.ProgressListener in GeoTools. However the two interfaces have fundamental differences:
ProgressListener:
public abstract String getDescription();
public abstract void setDescription(final String description);
public abstract void started();
public abstract void progress(final float percent);
public abstract void complete();
public abstract void dispose();
public abstract void warningOccurred(String source, String margin, String warning);
public abstract void exceptionOccurred(final Throwable exception);
IProgressMonitor:
public void beginTask(String name, int totalWork); (totalWork can be -1 = unknown)
public void done();
public boolean isCanceled();
public void setCanceled(boolean value);
public void setTaskName(String name);
public void subTask(String name);
public void worked(int work);
(public void internalWorked(double work);)One difference is that ProgressListener (as well as the Swing ProgressMonitor BTW) work cumulative,
whereas a caller to IProgressMonitor just tells how much work was just done, not how much total work
is already done.
Now, when uDig code gets backported the implementations must wok against ProgressListener instead
of against IProgressMonitor. That is, they themselves have to keep track of the total amount of work
done. On the other side The adapter from ProgressListener to IProgressMonitor has to compute the
progress difference since the last call and send this to IProgressMonitor.
Other differences are:
- ProgressListener can handle warnings and exceptions. Since IProgressMonitor doesn't, the wrapper will have to care about how to signal these warnings to the user.
- IProgressMonitor supports the notion of subtasks, but this can be simulated.
- ProgessListener supports no possibility to explicitely cancel the task.
Following interfaces seem mandatory:
- IGeoResource (becomes GeoResource?)
- IGeoResourceInfo (becomes GeoResourceInfo?)
- IResolve (becomes Resolve?)
Further suggestions to backport:
-
IService
Jody: I think we do need a way to manage services, it may not seem required
for rendering - but you will run into the situtation where two layers
come from the same WMS and can be handled with a single request (when
they are next to each other in zorder). Also you need the IService to
"hold" the WMS without duplication.
-
ICatalog???
Jody: You could consider a catalog api without searching, it is
mainly used to manage conentions and provides an event system. That is
reporting on status changes as services are connected, disconnected,
fixed etc ...
What format should images returned by info objects. The following is the uDig implementation:
public class IServiceInfo {
...
public org.eclipse.jface.resource.ImageDescriptor getIcon();
}Possible Solutions:
Pain for the uDig developers. Doesn't really fit in with the idea of Lazy Loading.
Sounds similar, but Icon does not say anything about whether the implementation has the image ready
or uses lazy loading. Both is possible.
I have an adapter class for this which supports lazy loading. It it attached:
30367/SwingImageDescriptor.java
The idea is: API returns Icon interface, Icon gets wrapped in SWT image descriptor. Only when SWT
image is to be created will the adapter ask the icon to paint itself. Then the icon implementation
fetches the data and paints.
So lazy loading should be fine.
That's what I suggest Matthias\ Basler
Pain for client code. Images must be obtained through a seperate api or just by hacking.
Not an option. This case occurs several times in GeoTools/GeoWidgets (f.e. in map and map layer) and it is impossible to remove any icons from GeoTools just because Eclipse can't use them without adapter.
Client code can do things like:
SWT
IServiceInfo info = ...;
ImageDescriptor id = info.adapt(ImageDescriptor.class):Swing
IServiceInfo info = ...;
Image image = info.adapt(Image.class):The pain here is that different IServiceInfo objects are needed for different platforms (SWT vs Swing).
If it is only that ... that's what inheritance is good for.
I fear however that it tends towards a non-intuitive API. Matthias
Makes only sense if done consequently, because then it does not force the Swing user to have the SWT
library, nor does it force the SWT user to have Sun Java installed.
Pain is, that this means reinventing the wheel (We'd have to write our own Icon and ImageDescriptor
classes and others.) Moreover the API would become strange to the normal user.
❎ Question: How does GeoWidgets handle this one?
ℹ️ Original intention for GeoWidgets was to use AWT
only (i.e. nothing Sun specific) and adapt to SWT, but probably there's no point to circumvent
Swing: A) Most people have it anyway and B) It is widely used in GeoTools, isn't it? So I used the
javax.swing.Icon interface and adapted SWT.
ℹ️ Works for me, that is what the catalog
implemtnation will use. I beleive uDig already has an implementation of ImageDescriptor which
implements javax.swing.Icon.
Further comments appreciated.