Float rounding error in GEOS factory about rgeo HOT 6 CLOSED

Hm, github markdown got me.. let me try again:

ruby-1.8.7-p160 :002 > f = RGeo::Cartesian.simple_factory
 => #<RGeo::Cartesian::Factory:0x7f47b7a70890 @srid=0, @proj4=nil, @has_m=false, @coord_sys=nil, @has_z=false> 
ruby-1.8.7-p160 :003 >  f.point(111.99, -40.37)
 => #<RGeo::Cartesian::PointImpl:0x3fa3dbd31724 "Point(111.99 -40.37)"> 
ruby-1.8.7-p160 :004 > f = RGeo::Cartesian.preferred_factory
 => #<RGeo::Geos::Factory:0x3fa3dbcf7cb8 srid=0 bufres=1 flags=0> 
ruby-1.8.7-p160 :005 >  f.point(111.99, -40.37)
 => #<RGeo::Geos::PointImpl:0x3fa3dbcf1520 "POINT (111.9899999999999949 -40.3699999999999974)"> 

from rgeo.

Man I'm on a roll, mistakenly hit comment & close.. reopened. i need caffeine.

from rgeo.

Yeah, I've seen this too. I haven't paid much attention to it so far, but if it's causing you issues, then I'll see what I can do.

Your example above illustrates that the pure Ruby WKT generator (which is the one used by the simple Cartesian factory) seems to do better than the native GEOS WKT generator (which is used by the GEOS factory). If the behavior of the pure Ruby WKT generator is sufficient for your needs, you may be able to work around the issue for now by using it manually. Create a RGeo::WKRep::WKTGenerator, and it will work even on a GEOS geometry object.

# The GEOS-based factory
f = RGeo::Cartesian.preferred_factory
p = f.point(111.99, -40.37)
# ...uses the native GEOS WKT generator by default
p.as_text  # => "POINT (111.9899999999999949 -40.3699999999999974)"
# ...but you can manually use the pure Ruby WKT generator
gen = RGeo::WKRep::WKTGenerator.new
gen.generate(p)  # => "Point(111.99 -40.37)"

# The pure Ruby factory
f = RGeo::Cartesian.simple_factory
p = f.point(111.99, -40.37)
# ...uses the pure Ruby WKT generator by default
p.as_text  # => "Point(111.99 -40.37)"

In fact, maybe one possible "solution" could be to provide an option on the GEOS factory to use the pure ruby WKT generator by default instead of the native GEOS implementation. I'll look into this possibility.

I've also noticed that, in a few uncommon cases (which I don't understand too well), Ruby 1.9.2 seems to do slightly better with floating point roundoff than 1.8.7. (In fact, the test suite currently gives two failures on 1.8.7 because of floating point roundoff issues that do not appear in 1.9.2.) It doesn't help on your example above, but it may on others.

from rgeo.

You are on the ball, thanks for the reply. As it turns out and as you've pointed out, it seems the issue is only WKT output using GEOS (and perhaps WKB output using GEOS, haven't tested that). I hadn't actually checked the values of x and y themselves on the point object. Parsing GEOS objects using wkb, the actual values seem to be fine, which was our initial concern.

The problem does seem to be upstream in the GEOS libraries themselves as you indicated.

ruby-1.8.7-p160 :012 > p
 => #<GeoRuby::SimpleFeatures::Point:0x7fd2e36adde0 @x=111.99, @srid=-1, @m=0.0, @with_m=false, @z=0.0, @with_z=false, @y=-40.37> 
ruby-1.8.7-p160 :006 > f = RGeo::Cartesian.preferred_factory
 => #<RGeo::Geos::Factory:0x3fe971af75f4 srid=0 bufres=1 flags=0> 

--wkb parsed in--
ruby-1.8.7-p160 :007 > f.parse_wkb(p.as_wkb).x
 => 111.99 
ruby-1.8.7-p160 :008 > f.parse_wkb(p.as_wkb).y
 => -40.37 
ruby-1.8.7-p160 :009 > f.parse_wkb(p.as_wkb)
 => #<RGeo::Geos::PointImpl:0x3fe971d9c0e8 "POINT (111.9899999999999949 -40.3699999999999974)"> 

-- and wkt parsed in --
ruby-1.8.7-p160 :015 > f.parse_wkt('POINT(111.99 -40.37)').x
 => 111.99 
ruby-1.8.7-p160 :016 > f.parse_wkt('POINT(111.99 -40.37)').y
 => -40.37 
ruby-1.8.7-p160 :017 > f.parse_wkt('POINT(111.99 -40.37)')
 => #<RGeo::Geos::PointImpl:0x3fe971d84cf4 "POINT (111.9899999999999949 -40.3699999999999974)"> 

from rgeo.

WKB embeds actual IEEE 754 floating-point representations, so round trips through WKB should reproduce the original values exactly bit-for-bit. Only WKT should be a concern because of the conversion between binary and decimal.

from rgeo.

Sorry, forgot to close this issue. Version 0.2.9 (released a few weeks ago) switched the WKT generation to RGeo's pure Ruby WKT generator by default, which should greatly reduce if not eliminate this issue.

from rgeo.