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
[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> :)
[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
[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
