[gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

I need some help trying to make sense of an issue I'm running into using OGRGeometry::difference. I have some pretty large geometries (spans across multiple longitude/latitude values) in which I am utilizing the difference operation in OGRGeometry to cut holes in and get the resulting geometry. Thi

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

Just to add some more information.. upon some further inspection it seems all the values are snapped to a grid. All my geometry is in a WGS84 (EPSG:4326) projection, and the values are snapped to a 0.01 lat/long grid. I don't do anything to set a tolerance or anything for these values, or see where

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

Got permission to show the actual data: (left side is what the data should look like, red is what the data looks like after calling the difference operation). -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

On lundi 15 janvier 2018 16:49:57 CET mikeucfl wrote: > Just to add some more information.. upon some further inspection it seems > all the values are snapped to a grid. All my geometry is in a WGS84 > (EPSG:4326) projection, and the values are snapped to a 0.01 lat/long grid. > I don't do anything

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

So the geometry before using the difference operation looks good (geodetic values go up to 8-9 decimal places), and then the resulting geometry is truncated to two (this is before placing in any file geodatabase) as well. I have checked the source feature classes and verified that the precision is

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

Just to update with what I've figured out so far. 1. The issue surrounds an OGRMultiGeometry that has intersecting interior rings. 2. The projection of the geometries are in EPSG 4326 (lat/long). 3. Internally in GEOS when the difference operator runs, there is a call to check if the geometry is v

Re: [gdal-dev] Resulting geometry from OGRGeometry::difference somehow got simplified

mikeucfl wrote > So if anyone sees a similar issue, it's something internally with GEOS but > I > didn't have enough time to track it down. Re-projecting to something using > meters does help though. Hi, If you could share couple of problematic geometries for example as WKT then somebody else cou