I've been trying to get a handle/response re FM game plan for a while
too. Its like herding Schrodinger's cats in the dark whilst enjoying the
afterglow of a bottle of port. (from very vague memories.. )
From a "test-driven development" perspective I think that we will need
to invest in a decent set of test cases for each data source. We are
starting to get a useful set of test cases from the "complex-features"
work but they need to be formalised into some of testing framework - at
the moment there is a disconnect between data store tests and geoserver
tests, it would be nice to have the data store test data suite exposable
right through the geoserver functions, and to reuse the bulk of the test
case code between datastore test suites. A common abstract data store
test suite that is extended with initialisation and cleanup routines or
something.
This is relevant now, since coverages may have a very different set of
issues, and merging then refactoring may be more expensive that getting
the test suite sorted out. The tests suite will need to exercise the FM
concepts as far as I can see, since there are a range of critical issues
relating to namespaces and building the internal feature type metadata
that are integral to datastore behaviour.
So, from this pragmatic perspective, is it going to be more efficient to
do the FM merge first, or the coverage?
Secondly, the relationship between coverages and features is quite
strong - there will be cases where data stored in a grid format (like
NETCDF) will contain features (imagine position being just a dependent
variable) - so extracting for example a flight path or ship cruise from
a grid format, as a feature, is a natural thing to do. Likewise,
consider the common case of clicking on a raster derived map and
returning a feature containing all the values in the grid at that point.
Timeseries features are often stored in array coverages.
The merging of coverage concepts _without_ a feature model may result in
a lot of in-built limitations in the architecture that will be difficult
and costly to fix. (The effort required to unpack the erroneous
assumption that the underlying database schema could form the basis of
an interoperable feature type has been enormous - and would have been
much less with the blow-torch of analysis applied earlier.
I for one would like to see a common architecture for FM and coverages
before merging them in. If this architecture identifies that they can be
safely done independently, so well and good, but if not then I think we
need to follow the underlying logic in our planning.
Specific questions I have relating to the project plan for FM:
a) What will be involved in migrating the complex-feature datastores to FM?
b) how will the project be managed? Will there be a single point of
contact to find out what is going on?
c) what can I do to help?
Rob Atkinson
David Blasby wrote:
During the Grid Coverage/Renderer improvements IRC today, we talked
about merging the grid coverage branch onto trunk.
See:
http://docs.codehaus.org/display/GEOTOOLS/2006/05/01/Renderer+IRC
and the " Renderer improvements meeting part 2 (Grid Coverge Merge to
Trunk)" message thread.
I know almost nothing about the FM branch, and the last I heard was
that it was going to be another 6 months before its done. Apparently,
thats incorrect, and its going to be finished up next month (june)
because there's a lot of OWS-4 work thats depending on it.
Perhaps we can get a check-in from the folks who are working on FM, or
who are current stalled (or will soon be stalled) waiting for it - at
the very least get a list of the FM 'stakeholders'.
The main problem is that a Grid Coverage merge could quite possibily
"step on the toes" of the FM folks (see the IRC discussion linked
above). Trying to do the Grid Coverage merge and FM merge at the same
time is almost certainly going to cause problems, so it seems like we
should either:
a) merge current trunk (I believe the main changes are changes to
expression - correct me if I'm wrong) with Grid Coverage Branch +
Renderering Improvments - this would be a 2.3 release.
2.4 would then be 2.3 (ie. coverages) + FM.
OR
b) wait for the FM merge to occur (current trunk + FM = 2.3) then
merge the Grid Coverage stuff in later (2.4 = trunk + FM + Grid).
There's other options, but I thought I would just throw this out so
that the FM folks could start talking. Whats the plan? (In terms of
those working on it, and those "waiting" on it) Is doing a Grid merge
going to cause problems? If so, what do we do?
I dont think there's a pressing need "right now, today" to merge the
grid stuff in (I could be wrong, though), but I know a lot of people
have been waiting for it for a while.
dave
ps. Jody's kindly offered (free-as-in-beer-and-as-in-speech) FM
walk-throughs all this week on IRC.
pps. There is starting to be a fairly large divergence between 2.2.x
and trunk. This is making it difficult to move 2.2.x patches to trunk
- not all bug fixes are finding there way to trunk. This seems to
indicate that we should kick out a 2.3 fairly soon.
ppps. Justin has said that the FM branch is basically a re-write of
the geotools core. It certainly makes sense to call the end result
"geotools 3" to recognize this.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
