The ActiveMQ project site, 2004–2007 · independent archive
Independent historical archive. This site preserves the ActiveMQ project pages that were published at activemq.org in 2004–2007. It is not the project’s website and is not affiliated with or endorsed by the Apache Software Foundation. ActiveMQ and Apache are trademarks of the ASF. For current downloads and documentation go to activemq.apache.org.

Archive › Documentation › Overview › News

Archived page

News

Archived from http://www.activemq.org/site/news.html, captured 2006-07-17 · view the capture · Added by James Strachan, last edited by James Strachan on May 12, 2006

Friday, June 16, 2006
Last changed: Jun 16, 2006 06:54 by James Strachan

We've created a performance tuning guide which takes you through the various different configurations and quality of service settings you can use to help tune your use of Apache ActiveMQ. Enjoy!

Posted at 16 Jun @ 6:51 AM by James Strachan | 0 comments
Thursday, March 23, 2006

Before posting you might want to read the Tips for getting help.

Many users prefer to use online forums rather than joining a mail list which can lead to lots more email traffic so we use the online forums at Nabble forums which also work with our Mailing Lists so that both stay completely in sync.

The old forum is here which is now deprecated.

Posted at 23 Mar @ 9:01 AM by James Strachan | 0 comments
Friday, December 9, 2005

You can surf it at https://svn.apache.org/repos/asf/incubator/activemq/.

For more details see Source.

Posted at 09 Dec @ 12:33 PM by James Strachan | 0 comments
Wednesday, November 23, 2005
Last changed: Nov 23, 2005 06:04 by James Strachan


Various users don't like joining busy email lists - we all get enough email as it is - so we've setup a discussion forum you can use as an alternative to the mail lists. Enjoy!

Posted at 23 Nov @ 6:03 AM by James Strachan | 2 comments
Wednesday, November 9, 2005

We've documented some of the new features coming along in the 4.x branch of ActiveMQ. In particular the things I'm particularly happy about are

I really love Message Groups, they totally rock! Its well worth reading the overview of what they are and how they can be useful making a partitioned high performance grid style distributed system with ordering or fast caching etc.

Posted at 09 Nov @ 10:06 PM by James Strachan | 0 comments
Wednesday, October 26, 2005
Last changed: Oct 26, 2005 03:54 by James Strachan

This new release includes the following

  • Improved Stomp 1.0 support to make it easy to create cross language clients such as for C, C#, Python, Ruby, Perl and Pike.
  • Ajax support now uses OpenRico as the default Ajax library
  • the Resource Adaptor now supports batching
  • demand based store and forward in networks
  • support for Informix JDBC
  • updated DTD for the latest Spring
  • various performance enhancements and bug fixes

For more details please see the Release Notes

Posted at 26 Oct @ 3:53 AM by James Strachan | 0 comments
Tuesday, October 11, 2005

Craig has a great post which describes how XBean can really help provide a customized XML language with Spring XML configuration extensibility. We're really happy with it so far and have moved away from XSLT and custom DOM processing to the simpler XBean model in ActiveMQ and Jencks with ServiceMix to follow suit real soon now.

Whats cool is we've just about got a working XBean Ant task to auto-generate the configuration, the XSD and HTML documentaiton now. e.g. here's the current ServiceMix generated documentation.

Posted at 11 Oct @ 9:09 PM by James Strachan | 0 comments
Wednesday, September 14, 2005

We've now migrated our real time portfolio Ajax demo to use the OpenRico library. Cool Beans!

This means you can now use an off the self Ajax library such as Rico for the browser side, then use ActiveMQ as the message broker on the server side for handling your scalable asynchronous messaging.

I'm sure we're only scratching the surface of the Ajax possibilities as we start to integrate asynchronous messaging and real time eventing into web applications.

Posted at 14 Sep @ 8:37 AM by James Strachan | 0 comments
Thursday, August 25, 2005

The long awaited ActiveMQ 3.1 Release is finally out. Who-hoo! Many thanks to all those on the Team who've helped.

This release includes support for Ruby and Perl thanks to the Stomp project together with heaps of new features such as better persistence, journalling and integration with JNDI, JCA, Servlets, Spring, WebLogic and JBoss.

Go on, Download it today!

Enjoy!

Posted at 25 Aug @ 6:33 AM by James Strachan | 0 comments
Friday, July 15, 2005
Last changed: Jul 15, 2005 11:11 by James Strachan

Craig has a great post on message driven POJOs. If you can make it to the LoneStar Software Symposium to see Craig's talk it sounds well worth attending. CoolBeans!

Also of interest is a new JIRA plugin for JMS and ActiveMQ - thanks for the heads up Mike

Posted at 15 Jul @ 11:11 AM by James Strachan | 0 comments

