Martin Desruisseaux wrote: > Yes, rewriting GeoTools from scratch would be a mistake. What I'm > suggesting is more a cleaning. The metadata and referencing modules > would be close to identical, except for: > > * More uniform naming policy (the metadata renaming proposal would be > applied only on GeoTools 3, not GeoTools 2. An Ant script can easily > performs the renaming for peoples migrating from GeoTools 2 to 3). Check; can you write these down as a "GeoTools Planning email"; and then we should collect them onto a wiki page for later. > * More aggressive removal of deprecated classes and methods. Try at all; but yes I understand. > * Maybe a different (at least a hopefully simplified) FactoryFinder > mechanism. yeah! Even taking what we do now and make it "pure factory finder" would help a lot. But FactorySPI is a trouble; witness the user list where referencing does not work under JBoss anymore. > Next step would be a new geometry module backed by ISO geometries. > This one is a rewrite from scratch (Adrian is already working on > that). The goal is to support 3D in addition of 2D, as well as curves > and non-cartesian spaces. This will be a tough one; I am strict about the need to support both ISO Geometry and JTS Geometry. I think I mentioned these ideas (and a JTS 2.0) in one of the planning emails. > Things would become different when we hit Features. GeoTools 3 would > contains only one feature model without the deprecated classes. I > would also suggest that we avoid any direct reference to JTS except > from a "JTS-wrapper" geometry module (so JTS could still be used > indirectly), and maybe from a few plugins designed specifically for > JTS if needed. Yeah I am not sure that will fly; SFSQL is a perfectly good specification in common use. We should think about how to make multiple Geometry specifications available at the GeoAPI level? > For all those module, the practice would not be "rewrite from scratch" > but rather "port from GeoTools 2". If you review some of my earlier email; I had a very similar approach. Handle things one module at a time.. >> Scope & Feasibility, then we can get down to Planning and Schedule. >> We should actually take this pretty seriously; look into the amount >> of planning we put into just changing the feature model ;-) > The hard stuff was to have different Feature models coexisting while > preserving compatibility. Starting GeoTools 3 from a clean room make > the task easier if we don't have to preserve compatiiblity with the > deprecated model, and adapt the code only as we port them. The idea to offering the bridge is to allow code to run during the transition. What we need is a "strict" mode; where people can: - set a flag and get a "pure" GeoAPI Filter - set a hint and get a "pure" GeoAPI Feature
So as long as our code can run using "strict" we are good to go; client code can still make use of the non strict factories in order to allow them to migrate. I know it does not fit with your planning at all but a *really* good idea would be to make 2.6.x introduce this "strict" idea. That way client code will have a chance to be ready *before* 3.0. Cheers Jody ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
