GeoTools Blog from July, 2008

Agenda topics:

1. SE 1.1 and SLD 1.1 chat
2. Wwhat is up
3. 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 http://docs.codehaus.org/display/GEOTDOC/1+Referencing+Configuration+and+Tool
Eclesia hi
jgarnett morning
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 yes
  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
  jgarnett cool
  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 none
  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
  jgarnett (sigh)
  simboss simboss - jpeg2000, jpip and python
  tar1 tara - lurking
  aaime http://jira.codehaus.org/browse/GEOT-1704
  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
  dwins okay
  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
  aaime np
  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?
  dwins aaime++
  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 thinking
  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?
  gdavis_ alright
  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 ok...
  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?
  jgarnett correct
  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 agreed
  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 yep
  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
  simboss worked
  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.
  aaime Uh?
  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?
  jgarnett yes.
  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?
  jgarnett yes
  aaime you should have sent me a mail saying so?
  jgarnett I did?
  aaime I did not see it
  jgarnett reading
  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 k
  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?
  dwins sure

Agenda:
0) chat
1) what is up
2) follow up OSGeo
3) gridrange/gridenvelope

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 hrm
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
graduation"
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 thinking
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)
jgarnett ah
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 true
jgarnett thinking
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 visibility
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 suggestions?
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...?
dwins waves
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 cool
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.
acuster dvcs
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....
simboss anyway
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...
desruisseaux yes
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
simboss done
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 exlusive
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 yes
desruisseaux (I need to look back what GeneralGridRange constructor said)
simboss so we might need to change that as well
simboss k
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
simboss :-9

Agenda:

1. what is up
2. OSGeo Representative
3. GeoTools 3.3
4. SoC Status Reports

Action Items:

1. 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: yep
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:
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://www.mail-archive.com/geotools-devel@lists.sourceforge.net/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
aaime: jgarnett++
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: http://docs.codehaus.org/display/GEOT/4+Project+Management+Committee
jgarnett: done
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: +1
aaime is now known as aaime|away
jgarnett: +0 (since I am being nominated)
desruisseaux: +1
jgarnett: simone and jdeolive are on holiday
lreed n=lreed@mail.refractions.net 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.
jgarnett: :-P
(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_ n=ijturton@96.235.253.34 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: Understood
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:
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
iant_: OK
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
desruisseaux: Fine
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: hrm
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: okay;
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

Summary:
0) What is up?
1) Geotools 3
2) Dealing with feature validation
3) Governance
4) Graduation
5) Distributed Versioning Systems