Hi Lucas,
GDAL will keep the input values unchanged when possible, and saturate (use the
maximum or minimum representable value) when not. So 10050 will be transformed
to 255 when you're converting to Byte, and -4 will be saved as -32768 for
Int16. NaN nodata values will be converted to 0 w
Hi guys. Have a nice day.
I’m curious how gdal scales the values when converting from a larger range to a
smaller range,like from u32 to u8, u16 to u8, f32 to u8 etc..
I made a test:
gdal_translate -ot Byte -of GTiff gray_u32.tif gray_u8.tif
All the u32 value in every sample of my gray_u32.tif i
should be fixed per https://github.com/OSGeo/gdal/pull/11429
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
___
gdal-dev mai
Hi
20% more speed into GeoJSON writing is notable. I do not use GeoJSON so much
but some other people in the community may be happy. Thanks for having a look.
-Jukka-
Lähettäjä: Even Rouault
Lähetetty: tiistai 3. joulukuuta 2024 20.22
Vastaanottaja: Rahkonen Jukka ;
'gdal-dev@lists.osgeo.org'
Hi Even,
thank you.
I have this
{
dimensions:
Time = UNLIMITED ; // (25 currently)
bottom_top = 1 ;
south_north = 229 ;
west_east = 174 ;
DateStrLen = 19 ;
variables:
float NO2(Time, bottom_top, south_north, west_east) ;
NO2:units =
Le 03/12/2024 à 12:09, andy via gdal-dev a écrit :
Hi Michael and thank you.
I do not have lon and lat subdatasets listed under "geolocation" and I
wrote here for that reason.
Please post the output of "ncdump -h out.intput.nc" to understand why
the driver doesn't automatically detect the l
Jukka,
well, we have used up to now the same trick as a famous vendor did with
their flagship text processing editor for Mac decades ago: add explicit
sleep() to make the process slower, to discourage users from creating
too large GeoJSON files, which are difficult to read if too big.
More s
Hi Michael,
and thank you.
On Tue, 3 Dec 2024 at 19:06, Michael Sumner wrote:
> You can't use a geotransform unless the data are actually regular. There's
> no saying whether the lon lat arrays describe a regular grid redundantly
> without inspecting them (it's also very common for formats to de
You can't use a geotransform unless the data are actually regular. There's
no saying whether the lon lat arrays describe a regular grid redundantly
without inspecting them (it's also very common for formats to deliver lon
lat coords when the data is actually a regular grid in a different crs, but
i
Le 03/12/2024 à 15:28, Howard Butler via gdal-dev a écrit :
+1 Howard
I think it would be prudent for the documentation and communication about the
'gdal' command to state something like the following:
agreed. Added in candidate implementation per
https://github.com/OSGeo/gdal/pull/11303/co
+1 Howard
I think it would be prudent for the documentation and communication about the
'gdal' command to state something like the following:
> The 'gdal' command is provisionally provided as an alternative interface to
> GDAL and OGR command line utilities. The project reserves the right to
>
Hi Michael,
It seems to work.
Is there no way not to hard-code the GeoTransform, SrcRect, etc.
parameters?
Thank you
EPSG:4326
4.36, 0.0894, 0.0, 48.88, 0.0, -0.0597
NO2 Concentration
ppb vol
NETCDF:"out.input.nc
":NO2
1
+1 Javier
On Mon, 2 Dec 2024 at 18:27, Daniel Morissette via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> +1
>
> Daniel
>
>
> On 2024-12-02 11:13, Even Rouault via gdal-dev wrote:
>
> Hi,
>
> I move to adopt RFC 104: Adding a "gdal" front-end command line interface
> : https://github.com/OSGeo/g
Hi,
Using GDAL 3.9.3, I'm running a DXF output and creating an OGR_STYLE column for
a point geometry label such as:
LABEL(f:"Romans",s:"1400",t:"HIGH STREET",a:"322.1",p:"10")
When I view the output label, it has no visible space, in a text editor I can
see the label is:
"HIGH\~STREET"
How m
Hi Michael and thank you.
I do not have lon and lat subdatasets listed under "geolocation" and I
wrote here for that reason.
I also tried doing a VRT, but I am doing something wrong, because I always
see the coordinates in pixels
Thank you again
EPSG:4326
NETCDF:"out.input.nc"
Try
gdalinfo NETCDF:"out.input.nc":NO2
If you see those lon and lat subdatasets listed under "geolocation" then
you can use gdalwarp to create a georeferenced dataset, automatically with
gdalwarp sds.in out.tif or by specifying a grid with some of
-tr,-te,-t_srs,-ts.
If they don't appear they ca
Hi,
I have a NetCDF file that I cannot share here.
Using gdalinfo I have the below output.
Is there any way to tell gdal to read coordinates from the “lon” and “lat”
variables/subdatasets, and thus have the coordinates of the vertices not in
pixels?
Thank you very much
Driver: netCDF/Network C
17 matches
Mail list logo