Confluence RSS Feed (rss_2.0)
(The 15 most recent creations of or modifications to blogposts in all Spaces.)
IRC Meeting - 10 July 2005 (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 2 on Jul 12, 2006 12:25. created by Richard Gould (rgould@refractions.net) on Jul 10, 2006 15:38

1: Confluence
2: 2.2.0 Release
3: Colour palette
4: IP Progress
5: PMC Membership

acuster: okay, on Confluence
acuster: i'm using it for the user docs right now and am running into issues
acuster: I'd like to know what our relationship is with the Confluence folk
acuster: for example, PDF export
acuster: all my images are 550px to be readable online
acuster: but that's terrible for PDf
acuster: so it's a wishlist feature for Confluence
jgarnett: confluence is willing to accept money to get work done
acuster: do we have any hope of influencing where they take things
jgarnett: we looked into it for some features needed for the uDig website
jgarnett: but it was a money kind of thing, and they were mostly outsourcing as they were swamped with popularity.
jgarnett: Not sure acuster, but the XML format is open and XSLT may be your friend?
acuster: because otherwise i'd rather work in docbook/latex in the svn tree
acuster: the other bugs I ran into i'll live with. That is all.
jgarnett: I am having my own fun in docbook, they even have an eclipse help thing these days. But seriously acuster we tried that and all it
jgarnett: did was keep people from editing the docs, even what we have now is better.
rgould: What about the possibility of moving from Confluence to another, more open, wiki project?
acuster:
jgarnett: So if I understand things you would like to ensure that the PDF output is decent, including pictures.
acuster: yeah, pdf is all I care about really
jgarnett: in a word ug, I got burned on drupal and am hating the OSGEO wikipedia stuff
acuster: it's what I use when I need to learn a library
jgarnett: I use javadocs
acuster: okay, forget it, not worth going into now. Perhaps we will revist later
acuster: next
rgould: 2.2.0 Release
jgarnett: thanks for the concerns.
rgould: So last week I went and made 2.2-RC4 jars
rgould: and put them up
rgould: and I should be able to properly release them this week
rgould: but what about releasing 2.2.0? Adrian brought up the issue that fixing up the user guide and tutorials is quite a significant effort
jgarnett: rgould I had some serious communication problems as 2.2-RC4 was rolled out, the point was to ensure it was included with GeoServer 1.3.2 and uDig 1.1.RC5
jgarnett: (probably have my version numbers wrong)
rgould: Well I let Brent know I was making the release
jgarnett: So here is the question, I am unable to help with releases from there (heck the power is out and I am running on a generator now), do you want to just make a monthly release
jgarnett: and let the other projects sort themselves out.
jgarnett: I talked to Brent, he somehow did not understand that the message mattered to him.
rgould: If we had a regular release schedule, other projects could adapt themselves to it as they needed.
acuster: jgarnett, how long will removing deprecated stuff take and does it have to be done for the long overdue 2.2.0?
jgarnett: So let me spell it out; when geoserver packages up geotools jars they take responsibility for the IP contents.
jgarnett: It does need to be done, or I will cry
acuster: that's the only thing blocking release in my mind
rgould: jgarnett, they should be doing that anyway
jgarnett: Seriously it is the only way I am going to get the library to look shipshape...
jgarnett: I think it will take an afternoon.
rgould: http://docs.codehaus.org/display/GEOTOOLS/Tasks+for+2.2.0+release
rgould: Most of the deprecated code was removed when the two modules (legacy and something else) were removed, but there is still some left.
jgarnett: the hard part is checking out geotools 2.0.0 and generating some javadocs, who knows if half the stuff is even around in maven reposiotories now?
jgarnett: in terms of user docs acuster, I was more thinking of a perge ...
jgarnett: I know it is brutal but much of the docs dates from GeoTools 2.0 or before...
jgarnett: Do you have any feedback, or user docs you would like saved?
acuster: purge, yeah, but that's hard because i need to look at each snippet/tutorial and decide if it's still going to work or not.
acuster: I'd like to move the snippets/tutorials off the main page and start over. I'd like to add a disclaimer that we don't know against which code base they work and
jgarnett: acuster I can export that stuff off to html, and make it available for download ... or we can just remove the navigation links until you are done w/ the material.
acuster: we are trying to write new tutorials/snippets
jgarnett: I am cool with that ...
rgould: I think one of the issues might be that we don't have a concrete set of documents that go out with each release. The docs are all available on the wiki and change/get out of date.
jgarnett: ... indeed will maintain the demo modules as needed.
rgould: If you look at other projects, they generally have previous versions of documentation available, just like downloads
acuster: does all of demo run?
jgarnett: rgould I intend to export the GEOTDEV and GEOTDOC
jgarnett: sapces and include them with each release.
rgould: cool
jgarnett: all of demos runs, only like 5 files right now.
jgarnett: been adding to them as I answer user list questions.
acuster: yeah, once we get a systematic set of docs we can include them.
jgarnett: we can include the developers guide now
acuster: so, can we resume what needs to happen for 2.2.0?
chorner: on 2.2.x only demo/property is running
jgarnett: 1. remove deprecations
jgarnett: 2. clean up (or out) user docs
jgarnett: 3. release
jgarnett: chorner you are correct, I have been updating demos on trunk for people.
acuster: I'll work on 2
acuster: i'd say remove demo from 2.2.x
jgarnett: acuster I will update the datastore tutorial, and at least do a basic data access demo for 2.2.x.
jgarnett: rgould can you help organize these things into jira, ... while we have people volunteering.
jgarnett: (please)
acuster: jgarnett, I'm going to add 2.0/2.1/2.2 into the navigation bar
rgould: I'll make the tasks
jgarnett: going to think about that acuster, what would the point be?
jgarnett: (thanks richard, muchly)
acuster: isolate older snippets/tutorials from current releases until they are known to still work
acuster: we already have 2.0
acuster: call what exists now 2.1
jgarnett: ah okay, I did try that approach once but it did not stick. most of the code is for geotools 2.0.0
acuster: and 2.2 is what we do from now on
jgarnett: slightly confused, but as long as you have a plan.
jgarnett: oh stupid idea
jgarnett: you can "tag" pages in confluence.
rgould: for docs: http://docs.codehaus.org/display/GEOTOOLS/Tasks+for+2.2.0+release
jgarnett: lets tag pages with the version they work against, and I we can use some macros to produce the correct list
acuster: no, I'm trying to get the navigation hierarchy and the repository hieararchy to match
rgould: acuster, can you leave a comment sayin what you are working on?
acuster: will do
jgarnett: okay, I am trying to get the navigation hierarchy to link to the UsesGuide and that is that
jgarnett: aka do we not already have too many links? I did not mean to cut off conversation...
rgould: oops, that URL should have been a JIRA
rgould: http://jira.codehaus.org/browse/GEOT-885
acuster: no, the navigation is good, it just needs to lead correctly into the tree
acuster: rgould, understood
jgarnett: okay, I do want to make sure that everything you want in the users guide is in that sepeate space, ready to be exported to pdf.
rgould: And for deprecation: http://jira.codehaus.org/browse/GEOT-886
jgarnett: but that is just how I want things, no formal decision has been made or anything...
rgould: I'm linking the tasks page to these jiras
acuster: jgarnett, another problem with pdf is that it's not built in alpha order so 1. Welcome comes before 0. TitlePage and then 2. ....
acuster: we done with (2) release?
jgarnett: That is more of a pain, I can submit a bug report of you like.
acuster: jgarnett, please
acuster: but they know, there's a comment on their doc site
jgarnett: yes we are done, lets move on before we run out of time.
jgarnett: aside: richard is there any progress on getting a new confluence license for uDig?
rgould: 3: Colour palette
rgould: oh shoot, I said I'd contact them long ago and I never did
acuster: okay, we need a standard palette of colours
rgould: jgarnett, do you have contact information for them?
jgarnett: Um is this color brewer, I do have IP comments.
acuster: the tango project shows what we should have
jgarnett: it is on their website, paul has been CCed on all communications.
acuster: http://tango.freedesktop.org/Tango_Desktop_Project
acuster: http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines
jgarnett: acuster if this is for the wiki, I can do whatever you want ...
acuster: the second has a palette that they use for their docs/icons...
acuster: Has refractions made any effort to squat a colour palette?
chorner: squat?
jgarnett: sorry?
acuster: Have any of you been systematic in the colours you use
jgarnett: We do follow the eclipse ui guidelines for uDig?
acuster: yeah, IBM blue is a registered trademark
jgarnett: not really the same thing ...
jgarnett: ah, no but we should try for black!
jgarnett: that would be fun...
acuster: so (1) has their been any attempt at consistency up to now?
acuster: if not, I'll try to match the GeoTools green/blue and think about the rest of the spectrum we need
acuster: I need a palette for my docs and I figure we should all use the same.
jgarnett: It has not been an issue, I tend to hack up the look of the site every 6 months to see if anyone still reads it near as I can tell.
jgarnett: most colors are under my control, we mostly use omondo for diagrams so consistency has not been an issue.
acuster: okay, then i'll work on my own and report back. that's all from me for (3). thanks
rgould: 4: IP Progress
jgarnett: okay, interesting, normally I cannot get anyone to talk about colours.
jgarnett: Right, I am 1/2 way through.
jgarnett: I expected feedback from module maintainers, and I would like to venture a deadline.
rgould: You are halfway through everything?
jgarnett: Of September September 1st, I do not want to have this dragging us down as we try and co-operate with the OSGEO people.
jgarnett: I am a bit dismayed at our lack of movement...
jgarnett: everything
jgarnett: see email, sent out to each module maintainer, CCed to the list.
jgarnett: each module has a review.txt file with comments and issues raised.
rgould: good idea
rgould: but is that a duplication of what's on the wiki?
jgarnett: But it is going to be time to kick more then arcsde out of the build ...
jgarnett: wiki was not working for module maintainers, trying to get them where they live - source code.
jgarnett: But rgould if you could use your perl mojo to make a document out of all the review.txt files in geotools it was be great
rgould: i'll see what I can do
jgarnett: So should I just keep beating this horse? Can anyone think of a polite way to continue?
jgarnett: After this IP check we will at least know what the issues are, which is all we wanted to start out with. Module maintainers should not feel they are
rgould: "if you don't do an IP review on your module, it's out"?
jgarnett: on their own solving these things, but please do a review at let us know how we can help as a community.
rgould: Right
jgarnett: I am going to do the review cause I want this thing to move, but I am going to ask questions before shutting things off.
jgarnett: Already modules Like GeoMedia have reported back with the permission for geotools PMC to have (C) that we need.
jgarnett: David Adler is checking w/ IBM.
acuster: thanks for all the hard work jody
jgarnett: I am sad that we have not heard from gabriel, or had any volunteer to write him a stub jar
jgarnett: So rather then rant, I am happy things are moving ...
jgarnett: does anyone have any questions?
jgarnett: (aside acuster the most popular bug is http://jira.codehaus.org/browse/GEOT-886)
jgarnett: sorry http://jira.atlassian.com/browse/CONF-2079
jgarnett: aka "More control over PDF exporting"
acuster:
FrankW tunes in.
jgarnett: chorner? I had some questions for you with respect to your modules, can you try and look into them this week?
jgarnett: Hi FrankW.
chorner: yes
jgarnett: acuster did you ever get your docuemntation license questions answered?
jgarnett: FrankW you commeted about the need to include extra license.txt files in geotools for the corner cases, like HSQL datastore, and the public domain work.
jgarnett: Is that the general approach?
jgarnett: (sorry if this is covered in the iccubation docs already)
FrankW: I'm not sure if it is the general approach.
FrankW: It is what I'm planning for GDAL.
acuster: no
FrankW: Basically, right now, careful companies wanting to use stuff like GDAL or GeoTools need to sift through everything to build up a required license document to distribute with binaries.
FrankW: I would like to help but doing that within the project.
jgarnett: acuster I will try and attend an iccubation meeting again and ask those questions for you, I am supposed to be our representative - bad jody no cookie.
jgarnett: rgould, this has consequences for uDig, we include geotools software and should pay attention to the process.
rgould nods
jgarnett: So guys I will try and place a LICENSE.TXT file in each module capturing the strange and wonderful things we go going on. Many modules already had this ...
jgarnett: That is about it for me, I should ask FrankW what is next?
jgarnett: I had thought of persuing the (C) to OSGEO angle, but perhaps he has a better suggestion?
FrankW: Well, I don't know how significant it is that the copyright is held by a group that doesn't really exist.
FrankW: It would certainly put things on clearer ground for the GeoTools PMC to assign it's copyright to the foundation.
acuster: jgarnett, do you understand the issues with a (c) held in common by various authors? i.e. will we need to ask each one to donate their (c) to OSGE or simply add OSGEO as another copyright holder?
jgarnett: Well the alternative is to make the group exist, but playing with OSGEO is more fun all around.
FrankW: I'm going to write Rich an email on this topic and see what he things.
jgarnett: acuster part of the IP review is me ensuring with the module maintainers that the (C) is assigned to the geotools PMC
jgarnett: even if I need to create a geotools PMC non profit for a year, just to hold the code to pass over to the OSGEO it would be worthwhile no?
FrankW: acuster: I think a copyright assignment should be signed by all current members of the GeoTools PMC to give it maximum legitimacy, and perhaps significant previous contributors if possible.
FrankW: jgarnett: Well, I don't think creating something legal called the GeoTools PMC would grant it ownership of the code.
jgarnett: So at the end of the day (C) 2006 Open Source Geospatial Foundation would appear on the headers, along with a list of previous holders like (C) Refractions and (C) John Smith
FrankW: Otherwise I could do that!
jgarnett: well in Canada I just need to walk into a bank with minuets of a meeting and set up a bank account, and then send out some forms...
CIA-3: 03simboss 07coverages_branch * r20449 10geotools/trunk/gt/module/referencing/ (LICENSE.txt pom.xml site/ src/ test/): -removed after merge with trunk
FrankW: jgarnett: yes, basically where there is a list of copyright holders we would be replacing just the PMC entry with OSGeo.
jgarnett: but I digress.
FrankW: jgarnett: my point is that creation of a group with that name, does not necessarily establish clear title to the geotools code.
FrankW: excuse my extra commas thrown in for no apparent reason.
jgarnett: FrankW is this a good next step, or do the iccubation lamps have any other eggs to crack?
FrankW: Well, I can't speak for the rest of the committee.
FrankW: But as mentor, I'm happy to bring GeoTools forward for graduation once IP issues are all addressed.
jgarnett: Heh, me either, but I venture you have attended a meeting more recently then me.
FrankW: Well, one thing we saw with Mapbender was that once it was recommended for graduation, folks started raising new kinds of issues.
FrankW: So that could always happen.
jgarnett: I am going to target september first, five acuster and myself a chance to clean up the website
jgarnett: we are at the end of the meeting time, rgould want to chase us through the rest of the agenda?
rgould: only one item remaining: PMC Membership
rgould: jgarnett, was that you?
jgarnett: Right, well we got some progress.
jgarnett: A couple people stepped down.
jgarnett: And simboss grabbed a couple of votes.
rgould: A couple? Who else? (I'm still catching up on email)
jgarnett: Well to be frank here is the rub, according to the Developers Guide we need like 70%
jgarnett: but we do not have 50% of PMC members who are actually out and about and voting ... so what are we going to do?
jgarnett: Coupe time? And cull the list as mentioned last week?
jgarnett: It is kind of slack letting it get to this state, apparently we miss James
rgould: Should we compose a list of idle PMCs?
FrankW: There was a procedure for removing PMC members who haven't been active in some defined way for a while, right?
FrankW: I would suggest active culling according to this criteria.
jgarnett: Bur we are a little stuck in that we cannot get out of our procedures while following our procedures...
rgould: FrankW, it requires 70% to remove one
FrankW: Ah
jgarnett: FrankW I am not sure we got a procedure that does not involve getting 70% permission from the PMC...
rgould: It sounds like we need a provision to handle idle PMCs
rgould: or
jgarnett: and I think that procedure was focused on Module Maintainers, we tend to focus on code rather then committee
CIA-3: 03simboss 07coverages_branch * r20450 10geotools/trunk/gt/plugin/epsg-hsql/ (LICENSE.txt pom.xml src/ test/): -removed after merge with trunk
rgould: What about 70% of active PMC are required to pass a vote?
jgarnett: Heh, only works if we can achive 70%
rgould: Well we can collect a list of idle PMC members and email them specifically
rgould: and hope they respond
jgarnett: (sorry this is a mess richard, I cannot yet think my way out)
rgould: James does respond when you email him
rgould: I just don't think he follows the list.
FrankW: I would suggest preparing a revised set of PMC rules, and getting broad (perhaps complete) support from active PMC members, and a blessing from the exaulted leader.
acuster: and recreate a new, active PMC
aaime: Hi guys
FrankW: I would suggest the new rules include an explicit chair with some extraordinary powers in time of crisis.
jgarnett: I did talk to him, and he recomended some form of founder status ...
rgould: hi aaime
jgarnett: unclear if it was for himself or others...
FrankW: The chair presumably being the one who would be an officer of OSGeo on behalf of Geotools.
jgarnett: I was kind of hoping to see how the GeoServer rules worked out ... but they have had no luck starting their process.
jgarnett: Interesting idea Frank
acuster: benevolent dictator of the moment
jgarnett: perhaps revamping the PMC could just be drawing up the set of rules for a PSC for interaction with OSGEO
jgarnett: no polictics or hurt feelings, ... and we need to write up how our interaction would work anyways.
acuster: sounds elegant
jgarnett: The funny part is the PMC rarely mattes, it all comes down to the module maintainers and hackers ... often in IRC breakout meetings.
jgarnett: So Rgould, Cholmes can we tag simboss as PMC, we got a number of votes.
FrankW: Right, I don't think the PMC needs to do too much, but it must ultimately be able to make decisions when needed.
jgarnett: Another set of hands would help write up a PSC and ease the transition ...
jgarnett: Or do grunt work like Rgould making the releases, thanks richard.
jgarnett: cholmes ping?
rgould: Did we get enough votes? Or should we ignore "policy" and make him PMC anyway?
FrankW: The existing PMC rules are at: http://docs.codehaus.org/display/GEOT/4+Roles+and+Responsibilities right?
rgould: no problem
jgarnett: yep.
cholmes: hey
jgarnett: To be fair given that list of responsibilities, we could probably update the list right now
rgould: jgarnett, you mentioned people stepped down. Dzwiers and ... ?
jgarnett: cholmes I am trying to set up simboss as PMC, we got votes but not the 70% of PMC needed.
jgarnett: david zwiers was who I was thinking of
rgould removes him from that page
jgarnett: (a bit sad, he could point out when my designs were stupid before I implemented them)
cholmes: I'm +1 on simboss. But yeah, we need to fix the situation.
jgarnett: Rueben has also tried to step down ...
jgarnett: we did not let him last year.
jgarnett: but perhaps the time is neigh.
jgarnett: James mentioned being promoted to "founder status" ... want to make a new heading.
rgould: It looks like we only got 4 out of 9 votes for simboss
jgarnett: but we also have no -1, or 0 votes ...
jgarnett: perhaps we are down to 4 PNC?
jgarnett: cholmes do you have any advice?
aaime: (+1 from an ex-PMC!)
jgarnett: heh, be careful we may tag you back in.
cholmes: What was the response from the 'clean and sweep' ?
rgould: I don't think there is anyone here who would not like to see simboss as PMC
aaime: I would not complain
jgarnett: or andrea for that matter
jgarnett: the response was good, got a better response for posting the IRC logs.
jgarnett: martin did go through the logs, and respond publically.
jgarnett: I cannot remember if richard did
rgould will make gtbot email logs out in the future
rgould: I did go through the logs
rgould: did not respond
jgarnett: did you vote
rgould: on simboss, yeah
jgarnett: okay while we have andrea's attention.
jgarnett: I would like to nominate Andrea back in the ring for geotools PMC
aaime: I'm not against it, but it will take some time before I'm back at full steam
simboss: (+2 on this one...)
jgarnett: +1
rgould: Is there a different procedure for ex-pmc members? Otherwise, we are stuck on the same problem as simboss
rgould: +1
jgarnett: indeed
jgarnett: if only they could vote for each other ...
cholmes: +1
acuster: let's break the rules, they are clearly not working and simply reform a viable PMC
acuster: if anyone objects we can do something about it.
jgarnett: okay I am not interested in screwing around on this for another week, or we begin to resemble the formation of the geoserver PSC (dig dig)
rgould: acuster, I am in agreement
acuster: but no one is going to object, because everyone sees that it's needed
jgarnett: As a current PMC, I will update the list
FrankW: Right, so just go ahead, giving a couple days for anyone to object if they wish to.
jgarnett: rgould can you go over email and see who responded from the PMC in the last week?
acuster: cool
rgould: jgarnett, in any email whatsoever? sure
jgarnett: that will do, responsibilities were to respond to IRC Logs, but I will take any sign of life
rgould: ok
rgould: Shall we close the meeting then?
acuster: +1
jgarnett: rgould if you can give me the list of names publically
FrankW: +1
rgould: Yes, I will email them out.
jgarnett: I would really like to keep this as above bord as we can.
rgould: Ok. Let me welcome simboss to the PMC, and aaime back to the PMC
acuster: jgarnett, http://jira.atlassian.com/browse/CONF-6543 and http://jira.atlassian.com/browse/CONF-6544 since you got me started
jgarnett: simboss, andrea, I hope that with a revised list we can proceed, as you can see you are needed.
acuster: congrats simboss aaime !
rgould: Ok, we are done
aaime: Thank you

Changes between revision 1 and revision 2:

view all revisions | revert page to version 1
 {excerpt}
 1: Confluence
 2: 2.2.0 Release
 3: Colour palette
 4: IP Progress
 5: PMC Membership
 {excerpt}
   
 acuster: okay, on Confluence
 acuster: i'm using it for the user docs right now and am running into issues
 acuster: I'd like to know what our relationship is with the Confluence folk
 acuster: for example, PDF export
 acuster: all my images are 550px to be readable online
 acuster: but that's terrible for PDf
 acuster: so it's a wishlist feature for Confluence
 jgarnett: confluence is willing to accept money to get work done
 acuster: do we have any hope of influencing where they take things
 jgarnett: we looked into it for some features needed for the uDig website
 jgarnett: but it was a money kind of thing, and they were mostly outsourcing as they were swamped with popularity.
 jgarnett: Not sure acuster, but the XML format is open and XSLT may be your friend?
 acuster: because otherwise i'd rather work in docbook/latex in the svn tree
 acuster: the other bugs I ran into i'll live with. That is all.
 jgarnett: I am having my own fun in docbook, they even have an eclipse help thing these days. But seriously acuster we tried that and all it
 jgarnett: did was keep people from editing the docs, even what we have now is better.
 rgould: What about the possibility of moving from Confluence to another, more open, wiki project?
 acuster: :-)
 jgarnett: So if I understand things you would like to ensure that the PDF output is decent, including pictures.
 acuster: yeah, pdf is all I care about really
 jgarnett: in a word ug, I got burned on drupal and am hating the OSGEO wikipedia stuff
 acuster: it's what I use when I need to learn a library
 jgarnett: I use javadocs ;-)
 acuster: okay, forget it, not worth going into now. Perhaps we will revist later
 acuster: next
 rgould: 2.2.0 Release
 jgarnett: thanks for the concerns.
 rgould: So last week I went and made 2.2-RC4 jars
 rgould: and put them up
 rgould: and I should be able to properly release them this week
 rgould: but what about releasing 2.2.0? Adrian brought up the issue that fixing up the user guide and tutorials is quite a significant effort
 jgarnett: rgould I had some serious communication problems as 2.2-RC4 was rolled out, the point was to ensure it was included with GeoServer 1.3.2 and uDig 1.1.RC5
 jgarnett: (probably have my version numbers wrong)
 rgould: Well I let Brent know I was making the release
 jgarnett: So here is the question, I am unable to help with releases from there (heck the power is out and I am running on a generator now), do you want to just make a monthly release
 jgarnett: and let the other projects sort themselves out.
 jgarnett: I talked to Brent, he somehow did not understand that the message mattered to him.
 rgould: If we had a regular release schedule, other projects could adapt themselves to it as they needed.
 acuster: jgarnett, how long will removing deprecated stuff take and does it have to be done for the long overdue 2.2.0?
 jgarnett: So let me spell it out; when geoserver packages up geotools jars they take responsibility for the IP contents.
 jgarnett: It does need to be done, or I will cry ;-)
 acuster: that's the only thing blocking release in my mind
 rgould: jgarnett, they should be doing that anyway
 jgarnett: Seriously it is the only way I am going to get the library to look shipshape...
 jgarnett: I think it will take an afternoon.
 rgould: http://docs.codehaus.org/display/GEOTOOLS/Tasks+for+2.2.0+release
 rgould: Most of the deprecated code was removed when the two modules (legacy and something else) were removed, but there is still some left.
 jgarnett: the hard part is checking out geotools 2.0.0 and generating some javadocs, who knows if half the stuff is even around in maven reposiotories now?
 jgarnett: in terms of user docs acuster, I was more thinking of a perge ...
 jgarnett: I know it is brutal but much of the docs dates from GeoTools 2.0 or before...
 jgarnett: Do you have any feedback, or user docs you would like saved?
 acuster: purge, yeah, but that's *hard* because i need to look at each snippet/tutorial and decide if it's still going to work or not.
 acuster: I'd like to move the snippets/tutorials off the main page and start over. I'd like to add a disclaimer that we don't know against which code base they work and
 jgarnett: acuster I can export that stuff off to html, and make it available for download ... or we can just remove the navigation links until you are done w/ the material.
 acuster: we are trying to write new tutorials/snippets
 jgarnett: I am cool with that ...
 rgould: I think one of the issues might be that we don't have a concrete set of documents that go out with each release. The docs are all available on the wiki and change/get out of date.
 jgarnett: ... indeed will maintain the demo modules as needed.
 rgould: If you look at other projects, they generally have previous versions of documentation available, just like downloads
 acuster: does all of demo run?
 jgarnett: rgould I intend to export the GEOTDEV and GEOTDOC
 jgarnett: sapces and include them with each release.
 rgould: cool
 jgarnett: all of demos runs, only like 5 files right now.
 jgarnett: been adding to them as I answer user list questions.
 acuster: yeah, once we get a systematic set of docs we can include them.
 jgarnett: we can include the developers guide now
 acuster: so, can we resume what needs to happen for 2.2.0?
 chorner: on 2.2.x only demo/property is running
 jgarnett: 1. remove deprecations
 jgarnett: 2. clean up (or out) user docs
 jgarnett: 3. release
 jgarnett: chorner you are correct, I have been updating demos on trunk for people.
 acuster: I'll work on 2
 acuster: i'd say remove demo from 2.2.x
 jgarnett: acuster I will update the datastore tutorial, and at least do a basic data access demo for 2.2.x.
 jgarnett: rgould can you help organize these things into jira, ... while we have people volunteering.
 jgarnett: (please)
 acuster: jgarnett, I'm going to add 2.0/2.1/2.2 into the navigation bar
 rgould: I'll make the tasks
 jgarnett: going to think about that acuster, what would the point be?
 jgarnett: (thanks richard, muchly)
 acuster: isolate older snippets/tutorials from current releases until they are known to still work
 acuster: we already have 2.0
 acuster: call what exists now 2.1
 jgarnett: ah okay, I did try that approach once but it did not stick. most of the code is for geotools 2.0.0
 acuster: and 2.2 is what we do from now on
 jgarnett: slightly confused, but as long as you have a plan.
 jgarnett: oh stupid idea
 jgarnett: you can "tag" pages in confluence.
 rgould: for docs: http://docs.codehaus.org/display/GEOTOOLS/Tasks+for+2.2.0+release
 jgarnett: lets tag pages with the version they work against, and I we can use some macros to produce the correct list ;-)
 acuster: no, I'm trying to get the navigation hierarchy and the repository hieararchy to match
 rgould: acuster, can you leave a comment sayin what you are working on?
 acuster: will do
 jgarnett: okay, I am trying to get the navigation hierarchy to link to the UsesGuide and that is that ;-)
 jgarnett: aka do we not already have too many links? I did not mean to cut off conversation...
 rgould: oops, that URL should have been a JIRA
 rgould: http://jira.codehaus.org/browse/GEOT-885
 acuster: no, the navigation is good, it just needs to lead correctly into the tree
 acuster: rgould, understood
 jgarnett: okay, I do want to make sure that everything you want in the users guide is in that sepeate space, ready to be exported to pdf.
 rgould: And for deprecation: http://jira.codehaus.org/browse/GEOT-886
 jgarnett: but that is just how I want things, no formal decision has been made or anything...
 rgould: I'm linking the tasks page to these jiras
 acuster: jgarnett, another problem with pdf is that it's not built in alpha order so 1. Welcome comes before 0. TitlePage and then 2. ....
 acuster: we done with (2) release?
 jgarnett: That is more of a pain, I can submit a bug report of you like.
 acuster: jgarnett, please
 acuster: but they know, there's a comment on their doc site
 jgarnett: yes we are done, lets move on before we run out of time.
 jgarnett: aside: richard is there any progress on getting a new confluence license for uDig?
 rgould: 3: Colour palette
 rgould: oh shoot, I said I'd contact them long ago and I never did
 acuster: okay, we need a standard palette of colours
 rgould: jgarnett, do you have contact information for them?
 jgarnett: Um is this color brewer, I do have IP comments.
 acuster: the tango project shows what we should have
 jgarnett: it is on their website, paul has been CCed on all communications.
 acuster: http://tango.freedesktop.org/Tango_Desktop_Project
 acuster: http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines
 jgarnett: acuster if this is for the wiki, I can do whatever you want ...
 acuster: the second has a palette that they use for their docs/icons...
 acuster: Has refractions made any effort to squat a colour palette?
 chorner: squat?
 jgarnett: sorry?
 acuster: Have any of you been systematic in the colours you use
 jgarnett: We do follow the eclipse ui guidelines for uDig?
 acuster: yeah, IBM blue is a registered trademark
 jgarnett: not really the same thing ...
 jgarnett: ah, no but we should try for black!
 jgarnett: that would be fun...
 acuster: so (1) has their been any attempt at consistency up to now?
 acuster: if not, I'll try to match the GeoTools green/blue and think about the rest of the spectrum we need
 acuster: I need a palette for my docs and I figure we should all use the same.
 jgarnett: It has not been an issue, I tend to hack up the look of the site every 6 months to see if anyone still reads it near as I can tell.
 jgarnett: most colors are under my control, we mostly use omondo for diagrams so consistency has not been an issue.
 acuster: okay, then i'll work on my own and report back. that's all from me for (3). thanks
 rgould: 4: IP Progress
 jgarnett: okay, interesting, normally I cannot get anyone to talk about colours.
 jgarnett: Right, I am 1/2 way through.
 jgarnett: I expected feedback from module maintainers, and I would like to venture a deadline.
 rgould: You are halfway through *everything*?
 jgarnett: Of September September 1st, I do not want to have this dragging us down as we try and co-operate with the OSGEO people.
 jgarnett: I am a bit dismayed at our lack of movement...
 jgarnett: *everything*
 jgarnett: see email, sent out to each module maintainer, CCed to the list.
 jgarnett: each module has a review.txt file with comments and issues raised.
 rgould: good idea
 rgould: but is that a duplication of what's on the wiki?
 jgarnett: But it is going to be time to kick more then arcsde out of the build ... :-(
 jgarnett: wiki was not working for module maintainers, trying to get them where they live - source code.
 jgarnett: But rgould if you could use your perl mojo to make a document out of all the review.txt files in geotools it was be *great*
 rgould: i'll see what I can do
 jgarnett: So should I just keep beating this horse? Can anyone think of a polite way to continue?
 jgarnett: After this IP check we will at least know what the issues are, which is all we wanted to start out with. Module maintainers should not feel they are
 rgould: "if you don't do an IP review on your module, it's out"?
 jgarnett: on their own solving these things, but please do a review at let us know how we can help as a community.
 rgould: Right
 jgarnett: I am going to do the review cause I want this thing to move, but I am going to ask questions before shutting things off.
 jgarnett: Already modules Like GeoMedia have reported back with the permission for geotools PMC to have (C) that we need.
 jgarnett: David Adler is checking w/ IBM.
 acuster: thanks for all the hard work jody
 jgarnett: I am sad that we have not heard from gabriel, or had any volunteer to write him a stub jar :-(
 jgarnett: So rather then rant, I am happy things are moving ...
 jgarnett: does anyone have any questions?
 jgarnett: (aside acuster the most popular bug is http://jira.codehaus.org/browse/GEOT-886)
 jgarnett: sorry http://jira.atlassian.com/browse/CONF-2079
 jgarnett: aka "More control over PDF exporting"
 acuster: :-)
 FrankW tunes in.
 jgarnett: chorner? I had some questions for you with respect to your modules, can you try and look into them this week?
 jgarnett: Hi FrankW.
 chorner: yes
 jgarnett: acuster did you ever get your docuemntation license questions answered?
 jgarnett: FrankW you commeted about the need to include extra license.txt files in geotools for the corner cases, like HSQL datastore, and the public domain work.
 jgarnett: Is that the general approach?
 jgarnett: (sorry if this is covered in the iccubation docs already)
 FrankW: I'm not sure if it is the general approach.
 FrankW: It is what I'm planning for GDAL.
 acuster: no
 FrankW: Basically, right now, careful companies wanting to use stuff like GDAL or GeoTools need to sift through everything to build up a required license document to distribute with binaries.
 FrankW: I would like to help but doing that within the project.
 jgarnett: acuster I will try and attend an iccubation meeting again and ask those questions for you, I am supposed to be our representative - bad jody no cookie.
 jgarnett: rgould, this has consequences for uDig, we include geotools software and should pay attention to the process.
 rgould nods
 jgarnett: So guys I will try and place a LICENSE.TXT file in each module capturing the strange and wonderful things we go going on. Many modules already had this ...
 jgarnett: That is about it for me, I should ask FrankW what is next?
 jgarnett: I had thought of persuing the (C) to OSGEO angle, but perhaps he has a better suggestion?
 FrankW: Well, I don't know how significant it is that the copyright is held by a group that doesn't really exist.
 FrankW: It would certainly put things on clearer ground for the GeoTools PMC to assign it's copyright to the foundation.
 acuster: jgarnett, do you understand the issues with a (c) held in common by various authors? i.e. will we need to ask each one to donate their (c) to OSGE or simply add OSGEO as another copyright holder?
 jgarnett: Well the alternative is to make the group exist, but playing with OSGEO is more fun all around.
 FrankW: I'm going to write Rich an email on this topic and see what he things.
 jgarnett: acuster part of the IP review is me ensuring with the module maintainers that the (C) is assigned to the geotools PMC
 jgarnett: even if I need to create a geotools PMC non profit for a year, just to hold the code to pass over to the OSGEO it would be worthwhile no?
 FrankW: acuster: I think a copyright assignment should be signed by all current members of the GeoTools PMC to give it maximum legitimacy, and perhaps significant previous contributors if possible.
 FrankW: jgarnett: Well, I don't think creating something legal called the GeoTools PMC would grant it ownership of the code.
 jgarnett: So at the end of the day (C) 2006 Open Source Geospatial Foundation would appear on the headers, along with a list of previous holders like (C) Refractions and (C) John Smith
 FrankW: Otherwise I could do that!
 jgarnett: well in Canada I just need to walk into a bank with minuets of a meeting and set up a bank account, and then send out some forms...
 CIA-3: 03simboss 07coverages_branch * r20449 10geotools/trunk/gt/module/referencing/ (LICENSE.txt pom.xml site/ src/ test/): -removed after merge with trunk
 FrankW: jgarnett: yes, basically where there is a list of copyright holders we would be replacing just the PMC entry with OSGeo.
 jgarnett: but I digress.
 FrankW: jgarnett: my point is that creation of a group with that name, does not necessarily establish clear title to the geotools code.
 FrankW: excuse my extra commas thrown in for no apparent reason.
 jgarnett: FrankW is this a good next step, or do the iccubation lamps have any other eggs to crack?
 FrankW: Well, I can't speak for the rest of the committee.
 FrankW: But as mentor, I'm happy to bring GeoTools forward for graduation once IP issues are all addressed.
 jgarnett: Heh, me either, but I venture you have attended a meeting more recently then me.
 FrankW: Well, one thing we saw with Mapbender was that once it was recommended for graduation, folks started raising new kinds of issues.
 FrankW: So that could always happen.
 jgarnett: I am going to target september first, five acuster and myself a chance to clean up the website ;-)
 jgarnett: we are at the end of the meeting time, rgould want to chase us through the rest of the agenda?
 rgould: only one item remaining: PMC Membership
 rgould: jgarnett, was that you?
 jgarnett: Right, well we got some progress.
 jgarnett: A couple people stepped down.
 jgarnett: And simboss grabbed a couple of votes.
 rgould: A couple? Who else? (I'm still catching up on email)
 jgarnett: Well to be frank here is the rub, according to the Developers Guide we need like 70%
 jgarnett: but we do not have 50% of PMC members who are actually out and about and voting ... so what are we going to do?
 jgarnett: Coupe time? And cull the list as mentioned last week?
 jgarnett: It is kind of slack letting it get to this state, apparently we miss James ;-)
 rgould: Should we compose a list of idle PMCs?
 FrankW: There was a procedure for removing PMC members who haven't been active in some defined way for a while, right?
 FrankW: I would suggest active culling according to this criteria.
 jgarnett: Bur we are a little stuck in that we cannot get out of our procedures while following our procedures...
 rgould: FrankW, it requires 70% to remove one ;)
 FrankW: Ah
 jgarnett: FrankW I am not sure we got a procedure that does not involve getting 70% permission from the PMC...
 rgould: It sounds like we need a provision to handle idle PMCs
 rgould: or
 jgarnett: and I think that procedure was focused on Module Maintainers, we tend to focus on code rather then committee
 CIA-3: 03simboss 07coverages_branch * r20450 10geotools/trunk/gt/plugin/epsg-hsql/ (LICENSE.txt pom.xml src/ test/): -removed after merge with trunk
 rgould: What about 70% of active PMC are required to pass a vote?
 jgarnett: Heh, only works if we can achive 70% ;-)
 rgould: Well we can collect a list of idle PMC members and email them specifically
 rgould: and hope they respond
 jgarnett: (sorry this is a mess richard, I cannot yet think my way out)
 rgould: James does respond when you email him
 rgould: I just don't think he follows the list.
 FrankW: I would suggest preparing a revised set of PMC rules, and getting broad (perhaps complete) support from active PMC members, and a blessing from the exaulted leader.
 acuster: and recreate a new, active PMC
 aaime: Hi guys
 FrankW: I would suggest the new rules include an explicit chair with some extraordinary powers in time of crisis.
 jgarnett: I did talk to him, and he recomended some form of founder status ...
 rgould: hi aaime
 jgarnett: unclear if it was for himself or others...
 FrankW: The chair presumably being the one who would be an officer of OSGeo on behalf of Geotools.
 jgarnett: I was kind of hoping to see how the GeoServer rules worked out ... but they have had no luck starting their process.
 jgarnett: Interesting idea Frank
 acuster: benevolent dictator of the moment
 jgarnett: perhaps revamping the PMC could just be drawing up the set of rules for a PSC for interaction with OSGEO
 jgarnett: no polictics or hurt feelings, ... and we need to write up how our interaction would work anyways.
 acuster: sounds elegant
 jgarnett: The funny part is the PMC rarely mattes, it all comes down to the module maintainers and hackers ... often in IRC breakout meetings.
 jgarnett: So Rgould, Cholmes can we tag simboss as PMC, we got a number of votes.
 FrankW: Right, I don't think the PMC needs to do too much, but it must ultimately be able to make decisions when needed.
 jgarnett: Another set of hands would help write up a PSC and ease the transition ...
 jgarnett: Or do grunt work like Rgould making the releases, thanks richard.
 jgarnett: cholmes ping?
 rgould: Did we get enough votes? Or should we ignore "policy" and make him PMC anyway?
 FrankW: The existing PMC rules are at: http://docs.codehaus.org/display/GEOT/4+Roles+and+Responsibilities right?
 rgould: no problem
 jgarnett: yep.
 cholmes: hey
 jgarnett: To be fair given that list of responsibilities, we could probably update the list right now ;-)
 rgould: jgarnett, you mentioned people stepped down. Dzwiers and ... ?
 jgarnett: cholmes I am trying to set up simboss as PMC, we got votes but not the 70% of PMC needed.
 jgarnett: david zwiers was who I was thinking of
 rgould removes him from that page
 jgarnett: (a bit sad, he could point out when my designs were stupid before I implemented them)
 cholmes: I'm +1 on simboss. But yeah, we need to fix the situation.
 jgarnett: Rueben has also tried to step down ...
 jgarnett: we did not let him last year.
 jgarnett: but perhaps the time is neigh.
 jgarnett: James mentioned being promoted to "founder status" ... want to make a new heading.
 rgould: It looks like we only got 4 out of 9 votes for simboss
 jgarnett: but we also have no -1, or 0 votes ...
 jgarnett: perhaps we are down to 4 PNC?
 jgarnett: cholmes do you have any advice?
 aaime: (+1 from an ex-PMC!) :-)
 jgarnett: heh, be careful we may tag you back in.
 cholmes: What was the response from the 'clean and sweep' ?
 rgould: I don't think there is anyone here who would not like to see simboss as PMC :)
 aaime: I would not complain ;-)
 jgarnett: or andrea for that matter ;-)
 jgarnett: the response was good, got a better response for posting the IRC logs.
 jgarnett: martin did go through the logs, and respond publically.
 jgarnett: I cannot remember if richard did ;-)
 rgould will make gtbot email logs out in the future
 rgould: I did go through the logs
 rgould: did not respond
 jgarnett: did you vote ;-)
 rgould: on simboss, yeah
 jgarnett: okay while we have andrea's attention.
 jgarnett: I would like to nominate Andrea back in the ring for geotools PMC
 aaime: I'm not against it, but it will take some time before I'm back at full steam
 simboss: (+2 on this one...)
 jgarnett: +1
 rgould: Is there a different procedure for ex-pmc members? Otherwise, we are stuck on the same problem as simboss
 rgould: +1
 jgarnett: indeed
 jgarnett: if only they could vote for each other ...
 cholmes: +1
 acuster: let's break the rules, they are clearly not working and simply reform a viable PMC
 acuster: if anyone objects we can do something about it.
 jgarnett: okay I am not interested in screwing around on this for another week, or we begin to resemble the formation of the geoserver PSC (dig dig)
 rgould: acuster, I am in agreement
 acuster: but no one is going to object, because everyone sees that it's needed
 jgarnett: As a current PMC, I will update the list ;-)
 FrankW: Right, so just go ahead, giving a couple days for anyone to object if they wish to.
 jgarnett: rgould can you go over email and see who responded from the PMC in the last week?
 acuster: cool
 rgould: jgarnett, in any email whatsoever? sure
 jgarnett: that will do, responsibilities were to respond to IRC Logs, but I will take any sign of life
 rgould: ok
 rgould: Shall we close the meeting then?
 acuster: +1
 jgarnett: rgould if you can give me the list of names publically
 FrankW: +1
 rgould: Yes, I will email them out.
 jgarnett: I would really like to keep this as above bord as we can.
 rgould: Ok. Let me welcome simboss to the PMC, and aaime back to the PMC :)
 acuster: jgarnett, http://jira.atlassian.com/browse/CONF-6543 and http://jira.atlassian.com/browse/CONF-6544 since you got me started
 jgarnett: simboss, andrea, I hope that with a revised list we can proceed, as you can see you are needed.
 acuster: congrats simboss aaime !
 rgould: Ok, we are done
 aaime: Thank you
