Bryce L Nordgren wrote:
This is a document precipitated because I don't understand the
inter-feature relationship under the TC/211 model, which is what the
coverage schema in 19123 is based on. In essence, it explores how to model
features with software to provide uniform access to attributes,
associations, and behaviors, regardless of whether the feature type was
constructed dynamically or is implemented directly in Java code. Along the
way, the ComplexFeatures model is evaluated with respect to a specific set
of requirements developed from the TC/211 meta model.
This document ping pongs back and forth between concepts in the ISO 19109
specification and how one might implement these concepts. My goal is to
have a system where coverages are a type of feature, and can therefore be
treated like any other feature. As expressed in the document, a simple
formulation of this problem is: I need a model which implements meta layer
concepts with classes and objects.
The coverage effort pretty much requires an out-of-the-box solution because
deadlines wait for no man. Therefore, you may regard this document as a
pie in the sky target for long term implementation. However, there are two
immediate alternatives for the coverage effort: direct implementation of
the coverage interfaces in Java, or use of the eclipse modeling framework
to support runtime modeling of the coverage framework (and back this model
with Java classes). I have not yet thought of a way to implement coverages
using the ComplexFeatures model due to some issues expressed in the 19109
primer.
Of the two tractable solutions, (EMF and direct implementation), EMF is
only attractive if the feature model types buy into it as well. Let me
make this clear: uniformly using EMF is the only way I can see which
accomplishes a coverage and feature unification. Let me also make clear
that this does not mean dumping ComplexFeatures. EMF would replace those
parts of ComplexFeatures which model features, leaving intact those parts
which implement the fancy Xpath Xquery stuff which I don't know too much
about.
EMF is just full of promise at this point. I have not fully investigated
it to ensure that it won't buckle under when I try to use it for coverages.
However, the laundry list of requirements from TC/211 matches very nicely
with the laundry list of features from EMF. If it does not live up to it's
promise, then coverages will have to be implemented directly as Java
implementations of the GeoAPI interfaces in pending and there will be
_nothing_ to tie features and coverages together.
Please yell at me if I'm missing a solution. I do realize I'm jumping into
an area (features) where I have not invested as much thought as others. On
the other hand, I don't have much more time for planning. Gotta start
doing.
Bryce we have a lot of positive experience with EMF, it should do you
just fine. At its heart EMF has EClass and EObject which are similar in
spirit to the featureType and Feature constructs (aka they both are
forming a dynamic type system).
You will also find that JET (Java Emitter Template) will enable you to
generate out either a) an imlementation that satisfies both EMF and
Feature needs. If you need assistence with JET talk to Justin or Jesse
(an offer to put Justin up when he comes to europe ;-)
Best of luck and I understand about the deadlines. I have carefully
ensured that the FeatureType work will not conlfict with an EMF based
solution - as it is an obvious move from where I sit as well.
If there is any chance that you can put together these abstractions in a
public space - geotools spike or udig? I would be very interested taking
part.
You will also find that the GeoServer team is in the "gotta start" doing
stage, there is probably room for collaboration. Indeed you will find
trunk is being "cleared" explicitly for this work.
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel