Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

The Docker images are now available:

ghcr.io/osgeo/gdal:alpine-small-3.9.0beta1
ghcr.io/osgeo/gdal:ubuntu-small-3.9.0beta1
ghcr.io/osgeo/gdal:alpine-normal-3.9.0beta1
ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1

Le 22/04/2024 à 14:12, Even Rouault via gdal-dev a écrit :

Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.

The NEWS file is here:

  https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers, 
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html 
may make it more attractive to build some drivers that typically have 
heavy dependencies as plugins, installable in separate packages, due 
to the load time penalty having being improved. It is let to the 
appreciation of packagers to decide which drivers are worth building 
as plugins installable in a separate package.
You may also pass CMake options 
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so 
user get a hint of which package they need to install when GDAL 
detects that a file may be opened by a plugin which is not available 
on the file system but known to have been built as a plugin. Cf 
https://gdal.org/development/building_from_source.html#deferred-loaded-plugins 
for more details.


For end-users, the following utilities have been updated to use a new 
argument parsing framework: gdaladdo, gdalinfo, gdal_translate, 
gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, 
ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that 
should be specified once (where generally the last instance was the 
one used). While we have tried to retain backwards compatibility for 
nominal use cases, obviously if you have scripts that accidentally 
specify an argument several times whereas it should be specified at 
most once, they will have to be corrected.


Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has been 
created. All bugfixes for 3.9 should be backported into it.


Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even


--
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] GDAL 3.9.0beta1 available for testing

[Sean Gillies via gdal-dev]

Thanks for the fix and suggestions! I'm looking forward to 3.9.0.

On Mon, Apr 22, 2024 at 11:27 AM Even Rouault 
wrote:

> Sean,
>
> Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.
>
> Metadata output of gdalinfo has changed.
>
> ok, I've run locally rasterio tests and I see gdalinfo now outputs:
> Metadata:
>   a=1
>   b=2
>   AREA_OR_POINT=Area
>
> whereas the test expects
>
> Metadata:
>   a=1
>   AREA_OR_POINT=Area
>   b=2
>
> Order of metadata items shouldn't be relied upon. I believe we have
> changed something internally (likely changing from char** to CPLStringList
> that does sorting) that might indeed have affected it. You could also
> potentially use "gdalinfo -json" output to get something easier to parse.
> But don't you have a rasterio API to get GDAL metadata that would avoid
> using gdalinfo at all?
>
> As soon as there are docker images I'll look more closely at this.
>
> ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 is already available
>
>
> Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a 
> RGB.byte.tif.msk
> file:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231
> .
>
> Yes, this is intended. Due to this change:
> GTiff driver:
>  * change default value of GDAL_TIFF_INTERNAL_MASK config option to YES
>
> You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you want to
> test external mask.
>
>
> The text of an error message which was "tests/data/corrupt.tif, band 1:
> IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed."
> in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset
> 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we
> can adjust Rasterio's test.
>
> Yes, related to
> https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0
>
>
> Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems
> to have changed:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287.
> I'm not entirely sure what the intent is in Rasterio's test, will dig into
> that. I just wanted to say that I see a change in GDAL.
>
> ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which
> indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using
> directly the geotransform from the source dataset.
>
> Fix queued in https://github.com/OSGeo/gdal/pull/9724
>
> (that said, tests reprojecting from 4326 to 3857 while ignoring the
> geotransform are a bit weird)
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Sean Gillies via gdal-dev]

Thanks, Jukka!

On Mon, Apr 22, 2024 at 10:48 AM Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> The mask thing may happen due to https://github.com/OSGeo/gdal/pull/9604.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Sean
> Gillies via gdal-dev
> *Lähetetty:* maanantai 22. huhtikuuta 2024 19.15
> *Vastaanottaja:* Even Rouault 
> *Kopio:* gdal-dev@lists.osgeo.org
> *Aihe:* Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
>
>
>
> Hi Even,
>
>
>
> Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.
>
>
>
> Metadata output of gdalinfo has changed. As soon as there are docker
> images I'll look more closely at this.
>
>
>
> Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a 
> RGB.byte.tif.msk
> file:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231
> .
>
>
>
> The text of an error message which was "tests/data/corrupt.tif, band 1:
> IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed."
> in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset
> 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we
> can adjust Rasterio's test.
>
>
>
> Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems
> to have changed:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287.
> I'm not entirely sure what the intent is in Rasterio's test, will dig into
> that. I just wanted to say that I see a change in GDAL.
>
>
>
>
>
> On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
> Hi,
>
> I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md
>
> For packagers,
> https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may
> make it more attractive to build some drivers that typically have heavy
> dependencies as plugins, installable in separate packages, due to the
> load time penalty having being improved. It is let to the appreciation
> of packagers to decide which drivers are worth building as plugins
> installable in a separate package.
> You may also pass CMake options
> ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so
> user get a hint of which package they need to install when GDAL detects
> that a file may be opened by a plugin which is not available on the file
> system but known to have been built as a plugin. Cf
>
> https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
> for more details.
>
> For end-users, the following utilities have been updated to use a new
> argument parsing framework: gdaladdo, gdalinfo, gdal_translate,
> gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo,
> ogr2ogr, sozip.
> This helps detecting errors such as specifying twice an argument that
> should be specified once (where generally the last instance was the one
> used). While we have tried to retain backwards compatibility for nominal
> use cases, obviously if you have scripts that accidentally specify an
> argument several times whereas it should be specified at most once, they
> will have to be corrected.
>
> Docker images with 3.9.0beta1 are currently cooking.
>
> master is now marked as 3.10.0dev, and the release/3.9 branch has been
> created. All bugfixes for 3.9 should be backported into it.
>
> Source snapshots at:
>
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
> - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip
>
> Autotest snapshots:
>
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip
>
> Even
>
>
>
> --
>
> Sean Gillies
>


