[Community] OWSLib WCS bbox problem

[Dominic Lowe]

Hi Michael,

Thanks for the observation - sorry for the slow reply. I've just
committed your change to WCS, WFS and WMS as they all have the same issue.
I don't have a suitable server (with high precision bbox) to test it on
so if you do get a chance to try it out that would be great.

Regards

Dom

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

[Dominic Lowe]

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

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

[Michael Schulz]

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

Post by Dominic Lowe

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

Post by Dominic Lowe
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

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.

[Dominic Lowe]

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

Post by Michael Schulz
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
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
This is the lower left Y value: 35.41667175292969

Post by Dominic Lowe

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

Post by Dominic Lowe
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

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.

[Dominic Lowe]

See also: http://trac.gispython.org/lab/changeset/1734

I made a mistake in the first check in (thanks Tom!)

Post by Dominic Lowe
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

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