Alessio Fabiani ha scritto:
> Hi Andrea,
> see responses below...
>
> On Thu, May 22, 2008 at 12:22 PM, Andrea Aime <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi,
> in the project we're following we need to make a couple of variants
> to the sldService, so I guess I'll need to discuss them a bit to make
> sure we don't break FAO users of that module.
>
> The first thing I need, is to change the generated rules so that they
> all use closed intervals, such as:
> 0 <= x <= 10
> 10 < x <= 20
> 20 < x <= 30
> as opposed of today's result:
> x <= 10
> 10 < x <= 20
> x > 20
>
> In order to do that without breaking current users, I was thinking
> of adding a new parameter, closedIntervals=true/false to the POST
> call that generates the intervals.
>
>
> Even using directly closing intervals won't break FAO implementation, so
> use the solution you prefer ... however using the closingIntervals
> parameter would give higher control on the rules generation, so in my
> opinion we should go for it.
Ok, I'll add the parameter.
>
> The second issue is dealing with odd but not uncommon data histograms
> like, for example {0 0 0 0 2 4 6 8}. If you ask the current quantile
> classifier to classify that with 4 intervals, you'll get {0 0}, {0 0},
> {2 4} {6 8}, which would result in very confusing rules (see attached
> screenshot for an example).
>
> One idea I had is to make the quantile function detect the flat areas
> and make it create separate classes for them, and then classify the
> rest using the standard sized classes. The above example would then
> become: {0 0 0 0} {2 4} {6 8}.
> Another example: {0 1 2 3 3 3 4 5}, 2 classes -> {0 1 2} {3 3 3} {4 5},
> that is, first isolate the flat area, then try to build classes of 4
> elements with the rest of the data, accepting the fact that more classes
> than requested may be generated.
>
> Another possible approach, which is easier because we can handle it
> in post processing, that is, when building the rules, would be to
> simply kill subsequent classes that do have the same min and max.
> With the
> above examples, the rules would become:
> {0 0 0 0 2 4 6 8}
> x = 0 (killing the second x = 0 interval)
> 0 < x <= 4
> 4 < x <= 8
> or if you prefer, {0 0 0 0} {2 4} {6 8}
> and:
> {0 1 2 3 3 3 4 5}
> 0 <= x <= 3
> 3 < x <= 5
> that is {0 1 2 3 3 3} {4 5}
>
> If the latter is good for FAO as well, I can just modify the way
> we build the rules and avoid touching the underlying quantile
> classification function. Opinions?
>
>
> I would prefer that simply the quantile generates the right rules, I
> don't think that post-processing would be a good approach. I would
> prefer to modify the client behaviour accepting the fact that quantile
> can generate a different number of classes than requested.
It's not that simple for two reasons:
* the way the current quantile function works is mathematically sound,
it's the data in the samples above that should not be fed into it.
That is, {0 0} {0 0} {2 4} {6 8} is the right answer from a
mathematical standpoint, 4 classes each of which has the same number
of elements in it, and thus the same probability of representing
a feature in the map.
* uDig is already using it as is, I cannot just go and change the
functionality of it under its feet.
I tried to discuss this on the gt2-devel mailing list, but did not have
very good success. That's why post processing seems the easiest and most
effective way of dealing with it.
Cheers
Andrea
-------------------------------------------------------------------------
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/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
