Gabriel Rolda'n wrote:
Hi Adrian,
I'll try to answer some of your questions, inline.
Thanks for taking this up Adrian & Gabriel, I am actually writing a bit
of a summary for Rob and you just did most of the work for me.
I am going to reply in line where I have a bit more to say.
On Monday 03 October 2005 16:12, Adrian Custer wrote:
http://docs.codehaus.org/display/GEOTOOLS/FeatureTypes+for+GML
appears to be the oldest. Is this still relevant? Did it result
in what Geotools 2.1/2.2M0 is currently?
Yes, it is finished for 2.1, and is still the best description of what
they did. Chris Holmes had plan to
write up more complete documentation.
Two other docs may or may not be recent:
http://docs.codehaus.org/display/GEOTOOLS/Review+of+FeatureType+Models
This is recent. It was Jody's blackboard in the process of supporting our work
on the complex datastore project
This is the research into existing Feature Type models, and the criteria
I used for evaluation.
Which api is current?
Most critically, there are 3 proposed api:
1) bottom of
http://docs.codehaus.org/display/GEOTOOLS/FeatureType+Survey
2) under first draft of
http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Discussion
(3) in
http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal
The last one, and it is a work in progress. We are experimenting in a
subversion
spike directory (and the the source code + javadoc comments are the one
true source).
I have asked Gabriel (and myself) to complete two sanity checks before
we even present the
proposal:
1. Does it meet Gabriel's (well document) biz case needs
2. Can it be used with JXPath (or anything) to provide XPath based access
The above questions will need to be answered, and we will have to have
at least an outline of a plan before we can even ask people to consider it.
No it is no more true since today. The project is already alive, and the
schedule was updated on the project page:
http://docs.codehaus.org/display/GEOTOOLS/ComplexDataStore+project#ComplexDataStoreproject-Projectdeliverables
Note I have a bit of a bigger rough draft of a "plan" on the Feature
Model Proposal page.
* Is there any proposal for the input/output procedure?
I do not yet understand your working vision is of the processing
of schema/gml files during input or output.
This is a Feature Model, input/output is a concern of the data access
API. GML is specifically the concern of several of the parsing
technologies we have around here. You may want to talk to David Zwiers
and Justin for more details.
* How is GeoAPI participating?
I gather that both the pure Geotools and the pure GeoAPI efforts
were merged. Is this correct?
I am wanting them to be involved, right now both geotools and geoapi is
willing to break backwards compatibility to achive a complete and shared
feature model. They need a proposal by the middle of this month.
* What is the API stability guarantee of Geotools across version
numbers?
Is stability limited to "if we deprecate it in one minor version
(i.e. x in #.x) version, we can remove it the next"?
See above comment, our existing Feature Model is broken enough that we
are willing to break backwards compatibility to work with GeoAPI. This
is an exception, and if GeoAPI bails we will ensure that the working 30%
of the old Feature Model is at least compatible on the method level.
Also if an application access content strictly through Expressions it
will remain unaffected.
* What's the aim of 2.1.x and 2.2.x?
GeoTools 2.1.x is done, its aim was to switch over to the new
CoordinateReferenceSystem interfaces. This took along time and it also
picked up a revised GridCoverageAPI, WFS and WMS support in the interm.
A last ditch attempt was made to help with the Feature Model, and it was
partially successful. In GeoTools 2.0 a FeatureCollection did not have a
FeatureType, and this was fixed as part of 2.1. Also support for facets
was provided, allowing the removal of a lot of one off metadata methods
that had been added over the years.
On paper the goal of GeoTools 2.2 is to switch to the GeoAPI geometry
interfaces. That does not seem to be what people are interested in.
G.t. 2.1.x seems to do 'Simple Features' more or less
completely. Is the idea that it will continue to do this while
2.2 aims to support GML3? That is, is there any idea to complete
and stabilize the simple feature support separate from the
effort to support complex features?
I had thought of it, but the 2.1 API does have methods that indicate
ancestors for example, or parent child feature collection relationships.
The whole does not actually fit together as it was never backed by an
implementation.
* Do all GML files necessarily have a schema?
Yes, even if they make use of the "raw" types present in the GML schema
itself.
Cheers,
Jody
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
