Re: [gdal-dev] gdal_translate

Yes, you can use gdal_edit -gcp to add some GCPs, then gdalwarp -tps to straighten out the image. QGIS has a tool to do this interactively, but last time I tried it, it somewhat buggy and confusing. Laurentiu On Tue, Oct 15, 2024, at 16:54, Paul via gdal-dev wrote: > Is there a way to transfor

[gdal-dev] gdal_translate

Is there a way to transform a raster file with selected points other then ulx, uly, lrx and lry in Gdal? I would like to select some distinct pixels in the raster file and connect them to coordinates in my map and then translate. Kind regards, Paul ___

[gdal-dev] gdal_translate -expand rgba behaving incorrectly, pct2rgb.py working correctly on a tif

Hi, I am processing a bunch of tifs where the gdal_translate and pct2rgb.py seem to be behaving differently. Is it a bug in gdal_translate, or I need to pass some options to get correct behavior. gdal_translate -expand rgba a.tif gdalbad.tif # This produces a tif file with _incorrect_ colors. p

Re: [gdal-dev] gdal_translate shifted values

Indeed, good catch, I exported both of them to a new file and it's obvious now: Laurentiu On Thu, Feb 1, 2024, at 15:22, Even Rouault wrote: > Hi, > > I don't think there's any problem regarding GDAL vs xarray. It is just a > difference of convention on how GDAL and xarray choose the origin of

Re: [gdal-dev] gdal_translate shifted values

Hi, I don't think there's any problem regarding GDAL vs xarray. It is just a difference of convention on how GDAL and xarray choose the origin of rasters. GDAL selects the northern-west corner as the (0,0) image coordinate. The line in GDAL that contains values 13.75 14.25 14.75 which are at

Re: [gdal-dev] gdal_translate shifted values

It's actually pretty easy to test: import numpy as np import xarray as xr from osgeo import gdal xarray_ds = xr.load_dataset("st4_pr.2017092016.01h", engine="cfgrib") # GDAL uses as NODATA xarray_data = np.nan_to_num(xarray_ds.tp.data, nan=.0) gdal_ds = gdal.Open("st4_pr.2017092016.01h")

Re: [gdal-dev] gdal_translate shifted values

>From the R code snippet I see: "Surprisingly, the value 9.75 is shifted to >106, 86 = 105,85 in Python indexing", but R is 1-base and Python 0-base. In R: > library(terra) terra 1.7.71 > gdal() [1] "3.8.3" > a <- rast("attachment.obj") > b <- rast("st4_pr.2017092016.01h.tif") > a class : S

Re: [gdal-dev] gdal_translate shifted values

les are identical. All I > can conclude is that gdal_compare and your R script are doing something in > different ways. > > -Jukka Rahkonen- > > *Lähettäjä:* gdal-dev *Puolesta *Furuya, > Takahiro via gdal-dev > *Lähetetty:* torstai 1. helmikuuta 2024 1.53 > *Vastaanottaja:*

Re: [gdal-dev] gdal_translate shifted values

s. -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Furuya, Takahiro via gdal-dev Lähetetty: torstai 1. helmikuuta 2024 1.53 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] gdal_translate shifted values Hi gdal-dev, I am Takahiro, a student who is using gdal_translate. I have an issue with gdal

Re: [gdal-dev] gdal_translate shifted values

I'd check both files *before* all the processing. Something like: gdallocationinfo -l_srs EPSG:4326 gribFile -110 40 gdallocationinfo -l_srs EPSG:4326 tiffFile -110 40 That will tell narrow it down. On 1/31/24 15:53, Furuya, Takahiro via gdal-dev wrote: Hi gdal-dev, I am Takahiro, a student

[gdal-dev] gdal_translate shifted values

