Hi Jody,
Upon a little further investigation I don't think I need to do anything
with the casting functions. I think all that needs to be done is to add
a check so that no casting is done if both objects are Numbers.
So for my case if I add
if (v1 instanceof Number && v2 instanceof Number)
return new Object[] { v1, v2 };
to the eval function of the BinaryComparisonAbstract function then
instead of converting between doubles and integers it just compares the
two numbers and the issues I have are resolved.
I think this should be okay for other cases Number cases as well. I
looked at the CompareFilterImpl and it doesn't differentiate between
Integers and Doubles it treats all Numbers the same (converts them to
doubles and then runs the comparison).
But I guess this won't work well for String/Number cases.
What do you think? Can we add something like this or is it going to
cause other problems I haven't forseen?
Emily
Jody Garnett wrote:
> Hi Emily:
>
> The filter thing is not strongly typed (it does not really know they
> are integers).
>
> It should however be able to check that your DAMAGE attribute is of
> type interger and then it will compare try and convert the other
> strings into an interger to match.
>
> The same thing happens in reverse if your DAMAGE attribute was a String.
>
> To force the issue there are a couple of "casting" functions you could
> wrap around to force the value to be an int or a double or whatever.
>
> For a while the handling of literal was very slow and tried to parse
> every string as a double; then an interger before giving up and
> returning a string. Slow and painful.
>
> Can we think of another way? Perhaps detect any number as a request
> for numeric comparison and perform all checks using BigDecimal?
>
> Jody
>
> On Wed, Jun 10, 2009 at 9:44 AM, Emily Gouge<ego...@refractions.net> wrote:
>> I have shapefile with 5 features with an integer attribute - DAMAMGE).
>> Each of these features as a unique DAMAGE value between 1 and 5. In
>> uDig I'm creating a color-theming style that creates 5 rules that are
>> similar to the SLD below. These rules basically evaluate the statement
>> "1 <= DAMAGE < 1.8";
>>
>> When I view the results in uDig, the colors are incorrect as the
>> features are being put in the wrong categories. From my debugging it
>> looks like that when the filter is evaluating, the "1.8" is being
>> converted to the Integer "1" thus evaluating the expression "1 <= DAMAGE
>> < 1" which is always going to return false.
>>
>> This conversion from 1.8 to 1 is being done in the eval function of the
>> BinaryComparisonAbstract class. Here it converts the "1.8" double to an
>> integer.
>>
>> I'm wondering how/if this can be fixed? (or maybe it's designed to work
>> this way?)
>>
>> I was thinking of trying to add some logic to this function to be
>> smarter about the conversion done & try to not loose precision if
>> possible (for example convert from integer to double before we convert
>> from double to integer). I'm not sure if this is the best way to go
>> about this?
>>
>> Thanks,
>> Emily
>>
>>
>> <sld:Rule>
>> <sld:Name>rule01</sld:Name>
>> <sld:Title>1..1.8</sld:Title>
>> <ogc:Filter>
>> <ogc:And>
>> <ogc:PropertyIsGreaterThanOrEqualTo>
>> <ogc:PropertyName>Damage</ogc:PropertyName>
>> <ogc:Literal>1</ogc:Literal>
>> </ogc:PropertyIsGreaterThanOrEqualTo>
>> <ogc:PropertyIsLessThan>
>> <ogc:PropertyName>Damage</ogc:PropertyName>
>> <ogc:Literal>1.8</ogc:Literal>
>> </ogc:PropertyIsLessThan>
>> </ogc:And>
>> </ogc:Filter>
>> <sld:MaxScaleDenominator>1.7976931348623157E308</sld:MaxScaleDenominator>
>> <sld:PolygonSymbolizer>
>> <sld:Fill>
>> <sld:CssParameter name="fill">
>> <ogc:Literal>#EFF3FF</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="fill-opacity">
>> <ogc:Literal>0.5</ogc:Literal>
>> </sld:CssParameter>
>> </sld:Fill>
>> <sld:Stroke>
>> <sld:CssParameter name="stroke">
>> <ogc:Literal>#000000</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="stroke-linecap">
>> <ogc:Literal>butt</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="stroke-linejoin">
>> <ogc:Literal>miter</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="stroke-opacity">
>> <ogc:Literal>1</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="stroke-width">
>> <ogc:Literal>1</ogc:Literal>
>> </sld:CssParameter>
>> <sld:CssParameter name="stroke-dashoffset">
>> <ogc:Literal>0</ogc:Literal>
>> </sld:CssParameter>
>> </sld:Stroke>
>> </sld:PolygonSymbolizer>
>> <sld:Rule>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