IRC Grid Coverage Merge Breakout July 6th (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 2 on Jul 12, 2006 12:24. created by Jody Garnett (jgarnett@refractions.net) on Jul 07, 2006 03:46

Martin and Simboss coordinate on Grid Coverage Branch merge; and then just talk shop

[06/07/2006 21:09] <simboss> martin?
[06/07/2006 21:10] <desruisseaux> Hello Simmone
[06/07/2006 21:28] <simboss> are we waiting for someone else?
[06/07/2006 21:29] <simboss> I am trying to ping aaime
[06/07/2006 21:29] <aaime> Hi guys
[06/07/2006 21:29] <aaime> Nice subject
[06/07/2006 21:29] <desruisseaux> Hello all
[06/07/2006 21:30] <simboss> trying to see if I can get jody here
[06/07/2006 21:30] <aaime> So, how is it going with the merge?
[06/07/2006 21:31] <aaime> I can call him
[06/07/2006 21:31] <simboss> that would be good
[06/07/2006 21:32] <aaime> They're looking for him at Bluesphere
[06/07/2006 21:32] <desruisseaux> Checking for the change is easy enough. I don't know yet however or big the changes are. I just finished ImageUtilities, but I have not yet tested it. I'm writing a test suite for ImageWorker now.
[06/07/2006 21:32] <aaime> Maybe he's in the kitchen eating something
[06/07/2006 21:32] <aaime> Oh, ImageUtilities extra methods were untested?
[06/07/2006 21:33] <desruisseaux> ImageUtilities itself is unchanged (compared to the coverage branch)
[06/07/2006 21:33] <desruisseaux> The new methods are in a new, different class.
[06/07/2006 21:33] <desruisseaux> ImageWorker.
[06/07/2006 21:33] <desruisseaux> Tests are in progress.
[06/07/2006 21:34] <simboss> cool
[06/07/2006 21:34] <aaime> It is my understanding that we cannot start merging the plugins until you've finished with the coverage module
[06/07/2006 21:34] <aaime> Plugin merging could be done in parallelo
[06/07/2006 21:34] <aaime> (parallel, sorry)
[06/07/2006 21:35] <desruisseaux> Yes. But I'm watching all the changes done in the coverage branch. If a see that a class that I already ported has been changed, I will port the changes.
[06/07/2006 21:35] <desruisseaux> I have been much slower than I hoped, because JSR-275 eated the majority of my time.
[06/07/2006 21:35] <simboss> don't worry
[06/07/2006 21:36] <simboss> have you had a chance to look at
[06/07/2006 21:36] <simboss> the new operations?
[06/07/2006 21:36] <desruisseaux> Just a very fast look, but I have not yet reached this point in the mergE.
[06/07/2006 21:37] <desruisseaux> I'm working on a package-by-package basis.
[06/07/2006 21:37] <aaime> JSR-275 --> units?
[06/07/2006 21:37] <simboss> on which packages are you focusing?
[06/07/2006 21:38] <desruisseaux> My work in New-Caledonia will be finished in one or two week. I will take the plane on July 25, back to France. When I will be back there, I may have a chance to attend more often to IRC meeting.
[06/07/2006 21:38] <desruisseaux> Yesn JSR-275 is javax.units.
[06/07/2006 21:38] <simboss> I thought you were working exclusivelu on the coverage package
[06/07/2006 21:38] <desruisseaux> No. I was sharing my time between the coverage branch and JSR-275 (I announced that in some email).
[06/07/2006 21:39] <desruisseaux> Geotools is currently working with JSR-108, which has been withdrawn.
[06/07/2006 21:39] <desruisseaux> JSR-275 is a new attempt to get a javax.units package, with a new expert group.
[06/07/2006 21:39] <desruisseaux> But the work is not going as fast as it should. Basically, everybody is hopping that somebody else will do the work.
[06/07/2006 21:40] <simboss> exclusively meant with respect to the other modules
[06/07/2006 21:40] <desruisseaux> We realized that if we do not start writting a specification very soon, Sun will withdrawn JSR-275 again. With no hope to get a new start this time.
[06/07/2006 21:40] <desruisseaux> So it is a kind of urgent work, and I took vacation time for that because I realized that nobody was about to do this work in the JSR-275 group.
[06/07/2006 21:41] <desruisseaux> I wanted to do both JSR-275 and the coverage branch.
[06/07/2006 21:41] <desruisseaux> And none of them are as far as I hoped.
[06/07/2006 21:42] <desruisseaux> (I means, I didn't do one third of the work I hoped to do).
[06/07/2006 21:42] <simboss> well let's see how we can speed geotools work up
[06/07/2006 21:43] <simboss> which modules have you been looking at so far?
[06/07/2006 21:43] <desruisseaux> I'm focusing exclusively on module/coverage.
[06/07/2006 21:44] <desruisseaux> I would like to let plugin and module/main to other volunters...
[06/07/2006 21:44] <simboss> ok
[06/07/2006 21:45] <simboss> I will take plugins
[06/07/2006 21:45] <simboss> how are we going to decide about the others?
[06/07/2006 21:45] <desruisseaux> Thanks.
[06/07/2006 21:45] <simboss> other modules I mean
[06/07/2006 21:46] <desruisseaux> Maybe we need to ask to Jody about main? (did you made some changes in gt/module/main?)
[06/07/2006 21:46] <desruisseaux> Note: gt/module/referencing is done - we should have nothing more to port for this module.
[06/07/2006 21:47] <simboss> In main I made minor changes
[06/07/2006 21:47] <simboss> the most important
[06/07/2006 21:47] <simboss> is a class that should act as a superclass for all readers of gridcoverage2d
[06/07/2006 21:47] <simboss> AbstractGridCoverage2DReader
[06/07/2006 21:47] <simboss> or something like it
[06/07/2006 21:48] <simboss> I also tried to clean up here and there
[06/07/2006 21:48] <simboss> but nothing so important besides this
[06/07/2006 21:49] <desruisseaux> Would you have time for taking the task of merging gt/module/main (maybe together with Jody)?
[06/07/2006 21:50] <simboss> mmmhhh
[06/07/2006 21:50] <simboss> I might
[06/07/2006 21:50] <simboss> it should ne hard at all
[06/07/2006 21:50] <simboss> and besides
[06/07/2006 21:50] <simboss> without it
[06/07/2006 21:50] <simboss> I cannot proceed again
[06/07/2006 21:50] <simboss> since I need the above mentioned class
[06/07/2006 21:51] <simboss> otherwise most plugins wown't work
[06/07/2006 21:51] <simboss> at all
[06/07/2006 21:52] <aaime> Once you have done that I can take some plugins and merge them
[06/07/2006 21:53] <simboss> what about streaming renderer
[06/07/2006 21:53] <simboss> would you rather take on that aaime?
[06/07/2006 21:54] <simboss> it should basically be
[06/07/2006 21:54] <simboss> a take and replace
[06/07/2006 21:54] <simboss> with the old one
[06/07/2006 21:54] <simboss> same thing s going to happen with pugins
[06/07/2006 21:54] <simboss> more or less
[06/07/2006 21:54] <simboss> except only for arcgrid
[06/07/2006 21:54] <simboss> becuse the new one is not ready yet
[06/07/2006 21:55] <simboss> (very close to be ready though )
[06/07/2006 21:55] <aaime> Yes, I think I can
[06/07/2006 21:55] <aaime> Jody is on his way here
[06/07/2006 21:56] <desruisseaux> That would be nice . If you meet a dependency toward gt/module/coverage which is not yet merged, you could email me so I give the priority to those specific classes.
[06/07/2006 21:56] <simboss> well
[06/07/2006 21:56] <simboss> basically
[06/07/2006 21:56] <simboss> plugins
[06/07/2006 21:56] <simboss> need imageutilies
[06/07/2006 21:56] <desruisseaux> This one is done
[06/07/2006 21:57] <jgarnett> hello
[06/07/2006 21:57] <desruisseaux> Hello Jody.
[06/07/2006 21:57] <aaime> Martin, yes, I'll do
[06/07/2006 21:57] <simboss> gridcoverage renderer
[06/07/2006 21:57] <simboss> needs the new operation
[06/07/2006 21:57] <simboss> plugins and streaming renderer
[06/07/2006 21:58] <simboss> need abstractgridcoverage2dreader
[06/07/2006 21:58] <simboss> streaming renderer need some minor changes I made to ReferencedEnvelope
[06/07/2006 21:59] <simboss> in order to interoperate
[06/07/2006 21:59] <simboss> between geoapi envelopes
[06/07/2006 21:59] <simboss> and referenced envelopes
[06/07/2006 21:59] <simboss> this is more or less where we are
[06/07/2006 21:59] <aaime> So without the new opetation I can't merge the new streaming renderer (at least the parts that do renderer coverages)
[06/07/2006 21:59] <simboss> in terms of dependencies
[06/07/2006 21:59] <simboss> no
[06/07/2006 21:59] <simboss> main
[06/07/2006 21:59] <simboss> and coverage
[06/07/2006 22:00] <simboss> are prerequisites to do all the work
[06/07/2006 22:02] <desruisseaux> So the work can start now (if we wish) for gt/module/main, and hopefully I may get some operations done in the main time?
[06/07/2006 22:02] <simboss> that would be great
[06/07/2006 22:02] <simboss> Tomorrow I will try to merge
[06/07/2006 22:02] <simboss> main
[06/07/2006 22:03] <simboss> it should not be that hard
[06/07/2006 22:03] <simboss> I did the inverse thing more than once without problems
[06/07/2006 22:04] <aaime> Ok, so we are set?
[06/07/2006 22:04] <aaime> Can someone inform me when all the operations are merged?
[06/07/2006 22:05] <desruisseaux> Yes, I will post on the mailing list.
[06/07/2006 22:05] <simboss> sorry guys
[06/07/2006 22:05] <simboss> I have a couple of questions more
[06/07/2006 22:05] <simboss> since we have here martin
[06/07/2006 22:06] <simboss> let's abuse of his time a little bit
[06/07/2006 22:06] <simboss> if he agrees of course
[06/07/2006 22:06] <desruisseaux> Sure, but let see if I'm able to propose an answer...
[06/07/2006 22:06] <desruisseaux> ?
[06/07/2006 22:07] <simboss> 1>Can you spend a few workd about the work on rendering?
[06/07/2006 22:07] <simboss> I might help you out
[06/07/2006 22:08] <simboss> but I have not much time for the moment
[06/07/2006 22:08] <simboss> I might find a student to do some work for us though
[06/07/2006 22:08] <simboss> (done with question 1)
[06/07/2006 22:08] <desruisseaux> There is the picture:
[06/07/2006 22:09] <desruisseaux> There is two distinct project planned: a 2D and a 3D renderer.
[06/07/2006 22:09] <desruisseaux> The 2D renderer would be a GO-1 implementation.
[06/07/2006 22:09] <desruisseaux> The code would be J2D-renderer refactored + streaming renderer.
[06/07/2006 22:10] <desruisseaux> Some of this work put the basis for a 3D renderer as well (even if it is out of 2D renderer scope).
[06/07/2006 22:10] <desruisseaux> I means, some base classes can apply to both 2D and 3D renderer.
[06/07/2006 22:10] <desruisseaux> I will do the work for the 2D renderer after the coverage branch merge.
[06/07/2006 22:10] <desruisseaux> My priority order is:
[06/07/2006 22:11] <desruisseaux> 1) get out of my current work (leaving very soon)
[06/07/2006 22:11] <desruisseaux> 2) Coverage branch merge
[06/07/2006 22:11] <desruisseaux> 3) GO-1 renderer (2D only)
[06/07/2006 22:12] <desruisseaux> We are in contact with two computer teachers in Marseille.
[06/07/2006 22:12] <desruisseaux> Those two teachers are planning a 3D renderer with a team of 4 students.
[06/07/2006 22:13] <simboss> ok
[06/07/2006 22:13] <jgarnett> I should probably come clean with my work prority as well
[06/07/2006 22:13] <desruisseaux> The 3D renderer would build on top of the 2D renderer part which is common to 2D and 3D.
[06/07/2006 22:13] <jgarnett> 1) FM
[06/07/2006 22:13] <jgarnett> 2) Catalog
[06/07/2006 22:13] <jgarnett> 3) GeoTools 3
[06/07/2006 22:13] <jgarnett> missed one
[06/07/2006 22:13] <jgarnett> 2.5) Rendering API
[06/07/2006 22:14] <jgarnett> basically I want to finish the QA check of geotools and call it GeoTools3
[06/07/2006 22:14] <jgarnett> darn
[06/07/2006 22:14] <aaime> Hmm... that means we need coordination between Jody's 2.5
[06/07/2006 22:14] <jgarnett> 0) IP Check - as my token PM persuite
[06/07/2006 22:14] <aaime> and Martin's 3)
[06/07/2006 22:14] <jgarnett> not really, my 2.5 is just a QA check making sure factories and so on are used consistently and things do not suck
[06/07/2006 22:14] <simboss> 2>
[06/07/2006 22:14] <aaime> I would also like to split up rendering so that each layer can be managed by a different renderer
[06/07/2006 22:15] <simboss> CRS.decode(code,hint)
[06/07/2006 22:15] <simboss> what is the status of that?
[06/07/2006 22:15] <simboss> I recall you said you were going to implement such thing
[06/07/2006 22:15] <desruisseaux> Where 'hint' is a hint about axis order? If yes, then it is already done.
[06/07/2006 22:15] <simboss> (done with question 2)
[06/07/2006 22:16] <simboss> cool
[06/07/2006 22:16] <simboss> so I can do
[06/07/2006 22:16] <simboss> CRS.decode("EPSG:4326",hint_force_axis)a
[06/07/2006 22:17] <desruisseaux> http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#decode(java.lang.String,%20boolean)
[06/07/2006 22:17] <simboss> and get a lon,lat 4326?
[06/07/2006 22:17] <desruisseaux> Yes, it is done. Javadoc link above.
[06/07/2006 22:17] <simboss> this is sooooooooo cool!
[06/07/2006 22:17] <simboss>
[06/07/2006 22:17] <simboss> thanks
[06/07/2006 22:17] <simboss> question 3>
[06/07/2006 22:17] <desruisseaux> You are welcome
[06/07/2006 22:17] <simboss> This is more for the future
[06/07/2006 22:17] <simboss> right now
[06/07/2006 22:17] <simboss> regardless
[06/07/2006 22:18] <simboss> of the crs
[06/07/2006 22:18] <simboss> being lat,ln
[06/07/2006 22:18] <simboss> or lon,lat
[06/07/2006 22:18] <simboss> the gridrange of a gridcoverage2d
[06/07/2006 22:18] <simboss> is assuming
[06/07/2006 22:18] <simboss> to have lon first then lat
[06/07/2006 22:18] <simboss> and the gridtoworld transform
[06/07/2006 22:18] <simboss> performs a switch between the coefficients
[06/07/2006 22:19] <simboss> to reflect this
[06/07/2006 22:19] <simboss> is this correct?
[06/07/2006 22:19] <simboss> I do not think so
[06/07/2006 22:19] <simboss> (done)
[06/07/2006 22:21] <desruisseaux> GridRange itself has no notion of which dimension is longitude and which notion is latitude.
[06/07/2006 22:21] <desruisseaux> I assume that you refer to GridGeometry?
[06/07/2006 22:21] <simboss> yeah
[06/07/2006 22:21] <simboss> sorry
[06/07/2006 22:21] <desruisseaux> GridGeometry can be seen as GridRange + Envelope
[06/07/2006 22:21] <desruisseaux> But actually it is a GridRange + MathTransform.
[06/07/2006 22:22] <desruisseaux> The GridGeometry(GridRange, Envelope) is really just a convenience constructor.
[06/07/2006 22:22] <desruisseaux> And it is true that this constructor assumes (longitude,latitude) axis order.
[06/07/2006 22:22] <desruisseaux> However, this assumption can be improved, since an Envelope carry a CoordinateReferenceSystem.
[06/07/2006 22:22] <desruisseaux> So the GridGeometry constructor should look at it.
[06/07/2006 22:22] <desruisseaux> (I need to check if it already does or not - I'm not sure).
[06/07/2006 22:23] <simboss> it does
[06/07/2006 22:23] <desruisseaux> In the mean time, the really generic constructor is GridGeometry(GridRange, MathTransform)
[06/07/2006 22:23] <simboss> because it reverse the axes
[06/07/2006 22:23] <desruisseaux> With such constructor, you can really swap axis in whatever way you wish.
[06/07/2006 22:23] <simboss> not sure about this too
[06/07/2006 22:23] <desruisseaux> But this constructor is of course more complicated for the user (because not everybody is familiar with affine transforms).
[06/07/2006 22:23] <simboss> lemme check a sec
[06/07/2006 22:24] <simboss> I remember I had problems with this one too
[06/07/2006 22:24] <simboss> since with world images
[06/07/2006 22:24] <simboss> what you have is really an affine transform
[06/07/2006 22:24] <simboss> one sec...
[06/07/2006 22:25] <desruisseaux> Note: there is an other constructor which may be of some use
[06/07/2006 22:25] <desruisseaux> http://javadoc.geotools.fr/snapshot/org/geotools/coverage/grid/GeneralGridGeometry.html#GeneralGridGeometry(org.opengis.coverage.grid.GridRange,%20org.opengis.spatialschema.geometry.Envelope,%20boolean[],%20boolean)
[06/07/2006 22:26] <desruisseaux> This constructor expect a GridRange and an Envelope like the above-mentioned convenience constructor, but also expect in addition some more argument allowing users to control axis reversal and axis swapping.
[06/07/2006 22:27] <simboss> I have to run in few minutes
[06/07/2006 22:27] <simboss> my point here
[06/07/2006 22:27] <simboss> was as follows
[06/07/2006 22:27] <simboss> we need to remove all the assumption
[06/07/2006 22:27] <aaime> I got to go
[06/07/2006 22:27] <simboss> on the axis order
[06/07/2006 22:27] <aaime> Let me know when I can start merging the renderer
[06/07/2006 22:27] <simboss> this is probably next step
[06/07/2006 22:27] <simboss> when all this merge copy paste thing will be over
[06/07/2006 22:28] <simboss> what do oyou think martin?
[06/07/2006 22:28] <desruisseaux> I agree about removing all assumptions about axis order.
[06/07/2006 22:28] <desruisseaux> Or at least, user should have full control when they wish.
[06/07/2006 22:28] <simboss> ok
[06/07/2006 22:29] <desruisseaux> Some time, convenience methods have no choice to make some assumptions since they are convenience methods.
[06/07/2006 22:29] <simboss> I have to run now
[06/07/2006 22:29] <simboss> I still have at least other two questions but no time ;-(
[06/07/2006 22:29] <simboss> to ask them
[06/07/2006 22:29] <desruisseaux> I mean, (GridRange, Envelope) carry less informations than (GridRange, MathTransform), so the former must make some assumption, while the later do not require any assumption.
[06/07/2006 22:29] <desruisseaux> So lets ask question on the mailing list if you wish
[06/07/2006 22:29] <simboss> if the former
[06/07/2006 22:30] <simboss> has CRS
[06/07/2006 22:30] <simboss> we have all we need
[06/07/2006 22:30] <simboss> and anyway
[06/07/2006 22:30] <simboss> even without crs
[06/07/2006 22:30] <simboss> it does not really have to make any assumption
[06/07/2006 22:30] <simboss> because if you do not assume anything
[06/07/2006 22:31] <simboss> you will get an affine transform
[06/07/2006 22:31] <simboss> that just transform
[06/07/2006 22:31] <simboss> the from the cartesions crs of the coverage
[06/07/2006 22:31] <simboss> to some geo or proj crs
[06/07/2006 22:31] <simboss> the only underlying assumption
[06/07/2006 22:31] <simboss> is about having a georectified coverage
[06/07/2006 22:31] <simboss> but this is obvious
[06/07/2006 22:32] <desruisseaux> Even with a CRS, (GridRange, Envelope) still need to make some assumption, because it doesn't know if the first Envelope dimension (no matter if it is longitude or latitude) match the first GridRange dimension. With the later (GridRange, MathTransform), the relationship is fully and uniquely specified.
[06/07/2006 22:32] <simboss> I think here is the problem
[06/07/2006 22:32] <simboss> if I say
[06/07/2006 22:32] <simboss> this envelope
[06/07/2006 22:32] <simboss> is latlon
[06/07/2006 22:32] <simboss> or lonlat
[06/07/2006 22:32] <simboss> for the transformation
[06/07/2006 22:33] <simboss> this should not matter
[06/07/2006 22:33] <simboss> the first dimension of the envelope should match with the first dimension of the grid range
[06/07/2006 22:33] <simboss> at least in my opinion
[06/07/2006 22:33] <desruisseaux> Not always - this is at user choice.
[06/07/2006 22:33] <simboss> this should be the default choice
[06/07/2006 22:33] <desruisseaux> It could be the default, yes.
[06/07/2006 22:33] <simboss> cool, we are in agreement
[06/07/2006 22:33] <simboss> unless specified
[06/07/2006 22:34] <simboss> we should not make any assumption
[06/07/2006 22:34] <simboss> and therefore
[06/07/2006 22:34] <simboss> we should not reerse anything
[06/07/2006 22:34] <desruisseaux> Only (GridRange, MathTransform) has no ambiguity.
[06/07/2006 22:34] <simboss> cool
[06/07/2006 22:34] <desruisseaux> (GridRange, Envelope) has ambiguity, and requires assumption. If we want to match first envelope dimension to firs grid range dimension, this is an assumption.
[06/07/2006 22:34] <simboss> we are on the same line
[06/07/2006 22:35] <simboss> sure
[06/07/2006 22:35] <simboss> but it is the obvious one
[06/07/2006 22:35] <simboss> if I provide a lat,lon envelope
[06/07/2006 22:35] <simboss> this usually means that I want to see an image
[06/07/2006 22:35] <simboss> where point towards north
[06/07/2006 22:36] <simboss> at least this is what people I have worked with wanted to see
[06/07/2006 22:37] <desruisseaux> If you provides a (lat,lon) envelope, and if the first envelope dimension match the first grid dimension, then North will point toward right when rendering with Java2D.
[06/07/2006 22:37] <desruisseaux> (or toward left, I'm not sure).
[06/07/2006 22:38] <simboss> towards right
[06/07/2006 22:38] <desruisseaux> If we want North to point toward up, we need to match the first envelope dimension to the second grid dimension.
[06/07/2006 22:38] <simboss> and that would be the expected behaviour for me
[06/07/2006 22:38] <simboss> the user has to be provided with control over these things
[06/07/2006 22:39] <simboss> and no assumptions have to be made in my opinion
[06/07/2006 22:39] <simboss> if you give an envelope
[06/07/2006 22:39] <simboss> lat,lon
[06/07/2006 22:39] <simboss> without asksing for an axis switch
[06/07/2006 22:39] <desruisseaux> You can get this behavior with the following constructor:
[06/07/2006 22:39] <simboss> you will see north pointing towards right
[06/07/2006 22:39] <desruisseaux> new GridGeometry(gridRange, envelope, null, false);
[06/07/2006 22:40] <simboss> I know
[06/07/2006 22:40] <jgarnett> I gotta grab some food, can you guys post logs if I miss anything?
[06/07/2006 22:40] <simboss> but most people get confused
[06/07/2006 22:40] <desruisseaux> I guess that the issue is a naming problem then.
[06/07/2006 22:40] <simboss> I think we should not reverse or swap anything
[06/07/2006 22:40] <desruisseaux> The GridCoverage(GridRange, Envelope) method should probably be refactored as a static method with a very explicit name.
[06/07/2006 22:40] <simboss> unless explcitly asked to
[06/07/2006 22:41] <simboss> I have to run, we will discuss this after the mergem once we will be speding time on refining things
[06/07/2006 22:41] <simboss> is that ok?
[06/07/2006 22:41] <desruisseaux> Sure.
[06/07/2006 22:41] <simboss> gotta run
[06/07/2006 22:42] <simboss> thanks a lot martin
[06/07/2006 22:42] <jgarnett> (post logs i missed the first part)
[06/07/2006 22:42] <desruisseaux> Fine. Thanks for all yours work
[06/07/2006 22:42] <jgarnett> pls
[06/07/2006 22:42] <simboss> I will reread the log
[06/07/2006 22:42] <simboss> and send some emails if something comes to my mind
[06/07/2006 22:45] <desruisseaux> I will send the log to Jody.
[06/07/2006 22:45] <desruisseaux> Bye all

Changes between revision 1 and revision 2:

view all revisions | revert page to version 1
 {excerpt}Martin and Simboss coordinate on Grid Coverage Branch merge; and then just talk shop{excerpt}
   
 [06/07/2006 21:09] <simboss> martin?
 [06/07/2006 21:10] <desruisseaux> Hello Simmone
 [06/07/2006 21:28] <simboss> are we waiting for someone else?
 [06/07/2006 21:29] <simboss> I am trying to ping aaime
 [06/07/2006 21:29] <aaime> Hi guys
 [06/07/2006 21:29] <aaime> Nice subject :-)
 [06/07/2006 21:29] <desruisseaux> Hello all
 [06/07/2006 21:30] <simboss> trying to see if I can get jody here
 [06/07/2006 21:30] <aaime> So, how is it going with the merge?
 [06/07/2006 21:31] <aaime> I can call him
 [06/07/2006 21:31] <simboss> that would be good
 [06/07/2006 21:32] <aaime> They're looking for him at Bluesphere :-)
 [06/07/2006 21:32] <desruisseaux> Checking for the change is easy enough. I don't know yet however or big the changes are. I just finished ImageUtilities, but I have not yet tested it. I'm writing a test suite for ImageWorker now.
 [06/07/2006 21:32] <aaime> Maybe he's in the kitchen eating something
 [06/07/2006 21:32] <aaime> Oh, ImageUtilities extra methods were untested?
 [06/07/2006 21:33] <desruisseaux> ImageUtilities itself is unchanged (compared to the coverage branch)
 [06/07/2006 21:33] <desruisseaux> The new methods are in a new, different class.
 [06/07/2006 21:33] <desruisseaux> ImageWorker.
 [06/07/2006 21:33] <desruisseaux> Tests are in progress.
 [06/07/2006 21:34] <simboss> cool
 [06/07/2006 21:34] <aaime> It is my understanding that we cannot start merging the plugins until you've finished with the coverage module
 [06/07/2006 21:34] <aaime> Plugin merging could be done in parallelo
 [06/07/2006 21:34] <aaime> (parallel, sorry)
 [06/07/2006 21:35] <desruisseaux> Yes. But I'm watching all the changes done in the coverage branch. If a see that a class that I already ported has been changed, I will port the changes.
 [06/07/2006 21:35] <desruisseaux> I have been much slower than I hoped, because JSR-275 eated the majority of my time.
 [06/07/2006 21:35] <simboss> don't worry
 [06/07/2006 21:36] <simboss> have you had a chance to look at
 [06/07/2006 21:36] <simboss> the new operations?
 [06/07/2006 21:36] <desruisseaux> Just a very fast look, but I have not yet reached this point in the mergE.
 [06/07/2006 21:37] <desruisseaux> I'm working on a package-by-package basis.
 [06/07/2006 21:37] <aaime> JSR-275 --> units?
 [06/07/2006 21:37] <simboss> on which packages are you focusing?
 [06/07/2006 21:38] <desruisseaux> My work in New-Caledonia will be finished in one or two week. I will take the plane on July 25, back to France. When I will be back there, I may have a chance to attend more often to IRC meeting.
 [06/07/2006 21:38] <desruisseaux> Yesn JSR-275 is javax.units.
 [06/07/2006 21:38] <simboss> I thought you were working exclusivelu on the coverage package
 [06/07/2006 21:38] <desruisseaux> No. I was sharing my time between the coverage branch and JSR-275 (I announced that in some email).
 [06/07/2006 21:39] <desruisseaux> Geotools is currently working with JSR-108, which has been withdrawn.
 [06/07/2006 21:39] <desruisseaux> JSR-275 is a new attempt to get a javax.units package, with a new expert group.
 [06/07/2006 21:39] <desruisseaux> But the work is not going as fast as it should. Basically, everybody is hopping that somebody else will do the work.
 [06/07/2006 21:40] <simboss> exclusively meant with respect to the other modules
 [06/07/2006 21:40] <desruisseaux> We realized that if we do not start writting a specification very soon, Sun will withdrawn JSR-275 again. With no hope to get a new start this time.
 [06/07/2006 21:40] <desruisseaux> So it is a kind of urgent work, and I took vacation time for that because I realized that nobody was about to do this work in the JSR-275 group.
 [06/07/2006 21:41] <desruisseaux> I wanted to do both JSR-275 and the coverage branch.
 [06/07/2006 21:41] <desruisseaux> And none of them are as far as I hoped.
 [06/07/2006 21:42] <desruisseaux> (I means, I didn't do one third of the work I hoped to do).
 [06/07/2006 21:42] <simboss> well let's see how we can speed geotools work up
 [06/07/2006 21:43] <simboss> which modules have you been looking at so far?
 [06/07/2006 21:43] <desruisseaux> I'm focusing exclusively on module/coverage.
 [06/07/2006 21:44] <desruisseaux> I would like to let plugin and module/main to other volunters...
 [06/07/2006 21:44] <simboss> ok
 [06/07/2006 21:45] <simboss> I will take plugins
 [06/07/2006 21:45] <simboss> how are we going to decide about the others?
 [06/07/2006 21:45] <desruisseaux> Thanks.
 [06/07/2006 21:45] <simboss> other modules I mean
 [06/07/2006 21:46] <desruisseaux> Maybe we need to ask to Jody about main? (did you made some changes in gt/module/main?)
 [06/07/2006 21:46] <desruisseaux> Note: gt/module/referencing is done - we should have nothing more to port for this module.
 [06/07/2006 21:47] <simboss> In main I made minor changes
 [06/07/2006 21:47] <simboss> the most important
 [06/07/2006 21:47] <simboss> is a class that should act as a superclass for all readers of gridcoverage2d
 [06/07/2006 21:47] <simboss> AbstractGridCoverage2DReader
 [06/07/2006 21:47] <simboss> or something like it
 [06/07/2006 21:48] <simboss> I also tried to clean up here and there
 [06/07/2006 21:48] <simboss> but nothing so important besides this
 [06/07/2006 21:49] <desruisseaux> Would you have time for taking the task of merging gt/module/main (maybe together with Jody)?
 [06/07/2006 21:50] <simboss> mmmhhh
 [06/07/2006 21:50] <simboss> I might
 [06/07/2006 21:50] <simboss> it should ne hard at all
 [06/07/2006 21:50] <simboss> and besides
 [06/07/2006 21:50] <simboss> without it
 [06/07/2006 21:50] <simboss> I cannot proceed again
 [06/07/2006 21:50] <simboss> since I need the above mentioned class
 [06/07/2006 21:51] <simboss> otherwise most plugins wown't work
 [06/07/2006 21:51] <simboss> at all
 [06/07/2006 21:52] <aaime> Once you have done that I can take some plugins and merge them
 [06/07/2006 21:53] <simboss> what about streaming renderer
 [06/07/2006 21:53] <simboss> would you rather take on that aaime?
 [06/07/2006 21:54] <simboss> it should basically be
 [06/07/2006 21:54] <simboss> a take and replace
 [06/07/2006 21:54] <simboss> with the old one
 [06/07/2006 21:54] <simboss> same thing s going to happen with pugins
 [06/07/2006 21:54] <simboss> more or less
 [06/07/2006 21:54] <simboss> except only for arcgrid
 [06/07/2006 21:54] <simboss> becuse the new one is not ready yet
 [06/07/2006 21:55] <simboss> (very close to be ready though :-) )
 [06/07/2006 21:55] <aaime> Yes, I think I can
 [06/07/2006 21:55] <aaime> Jody is on his way here
 [06/07/2006 21:56] <desruisseaux> That would be nice :). If you meet a dependency toward gt/module/coverage which is not yet merged, you could email me so I give the priority to those specific classes.
 [06/07/2006 21:56] <simboss> well
 [06/07/2006 21:56] <simboss> basically
 [06/07/2006 21:56] <simboss> plugins
 [06/07/2006 21:56] <simboss> need imageutilies
 [06/07/2006 21:56] <desruisseaux> This one is done :)
 [06/07/2006 21:57] <jgarnett> hello
 [06/07/2006 21:57] <desruisseaux> Hello Jody.
 [06/07/2006 21:57] <aaime> Martin, yes, I'll do
 [06/07/2006 21:57] <simboss> gridcoverage renderer
 [06/07/2006 21:57] <simboss> needs the new operation
 [06/07/2006 21:57] <simboss> plugins and streaming renderer
 [06/07/2006 21:58] <simboss> need abstractgridcoverage2dreader
 [06/07/2006 21:58] <simboss> streaming renderer need some minor changes I made to ReferencedEnvelope
 [06/07/2006 21:59] <simboss> in order to interoperate
 [06/07/2006 21:59] <simboss> between geoapi envelopes
 [06/07/2006 21:59] <simboss> and referenced envelopes
 [06/07/2006 21:59] <simboss> this is more or less where we are
 [06/07/2006 21:59] <aaime> So without the new opetation I can't merge the new streaming renderer (at least the parts that do renderer coverages)
 [06/07/2006 21:59] <simboss> in terms of dependencies
 [06/07/2006 21:59] <simboss> no
 [06/07/2006 21:59] <simboss> main
 [06/07/2006 21:59] <simboss> and coverage
 [06/07/2006 22:00] <simboss> are prerequisites to do all the work
 [06/07/2006 22:02] <desruisseaux> So the work can start now (if we wish) for gt/module/main, and hopefully I may get some operations done in the main time?
 [06/07/2006 22:02] <simboss> that would be great
 [06/07/2006 22:02] <simboss> Tomorrow I will try to merge
 [06/07/2006 22:02] <simboss> main
 [06/07/2006 22:03] <simboss> it should not be that hard
 [06/07/2006 22:03] <simboss> I did the inverse thing more than once without problems
 [06/07/2006 22:04] <aaime> Ok, so we are set?
 [06/07/2006 22:04] <aaime> Can someone inform me when all the operations are merged?
 [06/07/2006 22:05] <desruisseaux> Yes, I will post on the mailing list.
 [06/07/2006 22:05] <simboss> sorry guys
 [06/07/2006 22:05] <simboss> I have a couple of questions more
 [06/07/2006 22:05] <simboss> since we have here martin
 [06/07/2006 22:06] <simboss> let's abuse of his time a little bit
 [06/07/2006 22:06] <simboss> if he agrees of course :-)
 [06/07/2006 22:06] <desruisseaux> Sure, but let see if I'm able to propose an answer...
 [06/07/2006 22:06] <desruisseaux> ?
 [06/07/2006 22:07] <simboss> 1>Can you spend a few workd about the work on rendering?
 [06/07/2006 22:07] <simboss> I might help you out
 [06/07/2006 22:08] <simboss> but I have not much time for the moment
 [06/07/2006 22:08] <simboss> I might find a student to do some work for us though
 [06/07/2006 22:08] <simboss> (done with question 1)
 [06/07/2006 22:08] <desruisseaux> There is the picture:
 [06/07/2006 22:09] <desruisseaux> There is two distinct project planned: a 2D and a 3D renderer.
 [06/07/2006 22:09] <desruisseaux> The 2D renderer would be a GO-1 implementation.
 [06/07/2006 22:09] <desruisseaux> The code would be J2D-renderer refactored + streaming renderer.
 [06/07/2006 22:10] <desruisseaux> Some of this work put the basis for a 3D renderer as well (even if it is out of 2D renderer scope).
 [06/07/2006 22:10] <desruisseaux> I means, some base classes can apply to both 2D and 3D renderer.
 [06/07/2006 22:10] <desruisseaux> I will do the work for the 2D renderer after the coverage branch merge.
 [06/07/2006 22:10] <desruisseaux> My priority order is:
 [06/07/2006 22:11] <desruisseaux> 1) get out of my current work :( (leaving very soon)
 [06/07/2006 22:11] <desruisseaux> 2) Coverage branch merge
 [06/07/2006 22:11] <desruisseaux> 3) GO-1 renderer (2D only)
 [06/07/2006 22:12] <desruisseaux> We are in contact with two computer teachers in Marseille.
 [06/07/2006 22:12] <desruisseaux> Those two teachers are planning a 3D renderer with a team of 4 students.
 [06/07/2006 22:13] <simboss> ok
 [06/07/2006 22:13] <jgarnett> I should probably come clean with my work prority as well :-)
 [06/07/2006 22:13] <desruisseaux> The 3D renderer would build on top of the 2D renderer part which is common to 2D and 3D.
 [06/07/2006 22:13] <jgarnett> 1) FM
 [06/07/2006 22:13] <jgarnett> 2) Catalog
 [06/07/2006 22:13] <jgarnett> 3) GeoTools 3
 [06/07/2006 22:13] <jgarnett> missed one
 [06/07/2006 22:13] <jgarnett> 2.5) Rendering API
 [06/07/2006 22:14] <jgarnett> basically I want to finish the QA check of geotools and call it GeoTools3
 [06/07/2006 22:14] <jgarnett> darn
 [06/07/2006 22:14] <aaime> Hmm... that means we need coordination between Jody's 2.5
 [06/07/2006 22:14] <jgarnett> 0) IP Check - as my token PM persuite
 [06/07/2006 22:14] <aaime> and Martin's 3)
 [06/07/2006 22:14] <jgarnett> not really, my 2.5 is just a QA check making sure factories and so on are used consistently and things do not suck ;-)
 [06/07/2006 22:14] <simboss> 2>
 [06/07/2006 22:14] <aaime> I would also like to split up rendering so that each layer can be managed by a different renderer
 [06/07/2006 22:15] <simboss> CRS.decode(code,hint)
 [06/07/2006 22:15] <simboss> what is the status of that?
 [06/07/2006 22:15] <simboss> I recall you said you were going to implement such thing
 [06/07/2006 22:15] <desruisseaux> Where 'hint' is a hint about axis order? If yes, then it is already done.
 [06/07/2006 22:15] <simboss> (done with question 2)
 [06/07/2006 22:16] <simboss> cool
 [06/07/2006 22:16] <simboss> so I can do
 [06/07/2006 22:16] <simboss> CRS.decode("EPSG:4326",hint_force_axis)a
 [06/07/2006 22:17] <desruisseaux> http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#decode(java.lang.String,%20boolean)
 [06/07/2006 22:17] <simboss> and get a lon,lat 4326?
 [06/07/2006 22:17] <desruisseaux> Yes, it is done. Javadoc link above.
 [06/07/2006 22:17] <simboss> this is sooooooooo cool!
 [06/07/2006 22:17] <simboss> :-)
 [06/07/2006 22:17] <simboss> thanks
 [06/07/2006 22:17] <simboss> question 3>
 [06/07/2006 22:17] <desruisseaux> You are welcome :)
 [06/07/2006 22:17] <simboss> This is more for the future
 [06/07/2006 22:17] <simboss> right now
 [06/07/2006 22:17] <simboss> regardless
 [06/07/2006 22:18] <simboss> of the crs
 [06/07/2006 22:18] <simboss> being lat,ln
 [06/07/2006 22:18] <simboss> or lon,lat
 [06/07/2006 22:18] <simboss> the gridrange of a gridcoverage2d
 [06/07/2006 22:18] <simboss> is assuming
 [06/07/2006 22:18] <simboss> to have lon first then lat
 [06/07/2006 22:18] <simboss> and the gridtoworld transform
 [06/07/2006 22:18] <simboss> performs a switch between the coefficients
 [06/07/2006 22:19] <simboss> to reflect this
 [06/07/2006 22:19] <simboss> is this correct?
 [06/07/2006 22:19] <simboss> I do not think so
 [06/07/2006 22:19] <simboss> (done)
 [06/07/2006 22:21] <desruisseaux> GridRange itself has no notion of which dimension is longitude and which notion is latitude.
 [06/07/2006 22:21] <desruisseaux> I assume that you refer to GridGeometry?
 [06/07/2006 22:21] <simboss> yeah
 [06/07/2006 22:21] <simboss> sorry
 [06/07/2006 22:21] <desruisseaux> GridGeometry can be seen as GridRange + Envelope
 [06/07/2006 22:21] <desruisseaux> But actually it is a GridRange + MathTransform.
 [06/07/2006 22:22] <desruisseaux> The GridGeometry(GridRange, Envelope) is really just a convenience constructor.
 [06/07/2006 22:22] <desruisseaux> And it is true that this constructor assumes (longitude,latitude) axis order.
 [06/07/2006 22:22] <desruisseaux> However, this assumption can be improved, since an Envelope carry a CoordinateReferenceSystem.
 [06/07/2006 22:22] <desruisseaux> So the GridGeometry constructor should look at it.
 [06/07/2006 22:22] <desruisseaux> (I need to check if it already does or not - I'm not sure).
 [06/07/2006 22:23] <simboss> it does
 [06/07/2006 22:23] <desruisseaux> In the mean time, the really generic constructor is GridGeometry(GridRange, MathTransform)
 [06/07/2006 22:23] <simboss> because it reverse the axes
 [06/07/2006 22:23] <desruisseaux> With such constructor, you can really swap axis in whatever way you wish.
 [06/07/2006 22:23] <simboss> not sure about this too
 [06/07/2006 22:23] <desruisseaux> But this constructor is of course more complicated for the user (because not everybody is familiar with affine transforms).
 [06/07/2006 22:23] <simboss> lemme check a sec
 [06/07/2006 22:24] <simboss> I remember I had problems with this one too
 [06/07/2006 22:24] <simboss> since with world images
 [06/07/2006 22:24] <simboss> what you have is really an affine transform
 [06/07/2006 22:24] <simboss> one sec...
 [06/07/2006 22:25] <desruisseaux> Note: there is an other constructor which may be of some use
 [06/07/2006 22:25] <desruisseaux> http://javadoc.geotools.fr/snapshot/org/geotools/coverage/grid/GeneralGridGeometry.html#GeneralGridGeometry(org.opengis.coverage.grid.GridRange,%20org.opengis.spatialschema.geometry.Envelope,%20boolean[],%20boolean)
 [06/07/2006 22:26] <desruisseaux> This constructor expect a GridRange and an Envelope like the above-mentioned convenience constructor, but also expect in addition some more argument allowing users to control axis reversal and axis swapping.
 [06/07/2006 22:27] <simboss> I have to run in few minutes
 [06/07/2006 22:27] <simboss> my point here
 [06/07/2006 22:27] <simboss> was as follows
 [06/07/2006 22:27] <simboss> we need to remove all the assumption
 [06/07/2006 22:27] <aaime> I got to go
 [06/07/2006 22:27] <simboss> on the axis order
 [06/07/2006 22:27] <aaime> Let me know when I can start merging the renderer
 [06/07/2006 22:27] <simboss> this is probably next step
 [06/07/2006 22:27] <simboss> when all this merge copy paste thing will be over
 [06/07/2006 22:28] <simboss> what do oyou think martin?
 [06/07/2006 22:28] <desruisseaux> I agree about removing all assumptions about axis order.
 [06/07/2006 22:28] <desruisseaux> Or at least, user should have full control when they wish.
 [06/07/2006 22:28] <simboss> ok
 [06/07/2006 22:29] <desruisseaux> Some time, convenience methods have no choice to make some assumptions since they are convenience methods.
 [06/07/2006 22:29] <simboss> I have to run now
 [06/07/2006 22:29] <simboss> I still have at least other two questions but no time ;-(
 [06/07/2006 22:29] <simboss> to ask them
 [06/07/2006 22:29] <desruisseaux> I mean, (GridRange, Envelope) carry less informations than (GridRange, MathTransform), so the former must make some assumption, while the later do not require any assumption.
 [06/07/2006 22:29] <desruisseaux> So lets ask question on the mailing list if you wish
 [06/07/2006 22:29] <simboss> if the former
 [06/07/2006 22:30] <simboss> has CRS
 [06/07/2006 22:30] <simboss> we have all we need
 [06/07/2006 22:30] <simboss> and anyway
 [06/07/2006 22:30] <simboss> even without crs
 [06/07/2006 22:30] <simboss> it does not really have to make any assumption
 [06/07/2006 22:30] <simboss> because if you do not assume anything
 [06/07/2006 22:31] <simboss> you will get an affine transform
 [06/07/2006 22:31] <simboss> that just transform
 [06/07/2006 22:31] <simboss> the from the cartesions crs of the coverage
 [06/07/2006 22:31] <simboss> to some geo or proj crs
 [06/07/2006 22:31] <simboss> the only underlying assumption
 [06/07/2006 22:31] <simboss> is about having a georectified coverage
 [06/07/2006 22:31] <simboss> but this is obvious
 [06/07/2006 22:32] <desruisseaux> Even with a CRS, (GridRange, Envelope) still need to make some assumption, because it doesn't know if the first Envelope dimension (no matter if it is longitude or latitude) match the first GridRange dimension. With the later (GridRange, MathTransform), the relationship is fully and uniquely specified.
 [06/07/2006 22:32] <simboss> I think here is the problem
 [06/07/2006 22:32] <simboss> if I say
 [06/07/2006 22:32] <simboss> this envelope
 [06/07/2006 22:32] <simboss> is latlon
 [06/07/2006 22:32] <simboss> or lonlat
 [06/07/2006 22:32] <simboss> for the transformation
 [06/07/2006 22:33] <simboss> this should not matter
 [06/07/2006 22:33] <simboss> the first dimension of the envelope should match with the first dimension of the grid range
 [06/07/2006 22:33] <simboss> at least in my opinion
 [06/07/2006 22:33] <desruisseaux> Not always - this is at user choice.
 [06/07/2006 22:33] <simboss> this should be the default choice
 [06/07/2006 22:33] <desruisseaux> It could be the default, yes.
 [06/07/2006 22:33] <simboss> cool, we are in agreement
 [06/07/2006 22:33] <simboss> unless specified
 [06/07/2006 22:34] <simboss> we should not make any assumption
 [06/07/2006 22:34] <simboss> and therefore
 [06/07/2006 22:34] <simboss> we should not reerse anything
 [06/07/2006 22:34] <desruisseaux> Only (GridRange, MathTransform) has no ambiguity.
 [06/07/2006 22:34] <simboss> cool
 [06/07/2006 22:34] <desruisseaux> (GridRange, Envelope) has ambiguity, and requires assumption. If we want to match first envelope dimension to firs grid range dimension, this is an assumption.
 [06/07/2006 22:34] <simboss> we are on the same line
 [06/07/2006 22:35] <simboss> sure
 [06/07/2006 22:35] <simboss> but it is the obvious one
 [06/07/2006 22:35] <simboss> if I provide a lat,lon envelope
 [06/07/2006 22:35] <simboss> this usually means that I want to see an image
 [06/07/2006 22:35] <simboss> where point towards north
 [06/07/2006 22:36] <simboss> at least this is what people I have worked with wanted to see
 [06/07/2006 22:37] <desruisseaux> If you provides a (lat,lon) envelope, and if the first envelope dimension match the first grid dimension, then North will point toward right when rendering with Java2D.
 [06/07/2006 22:37] <desruisseaux> (or toward left, I'm not sure).
 [06/07/2006 22:38] <simboss> towards right
 [06/07/2006 22:38] <desruisseaux> If we want North to point toward up, we need to match the first envelope dimension to the second grid dimension.
 [06/07/2006 22:38] <simboss> and that would be the expected behaviour for me
 [06/07/2006 22:38] <simboss> the user has to be provided with control over these things
 [06/07/2006 22:39] <simboss> and no assumptions have to be made in my opinion
 [06/07/2006 22:39] <simboss> if you give an envelope
 [06/07/2006 22:39] <simboss> lat,lon
 [06/07/2006 22:39] <simboss> without asksing for an axis switch
 [06/07/2006 22:39] <desruisseaux> You can get this behavior with the following constructor:
 [06/07/2006 22:39] <simboss> you will see north pointing towards right
 [06/07/2006 22:39] <desruisseaux> new GridGeometry(gridRange, envelope, null, false);
 [06/07/2006 22:40] <simboss> I know
 [06/07/2006 22:40] <jgarnett> I gotta grab some food, can you guys post logs if I miss anything?
 [06/07/2006 22:40] <simboss> but most people get confused
 [06/07/2006 22:40] <desruisseaux> I guess that the issue is a naming problem then.
 [06/07/2006 22:40] <simboss> I think we should not reverse or swap anything
 [06/07/2006 22:40] <desruisseaux> The GridCoverage(GridRange, Envelope) method should probably be refactored as a static method with a very explicit name.
 [06/07/2006 22:40] <simboss> unless explcitly asked to
 [06/07/2006 22:41] <simboss> I have to run, we will discuss this after the mergem once we will be speding time on refining things
 [06/07/2006 22:41] <simboss> is that ok?
 [06/07/2006 22:41] <desruisseaux> Sure.
 [06/07/2006 22:41] <simboss> gotta run
 [06/07/2006 22:42] <simboss> thanks a lot martin
 [06/07/2006 22:42] <jgarnett> (post logs i missed the first part)
 [06/07/2006 22:42] <desruisseaux> Fine. Thanks for all yours work :)
 [06/07/2006 22:42] <jgarnett> pls
 [06/07/2006 22:42] <simboss> I will reread the log
 [06/07/2006 22:42] <simboss> and send some emails if something comes to my mind
 [06/07/2006 22:45] <desruisseaux> I will send the log to Jody.
 [06/07/2006 22:45] <desruisseaux> Bye all
IRC Meeting - 26 June 2006 (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 3 on Jul 12, 2006 12:24. created by Richard Gould (rgould@refractions.net) on Jun 26, 2006 14:45

1: GC update
2: maven 2 repository update
3: jira
4: start on time, end on time

acuster: simboss the GC is you?
acuster: if so, GO!
rgould: ping simboss
aaime: Fact is, GC is really Martin so far...
acuster: okay, let's go to 2
simboss: sorry guys
acuster: oh, hold off
simboss: but I am having dinner
rgould: ok
acuster: you want to go last?
simboss: yeah
simboss: but aaime
simboss: knows as much as i know anyway
simboss: go ahead
aaime: Well, that not really true
acuster: aaime : want to give us five words on how its going
aaime: Anyway, I can try
simboss: I will try to make it for the last point
aaime: As far as we know, Martin has started merging gc onto trunk piecemeal
aaime: So far, it's a one man effort, we haven't managed to organise it
aaime: Martin just started and went off leaving us a little baffled
aaime: (ok, pleasingly baffled)
acuster: you were going to go the other way, no?
aaime: The only communication channel so far is JIRA task
aaime: Well, we did not decide actually...
acuster: cool, so that's been decided
aaime: Simboss was willing to add the "last finishing touches"
aaime: Yeah, Martin took the thing and it seems he's carrying it thru
acuster: thanks. Anything else?
acuster: let's move on and come back when simboss wanders back
aaime: That's all I know...
acuster: 3: jira
aaime: Oh, in the branch I did a few fixes on JMapPane
rgould: 2: maven repo
acuster: yeah
chorner: i guess that's me?
rgould: so thanks to aaime, we now have webdav support working for maven 2 builds
rgould can do it!
rgould: but you can assist
chorner smiles and sits back
rgould: and also thanks to chorner for helping sort out the maven 2 repo on lists.refractions.net
acuster: what's webdav?
rgould: but now we have the problems of having two maven 2 repositories: lists.refractions.net and maven.geotools.fr
rgould: I'm not certain exactly, but allows for file transfer over HTTP
aaime: Think of it as a ftp with versioning and file based authorization as far as I know
aaime: And you can mount it as if it was a local folder
acuster: what server is being used?
rgould: lists.refractions.net
acuster: cool
rgould: But because transfer times to maven.geotools.fr can be very slow, and because uploading to two different repositories is a PITA, I am trying ot set up a mirroring scheme, with martin's help
chorner: lists.refractions.net/m2
acuster: who runs geotools.fr?
rgould: so i'm setting up rsync on lists.refrractions.net (mostly set up)
rgould: martin
rgould: and i will see if he can set up an rsync client on maven.geotools.fr that will query lists.refractions.net every so often
rgould: and i'm almost done
rgould: that's all I'vegot
aaime: Btw, where did Jody go? I haven't catched him online for the whole day
acuster: how often will rsync run? Also can you let us know what time of day it runs?
rgould hasn't seen him either
acuster: may become important when trouble shooting versions
rgould: I was going to suggest that martin has it run every 30 mins
acuster: oh, that's not a problem then
rgould: It only initiates a download request if a change has been made on lists.refractions.net
acuster: cool
rgould: i've run into firewall issues on this end
rgould: and our sys admin is out of the office until tomorrow
rgould: so I don't think I will get anywhere today
rgould is finished
rgould: 3: JIRA
rgould: Who was that?
chorner: me
chorner: ...was looking through the gt jira today... and found it to be a complete mess
chorner: recently uDig cleaned up its jira – and it has been fantastic; we should do the same here
rgould: what kind of clean up do you propose?
chorner: making sure that bugs haven't already been fixed, selecting a target version for fixes, and assigning bugs to people where applicable
rgould: a cleaner JIRA would really help the changelogs during releases
chorner: the main thing however, is that we haven't been maintaining it
chorner: so I guess this is a call out to module maintainers: start looking at your jira space in the next few weeks
rgould: it looks like the WMS module has been erased from jira?
rgould: or maybe it's just empty?
chorner: ...or any enthiastic volunteers
rgould: ah, wms is just empty
chorner: ok... that's it
rgould: I think I will add a "next" command
rgould: any have any thoughts regarding JIRA?
rgould: ok.. 4: Start on time, end on time
aaime: Well, I guess we are ending even before time
simboss: back
simboss: too late ,_(
simboss: ;-(
rgould: no
rgould: meeting is still going
chorner: so we start at 12:01 next week, or to the gallows with ye?
rgould: i think so
simboss: cool
rgould: acuster, did you have anything you wanted to say?
acuster: nope
rgould: ok
rgould: back to 1: GC update
rgould: simboss
simboss: well
simboss: there is not mcu to say except that
simboss: the merge is in progress
simboss: martin took a vacation on purpose for it
simboss: we are exchanging some emails
simboss: about conflicts
simboss: I am hoping to find a way to help him out
simboss: since he basicallly basically started while I was still planning the merge itself
simboss: as aaime can confirm
aaime: Yeah
simboss: I think that for the moment
aaime: Anway, the sooner we the merge ends, the sooner we can start working on FM
simboss: this is it as far as talking about gc merge
rgould: ok
rgould: no more items.. any have anything else they would like to say?
rgould: yay!
rgould: ok, meeting over

Changes between revision 2 and revision 3:

view all revisions | revert page to version 2
 {excerpt}
 1: GC update
 2: maven 2 repository update
 3: jira
 4: start on time, end on time
 {excerpt}
   
 acuster: simboss the GC is you?
 acuster: if so, GO!
 rgould: ping simboss
 aaime: Fact is, GC is really Martin so far...
 acuster: okay, let's go to 2
 simboss: sorry guys
 acuster: oh, hold off
 simboss: but I am having dinner
 rgould: ok
 acuster: you want to go last?
 simboss: yeah
 simboss: but aaime
 simboss: knows as much as i know anyway
 simboss: go ahead
 aaime: Well, that not really true :-)
 acuster: aaime : want to give us five words on how its going
 aaime: Anyway, I can try
 simboss: I will try to make it for the last point
 aaime: As far as we know, Martin has started merging gc onto trunk piecemeal
 aaime: So far, it's a one man effort, we haven't managed to organise it
 aaime: Martin just started and went off leaving us a little baffled
 aaime: (ok, pleasingly baffled)
 acuster: you were going to go the other way, no?
 aaime: The only communication channel so far is JIRA task
 aaime: Well, we did not decide actually...
 acuster: cool, so that's been decided
 aaime: Simboss was willing to add the "last finishing touches"
 aaime: Yeah, Martin took the thing and it seems he's carrying it thru
 acuster: thanks. Anything else?
 acuster: let's move on and come back when simboss wanders back
 aaime: That's all I know...
 acuster: 3: jira
 aaime: Oh, in the branch I did a few fixes on JMapPane
 rgould: 2: maven repo :)
 acuster: yeah:-)
 chorner: i guess that's me?
 rgould: so thanks to aaime, we now have webdav support working for maven 2 builds
 rgould can do it!
 rgould: but you can assist
 chorner smiles and sits back
 rgould: and also thanks to chorner for helping sort out the maven 2 repo on lists.refractions.net
 acuster: what's webdav?
 rgould: but now we have the problems of having two maven 2 repositories: lists.refractions.net and maven.geotools.fr
 rgould: I'm not certain exactly, but allows for file transfer over HTTP
 aaime: Think of it as a ftp with versioning and file based authorization as far as I know
 aaime: And you can mount it as if it was a local folder
 acuster: what server is being used?
 rgould: lists.refractions.net
 acuster: cool
 rgould: But because transfer times to maven.geotools.fr can be very slow, and because uploading to two different repositories is a PITA, I am trying ot set up a mirroring scheme, with martin's help
 chorner: lists.refractions.net/m2
 acuster: who runs geotools.fr?
 rgould: so i'm setting up rsync on lists.refrractions.net (mostly set up)
 rgould: martin
 rgould: and i will see if he can set up an rsync client on maven.geotools.fr that will query lists.refractions.net every so often
 rgould: and i'm almost done
 rgould: that's all I'vegot
 aaime: Btw, where did Jody go? I haven't catched him online for the whole day
 acuster: how often will rsync run? Also can you let us know what time of day it runs?
 rgould hasn't seen him either
 acuster: may become important when trouble shooting versions
 rgould: I was going to suggest that martin has it run every 30 mins
 acuster: oh, that's not a problem then
 rgould: It only initiates a download request if a change has been made on lists.refractions.net
 acuster: cool
 rgould: i've run into firewall issues on this end
 rgould: and our sys admin is out of the office until tomorrow
 rgould: so I don't think I will get anywhere today
 rgould is finished
 rgould: 3: JIRA
 rgould: Who was that?
 chorner: me
 chorner: ...was looking through the gt jira today... and found it to be a complete mess
 chorner: recently uDig cleaned up its jira -- and it has been fantastic; we should do the same here
 rgould: what kind of clean up do you propose?
 chorner: making sure that bugs haven't already been fixed, selecting a target version for fixes, and assigning bugs to people where applicable
 rgould: a cleaner JIRA would really help the changelogs during releases
 chorner: the main thing however, is that we haven't been maintaining it
 chorner: so I guess this is a call out to module maintainers: start looking at your jira space in the next few weeks
 rgould: it looks like the WMS module has been erased from jira?
 rgould: or maybe it's just empty?
 chorner: ...or any enthiastic volunteers
 rgould: ah, wms is just empty
 chorner: ok... that's it
 rgould: I think I will add a "next" command
 rgould: any have any thoughts regarding JIRA?
 rgould: ok.. 4: Start on time, end on time
 aaime: Well, I guess we are ending even before time :-)
 simboss: back
 simboss: too late ,_(
 simboss: ;-(
 rgould: no
 rgould: meeting is still going
 chorner: so we start at 12:01 next week, or to the gallows with ye?
 rgould: i think so
 simboss: cool
 rgould: acuster, did you have anything you wanted to say?
 acuster: nope
 rgould: ok
 rgould: back to 1: GC update
 rgould: simboss
 simboss: well
 simboss: there is not mcu to say except that
 simboss: the merge is in progress
 simboss: martin took a vacation on purpose for it
 simboss: we are exchanging some emails
 simboss: about conflicts
 simboss: I am hoping to find a way to help him out
 simboss: since he basicallly basically started while I was still planning the merge itself
 simboss: as aaime can confirm :-)
 aaime: Yeah :-)
 simboss: I think that for the moment
 aaime: Anway, the sooner we the merge ends, the sooner we can start working on FM :-)
 simboss: this is it as far as talking about gc merge
 rgould: ok
 rgould: no more items.. any have anything else they would like to say?
 rgould: yay!
 rgould: ok, meeting over
