Andrea Aime wrote: >> - aggregate functions for generation of useful summary information to >> use when creating styles > But... don't we have them already? We do; but they are not passing tests! >> I have a bunch of possible work I am trying to land: >> - TAB support (perhaps using a gdal/MITAB bridge) >> - rendering optimization (and hopefully removal of hacks) > What optimizations - optimizations are always an question; that only a profiler can answer > what hacks? - the various renderer correcting for datastore mistakes troubles me - the axis order stuff is really troubling me >> - an oracle datastore that makes external IDs available as Associations > Uh, ambitious. Only if we land it; I would rather see the community schema (ie mapping based) approach take point on this topic. >> - SE 1.1 is a much better fit to uDig's needs than SLD 1.0 (infact it >> is exactly the split we need because we define the split in OWS-3) > May I say the split seems ill defined to me? The example I usually do > is, how do you define a highway style in SE 1.1? You cannot unless you > change the order in which the symbolizers are drawn (each symbolizer > on all features vs all symbolizer for each feature) I was thinking of the split between SE 1.1 (focused on rendering control) and SLD 1.1 (focused on mapping of styles to WMS layers). I am not sure I understand the exact problem you are talking about ... perhaps we can have a seperate email thread on the topic? >> - H2DataStore - Martin Davis has been thinking up mad plans and this >> may be a good hook to involve him in what we do >> - H2DataStore has a much more organized base for creating new >> JDBCDataStores > To have JDBCDataStore prove itself for good it should try to replace > PostgisDataStore 1-1 (that is, have every feature, same or better > performance), that would be a compelling story to migrate the other > ones as well. The other form of proof is in how long it takes a new developer to create a new datastore - say SQLServer? Based on the code review I have done thus far I have no problem recommending H2 as a starting point for new work. >> For GeoTools I would like to see (most of these will not happen; but >> some may prove necessary): >> - documentation (always documentation) >> - creation of a datastore that is not limited to simple content >> - the style factory / builder situation sorted out (SE 1.1 work is my >> best chance to do this) >> - the MapContext API sorted out - brought in line with OWS Context is >> my best direction on this >> - The FactorySPI story clean up and possibly replaced. >> >> I probably missed a few things; is that enough to start with Andrea? > Enough to be really concerned about staying on trunk, since some of > these changes have a high chance of breaking GeoServer solid and delay > the 2.0 release (factory spi, referencing, rendering). Given that rendering is very important to both projects I would start any rendering work by making a copy of StreamingRenderer; both to ease your concerns and to have a chance to sort out the method names.
Referencing is the larger concern - referencing has uDig trunk broken right now; so my hands are tied on that one. Hopefully I can find a bug and fix it ... what could help me is an exact list of the system properties geoserver sets in order to effect the forceXY option? I have no good solutions on the FactorySPI replacement; as Martin is fond of reminding me I need to show a working solution rather than just talk about it. For GeoServer I would also also list Java EE integration as a direction for 2.6? There has been some good discussion about making use of long transaction support etc... Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
