Thank you Andrew!
From: Andrew C Aitchison
Sent: January 11, 2024 6:00 AM
To: ni hao
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] gdal_merge -of format
On Wed, 10 Jan 2024, ni hao via gdal-dev wrote:
> Hi list,
>
>
>
> question about: gdal_merge -of for
In the DK registry we used descriptive names, rather than numbers to refer
to the transformations taking legacy systems to ETRS89. Essentially these
transformations amounted to CRS definitions. Is it safe to assume a
"crs_code" is strictly numeric?
Den ons. 10. jan. 2024 kl. 20.46 skrev Meyer, Jes
Hi,
as documented in
https://gdal.org/drivers/vector/pdf.html#feature-style-support, styling
support in the PDF driver is very limited, and doesn't include the brush
type. For things not supported, you'd better use a more advanced
rendering engine that can output PDF, like QGIS or MapServer
Jukka,
nearblack is quite a special case. The doc says "The processing is all
done in 8bit (Bytes)." , so it only properly works on Byte datasets.. If
you provide any other data type, the values will be clamped to [0,255].
And when creating an output file, it will always be Byte.
The data ty
Hi,
Do I understand right that the raster drivers like the GTiff driver do not have
a creation option for the datatype? Most utilities like gdal_translate,
gdalwarp, and gdal_create have the -ot option, but there are couple of
utilities that don't even it might make sense. For example nearblack
Hi,
I am facing challenges in using the OGR Brush symbols for PDF generation
and only the default styling seems to be working. It seems the
id:"ogr-brush-n" is not considered.
[image: image.png]
GDAL version is 3.2.2
Can anyone provide any feedback ?
Regards
Mandeep
___