GeoTools 2.1.M4 Released (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 7 on Jul 12, 2006 11:00. created by Jody Garnett (jgarnett@refractions.net) on Apr 29, 2005 04:22

Geotools 2.1-M4 is available for download. This release brings us much closer to 2.1.0 (see Road Map to 2.1

The successful RnD work has been on:
1. FeatureType revision to provided "facets"
2. FactoryFinder revision to allow application control

I would also like to thank the new geotools volunteers, the number of bug fixes (David Blasby), and the progress of GridCoverage (Simone Giannecchini) is due to your hard work.

The release is made in conjunction with GeoServer 1.3.0-beta3
For more information: 2.1-M4

Changes between revision 6 and revision 7:

view all revisions | revert page to version 6
  Geotools [2.1-M4] is available for download. This release brings us much closer to 2.1.0 (see [Road Map]
  Geotools [2.1-M4] is available for download. This release brings us much closer to 2.1.0 (see [Road Map to 2.1]
  
 The successful RnD work has been on:
 1. FeatureType revision to provided "facets"
 2. FactoryFinder revision to allow application control
  
 I would also like to thank the new geotools volunteers, the number of bug fixes ([~dblasby]), and the progress of GridCoverage ([~simboss]) is due to your hard work.
  
 The release is made in conjunction with [GeoServer 1.3.0-beta3|GEOS:GeoServer 1.3.0-beta3]
 For more information: [2.1-M4]
2.2-RCO (Release Candidate) is Out (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 9 on Jul 12, 2006 10:26. created by Jody Garnett (jgarnett@refractions.net) on Jan 26, 2006 01:36

Congrats to Martin, Corey and Jody all of which have significant work appearing in this release.

New in this Release

New with this releaes is a Maven 2 repository: users can refer to it for automatic download of Geotools JAR and dependencies in their Maven 2 projects!

Also new in this releaes is Filter 1.1 interfaces for sorting, FeatureCollection has obtained two new methods:

  • sort( SortBy order ): FeatureList
  • subCollection( Filter ): FeatureCollection

This release has also seen a vast improvement in the performance of the aggregate functions used by color brewer to generate styles based on your FeatureCollections.

Help us Help You!

This release is the first one build with Maven 2 instead of Maven 1. It may have some issues like forgotten dependencies. Please let us know any such issues you may encounter. We will try to fix any reported build-related issues for 2.2 final.

Issue Tracker:

We need volunteers to:

  • make a release anouncement
  • upload to source forge
  • make a src release (this is a great oppertunity for someone to explore maven 2)

For more information on making a releaes please visit this page:

  • GEOT:How to cut a release

RnD Report

This represents the conclusion of the following RnD branches:

This is a release candidate, there is no scheduled RnD work remaining during the 2.2 timeline. We are clearing the decks to make way for improvments ot the Feature Model (aka Community Schema ) over the course of GeoTools 2.3.

Thanks to everyone for their hard work.

Changes between revision 8 and revision 9:

view all revisions | revert page to version 8
 Congrats to Martin, Corey and Jody all of which have significant work appearing in this release.
  
 - Downloads: [2.2-RC0]
 - Release Notes: [GeoTools - Version 2.2-RC0|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10270&styleName=Html&version=12097]
 - Repository: http://maven.geotools.fr/repository
 - Javadoc: http://javadoc.geotools.fr/
  
 h3. New in this Release
  
 New with this releaes is a Maven 2 repository: users can refer to it for automatic download of Geotools JAR and dependencies in their Maven 2 projects!
  
 Also new in this releaes is Filter 1.1 interfaces for sorting, FeatureCollection has obtained two new methods:
 - sort( SortBy order ): FeatureList
 - subCollection( Filter ): FeatureCollection
  
 This release has also seen a vast improvement in the performance of the aggregate functions used by color brewer to generate styles based on your FeatureCollections.
  
 h3. Help us Help You!
  
 This release is the first one build with Maven 2 instead of Maven 1. It may have some issues like forgotten dependencies. Please let us know any such issues you may encounter. We will try to fix any reported build-related issues for 2.2 final.
  
 Issue Tracker:
  
 We need volunteers to:
 - make a release anouncement
 - upload to source forge
 - make a src release (this is a great oppertunity for someone to explore maven 2)
  
 For more information on making a releaes please visit this page:
 - [GEOT:How to cut a release]
  
 h3. [RnD] Report
  
 This represents the conclusion of the following RnD branches:
  - [GEOTDOC:Random Data Access]
  - [Random Data Access]
 - [FeatureVisitor] & [http://colorbrewer.org/] (we don't have an RnD page)
  
 This is a release candidate, there is no scheduled RnD work remaining during the 2.2 timeline. We are clearing the decks to make way for improvments ot the Feature Model (aka Community Schema ) over the course of GeoTools 2.3.
  
 Thanks to everyone for their hard work.
GeoTools 2.2 RnD Update (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 17 on Jul 12, 2006 10:26. created by Jody Garnett (jgarnett@refractions.net) on Aug 25, 2005 23:26

Now that GeoTools 2.2 development is starting up in earnest it is time for quick intro to the RnD Page.

Timeline Adventure
September FeatureVisitor
September Feature Model Design Discussion
October Random Data Access
October ComplexDataStore project
January Grid Coverage Exchange Design

And there are a few other development ideas inflight, but I am unaware of their timeline.

On the lighter side I have finally restored James Macgill beloved compass. You know it is a tool that is used for understanging maps - perfect (probably why he chose it to begin with).

I have imaged it with transparency etc .. and it is now used for the confluence site's favicon and banner.

  shaded white
Icon: Unable to embed resource: gt.ico of type application/octet-stream Unable to embed resource: gt.ico of type application/octet-stream
Banner

Changes between revision 16 and revision 17:

view all revisions | revert page to version 16
 Now that GeoTools 2.2 development is starting up in earnest it is time for quick intro to the [RnD] Page.
  
 || Timeline || Adventure |
 | September | [FeatureVisitor] |
 | September | [Feature Model Design Discussion] |
  | October | [GEOTDOC:Random Data Access] |
  | October | [Random Data Access] |
 | October | [ComplexDataStore project]
 | January | [Grid Coverage Exchange Design] |
  
 And there are a few other development ideas inflight, but I am unaware of their timeline.
  
 On the lighter side I have finally restored [~jmacgill] beloved compass. You know it is a tool that is used for understanging maps - perfect (probably why he chose it to begin with).
  
 I have imaged it with transparency etc .. and it is now used for the confluence site's favicon and banner.
  
 | || shaded || white ||
 | Icon: || !http://docs.codehaus.org/download/attachments/593/gt.ico! | !http://docs.codehaus.org/download/attachments/593/gt.ico! |
 | Banner || !http://docs.codehaus.org/download/attachments/593/geotools_banner_small.png! | !http://docs.codehaus.org/download/attachments/593/geotools_banner_small.png! |
GeoTools 2.2.RC1 Released (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 3 on Jul 12, 2006 10:25. created by Chris Holmes (cholmes@openplans.org) on Mar 06, 2006 15:23

GeoTools is pleased to announce the release of version 2.2.RC1, representing the next milestone of stability on the 2.2 branch. Most improvements have been made to shapefile performance, with improved indexing of featureids, and much faster writing. Styling generating code has also been improved. We recommend to all users to transition to this version of GeoTools, and to submit bug reports and patches against. Major improvements should take place against trunk, or on a RnD branch. The release can be downloaded at: http://sourceforge.net/project/showfiles.php?group_id=4091&package_id=95639&release_id=399190

Changes between revision 2 and revision 3:

view all revisions | revert page to version 2
  GeoTools is pleased to announce the release of [version 2.2.RC1|http://sourceforge.net/project/showfiles.php?group_id=4091&package_id=95639&release_id=399190], representing the next milestone of stability on the 2.2 branch. Most improvements have been made to shapefile performance, with improved indexing of featureids, and much faster writing. Styling generating code has also been improved. We recommend to all users to transition to this version of GeoTools, and to submit bug reports and patches against. Major improvements should take place against trunk, or on a [GEOTDOC:RnD] branch. The release can be downloaded at: http://sourceforge.net/project/showfiles.php?group_id=4091&package_id=95639&release_id=399190
  GeoTools is pleased to announce the release of [version 2.2.RC1|http://sourceforge.net/project/showfiles.php?group_id=4091&package_id=95639&release_id=399190], representing the next milestone of stability on the 2.2 branch. Most improvements have been made to shapefile performance, with improved indexing of featureids, and much faster writing. Styling generating code has also been improved. We recommend to all users to transition to this version of GeoTools, and to submit bug reports and patches against. Major improvements should take place against trunk, or on a [RnD] branch. The release can be downloaded at: http://sourceforge.net/project/showfiles.php?group_id=4091&package_id=95639&release_id=399190
New GeoTools Article (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 5 on Jul 12, 2006 10:25. created by Jody Garnett (jgarnett@refractions.net) on Nov 10, 2005 16:28

Article:

  • Objects, Interfaces and Factories
  • Supporting Hacks and Versions

Explores the transition from Classes to Interfaces (what you need to know). Looks into this helps us with Plugins, Contains, and Future Proofing Geotools (what you don't need to know).

Changes between revision 4 and revision 5:

view all revisions | revert page to version 4
 Article:
 * [Objects, Interfaces and Factories]
  * [GEOTDOC:Supporting Hacks and Versions]
  * [Supporting Hacks and Versions]
  
 Explores the transition from Classes to Interfaces (what you need to know). Looks into this helps us with Plugins, Contains, and Future Proofing Geotools (what you don't need to know).
IRC Logs - October 11th (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 3 on Jul 12, 2006 08:37. created by Jody Garnett (jgarnett@refractions.net) on Oct 11, 2004 17:50

2004-10-11 October 11th
Happy canadian thanksgiving.

Changes between revision 2 and revision 3:

view all revisions | revert page to version 2
  
  [GEOTDOC:2004-10-11 October 11th]
  [2004-10-11 October 11th]
 Happy canadian thanksgiving.
IRC Logs - November 28th (updated)
News updated by Adrian Custer (acuster@gmail.com) to revision 3 on Jul 12, 2006 08:37. created by Jody Garnett (jgarnett@refractions.net) on Nov 29, 2004 16:24

The November 28th IRC logs are available.

Agenda:
1) CRS progress
2) Metadata unprogress
3) svn.geotools.org update
4) 2.0 status
5) Proposed IRC move time

Changes between revision 2 and revision 3:

view all revisions | revert page to version 2
  
  The [November 28th|GEOTDOC:5 November 28th] IRC logs are available.
  The [November 28th|5 November 28th] IRC logs are available.
  
 Agenda:
 1) CRS progress
 2) Metadata unprogress
 3) svn.geotools.org update
 4) 2.0 status
 5) Proposed IRC move time

More from the archive