Adrian Custer was kind enough to ambush me on IRC for a bit of planning .... here is a summary.
1) I'd like to push us to graduate by the end of the month It sounds like we can do a couple of things: 1. search and replace to update the (c) headers 2. chew through the code review for most of the core libraries After that we have an open question; what to do with module that are not ready? For this to happen we need to have the following information filled in before we annoy the OSGeo board: - http://wiki.osgeo.org/wiki/GeoTools_Incubation_Progress - http://wiki.osgeo.org/wiki/GeoTools_Provenance_Review We should probably move these pages to our own wiki in order to just get things done... 2) wha'ts the status of main's dependency on epsg-wkt? It is just a test dependency; main should not depend on epsg support ... it is CRS Authority agnostic <dependency> <groupId>org.geotools</groupId> <artifactId>gt-epsg-wkt</artifactId> <version>${project.version}</version> <scope>test</scope> </dependency> 3) in passing, I'm going to have to do udig svncleanup on my own time, maybe this weekend Go acuster go ... 4) what do I do with iso geom module? Talk to gdavis (the module maintainer) and see if acuster can take over. There are plenty of problems to fix, the goal is to keep the test cases (and test coverage high) and drop the module back to unsupported for refactoring. I personally hope that the GeoAPI GeometryFactory constellation is reviewed as well. 5. A. pull gt.util out of metadata and gt.measure out of referencing to make a gt-base module This is an interesting one, on a related note I have considered killing gt-api module because it prevents user from just using the layers of abstraction they care about (ie they drag in gt-api for the JTS utility class, allowing them to use JTS Geometry + CRS) and they see stuff like DataStoreFinder... Diagram here: http://docs.codehaus.org/display/GEOTDOC/02+Meet+the+GeoTools+Library One suggestion is to set up gt-util as the public API for metadata and referencing; forcing the JTS dependencie as provided so it is useful to the real world. And keep gt-api as the api for coverage and higher. Next suggestion is to make it called gt-geotools and use it to contain the GeoTools utility class and our Factory system etc... and dissolve the gt-api class .. This one needs further thought; basically we need to think about the user community on this one 6) I've tried to digest your vision for expression as a mechanism for pulling geometries out of features and every time I get stuck Q: who does the evaluation of the expression? A: Who cares; I need you to let that go for a bit until you see what Expression and Filter are for. Q: where how? The user is letting us know what they want through a data structure Q: what is the fallback A: The fallback did not exist; until the SE 1.1. specification added it - and even so it is only there as a fallback for when the "function" the user asked for is not avaialble. Other fallbacks exist in the form of NULL checks and existence checks but those are up to the user to use. Q: I really just want to know what we have to write to pull geometries out of features? A (as a user) You need to write an expression saying where the geometry is (ie a propertyName) or an expression to calculate the geometry; perhaps a function? A (as a developer) You need to write a Converter; the implementation of Expression uses our Converters API to handle the requirement that Expressions not care about type... Q: so who is smart? the user code? the feature? the data store? ... It is the DataStore's responsibility to be smart; they are the code at the end of the day who is going to look at what the user wanted and do its best to figure it the heck out. We have provided a lot of tools to help them be smart. In the form of FilterVisitors that prepair the expression (perhaps applying environmental vairables like DPI). In the form of the Expression.evaulate methods itself; which delegates to the Conveters API in order to take care of all the "type" information that the user is supposed to be able to ignore. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
