Hi, Even.
Using both options "-optim raster" and "-optim vector" results in the same
size files. This is expected, since, as follows from the option description, it
only affects the rasterization algorithm.
>Wednesday, March 20, 2024 1:04 AM +03:00 from Even Rouault
>:
>
>
>Le 19/03/20
Carsten,
gdal_rasterize definitely supports burning into existing files.
I'm not sure about the configuration of your raster -- some formats are not
updatable-in-place, but the limitation isn't in gdal_rasterize.
Best regards,
Frank
On Tue, Mar 19, 2024 at 8:42 AM Carsten Lockenkötter <
carsten
Excellent! Thanks for the answers.
When I've explored a bit more I might implement the overview sizes just so
we can match downstream tools (the current motivation is like-for-like
performance comparison, I haven't looked there but I think odc goes very
low level to eke out speed).
Cheers, Mike
Michael,
Hi, can we specify overview sizes exactly?
No, the BuildOverviews() interface onlys take an array of overview
factors. It is up to the driver implementation to decide how it computes
the overview size from the main raster size and overview factor.
The COG driver is a bit of a speci
Hi, can we specify overview sizes exactly? I have this odd grid that is
36000x17999, and I get consequently yucky overview sizes:
gdal_create -outsize 36000 17999 -ot Int8 -co SPARSE_OK=YES -a_srs
EPSG:4326 -a_ullr 0 17999 0 36000 weird.tif
gdal_translate weird.tif cog.tif -of COG
gdalinfo cog.ti
Le 19/03/2024 à 22:56, Rahkonen Jukka via gdal-dev a écrit :
Hi,
I suppose that something similar than with gdalwarp
https://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken
happens but with gdal_rasterize I think there are no tricks that could
help.
Actually th
Hi,
I suppose that something similar than with gdalwarp
https://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken
happens but with gdal_rasterize I think there are no tricks that could help.
-Jukka Rahkonen-
Lähettäjä: Andrey VI
Lähetetty: tiistai 19. maaliskuuta 202
Le 19/03/2024 à 21:38, Fengting Chen a écrit :
I copied out the command from install_python_Release.cmake and ran it
manually. Then it worked. Not sure why the command not invoked. I
don’t see error from “cmake –build . –target install –config Release”.
My setuptools is 40.6.2.
Not sure if
I copied out the command from install_python_Release.cmake and ran it manually.
Then it worked. Not sure why the command not invoked. I don’t see error from
“cmake –build . –target install –config Release”.
My setuptools is 40.6.2.
From: Even Rouault
Date: Tuesday, March 19, 2024 at 3:22 PM
To
Hi,
Le 19/03/2024 à 20:14, Fengting Chen via gdal-dev a écrit :
Hi, I was able to build the GDAL with python binding on without error
on windows. However, “cmake --build . --target install --config
Release” command doesn’t install the python site-packages etc to the
specified “CMAKE_INSTALL
Hi, I was able to build the GDAL with python binding on without error on
windows. However, “cmake --build . --target install --config Release” command
doesn’t install the python site-packages etc to the specified
“CMAKE_INSTALL_PREFIX” directory. The rest of the GDAL components were
installed
Hello GDAL community,
this is an update and preliminary summary about references to the GDAL project
(and developer community) within scientific publications since 2022.
In 2022, a Digital Object Identifier (DOI) was registered for the GDAL project.
Since then (version 3.5.1), each new release
Yes, the target files already exists. Yes, I’ve tried to investigate this issue
on some small and medium files. For example:
original hillshade.tif size is 11469 bytes, after gdal_rasterize its size is
26465 bytes, and after gdal_translate - 15426 bytes,
original - 7477 K, gdal_rasterize - 8705
Hi,
So the target files dem.tif and hillshade.tif exist already? Maybe it is not so
simple to update already compressed data in place. Have you tried what happens
if you re-write the results into new files
gdal_translate -co tiled=yes -co compress=LZW hillshade.tif final_hillshade.tif.
-Jukka
Why not just trying?
Demo:
$ gdal_create -outsize 10 10 -burn 255 test.tif -a_srs EPSG:4326 -a_ullr
0 10 10 0
$ gdal_rasterize -burn 0
'{"type":"Polygon","coordinates":[[[2,2],[2,4],[4,4],[4,2],[2,2]]]}'
test.tif
$ gdal_translate test.tif /vsistdout/ -of aaigrid
ncols 10
nrows
Hi Frank,I have read about gdal_rasterize but it seems it works a bit different as i need it.Gdal_rasterize converts a vector layer to a raster layer with specific dimensions and create a new file, like a mask.It could be work for me yes, because i publish the raster files as image mosiac at t
Hello.
I’m using gdal_rasterize to remove some data from DEM (Int16) and hillshade
(Byte) rasters with shape-file, like this:
gdal_rasterize -burn -32768 shape.shp dem.tif and gdal_rasterize -burn 0
shape.shp hillshade.tif
Both DEM and hillshade GTiffs created with -co COMPRESS=LZW -co TILED=Y
Thomas,
Le 19/03/2024 à 08:26, thomas bonfort via gdal-dev a écrit :
I have a side-question concerning the update-in-place behavior of the
gtiff driver in this case: given that a compressed strile will nearly
always be smaller after this update (due to better compression ratios
on the uniform
I have a side-question concerning the update-in-place behavior of the gtiff
driver in this case: given that a compressed strile will nearly always be
smaller after this update (due to better compression ratios on the uniform
area), will libtiff overwrite the previous strile in place also, or will i
19 matches
Mail list logo