Summary: Jody figures out that GridCoverageExchange is up for grabs a=
trys to present a solution that works for raster and vector data prod=
> D=FCnnebeil Gerhard a =E9crit :
>> Other points we like to see is the storages of coverages in a data=
>> and a more elegant way to tell geoserver about them. I dream of si=
>> inserting a new coverage in the database and the next time I query=
>> geoserver it will know about my updates without the need of a rest=
>> or the call of some URLs. (Ok, ok, I'm aware of the impact on=20
>> performance with that. But maybe we can find a reasonable compromi=
> I agree with this goal; but it may be a long-term effort (i.e. clos=
> one year).
> In our laboratory, we use a PostgreSQL database as an index. Images=
> stored as plain PNG, TIFF or whatever file, and the PostgreSQL data=
> contains their envelope, time range, CRS, etc. A search for some ki=
> image covering some geographic area in PostgreSQL is fast, then we =
> the image by the usual way (ImageIO or JAI...)
> This code is not yet on Geotools, because 1) I don't know yet if it=
> too specific and 2) we need to design a better [Grid]CoverageExchan=
> interface first, which is the goal of the upcomming IRC. The above-=
> PostgreSQL database is mostly a workaround for the not-yet-working=
> [Grid]CoverageExchange interface.
>> What I learned from your answers is that our goals are widely=20
>> identical to ours and that it makes sense to discuss details. I al=
>> learned that most (nearly all) things we like to see are already i=
>> the discussion.
> I believe too that most of our laboratory goals and Bryce's (for=
> example) goals are very similar.
>> What we would like to add is some kind of dictionary to the new=
>> Gridcoverage so that geotools (by the means of the proper plugin) =
>> find out about available coverages.
> Yes, Jody had this idea too. The initial attempt was to provide thi=
> functionality through a catalog API. So a GridCoverageExchange inte=
> may not be the only work needed. Some work for a org.opengis.catalo=
> may be needed too.
Oh dear - that is on the agenda isn't it. I am really sorry that my=
time is constrained at the moment.
I can sum up my plans pretty easily.
1. Port the uDig Catalog API ...
2. drop in extensible metadata
3. Use Filter 1.1 to bring it in line with the current standards
Of couse only the first one is needed.
- started as GeoServer Data API
- and was turned into the GeoTools Registry interface to allow=20
separation of GeoTools modules (like validation) from the actuall=
catalog of known data maintained by GeoServer (or any other applicati=
- attempt was made to port this to the Catalog standard for GeoAPI, t=
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 =
unified manner. The API can easily be extended to reveal the details =
An idea on how to do metadata:
In short, udig catalog and geosever FeatureTypeInfo are both based on=
minimal take on dublin core. Above link explains how we can transitio=
between Metadata standards as required, and more importantly flow an=
open ended set of metadata through our object based system. The=20
technique supports XML or Object based systems, and is way cool.
An idea of how to move "Filter" forward ...
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 ud=
catalog support basic keyword, location lookup. Our filter=20
implementation is only against Features. Both things are totally fixa=