Inconsistent behavior between Ruby and C implementations

[wenley]

A friend and I were using the gem and noticed a difference in behavior between our two machines: mine was using the C implementations whereas his was sticking with Ruby. This by itself is not an issue.

However, we found out that the two implementations have different behaviors when calling the #boundary method on a POLYGON object. The Ruby implementation returns a MULTILINESTRING whereas the C implementation returns a simple LINESTRING. This caused an exception because the former responds to the #first method and the latter does not.

Code to reproduce the issue

require 'rgeo'
require 'rgeo-geojson'

json = <<-JSON
{
 "type": "Polygon",
 "coordinates": [
   [[102.0, 2.0], [103.0, 2.0], [103.0, 3.0], [102.0, 3.0], [102.0, 2.0]]
 ]
}
JSON

ruby_factory = RGeo::Cartesian.simple_factory(srid: 4326)
c_factory = RGeo::Geos::CAPIFactory.create

ruby_obj = RGeo::GeoJSON.decode(
 json,
 json_parser: :json,
 geo_factory: ruby_factory,
)
c_obj = RGeo::GeoJSON.decode(
 json,
 json_parser: :json,
 geo_factory: c_factory,
)

puts "RUBY OBJECT"
puts ruby_obj.class
puts ruby_obj
puts ruby_obj.boundary

puts "C OBJECT"
puts c_obj.class
puts c_obj
puts c_obj.boundary

The output:

RUBY OBJECT
RGeo::Cartesian::PolygonImpl
POLYGON ((102.0 2.0, 103.0 2.0, 103.0 3.0, 102.0 3.0, 102.0 2.0))
MULTILINESTRING ((102.0 2.0, 103.0 2.0, 103.0 3.0, 102.0 3.0, 102.0 2.0))
C OBJECT
RGeo::Geos::CAPIPolygonImpl
POLYGON ((102.0 2.0, 103.0 2.0, 103.0 3.0, 102.0 3.0, 102.0 2.0))
LINESTRING (102.0 2.0, 103.0 2.0, 103.0 3.0, 102.0 3.0, 102.0 2.0)

[fergyfresh]

@teeparham do you think this is at all related to the fact that multi_line_string.rb's C binding doesn't exist in the ext folder.

My thought process is that the features are expanded by the FeatureCollection class in ruby and I'm thinking since the multi_line_string.[c|h] (C implementation of the multi_line_string.rb) doesn't exist it is defaulting to the plain old line_string.[h|c] in https://github.com/rgeo/rgeo/tree/master/ext/geos_c_impl.

I pulled the thread as much as I could and that seems to be the biggest hole based on my understanding of the C APIs.

Either way I plan on trying my fix and reporting back later today.

[rossi-jeff]

is there a way to specify to not use the c api under any circumstances, the ruby api works fine for development, but then the c api is broken in production.

[keithdoggett]

The issue is that the C API will return either a multi_linestring or linestring depending on the precence of interior rings or not.

For example:

c_factory = RGeo::Geos.factory
poly = c_factory.parse_wkt("POLYGON ((-120.0 60.0, 120.0 60.0, 120.0 -60.0, -120.0 -60.0, -120.0 60.0), (-60.0 30.0, 60.0 30.0, 60.0 -30.0, -60.0 -30.0, -60.0 30.0))")
poly.boundary
=> #<RGeo::Geos::CAPIMultiLineStringImpl "MULTILINESTRING ((-120.0 60.0, 120.0 60.0, 120.0 -60.0, -120.0 -60.0, -120.0 60.0), (-60.0 30.0, 60.0 30.0, 60.0 -30.0, -60.0 -30.0, -60.0 30.0))"> 

Per the OGC SFS boundaries for Polygons should work as follows:

The boundary of a Polygon consists of a set of LinearRings that make up its exterior and interior boundaries

So it seems like the boundary method should return a collection, but libgeos does not do that by default. It's possible to modify the C API implementation in RGeo to match the Ruby implementation or vice versa. A decision just has to be made on whether its better to mirror libgeos or base things more closely off of the OGC SFS.