- what is up
jgarnett I am working hard on uDig today; I have my laptop with me ... but cannot give the meeting my full attention.
jgarnett Hopefully someone can rally the troops and strike up an agenda
jgarnett apparently gabriel is making 2.5.x releases; but is not around to talk about it ...
jgarnett ... trying to see if anyone is online.
aaime I am
jgarnett Hi andrea
aaime I cannot catch Gabriel with Skype either
aaime about a 2.5.0 release this week, unlikely
aaime we keep on spotting issues in gs 1.7.x...
jgarnett we are still stuck on mvn assembly as far as I know
jgarnett I talked to jdeolive; he is just off ... sigh.
jgarnett well I do not have time for this early morning meeting either; perhaps we should revert the timeslot.
aaime is that going to change the lack of topics?
jgarnett well stuff is happening; the developers are just not here to talk about it ...
aaime would be moving the meeting to 19.00 italian time (15 minutes from now)
aaime improve things?
jgarnett I am not sure; asking jdeolive
aaime I'm kind of sick to have a 12hours working day due to the meetings, I would probably not participate if the time was moved back to the old 21.00 italian time
jdeolive i am flexible on time... its just today something has come up
jgarnett well let us go through our short agenda and get out of here ...
jgarnett 0) what is up
jdeolive is working on oracle stuff and perparing for foss4g
jgarnett jgarnett - working on udig rendering system; trying to beat comments out of jesse and having too many branches for happiness
aaime is trying to hammer anything good out of Oracle (a hell of a job, believe me)
jgarnett 1) 2.5.x
jgarnett we covered this already; gabriel is not here - but it does not look likely this week.
Eclesia nothing new, hack a bit evrywhere
jgarnett sorry Eclesia ...
jgarnett Anything else? I trust the oracle stuff is going okay; I tried helping find a dummy jar on the weekend; the old module maintainer thought it was produced with a tool.
jgarnett okay I can post the very short logs; thanks everyone.
The GeoTools 2.5-RC0 release candidate is available for download:
The GeoTools 2.5 series is reaching stability. The target 2.5.0 release is centred around making a new Feature model available. The new feature model is based on formal GeoAPI interfaces and will allow the library to evolve into supporting complex data structures.
GeoTools 2.5 also targets graduation as an OSGeo (The Open Source Geospatial Foundation) project, and includes usability and performance improvements, preview version for the new Swing Widgets, and online and downloadable User Guide, an ISO 19107 Geometry implementation available as a supported module, new GPX DataStore, a much more robust ArcSDE DataStore, and JAXB Bindings for xml marshaling of GeoAPI ISO-19115 metadata structures.
This first release candidate of the series brings bug fixes related to raster coverage rendering, data access, ArcSDE, some improvements on the project build process, and the finalization of the switch to the new GeoAPI Feature Model (though remember 2.5 still focuses on Simple Features only).
Thanks to everyone who provided feedback on our new Feature model. This release contains several usability improvements based on your feedback; thanks also go out to Andrea and Justin who spent some time making the switch to the GeoAPI Feature Model passing GeoServer CITE tests, and to Jody for improving our build system.
Not to forget, a big thanks to Geomatys, GeoSolutions, Refractions Research, OpenGeo and the community for continuously leveraging the project and making it such a success every day!
Features from 2.5-RC0:
- Feature Model switch to GeoAPI completed with passing CITE tests from GeoServer as sanity check
- Some major bug fixes related to raster coverage rendering, ArcSDE, and Filter to SQL simplification
- Build system improvements
Features from 2.5-M3:
- OSGeo gradudation! All the headers have changed and we now track license use on a module by module basis
- Usability and Performance improvements to the Feature
- FeatureCollection no longer implements SimpleFeature or Collection; removal associated implementation classes such as ResourceCollection
Features from 2.5-M2:
- JAXB bindings for the metadata module (ie support for ISO 19139 documents)
- FeatureAccess super class for DataStore, allowing data access using ISO
Features from 2.5-M1:
- Change over to GeoAPI SimpleFeature
- Support GetGMLObject
- Preview of new Swing Widgets (and a warm welcome to Eclesia)
Features from 2.5-M0:
- Online User Guide
- Java 5
- Improved CRSAuthorityFactory implementations available for Java Enterprise Edition users
- ISO 19107 Geometry implementation available as a supported module
- DB2 returns to supported status
- ArcSDE returns to supported status
- GeometryBuilder utility class
- A new GPX DataStore
For more information please visit:
If you are new to GeoTools please consider this release as a good starting point, although the 2.4.x remains the stable branch we have no planned API changes and user documentation available for the 2.5.x series.
The GeoTools Community
- What is up
- 2.5.0-RC0 status
- svn uptime
- groldan is working on the 2.5-RC0 release and needs help with mvn assembly
- jgarnett is making a Move to another Server proposal
jgarnett* good morning
jgarnett (sorry I am late...)
jgarnett do we have agenda topics?
Eclesia doesnt have any
Eclesia hi jody
jgarnett has changed the topic to "0) what is up 1) 2.5.0-RC0 status"
jgarnett groldan ping? You did want to talk about 2.5.0-RC0 right?
groldan hi, sure
jgarnett has changed the topic to "0) what is up 1) 2.5.0-RC0 status 2) svn uptime"
jgarnett Do you have anything for the meeting andrea? You have been asking interesting questions about SDO and Oracle
jgarnett But perhaps we should just start ...
jgarnett 0) what is up
aaime is looking into JDBCDataStore again and working on some GS/MS benchmarks
groldan is trying to figure out how to assembly without unsupported modules
Eclesia nothing special
jgarnett jgarnett - testing 2.5-RC0, check user guide sample code (and assorted udig/gwc stuff)
groldan aaime: what's an MS benchmark?
jgarnett I think he means "Map Server"
jgarnett now that pramsey is making it faster; andrea has some work to do.
aaime ha ha, indeed
jgarnett if it would help Andrea we can try and keep pramsey drunk on this end ...
aaime no no
jgarnett I know where he lives; a bottle of scotch placed on his doorstep should do it...
aaime if he insists optimizing a C based rendering he'll eventually win but.. I'm not ready to give up just yet
jgarnett 1) 2.5.0-RC0 status
jgarnett groldan how is it happening?
groldan well it seems assembly did assemble everything
groldan I'm looking now if a mvn clean install (without -Dall) first
groldan makes it assemble only the supported modules
aaime yeah, that's my guess as well, I believe assembly just lumps up all the jars ending up in target
groldan was stuck for a while due to the refractions repo being down, but its fixed now
groldan confirmation in 10 secs.. just finished
aaime jgarnett, how is it going on trunk vs udig?
jgarnett it is going fine
jgarnett it seems that udig is the major source of change; as we find and fix problems
jgarnett I want to see the FeatureEvents cleaned up over time; but I am mostly driven by customer problems (so my chance to work on stuff depends on how annoying any given problem is)
groldan could you check if that's the correct list of modules to include?: http://pastebin.ca/1184407
jgarnett It is not
jgarnett see: geotools-2.5-SNAPSHOT/gt-oracle-spatial-2.5-SNAPSHOT.jar
jgarnett that should not be included.
aaime curious, how is it oracle is in there, and mif is not?
groldan or rather a sorted version: http://pastebin.ca/1184409
aaime (a sorted list... thanks!)
jgarnett so yeah; that list has too much stuff in it
jgarnett I assume those items do not build when you do a: mvn clean install ?
groldan lets see
jgarnett I am trying to figure out if you have everyting
jgarnett martin made the change to remove "Validation"
groldan seems not: http://pastebin.ca/1184412
jgarnett I made the change to chunk the unsupported modules into profiles
jgarnett I concur - that is a better list.
jgarnett .. so there must be something about "assembly" we do not understand?
groldan this is what assembly is trying to build: http://pastebin.ca/1184417
groldan mvn clean install is building swing widgets
groldan isn't that on unsupported?
groldan so the problem may be with install rather than assembly?
Eclesia there are 2 swing widgets
groldan ah ah
Eclesia siwng widgets and swing widgets pending
Eclesia pending is in unsupported
jgarnett there are two swing widgets; one in unsupported; and one in extensions
jgarnett yeah what he said.
groldan hmmm the list of modules to build on install and assembly seems equal
aaime so, it seems this topic is killing the meeting?
jgarnett okay so we are a bit stuck on this; perhaps we can try with a small example module? I am not finding anything in the maven docs...
jgarnett let us return to this topic on IRC after the meeting
jgarnett 2) svn uptime
jgarnett I have talked to Jeff
jgarnett and we have no good way to keep our server from going down
aaime ok, time to move to osgeo ones?
jgarnett our service provider is not being that helpful; we can hope that rebuilding the server will "fix" the problem
jgarnett but that is just a hope?
jgarnett So I would say time to move to codehaus ones
jgarnett (since we are short on volunteer time around here?)
aaime and moving on codehaus is easier/better than osgeo?
jgarnett geoserver is managing to use codehaus svn are they not?
jgarnett it offers single sign on with our wiki
jgarnett so ... yes.
jgarnett (and we do not have to maintain it ... I would much rather have everyone here working on code then servers)
aaime yes, we had problems over one year ago for a couple of weeks (not continuosly) but that's all
jgarnett however I am open to both options; the above is just my take on the matter.
jgarnett I would also like to see if we can use codehaus for some of the repository duties?
jgarnett I know geoserver deploys to a codehaus repo right?
aaime we can
aaime GeoServer has webdav support
aaime and a repo as well
aaime (two different addresses I believe)
jgarnett I am going to tough it out on the udig project a while longer But udig also has a wiki and svn space on codehaus.
jgarnett But I will bring the issue up in thursday's udig meeting as well.
jgarnett So what do we need here? We need a change proposal; and we need volunteers to help with the move.
jgarnett This is one activity where I cannot volunteer on; running svn is not my forte.
jgarnett I am hoping others have more/better experience?
aaime I have never run a server myself either
aaime (a svn server)
jgarnett Andrea are you in a good position to make a change proposal?
jgarnett If I write it up it will be very shy on the details
jgarnett it is going to be a tie
jgarnett between downtime from refractions server being hit by scripts
jgarnett and downtime from making the change?
jgarnett I am going to do all I can to get some sys admin time to bundle up the geotools svn ...
aaime ok, first let's find someone willing to make the switch
jgarnett Well we can make the proposal
aaime can you just write a mail to gt2-devel asking for a volounteer?
jgarnett and just not vote on it until we round up enough volunteers.
jgarnett that is it for the agenda
jgarnett I can post the logs
jgarnett and if I can ask people to leave this window open
jgarnett and help groldan get 2.5.0-RC0 out (because battling maven is no fun)
jgarnett groldan I checked out 2.5.x in order to help; it is building now...
groldan cool, here too
0. Whats Up
1. 2.5.0 Release
2. Unsupported Module Handling
jdeolive has changed the topic to ``1) 2.5.0 release''
aaime has changed the topic to ``0) What's up 1) 2.5.0 release''
<aaime> ok, I added my topic, we're even
Eclesia has no topic to give
groldan is now known as groldan|holiday
<jdeolive> ping aaime, acuster, afabiani_ , cbriancon , Eclesia , simboss , vheurteaux
<jdeolive> hi all, meeting time, jody asked me to run
<jdeolive> anyone have any agenda items?
<aaime> jdeolive, what are you still doing at the keyboard?
<jdeolive> ok, lets start
<jdeolive> 0) whats up
jdeolive is working on getting gs 1.7.0 out, requiring gt 2.5.0
aaime is reading mail and looking around after a week vacation, also getting ready to go to foss4g 2008
Eclesia playing with rendering
<simboss> hating python right now
<jdeolive> ok moving on...
<jdeolive> 1) 2.5.0 release
<--| Mediii has left #geotools ("Leaving.")
<jdeolive> not much to say here... we hope to release 2.5.0 by the end of the week
<jdeolive> jody has a few things to get out of the way for this release.... so i figure we give him a few days to do that
<aaime> I guess the crucial issue is to leave out of the downloads the unsupported modules?
<jdeolive> and tehen release toward the end of the week
<jdeolive> right, his proposal
<aaime> but we're ok deploying them to maven repo right?
<jdeolive> aaime: yes, i believe that is the idea
<jdeolive> leave them out of the release, but available to the other projects that need them
<aaime> I'm ok with that proposal
<jdeolive> as am i
<aaime> we have to make sure the build servers build with -Dall
<aaime> like, when you make an api/behaviour change
<aaime> what are you supposed to check?
<aaime> if unsupported is out of the build
<jdeolive> or... have all build by default
<jdeolive> and have the "release profile" limit the modules
<aaime> if you can do that, it would be ideal imho
<jdeolive> i also don
<jdeolive> t see why the property all is used... rather then just directly invoking the profile
<jdeolive> its my experience that profiles work better when invoked directly... rather then relying on a property
<aaime> yeah, agreed, using the profile directly it's more direct
<jdeolive> ok... so two bits of feedback thus far?
<aaime> less troublesome
<jdeolive> 1) invoke profile directly
<jdeolive> 2) have unsupported included by default, make release filter them out
<aaime> jdeolive, afaik maven profiles are "addictive", in that they only override/add config
<aaime> so we should have a default profile that uses everything
<jdeolive> addictive = additive?
<aaime> yeah sorry
<aaime> (once you start using profiles, they get addictive as well)
<jdeolive> they can be quite addicting too though, once you start you cant stop!!!
<aaime> anyways, that's a little troublesome
<aaime> since we may have other profiles that do not have anything to do with the unsupported modules build
<aaime> and they will interefere with the eventual default profile there... bah...
<jdeolive> yeah... it seems profiles in gt are a bit of a mess at the moment
<jdeolive> pending, archive, unsupported.... now release
<jdeolive> i see trouble on the horizon as well
<aaime> ah,t hat's probably why Jody is using variables
<taichimaro> merci Eclesia
<aaime> afaik you can have two profiles activate/deactivate according to the presence of a certain system variable
<taichimaro> tu fais vraiment bcp de choses qui aident
Eclesia slaps taichimaro
<taichimaro> haha pq
<Eclesia> chutttt, meeting time
<jdeolive> which is where they have an opportunity to trip each other up
<aaime> Meh, if we use a default profile any other profile activating will kill it thought
<aaime> Description of "activeByDefault" says: This profile will automatically be active for all builds unless another profile in the same pom is activated using one of the previously described methods.
<jdeolive> yup... which is why i like the direct profile approach, activating profiles by default should be banned imho
<aaime> which means we'll need to always build gt2 with -Pall?
jdeolive prefers getting only what he asks for
<aaime> afaik all the trouble arises from the hypothesis that's not possible to remove modules from a build using profiles, only adding them
<jdeolive> aaime: i dont think thats true
<jdeolive> you can ovveride the entire modules section can you not?
jdeolive could be wrong
<jdeolive> actually i think i am wrong
<aaime> mumble, when we use profiles in gs, we have a modules section for each
<aaime> and they are additive
<jdeolive> right right
jdeolive slaps himself
<jdeolive> maybe we should have an unsupported profile then...
<jdeolive> and by default not build unsupported modules...
aaime hopes that devs will remember to add the profile to build everything
<aaime> One thing that we should make clear in the proposal is that
<aaime> if you break the build with a change and the error is in an unsupported module
<aaime> the build is broken for good
<aaime> What I fear is that people will get the message "unsupported modules are none of our concern, not even build wise, anymore"
<jdeolive> correct, we should ensure that is not the case
<jdeolive> i think having the build server yell at them should do a decent job of that
<jdeolive> buut agreed
<jdeolive> we should make it clear in the proposal
<aaime> well, hopefully jgarnett will read the logs
<aaime> anything else?
<jdeolive> nope, i think thats it
<jdeolive> unless anyone else has anything?
<jdeolive> cool, lets call it a meeting then
<jdeolive> i will post the logs
0) what is up
2) poml.xml management for unsupported modules
3) GenericName vs Name
- desruisseaux: will remove verifier from trunk and 2.5.x
- jgarnett: will write up a proposal for handling unsupported modules
jgarnett* good morning
jgarnett This page still shows us meeting 3 hours from now
jgarnett - http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett going to go over the past logs and figure out what to update the page to
desruisseaux (firstname.lastname@example.org) has joined #geotools
Eclesia (n=Administ@22.214.171.124) has joined #geotools
Eclesia (hi all)
desruisseaux Hi Eclesia
jgarnett good morning;
jgarnett it is meeting time.
jgarnett Shall we gather up some topics and get going ...
jgarnett 0) what is up 1) verifier 2) pom.xml management
jgarnett While we start I would like to thank Christian Muller for expanding his roll in the project; it is great to have
someone able to hunt down and squish ibm JRE related issues.
jgarnett does anyone else have topics for todays meeting?
desruisseaux not on my side
jgarnett okay it has been fine minuets so we should start.
jgarnett I am going to send a reminder email
jgarnett and I have updated the developers guide to reflect this meeting time:
jgarnett okay let's get our game on
jgarnett 0) what is up
acuster acuster---learning referencing for real this time, trying to understand what mathematical space(s) geometric
analysis needs to happen
jgarnett jgarnett - apparently breaking the 2.5.x build trying to sort our verifier and release artifact creation.
Reviewing 2.5.x proposals and user gide in anticipation of a 2.5.0 release. Looking into OGR bundling issues for udig and
generally being busy.
desruisseaux Martin: working in parrallel on ISO 19103 names and on mosaic work on 180,000 tiles.
jgarnett Sounds like you guys are having fun; thanks for the nice summary of naming issues on the geoapi mailing list
jgarnett going to do a couple of pings and then carry on with the meeting
jgarnett jdolive ping
jgarnett groldan ping
emily_g emily: I made a few updates to the image mosaic code to allow additional styling parameters to be applied to the
jgarnett (I had really hoped to see simone as he is reviewing some of Emily's image-moasic work)
jgarnett 1) verifier
jgarnett We seem to be caught in a build loop on this one; it hits me every time we tag and try to make a release.
desruisseaux I suggest to just delete verifier.
jgarnett I was hoping we could use the build plugins to try out your ideas of "fixed version numbers" Martin.
acuster kill it
jgarnett okay that is a nice clear direction.
acuster it doesn't catch our errors at the right time
jgarnett it did initially serve a value; it helped us find problems when we moved svn around right?
jgarnett (sorry for the review I am trying to make sure I have a good reason to vote to kill it; rather than just
annoyance you see)
desruisseaux When we move module directory? Yes it serves that purpose.
jgarnett can we make it an option? much like we did for code reformatting?
simboss (email@example.com) has joined #geotools
jgarnett ie it would be nice to "verify" next time we move svn around ...
jgarnett this is a yes/no question .... I suspect we should probably kill it as well.
acuster too much work and no one cares enough to do it
jgarnett shall we move on ... wait this should give us an action item.
jgarnett I can remove it from trunk/
jgarnett not sure I have a 2.5.x checkout at work.
jgarnett do I have a volunteer with a 2.5.x checkout?
desruisseaux I can do the removal.
desruisseaux Will do it on both trunk and 2.5 branch.
jgarnett okay thanks martin
jgarnett and thanks for writing it up as well; it really did help during our svn group/name wrangling.
jgarnett 2) pom.xml management
awp_ has left freenode ("O.o")
jgarnett we ran into an issue with management unsupported/pom.xml last week.
jgarnett We have no clear guidelines on how to handle unsupported/pom.xml
jgarnett and we get in trouble over it every couple of months
jgarnett removing broken modules from the build; adding stuff to the build that takes too long to test
jgarnett and removing modules from the build that people are using.
jgarnett In general I expect PMC members to handle this as general "community support"
jgarnett (indeed the entire unsupported module experiment falls under "community support").
jgarnett So I got a question - are we doing okay on this topic as it stands? Or do we need to look into setting down some
jgarnett For reference I had 3 developers go idle when we were messing around with unsupported/imageio-ext last week. So I
need to be able to tell management that we are handling this as a project
jgarnett and not wasting developer time.
simboss if we had followed the procedures
simboss nothing would have happened
simboss I think that was a matter of obstructionism vs procedures
jgarnett we have lots of procedures about modules (and letting each module maintainer work)
jgarnett but very little about the entire build system - other than to say it is the kind of thing PMC is responsible for.
simboss as a baseline
simboss I would not expect people to take decisions without communication
simboss like it happened for the imageio-ext thing last week
jgarnett indeed; however it has been known to happen and known to be justified (usually in the case of me removing a
broken unsupported module from the build)
simboss that is specific compelling case
simboss which we could write down
simboss anybody can do that
jgarnett I am going over the developers guide and am seeing very little about a communication requirement; my assumption
here is that the PMC will to communicate.
simboss as a baseline I think
simboss that only cause for removing something from the build right away
simboss should be
simboss breaking the build
simboss everything else should need communication
simboss or better
simboss the module maintainer should have some degree of freedom
simboss the others a bit less
simboss but still
simboss I would not like to have someone
simboss remove a module
simboss even its own
simboss without notice
jgarnett I understand simboss; however we are in new territory here with both handling the pom.xml file and handling
jgarnett my default assumption is the module maintainer is responsible for their entry in the pom.xml.
cbriancon has left freenode ("Leaving.")
jgarnett I got in trouble for adding Ecleisa's work to the build when he was not ready for example.
jgarnett he was kind about it; but I was probably out of line. From my standpoint it was hard to collaborate with him if
his work was never in the build.
jgarnett I think we eventually used a profile to iron out that situtation.
jgarnett okay the fact that we have managed to talk for a few mins probably means the documentation / polices here can use
acuster Jody, I told you that I would trust your judgement, but if your solution implies that (1) anyone can propose a
unsupported module (2) that module can introduce any dependency and (3) that code gets deployed onto my hard drive, then I
am very vulnerable to the sloppiness of others
jgarnett acuster; it is true - we are taking on some up front risk and pain; in the hopes of pulling in new developers
jgarnett (and finding maintainers for code we would otherwise throw away)
jgarnett so far there are two downsides
jgarnett the risk you mention
jgarnett and for our existing developers to just make use of unsupported modules; because it is less work
simboss I am sorry acuster but I think you are shooting at a fly with cannonball
simboss we must be careful
simboss with the dependencies of the core libraries
simboss as we should have been with jaxb
simboss but as of plugins
jgarnett About the only strict restriction we have mentioned up front here is asking people not to commit data or jars
into the repository.
simboss it is quite simple
simboss dont want, don't use
jgarnett it is not quite that simple simboss
jgarnett we are expecting people to checkout
simboss it is never simple
simboss but we need to move
jgarnett and include in their own build
jgarnett work they may not be interested in.
acuster so why don't we throw all of unsupported into a profile
simboss I am fine with profiles
jgarnett we do that because we want as many eyes on the problem of api change and breaking stuff as we can get.
acuster that way I don't have to use any of it
acuster since I don't trust it
simboss that's how we handled the thing since the beginning
simboss we might have to ask aaime also
simboss to check if we are with the geoserver procedures
acuster yes, it was a strange decision to throw your work into the build with no warning
jgarnett simboss we have not been quite that strict; unsupported modules such as oracle have stayed in the build because
they are important to geoserver and udig as products.
simboss acuster: I agree
simboss but again
simboss building something routinely
simboss it does not mean
simboss we do not have to use profiles
CIA-35 desruisseaux * r31163 /branches/2.5.x/ (build/maven/verifier/ pom.xml): Removed build/maven/verifier plugin from
the 2.5 branch. Its look like that it was already removed from trunk, so both should be less troublesome now.
dany_r has left freenode ("ChatZilla 0.9.81 Firefox 126.96.36.199/2008070205")
simboss for selecting specific parts out of the whole library
- Eclesia going ++
acuster so what are the down sides of having a profile for unsupported?
jgarnett I got lost in double negatives
*--| Eclesia has left #geotools
simboss the imageio-ext will stay unsupported as long as the gdal version we are waiting for won't be released
acuster -Punsupported pulls them all in
jgarnett the downside is we could break some code with out noticing.
jgarnett the upsides are a reduced build time
simboss a lot!
jgarnett and a reason for unsupported modules to want to upgrade their status.
acuster but our response to breaking the code is to pull the module from the build anyhow, no?
simboss but we could also have some specific profiles
simboss to pull in only some of them
simboss of course!
jgarnett okay this is giving me some material to work with
jgarnett I will write up a proposal for the handling of unsupported modules
simboss if the geoserver guys wants to build with imageio.-ext enabled
simboss they can do that
simboss like we do
simboss but as rule of thumb
simboss we should build with most of them disabled
jgarnett to really clarify it is an svn "work in progress space"; the contents are only enabled through profiles; and none
of it shows up in our prepackaged downloads.
simboss all of them
simboss I agree
simboss so that everyone is happy
jgarnett martin / acuster feedback?
jgarnett I don't want to spend time writing up a proposal if this is going to be a stupid idea.
jgarnett desruisseaux ping?
jgarnett I am thinking of writing up a proposal about unsupported module handling; I was going to get a sanity check from
you before starting.
acuster personally, I like the idea of having them all out of the build
jgarnett the idea is to push the unsupported modules out of the build; only using profiles to add them in. And clarify the
fact that we don't ship them.
acuster and an easy way to include them all for those who want to see what they have broken
jgarnett acuster++ this does sound like a good way to handle this.
acuster it will make the transition to supported even more fun
jgarnett okay I will write this up and we can revise via email.
simboss i would also like to have the ability to turn my own module
simboss just in case
desruisseaux The above proposal (maven profile) can be a good mid-term compromise. A longer term approach may be to split
the SVN on two separated versionning system: "core geotools" and "experimental", with the experimental modules depending on
core milestones rather than snapshots.
acuster but the issue of what unsupported modules are allowed to pull in still seems relevant as long as the code uses a
centralized versioning system
simboss to do selective build
jgarnett simboss I was thinking of leaving that in the hands of the module maintainer? That makes sense does it not?
simboss it is perfect
jgarnett martin if possible I would like to use the same svn; remember my goal is as much getting new developers as
getting more code.
acuster martin, I like that. We should think about setting up a dummy maven and directory layout so users can (1) build a
module that depends on the "core"
acuster then (2) integrate that someday into the 'core'
jgarnett acuster; your point is valid - can we address that when a module tries to become supported? Or do we want to put
down some guidelines like we have for committing data and writing test cases?
desruisseaux The "split SVN" proposal is a long-term one. Not for anytime soon, so we can come back on it later. In short
term, maven profile would work.
acuster when a module wants to be supported, there should be an explanation of what it does, what it pulls in, and other
simboss I agree.
jgarnett and docs (I always need to mention docs)
jgarnett okay guys that sonuds like a wrap for the meeting.
jgarnett Martin we had some issues with Java 6 and IBM JRE build failures
jgarnett is that anything we need to talk about?
acuster but regardless, modules, supported or not, have a responsibility to follow the law, and be careful about what they
are depending on, no?
jgarnett or can we put it off till later.
desruisseaux I saw the email. The Java 6 issues are actually existing for one year or so.
jgarnett acuster - see above - I was trying to ask you that. I think there are some limits (such as we run into with ESRI
jgarnett but we will need to carefully word the issues so it makes sense
jgarnett (I wrote a blog post http://how2map.blogspot.com/ on the topic but I am not sure anyone read it)
jgarnett but yeah I agree with you; there are limits on the dependencies allowed - we just need to figure out what they
are so we can communicate them well.
desruisseaux I will fix the Java 6 issues, since geotidy is targeting Java 6 - so there is no way I can work on
referencing without fixing those issues. It is just that I need to finish GeneralName and its friend before to move on
referencing, since referencing depends on it.
jgarnett I am interested in how you are planning to fix GeneralName
acuster (1) by not making it a repository system
acuster i.e. no pointers to object
jgarnett the relationship between GeneralName and Record is what pretty much stopped my agressive geoapi work.
acuster ah, I have been ignoring Record.
acuster Martin probably knows more
acuster and has javadoc links
jgarnett acuster++ (now if you can do this before 2.5.0 goes out we can kill org.opengis.feature.Name)
acuster aha, now that's incentive
desruisseaux Tried to clearify the meaning of "head", "tail", "path" and "tip" with a figure.
jgarnett the "name as repository / reflection" story is what stopped us cold (after three months emailing bryce)
acuster yeah, they want to do a catalog system in the identification system
acuster with basically no documentation
jgarnett acuster - yeah someone finally sees my conflict
acuster even if it could work, it's bad standards writing
jgarnett now that said they have a reason
jgarnett they actually want a catalog system
jgarnett (not an identification system)
jgarnett ie my take on it last time is we went into the standard looking for the wrong answer.
jgarnett I basically decided that the "Name" part of GenericName / LocalName was misleading us
jgarnett into thinking we were looking at an identification system.
acuster surely we can start with an id system and build a catalog system on it later?
jgarnett Thus I could justify the creation of org.opengis.feature.Name as an identification system.
acuster does record need a catalog system to work?
jgarnett yeah it basically demanded it
acuster if you have time to look at what martin has done
jgarnett the deegree people dodged the issue and made their Record extend Feature.
acuster you could tell us if it satisfies the feature system
jgarnett my best idea yet is to make our Name in geoapi an identificaiton system
acuster it's attempting to be merely an id system
jgarnett and advise people to use something like JNDI for their catalog / reflection system.
acuster yes, we can cross that river when we want to build a record bridge
jgarnett What is your timeline martin? I am not going to have time to review (seriously review) until next week
acuster who uses records anyhow?
jgarnett and catalog should use it
jgarnett both problems have lead me against it (and to asking for help on the geoapi list) previously
jgarnett catalog is supposed to return records
acuster I don't think martin has dealt with the issue of separator yet
jgarnett records that are described me one or more metadata.
acuster yeah, so catalog is a bigger deal that we can tackle on its own
jgarnett I was meaning formal OGC Catalog spec.
jgarnett not the ISO GenericName / LocalName / Namespace split.
acuster it may be as simple as adding a sub-class to name-the-id-version
desruisseaux About my time frame: I'm working on name mid-time, since I have to work on a mosaic in same time. So it may
take me a week before I have an implementation to suggest.
acuster which has a .getObject() method
jgarnett acuster that may be a useful hack; it goes against a bit what the ISO spec is trying to do does it not?
jgarnett ie if I look at a record that has MemberName(s)
jgarnett the MemberName(s) actually are the child objects.
acuster perhaps you are right
jgarnett if we make a getObject() method
jgarnett it would demote them to being like Map.Entry
jgarnett (not that that would be a bad thing - the ISO spec seems really poorly thought out in terms of a split)
acuster again, I have happily ignored record
jgarnett or our thinking approach is wrong.
jgarnett okay please look into how people use Name; even what we have as FeatureType right now
acuster so maybe we split GenericName into two hiearachies, one for id and one for cataloguing
jgarnett is supposed to literally extend Name
awp_ (firstname.lastname@example.org) has joined #geotools
acuster okay, will take a look
jgarnett I wish I had a good approach to recommend acuster; we often talk about difficult problems together? This is a
problem that has kicked me down a few times.
jgarnett so I am really looking forward to a fresh pair of eyes.
acuster to prepare my seething for the next OGC meeting
jgarnett and sorting out Record / RecordType would immediately benefit the CoverageAPI which I find "unbelievable" in its
awp_ Hello all, how can I edit http://geotools.codehaus.org/The+axis+order+issue ? (Just to update the code example on
"What GeoTools Does", which is using FactoryFinder instead of CRS)
acuster yes we have all lost the battle with name several times over, you, Martin, Bryce, me, and probably justin and
jgarnett hi awp; our meeting is just ending so can I ask you to hold your question for a few more moments?
awp_ sure thing, sorry about that
acuster awp_, on the front page there are instructions on how to signup for editing rights
acuster we are done?
jgarnett acuster I was going to try it again when I had beaten a formal set of Names (ie a vocabulary) out of someone like
RobA. And see if it all made sense if I started with the right problem for the API.
jgarnett right now we do a few horrible things to report back records out of coverages; and then I have watched our
mistakes get repeated.
acuster nice, we should do that (the beating RobA. part).
jgarnett but yeah I will stop ranting and write up the logs.
acuster thanks for running the meeting
jgarnett thanks for the productive chat.
jgarnett awp_ ping? the floor is yours.
The GeoTools 2.5-M3 milestone release is available for download:
The GeoTools 2.5 series has been updated to use Java 5, and has undergone many improvements. This release is centred around making a new Feature model available. The new feature model is based on formal GeoAPI interfaces and allows the library to work complex data structures.
Thanks to everyone who provided feedback on our new Feature model. This release contains several usability improvements based on your feedback; thanks also go out to Andrea who spent some time with a profiler to minimize the performance cost associated with this change.
There are no further API chances planned for the 2.5.x series; we have started formal branch and are treating this as a stable branch. Both the GeoServer and uDig projects have successfully migrated, you should make your migration plans now; we expect a a release candidate as soon as GeoServer passes a few more CITE tests.
Features from 2.5-M3:
- OSGeo gradudation! All the headers have changed and we now track license use on a module by module basis
- Usability and Performance improvements to the Feature
- FeatureCollection no longer implements SimpleFeature or Collection; removal associated implementation classes such as ResourceCollection
Features from 2.5-M2:
- JAXB bindings for the metadata module (ie support for ISO 19139 documents)
- FeatureAccess super class for DataStore, allowing data access using ISO
Features from 2.5-M1:
- Change over to GeoAPI SimpleFeature
- Support GetGMLObject
- Preview of new Swing Widgets (and a warm welcome to Eclesia)
Features from 2.5-M0:
- Online User Guide
- Java 5
- Improved CRSAuthorityFactory implementations available for Java Enterprise Edition users
- ISO 19107 Geometry implementation available as a supported module
- DB2 returns to supported status
- ArcSDE returns to supported status
- GeometryBuilder utility class
- A new GPX DataStore
For more information please visit:
If you are new to GeoTools please consider this release as a good starting point, although the 2.4.x remains the stable branch we have no planned API changes and user documentation available for the 2.5.x series.
The GeoTools Community
0) what is up
0) 2.5-M4 tag created; to be released this week
1) 2.4.x to be released this week for GeoServer
2) 2.2.x to be released (pending one bug fix) for uDig
3) SE patch to arrive this week Eclesia will send email
jgarnett* good morning
jgarnett I am still wonder if the meeting time is now .. or in an hour
vheurteaux hello jgarnett it's now
jgarnett oh okay
jgarnett Morning Eclesia, aaime etc...
jgarnett let us start the meeting
Eclesia hi jgarnett
jgarnett (we are on holiday's here in Canada; so attendance from Refractions will be light)
aaime ops right it's Monday
jgarnett agenda topics
jgarnett aaime I feel a bit thrown around on the 2.4.x release schedule; can I ask you for an update in todays meeting?
aaime I have no topics for the meeting, the only topic I need an update for was sent to the ml
jgarnett looking for it ...
jgarnett what was it on?
jgarnett A WHERE 1=1 ?
jgarnett okay I can respond to that email.
aaime jgarnett, yes, that one
jgarnett gabriel is one of the people that can test arcsde; I should also be able to run tests for you. No idea about DB2; you can start by emailing the module maintainer directly.
jgarnett okay well let us start with the traditional 0) what is up
jgarnett this should be a short meeting.
desruisseaux Martin: metadata
Eclesia jsorel : playing with xml apis
aaime fixing bugs and plaing with the new GeoServer UI
jgarnett jgarnett - kicking off several new uDig based projects (the teams will have some exposure to this email list); wps project is wrapping up this week; looking into a gdal2gt bridge for MITAB support; hooking up the coveragetools in udig; adding some processing to imagemoasic with Emily
simboss jgarnett: wow
simboss simboss: netcdf
groldan geoserver 2.0 ui
jgarnett thinking; so if so many people are doing geoserver 2.0 ui; what is left on the 1.7 train? I ask because I would like an answer for the "GeoTools 2.5.0 when" questions on the user list.
aaime next rc is not scheduled this week afaik
aaime or at least not soon
jgarnett I see
aaime and the blockers in 1.7.0-rc1 need Justin attention
jgarnett well I would like to have a clue; since we kind of owe the OGC a press release
jgarnett and it would be nice if that included some associated software.
jgarnett was anyone able to go back and tag 2.5.x ?
jgarnett to reflect the release geoserver made last week?
jgarnett Martin started a thread about 2.5-M3 ...
aaime not sure, what I'm sure of is that someone noted the revision
aaime I wasn't involved in the release process other than doing CITE tests
jgarnett So do I ask dwins?
desruisseaux Basically I was just looking for a tag before to remove metadata annotations.
desruisseaux I was not looking for a real 2.5-M3 release.
jgarnett And I am looking to get a release in maven; for the user list.
aaime jgarnett, the release in geoserver was made by bmmpxf
aaime if he did not ask anybody to tag
aaime nobody did
groldan hmmm pity
aaime we have the revision number, we can add the tag at any point
jgarnett aaime if you could do so; I can release the tag today.
jgarnett (and can we please try and be a bit more clear next release cycle )
aaime why do you want to release the tag?
jgarnett Martin does that meet your needs?
aaime jgarnett, I cannot be clear for other people, just clear for myself
jgarnett because I care about geotools as a project; and we have users asking for the release...
jgarnett okay I will try and be more clear next release cycle; I thought I was working well with dwins
jgarnett and then he said "we are releasing a beta now" and everything went sideways for me...
aaime jgarnett, I said bmmpxf did the release
aaime he's the one doing the gs releases now
jgarnett true; dwins was just kind enough to tell me what had happened
jgarnett from my perspective I had set aside work and volunteer time to help get the geotools release out; and then I lost contact with who was doing what on the geoserver side.
groldan mike is eating, lets wait for him to get back and I can ask him for the rev number and do the tagging
jgarnett ie we wanted to try getting CITE tests to pass from a branch; and then we were going to release.
jgarnett cool; if someone can send me the -revision or create a tag; I can stumble through the release process today.
jgarnett (I would still like to confirm that this meets martin's needs?)
aaime jgarnett, we cannot pass cite due to a number of issues that require Justin attention
jgarnett I will release this as a 2.5-M3 then.
acuster it meets M's needs
aaime about the release of 1.6.5, I was going to do it, but Chris told me to delay it so...
jgarnett when you do get an idea let me know
aaime he said mid week next week thought
jgarnett hrm; should I bother to pass that on to the user list?
aaime so we could try to release 1.6.5 in a couple of days
aaime (I asked last week)
jgarnett so we should make a 2.4.x release this week then?
aaime jgarnett, you can, but there's no way I have time to fix more 2.4.x bugs
jgarnett Do you need anything for that ...
aaime apparently so
aaime nothing really
acuster GeoServer 1.7.0-beta2 (July 30, 2008) ..... This release is based on Geotools 2.5.x (revision 31101).
jgarnett thanks ...
CIA-35 groldan * r31127 /tags/2.5-M3/: tagging 2.5.x from rev #31101
groldan jgarnett: tagged http://svn.geotools.org/tags/2.5-M3 from 2.5.x at rev #31101
jgarnett oh darn ... I am in the same boat as everyone else
jgarnett I hate to "cry wolf" but we are at the stage of making press releases for uDig 1.1.0
jgarnett so chances are I need to make a 2.2.x release this week
jgarnett we have one remaining bug fix to sort out; charset support in shapefiles.
aaime which has been fixed in 2.4.x I believe
jgarnett It has; although doing some research I found that the DBF actually contains the info
aaime at least I rember making sure that GEoServer could display layers in
aaime norvegian, chinese and arab
aaime and that info can usually be trusted, right?
jgarnett yes; that was my first thought as well. The korean uDig developers already hardcoded their locale in; I am trying to actually fix the problem so they can use the uDig 1.1.0 release.
jgarnett well I don't know how many programs use the DBF correcty; so we can still keep our connection parameter as an override.
jgarnett but when i went looking I found a list of bug reports on the topic
jgarnett (users complaining that the DBF header settings were ignored)
aaime I see
jgarnett A couple more updates; Martin I was able to use the system properties to let uDig work with epsg-hsql.
aaime ah right, did you find where GeoServer sets its own?
jgarnett So hacking on referencing can return to a low priority for both of us ... not ideal but you may relax knowning I am not going to launch into the referencing codebase this week.
desruisseaux Thanks for the info Jody
jgarnett I did not find out; I had to look at the "Axis Issue" page I am not sure I got all the settings but it is enough to reduce the panic.
jgarnett It also points out that some of our Hints cannot be "global"
desruisseaux Yes, this is what Andrea said last week. I don't know why.
jgarnett Or at the very least referencing has some fun issues to sort out with respect to hints.
aaime jgarnett, for the record: http://svn.codehaus.org/geoserver/trunk/geoserver/web/src/main/java/org/geoserver/GeoserverInitStartupListener.java
aaime we tried to use hints only but it did not work so we had to go back to system properties
jgarnett Thanks Andrea; looks like I missed a few - that is the answer I was trying to ask these last couple weeks
aaime sorry, I noticed it once but it was too late, and then I forgot
groldan aaime: btw, that one does look like it should go in main, not in web?
aaime why, it's a startup listener
aaime web container dependedent
jgarnett martin I am pretty sure I know how to approach the bug hunt; but we can leave this until we are both more sane?
aaime you did not want filters in main, you want listeners now?
groldan thought it was spring dependent
aaime nope, that one has to be absoluted the very first thign that runs
aaime when spring starts up it's already too late
desruisseaux Jody, yes it would be fine to wait a bit. I will let peoples know when I will be back on referencing hacking?
jgarnett Eclesia how goes your SLD work? On uDig trunk we would love to write our Style pages using StyleVisitors etc today.
aaime those properties must be set before any crs is requested
jgarnett Since we are writing them anyways; if we had your patch applied on 2.6.x we would not have to rewrite them later.
Eclesia well with everything going around I was wiating a bit for the patch
jgarnett I thought of updating SLDParser (the DOM one) to be an SEParser
jgarnett but noticed that we do not have a GML3 DOM parser etc...
jgarnett so I figured that creating more along those lines would make me tired; and thought I should check in with what you were doing?
Eclesia I can send you the patch if that's what you mean ?
jgarnett Eclesia I am not interested in checking out a patch on volunteer time
jgarnett I am interested in working with you on trunk; but I don't know your timing.
Eclesia is lost
jgarnett I am just letting you know that the timing is pretty good from the uDig standpoing.
Eclesia on what do you want to work with me ?
jgarnett ie if you commit we will be able to give you timely feedback on the new style interfaces.
jgarnett we will be writing code using style visitor
jgarnett (rather than set methods)
jgarnett to update stuff.
Eclesia ok so if I apply the patch this week does that suit you ?
jgarnett We would like a couple days warning;
jgarnett but yes; we are on trunk in order to work with you on this
Eclesia when do you want me to apply it then ?
jgarnett we have a deliverable thursday
jgarnett so either early in the week (say today?)
jgarnett or thursday.
jgarnett I would not mind an overview of what your patch includes?
jgarnett I am assuming the getools style interfaces will extend the geoapi ones
Eclesia I cant today, but tomorrow I guess it's possible
jgarnett (I tried this myself and only ran into conflicts where ENUMS had been introduced)
Eclesia the patch makes the GT style interface extends the geoapi ones, and it fix the gt style implementations
Eclesia all methods (old ones and new ones) are still here
jgarnett Did you wade through all my email to geoapi on the subject. We seemed to only have a few areas left to talk about.
Eclesia but the streamingrenderer breaks a bit when It comes on FeatureTypeNames that where replaced from string to Name objects
Eclesia so there will be some fixes to do
jgarnett StreamingRenderer is easier to understand with the ResourceCollection stuff removed.
Eclesia so I apply tomorrow ?
Eclesia will you have time to fix before thrusday ?
jgarnett Eclesia we have a teams of developers working on turnk
jgarnett so you should not be applying broken code?
jgarnett do you need help getting something working?
Eclesia It's not broken, test failures
jgarnett (aside: Graphic.graphicalSymbols() is order dependent ie List)
Eclesia I cant fix the streaming renderer
jgarnett okay understood; so yeah send me an email before you commit and we can tag team that one.
jgarnett Is there a time when we are both working?
Eclesia for me it's at the end of the day
jgarnett okay so when you are ready please send an email; and set a time
Eclesia 17H to 18H
jgarnett I think that is it for the meeting time slot.
jgarnett Anything else or should I post the logs.
Eclesia jgarnett: a solution would be taht I send you the patch, and you can commit it when you think the streamingRenderer is fixed ?
Eclesia this way you can do it when you wish and we wont break the build
jgarnett I hear you
jgarnett I am weighing my volunteer time today vs you interecting with the geotools community in the normal manner.
jgarnett Is there another way to help you debug streaming renderer?
jgarnett And is your patch current; ie streaming renderer has changed over the last two weeks.
jgarnett nope I think you better set a time and commit
Eclesia I've been maitaining this patch for more then a month on my free time ...
jgarnett I don't want to set a precedent of accepting large patches; not when you have commit access.
jgarnett what I can do is help you clean up streaming renderer; and we do appoogize for taking so long to get 2.5.x out of the way ... thanks for maintaining the patch.
jgarnett So what time do you want to do this Eclesia; tomorrow?
Eclesia I cant do it know
Eclesia the patch is at work (I'm at home)
jgarnett How about tomorrow? You mentioned a time up above; but I have not figured out when that is for me
Eclesia meeting startes a 18H, so one hour before
acuster what time is it for you right now jody?
acuster its 19:42 here
acuster so 17:00 is 2:42 ago
Eclesia 17h to 18h is fine
jgarnett okay sounds great
jgarnett can you send an email; with that time slot; and the appropriate dire warning for people working on turnk.
jgarnett tunk - silly typo
jgarnett Is that okay?
jgarnett cool thanks for the meeting everyone.
- SE 1.1 and SLD 1.1 chat
- Wwhat is up
- 2.5.x branch
jgarnett desruisseuax ping? I was wondering if you had any thoughts about epsg-hsql use?
desruisseaux Hello Jody
desruisseaux I don't know why it doesn't find it. I was hopping to produce a dump of registered factories, but I'm unable to remember where is the program doing that.
desruisseaux We had a JIRA task for that with screenshot and usage instructions... I searched for it half-an-hour and didn't found it.
jgarnett I placed it in the geotools user guide
jgarnett I can make a dump of the factories for you.
jgarnett (and can send that on to email)
jgarnett however I think the design of the factory lookup / hints is incorrect.
jgarnett ie global hints are interferring with your ability to look up the epsg-hsql authority; so you never find it in order to wrap it ...
jgarnett here is the tool
jgarnett we should start the meeting?
jgarnett floor open to agenda topics...
jgarnett martin I am sad about the referencing stuff; I don't feel I have enough information to use up meeting time talking about it.
desruisseaux You have been much better than me for finding back the informations Jody . It was not far finally.
desruisseaux Could you send me a screenshot of the factories tree please? And also a list of all global hints
desruisseaux (there is a tools for dumping global hints as well - trying to remember...)
desruisseaux I think a copy and paste of System.out.println(GeoTools.getGlobalHints()) should be okay.
jgarnett okay I will take that to email (since I don't have enough information to talk about it during the meeting; you did get my earlier emails so you know that global hints are breaking the referencing module)
jgarnett I can make a bug report for that and we can track progress there.
jgarnett emily / Eclesia did you want to grab an agenda topic to talk about SLDParser and/or SE 1.1 ?
jgarnett I was also going to ask gabriel / dwins about the release train
Eclesia I still have no answer for SLD interface in geoapi so I can't really say
jgarnett dwins your code freeze email looked like it was held up in a moderation queue for a while? Hopefully you can clarify this meeting?
jgarnett I am not sure I understand "no answer for SLD interfaces" in geoapi? what do you mean ...
Eclesia For me it's first geoAPI then GeoTools
jgarnett well both have to happen at once; they feed into each other ... I did give you a very solid code review last week
jgarnett (using the geotools implementation to find questions about the geoapi interfaces)
- dwins doesn't remember sending an email that got held up in a moderation queue
jgarnett I was supposed to be monitoring the email list while gabriel was away; I let one of your email messages loose over the weekend
Eclesia (I'm just making the secretary work to build up the interfaces of OGC SLD in geoapi, I also have a look at GT sld class to see what could go wrong)
jgarnett okay I understand now; I just read your email on the geoapi list. Thus far you have done Symbology Encoding 1.1 I guess? And now you are looking at the SLD 1.1 interfaces?
Eclesia and they are done
jgarnett got it; so you have the SLD 1.1 interfaces available for geoapi; and you would like to commit them for review etc. That sounds okay; but I can reply to your email ...
jgarnett did you want to grab an agenda topic to talk about a) your plans for 2.6.x and b) SLDParser stuff with Emily?
Eclesia I just want to know if someone at refraction is going to make an SLD1.1 parser, I seen you work on styles and sld
jgarnett Eclesia we cannot make an SLD 1.1 parser until there is code (and a renderer to make use of it).
jgarnett We have no paid work in hand that requires SLD 1.1
jgarnett (indeed for udig we would probably just stick to the SE 1.1 work; SLD is more of interest to #geoserver developers
Eclesia ok so I dont any agenda item ^^
jgarnett that said we know the DOM based SLDParser
jgarnett and we need to know your plans for supporting SE 1.1 and SLD 1.1
jgarnett (ie this is planning; we don't do work you need for free; and we also don't start work without talking to you first ...)
Eclesia for SE1.1 GT is going to have a patch in 2.6.x
Eclesia and for SLD1.1 I still dont know what will be in GT
aaime GeoServer people has no sponsoring on using SE 1.1 and SLD 1.1 either, actually we don't implement any WMS standard that could use them
jgarnett well to put anything into geotools we got to keep the big picture in mind
jgarnett so someone better have plans for a parser
jgarnett (or we are not taking good care of the library)
jgarnett I do agree that SLD 1.1 is pretty useless...
jgarnett (note we have now talked about this so much we should of grabbed an agenda item)
jgarnett aaime does #geoserver have any plans for SE 1.1 or SLD 1.1 ?
Eclesia there's no t enormous difference with SLD1.0 now that we have SE1.1
aaime no one ever requested we support it
aaime and wms 1.1.1 is based on sld 1.0
jgarnett what is based on sld 1.1 ?
jgarnett WMS 1.3 or something?
aaime maybe wms 1.3, but I actually never seen that citation
jgarnett Eclesia I am interested in SE 1.1 for uDig.
jgarnett Based on review I don't think updating the SLDParser would be that bad
Eclesia streaming can handle Se1.1 ?
jgarnett so when you get there please talk to us and perhaps we can collaborate.
aaime of course not
aaime or can it?
jgarnett the SLDParser is dom based; the GTXML (ie streaming parser) only has binding for SLD 1.0.
Eclesia I dont now, perhaps just like me, there is a patch waiting somewhere ^^
jgarnett I think everyone has their cards on the table; SE 1.1 is new work.
aaime Eclesia, did you update SLDStyleFactory to handle the extra features se 1.1 has?
jgarnett and we either need enthusiasm (or a customer) to get it done.
Eclesia aaime: no
aaime also, classification functions should be supported directly in the renderer
aaime so it's quite fair to say streaming renderer does not support se 1.1
aaime and won't unless somee udig folk updates it in that direction
aaime or GeoServer gets some sponsoring to work on SLD 1.1/SE 1.1
jgarnett well I will start slow by making use of the classification functions (which can be represented in SLD 1.0)
jgarnett still it is good to see this stuff moving; perhaps we can go shopping for a sponsor on this topic.
jgarnett shall we move on ... with the agenda and meeting?
jgarnett 1) what is up
- aaime is fixing geoserver bugs for the 1.7.0-... rc1/beta2 (still haven't decided) release
- Eclesia JSorel : working on GeoAPI SLD
jgarnett jgarnett - despairing over epsg-hsql and wondering how geoserver manages to render anything (perhaps someone can help me after the meeting?)
- aaime is also mail drunk after reading 1100 mails in roughly one day
aaime jgarnett, GeoServer gave up using Hints because they don't work, we opened a jira issue and got back using System.setProperty
aaime ugly, but so far the only working solution
jgarnett thanks for the insight aaime; I am going to go freak out and break a lot of referencing in the process is my guess
simboss simboss - jpeg2000, jpip and python
tar1 tara - lurking
aaime (for jgarnett information)
aaime jdeolive, we're in the "what's up" phase of the gt2 meeting
aaime want to join?
- dwins having fun with wicket and fixing a gs bug or two
jgarnett moving on ...
jgarnett 2) 2.5.x branch
desruisseaux Andrea, could you remind me the JIRA issue please?
jgarnett dwins without gabriel here this one is mostly you ...
aaime desriusseaux, the jira issue it the one I pasted above
gdavis_ I wanted to get unsupported gt-wps and gt-process into this branch. dwins, how do I sort that out?
aaime it contains a small "main" that can be used to reproduce the issue
dwins as far as I know everything is in place
desruisseaux Oups! Thanls Andrea
dwins gdavis_: good question. i'm not sure of the geotools policy for changing the 'unsupported' status of a module
dwins jgarnett: care to enlighten us?
jgarnett gdavis knows this one; it amounts to a page of docs and 40% test coverage.
aaime jgarnett, that is to get the module to supported land
jgarnett desruisseaux can point you towards a report of coverage; not sure if it covers unsupported modules however?
aaime he wants to keep it in 2.5.x as unsuported no?
jgarnett good question - gdavis what is your intention?
gdavis_ desruisseaux, how do I get test coverage of my unsupported modules?
aaime afaik the branching process will just keep it around, unless someone removes it manually
gdavis_ well are unsupported modules going to be in the 2.5 branch?
jgarnett well I want us to remove a lot of the unsupported modules; at the very least anything without a review.apt file...
jgarnett but stronger than that ... anything geoserver is not going to use.
gdavis_ review.txt file you mean?
aaime nope, apt
aaime (almost plain text)
gdavis_ well we have the wps geoserver module as well, which we'd like to get in 1.7
jgarnett gdavis_ they changed it in order to generate a "maven site"; no idea what apt stands for - looks similar to a wiki format.
gdavis_ i havent updated GT in a few days, was that a recent change? All mine still seem to say review.txt
desruisseaux About coverage: I do not yet have a coverage report for unsupported module. We had difficulty getting clover to run on GT trunk. We tried cobertura instead in a repository containing simplified pom.xml, but it doesn't cover unsupported modules yet.
gdavis_ so how does an unsupported module get test coverage in order to become supported then?
aaime so jgarnett, this is your idea, to remove unsupporetd modules from 2.5.x... it's the first time I hear about that
jgarnett aaime I have talked about this from the definition of the unsupported module idea / we are only hosting stuff to help get new developers. The actual library is defined by what meets our QA and Doc requirements.
jgarnett Every other time we talk about this you mention unsupported/oracle and assume I am losing my mind.
jgarnett (ie nobody supports oracle; but we need it; so jody must not be serious about removing unsupported modules from the release train)
aaime gdavis_, go to your module and type "mvn cobertura:cobertura"
aaime jgarnett, more or less correct, and how do we get out of that impasse?
jgarnett I think we start by removing everything geoserver is not using.
aaime I mean, we're talking about library procedures here
jgarnett and move the stuff we are using into the library.
jgarnett (by meeting the doc and testing requirements)
gdavis_ ok, what does this do?
aaime jgarnett, but oracle has no maintainer, so it cannot get into the library
aaime gdavis_, it generates a report, look into target/site
jgarnett well andrea we may be at a cross roads of either a) asking a sponsor to support a maintainer for oracle (refractions has at least one interested - but it will take dropping oracle from geoserver to show this is a serious requirement)
jgarnett b) recognizing that once something is in the library the community takes responsibility for keeping it going
jgarnett (at which point 40% test coverage and a page of docs looks like too small a bar to jump over)
jgarnett oracle is in limbo right now - no questions about that.
aaime we're going into a direction where I cannot talk about the issue intellligently. It involves providing resource, and I'm not the one controlling them
aaime cholmes can say if TOPP is going to maintain Oracle or not, and if it's ok to drop it completely, I cannot
jgarnett does the idea of removing unsupported modules that are not used by geoserver seem like a good compromise?
aaime sort of... I mean, what about modules used by udig but not geoserver?
jgarnett ie it has no effect on your release; and it provides insentive for people to finish their module.
jgarnett same deal
jgarnett if udig is keeping something in the build (like say the graph module)
jgarnett we can make sure it is passing tests on the branch.
jgarnett but udig is not following you on the 2.5.x branch (we could not get our feature event work done in time and referencing did not meet our requirements)
jgarnett so the 2.5.x branch is mostly about you
CIA-35 gdavis * r31086 /trunk/modules/unsupported/wps/src/test/java/org/geotools/data/wps/ (OnlineWPSFactoryTest.java OnlineWPSManualRequestTest.java): Turning online tests on for covertura
CIA-35 gdavis * r31087 /trunk/modules/unsupported/wps/src/test/java/org/geotools/data/wps/ (OnlineWPSFactoryTest.java OnlineWPSManualRequestTest.java): Turning online tests back off.
aaime well ok, I'm not exactly happy about this, but I don't see alternate routes
jgarnett andrea what is there not to be happy about? You don't need widgets-swing-pending do you?
jgarnett (this is just a question - I am not sure if I understand your concern)
aaime I'm not exactly happy that modules do appear and disappear from the library depending on which project uses the branch
gdavis_ these reports all show 0% when I know that can't be true....
jgarnett you are correct; I am not happy that modules that projects depend on are not meeting our very low QA bar; I figure that is irresponsible ...
jgarnett but the same token I don't want to advertise modules that we know are in flux (ie the definition of an unsupported module)
jgarnett unsupported is only there to bootstrap quick development; the library slurps up the good ideas (and hopefully grows our developer community in the process)
aaime it still seems me we should advertise this on the users community before pulling the plug
jgarnett Perhaps we should return to the details of making a release this week ... I am sorry the handling of unsupported was a surprise Andrea.
aaime it's quite rushed for a branch that we should do this week
jgarnett okay I can do that; ask them what they think.
aaime like for example Camp2Camp is using MIF, we just pissed them off enough with the licensing questions that they stopped mailing us
aaime (questions -> requirements)
jgarnett andrea I would settle for deploying to maven but not making it part of the download. See the language on this page for my intension with unsupported modules: http://docs.codehaus.org/display/GEOTDOC/16+Unsupported
aaime I would like to make a separate zip instead
jgarnett aaime++ that would work.
gdavis_ so, can process and wps still reach supported status for this release?
aaime so that peopole can still use them, but would understand they should get they act togheter and support themselves
aaime gdavis_, dunno, I tried cobertura on various modules and the coverage I get is not 0
aaime you can also try out with the cobertura eclipse plugin, you might have better luck
gdavis_ INFO test
gdavis_ INFO Tests are skipped.
gdavis_ it says this
aaime gdavis_, can we talk about this later?
gdavis_ I guess so
aaime it's problem solving, not something we should do during a meeting
aaime especially since it's supposed to end in 7 minutes
aaime jgarnett, anything else that is holding up the 2.5.x branch?
aaime (I was actually quite surprised by the rush of last minute api change proposals and actions, feature collection, feature id...this kind of stuff should be hanlded at the beginning on a development cycle, not at the end)
simboss aaime: I have something to say about the 2.5.x branch
jgarnett aaime I was surprised as well; a lot of this work was started and nto completed
jgarnett aaime I also did not do the deprecation cycle this release.
aaime feature collection and feature id are weren't started at all
jgarnett you know when we go through 2.4.x and remove deprecated methods.
jgarnett feature collection was started as part of the feature model change over; but it lost momentum.
jgarnett In trying to use this in a training environment I figured I could not stand to let it out the door with so many half finished ideas; I hope you don't mind.
aaime I've only seen proposal drafts for Justin, no coding was started
aaime I did not notice any significant change before your work of last week
aaime I do mind when these things are done last minute, since we're touching some fundamental class
aaime that would be better modified when a new trunk starts being worked on
jgarnett I kind of thought justin would get to it before release.
aaime how could you think that, we did not even vote the proposal??
jgarnett And I was hoping to do the featureid work with you but did not figure it out in time before you left on vacation.
aaime that one fell on me like a surprise as well, it's another major change that should not occur right before branching
jgarnett I could think that because we focused on the change over to simple feature during September; and we did the bare minimum to make the change. Other things that we knew were wrong (like featurecollection being a feature) were not attempted at that time.
jgarnett I have been talking to gabriel about the FeatureId handling as part of the feature event work for months; but perhaps because it was feature events it was not visible as a concern?
aaime jgarnett, I'm not questioning the goodness of the changes
aaime I'm questioning the timing
jgarnett But I agree too much was done last minuet; and too much was done by me at the last minuet.
jgarnett I don't know if I should of been more strict months ago or what.
jgarnett however I do like the result.
CIA-35 gdavis * r31088 /trunk/modules/unsupported/wps/src/main/java/org/geotools/data/ (4 files in 4 dirs): Adding package infos for these packages.
aaime so, let's recap a bit
aaime how are we setup for the 2.5.x branching?
aaime what still needs to be done?
jgarnett we await a decision from dwins / gabriel
jgarnett then we tag
jgarnett we have to rollback referencing
jgarnett and I want to review the user guide and bundle it up for download.
jgarnett (we also need to tag a geoapi milestone but we can limit that to a maven deploy)
aaime ha great, we tested geoserver for months with the current referencing and now we roll back... this 1.7.x relelase will be a damned one I guess...
jgarnett well we can ask martin
jgarnett but he did not get to the work right now?
jgarnett I think all that happens aaime is we remove my classes (that are still not hooked up)
aaime ah, not hooked up you say... so we haven't been using them at all
simboss guys I have two minor fixes for imagemosaic, I have made tests run for both geoserver and geotools successfully; question is can I commit?
aaime simboss, sure you can
jgarnett the work I did for so long has not been hooked up yet because I cannot pass one test case about looking up an existing identifier.
jgarnett so rolling back (or deleting these classes) should not be too stressful.
aaime I guess it will just be deleting the classes, since desriusseaux has been making changes/fixes to referencing on trunk afaik
jgarnett I think martin said he could help on that side; he feels bad about not getting time to work on referencing.
jgarnett and leaving me hanging.
CIA-35 simboss * r31089 /trunk/modules/plugin/ (4 files in 2 dirs):
CIA-35 - releaseing resource for ImageMoisacReader
CIA-35 - using some good old suppressWarnings tag
aaime ok, and we need to change the release scripts to create a separate zip for the unsupported modules... something I never managed to figure out how to do
- Eclesia can wait 2 more weeks if it helps
jgarnett Eclesia I don't think it will help; only thing we should do that we are not is removing deprecated methods.
aaime jgarnett, that is going to be a big one, and not possible at all in various cases
aaime think filters
aaime you simply cannot remove the deprecated filters
jgarnett I know
aaime there is still code using them
jgarnett (it is one of the things listed on technical debt on the 2.5.x page)
jgarnett but I suspect there is some work we could do; but it was not as important as making our Java 5 transition and getting our Feature / FeatureCollection story straight.
aaime ok, who does what and when?
jgarnett dwins / gabriel was going to make the branch today
jgarnett I was going to review the user guide pages
jgarnett I think martin was going to rollback the referencing module?
jgarnett I was going to help gabriel by running deploy from here.
aaime I haven't seen groldan around today
dwins and I don't have write access to the repository
jgarnett dwins was mostly organizing; gabriel just had the ability to do the work.
jgarnett I was hoping for code freeze / branch / unfreeze and then starting up the release process from the branch; releasing when CITE tests pass?
aaime thought if the FeatureId change is still in the air, we cannot release gt2 2.5-rc
jgarnett can we wrap up the meeting; and leave the IRC log open for collaboration on the 2.5.x release ...
- aaime is at the end of his working day almost right now
jgarnett if gdavis and simboss are happy we could branch 2.5.x fairly quickly. And worry about making the release from the branch tomorrow ...
simboss I just committed
simboss so yeah
simboss I just tested
aaime so we give up with FeatureId related changes?
simboss that the fix
simboss for the coverage bandselect problem
aaime (that's an API and GeoAPI change)
simboss and it worked indeed
dwins simboss: thanks a lot
aaime simboss, thanks
jgarnett FeatureID changes were done on the weekend Andrea; they went well.
jgarnett or actually late last week.
jgarnett I talked with gabriel after you left; and Justin.
aaime I did not even notice
aaime any page documenting how things are working vs pending ids?
jgarnett the FeatureEvent page
jgarnett but now you have the option of getting the FeatureIds from the features
jgarnett rather than only from events.
simboss dwins, aaime: If I were you I would double check anyway
aaime what about featureStore.add(..)?
jgarnett dwins made the change on the geoserver side.
jgarnett now returns a List<FeatureId>
jgarnett so you can build up your list ...
aaime and they do change after commit occurs?
aaime I see
*--| tar1 has left #geotools
aaime any way to know the feature id is "transient"?
aaime (pending, whatever)
jgarnett but that is only as good as the datastore implementation as per usual.
jgarnett no there is not
aaime I see
aaime could have been useful
jgarnett you could add that to the FeatureIdImpl if you want; I would like to see some experimentation on that side.
jgarnett note versioned postgis was the only thing
jgarnett to want to set the feature id more than once.
jgarnett I wanted to ask you why that was ...
aaime I don't know
aaime I coded that datastore more than one year ago
aaime I simply do not remember why
jgarnett I suspect it is so you can include "feature id" and "version" as part of the Identifier?
jgarnett but dwins only found tests that failed in #geoserver so I could not verify.
aaime it probably has something to do with the intricacies of having a feature id mapping between an inner and an external view
aaime jgarnett, externally the id stays the same
dwins it looks like you generate a temporary id immediately after getting the feature from the writer
aaime version is not part of the feature id the users sees, but internally yes, it's part of the id
dwins and then I guess you do something with it to generate a final id for versioning
aaime I see.. don't know, I would need to check the code
jgarnett okay so perhaps a change of api class can do it .. generate the "fid"; use it to construct the FeatureId; and then you can still set it once when you have your final value...
jgarnett (I just had a check to freak out if a FeatureId was being changed multiple times; and we had to turn it off for your module)
aaime so now it's not part of the build?
aaime you should have sent me a mail saying so?
jgarnett I did?
aaime I did not see it
aaime (mind, 1100 mails dropped in my mail client yesterday)
jgarnett (gasp I may of been evil like dwins and just had a conversation on IRC and not sense an email... the horror)
aaime I've only seen this, but could not make any sense of it: http://jira.codehaus.org/browse/GEOT-1934
CIA-35 simboss * r31090 /trunk/modules/unsupported/coveragetools/src/main/java/org/geotools/utils/imagepyramid/PyramidLayerBuilder.java: -minor fix as directed by Thomas Lutz
aaime also the jira says it's fixed, if so, the module should be brought back into the build
jgarnett that is true; it was done after the change.
jgarnett it never left the build; it was always passing its geotools test cases.
jgarnett you are correct andrea; I sent email and closed bugs on the geoapi list.
jgarnett I will correct that now.
aaime dwins, jgarnett, I have to go in a few minutes and I still have some pending commits
aaime can you send me a mail telling me if I should a) branch b) run the cite tests?
1) what is up
2) follow up OSGeo
jgarnett I just remembered the new meeting time
jgarnett (hard to both deal with monday morning questions; and attend a meeting .. sorry for being late)
desruisseaux No worry, nothing started
jgarnett okay sending email to the list now
desruisseaux I don't have any agenda topic for today...
jgarnett I noticed unsupported/go was removed?
jgarnett Is this a formal cancellation of the go-1 project?
jgarnett well we have some follow up to do from last week
desruisseaux No it is not a cancelation
jgarnett Martin should I be doing something on this end? I feel like communication on has been poor recently?
desruisseaux I'm don't know if the issue is communication
desruisseaux This is true that we are not communicating as much as we could
desruisseaux And some of our comunication may be poor
desruisseaux When I have a strong opinion on a topic, I look like close minded
desruisseaux But while the community see the weakness as a communication issue from geomatys, on our side we are worried by the entropy of managing many project around the geotools code base.
jgarnett the entropy?
simboss I would add a question about gridrange/gridenvelope to the topic list
jgarnett martin my thought is that we have these procedures and the PMC to account for the entropy.
jgarnett ie If a project wants to take part it can provide volunteers to geotools to handle the communication burden.
jgarnett martin I don't mind you appearing closed minded; indeed I value a good discussion with you - it results in high quality software (and we both learn from the discussion)
jgarnett I can think of a dozen examples
jgarnett My only concern is when people arrive "too late" to discuss stuff; ie when they actually have no time - and I think we try to be understanding about that.
jgarnett Is that what you meant by entropy?
desruisseaux I was thinking something a bit different
desruisseaux We started to cleanup metadata
desruisseaux fixing javadoc, splitting utilities methods in their own "utility" module
desruisseaux No design changes at this time
desruisseaux Then I have it Justin's converter classes in org.geotools.util
desruisseaux (typo: I have hit)
desruisseaux Those classes duplicates org.geotools.resources.ClassChanger, but Justin framework is more elaborated.
jgarnett I have not heard of class changer; I considered it a duplicate of the apache bean utils.
desruisseaux Nevertheless we have a duplication, so I wanted to retrofit the old ClassChanger functionality in Justin converters
jgarnett sounds great; I appologize if we knew about ClassChanger at the time we would of used it.
desruisseaux This kind of duplication is kind of the entropy I'm talking about
desruisseaux No it is not an issue - I do not expect peoples to known every bit that everyone write
jgarnett This was just before the change proposal process; do you think a change proposal (to introduce Converters) would of been enough
desruisseaux So it was part of entropy. Other part is that Justin converter were wrote in main module instead than metadata, but both defines classes in the same package (org.geotools.util)
jgarnett that we could avoid the duplication?
desruisseaux No I don't think that a proposal would have helped much (more on it later)
jgarnett (thinking of this as a) technical thing to fix b) a process thing we could think about)
jgarnett okay keep going; I will shut up
desruisseaux So entropy = duplication, service duplicated in many module (in this case "utility" splitted between metadata and main; and furthermore "metadata" is probably a bad place for "utility")
desruisseaux Also implementation thats look like "brute force" (looping over every converter until one is found that doesn't returns null and doesn't throw exception)
desruisseaux I understand that a lot of things in GeoTools have been developped under time constraint.
desruisseaux This is where I think that the proposal process doesn't help a lot, because we often don't have the time to look at them carefully.
desruisseaux We end up trusting the guy who proposed it, and only later we realize that we could have fighted more against entropy.
jgarnett so far we average one proposal a month; and have two weeks to respond.
jgarnett I am trying to be "brutal" in getting people to document what they are doing in the proposal; so it takes less time for everyone to review.
jgarnett but I agree duplication is bad; proposal process may not catch everything.
jgarnett stronger measures (like code reviews) would take even more time.
jgarnett Is having a two week chance to review a proposal "good enough" for you martin?
desruisseaux It is not only duplication; when I look at a code written by someone else, I often see stuff that I doesn't make me happy ("brute force" algorithms, eating exception in try .. catch ... log, bad usage of J2SE API...). It may be because I'm too maniac, but it make me worry
jgarnett martin: I agree - when out of time I tend to work on trust; I have stopped doing that in the last year and am "up front" when I am out of time and vote +0
jgarnett see this is why I like working with you; your worry is valuable to everyone
jgarnett is there any way we can address the kind of issues you mention above?
desruisseaux But this is where I came to an idea which I'm afraid would not be acceptable to the community
jgarnett I personally go in and fix stuff; and send email to the module maintainer as I go.
jgarnett but it is to little to be effective.
jgarnett I would rather set "find bugz" and use it to inpersonally catch mistakes like these. It works well for udig.
desruisseaux I got the feeling that GeoTools needs a "benevolant dictactor" in the way Linus is for Linux. I know that it is a radical point of view, but I have the feeling that the survival of the project as the "project of my dream" would need that.
desruisseaux But peoples can not be blocked because I dictator is too slow, or disagree, etc.
desruisseaux So this is clearly unacceptable on a centralized SVN.
desruisseaux But on a distributed system...?
jgarnett Hrm; I don't mind taking the roll.
jgarnett I am trying to work hard on geotools because it needs it.
desruisseaux If peoples are unhappy about a dictator on a given system, then can switch to an other distributed system managed in a different way.
jgarnett but I was going to take stock of what was needed for GeoTools 3; a dictator may be a good idea.
jgarnett not sure that works as a dictator; that is a democracy
jgarnett and personally I don't always trust the will of the masses on code decisions.
desruisseaux Thats my current though
jgarnett let us put it in the list for GeoTools 3
jgarnett now with OSGeo graduation out of the way
acuster dcvs solves the same problem in a more elegant way
jgarnett I promissed I would start taking action on those ideas.
jgarnett how so acuster
acuster everyone is dictoator over their repo
acuster they can decide what goes in
acuster the cost is everyone has to decide what goes it
acuster goes in
jgarnett (BTW acuster I had some usless naming questions for you - which would be very valuable for me; and prevent your annoyance in the future)
acuster which is why there are so many branches of linux
jgarnett I am not sure that this is an efficient approach; but yeah I get the idea.
acuster jgarnett, yes, on my todo list, you need answers today?
desruisseaux I'm done. I suggest to move on next IRC topic.
jgarnett acuster - if possible. I just want some words (we can chat on #udig)
jgarnett okay ... thanks for the chat guys
jgarnett 1) what is up
jgarnett jgarnett - trying to make sure the feature collection change did not break geoserver - dwins seems to have it all in hand. Working on bundling up a JRE+ImageIO-ext for udig development community. Juggling work responsibilities with open source commitments.
acuster acuster---iso19107 is messier than they would have you believe: I now have a working understanding of how geographic curves are expected to behave
acuster (well, that's a lie but a first approximation)
Eclesia hasck in puzzle-gis, and playing with JaxB
desruisseaux Martin: code review
simboss simone: ebrim
jgarnett acuster there was a good question on the JTS list as someone runs into some of the same questions (something about splitting a curve into a multi curve)
jgarnett oh; lucky simboss
jgarnett anyone else?
acuster yeah, that's in my inbox as a todo
jgarnett 2) follow up to OSGeo graduation
jgarnett It looks like we were successful; no official announcement yet.
jgarnett we have a couple blocker issues about license management to close up before the 2.5.x release.
jgarnett Firstly thanks so much for all the crazy hard work on this stuff.
jgarnett It has been long, brutal, and so on.
desruisseaux Thanks Jody, you worked hard on that too
jgarnett Hopefully over the next year we can benefit from this relationship on the "product" side of things; it sounds like we make do a few infrastructure things first (maven repository? etc...)
desruisseaux (the other one being Adrian)
jgarnett well thanks for keeping me sane. I know without acuster I would of slowed down on this stuff.
jgarnett Last week I was nominated as osgeo representative; as such I may get a few official questions
jgarnett I will punt each one of these to the geotools admin list; unless they are really really easy.
jgarnett And if you guys have questions about OSGeo; or if we have stuff we want to get done
jgarnett I can try and hunt down the right people.
jgarnett Does anyone have ideas for this week? Or can we relax for a bit and take this to email..
desruisseaux I have no additional item
jgarnett 3) gridrange/ gridenvelope
jgarnett simboss the floor is yours.
simboss thought/question for martin
simboss about the difference
simboss between what geotools does
simboss and what JAI does
simboss when cropping images
desruisseaux I saw email about cropping, but didn't investigated them.
simboss I have been sparing some time today to think about it
simboss even because I notice a while ago
simboss that you pushed the use of mosaic inside
simboss the resampler
simboss but that's another story....
desruisseaux It is not a real mosaic
desruisseaux It doesn't take more than one image
simboss mosaic operator
desruisseaux Yes I know, but mosaic operator with a single image
desruisseaux (so it is not a real mosaic)
simboss I know
desruisseaux The mosaic operator handle the border outside the image in a special way
simboss if you ever looked at the crop operation
simboss I used it to crop rotated raster
desruisseaux This is the border handling that was interresting me, not the mosaic per se
simboss that is why I mention that
desruisseaux (sorry, lets continue on crop)
simboss but anyway if I crop an image
simboss with the JAI crop
simboss I always get the smallest rectangle that contains the requested area
simboss the behvaiour in geotools is slightly ifferent
simboss and can cause illegalargument exception
simboss if you try to cut a very small portion out of a coverage
simboss I think I managed to reproduce the same thing for resample as well
hudson geoserver-1.7.x build fixed (http://gridlock.openplans.org:8080/hudson/job/geoserver-1.7.x/54/)
simboss I think I could fix that for the Crop operation
simboss but I would like to have consistency with resample
simboss because probably sooner or later we could merge the two things into one, probably with a simplified interface for crop, reproject, resample, etc...
simboss now the question is
simboss have you ever run into such a case?
simboss final annotation
simboss the sources of problems are 2
simboss generalgrid range roundings and usage of imagelayout
desruisseaux I don't remember having seen that, but if you have a test case reproducing the issue that would be very appreciated.
simboss well, the idea is simple
simboss I get an envelope
simboss which is smaller than a unit in world coordinate
simboss I go back to raster coordinate
simboss w and h
simboss will be between 0 and 1
simboss if I ever use imagelayou
simboss or the gridrange constructor
simboss you'll get w and/or h as 0
simboss you might
simboss I think in this cases it would be better to have a behavior similar to the JAI behaviour
desruisseaux If the fix is just ensuring that width and height are always equals and greater than 1, I'm in favor of that.
jgarnett (back: was grabbed for a conversation)
desruisseaux Or do you think something more elaborated is needed?
simboss I still have to think a little bit about it, I'll try to capture thoughts in an email
simboss on a side
simboss I think we need to ensure
simboss that when we crop a coverage
simboss we always return something
simboss even if that something is bigger than the requested area
simboss e.g. 1X1 raster
simboss on the other side
simboss the generalgridrange constructor
simboss states the opposite
simboss if you recall it
simboss (hello? )
desruisseaux (I need to look back what GeneralGridRange constructor said)
simboss so we might need to change that as well
simboss anyway, i'll wrap that in an email
simboss since it might require some thinking
simboss I am done
desruisseaux Nothing more on my side...
jgarnett okay thanks guys
jgarnett I can post the logs.
simboss right on time
- what is up
- OSGeo Representative
- GeoTools 3.3
- SoC Status Reports
- jgarnett nominated as OSGeo representative
jgarnett: okay time to go
jgarnett: aaime it is now time right? So we can get you for 15 mins ...
jgarnett: Good morning Martin; anything for the meeting?
aaime: for 13 minutes actually
desruisseaux: Hello Jody and all
jgarnett: I assume we are going to miss a few people with the new meeting time and all ...
jgarnett: so let us start
jgarnett: 0) what is up
aaime is working on speeding up the KML superoverlay code in GeoServer
jgarnett - udig now renderers; trying to review what is needed for 2.5.0; and generally happy it is summer
Eclesia1: hi al
jgarnett: Morning all ... topic 0) has already started; you know the drill - single line saying what you are up to. If anyone is up to something interesting you can chat with them on email.
jgarnett: 1) OSGeo Representative
jgarnett: Okay FrankW asked me today about our current osgeo representative form the PSC
Eclesia1 ahs prepared the style upgrade for 2.6.x, but has 4 last test failure in some stremaing renderer tests, but the code has no comment and is ... strange, so i cant fix those
desruisseaux: Martin: various task (cleaning, a bit of coverage work, etc)
jgarnett: moving on ...
jgarnett: I started out in this roll but burned out - I think acuster took over. Can you confirm Martin?
jgarnett: (I am searching the email archive)
desruisseaux: You means for the PSC representative?
FrankW: Note, the OSGeo reprsentative is normally the PSC chair.
FrankW: Do you guys have a chair?
jgarnett: looks like cholmes has volunteered.
FrankW: This will be the person named VP, GeoTools and expected to speak on behalf of the project, and answer on it's behalf.
jgarnett: We have a project management committee
aaime: we had one eons ago, but we don't really have a chair anymore in our PSC
jgarnett: we had James as our tie breaker.
jgarnett: Email record shows chomes as our representative after me; Dec 12 2006.
desruisseaux: There is Ian Turton as the historical creator of the project (together with James)
aaime: I hardly believe he has time
jgarnett: - http://email@example.com/msg05935.html
jgarnett: Indeed he later stepped down from the PMC did he not?
aaime: he did
desruisseaux: I don't know.
jgarnett: okay I will volunteer for this one
aaime: so we're chair-less
desruisseaux: +1 for Jody
jgarnett: well this is more a representative to the OSgeo foundation; so not exactly a chair.
FrankW: I believe Chris was the incubation rep.
FrankW: This isn't the same thing - or at least it does not need to be.
FrankW: I would think the VP GeoTools should at least be on the PMC!
FrankW: The rep is traditionally the chair though it is not strictly necessary.
jgarnett: oh I see ...
FrankW: From what I've seen, I think jgarnett is the logical choice if he is willing.
jgarnett: Okay - so I will need to write this down on the inncubation page I guess Frank?
jgarnett: And will put it in our developer guide as well.
FrankW: It doesn't have to be on the incubation page.
FrankW: But I do think you could note it in your PMC docs.
jgarnett: So my role for this will be communication monkey
jgarnett: rather than code monkey.
FrankW: It would be best if jgarnett was put in this role by a vote of the PMC.
aaime: here is my vote
aaime: and now I really have to run away
jgarnett: aaime can you make the motion.
aaime: vote for jgarnett to be osgeo representative
aaime is now known as aaime|away
jgarnett: +0 (since I am being nominated)
jgarnett: simone and jdeolive are on holiday
lreed firstname.lastname@example.org entered the room.
desruisseaux: I don't think they would object.
jgarnett: Ian T is MIA (the joys of academic life may be too much for him)
jgarnett: I will send an email out; Frank this can be offical as the votes come back in.
FrankW: OK, thanks folks!
FrankW: jgarnett: I'll assume it will be ok, unless I hear otherwise. Use whatever your process calls for.
desruisseaux: Are we done with topic 1?
Eclesia1: (+1 for jody ^^ )
jgarnett: well I should of probably voted +1 so you could of gotten an answer right now; but we can wait a few days.
(9:48:32 jgarnett: 2) GeoTools 3
desruisseaux: Thats mine
jgarnett: martin the floor is yours; personally I like the range of ideas expressed thus far - I think we have lots to work with.
desruisseaux: We would like a GeoTools with some cleaning in it. Adrian proposed the "geotidy" name.
desruisseaux: (as a code name; could be GeoTools 3 or something else as people wish)
desruisseaux: We can not really continue very long to work on GeoTools 2.
jgarnett: I would also like the same thing
jgarnett: but I think we need to negotiate a bit on what tidy means
desruisseaux: Moving on distributed versionning system make easier to express a wider range of opinions.
desruisseaux: It also reduce the pressure to commit unfinished stuff.
jgarnett: martin we need to get some documentation on the distributed version control thing
jgarnett: we have some contributors that really need this.
jgarnett: (I have tried asking for a couple of weeks; can you write down even some quick notes to help them get started)
jgarnett: (I can make that a seperate agenda topic if you like)
desruisseaux: There is on-line tutorial on Mercurial
desruisseaux: How they will applied exactly to GeoTools is to be determined
desruisseaux: since we are still setting up what may be GeoTools 3.
desruisseaux: Peoples can start with that: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial
jgarnett: So martin one of the things I want to emphaise here is communication; we had a hard time communicating with Simone when he was on a branch for a year. I am hard pressed to see how distributed version control is going to help matters stay on track; it is very attractive for groups of developers to go off on branches in order to make some tight deadlines - and then expensive to merge back in; go through the community process of collaboration and all that.
jgarnett: So I think that setting up a few policies
jgarnett: around the use of mercurial
jgarnett: is a great place to start.
jgarnett: Does that make sense; we have some great ideas on what geotools 3 can be.
jgarnett: And some wonderful opperunities based on the new work your organization; and several other organizations are getting involved in.
jgarnett: I want to make sure we are prepaired
jgarnett: before we open up GeoTools 3 for hacking.
CIA-32: jezekjan * r31012 /trunk/spike/jan/gsoc-transformations/src/main/java/org/geotools/referencing/operation/builder/GridParameters.java: Spike/Jan - Bug with negative array fixed
jgarnett: I have said I was prepaired to scope this out after OSGeo graduation; and thanks to some heroic efforts on acusters part we are now there
jgarnett has changed the topic to: 0) what is up 1) OSGeo Representative 2) GeoTools 3 3) SoC Stauts Reports
jgarnett: So what would you like to do martin? When can we start this discussion
jgarnett: is it something to handle at the PMC level?
jgarnett: Or should we as a responsible PMC consult the various organizations that fund our work? Refractions, GeoMatys, Open Planning Project etc...
desruisseaux: We could start the work and put a repository on-line on a geomatys server, so peoples can take a look if they wish.
jgarnett: I am not sure that would help Martin
jgarnett: part of the thing here is that we have a credibility crises here for GeoMatys
jgarnett: in terms of communication and control
jgarnett: still open development here would be good;
jgarnett: anything we can do to communicate your priorities; and what is happening with GeoAPI and so on would be excellent.
jgarnett: But perhaps I am thinking from another angle from you?
jgarnett: For me there is no repository yet; there is no GeoToold 3 project yet.
jgarnett: I need to get a "mandate" (something we can all believe in)
jgarnett: and then search for the correct venue; timeline; etc...
jgarnett: I am starting to entertain svn on osgeo hardware; and distributed version control to allow teams to work together (rather than branches)
jgarnett: but I need us to tell a better story then we did for GeoTools 2; both in terms of allowing teams to work together
jgarnett: and in terms of common goals.
desruisseaux: I would like to express the reasons why we are heading in the direction of GeoTools 3
jgarnett: I think we did a lot of that on email; the good news was that we all have similar motivations and similar scope.
desruisseaux: When I joined the GeoTools project 5 years ago, I was dreaming of a library
desruisseaux: I was hopping to build the best open source geographic toolsbox around (at least in the java world)
desruisseaux: As the years goes one, GeoTools became more like a bazar
desruisseaux: Patches submitted under time constraints
desruisseaux: While I come from a world where we try to think in longer terms
desruisseaux: (sciences vs business)
desruisseaux: Adrian and myself had strong disagreement with other member in this community
desruisseaux: But I stands with Adrian on most points. He have a quality that I appreciate a lot, which is sadly very uncommon in this community: rigor
iant_ email@example.com entered the room.
desruisseaux: The fact that Adrian and myself are the only ones with a scientific background my be part of an explication why we are having a hard time to be in agreement with the business view.
jgarnett: Martin I also have a long term plan in terms of API; usefulness and community.
desruisseaux: I was hopping a library released on a "when ready" policy; but in practice it is developped on a "when the client want it" or "when geoserver want a release" policy.
jgarnett: Now we each have different capabilities in terms of funding this dream; so far I am only able to get small chunks of time/money and as such have not been able to do all I have wanted on each day.
jgarnett: The stratagy for GeoTools 2
jgarnett: has been to build it because it is needed
jgarnett: once we have a working implementation
jgarnett: back it on to formal geoapi interfaces
jgarnett: as they are made available.
jgarnett: We are always caught in the conflct because GeoTools is a library used to develope
jgarnett: the standards as well as to implement them when they are published.
jgarnett: So I like this cycle.
jgarnett: However GeoAPI side lost some steam; so one of the things I would like to see for GeoTools 3 is a swift kick to get the GeoAPI project moving?
jgarnett: Does that make sense? I think it is compatible with both your goals; your companies goals; and the need to ship a useful library all the time.
desruisseaux: I was wondering if GeoAPI could be the glue between GeoTools 2 and GeoTools 3 (making easier to switch to geotools 3), with the side effect of increasing his credibility?
jgarnett: In short I find I need both sides (sciences and business) to have a library that is both correct (yeah siences) and timely (yeah business).
jgarnett: that is a good idea; migration stratagy is to use GeoAPI interfaces.
jgarnett: that has a lot of upside.
desruisseaux: I agree that there is both world (sciences and busincess) to conciliate
jgarnett: Now for GeoTools 2 we had a mandate - implement GeoAPI interfaces as they became available.
jgarnett: We did not quite get buy in for that mandiate all around; as an example (just like for documentation) there was not always budget to formally define a GeoAPI interface
jgarnett: for each deadline.
jgarnett: I think that is actaully really good.
jgarnett: because frankly a correct GeoAPI
jgarnett: that does not have a couple of implementations (and thus represent a compromise)
jgarnett: is pretty silly or not credible to me.
jgarnett: I am not sure how you feel about that?
desruisseaux: I believe that there is 2 things we need to do in order to get more GeoAPI implementations:
Eclesia1 is now known as Eclesia
desruisseaux: 1) make it alive as an OGC working group (a way to do "marketing")
desruisseaux: 2) Creates a test suite for GeoAPI implementation, which would give a clearer benefit for implementors to use this project.
desruisseaux: #2 implies moving some Geotools tests to GeoAPI.
jgarnett: yes to both counts
desruisseaux: Adrian is already preparing that for geometries.
jgarnett: the test case code should be either LGPL or Public Domain
jgarnett: (for obvious reasons)
iant_: couldn't we define GeoTools as the reference implementation of GeoAPI?
jgarnett: I am not sure that would be smart Ian
jgarnett: we make compromises to GeoTools to "get it done"
iant_: I'm not sure how you'd define tests for interfaces
jgarnett: for GeoAPI we often want to "Get it right"
desruisseaux: I would like that, but not from our initiative. It would be nice to get that words from OGC.
jgarnett: even at the expense of usability.
desruisseaux: We could select onyl a subset of geotools
desruisseaux: to be proposed as reference implementation
jgarnett: ianT_ you can inject a factory into the test case; implementors would subclass the test case.
desruisseaux: But the decision would need to be OGC's one (I don't think they would object if our implementation is correct)
jgarnett: Martin let me bounce an idea off you
jgarnett: (and then we should think about wrapping up this meeting in 10 mins)
jgarnett: One way to get more GeoAPI implementations is to make more GeoAPI implementations.
jgarnett: consider GeoTools as the nice friendly beast we know and love from GeoTools 2
jgarnett: And a GeoTools Kernal or something
jgarnett: that has all the strict implementations.
jgarnett: As an example our Filter implementation today contains a lot of backwards compatibility loving code and hacks.
jgarnett: A second implementation that avoided all that would a) be fun b) be clear c) be intergrated with GeoTools at a Factory / GeoAPI level.
jgarnett: ie; we need more than one implementation to be crediable.
desruisseaux: But could this second implementation be proposed as part of GeoTools 3?
jgarnett: there is nothing stopping us from providing several implementations.
jgarnett: I am talking about the structure of GeoTools 3
jgarnett: ie how to set it up as an interesting project; with room for collaboration etc...
iant_: I'm not sure how much credability it gets us if both implementations come from GeoTools
jgarnett: in a sense this would be very much "Eating our own dog food" on the factory front.
jgarnett: Iant_ ++
jgarnett: Iant_ I agree on the credibility side of things
jgarnett: but there are two levels here;
jgarnett: in terms of the java community GeoAPI was set up to provide a venue for communication
jgarnett: recent Java Collab discussions
desruisseaux: For GeoAPI, I think that we really need to find the time and energy to support a OGC working group. We need a chair and members of at least 3 different organizations.
jgarnett: have left me a bit cold; I don't think other projects are interested in collaborating at this level.
jgarnett: but I know from experience that commercial and research organizations are
jgarnett: (indeed behind the scenes they funded most of my geoapi / geotools / standards work)
jgarnett: so there is a roll here - but it may not always be with other java open source projects.
desruisseaux: As long as GeoAPI provides only interfaces, other projects may see it as just constraints. But if we provides a test suite for this interfaces, they are starting to see benefit in implementing them. If in addition we migrate for example the OpenOffice plugins from GeoTools to GeoAPI, they would have yet more benefit.
jgarnett: IanT - to finish. Even with two implementations from geotools memebers I would feel more comfortable and trusting of a geoapi interface.
desruisseaux: (assuming some are interrested in a OpenOffice plugins)
jgarnett: (I never want to repeate the SYS_TECHNOLOGIES experience)
jgarnett: martin we may need to offer a bit more than test cases; but it is a start.
jgarnett: Let me give an example; if we can start offering geotools modules as reuseable components
jgarnett: the boundaries of which are defined
jgarnett: using formal geoapi interfaces.
jgarnett: we may have something.
jgarnett: (But we got to work on thouse interfaces / boundaries)
jgarnett: there is a blance between correct and simplicity that we don't hit
jgarnett: and we can measure the lack of success
jgarnett: Still there are good ideas all around here; and good examples.
jgarnett: I find it amazing that the old CoordinateSystem implementation
jgarnett: is winning out the deegree community
jgarnett: over the new CoordianteReferneceSystem?
jgarnett: I don't even undertand how that decision is worked out?
jgarnett: DO you have any insight martin?
desruisseaux: I have theory
jgarnett: Is the old CS implementation that much more simple?
desruisseaux: The old CS implementation is simplier and closer to WKT, but it was to simple.
jgarnett: Or is it just a lack of control issue? So much process behind GeoAPI that developers would feel at risk ?
desruisseaux: On the Degrees using the old CS, the main issue is that they are not seeing the difficulties of referencing.
desruisseaux: They are discovering it as they progress
desruisseaux: And they are redoing what is already done in current geotools implementation.
desruisseaux: For example the post last week about how to get the CRS that are valid over the USA.
desruisseaux: By not trusting ISO 19111, they do not admit that the referencing issue is more complex that they believe
desruisseaux: And they are discovering the complexity progressively
desruisseaux: For example in the old CS implementation, there is no way to known if a CRS use a cartesian, ellipsoidal or spherical coordiante system.
desruisseaux: Soon or later, when they will want to do serious mathematic, they will hit this wall.
jgarnett: so what we have here is a communication problem
desruisseaux: You can not do all yours mathematic as if the everything is cartesian.
jgarnett: (ie I am sure you communicated correctly; but sometimes communication problems can be with respect to listening)
jgarnett: We also need to publish how amazing geotools is more often
jgarnett: Unless we write articles and talk about how nice it is to have a good coordinate reference system implementation
jgarnett: nobody will notice when they google the topic.
jgarnett: (right now if they google most of what they find about geotools is bursa wolf transform parameter questions)
jgarnett: but that is more of a PMC / publicity issue
jgarnett: one we should be able to turn to now that OSGeo graduation is winding down.
desruisseaux: Justin pointed out that not having the referencing module downlable as a single JAR is a major reason.
jgarnett: yeah that is a big one.
jgarnett: you know what.
jgarnett: that - and just that
jgarnett: would make an excellent "first" geotools 3 component.
jgarnett: (the idea of bundling geotools components seperate is a good one; you saw my email on version numbers)
desruisseaux: I had this idea in mind, and this is also a reason why I'm pushing for geotools 3.
jgarnett: well starting out with a message everyone likes is a good move
desruisseaux: Yes I saw your email - I was not sure if it would be easy to do or not.
jgarnett: (you know the pressure of science vs buiness means this first component will have to be "referencing for JTS" :-D )
desruisseaux: What would look like referencing for JtS?
jgarnett: it may not be easy; but we should tell some story with the version numbers.
jgarnett: that is a good question - what referencing for JTS would look like.
jgarnett: I have some quick ideas;
jgarnett: CRS facade + JTS facade
jgarnett: store the CoordinateReferenceSystem object in the Geometry.getUserData()
jgarnett: and use that maven plugin to hunt down all other stuff.
jgarnett: ie fold this into a single download = geoapi interfaces, various geotools classes - and epsg-hsql
jgarnett: does that sound about right?
jgarnett: note the normal GeoTools 3 referencing module would be more general;
desruisseaux: Yes it was my plan to provide a single JAR with what peoples need
iant_: have you seen the fatjar project on sourceforge?
jgarnett: this JTS+referencing thing would be a seperate "product" -
desruisseaux: Yes I saw fatjar
jgarnett: no; but martin found a slick plug-in for maven.
desruisseaux: And I'm thinking about using it
desruisseaux: I think that the Maven plugin used fatjar
iant_: I've used it for some of my projects and i works well - plugs in to eclipse
jgarnett: (aside: iant_ if you can vote on a couple recent proposals - we miss you!)
jgarnett: Okay this was a good discussion
iant_: (already voted for you as osgeo rep)
jgarnett: Martin I need to stay cool for a couple more weeks; and have these discussions with you
jgarnett: and then we can get serious and start some formal planning.
jgarnett: does that meet with your timelines at all?
desruisseaux: As of referencing in JTS, getSRID doesn't have to be EPSG number right? So it could be numbers generated by GeoTools and uniquely assigned to a CRS in a running JVM (or does it have to be persistent between different JVM executions)?
jgarnett: oh good thought there...
jgarnett: I suspect that some implementations will store the SRID number
jgarnett: (I know for POSTGIS we make use of this number to reference the Spatail_Ref_SYS table)
jgarnett: but that is a good thought.
jgarnett: 3) SOC Status reports
jgarnett: wolf was collecting them
jgarnett: Simone was on holiday so I tried to answer a few questions
jgarnett: but in general SoC students have not been at IRC
jgarnett: and with out a wiki page or status emails
jgarnett: I feel a bit out of the loop?
jgarnett: Does anyone have a SoC student?
jgarnett: Or is anyone here a SOC student?
desruisseaux: Not on our side
jgarnett: fair enough
jgarnett: We should call the meeting over
Eclesia: the one you asked me to help didn't even send me a mail ...
jgarnett: there is a couple threads about release planning this week.
jgarnett: Eclesia he did respond to both of us; it was not very clear but it sounded like he managed to sort things out.
jgarnett: (and thank you for trying to help; I think most of what he needed was an encouraging word)
jgarnett: Martin for release planning
jgarnett: what does referencing need?
darkblue_B left the room.
jgarnett: And is there any help that can be provided?
desruisseaux: It is basically in the same state than 2.4. It contains a lot of duplicated code; EpsgThreadedFactories are modified copy of other classes, and those classes are quite big.
desruisseaux: So the amount of duplication is quite important
jgarnett: Rigth and we put off the clean up until 2.5 here
jgarnett: well can we try cutting cold turkey?
desruisseaux: I'm not sure which implementation is actually used, which make interpretation of stack trace more hasardeous
jgarnett: we should be able to do that just with changing the FactorySPI file
jgarnett: if we do it now; it sounds like we will get a couple weeks of solid testing out of GeoServer
jgarnett: and I can try and transition to epsg-hsql on uDig trunk
jgarnett: when you say you are not sure what implementation is actually used what do you mean?
desruisseaux: I do not know by memory what is declared in META-INF
jgarnett: I do
jgarnett: right now "my" implementation
jgarnett: is not hooked up
jgarnett: so cutting over; and talking about any bugs on email
jgarnett: is the first step
jgarnett: We can leave the "old" implementation there for a bit; perhaps someone wants to use it via a factory hint?
desruisseaux: I don't think we should add a factory hints for old implementations
jgarnett: I was thinking the hint where you say exactly what factory to use?
desruisseaux: So lets edit META-INF...
desruisseaux: Ah yes
desruisseaux: I forgot this one
jgarnett: um; I will wrap up the meeting IRC logs then
jgarnett: (thanks everyone; early meeting time is indeed better for starting on time)
desruisseaux: Bye all
desruisseaux: Thanks for running the meeting Jody
0) What is up?
1) Geotools 3
2) Dealing with feature validation
5) Distributed Versioning Systems
- Meeting time for next IRC
- Graduation to OSGEO
- Image I/O metadata
- Meeting time moved to 9:30 PST
- Martin is going to make a mvn site:site report capturing the review.txt files
- Jody is going to make the Provenance Review page on the geotools wiki
- Jody is going to make a Jira issue category for "provenance" issues
- Andrea was going to verify the state of unsupported
- Breakout IRC on wednesday to fix any remaining issues
- GeoTools 2.5.0-RC1 to be released just in time for the board meeting (Unsupported modules will not be included)
- Simone is looking into ImageIO metadata and will ask on java-collab and possibly use google docs to collect requirements
- unsupported/ogc modules are required for our build
jgarnett hello everyone!
desruisseaux Hello Jody
desruisseaux The meeting didn't started yet
simboss hy guys
SamH Hi all
desruisseaux Hello Simone & Samuel
SamH How's everyone doing?
SamH I'm getting mad at JAI.
simboss don't worry, you are not the first one, and for sure you won't be the last one either
SamH it doesn't seem like a very well supported project...
desruisseaux Its is a very powerfull library, but its development is going slowly since a while.
simboss well from what I know
SamH yeah... good way to put it.
simboss they only take care of the commercial users
simboss but they are having internal problems to go open source for good
simboss hence it is kinf of a dangling project
simboss which sucks honestly
Eclesia (then we must join the jai project)
SamH that would explain a lot.
simboss patches takes forever to get to trunk
simboss eclesia, I did, but It did not changed much
jgarnett well it is like 30mins after? going to be a quick meeting?
simboss I would like to add
simboss imageio metadata
simboss for nd coverage
simboss just for the fun of it
SamH that would be very helpful...
simboss (well daniele is not around, I'll do my best)
SamH and could be very powerful.
aaime Shall we get started?
desruisseaux Fine for me
jgarnett yes ...
jgarnett aaime do you want to run the meeting today?
aaime 0) What's up?
aaime is trying to speed up feature and taking pain in the process
desruisseaux Martin: a bit of cleaning in metadata, referencing and coverage (just scratching the surface actually)
Eclesia playing on puzzle, and seriously working on styles
simboss simone: jpip + python
vheurteaux word excel and powerpoint :-/
jgarnett jgarnett: more udig training; I am really enjoying it - except for the GeoTools 2.2 part - which I am hoping to get over.
simboss move to trunk, move to trunk, move to trunk...
jgarnett (I have to move my developers first)
jgarnett so yeah - what is next?
jgarnett 1) Meeting time for next IRC
desruisseaux I'm fine with whatever hour people come with (would be happy if sooner)
simboss that would work for most europeans
desruisseaux This is 10:00 AM on American West coast. Sound raisonable?
SamH That is reasonable.
desruisseaux Computing again...
desruisseaux Yes, 10 AM (I think)
desruisseaux (checking again with a real tool; I think I'm confused...)
aaime works very nice for me
jgarnett that sounds fine for me; as mentioned on email the only people left out here are in Australia.
jgarnett so +1
aaime so we have 3 +1 right?
aaime or 4? simboss?
desruisseaux Would be 9:00 AM in Vancouver
simboss i proposed it, I am +1
jgarnett okay so simboss you get rewarded by updating the developers guide
jgarnett motion passed.
desruisseaux Is 9:00 AM okay for you Jody?
jgarnett I was hoping for 10:00 AM; but yeah 9:AM is fine ...
desruisseaux I made I mistake when I said 10 AM. This is why I checked with a better tool after.
aaime well, 19.00 italian time is not that bad either for me
aaime both work fine for me
desruisseaux Both work for me as well.
simboss no wait sorry
simboss it is a bit late for me
simboss can we make it 18:30
SamH That sounds like a good compromise.
aaime that would be 9.30am Vancouver time
jgarnett I don't mind moving the meeting early
jgarnett all these options are in refractions work day; so you are not cutting into my personal time.
aaime so, 19.30 CEST, 9.30 Vancover, deal?
jgarnett So I will vote +1 on any of them.
aaime it seems we have an agreement?
jgarnett sounds fine; and a final idea - let us start on time
aaime eh, right
aaime So ok, new meeting time is scheduled at 19.30CEST
desruisseaux 2) Graduation to OSGEO
aaime simboss, update the page, can you also send a mail?
jgarnett and simone updates the developer guide Can you send email too Simone?
jgarnett Simone is popular; it must be his good looks.
simboss being beatiful is a curse
aaime he has big shoulders, we know he can take it
simboss but I bear with it as a man would do
aaime desriusseaux, osgeo?
desruisseaux Adrian as sent an email last week
aaime do we have a wiki page with a status of each module?
jgarnett um the page has to be on the osgeo site
jgarnett let me find the link;
jgarnett last time I emailed each module maintainer; but perhaps this time we should just "get 'er done"
jgarnett - http://wiki.osgeo.org/wiki/GeoTools_Incubation_Progress
desruisseaux Rob is our mentor. The next OSGEO meeting is Friday in about 10 days. If we want him to submit GeoTools graduation to OSGEO vote, we need to make sure that:
jgarnett - http://wiki.osgeo.org/wiki/GeoTools_Provenance_Review
desruisseaux * review.txt file is up to date for every modules
jgarnett Cameron is our mentor
desruisseaux * We have determined to provenance of our data
jgarnett up martin
jgarnett review.txt is just our way of being organized
desruisseaux Ah? Oups, sorry to have confused who is our mentor
jgarnett for the actual issues we can fix them; or
jgarnett punt them into the bug tracker.
jgarnett We will link to the review text files; but that is really us just getting organized...
desruisseaux So do we have a parent JIRA task when we can create sub-task for open issues?
desruisseaux (typo: where we can create...)
jgarnett compare with http://wiki.osgeo.org/wiki/FDO_Provenance_Review
jgarnett or this one: http://wiki.osgeo.org/wiki/GDAL_Provenance_Review
jgarnett the second one is much more inline with what we need.
jgarnett notice each actual issue links to an entry in the issue tracker?
aaime well, ours is not that bad, we'd need to expand all the review files into the wiki page, right?
jgarnett gdal/data has the most issues; not it graduated with known issues.
jgarnett well we can link to the review.txt files in svn ... sound okay?
jgarnett really the committee will check the review files; and try and catch us out.
jgarnett make sure every issue is in Jira etc...
aaime sort of, I mean, we'd have to make it evident which review.txt contains issues
jgarnett How about we have a link to each review.txt in the wiki
aaime also that page hasn't been upgraded since 1.5 years it seems?
jgarnett and then a link to each issue covered by that review.txt
jgarnett I think we are down to only a few issues now right?
jgarnett correct aaime
jgarnett now a couple ideas to make this easier.
desruisseaux Adrian told me that Java code is okay, but we need to determine the provenance of our test data.
jgarnett can we move the contents of this page into our own wikit?
jgarnett I think we can ...
aaime desriusseaux, I fear that many shapefiles are very old
aaime no one knows where they come from
jgarnett would making it in our own wiki - make it easier for module maintainers to update?
desruisseaux I guess that Ian Turton would know.
aaime like the old old states.shp, anybody knows about its origins?
jgarnett I assume ESRI test data honestly.
desruisseaux We should ask to Ian Turton. He is the most likely guy to know about those data.
desruisseaux I will send an email to him.
desruisseaux Do we have someone up for the wiki page?
jgarnett that poor osgeo wiki page links to our module matrix; which is very incomplete...
jgarnett martin is there any chance our mvn site:site thing could have a report link for each review.txt file?
desruisseaux Yes we can do that.
jgarnett martin I can do the wiki page ... I will move it to our wiki and expect help filling in the details.
jgarnett if you can do a mvn site:site with the review.txt stuff it will take care a lot of the grunt work on the wiki page...
desruisseaux Thanks Jody. I take the email to Ian and the link in "mvn site:site".
jgarnett the other thing is to make a sample download of the code that is "Ready"
jgarnett I assume we do not want anything in unsupported;
jgarnett the downside is a lot of Justin's generated code is there ...
jgarnett we may have to set up a formal profile or something?
jgarnett what do people feel about that?
desruisseaux I think it would be safe to ommit the unsupported modules.
jgarnett well problem is martin we use some of them;
jgarnett andrea are you up for some pom.xml hacking?
aaime that does not mean we have to include them into the releases...
aaime jgarnett, what exactly?
jgarnett I am thinking we have several profiles in "unsupported"
aaime creating profiles so that unsupported is not included by default in the builds?
jgarnett (we do already)
jgarnett and we isolate all the stuff that is "ready" from an osgeo standpoint; oracle-spatial; ows; etc...
aaime that would speak trouble thought....
jgarnett and we turn that profile on by default.
jgarnett okay what trouble?
aaime modules getting broken because of chages in the core ones
aaime and nobody noticing
jgarnett we can include them in the nightly build if you want
aaime like what happened in epsg-oracle
jgarnett but they are not something we can ship right now?
jgarnett agreed; but this is a deadline; and we need to cut our losses (for the geotools project here)
jgarnett I understand that uDig and GeoServer make use of oracle-spatial plugin...
desruisseaux Do we need to provides downloadable files for the graduation?
jgarnett I think oracle-spatial is not the best example; it has a review.txt
jgarnett See email:
jgarnett I want to be able to point Cameron at the following:
jgarnett - sample download with the headers all fixed up; a release candidate?
jgarnett - a list of Jira tasks for each problem we found in the review.txt files
jgarnett - update the incubation status page to reflect we are ready
jgarnett ie we would like to say to the committee; here it is - the geotools library as we would like you to approve.
jgarnett does that make sense?
aaime it does
desruisseaux I think it make sense. But could the downloable file be just a milestone?
jgarnett the only problem here is unsupported\ogc ... we have no review.txt and this includes the work of the OGC (in the form of schemas)
jgarnett Do we have jdeolive around?
aaime jgarnett, actually I believe acuster did review most of the unsupported modules
aaime jgarnett, away, vacation
jgarnett ah ...
desruisseaux How does unsupported/ogc relate to the OGC project on dev.java.net?
aaime not at all afaik
jgarnett I am not sure if there is any relation martin
aaime there are EMF models
aaime of many OGC specs
jgarnett I think everything else in unsupported we can safely drop and still have the library work.
jgarnett okay we need a volunteer to look at unsupported; or pester acuster and see how far he got, or even check for email from acuster on the topic.
jgarnett can we follow this one up on emal?
aaime I so far counted 2 modules without review.txt made/updated by acuster
jgarnett and since this is a deadline and the PMC are responsible for seeing this happen; tag the subject "PMC:" to start out with; or use the admin list.
aaime ok, so the plan is?
desruisseaux Jody move the wiki; I ask Ian Turton for shapefile data provenance and I make review.txt content to appears in mvn site:site.
aaime (sorry guys, played tennis two hours, had a shower, no dinner, I'm about to fall flat on the floor)
jgarnett yeah and the meeting is running late; almost done andrea.
desruisseaux We can point Cameron to the new wiki and to the maven site
desruisseaux What else?
jgarnett we should check back in; say a breakout IRC later this week; and if ready we can make a release candidate.
jgarnett how does wednesday sound? too soon or too early?
desruisseaux fine for me
jgarnett or too late for us to fix stuff after.
jgarnett okay cool.
jgarnett 3) Image I/O metadata
jgarnett sounds like good progress on this one on the email list
simboss I just wanted to tell people what we are up to
simboss since we would like to do a tentative for early collaboration
simboss at the lowest possible level
simboss for coverage, which means imageio
simboss daniele and alessio have been working on imageio readers for grib1, netcdf-cf and hdf4/5
simboss some work hs already been done
simboss some needs to be done
simboss and especially on defining
simboss possible structure for metadata
simboss I was thinking about asking daniele
simboss to capture the work on the wiki
simboss but I am fraid it might be dispersive
simboss right now we are using an OO document
simboss I was thinking about
simboss a google document
simboss a public one
jgarnett quick suggestion
aaime I guess it's up to cbriancon, he's the one working on that for Geomatys, right?
jgarnett jump on that silly java-collab list - and let them know what is up
jgarnett at the very least frank will want a look see?
simboss yeah, good point
desruisseaux I'm fine with java-collab list
desruisseaux (fine with wiki page too, at your choice)
simboss what would you think about a google doc
simboss we could import the one we have
simboss and edit online
simboss in a cooperative fashion
desruisseaux Actually I don't know how google doc work (never tried before). But if you have experience with that, it is really worth a try I think
jgarnett (aside: I am going to make a new Issue Category for this "license" stuff; that way the wiki can report back the issues and always be correct)
desruisseaux Nice idea Jody!
jgarnett yeah I have my moments.
jgarnett simboss I am also doing okay with just open office documents in version control
simboss is it obvious that I am google docs fun?
simboss well, go for the document in subversion then
jgarnett but yeah google docs works fine.
jgarnett depends on how much collaboration you expect from java-collab I figure.
desruisseaux I have no objection against google doc; this is really as you wish
aaime if you're shooting for java-collabo maybe google stuff is better
jgarnett your party simboss
simboss let' try google docs, if it does not wkr we can export as open office again
simboss we can control who write on it
simboss who can read it
simboss we can have ffeds for the updates
simboss etc., etc.
jgarnett okay so with that non decision we better end the meeting.
jgarnett before andrea falls asleep on the keyboard.
jgarnett (and can I ask someone to post the logs; I got wiki page of doom going on here and I am scared to lose my train of thought)
desruisseaux On the metadata document, I would have a suggestion... If "calibration" is a requirement from your client, then I understand that we try to put it in the metadata. But if it is not a requirement, I would suggest to leave "calibration" out for now. This is really a much wider topic than just "scale" and "offset" coefficient (even if the have an "error" attributed). Actually it is venturing in...
desruisseaux ...the land of SensorML...
simboss martin, we might need it to capture
simboss packed remote sensing data
simboss for the moment thigs are simple
simboss but we might soon start working
simboss with the cosmo skymed data
jgarnett oh martin don't go to SensorML; we like you more than that.
simboss and that is going to be painful
jgarnett oh no they are both lost ...
aaime goes have some dinner
jgarnett we will hold a wake; SensorML is the start of specifications that never end ... Observations and Measurements.
desruisseaux I means, if you don't need calibration now, lets wait a bit before to try to handle them. "scale" and "offset" are related to data encoding, which is not the same. Calibration is really an other topic.
simboss yeah, I see what you mean
simboss let's put it this way
simboss from the moment scale and offset
simboss *shouldé be fine
simboss let's leave a question mark though
simboss I got some data to play with and calibration might really be involved
simboss but as I said for the moment
simboss scale and offset
simboss should be fine
desruisseaux Yes, but they would be deserve a "Calibration" node independant of the data encoding.
simboss yeah I see your point
desruisseaux Calibration scale and offset are not necessarly the same than data encoding scale and offset.
desruisseaux Calibration varies with each instruments
desruisseaux Data encoding is usually frozen for a whole data series
simboss (I remember that was part of the email right? )
desruisseaux Even if the data series come from of many instruments.
desruisseaux Yes, that was part of my email.
desruisseaux Calibration are almost never linear.
simboss (cool then, I'll talk to daniele about this tomorrow)
desruisseaux They are usually at least cubic, often yet higher degree.
simboss we might want to come back to that
desruisseaux So this is not the same than the scale and offset using for data encoding.
simboss quite soon
desruisseaux All right.
simboss if we get to model the sensor platform used for the acquisition of the scene we have to manage
simboss but for the moment
simboss you are right
simboss we might want to find a better name for data encoding params
desruisseaux I suggest to just move "scale" and "offset" either in Category, or in SampleDimension close to "nodataValues".
desruisseaux And reserve "Calibration" name for much more sophesticated calibration metadata later.
desruisseaux In OGC 01-004, "scale" and "offset" are in SampleDimension with "nodataValues".
simboss fine with that
jgarnett updated: http://wiki.osgeo.org/wiki/GeoTools_Provenance_Review
jgarnett created: http://docs.codehaus.org/display/GEOTOOLS/GeoTools+Provenance+Review
simboss since you are there
simboss did you ever manage to get around
simboss hdf crashes?
desruisseaux No, but last time I tried was two years ago.
desruisseaux I got crash on Linux only; it was working fine on Windows.
jgarnett that is a first
simboss well under big load crashed on windows as well
simboss I tried to rebuild the source from scratch putting guard expressions in the c/c++ code
simboss but it still fails
simboss it is failry unusable inside a web server
simboss too bad
desruisseaux I would suspect the problem to be more likely to be on JNI side than HDF C/C++ side
desruisseaux Given that the HDF C/C++ library is widely used at Nasa, it would be surprising if it was unreliable.
desruisseaux The JNI part is likely to be less widely tested.
desruisseaux I have done a little bit of JNI a while ago and I found that tricky.
simboss that's what I meant, i tried to reinforce the JNI part
desruisseaux Most be very careful about releasing JVM resources, especially pointer to arrays (and HDF library probably use a lot of them)
simboss woring in c/c++
simboss but it is too wide
desruisseaux Enforcing the JNI part with classical C/C++ guard expression code probably don't manage JVM resources.
simboss yeah, I guess we would need to spend quit some time on it to make it robust
desruisseaux So if a JVM resource was not properly released, I'm not sure that gard expression would have detected that (just an hypothesis; I just expect those expression to work on classical C/C++ stuff)
simboss I was thinking about rewriting them from scratch with SWIG
jgarnett guys can I capture the logs now? And it is Canada day tomorrow.
jgarnett oh simboss that is a lot of work ...
simboss not too much actually
simboss if you know how to use swig
jgarnett jgarnett not leet enough; repressed all JNI stuff ages ago.
simboss well, my python is calling me
simboss ciao a tutti!
A lazy meeting for a lazy community.
1) Meeting starts 20 minutes late because everyone waits for someone else to run things.
2) Most of the PMC doesn't show up enough to even say hello, almost no one participates.
3) No one so much as offers to post logs.
These are low days indeed in the community at large.
0) Whats up 1) Style proposal 2) Metadata renaming (proposal)
– Now talking on #geotools
– Topic for #geotools is: http://geotools.org
– Topic for #geotools set by jgarnett at Tue Jun 17 19:32:23 2008
<desruisseaux> Meeting time?
– desruisseaux has changed the topic to: 0) Whats up
<acuster> jgarnett, around!?
– aaime will be late tonight, I still haven't had dinner
<acuster> Eclesia hbullen jalmeida mauricio mgrant pramsey springmeyer wanna have a meeting?
– sfarber (firstname.lastname@example.org) has joined #geotools
<desruisseaux> Does anyone have agenda topic?
<Eclesia> styles once again
<Eclesia> and call for a vote on the proposal
– Eclesia remind the proposal page : http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
<hbullen> sure one min
– vheurteaux (email@example.com) has joined #geotools
– desruisseaux has changed the topic to: 0) Whats up 1) Metadata renaming (proposal)
– desruisseaux has changed the topic to: 0) Whats up 1) Style proposal 2) Metadata renaming (proposal)
– afabiani (firstname.lastname@example.org) has joined #geotools
<CIA-26> desruisseaux * r30792 /trunk/modules/library/metadata/src/ (36 files in 6 dirs): Synchronized the collections used in metadata. Javadoc cleanup.
<acuster> Eclesia, why don't you start the meeting since you have things to discuss?
<vheurteaux> go Eclesia go !!!
<Eclesia> It's useless if nobidyes here
<acuster> Everyone is expected to read the weekly irc minutes, and PMC members are required to
<acuster> hence you discuss, even if no one is around
<acuster> and then they have something to read
<Eclesia> ok so : please vote for the style proposal. seens no one raised objections
<Eclesia> proposal page : http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
<Eclesia> subject : upgrading the style package on new geoapi interfaces
<Eclesia> and fallow OGC Symbologie Encoding Specification, ISO 19117 portrayal and a part of OGC SLD 1.1
<Eclesia> if you have questions ...
<desruisseaux> Minor details
<desruisseaux> String getUnitOfMeasure();
<desruisseaux> Could it returns Unit instead of String?
<desruisseaux> We may need to define a Pixel constant...
<desruisseaux> (a Pixel Unit constant)
– johnValtus (email@example.com) has joined #geotools
– simboss (firstname.lastname@example.org) has joined #geotools
<Eclesia> If we can define a pixel unit then yes we can replace the string by a Unit
– ggesquiere (email@example.com) has joined #geotools
<Eclesia> or perhaps using "null" for the pixel unit
<Eclesia> seens is has no relation to any other units
<desruisseaux> Better defining a Pixel units
<Eclesia> it has*
<desruisseaux> "null" is rather used for no-units (which is not the same than pixel units)
– sfarber (firstname.lastname@example.org) has left #geotools
<desruisseaux> We can define a Unit without relation with other units.
<desruisseaux> (actually it has a relation, but admitely a complex one, so we may want to treat it as if it has no relation)
<Eclesia> noticed I didn't used "pixel" but display unit
<desruisseaux> Thats fine.
<desruisseaux> Other minor proposal:
<desruisseaux> Collection<String> getSemanticTypeIdentifiers();
<desruisseaux> Should we replace the String by an Enum?
<desruisseaux> Given that the allowed values is restricted.
<desruisseaux> (or maybe a CodeList if we want to allow peoples to expand the list)
<Eclesia> the specification says it's still in experimentation
<Eclesia> we should not limit possibility until we have more details
<Eclesia> (that's what I believe)
<desruisseaux> Then a CodeList may fit.
<hbullen> I agree with you eclesia
<desruisseaux> (CodeList can be expanded with user-provided elements)
– Eclesia have no objections
<hbullen> sounds good to me
<desruisseaux> I do not known well the style and symbolizer specification, but the proposal seems quite reasonable to me. Does anyone else have remarks?
<Eclesia> next topic ?
– acuster can see he's going to have to become a PMC member to slap some order into these IRC meetings.
<desruisseaux> Okay, I added my vote to the proposal.
<desruisseaux> Next topic
<desruisseaux> Metadata renaming
<desruisseaux> (Implementation class of course, not interfaces)
<desruisseaux> Proposal: http://docs.codehaus.org/display/GEOTOOLS/Naming+policy+for+GeoAPI+implementation+classes
<desruisseaux> 1) Brings cross-module consistency (metadata vs referencing vs coverage)
<desruisseaux> 2) Make apparent which classes are "abstract" in ISO sense (which is not necessary in java sense)
<desruisseaux> 3) Make apparent which classes are GeoAPI implementations (in theory to be hidden and created through a factory) and which classes are GeoTools specific.
<desruisseaux> Renaming would be performed through the usual "deprecated, delete at next release" cycle.
<desruisseaux> Comments, suggestions, objections?
– Eclesia community support +1 , I use those namings too
<acuster> are you proposing that all of geotools follow this?
<desruisseaux> I would propose that but would not take action outside the modules that I maintain - I would left the decision to maintainers.
<desruisseaux> Thanks Eclesia for your support
<acuster> for you the first glance of naming is looking for a different thing than for users
<acuster> I generally want to see which classes 'go with' which
<acuster> then I can sort out the five or ten together
<acuster> by looking at each in turn in the javadoc
<acuster> so I don't like DefautFoo
<acuster> being miles from AbstractFoo
<acuster> and in turn those being far from FooOne, FooTwo
<acuster> english is a shitty language for this since it puts the adjectives before the nouns
<acuster> So far I'm working with FooAbstract, FooDefault, FooSpecifc
<acuster> but I don't have your experience or needs
<acuster> so it's hard to know who we are targeting with our naming
– hudson (n=PircBot@188.8.131.52.static.nyinternet.net) has joined #geotools
<desruisseaux> Well, if we look at usage in JDK, I see both AbstractFoo and FooImpl, but I never saw FooAbstract... Between DefaultFoo and FooImpl, the former (DefaultFoo) seems to be used slightly more often, but not by far...
<desruisseaux> I often tend to take the Java Collection framework as a model, because it is often praised as one the the good part of Java library (the collection framework has win awards)
<desruisseaux> And they use AbstractFoo.
<acuster> you used to argue that all this would be taken care of by better and better javadoc tools...
<acuster> anyhow, you do as you see best and more power to ya
<desruisseaux> Yes this is also too. But when I develop GeoTools, I find more useful to separated GeoAPI implementation from support class than having everything in alphabetical order. So actually I find the English order (Abstract / Default in front) quite convenient after all.
<desruisseaux> (typo: this is also true)
<desruisseaux> And separating Abstract from Default is quite convenient too, since we typically want to instantiate only the DefaultFoo classes.
<desruisseaux> (so DefaultFoo are were I tend to look first).
<desruisseaux> typo: where
<desruisseaux> Okay, I guess that we will let the proposal sleep a few days and see later this week (I would like to know Jody's opinion).
<desruisseaux> I'm done.
<jgarnett> hi guys; I am teaching a class but I can try and answer a few questions.
– drywall406 (email@example.com) has joined #geotools
<jgarnett> I don't mind between Default and Impl; I just like things to be consistent. I am used to the XXXImpl from Eclipse land
<simboss> ciao jody+
<jgarnett> Also if there was anything I needed to vote on let me know
<desruisseaux> Hi Jody
<desruisseaux> There is Eclisia style proposal waiting for vote
<desruisseaux> I proposed few minor modification (getSemanticTypeIdentifiers() to returns CodeLists, getUnitOfMeasure to returns Unit), but this is not major.
<jgarnett> I was happy with your take on it martin; getRules() for thread safe access; and rules() direct live access (ie mutable)
<jgarnett> so it was up to Eclesia to say what he was building ....
<jgarnett> is it mutable?
<Eclesia> implementer choice
<Eclesia> I guess they will be mutable in gt
<jgarnett> well we need to know in order to define the interface
<jgarnett> if it is mutable we need a different API (ie with listeners)
<jgarnett> or at least some indication on what is allowed in the javadocs ...
<jgarnett> I think acuster went through my wiki ideas on the topic; style tends to be in the "prep the data (ie mutable)"
<jgarnett> and the pass it over for rendering (which assumes immutable)
<jgarnett> gotta go ...
<Eclesia> having a method rules or getRules is a different problem from mutable or immutable
<jgarnett> not according to martin; who wanted rules() naming to mean mutable ...
<jgarnett> (if I read his email right?)
<Eclesia> I think you misunderstood
<desruisseaux> No I don't means that "rules()" must be mutable
<desruisseaux> I realize that my email was giving this feeling.
hudson/#geotools geotools-trunk build fixed (http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/748/)
<desruisseaux> My idea was rather to let mutability decision to implementors
<desruisseaux> But if "rules()" is mutable, then it must be a living collection.
<desruisseaux> Again I'm using Java Collection framework as a model.
<jgarnett> from email:
<desruisseaux> Map.entrySet() or List.sublist doesn't need to be mutable
<jgarnett> Immutable collections: List<Foo> getRules()
<jgarnett> Live collections: List<Foo> rules();
<desruisseaux> Yes, I known that I said that.
<desruisseaux> "rules()" is a live collection: change to the underlying object are reflected in the collection view, and vis-versa.
<desruisseaux> But whatever those changes are allowed or not is implementor decision.
<desruisseaux> Again, what I'm proposing is exactly the same than Map.entrySet(), List.sublist, etc.
<desruisseaux> If Map is immutable, than Map.entrySet() is immutable as well.
<desruisseaux> If Map is mutable, then changes in this map are reflected in Map.entrySet() and vis-versa.
<desruisseaux> The spec doesn't said that Map.entrySet() has to be mutable or not.
<desruisseaux> It just said that is must reflect the content of the underlying Map in all time, even if one of those change.
<desruisseaux> This is different from getRules() / setRules(), since typical getter and setter involve cloning the argument.
<desruisseaux> I have to go. Bye all...
– desruisseaux has quit ("ChatZilla 0.9.83 Firefox 184.108.40.206/2008042015")
<Eclesia> I guess the meeting is finished
<Eclesia> please take time to vote for both proposals
<hbullen> before everyone gose could some one take a look at the mysql patches I have submited?
<Eclesia> you know who is the maintenar of the module ?
<jgarnett> okay makes sense
<hbullen> not really?
<jgarnett> I am not sure there is one
– johnValtus (firstname.lastname@example.org) has left #geotools
<jgarnett> aaime reviewed last time I think
<hbullen> It says he is the lead on codehaus
<hbullen> So I guess I'll bug him then
- what is up
- svn is down film at 11
- svn access post osgeo
- styles upgrade
- GeoAPI release with JSR-275
- 2.5 branch
- pmc: discuss options for moving svn to OSGeo or Codehaus hardware
- jgarnett: Create [Switch from JSR 108 to JSR-275 for Units] proposal
- eclesia: Create a migration plan for styling
jgarnett: let us start the meeting
jgarnett: agenda topics?
acuster: svn is down, film at 11.
sfarber: ok, let me think a bit. The circularity of it is making the code hard to read, and I think hard to implement/use correctly. Let's talk more later. Yes, the performance gain is important, heck it's neccesary...but I think there's a cleaner conceptual way to make it click together.
jgarnett has changed the topic to: 0) what is up 1) svn is down 2) svn access
jgarnett: I like the way acuster said it
Ed [email@example.com] entered the room.
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo
Eclesia: styles upgrade
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade
desruisseaux [firstname.lastname@example.org] entered the room.
jgarnett: I assume the #geoserver crowd is not around today? they were trying to do some planning last week ... let's keep that topic.
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) 2.5 branch
desruisseaux has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) GeoAPI release with JSR-275
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) GeoAPI release with JSR-275 5) 2.5 branch
jgarnett: acuster did we need to chat about the remaining osgeo issues?
jgarnett: or is email fine for that ...
acuster: I have nothing to add; work needs to be done.
jgarnett: okay ...
jgarnett: stupid question; is there a wiki page with the list of work on it? or can I update the proposal page based on your last email?
acuster: I have not written a wiki page
acuster: only the email, which is kind of self explanatory
acuster: ie. maintainers need to deal with their review. txt
jgarnett: okay I will try and update the tasks on our wiki page; even just to make sense of your email.
jgarnett: and we need a back up plan; ie kick things out of the build/release...
jgarnett: shall we start the meeting?
jgarnett: 0) what is up
jgarnett: jgarnett - reviewing styling work; relaxing after a busy week; trying to sort out communication
gdavis_: gdavis: working on and off on the wps module, getting the "execute" request working
***Eclesia working on styles GeoAPI/GeoTools and go module, raster function tests and vector tests
desruisseaux: Martin: testing and bug fixes in ImageMosaicReader. Starting the upgrate to JSR-275.
jgarnett: nifty ...
jgarnett: 1) svn is down film at 11
jgarnett: what is to say here?
jgarnett: do we think rsync caught it out?
jgarnett: or what ...
desruisseaux: I can try to stop rsync again and see if thing come back to normal.
desruisseaux: But we have verified that it is really run only once a day.
desruisseaux: And the next execution is scheduled in about 8 hours...
desruisseaux: Do I stop rsync?
acuster: what do the admins have to say?
vheurteaux: hello all Jody you can look if this IP address is flooding
vheurteaux: or this one
jgarnett: I am not the person looking at this; can you email the question to email@example.com
vheurteaux: ok I'll do that
jgarnett: we lease this server from a company in Vancouver; and we are on the phone with them sorting stuff out... I will send email when we have something useful.
jgarnett: near as I can tell everything is down;
jgarnett: and the long term solution is to upgrade things like svn right?
desruisseaux: One solution could be to move to OSGEO svn...
jgarnett: On a related note Thuens has been trying to set up a mirror of svn and a mirror of our repo in south africa (where the network delay and bandwidth costs are crazy)
jgarnett: so yeah; we can look at moving to OSGEO svn...
jgarnett: personally I would prefer to move to codehaus
jgarnett: for the simple reason that nobody in the community has to maintain it.
vheurteaux: svn 1.4 would be great
vheurteaux: it include's svnsync
jgarnett: (OSGeo == GeoTools as far as keeping the server alive goes right?)
jgarnett: you guys could also set up svn 1.4 and move things over to europe...
desruisseaux: I though that OSGEO has its own SVN. Don't they maintain it?
jgarnett: but we have all the codehaus premissions etc we need ... and it would give us single sign on for wiki + svn + jira ... that may be worthwhile?
jalmeida left the room (quit: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org").
jgarnett: OSGeo has servers available
jgarnett: but we are OSGeo; ie it is not a big thing like Codehaus
jgarnett: only volunteers on projects like ours.
jgarnett: (so OSGeo option; as far as I understand it = they provide a server and we set up svn ...)
jgarnett: Let me ask on the osgeo channel
jalmeida [n=Miranda@220.127.116.11] entered the room.
jgarnett: I will wait for a reply ...
jgarnett: So this svn situtation cannot go on; while this is not as bad as the SF days it is not good.
jgarnett: I am going out of the loop for weeks and cannot take this on; does anyone have facilities / time / interest?
acuster: for what?
jgarnett: (or in acusters case alternatives)
acuster: to host the svn?
jgarnett: for making a migration plan; either to codehaus or to osgeo hardware.
jgarnett: or to elsewhere...
vheurteaux: desruisseaux: shoot
desruisseaux: SVN on pulsar?
jgarnett: ... I can also ask if Refractions can upgrade svn to 1.4; but do we honestly expect that to help?
vheurteaux: no problem
acuster: refractions can't move
acuster: for some internal project
acuster: we should move to osgeo.org
jgarnett: refractions can spend money and move ... or lease another server.
jgarnett: I can ask.
jgarnett: I am intersted - why the interest in osgeo.org? Is it for the domain name? (that is a good reason).
desruisseaux: I'm hesitant between OSGEO and Codehaust. I can see the advantage in Codehaust. I was interrested in OSGEO only for the "symbol"
acuster: yeah, and maybe it's got a more recent svn
acuster: in which case we could mirror transparently
vheurteaux: yep sounds great
jgarnett: codehaus seems the better option for me; they are good about keeping their hardware going and svn etc... is up to date.
jgarnett: geoserver has had good luck with them.
acuster: let's move on; we won't resolve this tonight
desruisseaux: I'm not objecting against Codehaus
jgarnett: okay; but the question I had is
jgarnett: can we look into this? and the answer seems to be - yes.
jgarnett: and I expect we can swap notes on email?
jgarnett: 3) styles upgrade
jgarnett: Eclesia the floor is yours?
jgarnett: My first question is can you respond to the subject from last weeks meeting. We were trying to do planning and did not know your project timeline.
jgarnett: opps I missed agenda topic 2) I will come back ...
Eclesia: 2 or 3 ?
CIA-33: acuster * r30739 /trunk/modules/unsupported/jts-wrapper/src/ (20 files in 9 dirs): Copyright headers: unsup/jts-wrapper, change and add headers, add review.txt
CIA-33: acuster * r30740 /trunk/modules/unsupported/geomedia/ (3 files in 3 dirs): Copyright headers: unsup/geomedia, change and add headers, tweak review.txt
CIA-33: acuster * r30741 /trunk/modules/unsupported/jts-wrapper/review.txt: Copyright headers: unsup/jts-wrapper, this time with the review.txt
jgarnett: let me do 2
jgarnett: we can do that quickly
jgarnett: 2) svn access post osgeo
jgarnett: We have a list
jgarnett: should I shut off access based on this list?
jgarnett: so far a few people have asked for more time
jgarnett: and Jan Jezek missed signing the papers he sent.
acuster: Bryce should not be cutoff
acuster: since we can use his work wether he signs or not
acuster: it being in the public domain and all
jgarnett: okay; I will make a note of that ...
jgarnett: If you are under the impression you have sent in your paperwork; can you please check the above link.
jgarnett: I am not sure I saw one for Eclesia for example ...
jgarnett: sounds like I should send out a second round of nag letters...
jgarnett: 3) styles upgrade...
jgarnett: Eclesia the floor is yours
Eclesia: so I believe I have a 1month timelimit
Eclesia: I can start working very soon if needed
Eclesia: everyone depends on geoserver and others deadlines
jgarnett: geoserver has branched away; my question is if you think we need to make a branch of GeoTools 2.5 before you commit? Or basically what should be done ...
jgarnett: I think the idea last week was to either a) branch just before you switch the interfaces over ... or b) ask you to wait until geotools 2.5 is ready for release.
desruisseaux: So the question is related to: what is the schedule for GeoTools 2.5 release.
jgarnett: GeoTools 2.5 was supposed to target one major change; the feature model switch - and it has accomplished that goal.
desruisseaux: Can we do 5 first and come back to 3 after?
acuster: and meanwhile martin is talking us over to JScience units this week
acuster: so why can't we release 2.5 today?
jgarnett: I think this is okay? I would like to know what Eclesia's timeline is; so we can have a good discussion about 2.5
acuster: what is blocking?
jgarnett: thinking ...
desruisseaux: Hela!! Referencing is not ready for a release!!
jgarnett: what is not blocking?
acuster: okay, we have one blocker: referencing
***Eclesia waits for vheurteaux advice, I'm not the boss
jgarnett: uDig is on trunk for the first time in years and the datastore events are mostly missing
acuster: what else?
jgarnett: it is okay Eclesia; you have your timeline
jgarnett: it is up to us to figure out how we can arrange the geotools 2.5 release so you can work.
acuster: jody: can you draw up a list of blockers and then we can get a list of manpower
jgarnett: so tell us know what you know...
acuster: and see what that looks like?
jgarnett: acuster++ that is a good idea. I don't think there is much; but there is a lot of stuff that we were supposed to do (martin has referencing code reviews from last year for example) that we may need to let slide a while ...
***acuster doesn't understand this mythical month
acuster: we can't schedule a release for which we have no idea what work is to be done
jgarnett: acuster? a month is what eclesia said; so that is what we got ...
Eclesia: As you have seen I have barely duplicate the style implementation in the go module (I needed them) But going further is .. stupid. upgrading geotools styles classes woulmd be really nicer
jgarnett: well we can; we just need to cut scope to make the release ...
jgarnett: Eclesia can you udpate the style methods now?
acuster: I thought the GS crowd wanted a month of leeway?
jgarnett: and then after we branch make the classes implement the correct interface?
jgarnett: GS crowd made their geoserver 1.7 branch last week
Eclesia: it's not so easy, some returns types have changes, and it will break backward compatibility
jgarnett: I am doing my best to let them work on geotools trunk for both their 1.7.x branch and their 2.0.x branch ...
jgarnett: but that is incompatible with API change; basically some QA time is needed right?
jgarnett: can we go through and study the return types? We do have Java 5 type narrowing that may help us ...
Eclesia: returns types changed from arrays to collections, that's the problem
desruisseaux: Java 5-style for loop could help...
jgarnett: ie when LineSymbolizer.getMark() can return the geotools interface Mark; when we change geotools Mark to implement opengis Mark the method will be correct...
Eclesia: no, geotools have 2 arrays where geoapi have one collection for this
Eclesia: and a superclass for mark and ExternalGraphic
jgarnett: Eclesia good call about the arrays; I think we will find that most code uses a couple of methods like addFeatureTypeStyle to avoid the pain of using arrays...
jgarnett: so even regardless of branching; we need a migration plan ...
jgarnett: and it would be much smarter to know that plan now; so we can deprecate the methods that are going to be harmed now for geotools 2.5
jgarnett: does that make sense?
jgarnett: Martin how did you handle the transition from arrays to lists for metadata?
jgarnett: (aside: svn is back!)
desruisseaux: If I remember right, most methods was already collections. Only a few was array, and we though that their number was suffisiently low for suffering an API break.
Eclesia: there are 0 collections currently in geotools style classes
jgarnett: as an example FeatureTypeStyle.getRules()
jgarnett: most code uses fts.addRule( rule )
jgarnett: we could update our code now to use for loops when processing getRules
CIA-33: desruisseaux * r30742 /trunk/modules/ (9 files in 3 dirs): Coverage I/O MosaicImageReader: bug fix in the detection of overlapping tiles. Utilities package: added an additional exit code.
jgarnett: for( Rule rule : fts.getRules )
jgarnett: and thus be ready for the change from array to list
jgarnett: or we could make a new method
jgarnett: getRuleList(): List<Rule>
jgarnett: and thus avoid the conflict...
desruisseaux: Yes, this is the "Java 5-style for loop" I was suggesting a little bit sooner.
Eclesia: renaming is not the solution.
desruisseaux: Well, I would prefer "getRules()"
jgarnett: yes; you are correct martin - I am catching up ...
jgarnett: can we have fts.getRuleArray() now? ie run two methods ... that way code that expects array has something to migrate too during the transition.
jgarnett: (I also have to confess; we totally screwed up the transition for Filter; which is one of the reasons everyone is scared this time out ...)
desruisseaux: getRuleArray() in the current (to be deprecated) interfaces? Could be...
jgarnett: ie three years later we are still using the old interfaces internally; and since the project that paid for the transition is done ... everything else is on volunteer time
jgarnett: so far I like the getRuleArray() approach ...
jgarnett: I will put one other idea out here...
jgarnett: use java collections style naming....
jgarnett: fts.getRules(): Rule
jgarnett: fts.rules(): List<Rule>
jgarnett: the java collections naming is a bit more fasionable; the result forms a "domain specific lanague" ...
desruisseaux: Yes, rules() make sense too (especially if we decide that collections are "live" like Map.entrySet(), List.sublist(...), etc.)
jgarnett: - http://martinfowler.com/dslwip/Intro.html (for the example)
jgarnett: so we have 2 good options
gdavis_ left the room.
jgarnett: I would like an answer to this before we let 2.5.x go out the door; since it has some consequence for what we do to the geotools interfaces prior to release.
jgarnett: we have 5 mins left... moving on?
jgarnett: 4) geoapi release with JSR-275
jgarnett: so when does geotools trunk get to change?
desruisseaux: JSR-275 has been uploaded to dev.java.net today.
desruisseaux: So I'm adding the dependency to GeoAPI and I'm begining the replacements.
desruisseaux: I expect to be done before the end of this week.
desruisseaux: It seems to me that this change should be part of GeoTools 2.5 release, if it is workable for GeoServer and uDig guys.
jgarnett: I think so too
jgarnett: this should be part of our transition to Java 5;
jgarnett: so how do we do this martin? we asked a couple weeks ago - did we make a proposal page yet?
desruisseaux: Oups! I have not wrote a proposal page (well, we only have the JIRA task).
desruisseaux: Will look on the wiki tomorrow.
jgarnett: okay so if you can do that; and ask for a vote via email.
jgarnett: sweet. I am really looking forward to retiring jsr-108.jar
jgarnett: 5) 2.5. branch
***Eclesia go home +++
Eclesia left the room.
jgarnett: I think we had a couple good discussion already (thanks for putting up with us Eclesia). The branch will need to happen soon; I would like to see the migration plan for styles and jsr-275 make the cut.
jgarnett: I think some of the other work; like referencing may not make it in time?
jgarnett: what are your thoughts?
acuster: martin would really not like a release of the current referencing stuff
acuster: a release without his review makes him nervous
desruisseaux: I will see if I can spend a few time on referencing after the jsr-275 work...
jgarnett: jgarnett would like to complete the user guide section on styling; but would kind of like to wait for Eclesia's work (so I am stuck)
jgarnett: I would also like to see osgeo sorted out; so this can be the first offical osgeo release.
jgarnett: is that too crazy?
jgarnett: acuster this page had our list: http://docs.codehaus.org/display/GEOTOOLS/2.5.x
jgarnett: for udig the only remaining stuff is me to do some QA on the classification functions.
jgarnett: any other comments? If not I can close the meeting ...
acuster: do you know the GS time frame for this?
jgarnett: it was all in last weeks meeting was it not?
jgarnett: they made their first release candidate
jgarnett: when they are ready to release they will make a release of geotools 2.5.0
desruisseaux: When do they plan to make this release?
acuster: everyone has a mythical month floating around
jgarnett: they are worried that 2.5.0 is not ready; but they needed to start their ship sailing (before their code sprint)
acuster: and no firm dates
jgarnett: okay the first firm date already passed
jgarnett: it was last week.
jgarnett: geoserver branched.
jgarnett: nobody felt comfortable making another firm date until we did some cross company / project plannning.
desruisseaux: So, if a JSR-275 upgrate is performed this week, can they update?
jgarnett: between the two meetings we now know a fair bit.
jgarnett: desruisseaux; I think they can.
jgarnett: geoserver 1.7.0 has not made it out the door yet; we are making their life hard by changing this now ...
acuster: changing what?
jgarnett: I know you first talked about it some weeks ago; I should of reminded everyone about the release train leaving the station.
jgarnett: changing units.
jgarnett: so in terms of geotools 2.5.x scope
jgarnett: - we met our goals
desruisseaux: I'm 1-2 week late compared to what I said.
jgarnett: - we have some QA to do (on all sides)
jgarnett: - style interfaces shoudl be reviewed as part of a migration plan
jgarnett: - jsr-275 should go ahead
jgarnett: - categorization functions need test cases
jgarnett: that is all the stuff I know about?
desruisseaux: opportunist target (i.e. if we can): referencing
jgarnett: would it help if we set a deadline for ourselves?
desruisseaux: we could try, but I'm probably the worst guy in the whole geotools community about respecting deadline.
jgarnett: we understand; we know you
acuster: the only deadline I care about is graduating
jgarnett: I think the person I am most worried about here is Eclesia; I don't want him stressed out again ...
jgarnett: so martin we may just miss out on doing some of the work we wanted for 2.5.x right?
jgarnett: JSR-275 and styling represents the only pending API change; and only the JSR-275 one has any chance of impacting geoserver.
jgarnett: (ie they need to include a different jar...)
jgarnett: So martin how can we help you meet this deadline ...
desruisseaux: Some of the work wanted for 2.5 (referencing) may be missing, yes. Actually it is not a huge issue for me if we can warm peoples that some class will changes. My issue is that I would like to avoid a heavy "deprecated, then delete" cycle (we have some pre-threaded factory classes around).
jgarnett: From the perspective of people using that CRS utility class nothing will be different ...
jgarnett: So I suggest we "relax" about that one?
desruisseaux: If peoples agree, we can do thaT.
desruisseaux: In such case I would at least put big warning in the javadoc...
jgarnett: you are the module maintainer; I am happy to agree - but I want to make sure you are happy.
jgarnett: that is within your power; I also suggest putting a warning in the user guide
desruisseaux: My only issue is to avoid to heavy "deprecate, then delete" cycle.
jgarnett: still if we don't have time, we don't have time, and the users suffer ... sad but true.
jgarnett: So this is your call; can you make this work before eclesia is done his style migration plan?
jgarnett: you could always make him drink beer at work and slow him down ...
jgarnett: (that is a joke)
desruisseaux: No problem . I will try to at least start a little bit of work after jsr-275 and will let people known.
jgarnett: I found a GeoAPI Jira task for switching to JSR-275; but nothing for geotools...
desruisseaux: There is one for GeoTools too.
jgarnett: maybe you can hide the classes you are worried about; make them only package visible or protected visible ...
jgarnett: I did not see it in email; I am making you a proposal page now ... if that is okay?
desruisseaux: Sure, thanks a lot
jgarnett: oh they are linked; silly me ...
desruisseaux: In the GeoAPI JIRA task, you have the link to the GeoTools task.
jgarnett: okay thanks for the meeting guys; I know planning is tough.
jgarnett: I will post the logs.
desruisseaux: Thanks a lot for driving the IRC
desruisseaux: Bye all