Thanks for grabbing the logs Martin,

I was busy so I do not have a summary of this one ...

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

Reply via email to