Jody,
I hear you; I don't want to implement a solution that doesn't really
solve the problem either.
So here is my test case. This test case fails.
public void testMyTest() {
FilterFactory2 ff = CommonFactoryFinder.getFilterFactory2(null);
Filter f = ff.less(ff.literal(1), ff.literal(1.5)); //1 < 1.5
assertEquals(true, f.evaluate(null)); //this fails
}
> "If you parse in a filer "1 < 2" both literals will show up as "1"
and "2""
This doesn't seem to be the case in this test case. In the eval
function of BinaryComparisonAbstract class it seems that the literals
"1" and "1.5" in my case is actually showing up as Integer and Double
respectively; that is why my instanceOf Number check works out. It
would not work out if there were actually strings.
Emily
Jody Garnett wrote:
> Hi Emily:
>
> Hi Emily - I do not mind putting a patch in here (you have found a
> problem) but I am not sure the solution is going to work in all cases?
>
> The thing is we had code like this and we *removed* it all; in favour
> of asking the expressions to evaulate into a indicated class....
>
> So the general problem here is - does that the code has no way of
> telling if the values are numbers in each and every case. If you parse
> in a filer "1 < 2" both literals will show up as "1" and "2"
> internally. So I would like to know what your test case is that your
> instanceof Number checks actually effect things? What parser you are
> using and so on ...
>
> Can we do any kind of quick test of the string (to see if it patches a
> pattern for interger; or double or something - rather than an instance
> of check?
>
> I am thinking of a helper method like:
>
> /** @return null if we cannot make this a number */
> public Number asNumber( Object obj ){
> if( obj instanceof Number) return (Number) obj;
> if( obj instanceof String){
> String str = (String) obj;
> if( str.matches("pattern")){
> return Interger.parseInt( str );
> }
> etc...
> }
> return null;
> }
>
>
> For me to accept a patch I would like to have the following work:
> - ff.greaterThan( ff.property("amount"), ff.literal("1") );
> - ff.greaterThan( ff.property("amount"), ff.literal(1) );
> - ff.greaterThan( ff.property("amount"), ff.literal(1,0) );
>
> Jody
>
>
> On Thu, Jun 11, 2009 at 9:09 AM, Emily Gouge<ego...@refractions.net> wrote:
>> 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