-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

Holger,

thanks for the report. This should be fixed per 
https://github.com/OSGeo/gdal/commit/fba559b5bd8d33aac215681df4f6a613517a6c43 
which I've backported to the release/3.9 branch


A workaround is to explicitly run "cmake --target 
generate_gdal_version_h" before building all other targets


Even

Le 22/04/2024 à 23:28, Holger Jaekel via gdal-dev a écrit :

Hi Even,

Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.


I tried to build on Alpine Linux Edge and got the following error:


/builds/hjaekel/aports/community/gdal/src/gdal-3.9.0beta1/ogr/ogr_core.h:38:10: 


fatal error: gdal_version.h: No such file or directory
   38 | #include "gdal_version.h"
  |  ^~~~
compilation terminated.


gdal_version.h seems not to be generated to build/gcore.

You can find the full build logs here:
https://gitlab.alpinelinux.org/hjaekel/aports/-/pipelines/228841

Holger

___
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

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Holger Jaekel via gdal-dev]

Hi Even,

Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.


I tried to build on Alpine Linux Edge and got the following error:


/builds/hjaekel/aports/community/gdal/src/gdal-3.9.0beta1/ogr/ogr_core.h:38:10:
fatal error: gdal_version.h: No such file or directory
   38 | #include "gdal_version.h"
  |  ^~~~
compilation terminated.


gdal_version.h seems not to be generated to build/gcore.

You can find the full build logs here:
https://gitlab.alpinelinux.org/hjaekel/aports/-/pipelines/228841

Holger

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

It should have read https://download.osgeo.org/gdal/3.9.0/gdal390beta1.zip

Le 22/04/2024 à 21:29, Abel Pau via gdal-dev a écrit :

Hi,
I only want to advice that 
https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip is not found.
Thanks.

-Mensaje original-
De: gdal-dev  En nombre de Even Rouault via 
gdal-dev
Enviado el: dilluns, 22 d’abril de 2024 14:13
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] GDAL 3.9.0beta1 available for testing

Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.

The NEWS file is here:

    https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers,
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it 
more attractive to build some drivers that typically have heavy dependencies as 
plugins, installable in separate packages, due to the load time penalty having 
being improved. It is let to the appreciation of packagers to decide which 
drivers are worth building as plugins installable in a separate package.
You may also pass CMake options
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a 
hint of which package they need to install when GDAL detects that a file may be 
opened by a plugin which is not available on the file system but known to have been 
built as a plugin. Cf 
https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
for more details.

For end-users, the following utilities have been updated to use a new argument 
parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, 
gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that should be 
specified once (where generally the last instance was the one used). While we 
have tried to retain backwards compatibility for nominal use cases, obviously 
if you have scripts that accidentally specify an argument several times whereas 
it should be specified at most once, they will have to be corrected.

Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has been created. 
All bugfixes for 3.9 should be backported into it.

Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even

--
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 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

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Abel Pau via gdal-dev]

Hi,
I only want to advice that 
https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip is not found.
Thanks.

-Mensaje original-
De: gdal-dev  En nombre de Even Rouault via 
gdal-dev
Enviado el: dilluns, 22 d’abril de 2024 14:13
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] GDAL 3.9.0beta1 available for testing

Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.

The NEWS file is here:

   https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers,
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it 
more attractive to build some drivers that typically have heavy dependencies as 
plugins, installable in separate packages, due to the load time penalty having 
being improved. It is let to the appreciation of packagers to decide which 
drivers are worth building as plugins installable in a separate package.
You may also pass CMake options
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a 
hint of which package they need to install when GDAL detects that a file may be 
opened by a plugin which is not available on the file system but known to have 
been built as a plugin. Cf 
https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
for more details.

For end-users, the following utilities have been updated to use a new argument 
parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, 
gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that should be 
specified once (where generally the last instance was the one used). While we 
have tried to retain backwards compatibility for nominal use cases, obviously 
if you have scripts that accidentally specify an argument several times whereas 
it should be specified at most once, they will have to be corrected.

Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has been created. 
All bugfixes for 3.9 should be backported into it.

Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even

--
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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Javier Jimenez Shaw via gdal-dev]

In addition to all the previous, what about gamma correction?
Maybe your RGB images are gamma corrected, while the other bands are not.
In that case you will be comparing apples and oranges (in addition to the
scaling problems described before).
That also means that using the multispectral images (even if you had a Blue
one) without gamma correction will have a strange color for us humans using
a monitor.

What I did in the past was to "fake" blue as a combination of red and green
(yes, it is not perfect, but better than nothing), and apply a gamma of 2
to all the bands.

Other "nice" option is to display them as CIR
https://www.mngeo.state.mn.us/chouse/airphoto/cir.html

Cheers
Javier

