Re: [gdal-dev] Tests if the geometry is within the other geometry

2018-06-22 Thread mikeucfl
Use a spatial filter using your refpoly before iterating the features: http://gdal.org/python/osgeo.ogr.Layer-class.html#SetSpatialFilter -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.

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

2018-02-06 Thread mikeucfl
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

2018-01-18 Thread mikeucfl
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

2018-01-16 Thread mikeucfl
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

2018-01-15 Thread mikeucfl
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

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

2018-01-15 Thread mikeucfl
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] Possible bug with creating transactions using the FileGDB driver

2017-10-03 Thread mikeucfl
The fix worked for me, thanks! -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Possible bug with creating transactions using the FileGDB driver

2017-10-03 Thread mikeucfl
I recently stepped up some code to use Visual Studio 2015 and calling GDALDataset::startTransaction(true) seems to fail for the FileGDB driver. I tracked the issue down to cpl_conv's CPLCopyTree method: In Visual Studio 2012 the first call to VSIStatL(pszOldPath, &sStatBuf) sets sStatBuf so st_mod