Re: [gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
Le 19/12/2022 à 20:48, Peter Townsend a écrit : Thanks! One more question. For the time being, is it generally ok to ignore "tolerance condition error" and "Point outside of projection domain"? I can make our program not care about those if it's usually harmless. They could still be emitted if features' geometries fail to reproject. If you don't pass the -skip_failure flag, then you can just test ogr2ogr error code. If it is 0, everything is fine. -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
Thanks! One more question. For the time being, is it generally ok to ignore "tolerance condition error" and "Point outside of projection domain"? I can make our program not care about those if it's usually harmless. On Mon, Dec 19, 2022 at 1:42 PM Even Rouault wrote: > 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 > wrote: > >> Peter, >> >> I suspect the reprojection of your features went fine, otherwise you >> would have got an error message like "Failed to reproject feature >> (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=027A1189CBE0) succeeds as ESRI >> Shapefile. >> GDAL: Using ESRI Shapefile driver >> GDAL: GDALDriver::Create(ESRI >> Shapefile,c:\path\output,0,0,0,Unknown,) >> 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=027A1189CBE0) >> GDAL: GDALClose(c:\path\output, this=027A1189D4A0) >> 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
Re: [gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
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 wrote: Peter, I suspect the reprojection of your features went fine, otherwise you would have got an error message like "Failed to reproject feature (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=027A1189CBE0) succeeds as ESRI Shapefile. GDAL: Using ESRI Shapefile driver GDAL: GDALDriver::Create(ESRI Shapefile,c:\path\output,0,0,0,Unknown,) 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=027A1189CBE0) GDAL: GDALClose(c:\path\output, this=027A1189D4A0) 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
Re: [gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
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 wrote: > Peter, > > I suspect the reprojection of your features went fine, otherwise you would > have got an error message like "Failed to reproject feature (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=027A1189CBE0) succeeds as ESRI > Shapefile. > GDAL: Using ESRI Shapefile driver > GDAL: GDALDriver::Create(ESRI > Shapefile,c:\path\output,0,0,0,Unknown,) > 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=027A1189CBE0) > GDAL: GDALClose(c:\path\output, this=027A1189D4A0) > 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 > listgdal-dev@lists.osgeo.orghttps://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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
Peter, I suspect the reprojection of your features went fine, otherwise you would have got an error message like "Failed to reproject feature (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=027A1189CBE0) succeeds as ESRI Shapefile. GDAL: Using ESRI Shapefile driver GDAL: GDALDriver::Create(ESRI Shapefile,c:\path\output,0,0,0,Unknown,) 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=027A1189CBE0) GDAL: GDALClose(c:\path\output, this=027A1189D4A0) 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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Tolerance Condition Error ogr2ogr Albers to EPSG:4326
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=027A1189CBE0) succeeds as ESRI Shapefile. GDAL: Using ESRI Shapefile driver GDAL: GDALDriver::Create(ESRI Shapefile,c:\path\output,0,0,0,Unknown,) 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=027A1189CBE0) GDAL: GDALClose(c:\path\output, this=027A1189D4A0) 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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
