A couple comments inline ... > It was an improvised chat about future development needed for Grid > Coverage. > > Martin > ------------------------------------------------------------------------ > > [2006-11-28 10:55:21] <simboss> ok > [2006-11-28 10:55:22] <simboss> tomorrow > [2006-11-28 10:55:26] <simboss> I might have some time > [2006-11-28 10:55:33] <simboss> so that I can try to put together > [2006-11-28 10:55:51] <simboss> some toughts about where we could improve the > 2.3.x gridcoverage package > [2006-11-28 10:55:57] <simboss> after the realease of course > [2006-11-28 10:56:19] <simboss> so that we can talk about who does what when > [2006-11-28 10:56:21] <simboss> :-) > [2006-11-28 10:56:41] <desruisseaux> Would it be possible to do the work on > 2.4 (trunk) rather than 2.3 branch? > [2006-11-28 10:56:47] <simboss> nope > [2006-11-28 10:56:53] <simboss> because I need it for geoserver > [2006-11-28 10:57:04] <simboss> 1.5.x > [2006-11-28 10:57:12] <simboss> but we can port it over > [2006-11-28 10:58:03] <desruisseaux> Yes we can port, but I though that we > are not supposed to change the API of a branch. We can do that, but we are > using 2.3 branch as if it was the trunk. > [2006-11-28 10:58:27] <simboss> because some is unsing trunk as if it was a > branch > [2006-11-28 10:58:40] <simboss> and to do that > [2006-11-28 10:58:48] <simboss> forced to do go to a new release > [2006-11-28 10:59:16] <simboss> geoserver is now on 2.2.2 > [2006-11-28 10:59:27] <desruisseaux> I do not really realize; which parts of > trunk are so unstable? > [2006-11-28 10:59:49] <simboss> are working on features > Most of this work is in the unstable directories - I admit I broke trunk by accident yesterday (I really needed more feedback in yesterdays meeting - but it is showing up in email today so I think things will be okay). Is their anyway we can set the unstable modules to *not* be fatal to the build process (other then take them out of the pom.xml reference - which is what we do now).
I am interested in making sure we can all work; on trunk. I do hope the geotools 2.3 branch stays locked down - as that is central to our plan to switch uDig development over to it. > [2006-11-28 10:59:52] <simboss> and anyway > [2006-11-28 11:00:40] <simboss> geoserver > [2006-11-28 11:00:46] <simboss> will stay on 2.3.x for a while > [2006-11-28 11:05:20] <simboss> there are two things > [2006-11-28 11:05:28] <simboss> that I really need to work on soon > [2006-11-28 11:05:40] <simboss> 1>support for images with indexcolormodel > [2006-11-28 11:06:29] <simboss> 2>rastersymblization > [2006-11-28 11:06:34] <simboss> 3>Coverage dispose > [2006-11-28 11:06:47] <simboss> 2 was hackedd quickly by alessio a long time > [2006-11-28 11:06:48] <simboss> ago > [2006-11-28 11:07:03] <desruisseaux> ??? IndexColorModel should be already > supported in the coverage module; actually it really the color model the > whole coverage module is designed for. > [2006-11-28 11:07:27] <simboss> some operations I added does no0t really > support it (my fault) > [2006-11-28 11:07:29] <simboss> but also > [2006-11-28 11:07:32] <simboss> resample > [2006-11-28 11:07:45] <simboss> has some problems with them > [2006-11-28 11:07:49] <simboss> you usually put > [2006-11-28 11:07:58] <simboss> REPLACE INDEXCOLOR MODEL > [2006-11-28 11:07:59] <simboss> hint to false > [2006-11-28 11:08:03] <simboss> but this case > [2006-11-28 11:08:07] <simboss> warp and other operations > [2006-11-28 11:08:08] <simboss> to fail > [2006-11-28 11:08:14] <simboss> on indexcolormodel image > [2006-11-28 11:08:18] <simboss> with interpolation > [2006-11-28 11:08:25] <simboss> that is not nearest neighbor > [2006-11-28 11:08:35] <simboss> in such case > [2006-11-28 11:08:41] <simboss> you have to previously expand images to rgb > [2006-11-28 11:08:44] <simboss> or rgba > [2006-11-28 11:08:48] <simboss> no rocket science > [2006-11-28 11:08:50] <simboss> :-) > [2006-11-28 11:09:17] <desruisseaux> For the way grid coverage is used in > science, we are really not allowed to expand to RGB. > [2006-11-28 11:09:26] <simboss> yeah but martin > [2006-11-28 11:09:30] <simboss> you need to understand > [2006-11-28 11:09:38] <simboss> tat geotools is used inmany field > [2006-11-28 11:09:41] <simboss> and actually science > [2006-11-28 11:09:51] <simboss> is the smallest right now :-) > [2006-11-28 11:10:11] <simboss> we need to make things configurable at least > [2006-11-28 11:10:22] <simboss> if you have ortophoto > [2006-11-28 11:10:26] <simboss> tha are tiffs > [2006-11-28 11:10:31] <simboss> with indexcolormodel > [2006-11-28 11:10:40] <simboss> when you warp to repeoject > [2006-11-28 11:10:42] <simboss> in a WMS > [2006-11-28 11:10:46] <simboss> you want to use > [2006-11-28 11:10:49] <simboss> bilinear at least > [2006-11-28 11:10:59] <simboss> to have a nice image back > [2006-11-28 11:11:02] <simboss> hence > [2006-11-28 11:11:12] <simboss> you need to change to rgb > [2006-11-28 11:11:14] <simboss> or > [2006-11-28 11:11:19] <simboss> you will make a mess > [2006-11-28 11:11:22] <simboss> because > [2006-11-28 11:11:27] <simboss> as you know > [2006-11-28 11:11:32] <simboss> underlying raster > [2006-11-28 11:11:38] <simboss> holds index in a palette > [2006-11-28 11:11:42] <simboss> not really > [2006-11-28 11:11:44] <simboss> real data > [2006-11-28 11:11:50] <simboss> that is most important reason > [2006-11-28 11:12:00] <simboss> do you agree? > [2006-11-28 11:12:13] <desruisseaux> I understand the ortophoto case. > [2006-11-28 11:12:26] <simboss> I think the trink is > [2006-11-28 11:12:32] <simboss> knowng what you want > [2006-11-28 11:12:41] <simboss> tell what you want > [2006-11-28 11:12:42] <simboss> :-) > [2006-11-28 11:12:45] <simboss> so > [2006-11-28 11:12:54] <simboss> if you want I can expand > [2006-11-28 11:12:56] <simboss> otherwise > [2006-11-28 11:12:59] <simboss> I won't do it > [2006-11-28 11:13:42] <simboss> it is the same thing with the no data we > discussed lately > [2006-11-28 11:13:48] <simboss> I checked what gdal and other libs do > [2006-11-28 11:13:57] <simboss> and they do not hange the nodata to NAN > [2006-11-28 11:14:03] <simboss> are we sure we should do it? > [2006-11-28 11:14:15] <desruisseaux> For numerical work, yes absolutly. > [2006-11-28 11:14:21] <simboss> yes > [2006-11-28 11:14:23] <desruisseaux> For non-numerical work, it may be an > other story. > [2006-11-28 11:14:31] <simboss> and that was the anwer I am expecting from you > [2006-11-28 11:14:33] <simboss> :) > Can I assume that the nodata and NaN both show up as transparent when rendered - or is that a raster symbolizer thing? > [2006-11-28 11:14:35] <desruisseaux> But we are opening a box for a lot of > bug. > [2006-11-28 11:14:45] <simboss> I understand your point of view > [2006-11-28 11:14:57] <simboss> because I work with both worlds > [2006-11-28 11:15:05] <simboss> but many people I can assure > [2006-11-28 11:15:09] <simboss> do not understand > [2006-11-28 11:15:21] <simboss> why so? > [2006-11-28 11:16:11] <desruisseaux> Most classes in the coverage module will > give wrong answer if no-data value are not mapped to NaN. > [2006-11-28 11:16:22] <desruisseaux> For example Interpolator2D. > [2006-11-28 11:16:37] <simboss> do you think it will be impossible for next > releases to tweak them > [2006-11-28 11:16:42] <simboss> to work in a more general way? > [2006-11-28 11:16:47] <desruisseaux> If you ask for a value in the neighboard > of a no-data value, it will try to interpolate the -9999 value with the real > value around. > [2006-11-28 11:17:14] <desruisseaux> It is possible to tweak them, but I > believe that it would be a bad idea. > [2006-11-28 11:17:28] <simboss> I agree man > [2006-11-28 11:17:37] <simboss> but if we want people to use geotools > Simone when I had to do this kind of analysis with JAI I set up as "mask" for my "nodata" (ie 0.0 or 1.0); combined the mask with the original so the image looked like NaN was used everywhere nodata was recorded; did my interpoloation; and then did the mask again to fold the "nodata" value back into the final answer. This ends up being a graph of operators you can apply again and again - but it was not fun. > [2006-11-28 11:17:45] <desruisseaux> It would duplicate the processor work. > Our experience show that it slow down a lot the processing. And we can be > 100% sure that we will forget to tweak many area. > [2006-11-28 11:17:46] <simboss> we need to bend ourself a bit towards them > [2006-11-28 11:18:09] <simboss> this thing is especially important > [2006-11-28 11:18:12] <simboss> with transconding > [2006-11-28 11:18:21] <simboss> from a format to another > [2006-11-28 11:18:31] <simboss> anf when doing automatic recognition > [2006-11-28 11:18:32] <simboss> of formats > [2006-11-28 11:18:51] <simboss> depending on metadata > [2006-11-28 11:19:36] <simboss> being afraid of bugs is not a good reason to > improve things martin :-) > [2006-11-28 11:19:46] <simboss> as long as I can > [2006-11-28 11:19:56] <simboss> I can apply your approach > [2006-11-28 11:19:58] <simboss> for example > [2006-11-28 11:20:02] <simboss> on ascii grids > [2006-11-28 11:20:04] <simboss> I convert > [2006-11-28 11:20:07] <simboss> -999.0 > [2006-11-28 11:20:08] <simboss> to NaN > [2006-11-28 11:20:12] <simboss> on the fly when I read > [2006-11-28 11:20:18] <simboss> because I read float values > [2006-11-28 11:20:23] <simboss> and I am fine with that > [2006-11-28 11:20:39] <simboss> maybe you noticed when you were looking for > the internationalization bug > [2006-11-28 11:20:48] <simboss> but for exmample with GTOPO30 > [2006-11-28 11:21:00] <simboss> this can be problematic > [2006-11-28 11:21:09] <simboss> I need to reformat the data on the fly > [2006-11-28 11:21:17] <simboss> and then subsitute > [2006-11-28 11:21:24] <simboss> -9999 with NaN > [2006-11-28 11:21:35] <simboss> since the original data in in short > [2006-11-28 11:22:39] <desruisseaux> I remember the GTOPO30 case. > [2006-11-28 11:22:52] <desruisseaux> The problem is as below: > [2006-11-28 11:23:07] <desruisseaux> Coverage maintain 2 views of data: > geophysics and non-geophysics ones. > [2006-11-28 11:25:28] <desruisseaux> I really strongly believe that the > geophysics view should continue to map no-data to NaN, otherwise we will put > a huge burden in every area of the code dealing with data, as well as every > users performing numerical work. This is a huge risk, and in this case we are > really sure to introduce a lot of potentially dangerous bug in every > numerical computing code using Geotools. I agree that being afraid of > introducing bugs should not prevent us from improving geotools, but in this > case it sound to me like reintroducing C/C++ pointer in Java: a dangerous > move for an improvement that may not be worth the risk. > [2006-11-28 11:25:53] <desruisseaux> However, non-geophysics view do maps > no-data value to some value like -9999. > [2006-11-28 11:26:12] <desruisseaux> The problem is that current coverage > module merge "non-geophysics" and "displayable" views. > [2006-11-28 11:26:27] <desruisseaux> I means, Geotools use the > "non-geophysics" view as the view to use for displaying. > [2006-11-28 11:26:57] <desruisseaux> This means that we are constrained by > the capabilities of the Java2D library (itself constrained by the > capabilities of most video hardward) > [2006-11-28 11:27:11] <desruisseaux> In the particular case of GTOPO30, the > problem is that this format contains negative value. > [2006-11-28 11:27:22] <desruisseaux> And IndexColorModel can not handle > negative value. > [2006-11-28 11:27:43] <desruisseaux> So the GTOPO30 format do not directly > maps to "geophysics" view because "nodata" values are not NAN > [2006-11-28 11:28:00] <desruisseaux> And it does not directly maps to > "non-geophysics" view neither because it is not displayable. > [2006-11-28 11:28:27] <desruisseaux> A solution that I would like much more > than allowing -9999 values in "geophysics view" would be to introduces a > third view. > [2006-11-28 11:28:41] <desruisseaux> Instead of "geophysics" and > "non-geophysics" view, we could have: > > [2006-11-28 11:28:46] <desruisseaux> "geophysics", "native", "displayable" > [2006-11-28 11:29:01] <desruisseaux> Where "native" is the format as found in > the file format > [2006-11-28 11:29:12] <desruisseaux> and "displayable" is what > "non-geophysics" currently stand for. > [2006-11-28 11:29:16] <desruisseaux> What do you think? > [2006-11-28 11:32:16] <simboss> the point of this is > [2006-11-28 11:32:17] <simboss> and I was going sooner or later > [2006-11-28 11:32:19] <simboss> to talk to you about this > [2006-11-28 11:32:21] <simboss> that something > [2006-11-28 11:32:22] <simboss> which is really bad in the > [2006-11-28 11:32:24] <simboss> gridcoveage implementation specification > [2006-11-28 11:32:26] <simboss> which has been left apart in 19123 > [2006-11-28 11:32:27] <simboss> is this fact > [2006-11-28 11:32:29] <simboss> os having to specofy > [2006-11-28 11:32:32] <simboss> the two views > [2006-11-28 11:32:33] <simboss> when you create the coverage > [2006-11-28 11:32:34] <simboss> most part of time > [2006-11-28 11:32:36] <simboss> you do not really know > [2006-11-28 11:32:37] <simboss> hoe to render a coverage > [2006-11-28 11:32:39] <simboss> and most part of the time > [2006-11-28 11:32:40] <simboss> you just do not want > [2006-11-28 11:32:42] <simboss> ! > [2006-11-28 11:32:44] <simboss> I think sooner or later > [2006-11-28 11:32:46] <simboss> we should try > [2006-11-28 11:32:48] <simboss> to separate the concept > [2006-11-28 11:32:50] <simboss> or rendering a coverage > [2006-11-28 11:32:52] <simboss> from the process of processing a coverage > [2006-11-28 11:32:54] <simboss> ops > [2006-11-28 11:32:56] <simboss> sorry > [2006-11-28 11:32:58] <simboss> I wanted to say > [2006-11-28 11:33:00] <simboss> the opposite > [2006-11-28 11:33:02] <simboss> :-) > [2006-11-28 11:33:04] <simboss> now there is a net separation > [2006-11-28 11:33:06] <simboss> but it is artificious > [2006-11-28 11:33:08] <simboss> and sometime > [2006-11-28 11:33:10] <simboss> just problematic > [2006-11-28 11:33:12] <simboss> most part of the time I have to use *default* > colors > [2006-11-28 11:33:14] <simboss> for coverage > [2006-11-28 11:33:16] <simboss> that are in float > [2006-11-28 11:33:18] <simboss> or double > [2006-11-28 11:33:20] <simboss> even if I do not want to see any coloro > [2006-11-28 11:33:22] <simboss> I think that if ISO 19132 > [2006-11-28 11:33:24] <simboss> 19123 > [2006-11-28 11:33:26] <simboss> removed this concept > [2006-11-28 11:33:28] <simboss> I am not the only one > [2006-11-28 11:33:30] <simboss> thinking this > [2006-11-28 11:33:32] <simboss> :-) > [2006-11-28 11:34:04] <simboss> I think that > [2006-11-28 11:34:20] <simboss> we should slowly > [2006-11-28 11:34:22] <simboss> move beyond > [2006-11-28 11:34:34] <simboss> the old GridCoverage IS > [2006-11-28 11:34:36] <simboss> because > [2006-11-28 11:34:46] <simboss> it is more a showstopper than a benefit as of > now > [2006-11-28 11:34:54] <simboss> GCE part of fit > [2006-11-28 11:34:56] <simboss> sucks > [2006-11-28 11:35:07] <simboss> management of time and third > [2006-11-28 11:35:11] <simboss> sucks as well > [2006-11-28 11:35:25] <simboss> as you well know because you had to come up > with your own hierarchy > [2006-11-28 11:35:29] <simboss> (quite cool btw) > [2006-11-28 11:35:35] <simboss> this tihng > [2006-11-28 11:35:46] <desruisseaux> The "geophysics" vs "non-geophysics" > view things are not part of the old Grid Coverage implementation > specification. They are my own additions to Geotools. > [2006-11-28 11:36:16] <simboss> that's cool man > [2006-11-28 11:36:29] <simboss> but I am tring to show you a more general > picture > [2006-11-28 11:36:42] <simboss> I am not trying to criticize > [2006-11-28 11:36:48] <simboss> I am trying to say > [2006-11-28 11:36:52] <simboss> what we have is cool > [2006-11-28 11:36:53] <desruisseaux> I'm not upset at all > [2006-11-28 11:36:53] <simboss> but > [2006-11-28 11:36:59] <simboss> how can we make it super cool > [2006-11-28 11:37:52] <simboss> we are really good at dong some things > [2006-11-28 11:38:01] <simboss> but it is almost impossible to do many other > [2006-11-28 11:38:09] <simboss> which most people need > [2006-11-28 11:38:24] <simboss> working with geoserver I see that all the time > [2006-11-28 11:38:56] <simboss> in the past we were missing plugins with > decent performance > [2006-11-28 11:39:13] <desruisseaux> In the particular case of having to > specify the "geophysics" vs "non-geophysics" relationship at construction > time, I agree that we need to make that easier for peoples who don't know > this relationship. However there is also case where we know this > relationship, and we want to keep it constant for a whole range of images > from a time series (this is the case for my data). So we probably need both > way. > [2006-11-28 11:39:33] <simboss> sure > [2006-11-28 11:39:48] <simboss> the only real criticism > [2006-11-28 11:40:43] <desruisseaux> I believe that a first step is to split > the "non-geophysics" view into two views "native" and "displayable". > [2006-11-28 11:40:51] <desruisseaux> I can take care of this step. > [2006-11-28 11:40:52] <simboss> that I might move to the gridcoverage package > [2006-11-28 11:41:02] <simboss> is that > [2006-11-28 11:41:13] <simboss> it has been cut too for a specific purpose > [2006-11-28 11:41:19] <simboss> which is numerical computation > [2006-11-28 11:41:26] <simboss> we need to make it a bit more general > [2006-11-28 11:41:35] <simboss> and also to write some documentation on how > to use it :-) > [2006-11-28 11:41:40] <simboss> if we do this > [2006-11-28 11:41:45] <simboss> people will use it > [2006-11-28 11:41:47] <simboss> otherwise > [2006-11-28 11:41:52] <simboss> the situation > [2006-11-28 11:41:54] <simboss> won't improve > [2006-11-28 11:42:50] <simboss> this is why I am bothering > [2006-11-28 11:43:33] <desruisseaux> I agree that the grid coverage package > was strongly designed with numerical computation in mind; it was the whole > reason why I wrote it. I also agree that we should make it more general, but > I would like to preserve its numerical computation capability (i.e. I would > like to have the two worlds in same time...) > [2006-11-28 11:43:49] <simboss> that is more tha fine man > [2006-11-28 11:43:59] <simboss> I need it for numerical computation primarly > as well > [2006-11-28 11:44:09] <simboss> but I am pretty sure > [2006-11-28 11:44:16] <simboss> we can make it super great > [2006-11-28 11:44:20] <simboss> even in general > [2006-11-28 11:44:40] <simboss> do you mind if tomorrow I write a couple of > pages > [2006-11-28 11:44:47] <simboss> wit my thoughts > [2006-11-28 11:44:52] <simboss> so that you can read and comment? > [2006-11-28 11:45:25] <desruisseaux> Sure :) > [2006-11-28 11:45:47] <simboss> do you a mean to acquire the logs > [2006-11-28 11:45:51] <simboss> I am using netscape > [2006-11-28 11:45:53] <desruisseaux> No problem. > [2006-11-28 11:49:48] <desruisseaux> Just in summary: my main comment is that > instead of allowing "no-data" value that are not NaN in the "geophysics" > view, I would rather prefer to define an other view. > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
