0. FeatureVisitor 1. Renderer (skipped) 2. ACuster 'rant' 3. Catalog Backport 4. GeoWidgets update

CIA-10 These rename the Renderer interface to GTRenderer and move it one level up the package structure. RendererListener is moved up to match.
CIA-10 jmacgill * r15856 geotools/gt/module/main/src/org/geotools/renderer/lite/ (LiteRenderer.java LiteRenderer2.java): Fixed LiteRenderer and LiteRenderer2 to reflect the RenderListener move
jgarnett Morning Justin
jgarnett missed a good party last night ;-0
CIA-10 jmacgill * r15857 geotools/gt/module/main/src/org/geotools/renderer/ (3 files in 2 dirs): Applied [GEOT-689]
CIA-10 rgould * r15858 geotools/gt/module/main/src/org/geotools/xml/filter/FilterComplexTypes.java: Permitted flexibility when parsing FeatureCapabilities
CIA-10 jmacgill 2.1.x * r15859 geotools/module/main/src/org/geotools/renderer/ (5 files in 2 dirs): Merge r:15856,r:15857 in from trunk
CIA-10 jeichar * r15860 udig/plugins/ (22 files in 8 dirs): issues view works now
CIA-10 jmacgill * r15861 geotools/gt/ext/shaperenderer/ (4 files in 2 dirs): Updated to reflect the relocation of RenderListener
jmacgill Hi all
jmacgill I've been busy with the renderering interfaces today
jmacgill feel free to throw rotten egs
jmacgill eggs even
jgarnett Hi James
MatthiasB Hi, why should we throw eggs. I'd rather eat them...
jgarnett chorner and myself have been playing on a branch with aggregate functions. As we finish up I may ask you for a code review, looks like we can leave your existing aggregate functions alone (and only engage our behaviour when the Feature is a FeatureCollection).
jmacgill ok, but it sounds like your code has the potential to be more optimal
jmacgill is there scope for handing back to teh datastore?
jgarnett yep, postgis first as an example (as usual).
CIA-10 jmacgill 2.1.x * r15862 geotools/ext/shaperenderer/ (4 files in 2 dirs): Merge in r:15861 (reflect new location or RenderListener)
jgarnett that is actually what we will be doing this week, intergration with your functions comes after that.
Polio is this an interface change ... or another datastore to add into a chain?
jgarnett James Filter functions will be run on FeatureCollection (rather then Feature w/ an evil hack)
jgarnett and FeatureCollection will get a FeatureVisitor (to aid in the default implementation)
jgarnett (to answer Polio's question)
Polio hmm, and how will this impact backwards compatability? will an implementation be required by all datastores? do you have plans for a default implementation?
jgarnett Yes, default implementations exist up in the Abstract parent.
Polio and so far as backwards compatability goes? will this be another case like FeatureReader vs FeatureStore (some you want to call in one way to be optimal ... others from another entry point)
jgarnett It remains to be seen how well the datastore implementations can make use of this for providing optimizations, if nobody does by the time 2.2. goes out, we can inline all the code.
Polio I would rather avoid multiple entry point ... just confuses people as to why everything is slow / huge in memory
jgarnett There are two - sorry. One from Filter/Expression/Function land (for scripts), and one for java progammers.
jgarnett This is actually a generic problem - we are getting a lot of Functions build for use with Filter.
Polio And the entry point for programmers: is this representative of a thrid (potentaily faster / slower) method of data retrieval?
Polio for example:, DS a has a fast FR implementation, DS b has a fast FS implementation
Polio will requesting data through this new interface cause one of the DS to appear much slower ... and if so which one?
Polio or is this a third entry point entirely ... which means we have some DS which are optimized for only one / two of the many entry points?
jgarnett I see your point, the visitor is implemented on a FeatureCollection by FeatureCollection basis - the fastest way possible.
jgarnett Ie shapefile may actually navigate the spatial index rather then the shx index ...
Polio I understand that point, but my concern is that people will do 'MyFeature = DS.getMangledFeatures()' and thus we have a third entry point
Polio have you looked at making this a DS ... with the creation params as another DS?
jgarnett David the code will be available in the coming days for review, the design is to do the API high level, and let the DataStores do the right thing.
Polio then you could get the FR from a Shp DS and a FS from a WFS
jgarnett I don't see how this can be done as a DataStore.
jgarnett FeatureSource = FeatureCollection
jgarnett Nobody is supposed to see FeatureReader in the 2.2 timeframe.
jgarnett It is all FeatureCollection and iterator as far as client code is concerned.
Polio yes, I got that ... but what I am worried about is another query method
Polio we already too many (at least that's what I think)
jgarnett Okay I get your concern.
Polio and after reading our users thread this AM, I can't see why we would want to confuse the users more extensively
jgarnett No real answer though, we need a way to optimize and iterator does not allow for that?
CIA-10 jeichar * r15863 udig/plugins/ (6 files in 3 dirs): issues view can show groups
Polio that's what I figured ... so now we no longer can guarantee a streaming implementation when we ask for data from the interface ...
jgarnett Part of the problem Polio is I have no time for extensive RnD - I am in the same boat as James was - needing something to work. I can see how this could be done based on FeatureList (aka RandomAccess) and achive optimization that way.
jgarnett It is more that visitor lets the collection decide what is going on and the fastest way to do it.
jmacgill I think I need to see this as code to make sense of it.
Polio I understand your desire for a solution of some form ... perhaps as an extension then if we can't figure out a good longer term solution. This would avoid redoing this all in 6 mths when someone has the time
jmacgill jody, is there a set of standard agregators that are being supported?
jgarnett `I have min, max, midian, sum, count, average, unqiue on the board here.
jgarnett I was going to be guided by SQL and the needs of a "Themer"
Polio is this on the wiki anywhere?
jgarnett I don't think chorner has taken the time to update, but there is a RnD page.
Polio chorner: is it posible to send out a change proposal (like methods added / removed)?
jgarnett IN anycase, I just wanted to give an update - and let James gather an agenda.
Polio oh, and the link ...
jgarnett As it is Polio we have used up your time
jgarnett when I would of liked to be a bit more oganized and talk to you about Feature Model.
jgarnett (link http://docs.codehaus.org/display/GEOTOOLS/FeatureVisitor)
jgarnett I am removing as many convience methods as possible out of the core, and going with QName (it helped a lot vs GenericName)
jmacgill Adgenda items.
jgarnett did you have any more questions on that Polio?
Polio I'll have a read, thanks for the link
jgarnett The link is old - before any work was started.
jmacgill 1) Update on GTRenderer, StreamingRenderer etc.
jmacgill 2) The ACuster 'rant'
Polio ok ...
chorner i'll commit to aggregates if you guys would like something to chew on
jmacgill this is a branch yes?
jgarnett yes
CIA-10 jeichar * r15864 udig/plugins/net.refractions.udig.project/src/net/refractions/udig/project/internal/render/impl/TilingRenderer.java: turned tiling renderer back on
jmacgill chorner go for it
jmacgill Other Adgenda items?
jgarnett Feature Model - but I no longer have time - next week?
CIA-10 chorner aggregates * r15865 geotools/module/main/ (8 files in 5 dirs): First bit of visitor integration into FeatureCollection
jmacgill OK, I'll start from item 1 then.
jmacgill actualy, Dave said he would be late and that impacts him more than item 2
jmacgill so I'll reverse the two items.
jmacgill ok.. So the rant was inevitable. We all KNOW the issues are there. Neither GeoServer or uDIG uses GeoTools 'as advertised'. uDIG in particular uses back doors or ignores things (like MapContext) to get things done.
jgarnett I did offer to throw out the user docs 6 months ago
jgarnett at the time people offered to help, and we got a large volume of snipits - but the big tutorials were not updated.
jmacgill We have, and always have had, a confusion between 'users' and 'developers'
jgarnett I tried to divide it up in to 2.0 and 2.1 docs, so users would at least know what was current.
jmacgill but then the 2.0 docs got updated, and now we have 2.2 on the horizon
jmacgill I don't think docs by version are sustainable. Archived copies of the sight might be...
jmacgill The trouble is that most of our 'users' are 'developers' (At least that is true for the users we here from, users we do not here from may well be the silent majority)
CIA-10 jeichar * r15866 udig/plugins/ (2 files in 2 dirs): applied patch from Cole on renderers
jgarnett james - I can and do write docs for udig developers. And goeserver may/may not work in a similar fashion.
MatthiasB James, is this a problem?
MatthiasB I mean, the good thing about OpenSource is, that you can extend the code when you like.
jmacgill Its not a problem no. But it makes it hard to divide the site into 'user' and 'developer' areas
jgarnett It is a problem for those that just want to display a map, we do not always know how to help them (or what docs to point them towards)
jgarnett I did like the developer guide and "geotools use" division.
jgarnett I remember when I learned all the stuff about maven and docbook just got in my way.
MatthiasB I think it's not too bad: RnD and "Developer's guide" is clearly for developers, Snippets and Tutorials are for the user.
jmacgill we just need to make sure they work.
MatthiasB Of course...
jgarnett What I would like to have is our user invovled in fixing this problem, indeed they are already helping.
jmacgill Some of his points are valid but hard to fix.
jgarnett Could we set a frist monday of the month IRC that is devel/uesr focused?
CIA-10 markhamc * r15867 udig/community/cole/net.refractions.udig.project.ui.redrawlayer/fragment.xml: Added enablement for ILayers only
jmacgill i.e. the 'do not use english language words...' would be a major refactoring
jgarnett James udig is moved onto the aggregate branch, I am willing to do some major simplficiation and refactoring as required.
jgarnett Making geotools understandable is central to the success of udig after all.
jgarnett For example I would love to kill DataStoreFactory finder and make use of the Catalog API justin just backported.
jmacgill I'd like to put some extra unit tests in before we do any major changes. Just to make sure we do not break too many things.
jgarnett I don't agree with the English words idea - but he is correct on the naming collisions.
jdeolive speaking of catalog, can we add a status update of the backport to the agenda
jmacgill Perhaps an additional module that contains the tutorial code / snippets and the most common actions.
jdeolive 3) catalog backport
CIA-10 jeichar * r15868 udig/plugins/ (10 files in 4 dirs): now renderers can indicate whether they wish to be cached
jgarnett we have that in demo, it is just not maintained
jmacgill I would like to make such a module, and have the use of deprecated code be a failure
jgarnett can you turn depricated = failure for demo ?
jgarnett Hard because most of it is J2DRenderer ...
jgarnett Can J2DRenderer hide behind your new Renderering API James?
jgarnett (I was not involved in those discussions and you guys did not post a log to the wiki)
jmacgill demo is a mess. I'd like something clean. Based on acusters tutorial for example
jgarnett delete demo then, and start again.
jmacgill what should I call it?
jgarnett tutorial
jgarnett or examples
jmacgill I'll go with examples. module/plugin/ext?
jgarnett I was thinking its own category - like after demo is removed.
jgarnett that is all examples code that people write should have depricated = error
jmacgill I'll see what state demo is in first and see what can be done as there is some 'ok' code in there.
jmacgill I'll parse the rest of the rant and create JIRA issues as appropriate.
jmacgill No Dave yet, so lets move to item 3
jdeolive udig catalog API backport
jdeolive I have backported the core interfaces
jdeolive and have done a coouple of the implementations, wms and wfs, working on shapefile
jdeolive there are also some docs
jdeolive http://www.geotools.org/Catalog+Tutorial
jdeolive not quite complete yet, but would love feedback
jdeolive right now the backport lives on a spike
jgarnett Can you link to those from the RnD Page - I did read the docs. Nice pictures
jdeolive no, i will add a link
jdeolive so before it can move onto truck i think a couple of things need to be done
jdeolive the first is that there is alreayd a catalog interface, not sure if anyone uses it
jdeolive the second is testing, i need to write some tests, or better yet get some volunteers to help out
jgarnett We can remove it, It was for Catalog 2.0 - and the implementation was thrown out last novemeber.
jgarnett I removed the last trace of implementation code from JDBCDataStore last week.
jdeolive ok, so how shall this work, i guess catalog implemtnations will follow the same pattern as DataStore
jdeolive core interaces and default implemtnations in main
jdeolive and individual implemtnation in plugins
jmacgill what are the implications for this move.
jdeolive well i am under the impression that noone is really using catalog support in geotools
jdeolive so not that big?
jgarnett Frees up Matthias and Pizzi to start on their work. Also prevents a reoccurance of GridCovrageExchange
jgarnett gives people a unified way to handle DataStore, GridCoverage and WMS Layer ...
jgarnett ... provides a subsert of dublin core "info" about each resource.
jgarnett Use of a Handle allows for management without connecting.
MatthiasB One thing I'd like to know is: Is this GeoResource an alternative, wrapper or a replacement for existing classes in GT. Looks like wrapper...
jgarnett Not sure if that answers your question james, or makes more questions.
jgarnett No it is something new
jgarnett it is closest to being a wrapper on connection parameters combined with DataStoreFactory
jgarnett (does that help?)
jmacgill ok, so, what are the implication sof actualy starting to use it?
MatthiasB Well, anyway, I updated the MapFramework (on spike) to point to the backported GeoResource.
jgarnett Thanks Matthias.
MatthiasB (And btw created a Java1.4 copy of it.)
jgarnett Implications are that there is now a geotools facility to manage connections, before we left that kind of stuff up to client code.
MatthiasB This is not saying that I know it works completely or IS complete.
jgarnett jdeolive is there any way we can cut MatthiasB some Java 5 interfaces for this?
MatthiasB Don't need them, i think.
jdeolive cant we just give him the udig interfaces?
MatthiasB No. they are slightly different.
jgarnett I know we can, but geotools does not have a place for java 5 interfaces (yet).
MatthiasB Anyway this is nothing to worry for me.
jdeolive ok
jgarnett Okay, it is a worry for me (usability worry) but I can keep sucking it up for a while longer.
MatthiasB
jgarnett Q: Mechanics - how do you want to merge?
jdeolive with trunk?
jgarnett Make a branch? Copy the code in, remove previous catalog interfaces, merge back onto trunk, make a milestone release?
jdeolive sure that will work, it is necessary to branch since noone really used the current catalog interfaces
jmacgill gotta run, realtor visiting house
jmacgill sorry (will be doing this a lot for a while...)
jgarnett jdeolive, I know you are just doing this to help out (thanks!), I will help out with the merge, and documentation for users.
jdeolive that would be great, although i think the biggest help for me is if you could write some test cases
jdeolive i cant really merge in until the thing is tested
jgarnett thinking
jgarnett Okay I can do that
jgarnett Justin - any thought on changing it to URI
jgarnett Because we have problems with URL needing the internet to lookup its IP address for its hashcode.
jdeolive already done
jgarnett Doh - you did that.
jgarnett Nifty
jgarnett Totally worth udig updating then, it is our last "must have the internet bug"
jdeolive I also named ServiceFactory to ServiceFinder, and ServiceExtension to ServicegFactory
jgarnett Yep.
jgarnett I think this meeting is about done, James was going to talk about renderer - but dblasby did not show.
jgarnett Anything else guys? I am quite excited by some of the RnD work happening, the biggest thing we can do to help our friends on the user list is make things better and more consistent.
jgarnett And it looks like we are doing that.
MatthiasB A comment to MapFramework... OK?
jgarnett Sure
CIA-10 jeichar * r15869 udig/plugins/net.refractions.udig.project/src/net/refractions/udig/project/internal/render/impl/ (5 files): not sure
MatthiasB I believe it is at a point (when we have CatalogAPI), that I cannot improve it further...
MatthiasB ... without actually using it.
MatthiasB So I sort of would like to "give" you the code and let you do whatever you like to do with it.
MatthiasB I will add missing comments, headers, ... of course.
MatthiasB But I do not feel like I should be the one to put it into trunk or anywhere.
MatthiasB And it needs further comments from users. Definitely!
MatthiasB Thats all.
MatthiasB (P.S. I have to clean up, there's some trash left in my the spike directory.)
jdeolive later guys, have to take off, be back in a bit
MatthiasB Seems I mad all peole run away. Sorry. Bye then.
jgarnett Sorry Matthias
jgarnett oh
jgarnett meeting over dave, james had to go before he could talk to you (they wanted to talk renderers)
dblasby jgarnett have logs been posted (I assume I missed the meeting)
dblasby lol
jgarnett Everyone left, James had a call from a realtor and he was collecting logs.
jgarnett I will see what I have.
dblasby ok