On Mon, 22 Apr 2024 at 17:49, Andrew C Aitchison via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> On Mon, 22 Apr 2024, Raley, Nathan via gdal-dev wrote:
>
> > Hmm, good catch.  Looking at the stats for the red band:
> >
> > Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray
> >  Min=130.000 Max=36265.000
> >  Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933
> >  NoData Value=0
> >  Metadata:
> >STATISTICS_MAXIMUM=36265
> >STATISTICS_MEAN=10415.961859513
> >STATISTICS_MINIMUM=130
> >STATISTICS_STDDEV=3502.9325925887
> >STATISTICS_VALID_PERCENT=49
> >
> > So, is there no way to actually do this via command line, or am I going
> to have to write a python lib to actually read through these and determine
> what they should be scaled to?
>
> There is gdal_transform -scale (and -scale_2 etc.)
>
> What are you going to do with the resulting file ?
> QGIS allows you to make these sorts of adjustments at view-time.
>
> Remember that the max and min values present in an image may not represent
> the full range and the next-door image may have a larger or smaller range
> (or just a shifted range). Imagine a row of three tiles; the middle on on
> the edge of a glacier, the first entirely on the glacier and the last
> entirely off the glacier. You may wish to apply the same scaling to all
> three.
>
> > From: Daniel Evans 
> > Sent: Monday, April 22, 2024 9:29 AM
> > To: Raley, Nathan 
> > Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) <
> gdal-dev@lists.osgeo.org>
> > Subject: [External] Re: [gdal-dev] Question on building multi band
> composite and going back to RGB GeoTiff
> >
> > Hi Nathan, My initial suspicion might just be that the scaling the data
> provider did to go from the raw data to a human-eye-friendly RGB composite
> isn't the conversion you're assuming. I know that with the data I regularly
> work with,
> >
> > Hi Nathan,
> >
> > My initial suspicion might just be that the scaling the data provider
> did to go from the raw data to a human-eye-friendly RGB composite isn't the
> conversion you're assuming.
> >
> > I know that with the data I regularly work with, it may be provided as
> Uint16, but the data range doesn't extend all the way to 65535.
> >
> > If you compare the values in the separate R and G images to the RGB
> composite, do they appear to match the conversion you're assuming, or is
> there a different scaling (and possibly offset)?
> >
> > Cheers,
> > Daniel
> >
> > On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
> > I currently have a RGB geotiff composite image that has a Byte
> datatype.  I also have individual band images for R, G, Redge, and NIR that
> are UInt16 datatypes.  Since I’m missing the Blue band from the individual
> bands, I was attempting to extract the blue band from the RGB composite
> image, scale it up to the UInt16 datatype, and build a composite VRT with
> R, G, B, NIR, RE bands included in it.  I was then attempting to extract
> the RGB bands from the multispec VRT in order to see if the process was
> working as intended, but I’m getting an extremely blue image.
> >
> > Can anyone shed some light as to what I may be doing wrong here?
> >
> > I started by building a VRT for each band:
> > gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255
> 0 65535
> > gdalbuildvrt -b 1 r.vrt source_R.tif
> > gdalbuildvrt -b 1 g.vrt source_G.tif
> > gdalbuildvrt -b 1 nir.vrt source_NIR.tif
> > gdalbuildvrt -b 1 re.vrt source_RE.tif
> >
> > I then merged the VRTs:
> > gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt
> >
> > I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with
> a UInt16 datatype.
> >
> > Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with
> something like:
> > gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255
> -co PHOTOMETRIC=RGB multispec.vrt multispec.tif
> >
> > Viewing the result in QGIS appears overly blue.  What am I doing wrong
> here?
> >
> > Thanks,
> > Nathan
> >
> > 
> > This email transmission, including any attachments, is intended solely
> for the addressee named above, and may contain confidential or privileged
> 

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

Sean,

Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.

Metadata output of gdalinfo has changed.


ok, I've run locally rasterio tests and I see gdalinfo now outputs:

Metadata:
  a=1
  b=2
  AREA_OR_POINT=Area

whereas the test expects

Metadata:
  a=1
  AREA_OR_POINT=Area
  b=2

Order of metadata items shouldn't be relied upon. I believe we have 
changed something internally (likely changing from char** to 
CPLStringList that does sorting) that might indeed have affected it. You 
could also potentially use "gdalinfo -json" output to get something 
easier to parse. But don't you have a rasterio API to get GDAL metadata 
that would avoid using gdalinfo at all?



As soon as there are docker images I'll look more closely at this.

ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 is already available


Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a 
RGB.byte.tif.msk file: 
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231.


Yes, this is intended. Due to this change:

GTiff driver:
 * change default value of GDAL_TIFF_INTERNAL_MASK config option to YES

You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you want to 
test external mask.




The text of an error message which was "tests/data/corrupt.tif, band 
1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() 
failed." in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed 
at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." This is not 
a big deal, we can adjust Rasterio's test.
Yes, related to 
https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0


Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options 
seems to have changed: 
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. 
I'm not entirely sure what the intent is in Rasterio's test, will dig 
into that. I just wanted to say that I see a change in GDAL.


ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which 
indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using 
directly the geotransform from the source dataset.


Fix queued in https://github.com/OSGeo/gdal/pull/9724

(that said, tests reprojecting from 4326 to 3857 while ignoring the 
geotransform are a bit weird)


