[gdal-dev] Discrepancy when tiling on MAC and Linux

Hey all, So I have a strange issue that I somewhat isolated, but I don't know how to move further. I have dataset in EPSG 31468-15949 My goal is to tile it, render it with openlayers, and add a marker on the GCP location. Trouble is that the GCP location was falling a bit away from the marker ima

[gdal-dev] Add padding to an image

Hi All, What the best way to pad an output RGBA image with gdal tools? Thanks in advance. Cheers Jeremy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On Thu, 7 Nov 2019 at 20:05, Roger Bivand wrote: > Thanks for contributing! In research reproducibility, being able now to > get the same results as when the research was conducted using the same > software is basic. (again, apologies if I'm ignorant here -- I'm coming from a totally different d

Re: [gdal-dev] Limit on the number of files for gdalbuildvrt

Getting through a bit further... It appears that I can get this fixed if I set GDAL_DISABLE_READDIR_ON_OPEN to YES: GDAL_DISABLE_READDIR_ON_OPEN=YES gdalbuildvrt -input_file_list flist.txt outputfile.vrt In order to use the file, GDAL_DISABLE_READDIR_ON_OPEN needs to be selected too. Mystery solv

Re: [gdal-dev] OGRCoordinateTransformation Thread Safety

On jeudi 7 novembre 2019 08:49:06 CET Bryant wrote: > Thank you for the response Even! > > >As most C/C++ libraries, an object is not thread-safe unless it is > > explicitly mentioned it is. > > This makes sense. > However, I inferred from one of your previous responses >

Re: [gdal-dev] OGRCoordinateTransformation Thread Safety

Thank you for the response Even! >As most C/C++ libraries, an object is not thread-safe unless it is explicitly mentioned it is. This makes sense. However, I inferred from one of your previous responses

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On Thu, 7 Nov 2019, Even Rouault wrote: On jeudi 7 novembre 2019 11:10:26 CET Roger Bivand wrote: On Thu, 7 Nov 2019, Even Rouault wrote: On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote: On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote: I realise this too, but to permit legacy re

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On jeudi 7 novembre 2019 11:10:26 CET Roger Bivand wrote: > On Thu, 7 Nov 2019, Even Rouault wrote: > > On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote: > >> On Wed, 30 Oct 2019 at 06:16, Even Rouault > > > > wrote: > I realise this too, but to permit legacy results to be replicated

[gdal-dev] GDAL/OGR curve stroking dfMaxAngleStepSizeDegrees

Hi folks Iam interested in the default value for parameter dfMaxAngleStepSizeDegrees for stroking curved polygons. The OGR docs https://gdal.org/doxygen/classOGRPolygon.html#a7e5a3f9a67e18e045167832c5b8ff850 say only that there is some default value used if parameter 0 is passed. Does anybod

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On Thu, 7 Nov 2019, Even Rouault wrote: On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote: On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote: I realise this too, but to permit legacy results to be replicated, Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On Thu, 7 Nov 2019, Nyall Dawson wrote: On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote: I realise this too, but to permit legacy results to be replicated, Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate it in PROJ would be heartbreaking, an extra maintaince b

Re: [gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote: > On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote: > > > I realise this too, but to permit legacy results to be replicated, > > > > Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate > > it in PROJ would be heartb

Re: [gdal-dev] OGRCoordinateTransformation Thread Safety

On mercredi 6 novembre 2019 14:51:28 CET Bryant wrote: > Further, manual tests suggest that it is in GDAL 2.4.3 -- 20 threads > performing transformations on the same OGRCoordinateTransformation instance > and ensuring that the result is within 1e-4 of the correct result. As most C/C++ libraries,