Open wrkrb33 opened 8 years ago
I'm making a guess here...
Are there any self intersecting polygons in your data?
I'm pretty sure that there aren't - I don't believe postgis would accept them in that case. I should probably note though that they are stored in UTM Zone 15N (EPSG:26915), and I am reprojecting them in postgis to Geographic (EPSG:4326) before attempting to parse them. Not sure how that could make a difference, though...
PostGIS accepts them, but I've found that when GEOS library is not correctly linked to RGeo, it cannot parse self-intersecting polygons.
As regards GEOS, I think I'm correctly set up:
> RGeo::Geos.supported?
=> true
As regards validity of the polygons, the example that fails to parse above returns 't' for the below in postgis, which I believe indicates that it is not self-intersecting:
select st_isvalid('0103000020E6100000010000001800000041F9969B7D5B57C0616D371F0AB44640CD9A9A9A7D5B57C0140A329D08B446408C430A72CF5B57C0F754B66009B4464062E86360D05B57C07855EC6209B446405A83FA80D05B57C070F5396309B44640984A28D60B5C57C02BA4CDEF09B446406DBD4165225C57C01BDCFF240AB446401FCDD269225C57C0F6300A250AB44640A3394148235C57C0DD7F16270AB4464008B57167235C57C0D65760270AB446405E37C068225C57C0BDDB728154B446400B2DAE68225C57C017C5C58654B446402624AD68225C57C06AC31C8754B4464070B225D9215C57C02235EC6C7EB446404DDAC3E0CF5B57C02F9A8C077FB446400B8ABA94CD5B57C0B558DB0B7FB44640C6D2ECAAC05B57C0355A07247FB4464007DCEFF29C5B57C0DBDEA5667FB44640EBB61099985B57C06550BC6E7FB44640768C0422865B57C008E804917FB446407B2EC626805B57C016671B9C7FB4464058AB5DE87D5B57C0470F5C977FB4464099ACC3A57D5B57C0AA47E8AF19B4464041F9969B7D5B57C0616D371F0AB44640')
@wrkrb33 Where you able to figure out what the issue was? I believe I found the issue 2 days ago and reported it here: https://github.com/rgeo/activerecord-postgis-adapter/issues/202
I'd love to help get some movement here!
@nearapogee No, I have not been able to get to the bottom of this. It is a bit of a show-stopper...
I'm seeing a similar issue in a codebase I've recently started working on and was able to narrow it down (in at least one of the cases) to a polygon that has a few consecutive duplicate points.
I finally found this by calling is_simple?
on the the rings of the polygon and noticing that it threw an exception down in ArcXYZ#degenerate?
—when the start and end points of an arc are the same, axis
returns nil
.
I'm not sure if this exception is what is breaking parsing, but the consecutive duplicate points are definitely the problem in the data. Fixing them allowed parsing to work fine. Not sure if this is what @wrkrb33 was encountering, but it could be.
(Relatedly, it would be nice this error was handled with a meaningful exception during parsing, e.g. "consecutive identical points" or something. That would have made finding this issue much more obvious.)
I don't have much to add here except for a "me too", but I can confirm that:
• All of my records (succeeding and failing) pass the st_isvalid()
test.
• I'm seeing this behavior consistently after saving certain WKT MULTIPOLYGON
records, but not on others.
I'm working with activerecord-postgis-adapter
, and got here via @nearapogee's issue above. Condensed example from my app:
> region_text = "MULTIPOLYGON (...)"
> ActiveRecord::Base.connection.execute("UPDATE districts SET district_area = ST_Transform(ST_GeomFromText('#{region_text}',102645),4326) WHERE id = #{district.id}")
> District.find(district.id).district_area
=> nil
I've run into this locally as well; in lib/rgeo/types.rb, adding
nfactory_.line_string(obj_.points.chunk{|x| x}.map(&:first).map { |p_| cast(p_, nfactory_, opts_) })
has fixed our problems. The key bit is the chunk and subsequent map to remove equivalent points. I've added this for the ntpye == LinearRing and LineString blocks.
Same as #212. The geographic factory sometimes invalidates linear rings if the points are close due to floating point precision errors.
Using RGeo 0.4.0. The ewkb geometries I'm working with are polygons pulled from a postgis database. I am using them in all sorts of contexts and know them to be valid. However, parsing fails on some percentage of them (10-20%?). I haven't been able to identify any common characteristic among the polygons that fail to parse.