Even


--
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] GDAL 3.9.0beta1 available for testing

[Rahkonen Jukka via gdal-dev]

Hi,

The mask thing may happen due to https://github.com/OSGeo/gdal/pull/9604.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Sean Gillies 
via gdal-dev
Lähetetty: maanantai 22. huhtikuuta 2024 19.15
Vastaanottaja: Even Rouault 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

Hi Even,

Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.

Metadata output of gdalinfo has changed. As soon as there are docker images 
I'll look more closely at this.

Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a 
RGB.byte.tif.msk file: 
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231.

The text of an error message which was "tests/data/corrupt.tif, band 1: 
IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." in 
3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset 1, Y 
offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we can adjust 
Rasterio's test.

Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems to 
have changed: 
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287.
 I'm not entirely sure what the intent is in Rasterio's test, will dig into 
that. I just wanted to say that I see a change in GDAL.


On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev 
mailto:gdal-dev@lists.osgeo.org>> wrote:
Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.

The NEWS file is here:

   https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers,
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may
make it more attractive to build some drivers that typically have heavy
dependencies as plugins, installable in separate packages, due to the
load time penalty having being improved. It is let to the appreciation
of packagers to decide which drivers are worth building as plugins
installable in a separate package.
You may also pass CMake options
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so
user get a hint of which package they need to install when GDAL detects
that a file may be opened by a plugin which is not available on the file
system but known to have been built as a plugin. Cf
https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
for more details.

For end-users, the following utilities have been updated to use a new
argument parsing framework: gdaladdo, gdalinfo, gdal_translate,
gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo,
ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that
should be specified once (where generally the last instance was the one
used). While we have tried to retain backwards compatibility for nominal
use cases, obviously if you have scripts that accidentally specify an
argument several times whereas it should be specified at most once, they
will have to be corrected.

Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has been
created. All bugfixes for 3.9 should be backported into it.

Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even


--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Sean Gillies via gdal-dev]

Hi Even,

Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.

Metadata output of gdalinfo has changed. As soon as there are docker images
I'll look more closely at this.

Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a
RGB.byte.tif.msk
file:
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231
.

The text of an error message which was "tests/data/corrupt.tif, band 1:
IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed."
in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset
1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we
can adjust Rasterio's test.

Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems to
have changed:
https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287.
I'm not entirely sure what the intent is in Rasterio's test, will dig into
that. I just wanted to say that I see a change in GDAL.


On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md
>
> For packagers,
> https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may
> make it more attractive to build some drivers that typically have heavy
> dependencies as plugins, installable in separate packages, due to the
> load time penalty having being improved. It is let to the appreciation
> of packagers to decide which drivers are worth building as plugins
> installable in a separate package.
> You may also pass CMake options
> ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so
> user get a hint of which package they need to install when GDAL detects
> that a file may be opened by a plugin which is not available on the file
> system but known to have been built as a plugin. Cf
>
> https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
> for more details.
>
> For end-users, the following utilities have been updated to use a new
> argument parsing framework: gdaladdo, gdalinfo, gdal_translate,
> gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo,
> ogr2ogr, sozip.
> This helps detecting errors such as specifying twice an argument that
> should be specified once (where generally the last instance was the one
> used). While we have tried to retain backwards compatibility for nominal
> use cases, obviously if you have scripts that accidentally specify an
> argument several times whereas it should be specified at most once, they
> will have to be corrected.
>
> Docker images with 3.9.0beta1 are currently cooking.
>
> master is now marked as 3.10.0dev, and the release/3.9 branch has been
> created. All bugfixes for 3.9 should be backported into it.
>
> Source snapshots at:
>
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
> - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip
>
> Autotest snapshots:
>
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip
>
> Even
>
>

-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Andrew C Aitchison via gdal-dev]

On Mon, 22 Apr 2024, Raley, Nathan via gdal-dev wrote:


Hmm, good catch.  Looking at the stats for the red band:

Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray
 Min=130.000 Max=36265.000
 Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933
 NoData Value=0
 Metadata:
   STATISTICS_MAXIMUM=36265
   STATISTICS_MEAN=10415.961859513
   STATISTICS_MINIMUM=130
   STATISTICS_STDDEV=3502.9325925887
   STATISTICS_VALID_PERCENT=49

So, is there no way to actually do this via command line, or am I going to have 
to write a python lib to actually read through these and determine what they 
should be scaled to?


There is gdal_transform -scale (and -scale_2 etc.)

What are you going to do with the resulting file ?
QGIS allows you to make these sorts of adjustments at view-time.

Remember that the max and min values present in an image may not represent
the full range and the next-door image may have a larger or smaller range
(or just a shifted range). Imagine a row of three tiles; the middle on on 
the edge of a glacier, the first entirely on the glacier and the last 
entirely off the glacier. You may wish to apply the same scaling to all 
three.



From: Daniel Evans 
Sent: Monday, April 22, 2024 9:29 AM
To: Raley, Nathan 
Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Subject: [External] Re: [gdal-dev] Question on building multi band composite 
and going back to RGB GeoTiff

Hi Nathan, My initial suspicion might just be that the scaling the data 
provider did to go from the raw data to a human-eye-friendly RGB composite 
isn't the conversion you're assuming. I know that with the data I regularly 
work with,

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did to go 
from the raw data to a human-eye-friendly RGB composite isn't the conversion 
you're assuming.

