Mmm, I see ... is there no chance to have some feedbaks from uDig guys? It
could be a suitable solution to introduce a parameter here too in your
opinion?
On Thu, May 22, 2008 at 3:05 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> 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
>
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
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/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
