Skip to end of metadata
Go to start of metadata

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

jgarnett I just remembered the new meeting time
jgarnett (hard to both deal with monday morning questions; and attend a meeting .. sorry for being late)
desruisseaux No worry, nothing started
jgarnett hrm
jgarnett okay sending email to the list now
desruisseaux I don't have any agenda topic for today...
jgarnett I noticed unsupported/go was removed?
jgarnett Is this a formal cancellation of the go-1 project?
jgarnett well we have some follow up to do from last week
desruisseaux No it is not a cancelation
graduation"
jgarnett Martin should I be doing something on this end? I feel like communication on has been poor recently?
desruisseaux I'm don't know if the issue is communication
desruisseaux This is true that we are not communicating as much as we could
desruisseaux And some of our comunication may be poor
desruisseaux When I have a strong opinion on a topic, I look like close minded
desruisseaux But while the community see the weakness as a communication issue from geomatys, on our side we are worried by the entropy of managing many project around the geotools code base.
jgarnett thinking
jgarnett the entropy?
simboss I would add a question about gridrange/gridenvelope to the topic list
jgarnett martin my thought is that we have these procedures and the PMC to account for the entropy.
jgarnett ie If a project wants to take part it can provide volunteers to geotools to handle the communication burden.
jgarnett martin I don't mind you appearing closed minded; indeed I value a good discussion with you - it results in high quality software (and we both learn from the discussion)
jgarnett I can think of a dozen examples (smile)
jgarnett My only concern is when people arrive "too late" to discuss stuff; ie when they actually have no time - and I think we try to be understanding about that.
jgarnett Is that what you meant by entropy?
desruisseaux I was thinking something a bit different
desruisseaux We started to cleanup metadata
desruisseaux fixing javadoc, splitting utilities methods in their own "utility" module
desruisseaux No design changes at this time
desruisseaux Then I have it Justin's converter classes in org.geotools.util
desruisseaux (typo: I have hit)
jgarnett ah
desruisseaux Those classes duplicates org.geotools.resources.ClassChanger, but Justin framework is more elaborated.
jgarnett I have not heard of class changer; I considered it a duplicate of the apache bean utils.
desruisseaux Nevertheless we have a duplication, so I wanted to retrofit the old ClassChanger functionality in Justin converters
jgarnett sounds great; I appologize if we knew about ClassChanger at the time we would of used it.
desruisseaux This kind of duplication is kind of the entropy I'm talking about
desruisseaux No it is not an issue - I do not expect peoples to known every bit that everyone write
jgarnett true
jgarnett thinking
jgarnett This was just before the change proposal process; do you think a change proposal (to introduce Converters) would of been enough
desruisseaux So it was part of entropy. Other part is that Justin converter were wrote in main module instead than metadata, but both defines classes in the same package (org.geotools.util)
jgarnett visibility
jgarnett that we could avoid the duplication?
desruisseaux No I don't think that a proposal would have helped much (more on it later)
jgarnett (thinking of this as a) technical thing to fix b) a process thing we could think about)
jgarnett okay keep going; I will shut up (smile)
desruisseaux So entropy = duplication, service duplicated in many module (in this case "utility" splitted between metadata and main; and furthermore "metadata" is probably a bad place for "utility")
desruisseaux Also implementation thats look like "brute force" (looping over every converter until one is found that doesn't returns null and doesn't throw exception)
desruisseaux I understand that a lot of things in GeoTools have been developped under time constraint.
desruisseaux This is where I think that the proposal process doesn't help a lot, because we often don't have the time to look at them carefully.
desruisseaux We end up trusting the guy who proposed it, and only later we realize that we could have fighted more against entropy.
jgarnett so far we average one proposal a month; and have two weeks to respond.
jgarnett I am trying to be "brutal" in getting people to document what they are doing in the proposal; so it takes less time for everyone to review.
jgarnett but I agree duplication is bad; proposal process may not catch everything.
jgarnett stronger measures (like code reviews) would take even more time.
jgarnett suggestions?
jgarnett Is having a two week chance to review a proposal "good enough" for you martin?
desruisseaux It is not only duplication; when I look at a code written by someone else, I often see stuff that I doesn't make me happy ("brute force" algorithms, eating exception in try .. catch ... log, bad usage of J2SE API...). It may be because I'm too maniac, but it make me worry
jgarnett martin: I agree - when out of time I tend to work on trust; I have stopped doing that in the last year and am "up front" when I am out of time and vote +0
jgarnett see this is why I like working with you; your worry is valuable to everyone (smile)
jgarnett is there any way we can address the kind of issues you mention above?
desruisseaux But this is where I came to an idea which I'm afraid would not be acceptable to the community
jgarnett I personally go in and fix stuff; and send email to the module maintainer as I go.
jgarnett but it is to little to be effective.
jgarnett I would rather set "find bugz" and use it to inpersonally catch mistakes like these. It works well for udig.
desruisseaux I got the feeling that GeoTools needs a "benevolant dictactor" in the way Linus is for Linux. I know that it is a radical point of view, but I have the feeling that the survival of the project as the "project of my dream" would need that.
desruisseaux But peoples can not be blocked because I dictator is too slow, or disagree, etc.
desruisseaux So this is clearly unacceptable on a centralized SVN.
desruisseaux But on a distributed system...?
dwins waves
jgarnett Hrm; I don't mind taking the roll.
jgarnett I am trying to work hard on geotools because it needs it.
desruisseaux If peoples are unhappy about a dictator on a given system, then can switch to an other distributed system managed in a different way.
jgarnett but I was going to take stock of what was needed for GeoTools 3; a dictator may be a good idea.
jgarnett not sure that works as a dictator; that is a democracy
jgarnett and personally I don't always trust the will of the masses on code decisions.
desruisseaux Thats my current though
jgarnett cool
jgarnett let us put it in the list for GeoTools 3
jgarnett now with OSGeo graduation out of the way
acuster dcvs solves the same problem in a more elegant way
jgarnett I promissed I would start taking action on those ideas.
acuster dvcs
jgarnett how so acuster
acuster everyone is dictoator over their repo
acuster they can decide what goes in
acuster the cost is everyone has to decide what goes it
acuster goes in
jgarnett (BTW acuster I had some usless naming questions for you - which would be very valuable for me; and prevent your annoyance in the future)
acuster which is why there are so many branches of linux
jgarnett I am not sure that this is an efficient approach; but yeah I get the idea.
acuster jgarnett, yes, on my todo list, you need answers today?
desruisseaux I'm done. I suggest to move on next IRC topic.
jgarnett acuster - if possible. I just want some words (we can chat on #udig)
jgarnett okay ... thanks for the chat guys
jgarnett 1) what is up
jgarnett jgarnett - trying to make sure the feature collection change did not break geoserver - dwins seems to have it all in hand. Working on bundling up a JRE+ImageIO-ext for udig development community. Juggling work responsibilities with open source commitments.
acuster acuster---iso19107 is messier than they would have you believe: I now have a working understanding of how geographic curves are expected to behave
acuster (well, that's a lie but a first approximation)
Eclesia hasck in puzzle-gis, and playing with JaxB
desruisseaux Martin: code review
simboss simone: ebrim
jgarnett acuster there was a good question on the JTS list as someone runs into some of the same questions (something about splitting a curve into a multi curve)
jgarnett oh; lucky simboss (smile)
jgarnett anyone else?
acuster yeah, that's in my inbox as a todo
jgarnett 2) follow up to OSGeo graduation
jgarnett It looks like we were successful; no official announcement yet.
jgarnett we have a couple blocker issues about license management to close up before the 2.5.x release.
jgarnett Firstly thanks so much for all the crazy hard work on this stuff.
jgarnett It has been long, brutal, and so on.
desruisseaux Thanks Jody, you worked hard on that too
jgarnett Hopefully over the next year we can benefit from this relationship on the "product" side of things; it sounds like we make do a few infrastructure things first (maven repository? etc...)
desruisseaux (the other one being Adrian)
jgarnett well thanks for keeping me sane. I know without acuster I would of slowed down on this stuff.
jgarnett Last week I was nominated as osgeo representative; as such I may get a few official questions
jgarnett I will punt each one of these to the geotools admin list; unless they are really really easy.
jgarnett And if you guys have questions about OSGeo; or if we have stuff we want to get done
jgarnett I can try and hunt down the right people.
jgarnett Does anyone have ideas for this week? Or can we relax for a bit and take this to email..
desruisseaux I have no additional item
jgarnett 3) gridrange/ gridenvelope
jgarnett simboss the floor is yours.
simboss thought/question for martin
simboss about the difference
simboss between what geotools does
simboss and what JAI does
simboss when cropping images
desruisseaux I saw email about cropping, but didn't investigated them.
simboss I have been sparing some time today to think about it
simboss even because I notice a while ago
simboss that you pushed the use of mosaic inside
simboss the resampler
simboss but that's another story....
simboss anyway
desruisseaux It is not a real mosaic
desruisseaux It doesn't take more than one image
simboss mosaic operator
desruisseaux Yes I know, but mosaic operator with a single image
desruisseaux (so it is not a real mosaic)
simboss I know (smile)
desruisseaux The mosaic operator handle the border outside the image in a special way
simboss if you ever looked at the crop operation
simboss I used it to crop rotated raster
desruisseaux This is the border handling that was interresting me, not the mosaic per se
simboss that is why I mention that
desruisseaux (sorry, lets continue on crop)
simboss but anyway if I crop an image
simboss with the JAI crop
simboss I always get the smallest rectangle that contains the requested area
simboss the behvaiour in geotools is slightly ifferent
simboss and can cause illegalargument exception
simboss if you try to cut a very small portion out of a coverage
simboss I think I managed to reproduce the same thing for resample as well
hudson geoserver-1.7.x build fixed (http://gridlock.openplans.org:8080/hudson/job/geoserver-1.7.x/54/)
simboss I think I could fix that for the Crop operation
simboss but I would like to have consistency with resample
simboss because probably sooner or later we could merge the two things into one, probably with a simplified interface for crop, reproject, resample, etc...
desruisseaux yes
simboss now the question is
simboss have you ever run into such a case?
simboss final annotation
simboss the sources of problems are 2
simboss generalgrid range roundings and usage of imagelayout
simboss done
desruisseaux I don't remember having seen that, but if you have a test case reproducing the issue that would be very appreciated.
simboss well, the idea is simple
simboss I get an envelope
simboss which is smaller than a unit in world coordinate
simboss I go back to raster coordinate
simboss w and h
simboss will be between 0 and 1
simboss exlusive
simboss if I ever use imagelayou
simboss or the gridrange constructor
simboss you'll get w and/or h as 0
simboss you might
simboss I think in this cases it would be better to have a behavior similar to the JAI behaviour
desruisseaux If the fix is just ensuring that width and height are always equals and greater than 1, I'm in favor of that.
jgarnett (back: was grabbed for a conversation)
desruisseaux Or do you think something more elaborated is needed?
simboss I still have to think a little bit about it, I'll try to capture thoughts in an email
simboss on a side
simboss I think we need to ensure
simboss that when we crop a coverage
simboss we always return something
simboss even if that something is bigger than the requested area
simboss e.g. 1X1 raster
simboss on the other side
simboss the generalgridrange constructor
simboss states the opposite
simboss if you recall it
simboss (hello? (smile) )
desruisseaux yes
desruisseaux (I need to look back what GeneralGridRange constructor said)
simboss so we might need to change that as well
simboss k
simboss anyway, i'll wrap that in an email
simboss since it might require some thinking
simboss I am done
desruisseaux Nothing more on my side...
jgarnett okay thanks guys
jgarnett I can post the logs.
simboss right on time
simboss :-9

  • No labels