Jody wrote:
> Given the fact that I am trying to move something similar
to FeatureStoreInfo
> back into the geotools code base I would not mind a review,
to see if it can
> cover your required functionality.
>
> Please have a look at the diagram on this page:
> -<http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI>
>
> And let me know if IGeoResourceInfo is suitable for the
kinds of issues you
> need to address?Hi Paolo and Jody, hi others,
I am Matthias Basler and I currently try to improve some
easier components of
GeoTools towards the functionality that uDig offers in order
to have a good
basis for my GeoWidgets project.
I wrote a page about the proposed improvements on the
MapLayer, layer data
access and rendering improvements on
http://docs.codehaus.org/display/GEOTOOLS/Map%2C+Layer%2C+Data
+and+Rendering+Architecture
The MapLayer architecture was the easiest and is already
working (that's not
saying that it is final, suggestions are welcome). For the
data access part
(i.e. IGeoResource) I wasn't sure, so I left this open,
hoping to get comments
and suggesstions. Revising the rendering framework has not
yet really started.Paolo, we are grateful for any comments from the GeoServer
side. I want this new
MapLayer framework to be usable by as many projects as
possible, so if there are
requirements that are not yet fulfilled by the classes in the
proposed UML
diagram on
http://docs.codehaus.org/pages/viewpage.action?pageId=29757 or the
CatalogAPI, just comment on that directly on the wiki pages
or via the GeoTools
mailing list.
I looked at your wiki (correct link seems to be
http://docs.codehaus.org/display/GEOTOOLS/Map%2C+Layer%2C+Data+and+Rendering
+Architecture
) and I should say it's a very good job!!!
I really liked (and I share) your concerns about keeping code
as most "ignorant" as possible and about minimizing dependencies.
Having said that, I'm not at all considering the "Map side",
so I can only speak about data and metadata.
About metadata we had the need to be able to describe the structure
of a FeatureType before it was even stored somewhere. We had a
description of our data model and we needed something to manage it,
that also let us create a FeatureType on the fly to use it for
a DataStore.createSchema().
Our data model was hierarchical, that is we had an "Entity" FeatureType
from which all others inherited. We had a "Street" FeatureType from
which both "LocalStreet" and "Highway" inherited (we didn't actually
have them, but it's for giving you the picture).
We also have relationships between FeatureTypes, so that an "Arc"
points to its starting and ending "Node"s, and also inclusion relationships,
that are similar to the "implements" construct of Java.
So we built a MetaEngine capable of resolving all this inheritances
and relationships so that each FeatureType will have all the metadata
defined for itself and also the metadata defined for its ancestors.
Metadata can be about structure (what AttributeTypes it has, etc.),
about security (which role are allowed access, etc.) about validation
(which validation must be applied, etc.). Each piece of metadata
is contained in a POJO, that is the MetaEngine doesn't know the
type of information it contains, it works upon Java Objects (see also
http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastructure
I'm sorry for it not beeing up to date).
About data access I can't see no reason to use different interfaces.
GeoTools already has DataStores and we think they're enough.
We're also envisioning services (like Locator, geoCoder, etc.) presenting
themselves like DataStores, the metaphore is working and we like it,
so we believe data access should only pass through DataStores,
together with metadata.
Anyway what we really like to do is working against a repository
of FeatureTypes/FeatureSources as a whole and irrespective of their
actual parent DataStore. It would also be great to support "mirrored"
sources, where the repository will access the "best" available source
as you described in your wiki.
We can discuss this field either via this list, but I could
imagine having an
breakout IRC session (on the Geotoool channel?) on this
topic, if you like.
I live in Germany and could manage almost any time from 8:00
to 20:00 UTC.
I confess I never used IRC, so I don't know...
We may try it, but there'll only be the two of us...
Maybe cholmes (he's more or less on our time zone) can be interested,
and you should also talk with the two Italians working on the GeoServer WCS
(they're likely to have Map related interests in common with you).
Please note that I am not very familiar with GeoServer's API
yet, so you might
introduce your project shortly to me and tell me why you are
interested in what
new APIs in GeoTools.
(I loosely follow the "GeoServer and GeoTools versions" thread.)Matthias Basler
c9bama@anonymised.com
Bye
Paolo Rizzi