Hi Michael,

Funnily enough I've just encountered the same problem recently in some of our code. As you say, it's a floating numbers problem and I'm not sure it can be avoided as such.

To work around it we've just modified our code (not OWSlib) to allow a bit of tolerance in requests (+- 1/1000000 or something like that).

e.g.  when testing if a value is inside a bbox:

if value >= minValue - tolerance:
            if value <= maxValue + tolerance:
                #then you're in

If you don't have control over the server then maybe you have to add similar tolerance to the WCS request?

Regards,
Dom

On 04/07/11 17:06, [email protected] wrote:
Hi Dominic,

uh, turned out that I wrote to Tom about this already, but not to the
list... sorry...
I'll test this patch, but it looks good to me.

I think I have to lookup the way repr() actually works ... because it
can still break things:
I had the problem that depending on the value you're giving to repr()
it will return different things (basically the binary float repr
problem), but if the value your looking at is exactly the maximum
extent of a WCS and repr() returns sth rounded to 16 decimal digits,
then this could be bigger than the allowed extent, which could result
in an error of the requested WCS (I'm not making this up, this was a
real issue we had):

This is the lower left Y value: 35.41667175292969

repr(35.41667175292969)
'35.416671752929688'

As you can see the returned value is even lower (and has 1 decimal
digit more), which resulted in an error.

Cheers, Michael






2011/7/4 Dominic Lowe<[email protected]>:
Michael,

It turns out that using repr() caused some problems with string conversions
in other contexts.
I've added in a new fix in: http://trac.gispython.org/lab/changeset/1733
which uses repr only if the value to be converted is not already a string.

If you get a chance to confirm this still works for you that would be good.

Cheers,
Dom

On 29/04/11 14:01, [email protected] wrote:
Hi,

while testing some WCS services and requests from OWSLib, I found (at
least on my machine) that in wcs110.py when iterating over the bbox
tuple and creating a string, the use of str() leads to a truncation of
the bbox values after ten decimal places. using repr() at line 148
instead solves the issue.

Cheers, Michael


--
Scanned by iCritical.




--
Scanned by iCritical.
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

Reply via email to