Nice one, thanks! (I had a fomenting PR to implement on the fly geolocation
array config, so I'll use your hallucination for the design phase).
🤟
On Sat, 19 Oct 2024, 14:44 Even Rouault, wrote:
>
> Le 18/10/2024 à 23:32, Michael Sumner a écrit :
>
> I didn't know you could do that with -to!! Th
Le 18/10/2024 à 23:32, Michael Sumner a écrit :
I didn't know you could do that with -to!! That's awesome
🤟
Hum, sorry for giving a wrong track, it seems the newly LLM module
implemented in my brain has hallucinated...
So you have rather to create a geoloc.vrt file with
gdal_translate inp
I didn't know you could do that with -to!! That's awesome
🤟
On Sat, 19 Oct 2024, 05:01 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:
> Conrad,
>
> Try something like:
>
> gdal_translate input.tif imagery.vrt -b 3
>
> gdalwarp imagery.vrt imagery_warped.tif -geoloc -to X_DATASET=i
Good news indeed, thanks Even!
Best,
Jesse
Lead Computer Scientist
Science Systems and Applications, Inc.
Dr Compton Tucker Team
NASA Goddard Space Flight Center
From: Even Rouault
Date: Friday, October 18, 2024 at 5:46 PM
To: Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]
Jesse,
Le 18/10/2024 Ã 21:15, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
APPLICATIONS INC] via gdal-dev a écrit :
We have a bunch of legacy code that uses from osgeo import gdal, ogr,
where raster datasets are created with gdal and vector datasets with
ogr.  However, these don’t mix w
We have a bunch of legacy code that uses from osgeo import gdal, ogr, where
raster datasets are created with gdal and vector datasets with ogr. However,
these don’t mix well when, say, rasterizing a vector dataset with
gdal.rasterize. The ‘workaround’ is to create a vector dataset using gdal:
Conrad,
Try something like:
gdal_translate input.tif imagery.vrt -b 3
gdalwarp imagery.vrt imagery_warped.tif -geoloc -to X_DATASET=input.tif
-to X_BAND=2 -to Y_DATASET=input.tif -to Y_BAND=1 -to PIXEL_OFFSET=0 -to
PIXEL_STEP=1 -to LINE_OFFSET=0 -to LINE_STEP=1 -to SRS=EPSG:4326 -a_srs
EPSG:
Please provide a link to the file, or the full gdalinfo output with -stats
👌
On Fri, 18 Oct 2024, 23:16 Conrad Bielski, wrote:
> Hi Mike,
> thanks for the prompt. Looking into it, the data are DEM corrected
> latitude/longitude. A GDAL info shows it as a regular raster band: Band 1
> Block=4865x
Hi Mike,thanks for the prompt. Looking into it, the data are DEM corrected
latitude/longitude. A GDAL info shows it as a regular raster band: Band 1
Block=4865x1 Type=Int32, ColorInterp=Gray
How can I take advantage of VRT? That sounds like a great potential
solution.ThanksConrad
On Friday
Check if gdalinfo sees the longitude and latitude as geolocation arrays,
then just warp to grid you want.
If they aren't auto identified this can be arranged with VRT.
Cheers, Mike
On Fri, 18 Oct 2024, 21:55 Conrad Bielski via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:
> Hi Javier,
>
> it is
Hi Javier,
it is not a grid. So each raster pixel is assigned the geolocation. Yes - if I
was to extract it, that's what it could be considered.
Conrad
On Friday, October 18, 2024 at 11:37:28 AM GMT+1, Javier Jimenez Shaw
wrote:
Is it an actual grid? in the meaning of having constant
Is it an actual grid? in the meaning of having constant step size in X and
Y.
In that case the geolocation is just the corner and the x and y sizes. You
can convert to a georeference raster, and warp it.
If it is not the case, you have something more like a 2D pointcloud, or a
bunch of poins in a s
Hello GDAL-experts,
normally when I use GDAL for reprojecting imagery, the projection information
that I use is the source spatial reference (SRS) associated with the imagery.
However, now I have imagery which is lat/lon geographic and I have two separate
bands which also carry the pixel geograp
13 matches
Mail list logo
