[gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326

[Even Rouault]

Fix in https://github.com/OSGeo/gdal/pull/6945. The error is actually 
harmless as I suspected and was related to the polar geometry splitting 
heuristics not properly shutting off reprojection errors.

Even

Le 19/12/2022 à 19:59, Peter Townsend a écrit :
> I figured out that the dataset is actually the "trees" shapefile from 
> the QGIS sample dataset. Throws the same messaging out.
> https://download.qgis.org/downloads/data/
>
> qgis_sample_data\shapefiles\trees.*
>
> Good luck!
>
> On Mon, Dec 19, 2022 at 12:46 PM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     Peter,
>
>     I suspect the reprojection of your features went fine, otherwise
>     you would have got an error message like "Failed to reproject
>     feature XXXX (geometry probably out of source or destination
>     SRS)". This error message must come from some code that tries
>     heuristics related to polar or anti-meridian geometry splitting,
>     although normally there are provisions to silent non-critical
>     reprojection errors related to those heuristics, but perhaps
>     there's some silencing missing somewhere.
>
>     I could have a look if you can pass on the dataset (you can send
>     it / a link for it privately if needed)
>
>     Even
>
>     Le 19/12/2022 à 19:16, Peter Townsend via gdal-dev a écrit :
>>     I've got this test dataset of a bunch of forest areas in Alaska.
>>     The shapefile is in Albers, and we're converting it to EPSG:4326
>>     lat longs.
>>
>>     Layer name: trees
>>     Geometry: Polygon
>>     Feature Count: 444
>>     Extent: (-2175230.041280, 1899842.624457) - (4895522.387686,
>>     6909266.538422)
>>     Layer SRS WKT:
>>     PROJCRS["Albers",
>>         BASEGEOGCRS["NAD27",
>>             DATUM["North American Datum 1927",
>>                 ELLIPSOID["Clarke 1866",6378206.4,294.978698213898,
>>                     LENGTHUNIT["metre",1]],
>>                 ID["EPSG",6267]],
>>             PRIMEM["Greenwich",0,
>>                 ANGLEUNIT["Degree",0.0174532925199433]]],
>>         CONVERSION["unnamed",
>>             METHOD["Albers Equal Area",
>>                 ID["EPSG",9822]],
>>             PARAMETER["Latitude of false origin",50,
>>                 ANGLEUNIT["Degree",0.0174532925199433],
>>                 ID["EPSG",8821]],
>>             PARAMETER["Longitude of false origin",-154,
>>                 ANGLEUNIT["Degree",0.0174532925199433],
>>                 ID["EPSG",8822]],
>>             PARAMETER["Latitude of 1st standard parallel",55,
>>                 ANGLEUNIT["Degree",0.0174532925199433],
>>                 ID["EPSG",8823]],
>>             PARAMETER["Latitude of 2nd standard parallel",65,
>>                 ANGLEUNIT["Degree",0.0174532925199433],
>>                 ID["EPSG",8824]],
>>             PARAMETER["Easting at false origin",0,
>>                 LENGTHUNIT["US survey foot",0.304800609601219],
>>                 ID["EPSG",8826]],
>>             PARAMETER["Northing at false origin",0,
>>                 LENGTHUNIT["US survey foot",0.304800609601219],
>>                 ID["EPSG",8827]]],
>>         CS[Cartesian,2],
>>             AXIS["(E)",east,
>>                 ORDER[1],
>>                 LENGTHUNIT["US survey foot",0.304800609601219,
>>                     ID["EPSG",9003]]],
>>             AXIS["(N)",north,
>>                 ORDER[2],
>>                 LENGTHUNIT["US survey foot",0.304800609601219,
>>                     ID["EPSG",9003]]]]
>>
>>     We're trying to upgrade our GDAL from 3.21 to 3.53, and our poor
>>     test is getting flagged now with either "ERROR 1: Point outside
>>     of projection domain" and/or "ERROR 1: tolerance condition error".
>>
>>     This is what I'm seeing:
>>     ogr2ogr.exe -skipfailures -t_srs EPSG:4326 --debug on
>>     c:\path\output c:\path\trees.shp
>>     GDAL: GDALOpen(c:\path\trees.shp, this=0000027A1189CBE0) succeeds
>>     as ESRI Shapefile.
>>     GDAL: Using ESRI Shapefile driver
>>     GDAL: GDALDriver::Create(ESRI
>>     Shapefile,c:\path\output,0,0,0,Unknown,0000000000000000)
>>     Shape: DBF Codepage = LDID/87 for c:\path\trees.shp
>>     Shape: Treating as encoding 'ISO-8859-1'.
>>     ERROR 1: tolerance condition error
>>     ERROR 1: tolerance condition error
>>     GDALVectorTranslate: 444 features written in layer 'trees'
>>     Shape: 444 features read on layer 'trees'.
>>     GDAL: GDALClose(c:\path\trees.shp, this=0000027A1189CBE0)
>>     GDAL: GDALClose(c:\path\output, this=0000027A1189D4A0)
>>     GDAL: In GDALDestroy - unloading GDAL shared library.
>>
>>     (Same thing happens without skipfailures.)
>>
>>     Now I'm 95% sure it's throwing this error because there's some
>>     vertex somewhere in here that's in that special "dead zone" for
>>     Alaska Albers that can't convert to 4326 (seen this before on
>>     other datasets trying to project individual points).
>>
>>     What I'm wondering is this:
>>     1) Is there any way to get GDAL to tell me what
>>     feature/coordinate threw the error?
>>     2) What is it doing as a fallback behavior? Skipping the point
>>     and moving on? I still come out with the same number of features
>>     in the end.
>>
>>     Thanks!
>>     -- 
>>     Peter Townsend
>>     Senior Software Developer
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>
>
>
> -- 
> Peter Townsend
> Senior Software Developer

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221219/48995b27/attachment.htm>