I know that with the data I regularly work with, it may be provided as Uint16, 
but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB composite, 
do they appear to match the conversion you're assuming, or is there a different 
scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:
I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I’m missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I’m 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan


This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its 

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Raley, Nathan via gdal-dev]

Hmm, good catch.  Looking at the stats for the red band:

Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray
  Min=130.000 Max=36265.000
  Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933
  NoData Value=0
  Metadata:
STATISTICS_MAXIMUM=36265
STATISTICS_MEAN=10415.961859513
STATISTICS_MINIMUM=130
STATISTICS_STDDEV=3502.9325925887
STATISTICS_VALID_PERCENT=49

So, is there no way to actually do this via command line, or am I going to have 
to write a python lib to actually read through these and determine what they 
should be scaled to?

From: Daniel Evans 
Sent: Monday, April 22, 2024 9:29 AM
To: Raley, Nathan 
Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Subject: [External] Re: [gdal-dev] Question on building multi band composite 
and going back to RGB GeoTiff

Hi Nathan, My initial suspicion might just be that the scaling the data 
provider did to go from the raw data to a human-eye-friendly RGB composite 
isn't the conversion you're assuming. I know that with the data I regularly 
work with,

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did to go 
from the raw data to a human-eye-friendly RGB composite isn't the conversion 
you're assuming.

I know that with the data I regularly work with, it may be provided as Uint16, 
but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB composite, 
do they appear to match the conversion you're assuming, or is there a different 
scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:
I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I’m missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I’m 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan


This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

This is not a direct answer but maybe you’d be interested in this Julia package 
that addresses for example the automatic histogram stretching needed to produce 
nice true color images. Its target is Landsat and Sentinel data but there is 
nothing(?) that prevents it to work with data from other proveniences. Lots of 
GDAL work under the hood.

https://www.generic-mapping-tools.org/RemoteS.jl/dev/gallery/L8cube_img/remotes_L8_cube_img/

From: gdal-dev  On Behalf Of Daniel Evans via 
gdal-dev
Sent: Monday, April 22, 2024 3:29 PM
To: Raley, Nathan 
Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Subject: Re: [gdal-dev] Question on building multi band composite and going 
back to RGB GeoTiff

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did to go 
from the raw data to a human-eye-friendly RGB composite isn't the conversion 
you're assuming.

I know that with the data I regularly work with, it may be provided as Uint16, 
but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB composite, 
do they appear to match the conversion you're assuming, or is there a different 
scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:
I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I’m missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I’m 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan


This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

[Daniel Evans via gdal-dev]

Hi Joe,

Now you've pointed them out, I do see those little bits in the north east.
I hadn't zoomed in enough on the right area. Sadly, I've not much advice to
offer on whether it's expected, and/or how to avoid it.

(Apologies for the slow and unhelpful reply!)

Cheers,
Daniel

On Thu, 18 Apr 2024, 19:02 Joseph McGlinchy, 
wrote:

