Hey all, This discussion makes it clear to me, once again, that distributed coding of complex code in the absence of very complete design documents is simply stupid. It appears that those of you working on the coverage part of the Geotools library don't share the same understanding of the fundamental internal design of the module so it should be no surprise that this discussion has been so complex.
The issue is not so much that Geotools lacks a change proposal for Martin's current work; the issue is that there was never a good design document created for the coverage module. Indeed, a change proposal document could only make sense as a change proposal *against* an initial design. Since Martin started all this work in his own corner, he didn't write up a design document for himself---he just kept his design stored in his overly large brain. We should really have written up such the design document when other coders came along who were interested in working on the coverage code; of course, the issue then was that Martin was busy and isolated while the programmer's impulse appears to always be to code first and design later. (Jody and Jesse will recognize this rant from the uDig list where I emit it regularly; and yes, I also understand the financial constraints that contribute to this situation.) The correct thing to do right now would be to stop and write up the design document. In a discussion with Martin, we agreed that it would be good to write up Martin's design on our end since Martin maintains his design is sufficiently general to encompass all the current needs and sufficiently low level to guarantee a satisfactory level of performance. Also, I'm sufficiently ignorant of the entire chain and am pedantic enough that if he can satisfy me enough that I feel I've written up a decent document, then perhaps you all will have a draft ready for your serious evaluation. (Jody, yes, we plan to take care of your user docs at the same time, maybe even of my languishing docs for non-hacker scientists). Unfortunately, it is also clear that we can't embark on this work for a few months due to contractual obligations on our end. In the interim, you others are unfortunately in a bind and you will have better solutions for your needs than I can possibly offer. If you have your own design you could write that up as your working design document. If you have a different code structure, we could fairly easily fork the two efforts as two separate unsupported modules on trunk. Alternatively, you could embark on the write up the current design; yes, it sucks that it would be much harder for any of you than for Martin, but that's not a problem I can solve. It also sucks that we are not using a distributed VCS system where you all could simply avoid pulling from Martin's tree for a few months. In the meantime, we have a disconnect and only you all can figure out the solution for your needs. The only thing I can offer you all from my end right now is actually off topic. I can commit to you that for ISO geometry, as far as I am involved, this will not happen. I will not simply create a 'friedEgg' module wiki page and call that enough. Even though it's going to take several months to do, I'm going to write up a design document for the ISO geometry work *before* I start hacking on the code. It's already clear that previous efforts haven't understood the same problem that I see in the ISO geometry work so I can see we need clarification. I need to lay out my thinking to make it clear what use cases the work attempts to handle, how this design interacts with ISO/OGC specs, with GeoAPI and with the rest of Geotools, and how the design is reflected in the code packages, control flow, and exception emission. With such a document, I think it will be possible to collaborate, to correct flaws in my thinking, and to build world class code with each contributor pitching in where and when they can. Right now, I'm on the train to go talk with mathematicians as part of this design process. In my personal experience with scientific code, design is *much* more work than coding so I'm going after the design full tilt. We'll see what comes out of it all. Simone, I'm really puzzled by your mail; do we really not yet have a shared vocabulary for the various possible image formats and their mappings through analytic manipulation to user output? If we don't even share a common understanding of what data is what, how could we possibly be expecting to be building code together to do complex things on that data? Regardless, you could contribute significantly to any eventual design document by writing up some of your use cases. Over the past couple of years, I've heard Martin say repeatedly that your work has forced him to generalize his design to deal with situations where users either want to skip or don't know enough to define the step of mapping file data to 'values they care about' but rather want simply use and display the image raw: image data -> display colours. You obviously have done a bunch of work in this area, so one thing you could contribute to any eventual 'coverage design document' would be a set of use cases pulled from your experience. If you can produce a bunch of different cases, say a good paragraph on each describing the raw file contents, the required operations, and the desired output, these use cases could eventually be integrated into the Geotools coverage design document whomever gets around to creating it. Ideally, we can get a good example of each type of data for users to compare to their situation and thereby understand the code path to create. These use cases should at least get us all using the same terminology in the same way. Andrea and Chris, You asked some questions when our last discussion left off which I was waiting for clarification from Geomatys in order to answer. 1) Martin's 'scientific' approach will not necessarily be significantly slower than an 'image' approach for the simple case of images with no user defined mappings. Martin is working at the lowest level possible to minimize the work, reduce memory load, and leverage the efficiency of the JAI system. We will have to see actual performances when he finishes his approach. Only then would it really make sense to think of adding a 'short circuit' path for images that have no defined mapping to real world values. 2) Collaboration being stalled with Geomatys is indeed not necessarily permanent but a convenience of the moment. We will have to see if the forces re-align someday. For now, time constraints are the master. 3) Participation in a european geoserver codesprint and in the geoserver tele-conference doesn't make much sense from the Geomatys side of things since no one has looked at geoserver in several months and no one is working on it right now. Perhaps next year. All the best, --adrian On Mon, 2008-02-04 at 01:42 +0100, Simone Giannecchini wrote: > On Feb 1, 2008 7:21 PM, Martin Desruisseaux > <[EMAIL PROTECTED]> wrote: > > Jody Garnett a écrit : > > > a) the api changes that are happening; is this part of the expected long > > > term GeoAPI plan? (if so it would fall outside our proposal page process) > > > > No, this views stuff (geophysics, packed, etc.) do not appear at all in > > GeoAPI. > > They do not appears in any OGC/ISO specification I'm aware of. I don't plan > > to > > bring that stuff in GeoAPI since I suspect that it would be highly > > controversial > > (it is already in GeoTools alone). > > > > This stuff exists only because I try very hard to conciliate two worlds: > > > > - data as floating point values in geophysics space. > > - video cards (through Java2D) which work best with > > integer values in RGB space. > > How would you classify data like GTOPO30 and GTOPO60 which are > elevation data, 16 bits unsigned where the No Data values is -9999? > Or DTED (Military Elevation Data) which are as well 16 bits unsigned, > or SRTM () which are signed integers elevations that can range from > -32767 to 32767 meters, encompassing the range of > elevation to be found on the Earth. Nodata are flagged with the value -32768. > This data cannot be visualized directly, but they would not even be > strictly "geophysics", moreover there is no specific colormap to apply > and also there is a Nodata value which is an integer and not NaN. > > > > > This is controversial for good reasons, but I try very very hard to > > preserve the > > geophysics meaning of images, otherwise the whole coverage module would > > become > > pointless to me (even if RGB images have a lot of values for other users, > > I'm > > not myself in those fields. This explain why RGB support was poor in the > > first > > place). > > > I think that nobody ever suggested id to remove the concept of > geophysics but rather to not base the whole coverage module on that > concept. > > > > > > > > b) I noticed trunk depending on GeoAPI 2.2-SNAPSHOT; is this correct or > > > is there a GeoAPI 2.3-SNAPSHOT we should be using > > > > Yes it is correct. There is no GeoAPI 2.3 as far as I known? > > > > The pending API change in GeoAPI coverage are about replacing the old OGC > > 01-004 > > specification by ISO 19123. This is yet an other topic. The geophysics / > > photographic / packed views issues is unrelated to either OGC 01-004 and > > ISO 19123. > > > > > > > Martin I think you are stressed out on a deadline are you not? Can I > > > help set up the proposal page for you ... it will at least let me catch > > > up on all this email. > > > > We just created the following page: > > > > http://docs.codehaus.org/display/GEOTOOLS/Improve+support+of+RGB+coverages > > > > but this is just a skeleton for now (we are just starting the work on wiki > > side > > - I admit that this is a very late stage). > > Better later than never :-). Anyway it would be great if you could > start to write something about what your proposal would be, I think > that wass the original purpose if this > http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal. > > Ciao, > Simone. > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Geotools-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > > > -- > ------------------------------------------------------- > Eng. Simone Giannecchini > President /CEO GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > > ------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
