Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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

Catalog API

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

...

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.

...

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:

Issues

IProgressMonitor vs. ProgressListener

...