> Hi Daniel,
>
> Thank you.  I tried your commands exactly with gdal 3.8.3 and am seeing
> the odd type of output I was describing in the northeastern most reaches of
> the images. Would you be willing to verify if you see that or not?
>
> Here is the result of the debug messaging. I think a screenshot which
> shows what I see results in the message being over the size limit.
>
> GDAL: GDALOpen(../manyPts4000_SRTM_test_NptRPC.tiff, this=0x5584b5c21370)
> succeeds as GTiff.
> GDAL: GDALOpen(output_gdal38.tiff, this=0x5584b5c4c950) succeeds as GTiff.
> GDALWARP: Defining SKIP_NOSOURCE=YES
> Processing ../manyPts4000_SRTM_test_NptRPC.tiff [1/1] : 0WARP: Copying
> metadata from first source to destination dataset
> WARP: Set SOURCE_EXTRA=5 warping options due to RPC warping
> WARP: Set SAMPLE_STEPS=ALL warping options due to RPC DEM warping
> GDAL: GDALOpen(srtm_12_05.tif, this=0x5584b5c522a0) succeeds as GTiff.
> RPC: Short-circuiting coordinate transformation from DEM SRS to WGS 84 due
> to apparent nop
> GDAL: GDAL_CACHEMAX = 1504 MB
> GTiff: ScanDirectories()
> GDAL: GDALDefaultOverviews::OverviewScan()
> Using internal nodata values (e.g. 0) for image
> ../manyPts4000_SRTM_test_NptRPC.tiff.
> WARP: band=0 dstNoData=0.00
> RPC: Failed Iterations 101: Got: -121.6743548438707,37.81305392714289
>  Offset=0.200509,-7.35862
> WARP: At least one point failed after direct transform
> RPC: Failed Iterations 101: Got: -121.6743548438707,37.81305392714289
>  Offset=0.200509,-7.35862
> RPC: Failed Iterations 101: Got: -121.6756957607436,37.81515846637773
>  Offset=-0.0317686,-12.1573
> RPC: Failed Iterations 101: Got: -121.6759688314497,37.81397923057818
>  Offset=-0.0782949,-21.942
> RPC: Failed Iterations 101: Got: -121.6760567085541,37.81393132082147
>  Offset=-0.0200723,-13.2144
> RPC: Failed Iterations 101: Got: -121.6758750148136,37.8150256294207
>  Offset=0.0121725,-8.26664
> RPC: Failed Iterations 101: Got: -121.6758055299304,37.81513471897441
>  Offset=0.042,-9.29081
> RPC: Failed Iterations 101: Got: -121.6757471773221,37.81517816256341
>  Offset=0.00786933,-9.66179
> RPC: Failed Iterations 101: Got: -121.6757610763044,37.81516845364766
>  Offset=0.00852169,-9.58453
> GDAL: GDALSuggestedWarpOutput(): 1 out of 3249 points failed to transform.
> GDAL: GDALWarpKernel()::GWKNearestShort() Src=0,0,2383x2800
> Dst=0,0,2411x3318
> ...10...20...30...40...50GDAL: GDALWarpKernel()::GWKNearestShort()
> Src=1710,0,1460x1401 Dst=2411,0,1205x1659
> ...60GDAL: GDALWarpKernel()::GWKNearestShort() Src=2833,0,1263x2458
> Dst=3616,0,1206x829
> ...GDAL: GDALWarpKernel()::GWKNearestShort() Src=2995,148,1101x1054
> Dst=3616,829,1206x830
> 70..GDAL: GDALWarpKernel()::GWKNearestShort() Src=2036,993,2060x1807
> Dst=2411,1659,2411x1659
> .80...90...100 - done.
> GDAL: GDALClose(srtm_12_05.tif, this=0x5584b5c522a0)
> GDAL: Flushing dirty blocks:
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> GDAL: GDALClose(output_gdal38.tiff, this=0x5584b5c4c950)
> GDAL: GDALClose(../manyPts4000_SRTM_test_NptRPC.tiff, this=0x5584b5c21370)
> --
> *From:* Daniel Evans 
> *Sent:* Thursday, April 18, 2024 9:03 AM
> *To:* Joseph McGlinchy 
> *Cc:* Even Rouault ; gdal-dev@lists.osgeo.org
> 
> *Subject:* Re: [gdal-dev] gdalwarp with RPCs causing bogus output
>
> Hi Joe,
>
> My minimal change is just to add the missing "RPC_DEM=srtm_12_05.tif" and
> remove the "RPC_HEIGHT=350". RPC_HEIGHT appears to override the use of any
> supplied DEM, and the docs at least hint that this is the expected
> behaviour.
>
> ```
> gdalwarp --config CPL_DEBUG ON \
> -t_srs EPSG:32610 \
> -rpc \
> -to "RPC_DEM_SRS=+proj=longlat +datum=WGS84 +no_def" \
> -to "RPC_DEM_MISSING_VALUE=0.001" \
> -to "RPC_FOOTPRINT='POLYGON ((-123.12941327726458 38.01872167010621,
> -121.67068342817124 37.82615456858018, -121.87575337280391
> 37.11164114368971, -123.32135086275996 37.30124603928108,
> -123.12941327726458 38.01872167010621))'" \
> -to "RPC_MAX_ITERATIONS=101" \
> -to "RPC_DEM=srtm_12_05.tif" \
> manyPts4000_SRTM_test_NptRPC.tiff \
> output.tiff
> ```
>
> Changing to "RPC_DEM_SRS=EPSG:4326+5773" as Even suggested gives a
> noticeable change around the DEM locations of dams and lakes with the
> updated CRS, e.g. west and north of Livermore CA. Whether that's an
> improvement, or an undesired change due to the DEM being treated
> differently between generating the RPCs and using them, I'm not sure!
>
> Daniel
>
> On Thu, 18 Apr 2024 at 15:39, Joseph McGlinchy 
> wrote:
>
> Hi Daniel,
>
> Thanks for trying with the data! I appreciate that. The gdal command I
> provided 

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Daniel Evans via gdal-dev]

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did
to go from the raw data to a human-eye-friendly RGB composite isn't the
conversion you're assuming.

I know that with the data I regularly work with, it may be provided as
Uint16, but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB
composite, do they appear to match the conversion you're assuming, or is
there a different scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> I currently have a RGB geotiff composite image that has a Byte datatype.
> I also have individual band images for R, G, Redge, and NIR that are UInt16
> datatypes.  Since I’m missing the Blue band from the individual bands, I
> was attempting to extract the blue band from the RGB composite image, scale
> it up to the UInt16 datatype, and build a composite VRT with R, G, B, NIR,
> RE bands included in it.  I was then attempting to extract the RGB bands
> from the multispec VRT in order to see if the process was working as
> intended, but I’m getting an extremely blue image.
>
> Can anyone shed some light as to what I may be doing wrong here?
>
> I started by building a VRT for each band:
>
> gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0
> 65535
>
> gdalbuildvrt -b 1 r.vrt source_R.tif
> gdalbuildvrt -b 1 g.vrt source_G.tif
> gdalbuildvrt -b 1 nir.vrt source_NIR.tif
> gdalbuildvrt -b 1 re.vrt source_RE.tif
>
>
>
> I then merged the VRTs:
>
> gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt
>
>
>
> I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a
> UInt16 datatype.
>
>
>
> Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with
> something like:
>
> gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co
> PHOTOMETRIC=RGB multispec.vrt multispec.tif
>
>
>
> Viewing the result in QGIS appears overly blue.  What am I doing wrong
> here?
>
>
>
> Thanks,
>
> Nathan
>
>
> --
> This email transmission, including any attachments, is intended solely for
> the addressee named above, and may contain confidential or privileged
> information. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender immediately by reply email and destroy the message and its
> attachments.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Raley, Nathan via gdal-dev]

