David Blasby wrote:
During the Grid Coverage/Renderer improvements IRC today, we talked
about merging the grid coverage branch onto trunk.
Thanks for getting discussion rolling Dave.
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.
This is true - in my understanding the following work is dependent:
- Any GML3 or WFS 1.1 work
- GridCoverage interface from GeoAPI (I thought the coverage branch was
waiting on this? I was under pressure from Bryce to refine the FM
representation of operation as it was needed for the coverage API).
- Documentation - the existing improvements made on the FM branch (in
addition to simply having a consistent representation of feature and
feature type) make geotools much easier to use, learn and document. I
was not interested in writing documentation until the FM work was on track.
- I understand gabriel has some need for the FM branch to complete
- The work from social change is proceeding on the complex feature
branch, but is expected to be ported to trunk after the FM branch passes
some more tests.
That is what I can remember, but from my perspective all geotools RnD is
"stuck" right now, maintenance is continuing on the stable branch of course.
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'.
I would not be against the a Grid Coverage merge taking place soon
(indeed I am really looking forward to it)
However I need to caution my optimism, if it is not too much trouble I
would like to ask for a project plan (wiki page) detailing what is
required to merge in the respective branches. Risk wise the two
branches are not greatly connected, and it would be nice if the coverage
branch could go first.
My rough idea of a project plan for the FM branch would be:
- write test cases for everything up to "SimpleFeature"
- port shapefile and postgis over to use SimpleFeature
- slam the change onto trunk, and explore the rest of the API as aspects
of the orphaned complex-feature branch trickle in out of their long cold
night
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:
I need confirmation from Bryce that the FM is not a requirement for the
coverage branch? Getting the FM branch done so the coverage branch could
continue has been a source of some of the pressure development on the FM
branch has been under.
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.
Sounds good, it would be nice to complete the IP check for a proper 2.3
release (remember we do need to remove deprecated code and kick out a
2.2.x release still).
2.4 would then be 2.3 (ie. coverages) + FM.
This does sound like a decent plan, it simply comes down to risk for me,
and I need to see a project plan (with resourcing if that is not too
much trouble).
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).
This is not my preferred option, but depending on expected timeline we
may be forced to choose it.
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?
It should not cause a great deal of problems, the two are distinct, but
honestly we need more resources to bring the FM branch home, including
project management and testing time.
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.
I have reviewed the scope of work for OWS-4 and find that WCS support is
included, so from my perspective GC and FM may be on the
same footing. I admit there are other options (such as JOSSIM or JDAL)
that were explored during todays meeting. But if possible it would be
nice to continue to focus energies (and shared development) on the
geotools project where we have a history of cooperation.
Cheers,
Jody
ps. Jody's kindly offered (free-as-in-beer-and-as-in-speech) FM
walk-throughs all this week on IRC.
Plug Plug
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.
I am still waiting for either (or both) the geotools and uDig projects
to cough up 3 days to clean up geotools and kick out a release. I know we
have been waiting for our build system but that is starting to come back
into line.
So how about it Dave? When should we release 2.2.x?
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.
I agree, features are the still beating heart of any spatial toolkit, I
am quite impressed with how much has been done with AbstractDataStore to
allow existing implementations a path forward. I should also say that the
With respect to geotools 3.0 - just in terms of breaking backwards
compatibility this would be a kind gesture.
I need to emphasis that this was by design and vote last fall as we
chose a path forward that included GeoAPI (breaking both libraries and
allowing both to move forward). This partnership has been of great
benefit as the expert opinions of geoapi were combined with geotools
ability to actually do something. I would still like a review of the
operation code from those on the GC branch however.
-------------------------------------------------------
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