Hi gdal-dev, I am Takahiro, a student who is using gdal_translate. I have an issue with gdal_translate and would like to ask a question. I used gdal_translate to transform a NCEP GRIB file (downloadable from https://data.eol.ucar.edu/cgi-bin/codiac/fgr_form/id=21.093, or attached to this email) t

Re: [gdal-dev] gdal_translate tiff to netcdf

It sounds like the install wasn't built with libnetCDF. Try this: gdalinfo --formats If it's part of your install you'll see it. On 6/20/23 16:37, Abigaïl Dah wrote: Hello, I am trying to convert a file with the format GEOTIFF to netcdf using the command line: gdal_translate -of NetCDF

[gdal-dev] gdal_translate tiff to netcdf

Hello, I am trying to convert a file with the format GEOTIFF to netcdf using the command line: gdal_translate -of NetCDF However, I get the following error message: Output driver `NetCDF' not recognised. Would you know what's wrong and how to fix this? Thanks in advance, Best, Abigail _

Re: [gdal-dev] gdal_translate drops XMP exif tags

; - ANTOINE DE SAINT-EXUPERY "Wind, Sand, and Stars" (1939) - Original Message - From: "Even Rouault" To: "Tom O'Reilly" Cc: "gdal-dev" Sent: Monday, August 8, 2022 1:37:03 PM Subject: Re: [gdal-dev] gdal_translate drops XMP exif tags >

Re: [gdal-dev] gdal_translate drops XMP exif tags

T-EXUPERY > "Wind, Sand, and Stars" (1939) > > > -- > *From: *"Javier Jimenez Shaw" > *To: *"Tom O'Reilly" > *Cc: *"gdal-dev" > *Sent: *Monday, August 8, 2022 12:03:39 PM > *Subject: *Re: [gd

Re: [gdal-dev] gdal_translate drops XMP exif tags

nd, and Stars" (1939) - Original Message - From: "Even Rouault" To: "Tom O'Reilly" , "gdal-dev" Sent: Monday, August 8, 2022 12:13:03 PM Subject: Re: [gdal-dev] gdal_translate drops XMP exif tags Tom, It would be interesting if you could provide an image how to

Re: [gdal-dev] gdal_translate drops XMP exif tags

Kopio: gdal-dev Aihe: Re: [gdal-dev] gdal_translate drops XMP exif tags Hi Evan, I was mistaken in which gdal program drops the XMP tags. gdal_translate actually transfers the XMP tags properly from the input jpg file to tif output. But a subsequent gdalwarp on that tif does not pass the XMP ta

Re: [gdal-dev] gdal_translate drops XMP exif tags

the great mysteries of nature, but plunges us more deeply into them." - ANTOINE DE SAINT-EXUPERY "Wind, Sand, and Stars" (1939) From: "Javier Jimenez Shaw" To: "Tom O'Reilly" Cc: "gdal-dev" Sent: Monday, August 8, 2022 12:03:39 PM Subjec

Re: [gdal-dev] gdal_translate drops XMP exif tags

teries of nature, but plunges us more deeply into them." - ANTOINE DE SAINT-EXUPERY "Wind, Sand, and Stars" (1939) - Original Message - From: "Even Rouault" To: "Tom O'Reilly" , "gdal-dev" Sent: Monday, August 8, 2022 12:13:03 P

Re: [gdal-dev] gdal_translate drops XMP exif tags

Tom, It would be interesting if you could provide an image how to reproduce that With the sample file from the autotest suite, I can't reproduce that: $ gdal_translate ../autotest/gdrivers/data/jpeg/byte_with_xmp.jpg out.tif $ gdalinfo out.tif -mdd all Driver: GTiff/GeoTIFF Files: out.tif Siz

Re: [gdal-dev] gdal_translate drops XMP exif tags

Which version of GDAL are you using? in https://gdal.org/programs/gdal_translate.html there is an option, "-noxmp", since GDAL 3.2. Without that option it should keep them. If I remember correctly, the XMP tags are copied as proper XMP, not as GDALMetadata, with TIFF files. An example with "gdalin

[gdal-dev] gdal_translate drops XMP exif tags

gdal_translate output .tif file does not contain XMP tags that were present in the input .jpg file. The output file contains many of the input EXIF tags, aggregated as the GDALMetadata tag, but not the XMP tags. Why does gdal_translate remove XMP tags - is there an option to preserve them? Th

Re: [gdal-dev] gdal_translate wmts.xml wmts.tif: 0ERROR 4: ./gdalwmscache\xyz: No such file or directory; ERROR 1: GDALWMS: Unable to open downloaded block.

Rahkonen Jukka:   >So the error seems to be due to error in GetCapabilities that claims that zoom >level 20 is supported. You can get image data by selecting the zoom >level >manually with an open option "zoom_level". >gdal_translate bmortho77.xml bmortho77.tif -oo zoom_level=12 --debug on than

Re: [gdal-dev] gdal_translate wmts.xml wmts.tif: 0ERROR 4: ./gdalwmscache\xyz: No such file or directory; ERROR 1: GDALWMS: Unable to open downloaded block.

sta Helmut Kudrnovsky Lähetetty: maanantai 1. elokuuta 2022 19.04 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] gdal_translate wmts.xml wmts.tif: 0ERROR 4: ./gdalwmscache\xyz: No such file or directory; ERROR 1: GDALWMS: Unable to open downloaded block. Hi GDAL community, I have an GDA

[gdal-dev] gdal_translate wmts.xml wmts.tif: 0ERROR 4: ./gdalwmscache\xyz: No such file or directory; ERROR 1: GDALWMS: Unable to open downloaded block.

Hi GDAL community, I have an GDAL_WMTS XML file containing the information for: https://www.basemap.at/wmts/1.0.0/WMTSCapabilities.xmlbmaporthofoto30cmnormalgoogle385710719646000873107344559993854true204,404true When I'm opening the xml file in QGIS, the correct tile defined above in the XML wi

Re: [gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

Matt, The output of gdalinfo that matters here was the one on the subdataset you transform, so gdalinfo NETCDF:"./test.nc":analysed_sst I've a very poor Internet connection for the next 10 days so can't download the full .nc file yet, but from the .ncdump file you provided, I believe I mana

Re: [gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

Hi Even, > I have run this command with gdal 3.4.3 and gdal 3.5.1 and get different > output files. Can you compare the output of the two versions of gdalinfo ? This should determine whether the difference is when reading or writing. Good idea, I did that and there is no difference in the output

Re: [gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

Le 27/07/2022 à 17:03, Matthew Savoie a écrit : Hi Andrew, > I have run this command with gdal 3.4.3 and gdal 3.5.1 and get different output files. Can you compare the output of the two versions of gdalinfo ? This should determine whether the difference is when reading or writing. Good ide

Re: [gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

Hi Andrew, > I have run this command with gdal 3.4.3 and gdal 3.5.1 and get different > output files. Can you compare the output of the two versions of gdalinfo ? This should determine whether the difference is when reading or writing. Good idea, I did that and there is no difference in the outp

Re: [gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

On Tue, 26 Jul 2022, Matthew Savoie wrote: Hi all, I have noticed a difference in the output of gdal_translate between GDAL 3.4.3 and 3.5.1 and I can't see in the changelog that I should see a difference. This is just a request to see if I missed something or if there might be change not descri

[gdal-dev] gdal_translate differences between versions 3.4.3 and 3.5.1?

Hi all, I have noticed a difference in the output of gdal_translate between GDAL 3.4.3 and 3.5.1 and I can't see in the changelog that I should see a difference. This is just a request to see if I missed something or if there might be change not described in gdal_translate between versions 3.4.3 a

[gdal-dev] gdal_translate options

Hi List, We use GDAL3+ with MapWinGIS (C++ ActiveX control) and I'm working on making unit/functional tests for it. In one of our functions, we use GDALTranslate(). I'm creating the unit tests in C#: We pass the options as a string array to our C++ function, which expects SAFEARRAY* This one is

Re: [gdal-dev] Gdal_translate into HDF4 fails

Cool, i tired and actually works, but just a question, is it normal that using gdal_translate -of netCDF -co FORMAT=NC4 the resulting image is rotated by 180° (Upside down)? Thanks Il giorno ven 18 feb 2022 alle ore 15:39 Even Rouault < even.roua...@spatialys.com> ha scritto: > if you gdal_trans

Re: [gdal-dev] Gdal_translate into HDF4 fails

if you gdal_translate -of netCDF -co FORMAT=NC4 , the resulting netCDF file will actually be a HDF5 file (with netCDF "decorations"): - https://gdal.org/drivers/raster/netcdf.html#creation-options - https://www.unidata.ucar.edu/software/netcdf/docs/interoperability_hdf5.html Le 18/02/2022 à

Re: [gdal-dev] Gdal_translate into HDF4 fails

: Open() - Open existing dataset. -Jukka Rahkonen- Lähettäjä: Lorenzo Di Giacomo Lähetetty: perjantai 18. helmikuuta 2022 16.24 Vastaanottaja: Even Rouault Kopio: Rahkonen Jukka (MML) ; 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) Aihe: Re: [gdal-dev] Gdal_translate into

Re: [gdal-dev] Gdal_translate into HDF4 fails

Hi guys, i was reading the question and i was wondering if it's possibile do the same translate operation with HDF5, like: gdal_translate -of HDF5Image 3band.tif out.h5, i tried but doesn't work and says " HDF5 driver has no creation capabilities." Thanks _

Re: [gdal-dev] Gdal_translate into HDF4 fails

yes, this is sluggish . I just converted a 18002x22000 byte 3-band dataset in 28 minutes. Le 18/02/2022 à 13:44, Rahkonen Jukka (MML) a écrit : More information, probably it does not fail but it is extremely slow. After 15 minutes I am now at this stage gdal_translate -of HDF4Image 3band.ti

Re: [gdal-dev] Gdal_translate into HDF4 fails

More information, probably it does not fail but it is extremely slow. After 15 minutes I am now at this stage gdal_translate -of HDF4Image 3band.tif out.h4 --debug on GDAL: GDALOpen(3band.tif, this=0215A20D36A0) succeeds as GTiff. Input file size is 12000, 12000 GDAL: QuietDelete(out.h4) invo

[gdal-dev] Gdal_translate into HDF4 fails

Hi, There is a question about HDF4 in https://gis.stackexchange.com/questions/424204/convert-geotiff-to-hdf-using-gdal. I tried the same with GDAL 3.4.0. With a single band image conversion from GeoTIFF into HDF4Image succeeds but with a 3 band image not. I am not sure if it is even supposed to

Re: [gdal-dev] gdal_translate from .nc --> .tif --- issue with coordinates

On Thu, 15 Jul 2021, Hill, David Foster wrote: Hello. I asked this question a few weeks ago, but I think my question was not complete enough, and I also think I did not attach the right files. So, I would like to try again, if that is ok. I note that your earlier message said: The version is:

[gdal-dev] gdal_translate from .nc --> .tif --- issue with coordinates

Hello. I asked this question a few weeks ago, but I think my question was not complete enough, and I also think I did not attach the right files. So, I would like to try again, if that is ok. I have a .nc file. When I do: >>ncdump -c I can inspect the coordinates in the x and y directions. W

[gdal-dev] gdal_translate from .nc --> .tif --- issue with coordinates

Hello. I asked this question a few weeks ago, but I think my question was not complete enough, and I also think I did not attach the right files. So, I would like to try again, if that is ok. I have a .nc file. When I do: >>ncdump -c I can inspect the coordinates in the x and y directions. W

Re: [gdal-dev] gdal_translate - unable to process srs definition....

Not sure but your error " Failed to process SRS definition: ESPG:32612 " looks like a typo - should it be EPSG:32612 Regards On Fri, 2 Jul 2021 at 14:06, Hill, David Foster wrote: > Hi. > > gdal_translate was working great for me for the past two weeks. I would do > commands like: > > > —>fin="

[gdal-dev] gdal_translate - unable to process srs definition....

Hi. gdal_translate was working great for me for the past two weeks. I would do commands like: —>fin="/nfs/depot/cce_u1/hill/dfh/op_snowmodel/wy_snowmodel/ctl_files/wo_assim/$STAMP.nc" —>fout="/nfs/depot/cce_u1/hill/dfh/op_snowmodel/wy_snowmodel/ctl_files/wo_assim/$STAMP.tif" —>gdal_translate -of

Re: [gdal-dev] gdal_translate for nc --> tiff. Coords seem to change?

Apologies, I misread your original question. I don't observe a difference in min x between the .nc file you observe and the .tif I get from gdal_translate. However I see the .tif you uploaded has indeed a difference in x, but it also has a UTM CRS, whereas the original .nc file has no CRS infor

Re: [gdal-dev] gdal_translate for nc --> tiff. Coords seem to change?

As far as I can see, the netCDF driver behaves as designed. It reports as the origin the top-left corner of the raster. Le 28/06/2021 à 22:42, Hill, David Foster a écrit : Here is a link to the .tif: https://drive.google.com/file/d/1ZxNdoURdLZS1HRUQUhF-evD1NpuIDcvk/view?usp=sharing

Re: [gdal-dev] gdal_translate for nc --> tiff. Coords seem to change?

Here is a link to the .tif: https://drive.google.com/file/d/1ZxNdoURdLZS1HRUQUhF-evD1NpuIDcvk/view?usp=sharing And here is a link to the .nc: https://drive.google.com/file/d/1pcXklnup5AxYe3DQfGfsZ3mwwe8WI8mf/v

Re: [gdal-dev] gdal_translate for nc --> tiff. Coords seem to change?

David, providing a link to a such file could be useful for investigation Even Le 28/06/2021 à 20:59, Hill, David Foster a écrit : Hello. I am new to GDAL, and have spent the past two weeks exploring its use for (largely) nc —> tiff conversions. I am puzzled by a few things, however. I have

[gdal-dev] gdal_translate for nc --> tiff. Coords seem to change?

Hello. I am new to GDAL, and have spent the past two weeks exploring its use for (largely) nc —> tiff conversions. I am puzzled by a few things, however. I have a .nc file and when I use >> ncdump -c file.nc the coords are shown to me. The min x is 487200 and the min y is 4690100. The grid s

Re: [gdal-dev] gdal_translate clip PostGIS raster

I had missed something essential and simple ... mode=2 must be added to the end of the PG connection string to tell GDAL to treat a PostGIS raster table as one unit. The default mode=1 treats each tile as a subdataset Sorry for the noise Best regards Andreas Oxenstierna T-Kartor Geospatial AB O

Re: [gdal-dev] gdal_translate clip PostGIS raster

Tested with: 1 … table=rastertable WHERE=rid>0" dest.tif Returns: WHERE=rid>0 has no raster bands 2 … table=rastertable WHERE=rid=1" dest.tif Returns: a valid but empty tif file 3 … table=mailto:andreas.oxenstie...@t-kartor.com> www.t-kartor.com On 11 Ma

Re: [gdal-dev] gdal_translate clip PostGIS raster

Thanks but still stumbling (using 2.3.2) gdalwarp -cutline "PG:dbname=gisdb" -csql 'select * from polytest where id=1' -crop_to_cutline -of GTiff -srcnodata - -dstnodata - "PG: schema=a table=rastertable" dest.tif returns: ERROR 1: Input file has no raster bands. gdalinfo reports that

Re: [gdal-dev] gdal_translate clip PostGIS raster

Try with gdalwarp and the -cutline family of arguments Le 10/05/2021 à 19:23, Andreas Oxenstierna a écrit : Hi list Is it possible to clip a PostGIS raster with a PostGIS vector poly using gdal_translate? I cannot find a working syntax to define the clipping table in the WHERE clause. Eg. t

[gdal-dev] gdal_translate clip PostGIS raster

Hi list Is it possible to clip a PostGIS raster with a PostGIS vector poly using gdal_translate? I cannot find a working syntax to define the clipping table in the WHERE clause. Eg. this returns "Error browsing database for PostGIS Raster properties : ERROR: syntax error at or near "FROM" gda

Re: [gdal-dev] Gdal_translate batch processing

---Original Message- From: gdal-dev On Behalf Of gnihalk Sent: April 29, 2021 5:36 AM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Gdal_translate batch processing *** External email: Do not click on links or attac

[gdal-dev] Gdal_translate batch processing

Hi you all. I have a huge MODIS dataset and I need to translate them to tiff but each data is in a different sub-folder. C:\Users\HP\Desktop\modis\500889913\500889913\88258783\MOD10A2.2016322095024.hdf C:\Users\HP\Desktop\modis\500889913\500889913\96113659\MOD10A2.A2016321.h20v05.00

Re: [gdal-dev] gdal_translate receiving "Warning 6: driver GTiff does not support creation option WEBP_LOSSLESS"

Thanks for the suggestion. I did actually try to create a plain GTiff and tried with the WEBP_LOSSLESS=TRUE and received the same warning. It is strange because it does seem to create a WEBP compressed image (I think), gdalinfo seems to suggest that it is, so maybe I should just ignore the warn

Re: [gdal-dev] gdal_translate receiving "Warning 6: driver GTiff does not support creation option WEBP_LOSSLESS"

Hi, I would also have a try by actually using -co WEBP_LOSSLESS=True even by the error message it is perhaps automatically applied. -Jukka Rahkonen- Marty J. Sullivan wrote > Hello, > > I am attempting to create a COG format GeoTIFF with WEBP_LOSSLESS > compression using GDAL. > > I have comp

[gdal-dev] gdal_translate receiving "Warning 6: driver GTiff does not support creation option WEBP_LOSSLESS"

Hello, I am attempting to create a COG format GeoTIFF with WEBP_LOSSLESS compression using GDAL. I have compiled GDAL 3.2.1 from source with libwebp 0.4.2 installed from Debian Buster repos (I’ve also tried with libwebp v1.1.0 installed from source, no difference). When I run the ./configure s

Re: [gdal-dev] gdal_translate -scale

Hi, Please remember to use reply-to-all for sending a copy to the list as well. -Jukka- -Alkuperäinen viesti- Lähettäjä: jesus.mo...@solute.es Lähetetty: maanantai 14. joulukuuta 2020 14.27 Vastaanottaja: Rahkonen Jukka (MML) Aihe: RE: [gdal-dev] gdal_translate -scale Hi, Thank you

Re: [gdal-dev] gdal_translate -scale

Hi, If your output is 8 bit you can just use -scale without min/max values. From https://gdal.org/programs/gdal_translate.html: "Rescale the input pixels values from the range src_min to src_max to the range dst_min to dst_max. If omitted the output range is 0 to 255. If omitted the input range i

[gdal-dev] gdal_translate -scale

Hello GDAL team and thank you for welcome me. I have an issue with the gdal_translate command. I would like to use the “STATISTICS_MIN” and “STATISTICS_MAX” metadata key values in the -scale parameter of the program, so I don’t need to specify it manually every time I want to scale the output.

Re: [gdal-dev] gdal_translate, exporting "Byte - Eight bit unsigned integer" single band tiff to gpkg using -ot Byte results in 4 bands raster with changed values

It might be good to read also about the open options in https://gdal.org/drivers/raster/gpkg.html "BAND_COUNT=1/2/3/4: Number of bands of the dataset exposed after opening. Some conversions will be done when possible and implemented, but this might fail in some cases, depending on the BAND_COUNT v

Re: [gdal-dev] gdal_translate, exporting "Byte - Eight bit unsigned integer" single band tiff to gpkg using -ot Byte results in 4 bands raster with changed values

On mercredi 2 décembre 2020 15:16:44 CET Nicolas Cadieux wrote: > Hi, > > This follows a discussion in the qgis-user mailing list. We are using > gdal_translate (and QGIS "export as") on a 8bit unsigned single band > tiff to a .gpkg. When using no -ot switch or when using -ot Byte, this > result

[gdal-dev] gdal_translate, exporting "Byte - Eight bit unsigned integer" single band tiff to gpkg using -ot Byte results in 4 bands raster with changed values

Hi, This follows a discussion in the qgis-user mailing list.  We are using gdal_translate (and QGIS "export as") on a 8bit unsigned single band tiff to a .gpkg.  When using no -ot switch or when using -ot Byte, this results in a 4 band .gpkg raster with the wrong values.  (Values in band 1 to

[gdal-dev] gdal_translate resampling introduces bias, gdalwarp does not

Greetings. I have noticed a difference in gdal_translate vs gdalwarp. gdal_translate introduces a slight bias when it resamples. This seems to be reproducible when coarsening resolutions by roughly 5-10 percent. For my specific example, I'm starting with a .5m x .5m UTM image. I've seen this i

Re: [gdal-dev] gdal_translate multiplies bands

Hi, Perhaps it is just about how you open your GeoPackage. See https://gdal.org/drivers/raster/gpkg.html: "Opening options By default, the driver will expose a GeoPackage dataset as a four band (Red,Green, Blue,Alpha) dataset, which gives the maximum compatibility with the various encodings of t

[gdal-dev] gdal_translate multiplies bands

Hi I try to use gdal_translate in my windows command prompt to convert a single band .tif raster to a single band .gpkg. gdal_translate -of GPKG example.tif example.gpkg I always get a .gpkg with four bands and the nodata pixels get changed to a value of 255. I tried all possible combinations

Re: [gdal-dev] gdal_translate into netCDF file will lose some important metadata items such as scale_factor and add_offset

Hi Even, Thanks for such a quick fix! Really really appreciate what you've done for the GDAL community! Zhan. On Mon, Aug 31, 2020 at 8:32 PM Even Rouault wrote: > Zhan, > > > > adding back the list > > > > There was an issue in the writing code of the netCDF driver. It was > supposed suppose

Re: [gdal-dev] gdal_translate into netCDF file will lose some important metadata items such as scale_factor and add_offset

Zhan, adding back the list There was an issue in the writing code of the netCDF driver. It was supposed supposed to copy the offset and scale settings from the source dataset, but there was a logic error. Fixed per https://github.com/OSGeo/gdal/pull/2906 Even > Hi Even, > > Thanks a lot

Re: [gdal-dev] gdal_translate into netCDF file will lose some important metadata items such as scale_factor and add_offset

On lundi 31 août 2020 00:11:54 CEST Zhan Li wrote: > Hi, when I use gdal_translate to convert a raster file (e.g., either GTiff > or VRT) into netCDF format, it always loses some important metadata items > such as scale_factor, add_offset and etc. What am I doing it wrong? Can > anyone help me to s

[gdal-dev] gdal_translate into netCDF file will lose some important metadata items such as scale_factor and add_offset

Hi, when I use gdal_translate to convert a raster file (e.g., either GTiff or VRT) into netCDF format, it always loses some important metadata items such as scale_factor, add_offset and etc. What am I doing it wrong? Can anyone help me to solve this problem? Here I'm using an example NetCDF file f

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

Hi Andy, On Wed, Apr 22, 2020 at 8:33 AM Ritchie, Andrew C wrote: > > > Sorry I should’ve run more tests to clarify the situation re BIGTIFFs. It > looks like gdal_translate honors -co BIGTIFF=NO for the raster but not the > mask. > What's the output size of your COG when it successful complete

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

Palmer Sent: Tuesday, April 21, 2020 2:57 PM To: Even Rouault Cc: Ritchie, Andrew C ; gdal-dev@lists.osgeo.org Subject: [EXTERNAL] Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALY long time to unload. Hi Andrew, On Wed, Apr 22, 2020 at 6:11 AM Ev

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

Hi Andrew, On Wed, Apr 22, 2020 at 6:11 AM Even Rouault wrote: > Andrew, > > > > > When I create a mask band in a large lzw-compressed or jpeg-compressed > tif > > > using the COG driver it dramatically increases processing time over > writing > > > RGBA (hours instead of minutes), so the issue

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

Andrew, > When I create a mask band in a large lzw-compressed or jpeg-compressed tif > using the COG driver it dramatically increases processing time over writing > RGBA (hours instead of minutes), so the issue is not jpeg compression, it's > the creation of the mask band. Steps to reproduce: The

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

on internal masks it wasn't clear but I didn't see a way to specify copying masks in the COG driver. From: Ritchie, Andrew C Sent: Wednesday, April 15, 2020 12:26 PM To: Even Rouault ; gdal-dev@lists.osgeo.org Subject: RE: [EXTERNAL] Re: [gdal-dev] gdal_translate (3.1.0dev) "

Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

Andrew, Has your source raster an alpha band ? That could explain the difference since it isn't possible to directly create a YCbCrA JPEG compressed file, but internally a mask band must be created. However I wouldn't anticipate such a huge difference in performance between compression schemes.

[gdal-dev] gdal_translate (3.1.0dev) "never" finishes on large jpeg cogs... REALLLLLY long time to unload.

I've been working in the gdal-dev-env (version 3.1.0, installed around mid-December) on OSGeo4w (mostly because it's faster than making COGs using the GTIFF driver) on large (e.g. 102600x91100) orthophoto rasters, generating VRTs, TIFFs and COGs. While I can do LZW, DEFLATE, and uncompressed ju

Re: [gdal-dev] gdal_translate on VRT gives black image

Even, Thanks for your prompt fix and for the workaround! Guillaume On Thu, Apr 2, 2020 at 12:39 PM Even Rouault wrote: > Guillaume, > > > > It was a bug. Fix pushed. > > > > You can workaround it by adding > > > > > > > > as a child element of > > > > Even > > > > -- > > Spatialys - Geospati

Re: [gdal-dev] gdal_translate on VRT gives black image

Guillaume, It was a bug. Fix pushed. You can workaround it by adding as a child element of Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/m

[gdal-dev] gdal_translate on VRT gives black image

Hello, I'm posting this here instead of Github as I don't know if it is a bug or my misuse of the VRT format in conjunction with gdal_translate. When I create a VRT (v.vrt) with a SimpleSource pointing to a simple 20x20 pixels TIFF file and I do: gdal_translate v.vrt t.tif I get a black image at

[gdal-dev] gdal_translate geotiff to netcdf: values

HelloI have a geotiff file of sea ice concentration.When I use gdal_info it gives a series of values like:   Metadata:     COLORINTERP=Palette   Color Table (RGB with 65536 entries)     0: 9,60,112,255     1: 9,60,112,255     2: 9,60,112,255     3: 9,60,112,255     4: 9,60,112,255     5:

Re: [gdal-dev] gdal_translate is slow

Thanks guys for clarification! On Wed, Sep 4, 2019, 5:53 PM Even Rouault wrote: > On mercredi 4 septembre 2019 17:26:14 CEST Denis Rykov wrote: > > Thanks for quick reply, I've uploaded grib file here: > > https://transfer.sh/5JCVX/download.grib > > Turns out that my guess wasn't so bad after al

Re: [gdal-dev] gdal_translate is slow

On mercredi 4 septembre 2019 17:26:14 CEST Denis Rykov wrote: > Thanks for quick reply, I've uploaded grib file here: > https://transfer.sh/5JCVX/download.grib Turns out that my guess wasn't so bad after all. The uncompressed file size is 3601x1801x14(bands)x8(bytes_per_pixel) = 693 MB whereas a G

Re: [gdal-dev] gdal_translate is slow

Thanks for quick reply, I've uploaded grib file here: https://transfer.sh/5JCVX/download.grib On Wed, Sep 4, 2019 at 5:04 PM Even Rouault wrote: > On mercredi 4 septembre 2019 08:50:09 CEST Sean Gillies wrote: > > Hi Denis, > > > > rio-convert lacks some of the features of gdal_translate (advanc

Re: [gdal-dev] gdal_translate is slow

On mercredi 4 septembre 2019 08:50:09 CEST Sean Gillies wrote: > Hi Denis, > > rio-convert lacks some of the features of gdal_translate (advanced metadata > translation, statistics, &c) and it may be that the cost of those features > is being especially felt in the GRIB case. For a plain gdal_tra

Re: [gdal-dev] gdal_translate is slow

Hi Denis, rio-convert lacks some of the features of gdal_translate (advanced metadata translation, statistics, &c) and it may be that the cost of those features is being especially felt in the GRIB case. In fact, the core of gdal_translate has some GRIB-specific code that rasterio does not use: ht

[gdal-dev] gdal_translate is slow

Why gdal_translate so slow compared to rio translate from rasterio? rio convert: $ time rio convert download.grib download.tif Warning: Inside GRIB2Inventory, Message # 15 ERROR: Ran out of file reading SECT0 Warning: Inside GRIB2Inventory, Message # 15 ERROR: Ran out of file reading SECT0 rio co

Re: [gdal-dev] gdal_translate vs gdalwarp aggregation behaviour

I should have mentioned, this is using GDAL 2.4.1 on macOS. On Tue, 27 Aug 2019 at 03:16, John Baumgartner wrote: > Hi all > > I'm a bit confused by the difference in resampling behaviour seen when > using gdal_translate vs gdalwarp, when faced with ncol or nrow that is not > divisible by the ag

[gdal-dev] gdal_translate vs gdalwarp aggregation behaviour

Hi all I'm a bit confused by the difference in resampling behaviour seen when using gdal_translate vs gdalwarp, when faced with ncol or nrow that is not divisible by the aggregation factor. For example, consider this 9 cell raster (attached, hopefully) with values 1 through 9, with resolution 1x1

Re: [gdal-dev] Gdal_translate and -scale with non-Byte output

On vendredi 28 juin 2019 10:42:06 CEST Rahkonen Jukka (MML) wrote: > Hi, > > I was reading > https://gis.stackexchange.com/questions/247767/performing-histogram-strechi > ng-using-gdal-translate and made some tests and now I feel that > gdal_translate with -scale does not handle well some use case

[gdal-dev] Gdal_translate and -scale with non-Byte output

Hi, I was reading https://gis.stackexchange.com/questions/247767/performing-histogram-streching-using-gdal-translate and made some tests and now I feel that gdal_translate with -scale does not handle well some use cases with non-Byte output. The syntax is -scale [src_min src_max [dst_min dst_m

[gdal-dev] gdal_translate was compiled against GDAL 2.4, but the current library version is 2.2

After upgrading to 2.4 on Debian testing (buster), I get $ gdal_translate ERROR 1: gdal_translate was compiled against GDAL 2.4, but the current library version is 2.2 I've checked with synaptic and libgdal20 is 2.4 Any clue on what to do? Thanks ___ gd

Re: [gdal-dev] gdal_translate of VRT file with overlapping files. Target pixel value selection.

On vendredi 25 janvier 2019 14:36:23 CET Christoph Paulik wrote: > Hi, > > We have a VRT file in which some regions overlap. As far as I can tell > a gdal_translate of the VRT into a GTIFF just takes the value of the > first file it encounters for a given target pixel. Actually, this will be the

[gdal-dev] gdal_translate of VRT file with overlapping files. Target pixel value selection.

Hi, We have a VRT file in which some regions overlap. As far as I can tell a gdal_translate of the VRT into a GTIFF just takes the value of the first file it encounters for a given target pixel. Is there a way to specify an averaging method for such cases e.g. take the mean, max, min etc.? If not

Re: [gdal-dev] gdal_translate doesn't create GeoPackage's metadata

Hey Even, Thanks for the quick reply and fix. Apologies for the long delay in response. It looks great now when converting to GPKG from tif files, however when I convert from VRT to GPKG the metadata tables aren't created, is it intended? And regarding the GoogleCRS84Quad, thanks for adding the

Re: [gdal-dev] gdal_translate doesn't create GeoPackage's metadata

Hey Even, Thanks for the quick reply and fix. Apologies for the long delay in response. It looks great now when converting to GPKG from tif files, however when I convert from VRT to GPKG the metadata tables aren't created, is it intended? And regarding the GoogleCRS84Quad, thanks for adding the

Re: [gdal-dev] gdal_translate doesn't create GeoPackage's metadata

Gil, > > I got two questions: > 1) I have a question about something I believe is a bug, I recently upgraded > from 2.0.2 to 2.3.1, when using gdal_translate to convert a GeoTiff to > GeoPackage it doesn't create the GeoPackage's metadata tables > (gpkg_metadata/gpkg_metadata_reference). > If I

[gdal-dev] gdal_translate doesn't create GeoPackage's metadata

Hey all, I got two questions: 1) I have a question about something I believe is a bug, I recently upgraded from 2.0.2 to 2.3.1, when using gdal_translate to convert a GeoTiff to GeoPackage it doesn't create the GeoPackage's metadata tables (gpkg_metadata/gpkg_metadata_reference). If I create w

  1   2   3   4   >