Float rounding error in GEOS factory

[sharpone74]

Hi, First off, thanks for a GREAT gem! And thanks for fixing the last issue I encountered.

We uncovered what seems to be a classic floating point rounding error when a cartesian factory uses the GEOS extensions. Not an overly significant rounding error, but there none the less. Here is an example on the ruby console:

--pure ruby is correct-- 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 with c extension is not-- ruby-1.8.7-p160 :004 > f = RGeo::Cartesian.preferred_factory => # ruby-1.8.7-p160 :005 > f.point(111.99, -40.37) => #<RGeo::Geos::PointImpl:0x3fa3dbcf1520 "POINT (111.9899999999999949 -40.3699999999999974)">

I have not tested this with other rubies yet, as this is what we are currently running in prod (unfortunately) for the time being. Again, thanks for a great gem, and let me know if I can provide any other information, or if i'm wrong about this being an error.

[sharpone74]

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)"> 

[sharpone74]

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

[dazuma]

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.

[sharpone74]

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)"> 

[dazuma]

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.

[dazuma]

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.