It's been a big week for GeoTools releases, with both 2.6-RC1 and 2.5.8 hitting the streets.
GeoTools 2.5.8 has seen a number of changes including:
- Improvements Shapefile locking
- Various fixes to ImageMosaic stability
- Support for JDBC aggregate functions
To try out the latest release, head on over to the downloads page .
GeoTools 2.6 has finally reached release candidacy, with the resolution of a few key issues, including:
- Solving a crash when reading ECW files
- Updated the WCS 1.1 EMP model
- Resolved a reader exception caused by FastBBox filters
- The long-awaited return of the Javadoc build
For more information look to the 2.6.x branch page.
1) cleanup feedback
2) geoapi relationship
4) GeoTools site/blog
5) geotoolkit response
- Jody Garnett geoapi milestone release / dependency
- iant follow up at OGC meeting
- Jody Garnett http://geotoolsnews.blogspot.com/
- Jody Garnett response letter
(5:10:35 AM) aaime: rise and shine jgarnett
(5:10:43 AM) jgarnett: morning
(5:10:48 AM) jgarnett: a bit too early of a morning
(5:11:03 AM) aaime: damn timezones
(5:11:23 AM) aaime: can't you just live during the night and sleep during the day?
(5:11:28 AM) jgarnett: yeah daylight savings kicked in a while back so this is at least an hour earlier then expected
(5:11:38 AM) jgarnett: nope the point of moving to a sunny location is to see the sun!
(5:11:51 AM) aaime: aah, ok ok
(5:12:07 AM) aaime: jdeolive should be back, he's gone grab some food
(5:12:29 AM) jgarnett: okay cool
(5:12:52 AM) jgarnett: you will need to keep me from pestering him about jdbc-ng stuff; which is much more fun
(5:13:04 AM) jgarnett: I am going to do svn up and then get to work
(5:13:14 AM) jgarnett: I assume we are only clearning up trunk here?
(5:13:21 AM) aaime: yeah
(5:13:28 AM) aaime: that's what I was thiking to do anyways
(5:13:38 AM) aaime: 2.6.0 should see the light in 1-2 months anyways
(5:13:56 AM) aaime: (or else gs will have to cut it early and depend on some beta version of it)
(5:14:03 AM) jgarnett has changed the topic to: IRC Chat / GeoTools Future / Module Cleanup
(5:14:22 AM) jgarnett: I was thinking we should go with the Java numbering scheme
(5:14:37 AM) jgarnett: call it GeoTools 6 to respect both reality and the age of the project
(5:15:01 AM) aaime: lol
(5:15:26 AM) jgarnett: hey it is a good idea - you laugh at me :-P I am going to put coffee on
(5:16:27 AM) jgarnett: I am going to poke IanT who I think I see online
(5:16:46 AM) aaime: he is
(5:17:04 AM) ianturton: I'm back
(5:17:20 AM) jgarnett: ah ha!
(5:17:23 AM) jgarnett: good morning
(5:17:44 AM) ianturton: stupid notifier is quiter than the music
(5:18:13 AM) aaime: yeah, mibbit notifications are not good
(5:18:19 AM) jgarnett: stupid question
(5:18:21 AM) aaime: oh well, it seems jdeolive is not showing up
(5:18:29 AM) jgarnett: plugin\wms should really be extension\wms
(5:18:42 AM) jgarnett: except that we are starting to have "multiple" implementations of this sort of thing
(5:18:44 AM) jgarnett: wms-c
(5:19:00 AM) jgarnett: and there is a SOC student on the hook to do the other tile servers this summer.
(5:19:01 AM) ianturton: why are we having multiples?
(5:19:15 AM) aaime: well, as long as they don't share a plugin base stored in library, they are not plugins anyways
(5:19:22 AM) jgarnett: To capture all that stuff we would need a plugin mechanism.
(5:19:39 AM) aaime: but until we don't have it, it's not a plugin
(5:19:39 AM) jgarnett: indeed
(5:19:42 AM) aaime: let's think today
(5:19:47 AM) ianturton: OK
(5:19:49 AM) aaime: there's always time to move that back
(5:19:57 AM) aaime: if a plugin mechanism shows up
(5:20:00 AM) jgarnett: I will continue the move to extensions then
(5:20:08 AM) aaime: sounds good to me
(5:20:30 AM) jgarnett: but it may be wise to think up a plugin system; so we can capture some of these code contributions for the geotools library
(5:20:43 AM) aaime: jgarnett, I'll consider it when it's there
(5:21:02 AM) aaime: we have our hands full with today stuff without having to call for future/maybe stuff
(5:21:18 AM) jgarnett: some of this will fall to disucssions with you Andrea - with respect to MapContext and MapLayer. I thought I was going to have a free hand there but now both you and michael are active.
(5:21:45 AM) aaime: jgarnett, off topci
(5:21:58 AM) jgarnett: heh; repressed
(5:22:00 AM) aaime: please let's focus on today's issues
(5:22:11 AM) aaime: otherwise we won't get anything done
(5:22:37 AM) aaime: so, let's gather some topics?
(5:23:18 AM) jgarnett: sure; I was not sure if this was a meeting or a work party.
(5:23:30 AM) aaime has changed the topic to: IRC Chat / GeoTools Future / Module Cleanup: 1) cleanup feedback 2) geoapi relationship
(5:23:40 AM) aaime has changed the topic to: IRC Chat / GeoTools Future / Module Cleanup: 1) cleanup feedback 2) geoapi relationship 3) GeoTools site/blog
(5:24:05 AM) aaime: anything else?
(5:24:53 AM) ianturton: looks good to me
(5:25:12 AM) jgarnett: we have a couple other orders of biz; but perhaps they can be saved for email
(5:25:29 AM) aaime: what are they?
(5:25:40 AM) aaime: (can we talk about them here?)
(5:25:47 AM) jgarnett: we have to get a news post up with respect to new PMC members; and I see Cedric has accepted my nomination
(5:25:55 AM) aaime: Cedric?
(5:26:07 AM) jgarnett: wrong one
(5:26:12 AM) jgarnett: sleepy
(5:26:24 AM) aaime: ah, Christian
(5:26:25 AM) aaime: yeah
(5:26:45 AM) jgarnett: I almost lost his response in my email bucket
(5:27:00 AM) aaime: I don't keep mail folders threaded for that very reason
(5:27:09 AM) aaime: every now and then people answer an old thread
(5:27:26 AM) aaime: and I did loose the mail totally by keeping the folders threaded
(5:28:08 AM) aaime: voted for him
(5:28:17 AM) ianturton: Fortunately Gmail moves the tread up to the top when there's a repley
(5:28:26 AM) aaime: ah, nice one
(5:28:33 AM) aaime: thunderbird does not seem to be as smart
(5:29:10 AM) aaime: let's get started?
(5:29:13 AM) jgarnett: I have a filter set for thunderbird called "less stuff" that I have set to handle such things.
(5:29:16 AM) jgarnett: yep
(5:29:34 AM) aaime: 1) Cleanup feedback
(5:29:50 AM) aaime: Anyone has anything important/urgent about the module cleanup mails that was not addressed by mail?
(5:29:56 AM) ianturton: every thing looked good to me
(5:30:06 AM) eclesia firstname.lastname@example.org entered the room.
(5:30:20 AM) eclesia left the room.
(5:30:24 AM) aaime: at the end of the cleanup
(5:30:29 AM) aaime: everything should have a maintainer
(5:30:42 AM) aaime: I'm just a little worried about the mif/geomedia/gpx stuff
(5:30:51 AM) aaime: CampToCamp is using those modules
(5:31:01 AM) aaime: and they told me that they are thinking about stepping up as maintainers
(5:31:09 AM) aaime: but I had no confirmation
(5:31:17 AM) aaime: so I was thinking to keep those modules on hold
(5:31:26 AM) aaime: worst case, we can delete them next week no?
(5:31:44 AM) aaime: Also it seems the javacc-jjtree plugin is hard to kill
(5:31:50 AM) aaime: because of the way the parsers weer setup
(5:31:55 AM) ianturton: I don't think mif ever worked (unless someone finished it for me)
(5:31:59 AM) jgarnett: that sounds fine; I was also worried; as I have had reports of those modules saving peoples but in the past
(5:32:07 AM) aaime: (not in a standard way, and our custom plugin takes care of the weirdness of that)
(5:32:36 AM) aaime: ianturton, yeah, mif was taken over by an italian guy some time ago
(5:32:37 AM) jgarnett: I got a bit lost on that the jjtree plugin; I thought CQL used antlr or something?
(5:33:01 AM) aaime: and spatial data integrator from CampToCamp uses mif datastore successfully
(5:33:11 AM) aaime: jgarnett, nope, antlr is used by mbedward separate project
(5:33:15 AM) ianturton: cool - I don't have a MapInfo license any more
(5:33:46 AM) aaime has changed the topic to: IRC Chat / GeoTools Future / Module Cleanup: 1) cleanup feedback 2) geoapi relationship 3) GeoTools site/blog 4) geotoolkit response
(5:33:54 AM) aaime: jgarnett, anything else?
(5:34:12 AM) aaime: anyways, I'll write a last warning mail before removing the modules
(5:34:21 AM) jgarnett: a couple stupid questions I guess
(5:34:44 AM) aaime: shoot
(5:34:47 AM) jgarnett: can we issue a milestone release when this is done; and can we run mvn site and check that the various developer roles come out correct
(5:34:55 AM) jgarnett: (and we should publish javadocs again)
(5:34:59 AM) aaime: mvn site does not work
(5:35:10 AM) aaime: I tried out, it starts spinning on itself
(5:35:13 AM) aaime: building over and over the same moduels
(5:35:29 AM) aaime: I have no idea why
(5:35:33 AM) jgarnett: can we seperatly version the maven build tools
(5:35:49 AM) jgarnett: (which also prevent us building from a clean checkout when tagged)
(5:36:01 AM) aaime: I agree on that, but wouldn't that require a restructure of the svn
(5:36:08 AM) aaime: so that we give those a separate trunk or something?
(5:36:38 AM) aaime: or you say, we just keep them there and version them separately, working only on the current trunk
(5:36:46 AM) aaime: deploying them each time they are changed?
(5:37:17 AM) jgarnett: yep
(5:37:23 AM) aaime: that could work
(5:37:25 AM) jgarnett: just do not list them as children in the modules section
(5:37:27 AM) jgarnett: yep
(5:37:36 AM) aaime: but can we keep it as a separate step
(5:37:38 AM) jgarnett: we would need to change the developers guide a smidge
(5:37:40 AM) jgarnett: yep
(5:37:42 AM) aaime: after the cleanup is done?
(5:37:53 AM) jgarnett: I was figuring this was part of the clean up
(5:38:00 AM) jgarnett: but perhaps mvn site / javadocs is too much?
(5:38:08 AM) aaime: it is
(5:38:10 AM) jgarnett: (it was going to be my acceptence test to check if the work was done)
(5:38:16 AM) aaime: if you keep on expanding the scope
(5:38:19 AM) jgarnett: okay moving on ...
(5:38:20 AM) aaime: I will give up
(5:38:28 AM) aaime: because it's no more something I can do during the weekend
(5:38:38 AM) aaime: if I don't get chunks of stuff that I can start and end in a weekend
(5:38:45 AM) aaime: I won't be able to do it
(5:39:05 AM) aaime: I'm not saying not to do things
(5:39:17 AM) aaime: I'm saying to partition them into self contained, small steps
(5:39:35 AM) aaime: alternatively, let's find out someone that can spend a week doing this
(5:39:47 AM) jgarnett: understood; agreed; moving on?
(5:39:52 AM) aaime: yep
(5:39:59 AM) aaime: 2) geoapi relationship
(5:40:13 AM) jgarnett: This one is tough for me personally
(5:40:42 AM) aaime: in the end, to me it's simple
(5:40:44 AM) ianturton: me too
(5:40:56 AM) jgarnett: a) I find the geoapi project very worthwhile professionally - it has brought me a lot of great contacts; and has severed as a good venue for discussion and collaboration with the OGC
(5:40:57 AM) aaime: do we have the resources to be involved and discuss for days and days
(5:41:01 AM) aaime: the details of some iso spec?
(5:41:05 AM) ianturton: I feel we should support geoapi but if no o ne else is why bother
(5:41:41 AM) jgarnett: b) I find it a complete failure for its origional goal. James gave up in disgust considering it hijacked by the OGC; and then by Polexis and now I am concerned it is becoming a geomatys pony
(5:41:42 AM) aaime: geomatys people are going to push more and more changes into it
(5:42:02 AM) aaime: it is
(5:42:15 AM) ianturton: but unless Deegree or OpenJump start to use it we gain nothing
(5:42:28 AM) aaime: only someone that has plenty of time to discuss the nitty gritty details of all the ISO specs they are trying to implements
(5:42:32 AM) jgarnett: that was its origional purpose; but as I said that has been a failure.
(5:42:34 AM) aaime: can keep up with geoapi imho
(5:43:02 AM) aaime: I don't even have copies of the specs, nor time to read them
(5:43:16 AM) aaime: so, at least for me, it's impossible to participate in any meaningful way
(5:43:28 AM) ianturton: I have the same problem
(5:43:31 AM) jgarnett: well I certraintly cannot keep up with it on my own; I have talked privately with Martin with repspect to moving it to a milestone release cycle; but belive me I cannot find any easy answers.
(5:43:46 AM) aaime: I saw
(5:43:50 AM) aaime: I'm still subscribed to that ml
(5:43:52 AM) jgarnett: I find people pay me to keep up.
(5:44:34 AM) jgarnett: I also find it a nice quck way to pay attention to the specs; a few developers going over them and producing interfaces. But I have worked on geoapi a lot can can do this quickly.
(5:44:57 AM) aaime: so, it seems we don't have the resources to be involved, and we don't get any significant advantage out of that, no?
(5:45:38 AM) jgarnett: I do not want to be in the position of the only "outside" contributor; I was surprised just now to see a bunch of patches showing up for an upcomming OGC meeting. So I do not feel that involved; much like with geotools I feel like decisions are being made behind closed doors ... and that does not feel good.
(5:45:53 AM) jdeolive email@example.com entered the room.
(5:45:54 AM) aaime: the same amount of effort could be spent doing code, doing blogs, integrating with other osgeo work
(5:46:41 AM) aaime: jdeolive, log of the discussion so far: http://pastebin.com/m24523ba5
(5:47:15 AM) aaime: in the end I don't think it's a good idea to be spread that thin
(5:47:20 AM) jgarnett: I recognize this andrea; I feel we should talk the other PMC members; in particular I expect Ben's organization to freak out on this one
(5:47:44 AM) aaime: well, we don't have the resources to keep on fighting on that front
(5:47:49 AM) jgarnett: but for me personally I would be in +0 to dropping geoapi; and +1 to dropping geoapi-pending.
(5:48:15 AM) aaime: so if they freak out, they should provide the necessary resources to keep up the work
(5:48:20 AM) jgarnett: Indeed I would want to inform this decision based on our handling of the referencing module (the current scope of the geoapi jar)
(5:48:24 AM) ianturton: jgarnett - that sounds like a plan to me
(5:48:26 AM) aaime: I cannot just find time out of thin air
(5:48:46 AM) aaime has changed the topic to: IRC Chat / GeoTools Future / Module Cleanup: 1) cleanup feedback 2) geoapi relationship 2.5) referencing 3) GeoTools site/blog 4) geotoolkit response
(5:48:49 AM) ianturton: I'm going to the next OGC meeting so I can try to find out what's going on there
(5:49:03 AM) jgarnett: what time frame is that Ian?
(5:50:07 AM) jgarnett: andrea would you be okay with dropping geoapi-pending; and depending on a snapshot of the geoapi jar? So you are not forced to keep up...
(5:50:22 AM) ianturton: June somethime (endish)
(5:50:32 AM) aaime: for the short term
(5:50:43 AM) aaime: I would like to freeze the geoapi we depend on
(5:50:44 AM) jgarnett: how about until hune sometime (endish)
(5:50:49 AM) aaime: and stop changing it
(5:50:55 AM) aaime: for the next versoin of gt2 (2.7?)
(5:51:05 AM) jgarnett: (or 7)
(5:51:08 AM) aaime: I'm ok with dropping parts of geoapi and we can discuss what to do about referencing
(5:51:13 AM) ianturton: that would make sense
(5:51:21 AM) ianturton: - freezing that is
(5:51:38 AM) aaime: ianturton, yeah, that works as long as we need 0 changes on the interfaces
(5:51:55 AM) aaime: unfortunately we made the bad call of using geoapi interfaces everywhere in the code
(5:52:03 AM) ianturton: true
(5:52:04 AM) jgarnett: andrea while I feel this is a sensible response; I do not want to pressure you into anything; if Ben and the other PMC members come back and say to kill it I will not be in the way (see +0 comment above)
(5:52:05 AM) aaime: instead of using gt2 ones that did extend the geoapi ones
(5:52:39 AM) aaime: shall we move to the next one, referencing?
(5:52:56 AM) aaime: (and then come back to this one?)
(5:52:59 AM) jgarnett: let me formally propose so we can vote and move forward.
(5:53:12 AM) aaime: ok
(5:53:52 AM) jgarnett: I propose we drop geoapi-pending and depend on a milestone release of the geoapi jar until Ian reports back from the next OGC meeting.
(5:54:01 AM) jgarnett: +1
(5:54:06 AM) ianturton: +1
(5:54:07 AM) aaime: wait a second, I'm missing soething
(5:54:14 AM) aaime: how do we drop geoapi-pending?
(5:54:32 AM) aaime: by freezing the dependency on it?
(5:54:53 AM) aaime: and we keep on depending on geoapi-core snapshots?
(5:55:03 AM) aaime: Like, we're nearing a release for 2.6
(5:55:09 AM) jgarnett: fair nuff: I was thinking of depending on a milestone release; and then either folding it into geoapi (a license issue) or doing a bzr shadow copy.
(5:55:12 AM) aaime: so we should not do big api changes now no?
(5:55:31 AM) aaime: folding it into geoapi...
(5:55:41 AM) jgarnett: no the geotools api module
(5:55:47 AM) aaime: ah ok
(5:55:55 AM) aaime: so the plan really is
(5:55:58 AM) jgarnett: the geotools api module is designed to hold classes that are not ready for geoapi yet
(5:56:10 AM) jgarnett: so for me that is the same thing as geoapi pending
(5:56:30 AM) aaime: keep on depending on geoapi-core snapshots and depend on a milestone of geoapi-pending
(5:56:45 AM) aaime: mind thought, within 1 or 2 month we'll need something for 2.6.0
(5:56:58 AM) aaime: something that can be called a release, even if we are the ones labelling it
(5:57:35 AM) aaime: jgarnett?
(5:57:47 AM) jgarnett: I am catching up
(5:58:33 AM) jgarnett: so we all think the approach is "sane"; we just need to sort out the details for geoapi-pending; can we make use of a milestone release now; and come back to this another meeting.
(5:58:59 AM) aaime: imho we better start depending on a geoapi-core non snapshot as well
(5:59:05 AM) jgarnett: I intend to have us depend on geoapi milestone releases not snapshots for both geoapi and geoapi-pending
(5:59:15 AM) aaime: but we can go back to that when 2.6.0 is nearing completion
(5:59:18 AM) jgarnett: to be blunt
(5:59:40 AM) jgarnett: I want to draw a line in the sand (ie a milestone release) and then hear back from Ian towards the end of June.
(5:59:54 AM) aaime: that's totally fine by me
(6:00:03 AM) jgarnett: I think that is sufficient to allow us to proceed is it not?
(6:00:07 AM) aaime: let's package the geoapi of today as the one we depend on
(6:00:25 AM) aaime: and let's hear from ianturton in June
(6:00:38 AM) jgarnett: it is -r 1396 for reference
(6:00:41 AM) jgarnett: I will try tagging it now
(6:00:43 AM) aaime: jgarnett, would that work for you?
(6:01:09 AM) aaime: Ok, so the plan is package up geoapi as it is today, and depend on that solid
(6:01:27 AM) aaime: until we hear anything that may make us think otherwise
(6:01:30 AM) aaime: ok?
(6:01:30 AM) jgarnett: look it would work for me; and it is a responsible course of action; I just am generally a grumpy old man finding it hard to admit geoapi has failed in the goals I set for it
(6:01:46 AM) aaime: ok, +1 for me
(6:01:57 AM) ianturton: +1
(6:02:03 AM) jgarnett: we will need votes to come in from other PMC members out of band
(6:02:10 AM) jgarnett: next...
(6:02:17 AM) aaime: 2.5) referencing
(6:02:35 AM) aaime: I have some ideas here
(6:02:42 AM) aaime: one for the short term, one for the mid term
(6:02:51 AM) aaime: for the short term (2.6 timeframe)
(6:02:59 AM) aaime: we simply do nothing, keep the referencing modules as they are
(6:03:19 AM) aaime: it's not like there is anyone in a screaming need of major changes no?=
(6:03:50 AM) aaime: Opinions for this short term (lack of action) plan?
(6:04:04 AM) ianturton: sounds good to me
(6:04:14 AM) jgarnett: thinking
(6:04:50 AM) jgarnett: no that is fine; I will hear the mid term plan first...
(6:05:16 AM) aaime: mid term plan, for the 2.7 series
(6:05:39 AM) aaime: would be to find a way to get all the improvements that went into the geotoolkit referencing modules
(6:05:51 AM) aaime: without giving them a way to strangle us
(6:06:11 AM) aaime: which would be, to use mercurial to get our own copy
(6:06:12 AM) ianturton: how much of a change was there?
(6:06:16 AM) aaime: massive
(6:06:21 AM) aaime: you would not recognize the code anymore
(6:06:34 AM) ianturton: OK - is this a wait to move to java 6 thing?
(6:06:48 AM) aaime: no, I would port back their code to java 5
(6:07:11 AM) aaime: the thing is, I recognize there are improvemetns there
(6:07:19 AM) aaime: but I don't want them to set our pace
(6:07:30 AM) aaime: just like they did with Jody's patches
(6:07:42 AM) ianturton: well we could pull an update at any time we liked then
(6:07:44 AM) aaime: (1.5 year and no review, then total rewrite of it on geotoolkit)
(6:07:49 AM) aaime: that's the idea
(6:07:57 AM) aaime: clone, revert back to java 5
(6:08:12 AM) aaime: be free to use our copy of geoapi
(6:08:12 AM) jgarnett: yep
(6:08:14 AM) aaime: or our interfaces
(6:08:32 AM) aaime: be free to make our own changes without having to wait months
(6:08:46 AM) jgarnett: here is the thing; for planning. how much of an effort is that; do we need to get you a couple weeks free? what does it need to make it happen
(6:08:55 AM) aaime: and discuss for days on what is standard for them and what is reasonable for us
(6:09:12 AM) jgarnett: martin did talk to me about assisting; but I think it was a short term offer; and I have enough to handle right now.
(6:09:16 AM) aaime: right, I don't exactly know about that
(6:09:32 AM) aaime: simboss seemed to be interested in working on that
(6:09:39 AM) aaime: but sure resourcing is a problem
(6:09:59 AM) aaime: as opengeo is moving more and more to build on top of GeoServer instead of workin on the GeoTools foundations
(6:10:07 AM) ianturton: I keep meaning to get my head round refferencing - this might be my chance
(6:10:16 AM) jgarnett: so I think it is a fine mid term plan; or even short term plan if the amount of effort is low. the trick is figuring the amount of effort.
(6:10:29 AM) aaime: the code in geotoolkit seems less nightmarish than the one in gt2
(6:12:17 AM) aaime: so yeah, the idea of depending on a clone of geotoolkit works if we have resources
(6:12:31 AM) aaime: that needs to be compared with the eventual effort needed to keep the gt2 code alive
(6:12:51 AM) aaime: for very very minor maintenance I can keep up
(6:12:59 AM) aaime: I'm not worried about the math
(6:13:03 AM) aaime: but the class design is a maze
(6:13:18 AM) aaime: very deep inheritance hierarchies
(6:13:26 AM) aaime: silly tricks with SPI
(6:13:27 AM) ianturton: that's why I keep backing out of learning it
(6:13:36 AM) jgarnett: okay so as the PMC our best assistence would be to try and scare up resources in the time or money sense.
(6:13:48 AM) aaime: yep
(6:13:55 AM) jgarnett: aaime I do know the code; and have a plan to remove the silly tricks with SPI
(6:14:06 AM) jgarnett: but they have always fallen on deft ears
(6:14:30 AM) jgarnett: place that under "long term" plan
(6:14:35 AM) aaime: right, I remeber when everybody but Martin wanted to get rid of SPI and use some more modern container
(6:14:51 AM) aaime: (that was end of 2006)
(6:15:35 AM) aaime: (and who remembers the logging wars, where everybody but Martin wanted to use something other than java logging?)
(6:15:55 AM) aaime: but yeah, I agree that is more long term plan
(6:15:59 AM) jgarnett: stay on topic
(6:16:05 AM) aaime: roger
(6:16:19 AM) aaime: so it seems we have a sensible plan, we only need to scare out resources
(6:16:27 AM) aaime: let's move forward?
(6:16:31 AM) ianturton: +1
(6:16:36 AM) jgarnett: aaime; can we get a better scope on the work; that would help scare out resources.
(6:17:02 AM) jgarnett: 3) geotools site/blog
(6:17:42 AM) vheurteaux n=vheurtea@AMarseille-153-1-62-13.w86-200.abo.wanadoo.fr entered the room.
(6:17:43 AM) aaime: So here the idea would be to refresh the gt2 site and have a blog people do read
(6:18:02 AM) aaime: which seems a great one, but without any backing in terms of resourcing?
(6:18:09 AM) jgarnett: we could accomplish this by not posting IRC chats to our news feed; and submitting it to planet.osgeo.org
(6:18:14 AM) jgarnett: or setting up a blogger channel.
(6:18:49 AM) ianturton: that might work - announce on SlashGeo too
(6:19:04 AM) jgarnett: I think we can make improvements on the blogging side; I am keen to see a website developed and am on the osgeo marketting committe with this goal in mind (specically a geotools website with osgeo branding etc...)
(6:19:17 AM) jgarnett: however the marketting committee is kind of stalled out; making logos and so on ....
(6:19:48 AM) ianturton: I don't manage to keep my own blog going but I could write to a GT one sometimes
(6:19:56 AM) jgarnett: I think I would recommend blogger; why? because the confluence RRS feed is stupid
(6:20:00 AM) jgarnett: when wiki links update old posts.
(6:20:32 AM) aaime: is blogger the bloggin site manged by google?
(6:20:51 AM) ianturton: I think so
(6:21:08 AM) aaime: I would be ok with anything that is really dead easy
(6:21:23 AM) ianturton: Blogger is easy
(6:22:02 AM) aaime: what would the blog entries contain?
(6:22:09 AM) aaime: news about new features of geotools
(6:22:11 AM) aaime: releases
(6:22:14 AM) jgarnett: we use it for udig here: http://udig-news.blogspot.com/
(6:22:25 AM) aaime: did not even know it existed
(6:22:40 AM) ianturton: I could tell people about the book chapter on GT I wrote
(6:22:49 AM) aaime: indeed
(6:23:00 AM) aaime: jgarnet, that's on a different site thought
(6:23:05 AM) aaime: blogspot instead of blogger?
(6:23:30 AM) ianturton: same site
(6:23:34 AM) aaime: I see
(6:23:45 AM) jgarnett: okay back on track
(6:23:56 AM) aaime: so yeah, I would be ok with that
(6:23:59 AM) aaime: what about the wiki?
(6:24:00 AM) jgarnett: even a four page "site" that links of to the wiki would be fine
(6:24:09 AM) jgarnett: it has worked well for udig (the balance)
(6:24:21 AM) aaime: would the blog become geotools.org?
(6:24:24 AM) jgarnett: and what is up on codehaus/sourceforge etc right now is pretty scary.
(6:24:33 AM) aaime: with direct pointers to the wiki?
(6:24:35 AM) jgarnett: ah you miss understand me ...
(6:24:46 AM) jgarnett: compare:
(6:24:46 AM) jgarnett: - http://udig.refractions.net/
(6:24:46 AM) aaime: so ok, it would be separate
(6:24:55 AM) jgarnett: - http://udig-news.blogspot.com/
(6:24:58 AM) jgarnett: they are two seperate things
(6:25:03 AM) aaime: yeah, ok, family feeling
(6:25:12 AM) aaime: but how do we deal with the site/wiki then?
(6:25:29 AM) aaime: in order to better customize it we'd need to move it away from codehaus no?
(6:25:46 AM) aaime: (that's what we did for geoserver.org, besides a lot of issues with the site being unreachable)
(6:26:04 AM) ianturton: we should probably move to geotools.osgeo.org
(6:26:11 AM) jgarnett: we could move the wiki to osgeo hardware
(6:26:22 AM) aaime: but they don't support confluence
(6:26:33 AM) jgarnett: for an example of the new osgeo branding: http://wiki.osgeo.org/images/thumb/4/43/Osgeo_cover.png/450px-Osgeo_cover.png
(6:26:38 AM) aaime: how expensive would be the migration? It would seem it would take a lot of days?
(6:26:51 AM) jgarnett: aaime it would be us who would install and support confluence
(6:27:09 AM) aaime: look, confluence is a nightmare
(6:27:14 AM) aaime: it eats a lot of resources
(6:27:22 AM) ianturton: very nice branding - if only I had a booklet
(6:27:24 AM) aaime: you sure they would allow us to install it?
(6:27:39 AM) ianturton: I think it
(6:27:43 AM) aaime: with geoserver.org we had to give it a dedicated instance
(6:27:45 AM) ianturton: 's been talked about
(6:27:46 AM) jgarnett: then we can leave the wiki where it is; and seperate the site from it?
(6:27:54 AM) aaime: and remove qiute a bit of plugins to avoid it going OOM every 2 days
(6:28:56 AM) jgarnett: ianturton: you are correct I do have a geotools booklet - for a tutorial for foss4g - the important part is they are starting to have more then logos so we can start to build a site around the material.
(6:28:56 AM) aaime: and keep just the guides over there? may work, not super nice, but may work
(6:29:36 AM) aaime: I'm worried about maintenance
(6:29:37 AM) ianturton: actually I may turn parts of my web mapping course into a book/let
(6:29:46 AM) aaime: I guess we'd have to at least move to osgeo all release pages
(6:30:10 AM) jgarnett: hrm lots of ideas here
(6:30:33 AM) aaime: jgarnett, usual issue: resourcing (or, lack of it)
(6:30:34 AM) jgarnett: andrea as a wikie; confluence is not working due to codehaus anit-vandlism steps.
(6:30:37 AM) jgarnett: yep
(6:30:50 AM) jgarnett: we can take steps to cut down on the amount of work
(6:31:06 AM) aaime: jgarnett, my radical opiniong would be move the main site to osgeo
(6:31:14 AM) aaime: and turn the dev guide and user guide into sphinx format
(6:31:27 AM) jgarnett: we can drop the wiki release pages; and use the sourceforge etc...
(6:31:32 AM) aaime: (there is a converter from xhtml to restructuredText afaik)
(6:31:50 AM) jgarnett: in anycase i would find this less important then
(6:31:57 AM) jgarnett: getting an initial site together
(6:32:08 AM) jgarnett: and that less important then getting blog posts picked up
(6:32:24 AM) aaime: ok for initial site back pionting to the old wiki
(6:32:29 AM) aaime: and blog
(6:32:31 AM) aaime: you do it?
(6:32:32 AM) jgarnett: yep
(6:32:44 AM) jgarnett: not sure when I can get to this
(6:33:01 AM) aaime: (I can stretch to the impossible and do some blog posts... note how many I made on the geoserver.org blog )
(6:33:04 AM) jgarnett: it would at least kick the osgeo marketting email list along
(6:33:28 AM) jgarnett: aaime you already send "newsy" email to the devel list
(6:33:34 AM) jgarnett: sending those to the blog would be fine
(6:34:11 AM) jgarnett: in anycase can we table this; it is a strong direction; we can take action on the blog side; and will leave the website for another meeting
(6:34:24 AM) jgarnett: 4) geotoolkit response
(6:34:25 AM) ianturton: +1
(6:34:37 AM) pramsey firstname.lastname@example.org entered the room.
(6:35:13 AM) jgarnett: I feel I am in a good position to respond. I will compose an initial letter to the geotools-administration list; and then we can post it.
(6:35:47 AM) jgarnett: I would like to wait until after blog posts are sorted; and after the module clean up.
(6:35:58 AM) ianturton: I'm still not convinced we need to respond
(6:36:13 AM) jgarnett: will it be easier if I make this as a letter from me; as a geotools pmc member; or should I try and gather a bunch of input.
(6:36:31 AM) jgarnett: well I do feel the need to respond to martin leaving
(6:36:59 AM) ianturton: why?
(6:37:11 AM) jgarnett: we should thank him for his hard work if nothing else
(6:37:19 AM) ianturton: OK that
(6:37:31 AM) ianturton: is fair (stupid return key)
(6:38:11 AM) jgarnett: I will compose a letter; you can give me feedback before I post it.
(6:38:23 AM) jgarnett: if you hate it will not post it etc...
(6:39:11 AM) jgarnett: ...so here is a trick question. Where do we "post" the IRC logs? I would like to avoid posting them to the news feed (since that is what got us kicked off planet.osgeo.org)
(6:40:06 AM) ianturton: can we just have a wiki page that links to them and point to that in the blog
(6:40:07 AM) aaime: why did that happen?
(6:40:22 AM) aaime: can't we just have the feed report the summary, the topics?
(6:40:55 AM) jgarnett: each aggregator does it differently
(6:41:02 AM) jgarnett: planet.osgeo.org grabs the entire message
(6:41:09 AM) jgarnett: that is how it works....
(6:43:20 AM) jgarnett: okay I think we are out of topics
(6:43:23 AM) jgarnett: can we wrap this up?
(6:43:40 AM) CIA-76: jive * r33077 /trunk/modules/ (5 files in 4 dirs): move wms to extension
(6:43:48 AM) jgarnett: we can post this as a news item on confluence
(6:43:57 AM) ianturton: good plan
(6:44:05 AM) jgarnett: I can set up a seperate blogger thing for geotools
(6:44:11 AM) jgarnett: thanks everyone
(6:44:17 AM) jgarnett: productive meeting; if a little early.
(6:44:31 AM) jgarnett: thanks for the hard work all around
GeoTools is alive and kicking; well kicking out 2.5.5 release anyways. The developers have been very busy lately (organizing due to some staff changes).
Catching up with news posts - on May 5th GeoTools 2.5.5 was released featuring:
- Improved support for sparse shapefile
- JDBC-NG improvements
- Support for case insensitive like comparisons
- WMS client timeouts
- New filter functions that can convert types and format numbers
- New SLD vendor parameters to turn off label conflict
- resolution and set the goodness of fit while labelling polygons
For more details please check out the Release Notes.
Useful references for GeoTools users
There is now a GeoTools CiteULike library for useful papers, articles and other references relating to geo-spatial applications and computational geometry.
The library is freely accessible to search and browse. Items generally have keywords, abstracts and citation details plus a link to the full text where available. You can comment on an item, for example to point out errors or limitations in an article or to suggest an application.
You can also contribute your own references to the library (please do !). For this you will need to register with CiteULike.
Calling all grid coverage users.
Are you someone who:
- Needs to create, analyse or manipulate raster data ?
- Is often working at the image level with Java Advanced Imaging (JAI) ?
- Would like things to be easier ?
If so, then we need you...
GeoTools and JAI
GeoTools provides a number of classes that wrap JAI operators and allow you to do such things as arithmetic operations, resampling and basic convolution without needing write to JAI code yourself. But more complex operations usually involve working with the grid coverage's backing image data directly, often using JAI image operators.
The JAI-tools project
JAI-tools is an open source project, recently started by members of the GeoTools community. It aims to extend the Java Advanced Imaging library with new image operators and utilities.
JAI-tools is not a geo-spatial project itself. All of the JAI-tools components work in image-space (ie. with band and pixel coordinates) rather than geo-space. But one of the motivations in starting the project was to support GeoTools applications working with grid coverages.
One strand of the JAI-tools project is already being tested in this context: Jiffle, an image scripting language to apply mathematical expressions to image data. Andrea Antonello has bravely embedded Jiffle into the map calculator in his development version of JGrass. See Andrea's page on this work here .
Looking for guinea pigs
Now we are looking for other interested GeoTools users to try out JAI-tools components and give us some feedback. The source code is available from the project site and is set up to compile with Maven. Please be aware that all of the is in a pre-release state at the moment and assume that it contains bugs and other undocumented features.
If you would like to provide specific feedback on the jai-tools code, the best way to do so is to subscribe to the mailing list . General comments and suggestions that you think would be of interest to the wider GeoTools community can be posted to the GeoTools users' list.
Sydney, Australia. 2 March 2009.
In response to requests from presenters, the deadline for the FOSS4G 2009 workshop and tutorial abstract submissions has been extended by one week, to Monday 9 March 2009. If you are considering submitting a workshop, please notify your intent by emailing the Workshop/Tutorial coordinator, Mark Leslie
FOSS4G, held 20-23 October 2009 in Sydney, Australia, is the international "gathering of tribes" for open source geospatial communities. The theme for the FOSS4G 2009 conference will be "User Driven". Users and developers are encouraged present their latest projects and software to demonstrate the power of Open Source for system integration through a series of workshop sessions and tutorial presentations. Session participants should expect to see presentations on both geospatial open source and propriety software integration along with pure open source solutions.
Workshops are expected to be a hands-on experience with participants following along with the instructor, working directly with the application under discussion. All workshop rooms will be equipped with computers (two students sharing one system) to support this vision. Workshop computers will pre-installed with a basic image containing standard packages running in a Windows XP environment. A projector will be provided for each computer room for use within a workshop. Instructors will need to discuss pre-installation requirements with the Conference Organising Committee if required.
Workshops are expected to require considerable effort to create, with past experience showing that three days of preparation per hour of presentation are required to produce a high quality workshop. Additionally you will be expected to develop material for attendees to take home with them, such as handouts, workbook, CD-ROMs etc. Due to the effort involved in producing and presenting a workshop, instructors will receive a single complementary registration to the conference for delivering a workshop.
All workshop submissions will be considered, but particular interest will be shown in the following topics:
- Practical Introduction to ____
- Integrating Open Source
- Spatial Data Privacy and Security
Tutorial rooms will not be equipped with computers, however presenters may optionally make use of delegate laptops and the FOSS4G LiveDVD.
At least 80% of delegates are expected to be carrying a laptop and FOSS4G LiveDVDs will be given to all delegates.
Preference will be given to hands-on tutorials.
Any hands-on aspects to a tutorial will be the responsibility of the presenter and needs to be described in the tutorial description. Presenters making use of the Live DVD or Climate Change Integration Plugfest (CCIP) will be expected to contribute to testing pre-releases to ensure material and software is properly installed. To discuss your requirements for LiveDVD, please contact the organising committee: http://2009.foss4g.org/contacts/.
All tutorial submissions will be considered, but particular interest will be * shown in the following topics:
- Practical introductions
- Spatial data accuracy
- Spatial data privacy
- Spatial data security
- System implementation
- Data migration
The deadline for workshop / tutorial submissions is March 9, 2009
<simboss> ciao mbedward
<simboss> or michael
<mbedward> hi simone, andrea
<mbedward> I'm not sure how to start - do you have something you would like to begin with
<aaime> Is this a meeting?
<mbedward> no just a chat
<mbedward> about jai-related things
<simboss> well, the floor is yours
<simboss> daniele is coming
<simboss> not sure if antonello is around
<simboss> looks like is not
<simboss> checked on the udig channel
<mbedward> I can wait a few minutes - that's no problem
<simboss> if you did not sent around a reminder
<simboss> it might be that he has forgotten
<mbedward> yes - I'm afraid I forgot about reminding anyone
<mbedward> perhaps we can just start chatting - we can always go back if he joins us or rehash later
<aaime> if you want any chance of him showing up send a mail to him and Silvia
<mbedward> ok, I'll do that now
<moovida> morning folks
<moovida> thanks for the email
<mbedward> no worries
<moovida> I was working on a bug and forgot
<moovida> what did I miss?
<mbedward> we haven't started
<moovida> oh, great!
<mbedward> we couldn't start without you !
<mbedward> perhaps I'll begin my just describing my immediate project needs that have led me down this path
<moovida> good for me
<mbedward> for an app that I'm working on at the moment I need to be able to do two things
<mbedward> 1. allow a user to create a grid coverage based on mathematical expressions
<mbedward> where the user just provides a relatively simple script
<mbedward> and the expressions have spatial position and/or other coverage data as inputs
<aaime> just for the record, Sextante has some raster algebra support built-in
<mbedward> ok - I'd be interested to hear about that in a minute
<moovida> mbedward: what do you mean by: the expressions have spatial position?
<--| ggesquiere has left #geotools ("Bye")
<mbedward> basically functions of x,y coords
<moovida> not row/column, but instead coordinates?
<mbedward> could be row/col, or proportion of width/height etc
<moovida> can you make an example in which you would want to use coordinates inside an expression?
<moovida> ah, ok, got it, wanted to be sure
<mbedward> sure: my app is about animals in landscapes
<mbedward> responding to various resources
<mbedward> imagine I want to create an artificial resource map
<mbedward> with a north-south gradient
<mbedward> I might do that with a simple linear function plus a noise component
<moovida> ok, nice
<moovida> so you are talking about functions really or more neighbour cell touching?
<moovida> I mean you won't be able to embed a function based on position in a static approac
<moovida> you will have to use relative positions between cells?
- moovida has difficulties to explain himself
<moovida> so the gradient will be based for every cell on values of the cells around it
<moovida> is that what you mean by function?
<mbedward> that's not what I was think about in the example...
<mbedward> although neighbourhood stuff certainly comes in lates
<moovida> ok, good, how would a hipotetic function look like?
<moovida> you have an idea already?
<moovida> the linear function for example
<mbedward> value = xpos * alpha + beta + random(sigma)
<mbedward> where xpos could be position along coverage axis scaled as 0 -> 1
-->| mauricio (n=mauro@128.Red-80-36-0.staticIP.rima-tde.net) has joined #geotools
<moovida> sounds good
<mbedward> so very simple
<mbedward> this was the idea behind 'jiffle'
<mbedward> the ANTLR grammar that I'm fiddling with
<mbedward> it's essentially a simple expression evaluator
<mbedward> I've put the current ANTLR parser and tree grammars on to the project site
<mbedward> they are very preliminary but maybe give you some idea when you look at them
<mbedward> but it isn't joined to images yet
<mbedward> now that I've got basic arithmetic, trig functions etc in jiffle
<mbedward> the next thing I'd like to do is work out how to plug input image data into the interpreter
<mbedward> I was interested in the r.mapcalc page that you pointed me to yesterday
<aaime> again for the record, what about Janino? http://www.janino.net/use.html It can be used to compile expressions into bytecode. Makes the evaluation very fast
<moovida> r.mapcalc is what I will need and for which I could work
<mbedward> I don't know this at all - would be very interested to know more - have you used it ?
<moovida> and I think it contains also what you need
<moovida> so, how could I/we help you?
<mbedward> you mentioned that you were using jep previously ?
<aaime> sextante does too
<aaime> (use jep)
<moovida> yes, I did for a while
<moovida> but it is now closed source
<moovida> and so I would not want to use it any more
<moovida> or better, I do not use it any more
<aaime> yep, that's why I looked into janino a little bit, to suggest Sextante an escape route
<mbedward> I understand jep was highly optimized
<moovida> yes, it was, but from that moment on they closed the source
<mbedward> at the moment speed is less important for my needs than just ease of use and flexibility
<mbedward> and having something that I can understand !
<moovida> ok, but you would not want to use jep, right?
<mbedward> what are your r.mapcalc needs ?
<mbedward> no - I want to use open source
<moovida> my needs are well inside yours
<moovida> functions would be great
<moovida> because they contain also functions based on several maps
<moovida> and conditions are important
<moovida> things like:
<moovida> if in map1 the value is null, do that, else take value from map2
<moovida> but I think on this we have the same ideas
<moovida> so one question from an ignorant antrl person
<moovida> antrl is used as a functional language "compiler"?
<moovida> and then you need something to evaluate the transformed language?
<mbedward> it is general parser building tool
<mbedward> similar in aim to lex, yacc, bison...
<mbedward> for example
<moovida> ok, so thorught that you get your java language for the math you write
<mbedward> you can
<mbedward> or C, or python or other things
<mbedward> it can be used to build a translator
<mbedward> but what I am interested in is an interpreter
<mbedward> so two steps...
<mbedward> first provide a grammar that describes the language elements (similar to EBNF)
<mbedward> from this ANTLR helps you to build a lexer and parser that can accept language statements
<mbedward> detect syntax errors
<mbedward> re-arrange things for faster processing
<mbedward> the output of this first step is a tree representation of your input statements
<mbedward> Abstract Syntax Tree in the jargon
<mbedward> second step is to build a 'tree-walker'
<mbedward> this knows how to take navigate the tree-representation of your 'program'
<mbedward> and you can embed the code for actions into the walker
<mbedward> that's a really terrible explanation )
<mbedward> I'll give an example
<moovida> I understand, the JGrass console is built like that
<moovida> now I am very sorry we didn't use antrl
<mbedward> antlr is really cool
<mbedward> I'm only learning
<mbedward> but it is possible to get quite a bit done in a small amount of time
<moovida> the developer created an own compiler, and now every time I have to changes something, I get mad
<moovida> yes, that was my feeling of antrl
<moovida> sound really good
<mbedward> in the past I've written parsers by hand and this is **much** easier
<moovida> what timeline did you think of for this?
<moovida> also, were are you based?
<mbedward> I'm already very late
<mbedward> I'm in Sydney
<moovida> argh, I found one in London and thought we could meet for an initial push
<mbedward> I think he works for the BBC
<mbedward> I saw his name on TV once
<moovida> hmmm, then let's get back to the timeline, Sydney is out of budget for this project
<moovida> just to understand if we could coordinate
<moovida> I also have to study antrl first
<moovida> so it would be good to see if we are at least a bit in sync
<mbedward> well, it's very fuzzy for me and there are many strands to my project that I can also work on when it's not convenient to be in sync
<mbedward> sync in time I mean
<mbedward> there are good intros on the antlr site
<moovida> great, I'll check them out
<mbedward> I want to find a good starting approach for inputting image data into the interpreter...
<mbedward> r.mapcalc had the simple convention of var names
<mbedward> if not functions etc. they were assumed to be maps - is that right ?
<moovida> yes, and keeping those would help me get JGrass -> GRASS compatibility
<moovida> yes, exactly
<mbedward> I was thinking of something slightly more indirect
<mbedward> though it might still be compatible
<moovida> users have huge scripts for mapcalc to do the most powerfull things
<mbedward> I thought that would be the case
<mbedward> so it would be great to be compatible
<moovida> good you think so
<moovida> at least to start like that
<mbedward> I want to keep this all as modular as possible
<moovida> then there are always possibilities to get out of compatibility
<moovida> what do you mean?
<mbedward> well the interpreter is one module
<mbedward> it 'knows' (will know) how to access data from some provider interface
<mbedward> but the provider implementations could be quite diverse
<mbedward> my thinking is very fuzzy...
<mbedward> in r.mapcalc is there any sort of definition section for variables / inputs
<mbedward> or do they just appear in statements ?
<moovida> I don't understand exactly what you mean
<mbedward> is there anywhere in the script where you have to declare var names prior to using them ?
<moovida> you can have also variables evaluated in steps and then used inside the script
<moovida> no, var=eval() is enough
<mbedward> I need to go study r.mapcalc while you look at ANTLR
<moovida> then we have a sort of plan
<mbedward> yes !
<moovida> even if I feel it will take me some longer
<moovida> the mapcalc module can do very complex things
<moovida> did you think to make a constatly usable progress?
<mbedward> definitely !
<moovida> I mean, start to work and get a version that supports some functions and son and on?
<mbedward> otherwise giant mess !
<moovida> great, that sounds good
<moovida> same for me here, and also the project then can grow
<moovida> slowly and stable
<mbedward> there is also a second strand to this work - JAI operators
<mbedward> especially for neighbourhood map calculations
<mbedward> I need to be able to do the sort of things that, in the old, old days I might have done in arc-info
<mbedward> esp. focal functions
<mbedward> e.g. average neighbourhood value, dominant value, number of discrete values...
<mbedward> I was a bit surprised that these were not already in JAI operators
<moovida> are you sure there aren't?
<mbedward> also being able to constrain these and other calculations with mask / ROI
<moovida> sounds strange to me also
<mbedward> I think some of these things could be useful to geotools etc. generally
<mbedward> and I would like to open source my code for new operators
<mbedward> so I plan to put them on the jai-tools site also
<moovida> seems to be a lot of work to be done
<moovida> what was your schedule again?
<mbedward> I'm very very late
<moovida> for yesterday or so?
<mbedward> but I am also the project manager
<mbedward> unfortunately the project does not have enough money to employ a real programmer...
<mbedward> so an ecologist is doing the job
<moovida> ecologist and environmental engineer
<mbedward> obviously there is overlap between ANTLR side and jai-operators side
<moovida> any other person that wants to join the brigade?
<mbedward> I think / hope simone is interested in the jai operators strand
<moovida> simboss, dany_r ? What about you guys?
<dany_r> yes he's interested
<moovida> mbedward: just to have an idea, you need a version that does x,y,z for date a,b,c
<moovida> can you tell about x,y,z and a,b,c
<moovida> if you are allowed, and just a more-or-less
<moovida> is enough
<mbedward> yep, roughly anyway...
<moovida> this job is resources absorbing and if I help I want to be able to really do so
<mbedward> in next month I would like to have the scripting working to the point where
<dany_r> our aim would be allowing handling, chaining math operations and functions in JAI operators.
<mbedward> it can do arithmetic and basic math/trig functions already in grammar
<mbedward> plus conditional expressions
<moovida> hmmm, I guess that will not be exactly the case
<moovida> am I right?
<mbedward> and access data from input images
<mbedward> (will get to that in a sec)
<moovida> doing it mbedward's way will mean that no chaining occurs?
<mbedward> if I can get that working by end of Feb that would be very good for me
<mbedward> ok - in terms of output
<mbedward> I have thought about two approaches, each of which I'd like to implement
<dany_r> in this right moment Simone is not here but he can provide you more details about its idea very soon.
<mbedward> first is interpreter produces output that can be linked to a JAI image function
<moovida> sorry guys, I have to run, could anybody post the logs, or send me the logs, if much is said after this moment?
<mbedward> no worries
<moovida> mbedward: I am very interested to join the efforth, but I have to understand if I am ablr to contribute that early
<moovida> to do so, I will study antrl in the next days
<moovida> and study what you already did
<mbedward> you can then tell me all the mistakes
<moovida> would be glad to
<moovida> and let's keep the discussion in the list active please
<mbedward> will do
<moovida> thanks for the chat
<--| moovida has left #geotools
<mbedward> dany would you like to keep going when simone comes back ? or I can pen some thoughts and send them to you...
<simboss> ciao michael
<simboss> I am back
<mbedward> ciao simone
<simboss> sorry, but I have someone here, so I had to talk to him
<simboss> I am all yours now
<mbedward> I think we were only just getting to teh things you are most interested in
<mbedward> jai operators plus
<simboss> ah great
<mbedward> possibility of using an interpreter to help make image functions etc.
<simboss> well, at this stage
<simboss> my interest is in having a good project
<simboss> where we can drop JAI operators
<simboss> so that we can releases
<simboss> in a more stable manner
<simboss> JAI is not dead
<simboss> but it's a zombie
<mbedward> why has that happened ?
<mbedward> it's hard to understand
<simboss> the members of the prject are heavily involved in other projeects
<simboss> well, it's simpler than it seems
<simboss> JAI was created under bih push from JPL
<simboss> the Jet Propulsion lab fa NASA
<simboss> they used in a few mission
<simboss> and they are still using
<simboss> and it's pretty good the way it is
<mbedward> but there are some surprising gaps
<simboss> they are not interested in moving it forward
<simboss> or in babysitting
<simboss> but it's an empasse
<simboss> they do not want to spend time on it
<simboss> but they are not releasing it
<simboss> as OS
<simboss> that's why I started imageio-ext
<simboss> and I am happy to see something like JAI-operators
<mbedward> are there tricky licensing issues ?
<mbedward> for instance
<mbedward> I have written a modifed convolve operator
<mbedward> that can use an ROI
<mbedward> so it's really just a hack of the existing image op
<simboss> my advice about code from JAI is use it as a template
<simboss> but rewrite it all
<mbedward> I see
<simboss> the license is too messy to reuse that code
<simboss> for imageio
<simboss> you can reuse it, but that's another story ....
<simboss> I am hoping that sooner or later SUN will OS JAI and Imageio
<mbedward> I have a number of operators that I need for my current project
<mbedward> so I would like to open source these
<simboss> if we show them that there is a community able to ensure the continuity of the projects that might help them to make up their minds
<mbedward> that would be great
<mbedward> but surely they must know that jai is very actively used already ?
<simboss> yeh they know very well
-->| dany_r_ (email@example.com) has joined #geotools
<simboss> but their team, while very very good, is small
<mbedward> I should compile a list of the operators that I will be needing soon
<mbedward> and send it to you
<mbedward> perhaps some are already available and I have overlooked them
<mbedward> otherwise it will be the list of things I will be coding in the next month or two
<simboss> there is one thing
<simboss> that I might want to bring up
<simboss> I did the same thing with antonello a while ago
<simboss> are your operators geospatial-aware (e.g. they need some parts of geotools torun)
<mbedward> not so far
<simboss> or do they run in the pure raster space, where there is no notion of geospatial
<simboss> I would recommed to be careful with this in order to not introduce circular dependencies between the teo projects
<mbedward> I understand
<simboss> usually I try, whenver possible, to clearly separate geostuff (geotools) from pure raster stuff (jai or imageio)
<simboss> the key for doing this is usually the gridtoworld transform
<simboss> (probably I am going to far, but I think it is important to say at least once)
<mbedward> yes, that's good point to bring up early
-->| acuster (firstname.lastname@example.org) has joined #geotools
<mbedward> so far
<mbedward> for example with the convolve operator I mentioned
<mbedward> that works in raster space
<mbedward> then there is a wrapper for geo-spatial part
<mbedward> but I agree with you that keeping those things separate is best
<mbedward> and I also find it easiest
<mbedward> anyway, regarding the project and site
<simboss> following you...
<mbedward> I am very open to
<mbedward> approaches to managing it / handling releases etc
<mbedward> I don't have fixed ideas or
<mbedward> requirements in that regard
<mbedward> and to begin with
<mbedward> I will just be gradually uploading my operators
<mbedward> and working on the ANTLR related strand
<mbedward> we are probably done for now - yes ?
INFO Preference "collapseMsgs" is "on".
<simboss> I think
we would like to port one operator
that is right now inside geotools
which we could probably somehow join with your stuff
we should develop also a simple operator
<-- acuster has left irc.freenode.net ("Leaving")
<simboss> thatcan be used
to transform a single color
into a trasparent color
<mbedward> which is the operator in geotools ?
<simboss> it is buried inside the renderer since there was not complete consensu about where to put it
<CIA-21> aaime * r32368 /trunk/modules/ (4 files in 3 dirs): GEOT-2316 jdbc-ng should advertise query capabilities
<simboss> it can be used to create a piecewise transformation
<mbedward> have to go in minute - sorry
<simboss> np, I think we are done
<-- dany_r has left irc.freenode.net (Read error: 113 (No route to host))
<mbedward> thanks simone !
<simboss> thanks to you man
Some good news from the developers list today. The ECQL documentation is finished and the implementation is now available on trunk.
The OGC Common Query Language is defined as part of the catalog specification and provides a very readable text format for defining Filters. Filters are also use by the WFS specification to select data.
However the CQL format leaves out a few of the capabilies that WFS supports. The ECQL syntax documented above extends the CQL syntax allows you to do everything WFS is capable of.
Jody Garnett (PSC member) here - I have been unable to attend the formal IRC meeting time do to a change in timezone. As such I am setting up an informal IRC chat time for the month of February for Q&A and hopefully to work through a range of fascinating topics, ideas and directions that have emerged for the GeoTools library.
Click on the link to see the time in your area:
I have an idea for this week already:
- Week 1: Review the state of Filter with Andrea, consider FilterCapabilities (ie function list) and Function
Here are some ideas to consider for the rest of the month (not each depends on hunting down a party I know is interested)
- Go over the rendering module and clean it up for documentation in the user guide
- Figure out OSGi bundle plan (requires Harald Wellmann)
- Go over bzr (with Adrian Custer?)
- Review jdbc-ng work and go over migration stratagy
- Set up some good MemoryDataStore, MemoryFeatureCollection implementations (with Frank Gasdorf?)
- Review the FeatureCollection / FeatureSource plans Justin wrote up last year
The idea is for some hands on community work; with a PSC that can review and commit patches if needed.
Happy Hacking and welcome to 2009.
Hey look at that, another week with no IRC meeting!
Probably we should move the time to some moment accessible by Jody since generally speaking he's the most reliably enthusiastic member of the community.
– acuster has changed the topic to: Weekly IRC 2009.01.12 — get yer topics in
<acuster> lively debate this week, lots of energy....
<acuster> three more minutes and we can call it a meeting
<acuster> Okay, well that does it then. Great meeting everyone, we should do this every week.
– acuster has changed the topic to: Discussion channel for GeoTools, a library for geospatial processing in the Java language.
So technically, each PMC member is supposed to read this and comment on it. Perhaps they have all moved on?
The GeoTools project has moved repositories today - to hardware maintained by the Open Source Geospatial Foundation.
We would like to thank Refractions Research for giving us a home for the last five years (they kindly provided an svn repository for us when Source Forge was going through some growing pains in 2003).
The new hardware is faster and has a better connection which will result in a faster build time for those building with maven.
The new code repository is located here
To migrate an existing checkout to this new location please use:
This move also opens up a new maven repository (used to host the compiled geotools artifacts so other projects can use them). If needed you can add the following to your maven pom.xml:
Documentation that has been updated in response to this move:
0) What is up?
1) Geotools.org domain
2) meeting time for sydney
jgarnett good morning
jgarnett sorry to be late - packing up on this end.
jgarnett if we email email@example.com they may know something about the domain
acuster it's james macgill's
acuster registered in england
acuster we need to recuperate it
acuster negotiates with osgeo
acuster jgarnett, when are you leaving?
jgarnett I left refractions last week
jgarnett I am on a plane this Friday
jgarnett (so this week is packing - I will not be online much)
acuster no month long holiday in between?
jgarnett nope - refractions did not pay well enough for that
acuster osgeo is willing to hold the registration for us
acuster so that seems like a viable option either when james answers or when his control lapses
jgarnett understood; thanks for figuring that out
acuster anything else jody?
acuster anyone else?
jgarnett well I have been following aaime's progress on filter clean up
Eclesia has left #geotools
jgarnett and all I can say is
jgarnett I really appreciate the work you are doing.
aaime Ah hety
aaime sorry, I did not realize the meeting time moved for me
jgarnett but nothing important from me ... if I cannot hack I should not waste meeting time.
aaime since we went back to solar hour tonight
jgarnett note this meeting time will be unsuitable for me after this week
aaime right right
jgarnett I would recommend two meeting times (like we did for geoserver for a while)
aaime maybe we can negotiate a different time... not sure if there will be any time good for everybody
jgarnett one agenda carried over to the next ...
aaime we can try
aaime so you'll be in Sydney right?
aaime Victoria might soon become irrelevant meeting time wise
jgarnett depends when jdeolive picks up sticks
acuster early morning au and late night eu is the only one that works
acuster if memory serves
aaime if we do a single meeting, yep
jgarnett in anycase we do not need to make the decision today
aaime I must have picked the wrong Victoria above
aaime this one looks better:
aaime jgarnett, not sure what the times for gs meetings were
jgarnett they were at 12:30 pst
aaime I mean, as far as I can see the table it seems Sydney is going to do a stand alone meeting anyways?
jgarnett perhaps we will have to see what kind of community I can scare up
jgarnett I may be reduced to reading logs.
jgarnett in anycase we do not need to decide this week; and next week I should be jet lagged and awake.
aaime Ah, I have news about labelling
aaime we got a sponsor that is giving us the possibility to implement label displacement on lines in case of conflict
aaime and labelling long lines multiple times
aaime if we're lucky, maybe even curved labels along roads
aaime and multi line labels
aaime (the latter is unlikely, but we'll see)
aaime atm I'm coding a modified label cache in geoserver
aaime then we'll see how to donate back to gt2
jdeolive i think someone is playing voodoo with geotools... the sourceforge site says "invalid project"
jdeolive when i go to http://sourceforge.net/projects/geotools/
aaime jdeolive, it shows fine for me?
jgarnett not for mee
jdeolive hmmm... wierd
jdeolive i just refreshed and its ok again
jdeolive like i said... voodoo
jgarnett agreed it is back
aaime jgarnett, I guess you have no powers over that dns issue?
jgarnett pramsey figured out some stuff last time
jgarnett but I think it is about the same as what acuster told me a few minuets ago.
jdeolive who owns the domain?
jgarnett we could see about redirecting geotools.osgeo.org
acuster osgeo is willing and able to take over control of the domain
acuster if we can wrestle it from james
acuster I suggest we sponsor jody to go threaten james
acuster since they will be on the same continent
vheurteaux_ (firstname.lastname@example.org) has joined #geotools
jgarnett I thought james was in NY now?
aaime I don't know
acuster ah? /me has no idea
aaime but yeah, I head something along those lines some time ago
jgarnett well that may be it for the meeting
jgarnett if someone can post the logs I would not mind reviewing the earlier discussion
vheurteaux has left freenode (Read error: 110 (Connection timed out))
acuster there was none
apetkov (i=a6071a31@gateway/web/ajax/mibbit.com/x-369702630bef51df) has joined #geotools
=-= jgarnett has changed the topic to "Visit us at http://geotools.codehaus.org/"
jgarnett that will do for a subject line today.
apetkov geotools' svn down today?
desruisseaux (email@example.com) has joined #geotools
acuster apetkov, only the dns
acuster anyone have the numeric address?
apetkov not me
aaime Ben posted it on the ml
aaime just a sec
aaime you can use: 126.96.36.199 svn.geotools.org
aaime if you prefer a name: gtsvn.refractions.net
=-= jgarnett has changed the topic to "Visit us at http://geotools.codehaus.org/ (source code at http://gtsvn.refractions.net/ )"
aaime jgarnett, I'm still waiting from some examples on your part on the function factory issue
aaime 'cause I don't understand what you're suggesting and how it's supposed to be used
oterral123 has left freenode ("Leaving.")
jgarnett hi aaime
jgarnett I am going to have to go soon; but perhaps I can explain
jgarnett the idea is to make sure that we can always represent the expression (or SLD)
jgarnett as provided by the user
jgarnett regadless of if we have an implementation or not.
jgarnett is that part okay?
jgarnett just treat a function expression like a data structure
aaime sort of
jgarnett so I want to make sure we can do that; so geotools can be used to construct an SLD file for a WMS
jgarnett that has functions available to it
aaime yeah ok, I don't like it but I get it
jgarnett that we have not implemented in geotools.
jgarnett (for example).
jgarnett Or expressions for a datastore that has functions that we have not implemented in geotools.
aaime and then what?
jgarnett so there are two ways to do this ...
jgarnett a) try all our implementations during creation time (ie filterfactory.function( String, List<Expression> )
jgarnett b) or try finding an implementation when execute is called
jgarnett At least that is the only two I have thought of ...
aaime a) seems a bit more natural to me
aaime if you don't find an implementation, return a placeholder that will return the fallback value or throw an exception when it's called
jgarnett if we choose (a) like we do right now; we need to make sure the factory has a placeholder function ... and that is what it has right now (but it only uses this placeholder if you have provided a fallback value)
jgarnett bingo - so that is what we got.
aaime that deals also with the case in which you're hitting the datastore that can evaluate it, but you cannot encode it because it's mixed up with something else that cannot be encoded
aaime b) would require major changes in the code, and I don't see the advantage
jgarnett And we are both comfotable throwing an exeception if an implementaiton cannot be found; and no fallback value is provided?
aaime I am
jgarnett The advantage for me was that we could make our own "library" extension - and have it cover the Function and the FunctionName use cases.
aaime we just have to decide wheter to do so at parsing or execution time
aaime I'd say execution
aaime there I lost you
aaime we already have a function extension point
jgarnett yeah; execution - because people should still be able to create the data structure (perhaps it is not even for geotools after all)
jgarnett our function extension point is not very good IMHO - we seem to need to cover the FunctionName data structure
jgarnett and I would like to have a larger unit to contribute then just one function at a time.
jgarnett But you had some good suggestions about that? A FunctionFactory ?
aaime a factory that can generate many functions
jgarnett Note if we are contributing at execution time - then we do not need to contribute a GeoAPI Function
aaime and I mean, that is orthogonal to the idea of treating the function as a data structure and locating the actual implementation at execution time
jgarnett we can contribute something smaller if that is helpful.
aaime something... smaller?
jgarnett so to back up; we are totally happy with how function is shaping up.
jgarnett I am interested in talking about the "FunctionFactory" interface
aaime it seems to me we're already registering with the bare minimum information?
aaime (even with the proposed function factory, that would just barely return argument count and name)
aaime how can you make anything... smaller?
jgarnett I was under the impression that we registered with too little information; and we were having to double back and register functionName implementations.
jgarnett (note I would like to also list attribute names if that is okay;
jgarnett and I have the difficulty of variable legnth functions)
aaime The idea I had is that you register the factory
aaime and the factory has the names and whatnot in code
aaime for whatever function it generates
jgarnett right; so you see how a factory would "produce" a Function?
jgarnett if we are doing it at execute time
jgarnett then we do not need it to produce a function
jgarnett we could have it produce an answer.
aaime and would that be any better? Oh, instead of having a raft of classes
jgarnett perhaps you should talk about binding at execution time?
jgarnett right ...
aaime you only have a big switch statemnet?
Eclesia (firstname.lastname@example.org) has joined #geotools
jgarnett switch statement
jgarnett or reflection onto static methods ...
jgarnett you get the picture.
aaime the latter would be good for execution
aaime but it won't give you the argument names
aaime (no debug info, no arg name available in the vm)
jgarnett that is what I was meaning by a "Library" extension point. I am sorry I could not find the email where I proposed the idea...
=-= vheurteaux_ is now known as veurteaux
jgarnett that is the part where it is weak; annotations could help. But perhaps it would be a waste of time ...
aaime yeah well, it's doable but it would be quite a change
jgarnett I was just trying to think of the bare minimum that someone could right.
aaime So ok, the idea is nice, I just doubt I can stand that much work
aaime filter switch is already killing me
jgarnett Note I am happy with FunctionFactory approach
aaime and we have a million deprecations around out of the styling changes that again no one cared to fix
jgarnett I am sorry to be away from the code base; when you are working so hard.
aaime jgarnett, the issue has been there forever
jgarnett stylebuilder / stylefactory are murder
aaime I just decided that if I wasn't doing that, nobody would
aaime yeah whatever, the usual stuff, people complains, nobody moves a finger
jgarnett aaime++ - I have done small amounts; but nothing like what you are doing now.
jgarnett I wanted to ask how you were doing with filtercapabilities; that is where I got a little stuck last time.
aaime atm I stil haven't looked deeply into it
aaime I'm trying to fix one thing at a time
aaime otherwise the job is so big that I will loose any interest before even starting
cbriancon has left freenode ("Leaving.")
jgarnett thanks for the chat andrea; easier than swapping email back and forth
aaime I'm considering adding a proposal
aaime in which whoever deprecates an API
jgarnett I have implemented the "Library" idea once; for the WPS work
jgarnett (it was one of the approaches we considered)
aaime finds the resources to clean up all the usage points in the library
jgarnett I should go soon.
jgarnett um stupid idea; we could kill an ant with a hammer here
jgarnett and use the wps proccess class
aaime ugh, heavy
jgarnett it does the same work; we just needed way more detail on the wps side
jgarnett yeah - stupid idea.
aaime or maybe not
desruisseaux has left freenode ("ChatZilla 0.9.83 Firefox 188.8.131.52/2008101012")
aaime I mean, if the process generates just one scalar output
jgarnett and not appropriate; filter is "typeless"
aaime it could be considered a function as well
jgarnett We experimented with that; as I recall it was mostly to allow a programmer to write less code.
jgarnett (make the easy case easy etc...)
jgarnett okay enough of that; if I can find the library example I may send it to the email list.
aaime cool thanks
jgarnett And if you have any questions I can help you with please send them my way; I will be checking email and stuff.
jgarnett Is it worth posting the logs from todays "meeting"?
jgarnett yeah it probably is - no news in a while.
jgarnett (besides nobody can find the website)
The GeoTools 2.5 release is available for download:
The 2.5.0 release marks the first stable release of a number of exciting
developments and features of the 2.5.x series including:
- New feature model based on GeoAPI
- Java 5
- Support for units based on JSR-275
And much more. The entire change log can be found here:
Other exciting news for the GeoTools community includes graduation from
incubation as a project The OSGeo (Open Source Geospatial Foundation).
Special thanks to everyone who provided feedback and filed bugs for this
release. As usual a big thanks to Geomatys, GeoSolutions, Refractions
Research, and OpenGeo, and most importantly the user and contributor
community for continuing to drive GeoTools and make the project a success.
For more information about this release and about the GeoTools project
in general please visit:
0) What's up
1) 2.5.0 release
2) JDBC mosaic/pyramid plugin
3) geoapi geometry work
Weekly IRC meeting 15 Sept. 2008:
- What is up
- Meeting time
- GeoAPI version for Gt 2.5
- GeoTools 2.2.4
- volunteer for osgeo meeting
- 2.5.0 and mvn assembly
- meeting time remains as documented here 3.1 Internet Relay Chat in the developers guide
- the 2.5.x branch will be making use of the GeoAPI 2.2-M2 tag for the duration
- Jody Garnett should release 2.2.4 this week when moovida has given the go ahead
- Justin Deoliveira has volunteered to represent GeoTools at the annual OSGeo meeting
- Gabriel Roldán is waiting on GeoServer acceptance tests prior to releasing 2.5.0; we are stuck on the use of mvn assembly target and may fall back to an earlier "jar collector" solution.
aaime cannot find the official meeting time in confluence
jgarnett: I think it was 17 mins ago; sorry I am late
jgarnett: oh apparently it is in 10 mins
jgarnett: see http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett: I will send a reminder email to the list now.
aaime: damn, no wonder I did not find it, I kept on looking for IRC
aaime: not for the expanded version
jgarnett: I jumped to the section on communication and found it that way.
jgarnett: Good morning Andrea; thanks for fixing the streaming renderer bug last week.
Eclesia: (hi all)
jgarnett: Hi Eclesia; got your email.
jgarnett: I hope the comments about OSGi on the mailing list are clear; the changes being described are all to the MANIFEST.MF file; and do not effect anyone using the jar as normal.
jgarnett: I am not going to worry about it much until there is a solid proposal to look at; since I do not personally know what lines need to be added to the MANIFEST.MF; but it sounds like this is something Maven can handle for us.
axelfrancois_ left the room (quit: Remote closed the connection).
acuster: the changes sound like they could be useful
Eclesia: ok, then I will see how NetBeans RCP will handle it.
acuster has changed the topic to: Weekly IRC meeting 15 Sept. 2008: 0) What is up 1) Meeting time 2) GeoAPI version for Gt 2.5
jgarnett: well I hope Mr. Wellmann will make things more clear.
jgarnett: But yeah; I am sure the normal java classloader ignores things in the MANIFEST.MF that it does not understand
jgarnett: I have used a subset of GeoTools in this manner before
jgarnett: a couple minuets before the meeting; looks like we already have agenda items ...
jgarnett has changed the topic to: Weekly IRC meeting 15 Sept. 2008: 0) What is up 1) Meeting time 2) GeoAPI version for Gt 2.5 3) GeoTools 2.2.4
jgarnett: you return ...
jgarnett: okay meeting time; let us round up agenda topics...
jgarnett: I trust that everyone is busy getting ready for FOSS4G - so todays turn out is pretty good.
jgarnett: 0) what is up
jgarnett: jgarnett - I am releasing 2.2.4 this week (or at least tagging it - I will need to dig to come up with the right build environment), I am also working on a fork of 2.5.x for a customer (thanks to those who helped me check out a specific revision last week)
groldan email@example.com entered the room.
arneke firstname.lastname@example.org entered the room.
jdeolive is preparing for foss4g... putting together workshop / lab materials
simboss: simboss- refactor geotiff and geojp2
aaime has been working on the new Oracle data store, and now it's trying to get some more juice out of gt2/gs
groldan is working on WMS for nd coverages, namely fixing describelayer to handle coverages at all
Eclesia cleaning code
desruisseaux: Martin: geotidy
jgarnett has changed the topic to: Weekly IRC meeting 15 Sept. 2008: 0) What is up 1) Meeting time 2) GeoAPI version for Gt 2.5 3) GeoTools 2.2.4 4) volunteer for osgeo meeting
jgarnett: fun stuff all around.
jgarnett: 1) meeting time
jgarnett: We have the official meeting time marked down here:
jgarnett: - http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett: but it has been less than a month since this was changed; so there is still some confusion each week.
jgarnett: I hope this current timeslot is more suitable to those in Europe?
KevinIPS_ n=KevinIPs@97-116-20-214.mpls.qwest.net entered the room.
aaime: very much
desruisseaux: Good for me
acuster: okay for me
jgarnett: I suspect that this topic was on the agenda - simply because it was hard to track down the above link?
acuster: no, because people showed up early
acuster: that hasn't happened in years
acuster: so clearly something was up
aaime: ha ha ha ha
jgarnett: cool - anything else to be said on this one?
jgarnett: (I do want to keep starting the meetings on time - so we can schedule our lives a bit more reliably)
jgarnett: 2) GeoAPI version for GeoTools 2.5.3
acuster: I'm starting to eye changes to GeoAPI; for those changes to happen I'd like to know what their impact will be on geotools
jgarnett: adrian I tried to answer this via email; I did make a formal GeoAPI tag for the 2.5.x branch when it started.
jgarnett: so you should be good to go; but you are free to check my work.
acuster: right, can I assume that the branch will use that tag for ever more?
aaime: I believe you're willing to change geoapi geometry no?
acuster: I am filing bugs against geoapi only
aaime: the changes, will they be in the geoapi geometry interfaces?
jgarnett: acuster you are correct; that tag will be used for 2.5.x
acuster: yes, the changes will be in the geoapi geometry interfaces
acuster: on trunk/ I will either fix the geometry module or let it die a slow death
aaime: I believe they are not a problem, not even in trunk... nothing is actually using them besides the geom unsupported modules, right?
acuster: okay, that's that topic
oterral123 left the room.
jgarnett: acuster if it would hep you feel better; we may be able to strip geometry out of the 2.5.x series?
aaime: acuster, I see no issues from the GeoServer point of view
jgarnett: then you would feel more comfortable making the geometry APIs not suck.
acuster: jgarnett, not out of 2.5
jgarnett: okay; just checking.
acuster: that can stay since it has an appropriate geoapi
cbriancon left the room (quit: "Leaving.").
acuster: I don't care what happens to that
acuster: on trunk I'll negotiate with you when I have a better sense what is needed
jgarnett: good good
jgarnett: I have no current project making use of geometry interfaces; I only care that they are clear
jgarnett: 4) volunteer for osgeo meeting
grolda1 email@example.com entered the room.
jgarnett: At FOSS4G they are going to have some kind of meeting
jgarnett: I spoke at the one last year
acuster: hmm (3)
groldan left the room (quit: Nick collision from services.).
grolda1 is now known as groldan
jgarnett: 3) GeoTools 2.2.4
jgarnett: I think I can finally tag 2.2.4; I am waiting for the go ahead from Moovida; and then I can tag (and deploy / release)
jgarnett: any questions on this one? Other than horror that it is still around and active?
aaime: horror? no, actually funny
aaime: (and no, of course no issue there)
jgarnett: must only be a horror for me then
jgarnett: 4) volunteer for osgeo meeting
jgarnett: let me try it again
jgarnett: There is a yearly OSGeo meeting; taking place at FOSS4G (or before?)
jgarnett: As an official project now we need someone to crash the meeting and give a status update. Last year I was only able to say we were still inccubation (which got a round of laughter)
jgarnett: this year we actually have progress to report.
jdeolive: aaime or myself can probably do that
jgarnett: I am not sure who exactly is going to FOSS4G this year; but I would like to request a volunteer.
jdeolive is not sure who else will be there...
aaime: Jesse will be
jgarnett: It should be someone from the PMC if we can possibly manage it; it is supposed to be my responsibility but I am not on site.
jdeolive: is jesse on the psc?
jdeolive: i am fine with taking that on
jdeolive: can you possibly provide a hit list of things to touch on jgarnett
jgarnett: - we graduated
jgarnett: - 2.5.0 should be the first official release with 0SGeo (c)
jgarnett: (I would like to to actually exist by foss4g - but have not seen it come up in the agenda)
jgarnett: that is about it.
jdeolive: jgarnett: hopefully it will... we still want to get gs 1.7.0 out by foss4g
jgarnett: good good
jdeolive: although... i admit, its looking dim
jgarnett: hrm; so that means you may call a code freeze on 2.5.x near the end of the week?
jdeolive: depends on how much progress we make on the geoserver side of things
jgarnett: gabriel did we ever make progress on the maven assembly target?
jdeolive: afaik gt is all ready to go is it not?
jdeolive waits for groldans report
jgarnett: gabriel should we grab another agenda item for this?
groldan: so far I didn't found a way for assembly not to package everything, and didn't get back to it neither
jgarnett has changed the topic to: Weekly IRC meeting 15 Sept. 2008: 0) What is up 1) Meeting time 2) GeoAPI version for Gt 2.5 3) GeoTools 2.2.4 4) volunteer for osgeo meeting 5) 2.5.0 and mvn assembly
jgarnett: martin; were we ever able to explain the difficult to you? Perhaps it is something you could advise us on?
groldan: we could but I'm not sure what else could be said about it other than someone should investigate deeper on how to configure the assembly plugin or what command to run etc
afrancois n=afrancoi@AMarseille-251-1-90-95.w86-202.abo.wanadoo.fr entered the room.
acuster: is that the only thing stopping a final 2.5 release?
jgarnett: from the geotools side yes
jgarnett: I think geoserver is still doing some acceptance testing on there end
groldan: something I could do if I get assigned to do the release, btw, but so far I didn't have the opportunity to get back to the issue
jgarnett: but that can show up as a "dot" release if needed.
desruisseaux: I tried assembly plugin a bit, but I ended up using the custom "jar-collector" stull instead (I didn't found at that time how to configure the assembly plugin exactly like I wanted - but maybe it is more configurable today).
jgarnett: the problem acuster is that; even with me using profiles to stip all the "unsupported" modules from the build; mvn assembly will still package them all up into a single archive.
desruisseaux: (typo: stull --> stuff)
jgarnett: perhaps jar-collector could last another round?
jgarnett: I think gabriel even tried not building them; and they got pulled down from the maven repository and assembled.
desruisseaux: I'm neutral on that.
groldan: even with a clean local repo it got them from the refractions one
jgarnett: I just wonder how it did that; ie how did it know the list of "child" modules to assemble up?
groldan: since it was after the deploy -Dall
jgarnett: if you do not have the -Dall set; will it package up what we want?
KevinIPS left the room (quit: No route to host).
jgarnett: okay well I think this is going to wrap up the meeting
jgarnett: Gabriel; if you do get the go ahead to make the 2.5.0 release
jgarnett: send email to the list and we can try mvn assembly one more time; or dust of jar collector.
grolda1 is now known as groldan
groldan: sorry my clunky connection again
jgarnett: I can post the logs; thanks for the quick meeting everyone.