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. > -- ----------------------------------------------------------- Michael Schulz Christoph-Mang-Str. 5 D-79100 Freiburg _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
