Thanks Even!
Matt
From: Even Rouault
Sent: Wednesday, January 31, 2024 12:54
To: Matt.Wilkie ; gdal-dev@lists.osgeo.org
Subject: [EXT] Re: [gdal-dev] Unknown projection
Matt,
surprisingly or not, the GTiff driver doesn't try to get the SRS from a .prj
si
Hi Even,
It is great to hear that some people still take care of this library :-)
Lately, I have tried to compile it with Visual C 2019. And I gave up,
because of too many errors ...
I wonder how people running GDAL under windows manage to compile it, for
example QGIS.
Do you have any hints ?
Tha
Hi,
Following the well-known motto "release early, release often", and given
the last release was 4.5 years ago :-), I've cut down a OGDI 4.1.1
release. The main motivation was that 4.1.0 no longer built with recent
compilers.
4.1.1 changes:
o Fix various compiler warnings, in particular f
I see. Just create a new field with the sql query. Of course.
Thanks.
From: gdal-dev on behalf of Laurențiu Nicola
via gdal-dev
Reply-To: Laurențiu Nicola
Date: Thursday, February 1, 2024 at 10:14 AM
To: "gdal-dev@lists.osgeo.org"
Subject: [EXTERNAL] [BULK] Re: [gdal-dev] gdal_rasterize "b
Hi,
You can use -sql and -a to burn a field of the query.
Laurentiu
On Thu, Feb 1, 2024, at 17:11, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
APPLICATIONS INC] via gdal-dev wrote:
> Hi,
>
> We’d like to use gdal_rasterize to burn in a value that is a simple numerical
> function of the
Hi,
We’d like to use gdal_rasterize to burn in a value that is a simple numerical
function of the feature geometry. Currently we pre-process the feature
database, store the value into a new field, and then burn that in. It works,
but it would be handy to be able to express this directly to gd
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
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
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")
>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
Hi Jukka,
If GDAL shuffled around the pixels in that file, you wouldn't be able to notice
it by comparing the GRIB and the TIFF, because both would be shuffled.
My suggestion was to convert the GRIB to a NC or even CSV using xarray, then
comparing the GDAL output against that.
Laurentiu
On Th
Hi,
I used the gdal_compare script https://gdal.org/programs/gdalcompare.html
gdalcompare st4_pr.2017092016.01h st4_pr.2017092016.01h.tif
and it reports three differences:
* Files differ at the binary level (normal, GRIB and tif are not the same)
* Difference in SRS (but they are alike
12 matches
Mail list logo
