[gdal-dev] Merging TIFF files creates offset / deformation

Hi, I have a PNG library (524288 tiles of 256px * 256px) which I georeferenced via GDAL. # This first part works correctly. • ullr: > ulx = (360 * (column / 1024)) - 180 > uly = 90 - (180 * (line / 512)) > lrx = ulx + 0.3515625 > lry = uly - 0.3515625 > ULLR = ulx + '' + uly + '' + lrx + '' +

Re: [gdal-dev] stricmp in cpl_port.h

On Wed, Apr 7, 2021, 11:48 AM Andrew C Aitchison wrote: > > On Wed, 7 Apr 2021, Andrew Bell wrote: > > > Dare I suggest getting rid of EQUAL? > > Since the purpose of EQUALS is to compare two strings, that would > be passing the buck. Without it developers would have to solve this > issue for eac

Re: [gdal-dev] stricmp in cpl_port.h

You're welcome to submit a pull request changing stricmp by _stricmp so that we can check that our CI is happy with that. Given than we only support MSVC >= 2015 nowadays, I'd expect this to run smoothly. Le 07/04/2021 à 16:24, Andrew C Aitchison a écrit : I have developed a gdal driver plugi

Re: [gdal-dev] stricmp in cpl_port.h

On Wed, 7 Apr 2021, Andrew Bell wrote: Dare I suggest getting rid of EQUAL? Since the purpose of EQUALS is to compare two strings, that would be passing the buck. Without it developers would have to solve this issue for each platform each time, making it more likely that someone would break

Re: [gdal-dev] stricmp in cpl_port.h

Dare I suggest getting rid of EQUAL? On Wed, Apr 7, 2021 at 10:25 AM Andrew C Aitchison wrote: > > I have developed a gdal driver plugin on Linux and am now attempting to > build it on Windows. > I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler > (all installed this week,

[gdal-dev] stricmp in cpl_port.h

I have developed a gdal driver plugin on Linux and am now attempting to build it on Windows. I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler (all installed this week, latest versions I believe), but am open to other suggestions for building a windows gdal driver plugin.

Re: [gdal-dev] NITF Int16 image size limit

I took a closer look at the files. It looks like they maxed out the byte size and were truncated. Several NITF images have different rows * columns, but the same byte size. May not be a GDAL issue. From: gdal-dev on behalf of ni hao Sent: April 7, 2021 10:52 AM

Re: [gdal-dev] NITF Int16 image size limit

Hi Even, It was CSA using their own software. They said that it was fine access the last 2000 lines. But I could not confirm. From: Even Rouault Sent: April 7, 2021 10:41 AM To: ni hao ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] NITF Int16 image size l

Re: [gdal-dev] NITF Int16 image size limit

Hum, 4294967295 = 0x = max uint32 value. This really a suspicious file size that looks like truncation at the 4 GB limit. Are you really really sure that you tested the non-GDAL implementation with that exact file, and not another version that might have been truncated later ? Le 07/0

Re: [gdal-dev] "New" style import

Hi Daniel, On Wed, 7 Apr 2021 at 13:20, Daniel Evans wrote: > In 3.1 and earlier, GDAL had short helper scripts to allow the deprecated > imports, named “gdal.py”, “osr.py”, and “ogr.py” > Thanks, this is a good idea. I have packages installed all over the place (different environments, in deve

Re: [gdal-dev] NITF Int16 image size limit

Hi Even, I am using GDAL 2.4.4. I may try the latest version as you suggested. The NITF file size is 4,294,967,295 bytes The vendor used a non-GDAL implementation, and was able to display all image. Metadata: NITF_ABPP=16 NITF_BLOCKA_BLOCK_COUNT=01 NITF_BLOCKA_BLOCK_INSTANCE_01=01 NITF_

Re: [gdal-dev] "New" style import

In 3.1 and earlier, GDAL had short helper scripts to allow the deprecated imports, named “gdal.py”, “osr.py”, and “ogr.py”, with contents like: ``` # import osgeo.gdal as a convenience from osgeo.gdal import deprecation_warn deprecation_warn('gdal') from osgeo.gdal import * ``` You could create

[gdal-dev] MSSQLSpatial driver from GDAL 3.2.2 does not export data

Hi, I'm trying to export some data from shapefile to a MSSQLServer database with the MSSQLSpatial driver, but I'm getting an error when doing it with ogr2ogr from GDAL 3.2.2: ogr2ogr --version GDAL 3.2.2, released 2021/03/05 ogr2ogr.exe -progress -f MSSQLSpatial "MSSQL:server=HP-OMEN\SQLEXPRESS;

[gdal-dev] "New" style import

Hi, I've recently updated GDAL to 3.2.1. I mostly use it from Python, and have oodles of scripts from the past that use "import gdal" somewhere. With the newer versions of GDAL, this is deprecated and is now "from osgeo import gdal". Is there some hacky workaround/sacrifice to the technical debt g

Re: [gdal-dev] Proposed GDAL 3.3 release schedule

Idan, What is the policy for accepting feature PRs (not bug fixes) ? I mean do all new features from when beta/RC is published will be merged only to the next minor version, i.e. 3.4 ? Between beta1 and RC1, some feature PRs might be accepted, but not ones with strong impacts (typically shoul

Re: [gdal-dev] Proposed GDAL 3.3 release schedule

Hi Even and all, I think that the schedule makes sense. What is the policy for accepting feature PRs (not bug fixes) ? I mean do all new features from when beta/RC is published will be merged only to the next minor version, i.e. 3.4 ? Because we cannot release gdal-utils

[gdal-dev] Proposed GDAL 3.3 release schedule

Hi, We haven't yet talked about it. Given the changes on the Python bindings side with moving of script files around (see https://github.com/OSGeo/gdal/pull/3635), I think we should go for a beta to give a chance to packagers to check that everything is OK before we proceed further. Hopefully

Re: [gdal-dev] Shall I continue trying to get gdal java bindings to work?

Paul, you're kindly invited to help improving the documentation of https://gdal.org/api/java.html. See the "Edit on GitHub" button on the top right of the page to submit a contribution Even Le 07/04/2021 à 07:17, paul.m...@lfv.se a écrit : When I copy ALL the dll-files in gdal\bin (geos.dl

Re: [gdal-dev] NITF Int16 image size limit

Hi, Actually the error message doesn't look like there's a uint32 overflow as it displays a file offset that is beyond the 4 GB limit. Did you check that your file size is at least 4324329780 + 4194302 = 4 328 524 082 bytes ? I guess it is not, or then there's some mysterious error in the lo