Dear all,
I was wondering if there is a best practice or guide for the data type of alpha
channels in geotiffs.
I have many files where the data type is constant over all bands (UInt16 for
example).
I would expect the alpha band to be a byte band or even bit.
Is it possible to have different
Even
>
> Le 18/03/2021 à 12:20, Evert Etienne (SITEMARK) a écrit :
>> For reference, I decided to go for a simple gdal_calc with
>> `f"--calc=A*{factor}”`
>>
>>> On 12 Mar 2021, at 20:43, Evert Etienne (SITEMARK)
>>> wrote:
>>>
For reference, I decided to go for a simple gdal_calc with
`f"--calc=A*{factor}”`
> On 12 Mar 2021, at 20:43, Evert Etienne (SITEMARK)
> wrote:
>
> Hello all,
>
> I was wondering what the best or recommended way was to convert the vertical
> unit of a
Hello all,
I was wondering what the best or recommended way was to convert the vertical
unit of a DEM/DSM. I am able to use gdal_translate, gdal_calc.py, GDAL python
bindings or rasterio. I will afterwards be tiling using gdal2tiles.
Any pointers would be appreciated.
Greetings
Hey all,
I was wondering if there is someone in the community who is leading or ready to
take lead on the 3.2.2 release and if a (rough) release date would already be
available?
Many thanks
Evert
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Thank you Jukka for the links.
As I’ve commented on the github ticket and stackoverflow post, you helped me to
find a workaround.
Is there any tool available that can change a 3857 geotiff to the resolution
needed for a specific zoom level at the location of the geotiff (I am having a
hard
Hey,
Your zoom level explanation makes sense, thanks.
I should have included the gdalinfo in my previous mail, apologies.
```
Driver: GTiff/GeoTIFF
Files: output.tif
Size is 88543, 68686
Coordinate System is:
GEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS
Dear,
I have a question about the following extract of the MBTiles driver docs
(https://gdal.org/drivers/raster/mbtiles.html#raster-creation-issues)
> When using the CreateCopy() API (such as with gdal_translate), automatic
> reprojection of the input dataset to EPSG:3857 (WebMercator) will be
red into GeoTIFF tags. If the
result is good you can use that as a workaround. It is also possible to update
the geotiff tags with “gdal_edit -a_srs epsg:27573” but before that you should
be sure that it is the right thing to do.
-Jukka Rahkonen-
Lähettäjä: Evert Etienne (SITEMARK)
mailto:e
hkonen-
Evert Etienne (SITEMARK) wrote
It does not happen when just warping, but it does occur when warping to
the same EPSG as can be seen in the follow logs
```
orig.tif
EPSG:27573
bounds [828662.0710931281, 3203193.9700861075, 829595.8710931281,
3204344.6700861077]
EPSG:27573 bounds [828662.0710
2877, 1168x1439, 584x720, 292x360,
146x180
Mask Flags: PER_DATASET ALPHA
Overviews of mask band: 9338x11507, 4669x5754, 2335x2877, 1168x1439, 584x720,
292x360, 146x180
Unit Type: metre
Band 4 Block=256x256 Type=Byte, ColorInterp=Alpha
Overviews: 9338x11507, 4669x5754, 2335x2877, 1168x1439,
Hey all,
I have some behaviour that I can’t wrap my head around. When I reproject a tif
using gdalwarp, the location (as visible in QGIS or after using gdal2tiles on a
map) changes. It is visible when checking the bounds using QGIS.
It is also noticeable when checking the bounds with rasterio:
I actually have no idea what the extra code in your examples is doing, can you
explain?
For the behavior: it is the same as psutil (makes sense since memory_profiler
uses psutil by default). You can see it reach max cache by logging psutil
values in the Translate callback. I also saw the same
The issue is also visible on process level. Do you know if this cache exists in
process level and if so, if free can show this as well?
On Dec 27, 2019 20:08, Andrew C Aitchison wrote:
On Thu, 26 Dec 2019, Evert Etienne (SITEMARK) wrote:
> I am measuring memory usage using psutil: Proc
I am measuring memory usage using psutil:
Process: `psutil.Process().memory_info().rss` and
`psutil.Process().memory_percent()`
General: `psutil.virtual_memory().available`
I do tests both on MacOS and linux.
Any idea about how to investigate the file cache or how to use psutil to check
the
...@spatialys.com>> wrote:
On jeudi 26 décembre 2019 14:30:35 CET Evert Etienne (SITEMARK) wrote:
Using a bigger file (8GB) and a machine with 64GB Ram we can see the
increase being higher. For both gdal.Warp and gdal.Translate
GDAL may use up to GDAL_CACHEMAX memory, plus some other smaller cache
logging.debug(kwargs)
98691.5 MiB579.3 MiB gdal.Warp(temp.name, input_path,
**kwargs)
100 3943.1 MiB 3251.6 MiB gdal.Translate(output_path,
temp.name, creationOptions=copts)
```
On 26 Dec 2019, at 15:26, Evert Etienne (SITEMARK)
mailto:evert.etie
Hi all,
I have a question about memory usage of the python gdal bindings. For some GDAL
calls (python or not), we try to optimise the gdal cache. Doing this, I’ve
noticed the free RAM decreasing after doing gdal operations. I have been able
to narrow it down to the python bindings. Using
18 matches
Mail list logo