I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I'm missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I'm 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan

This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

Robert,

If you want to use ready-made binaries, then using Conda gdal-master 
builds might be the easiest way for all major platforms: 
https://gdal.org/download.html#gdal-master-conda-builds . They track 
gdal master, but that's more or less the same as 3.9.0beta1 right now.


Otherwise if you want to build from source, you can take inspiration 
from the build recipe we use for continuous integration:


https://github.com/OSGeo/gdal/blob/master/.github/workflows/ubuntu_22.04/Dockerfile.ci
https://github.com/OSGeo/gdal/blob/master/.github/workflows/ubuntu_22.04/build.sh

(you don't necessarily need all the dependencies)

And as I mentioned, Docker images are building. Should be ready by tomorrow.

Even

Le 22/04/2024 à 15:18, Robert Hewlett via gdal-dev a écrit :
Any advice on how to become a tester such as testing on prefered OS 
and setup?


I have access to a proxmox server but I usually stick to LINUX OSes.

Or is at easy as following the notes here:
https://gdal.org/development/dev_environment.html

Ubuntu 22.x is the goto right now.

Any advice would be appreciated.

Rob


On Mon, Apr 22, 2024 at 5:12 AM Even Rouault via gdal-dev 
 wrote:


Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early
testers.

The NEWS file is here:

https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers,
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html
may
make it more attractive to build some drivers that typically have
heavy
dependencies as plugins, installable in separate packages, due to the
load time penalty having being improved. It is let to the
appreciation
of packagers to decide which drivers are worth building as plugins
installable in a separate package.
You may also pass CMake options
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so
user get a hint of which package they need to install when GDAL
detects
that a file may be opened by a plugin which is not available on
the file
system but known to have been built as a plugin. Cf

https://gdal.org/development/building_from_source.html#deferred-loaded-plugins

for more details.

For end-users, the following utilities have been updated to use a new
argument parsing framework: gdaladdo, gdalinfo, gdal_translate,
gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo,
ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that
should be specified once (where generally the last instance was
the one
used). While we have tried to retain backwards compatibility for
nominal
use cases, obviously if you have scripts that accidentally specify an
argument several times whereas it should be specified at most
once, they
will have to be corrected.

Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has
been
created. All bugfixes for 3.9 should be backported into it.

Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even

-- 
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 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

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

[Robert Hewlett via gdal-dev]

Any advice on how to become a tester such as testing on prefered OS and
setup?

I have access to a proxmox server but I usually stick to LINUX OSes.

Or is at easy as following the notes here:
https://gdal.org/development/dev_environment.html

Ubuntu 22.x is the goto right now.

Any advice would be appreciated.

Rob


On Mon, Apr 22, 2024 at 5:12 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md
>
> For packagers,
> https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may
> make it more attractive to build some drivers that typically have heavy
> dependencies as plugins, installable in separate packages, due to the
> load time penalty having being improved. It is let to the appreciation
> of packagers to decide which drivers are worth building as plugins
> installable in a separate package.
> You may also pass CMake options
> ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so
> user get a hint of which package they need to install when GDAL detects
> that a file may be opened by a plugin which is not available on the file
> system but known to have been built as a plugin. Cf
>
> https://gdal.org/development/building_from_source.html#deferred-loaded-plugins
> for more details.
>
> For end-users, the following utilities have been updated to use a new
> argument parsing framework: gdaladdo, gdalinfo, gdal_translate,
> gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo,
> ogr2ogr, sozip.
> This helps detecting errors such as specifying twice an argument that
> should be specified once (where generally the last instance was the one
> used). While we have tried to retain backwards compatibility for nominal
> use cases, obviously if you have scripts that accidentally specify an
> argument several times whereas it should be specified at most once, they
> will have to be corrected.
>
> Docker images with 3.9.0beta1 are currently cooking.
>
> master is now marked as 3.10.0dev, and the release/3.9 branch has been
> created. All bugfixes for 3.9 should be backported into it.
>
> Source snapshots at:
>
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
> - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip
>
> Autotest snapshots:
>
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip
>
> Even
>
> --
> 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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.9.0beta1 available for testing

[Even Rouault via gdal-dev]

Hi,

I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.

The NEWS file is here:

  https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md

For packagers, 
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may 
make it more attractive to build some drivers that typically have heavy 
dependencies as plugins, installable in separate packages, due to the 
load time penalty having being improved. It is let to the appreciation 
of packagers to decide which drivers are worth building as plugins 
installable in a separate package.
You may also pass CMake options 
([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so 
user get a hint of which package they need to install when GDAL detects 
that a file may be opened by a plugin which is not available on the file 
system but known to have been built as a plugin. Cf 
https://gdal.org/development/building_from_source.html#deferred-loaded-plugins 
for more details.


For end-users, the following utilities have been updated to use a new 
argument parsing framework: gdaladdo, gdalinfo, gdal_translate, 
gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, 
ogr2ogr, sozip.
This helps detecting errors such as specifying twice an argument that 
should be specified once (where generally the last instance was the one 
used). While we have tried to retain backwards compatibility for nominal 
use cases, obviously if you have scripts that accidentally specify an 
argument several times whereas it should be specified at most once, they 
will have to be corrected.


Docker images with 3.9.0beta1 are currently cooking.

master is now marked as 3.10.0dev, and the release/3.9 branch has been 
created. All bugfixes for 3.9 should be backported into it.


Source snapshots at:

- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz
- https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip

Autotest snapshots:

- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
- https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip

Even

--
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] Issue with 3D GeoJSON to 3D DXF Conversion

[Rahkonen Jukka via gdal-dev]

Hi,

By reading the documentation 
https://gdal.org/drivers/vector/dxf.html#dxf-writer what you see is expected. 
--config DXF_WRITE_HATCH FALSE is writing polylines and polylines have vertices 
with different Z coordinates. --config DXF_WRITE_HATCH TRUE writes polygons. 
The polygons have same elevation value at each vertex, and that is also 
documented:
“You may need to do this [to use DXF_WRITE_HATCH FALSE] if your geometries do 
not have a constant elevation, as the DXF HATCH entity cannot represent such 
geometries.”

-Jukka Rahkonen-



Lähettäjä: gdal-dev  Puolesta Shahrukh Mirza 
Nawandish via gdal-dev
Lähetetty: maanantai 22. huhtikuuta 2024 13.26
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Issue with 3D GeoJSON to 3D DXF Conversion

Dear GDAL Team,

I hope this email finds you well. I'm encountering an issue converting 3D 
GeoJSON polygons to DXF format using ogr2ogr. During conversion, the elevation 
data becomes uniform for all points within the polygon. Additionally, when 
using "DXF_WRITE_HATCH," the geometry becomes a polyline instead of a polygon.

Attached are the GeoJSON data and conversion code for your reference. Could you 
please assist in resolving this discrepancy?
ogr2ogr -f "DXF" output.dxf input.geojson -t_srs EPSG:32737 --config 
DXF_WRITE_HATCH FALSE


Thank you for your attention to this matter.

--
Saygılarımla / Kind Regards

Shahrukh Mirza NAWANDISH
Havacılık Bilgi Sistemleri / Aeronautical Information Systems
Yazılım Geliştirme Uzm. Yrd. / Software Development Assist. Specialist
Bilgisayar Programcısı / Computer Programmer MCA

T:+90 312 266 66 98
M:+90 538 519 72 67
 E:mirza.nawand...@haritaevi.com
▶: Ankara-Istanbul-Bucharest
www.haritaevi.com
www.obstacleanalyze.com
www.aixm.haritaevi.com
www.aerodatamarket.com
[https://avatars.mds.yandex.net/get-mail-signature/2434044/d24bf65965f2be07edc47ff3c25b0348/orig][https://avatars.mds.yandex.net/get-mail-signature/200369/c75763261eac7fb671922d147573080b/orig][https://avatars.mds.yandex.net/get-mail-signature/2434044/1cd6e615d44979bf9b0d6b0ea9c47182/orig][https://avatars.mds.yandex.net/get-mail-signature/232821/ec6941b191f27730d3a5f92fd846beb4/orig][https://avatars.mds.yandex.net/get-mail-signature/232821/0545b2da2dc9f49f532774615ec45e51/orig][https://www.haritaevi.com/wp-content/uploads/2022/02/disclaimer_1.png]
 
[https://avatars.mds.yandex.net/get-mail-signature/2434044/58c47a3a908e28fdb209656734002f36/orig]
  
[https://avatars.mds.yandex.net/get-mail-signature/2423644/1ccfc2184635533811e43aeeae4bf6c1/orig]
  
[https://avatars.mds.yandex.net/get-mail-signature/2423644/405b95fb41fb8db77dcee35ff542f333/orig]
  
[https://avatars.mds.yandex.net/get-mail-signature/1539903/c89e02562564f32028015473ea475742/orig]
 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Issue with 3D GeoJSON to 3D DXF Conversion

[Shahrukh Mirza Nawandish via gdal-dev]

Dear GDAL Team, I hope this email finds you well. I'm encountering an issue converting 3D GeoJSON polygons to DXF format using ogr2ogr. During conversion, the elevation data becomes uniform for all points within the polygon. Additionally, when using "DXF_WRITE_HATCH," the geometry becomes a polyline instead of a polygon. Attached are the GeoJSON data and conversion code for your reference. Could you please assist in resolving this discrepancy?ogr2ogr -f "DXF" output.dxf input.geojson -t_srs EPSG:32737 --config DXF_WRITE_HATCH FALSE  Thank you for your attention to this matter. -- Saygılarımla / Kind Regards Shahrukh Mirza NAWANDISHHavacılık Bilgi Sistemleri / Aeronautical Information SystemsYazılım Geliştirme Uzm. Yrd. / Software Development Assist. SpecialistBilgisayar Programcısı / Computer Programmer MCA T:+90 312 266 66 98M:+90 538 519 72 67 E:mirza.nawand...@haritaevi.com▶: Ankara-Istanbul-Bucharestwww.haritaevi.comwww.obstacleanalyze.comwww.aixm.haritaevi.comwww.aerodatamarket.com  

input.geojson
Description: application/json
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev