[gdal-dev] gdalwarp + svg polygon as mask?

Hi Devs, Given - an image/raster file (from one webservice (IIIF service)) - some gcp's (from another webservice (allmaps.org) I found out (using some scripting) it is doable to 'warp' the original image (and load in QGIS). The allmaps.org service (providing georef 'annotions'), also provides

Re: [gdal-dev] gdalwarp across the antimeridian with a source extent >180E

Thanks! Educational as ever, this closes out a few hanging threads for me, much appreciated. Cheers, Mike On Mon, Jun 3, 2024 at 3:48 AM Even Rouault wrote: > Michael, > > https://github.com/OSGeo/gdal/pull/10108 will fix it. > > You can also workaround the issue by overriding the extent of

Re: [gdal-dev] gdalwarp across the antimeridian with a source extent >180E

Michael, https://github.com/OSGeo/gdal/pull/10108 will fix it. You can also workaround the issue by overriding the extent of the source dataset to be exactly -179.995,89.995,180.005,-89.995 with   "vrt://NETCDF:2024010209-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EP

Re: [gdal-dev] gdalwarp across the antimeridian with a source extent >180E

I forgot to mention that it needs earthdata credentials set up, basically your "Authorization: Bearer " in GDAL_HTTP_HEADERS or similar config. https://urs.earthdata.nasa.gov/documentation/for_users/user_token You can't download or stream these files without that set or logging in (the file used

[gdal-dev] gdalwarp across the antimeridian with a source extent >180E

This data source has an odd georeferencing, it's a 36000x17999 raster in the extent -179.995 -89.995 180.005 89.995. vrt://NETCDF:/vsicurl/ https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/2024010109-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analy

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

is=0x5584b5c21370) > -- > *From:* Daniel Evans > *Sent:* Thursday, April 18, 2024 9:03 AM > *To:* Joseph McGlinchy > *Cc:* Even Rouault ; gdal-dev@lists.osgeo.org > > *Subject:* Re: [gdal-dev] gdalwarp with RPCs causing bogus output > >

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

) From: Daniel Evans Sent: Thursday, April 18, 2024 9:03 AM To: Joseph McGlinchy Cc: Even Rouault ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalwarp with RPCs causing bogus output Hi Joe, My minimal change is just to add the missing "RPC_DEM=srtm_12_05.tif" and

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

ts. What command did you use to include the DEM? > > If there has been a fix between 3.6 and 3.8.3 that helps with this, then > I'm happy to try it. I'll give that a look too. > > thanks! > Joe > -- > *From:* Daniel Evans > *Sent:* Th

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

helps with this, then I'm happy to try it. I'll give that a look too. thanks! Joe From: Daniel Evans Sent: Thursday, April 18, 2024 5:44 AM To: Joseph McGlinchy Cc: Even Rouault ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalwarp with RPCs caus

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

ks! > Joe > -- > *From:* Even Rouault > *Sent:* Wednesday, April 17, 2024 4:20 PM > *To:* Joseph McGlinchy ; gdal-dev@lists.osgeo.org > > *Subject:* Re: [gdal-dev] gdalwarp with RPCs causing bogus output > > > Hi, > > > I haven

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

esday, April 17, 2024 4:20 PM To: Joseph McGlinchy ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalwarp with RPCs causing bogus output Hi, I haven't done myself that exercice but I know that computing RPC values that are stable enough might be challenging, so perhaps the issue is relat

Re: [gdal-dev] gdalwarp with RPCs causing bogus output

Hi, I haven't done myself that exercice but I know that computing RPC values that are stable enough might be challenging, so perhaps the issue is related to that A few other remarks: - your gdalwarp command line refers to  RPC_DEM_SRS and RPC_DEM_MISSING_VALUE but doesn't include a RPC_DE

[gdal-dev] gdalwarp with RPCs causing bogus output

Hello, I am attempting to implement georegistration through RPC. I have the following information I've used to calibrate the RPC coefficients, using all terms for numerator and denominator for both sample and line equations. * image grid, stored in tiff format with no geo-information associa

Re: [gdal-dev] gdalwarp different behavior for tif and netCDF files

I should also have added that original nc has data in Lat Lon, but is not actually stamped with EPSG:4326 SRS. Here is what I get from gdalinfo. (I used a tool called grdcut to create the sample, but the behaviour is same This is what gdalinfo shows on original nc file from which I created a sampl

[gdal-dev] gdalwarp different behavior for tif and netCDF files

I am trying to reproject a netCDF file which is in Lat Lon (EPSG:4326) projection to EPSG:3857 (Google mercator) (on GDAL 3.4.3, released 2022/04/22). If I reproject to a tif file, it is reprojected correctly. If I reproject to a nc file it reproject incorrectly/different location that tif file. I

Re: [gdal-dev] gdalwarp: question about methods implemented when source grid is denser than target.

Hi, to briefly answer your question, for the methods bilinear, cubic, cubicspline and lanczos who have nominal kernel radius of respective values 1, 2, 2 and 3 (and thus a diameter double that size), the radius is extended by a factor source_size / dest_size to take into account the downsampl

[gdal-dev] gdalwarp: question about methods implemented when source grid is denser than target.

Hi, I would like to know if gdalwarp does any "average" regriding when the source grid is denser than the target grid regardless of the chosen method for the interpolation. And if there is any document where I can follow exactly the calculations. I tried to follow the code on github but it is pret

Re: [gdal-dev] gdalwarp vs gdal_translate for scaling

ugh, sorry just realized my comment (sentence begins 'Further ...') about "scaling" is completely irrelevant - you mean spatial and not data scaling. Just ignore that one sentence. Cheers, Mike On Fri, Jan 6, 2023 at 10:36 AM Michael Sumner wrote: > in short, warp will give you exactly the ta

Re: [gdal-dev] gdalwarp vs gdal_translate for scaling

in short, warp will give you exactly the target extent of a (possibly) new grid specification in that -te subdivided by the -ts. translate will give you approximately the extent provided to projwin, but snapped to the source grid alignment at a particular zoom implied by the projwin subdivided by

[gdal-dev] gdalwarp vs gdal_translate for scaling

Hi folks! We have a process that generates web mercator zoom levels by resampling from the next higher up, from the original resolution down to zoom level 0. Currently we do so with gdalwarp, but a team member realized that gdal_translate is capable of the same, and at first glance is much faste

Re: [gdal-dev] gdalwarp running very slow

ttaja: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] gdalwarp running very slow I want to APPEND the UK data into the international.tif The updated international size should also be: 45, 225000 I first tried gdalbuildvrt -o /data/coastal-2020.vrt /vsis3/summer/3/coastal-2020.tif /vsis3/s

Re: [gdal-dev] gdalwarp running very slow

, -Jukka- *Lähettäjä:* Clive Swan *Lähetetty:* keskiviikko 14. joulukuuta 2022 10.29 *Vastaanottaja:* Rahkonen Jukka *Aihe:* Re: [gdal-dev] gdalwarp running very slow Hi Jukka, Thanks for that, was really stressed. I will export the UK extent, and rerun the script. Thanks Cliv

Re: [gdal-dev] gdalwarp running very slow

t. > > > > Good luck with your experiments, > > > > -Jukka- > > > > > > > > > > *Lähettäjä:* Clive Swan > *Lähetetty:* keskiviikko 14. joulukuuta 2022 10.29 > *Vastaanottaja:* Rahkonen Jukka > *Aihe:* Re: [gdal-dev] gdalw

Re: [gdal-dev] gdalwarp running very slow

utside the UK? The name of the image makes me think so. -Jukka Rahkonen- Lähettäjä: Clive Swan Lähetetty: tiistai 13. joulukuuta 2022 19.22 Vastaanottaja: gdal-dev@lists.osgeo.org Kopio: Rahkonen Jukka Aihe: [gdal-dev] gdalwarp running very slow Greetings, I am using the same files, I copied

[gdal-dev] gdalwarp running very slow

= hazard_reliability NoData Value=- -- Regards, Clive Swan -- Hi, If you are still struggling with the same old problem could you please finally send the gdalinfo reports of your two input files which are this time: coastal-2020.tif 5_UK_coastal-2020.tif -Jukka Rahkonen- Lähettäjä: gda

Re: [gdal-dev] gdalwarp running very slow

17.23 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] gdalwarp running very slow Greetings, I am running gdalwarp on a 6GB (output) and 600MB (input) tif image, the AWS Instance has approx 60 VCPU It has taken over 6 hours so far - still running, is it possible to optimise this and speed it

[gdal-dev] gdalwarp running very slow

Greetings, I am running gdalwarp on a 6GB (output) and 600MB (input) tif image, the AWS Instance has approx 60 VCPU It has taken over 6 hours so far - still running, is it possible to optimise this and speed it up?? gdalwarp -r near -overwrite coastal-2020.tif 5_UK_coastal-2020.tif -co BIGTIFF=

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

Rahkonen- Lähettäjä: Chao Li mailto:chaoli0...@gmail.com>> Lähetetty: maanantai 27. kesäkuuta 2022 13.55 Vastaanottaja: Rahkonen Jukka mailto:jukka.rahko...@maanmittauslaitos.fi>> Kopio: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> Aihe: Re: [gdal-dev] gdalwarp Resampling

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

ython to have a single > value for nodata. > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* Chao Li > *Lähetetty:* tiistai 28. kesäkuuta 2022 2.58 > *Vastaanottaja:* Rahkonen Jukka > *Kopio:* gdal-dev@lists.osgeo.org > *Aihe:* Re: [gdal-dev] gdalwarp Resamplin

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

-Jukka Rahkonen- > > > > *Lähettäjä:* Chao Li > *Lähetetty:* maanantai 27. kesäkuuta 2022 13.55 > *Vastaanottaja:* Rahkonen Jukka > *Kopio:* gdal-dev@lists.osgeo.org > *Aihe:* Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting > > > > Hi, > >

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

al-dev@lists.osgeo.org Aihe: Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting Hi, You are right but when I try to check the data processing, there is no any compression. On my computer, it is similar to your situation. I guess most nodata values are over 32760, so maybe I can list all o

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

Lähettäjä:* Chao Li > *Lähetetty:* maanantai 27. kesäkuuta 2022 11.29 > *Vastaanottaja:* Rahkonen Jukka > *Aihe:* Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting > > > > Hi, > > > > Now, seemingly, it works. I am also able to get output raster, but

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

be that at some moment the image has been compressed with JPEG or some other lossy method? -Jukka Rahkonen- Lähettäjä: Chao Li Lähetetty: maanantai 27. kesäkuuta 2022 11.29 Vastaanottaja: Rahkonen Jukka Aihe: Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting Hi, Now, seemingly, it

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

2022 10.50 Vastaanottaja: Rahkonen Jukka Aihe: Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting Dear Ms./Mr. Jukka Thank you for your reply. I try to delete the -srcnodata 32767, but it still doesn't work. I have attach a part of raster, in this email. Thanks for your hel

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

use gdal_translate with -srswin or -projwin for that. -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Chao Li Lähetetty: maanantai 27. kesäkuuta 2022 4.09 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting Dear GDAL experts, I have a problem

Re: [gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

On Mon, 27 Jun 2022, Chao Li wrote: Dear GDAL experts, I have a problem using *gdalwarp*. I want to reproject a raster and change its resolution by the average method. ... ... This is the *gdalinfo* of the raster Corner Coordinates: Upper Left (-20015109.354, 7783653.638) (166d17'

[gdal-dev] gdalwarp Resampling Input Raster Nodata Setting

Dear GDAL experts, I have a problem using *gdalwarp*. I want to reproject a raster and change its resolution by the average method. This is the *gdalinfo* of the raster [q70176a@ito-2 ~]$ gdalinfo DP12/11_RawData/02_GGP/Gross_PP_8Days_500m_v6/GPP/MOD17A2H_GPP_2016_001.tif

Re: [gdal-dev] gdalwarp alpha band resampling bug

One more data point; another colleague who is on a mac but built gdal himself instead of using brew does not see the artifact, so I suppose the lesson is, build your own gdal! Best, P On Fri, Sep 17, 2021 at 8:51 PM Patrick Young < patrick.mckendree.yo...@gmail.com> wrote: > Hi Even, > > Thanks

Re: [gdal-dev] gdalwarp alpha band resampling bug

Hi Even, Thanks for checking! I tried this in a docker container (osgeo/gdal) and sure enough, the output looks fine there. It reproduces for me with my brew installed gdal (3.3.2) and I was careful to do everything in a clean directory. I tried a few other outputs as well (png, jpeg) and the t

Re: [gdal-dev] gdalwarp alpha band resampling bug

I can't reproduce the issue you describe. There's not a single white pixel in the output image (the max of the green and blue bands is < 255). But I suspect this could be related to a pre-existing composite-bl.tif file you might have. gdalwarp doesn't overwrite by default the output image. It b

[gdal-dev] gdalwarp alpha band resampling bug

Hello, I've found behavior in gdalwarp related to compositing an image with a variable alpha band. Under bilinear resampling, the alpha compositing in areas where the alpha band is between 0 and 255 results in completely white pixels. To reproduce, I've first grabbed a rgba image from the test s

[gdal-dev] Gdalwarp fails with Stereographic_North_Pole

Hi, Have a look at this question https://gis.stackexchange.com/questions/383825/difference-between-qgis-export-and-gdalwarp? The original poster managed to get good output with gdalwarp by warping first into EPSG:9040 and then into EPSG:4326 but that feels like a workaround and not a solution.

Re: [gdal-dev] gdalwarp: behavior of "mode" resampling with NODATA

What I understand is (2), and also my experience. Cheers El mié., 30 dic. 2020 12:11, Jed O. Kaplan escribió: > Working with GDAL 3.0.4 > > The behavior of “mode” resampling when NODATA pixels are present is not > clear to me from reading the documentation. I guess there are two > possibilities

[gdal-dev] gdalwarp: behavior of "mode" resampling with NODATA

Working with GDAL 3.0.4 The behavior of “mode” resampling when NODATA pixels are present is not clear to me from reading the documentation. I guess there are two possibilities: 1) If NODATA is the modal value among the pixels under consideration, then the result is NODATA or 2) The modal value

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Thank to Jukka, so the problem was with my gdal 1.11.4 on Centos 7. When I translated it to EPSG:4647, it doesn't contain proper WKT for EPSG, e.g: Coordinate System is: LOCAL_CS["ETRS89 / UTM zone 32N (zE-N)", GEOGCS["ETRS89", DATUM["unknown", SPHEROID["unretrievable - us

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Hi again, Sorry, I did not read properly what you did. That should work and it does work for me with GDAL 3.2. I use a copy of your test.tif as "test_00.tif". gdal_translate -a_srs epsg:4647 test_00.tif test_000.tif Input file size is 100, 100 0...10...20...30...40...50...60...70...80...90...100

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 11:13 schrieb Pham Huu Bang: The tiff file you can download from https://files.fm/f/5ttjhyh9p The xyz file I already shared in the beginning: https://pastebin.com/40xSNqm4 Thanks. This really is EPSG:4647 and sho

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Hi, What you have wrong is the input coordinate system, not the output as you tested. Compare https://epsg.org/crs/wkt/id/25832 with https://epsg.org/crs/wkt/id/4647 and notice the difference in false easting. Now run gdalwarp right gdalwarp -s_srs epsg:4647 -t_srs epsg:4326 test_00.tif test_432

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

The tiff file you can download from https://files.fm/f/5ttjhyh9p The xyz file I already shared in the beginning: https://pastebin.com/40xSNqm4 Thanks, On Wed, 25 Nov 2020 at 11:10, Tobias Wendorff < tobias.wendo...@tu-dortmund.de> wrote: > Am 25.11.2020 um 11:00 schrieb Pham Huu Bang: > > ERROR

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 11:00 schrieb Pham Huu Bang: ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Can you share your data? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailm

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Hi Tobias, If I set to EPSG:4647, I cannot warp it either: gdal_translate -a_srs EPSG:4647 test.tif test1.tif Input file size is 100, 100 0...10...20...30...40...50...60...70...80...90...100 - done. gdalinfo test1.tif Driver: GTiff/GeoTIFF Files: test1.tif Size is 100, 100 Coordinate System is:

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 10:17 schrieb Pham Huu Bang: Corner Coordinates: Upper Left  (32573000.000, 6019990.000) (174d17' 8.00"W,Invalid angle) Lower Left  (32573000.000, 6018990.000) (114d59' 0.99"W,Invalid angle) Upper Right (32574000.000, 6019990.000) (109d46'37.15"W,Invalid angle) Lower Right (32574

[gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Hello, I have a DGM 10m tiff file (translated from xyz file: e.g:dgm10_32572_6020_1_sh.xyz - example: https://pastebin.com/40xSNqm4) in EPSG:25832 CRS with this gdalinfo as below. I tried to warp it to EPSG:4326 but I got error. Do I miss something? Thanks, gdalwarp test.tif -t_srs EPSG:4326 t

[gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Hello, I have a DGM 10m tiff file (translated from xyz file: e.g: dgm10_32572_6020_1_sh.xyz - example: https://pastebin.com/40xSNqm4) in EPSG:25832 CRS with this gdalinfo as below. I tried to warp it to EPSG:4326 but I got error. Do I miss something? Thanks, gdalwarp test.tif -t_srs EPSG:4326

Re: [gdal-dev] gdalwarp results differ in different gdal versions?

That is correct, my image is a Mars southern pole image. Those radii are pulled from another file but I have run the command with the +a/b being in meters, specifically 3396000 and I still get the same result (missing polar information). I have also run the command using -wo SAMPLE_GRID=YES and no

Re: [gdal-dev] gdalwarp results differ in different gdal versions?

Meghan, Handling poles tend to be fragile, so perhaps something that worked previously no longer works. Did you try -wo SAMPLE_GRID=YES ? If that still doesn't work, the best is you open a ticket with an input image attached (dimensions reduced as much as possible while still reproducing th

[gdal-dev] gdalwarp results differ in different gdal versions?

Hello! I'm hoping someone can shine some light in my direction because I can't find any answers. I'm trying to warp a Polar Stereographic image into an Equal Cylindrical projection. When I run the gdalwarp command on older versions (specifically 1.8.1), my image looks as I would expect. When I ru

Re: [gdal-dev] gdalwarp and gdaltransform are inconsistent

Thank you for all your quick answer. So the conclusion is I need a geogrid file to do it. Even Rouault ezt írta (időpont: 2020. ápr. 20., H, 12:06): > On lundi 20 avril 2020 01:08:15 CEST jratike80 wrote: > > > Hi, > > > > > > When it comes to gdalwarp I believe that this part of the documentati

Re: [gdal-dev] gdalwarp and gdaltransform are inconsistent

On lundi 20 avril 2020 01:08:15 CEST jratike80 wrote: > Hi, > > When it comes to gdalwarp I believe that this part of the documentation > https://gdal.org/programs/gdalwarp.html is essential > > "Starting with GDAL 2.2, if the SRS has an explicit vertical datum that > points to a PROJ.4 geoidgrid

Re: [gdal-dev] gdalwarp and gdaltransform are inconsistent

I would like to add that the command that you used gdalwarp -t_srs EPSG:4326 -s_srs EPSG:2056 SWISSALTI3D_10_TIFF_CHLV95_LN02_2600_1196.tif test.tif of course must not alter the pixel values. There are other sort of single band raster files than DEMs and it would make no sense at all to apply dat

Re: [gdal-dev] gdalwarp and gdaltransform are inconsistent

Hi, When it comes to gdalwarp I believe that this part of the documentation https://gdal.org/programs/gdalwarp.html is essential "Starting with GDAL 2.2, if the SRS has an explicit vertical datum that points to a PROJ.4 geoidgrids, and the input dataset is a single band dataset, a vertical correc

[gdal-dev] gdalwarp and gdaltransform are inconsistent

Hi, I'm new here, and just started using gdal, so maybe I'm misunderstanding something, but I found that gdalwarp and gdaltransform produces different results. The gdaltransform command is : echo 260 1196000 768 | gdaltransform -t_srs EPSG:4326 -s_srs EPSG:2056 and the result is: 7.438633171

Re: [gdal-dev] gdalWarp generates a black image when I use the outputBounds option

Hello, I think i found the erro, my conversion is not giving the ' - ' signal on the longitude. Thanks for the help! -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://

Re: [gdal-dev] gdalWarp generates a black image when I use the outputBounds option

Hi, Well, based on the errors I tend to do I am pretty sure that the bounds are not OK. Test data can be what ever raster, or you can use gdal_edit and paint your original image into totally red or what ever color you want. But I am sure that you can resolve your problem also by your own with some

Re: [gdal-dev] gdalWarp generates a black image when I use the outputBounds option

I am converting the Tiles Map Service coordinates to the ESPG:3857 projection. I have pretty sure that the tiles coordinates are between the master image's bounds. I use the command line gdalwarp using the -te flag but I have the same output. Sorry, but I am working with private data and I don't

Re: [gdal-dev] gdalWarp generates a black image when I use the outputBounds option

Hi, What I think first is that your output bounds do not hit your source data but with the information that you provide it is impossible to know. Have you considered to use the gdalwarp executable for testing? If you can't make it to work please send a link to some test data. -Jukka Rahkonen-

[gdal-dev] gdalWarp generates a black image when I use the outputBounds option

Hi, I am trying to crop a .tiff image. However, when I use the outputBounds option the output file is not what I was expecting. Here is my fuction code: def warp(t): bounds = t.getMercatorCorners() #calculates the minX, minY, maxX and maxY list(bounds) raster = gdal.Open("img/pre/104

Re: [gdal-dev] gdalwarp -dstalpha does not create alpha band

Jukka After reading your message assuring me that -dstalpha does work for others, and since what I was doing seemed so basic, I decided to re-boot my computer and try again (I have recently been using some large graphics files). Lo and behold I am now getting the expected result, transparency out

Re: [gdal-dev] gdalwarp -dstalpha does not create alpha band

Hi, It does really work for others. I just verified with GDAL 3.1.0dev and 2.4.2 on Windows. Could you repeat the test carefully with the bare minimum gdalwarp -dstalpha without_alpha.tif with_alpha.tif If it does not work please arrange a reproducible test case for us by telling how to get exa

[gdal-dev] gdalwarp -dstalpha does not create alpha band

For gdalwarp (GDAL 2.3.1), using -dstalpha (hoping to get transparent pixels outside the original image area) ala gdalwarp -dstalpha -srcnodata 0 -t_srs EPSG:4326 in.tif out.tif for an input geotiff RGB image (created by gdal_translate) I get an RGB output image, not an RGBA as I expected. Fro

Re: [gdal-dev] gdalwarp, by reading .RPB file

Hi Elmir, RPCs are just an approximation to the underlying camera model via rational polynomials; so just a pair of functions that go from XYZ world coordinates to line/sample in the image. To make an orthophoto, you first figure out where the orthophoto is located on the earth, and at each proje

Re: [gdal-dev] gdalwarp, by reading .RPB file

Elmir, > I was trying to orthorectify World View 4 raster image using the gdalwarp. > I used '-rpc' with the input of DEM file. > However, I am wondering whether this method of orthorectification is making > use of the ".RBP" file data available with the World View image OR is it > just warping wi

[gdal-dev] gdalwarp, by reading .RPB file

Hello GDAL Developer, I was trying to orthorectify World View 4 raster image using the gdalwarp. I used '-rpc' with the input of DEM file. However, I am wondering whether this method of orthorectification is making use of the ".RBP" file data available with the World View image OR is it just war

Re: [gdal-dev] gdalwarp into an existing destination from python

Awesome, that's what I was looking for :-) Thanks !!! Olivier On Wed, 27 Nov 2019 at 20:28, Even Rouault wrote: > Olivier, > > > Is there a flag or something to achieve same behaviour as command line ? > I > > looked carefully in the python api doc, but couldn't find it... > > Not exacly a fla

Re: [gdal-dev] gdalwarp into an existing destination from python

Olivier, > Is there a flag or something to achieve same behaviour as command line ? I > looked carefully in the python api doc, but couldn't find it... Not exacly a flag, but: destDS = gdal.Open("dest.tif", gdal.GA_Update) gdal.Warp(destDS, "source.tif", cutlineDSName="cutline.shp") Cheers, Ev

[gdal-dev] gdalwarp into an existing destination from python

Dear list, When I use gdalwarp from command line and set output to an existing file, the contents get mosaic-ed in the existing file (as expected and documented). $> gdalwarp -cutline cutline.shp source.tif dest.tif But when doing the from python, the existing destination file get overwritten.

Re: [gdal-dev] gdalwarp overhead on linux but not on windows

UTC 2019 x86_64 x86_64 x86_64 GNU/Linux real 0m0.399s user 0m0.032s sys 0m0.023s -Jukka Rahkonen- Lähettäjä: Brent Wood Lähetetty: keskiviikko 20. marraskuuta 2019 1.12 Vastaanottaja: gdal-dev@lists.osgeo.org; Rahkonen Jukka (MML) Aihe: Re: [gdal-dev] gdalwarp overhead on linux but not on

Re: [gdal-dev] gdalwarp overhead on linux but not on windows

Ummm... How much is due to the very different version of GDAL vs docker overhead? Any chance of using the same GDAL version for both tests? Brent Wood On Wednesday, November 20, 2019, 11:20:50 AM GMT+13, jratike80 wrote: Hi, I have been told that Docker has overhead with everythin

Re: [gdal-dev] gdalwarp overhead on linux but not on windows

Hi, I have been told that Docker has overhead with everything, with these numbers as evidence: ubuntu@t:/etc$ time gdalinfo --version GDAL 2.2.3, released 2017/11/20 real 0m0.030s user 0m0.017s sys 0m0.013s ubuntu@t:/etc$ time docker exec -it 742a044b8ef1 gdalinfo --version GDAL 3.1.0dev-19f342

[gdal-dev] gdalwarp overhead on linux but not on windows

Hi guys, I've been playing quite a lot with "wrapper_GDALWarpDestName" and a .net core wrapper (https://github.com/MaxRev-Dev/gdal.netcore/). Everything is running fine, I'm quite happy to see the same behavior on windows and linux. Sometimes linux is faster for reading and writing raster, thi

Re: [gdal-dev] gdalwarp -t_srs proj=utm

Forgot to mention, this is to reproject from lat/long to UTM. Thanks, Shawn From: gdal-dev [gdal-dev-boun...@lists.osgeo.org] on behalf of Gong, Shawn [shawn.g...@mdacorporation.com] Sent: September-05-19 5:12 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev

[gdal-dev] gdalwarp -t_srs proj=utm

Hi GDAL list, gdalwarp -t_srs '+proj=utm +zone=XX +datum=WGS84' source.tif result.tif Is there a way for GDAL to automatically figure out the Zone #, so I don't have to provide XX ? Thanks, Shawn This electronic correspondence, including any attachments, is intended solely for the use of the

Re: [gdal-dev] gdalwarp - Erroneous Outputs

On lundi 8 avril 2019 08:55:49 CEST Bryant wrote: > Hello! > > I've been trying to use /gdalbuildvrt/ and /gdalwarp/ to merge, project, and > crop a set of overlapping images with a new resolution. > > However, I've been running into an issue where the edges of the resulting > image have nondeter

Re: [gdal-dev] gdalwarp - Erroneous Outputs

bump -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalwarp: different results between 2.3.0 and 2.4.0

I have a small GRIB file whose coordinate system is GRIB-specific, and it spans the whole world, from longitude 0 to 360. I would like to read this raster from an EPSG:4326 perspective, so I'm using gdalwarp to warp it to a VRT : gdalwarp -t_srs EPSG:4326 -of VRT input.grib output.vrt When I i

Re: [gdal-dev] Gdalwarp with geolocation Array and nodata value

On lundi 22 avril 2019 08:43:30 CEST Andre Joost wrote: > Dear list, > > as a follow-up to > https://gis.stackexchange.com/questions/319147/using-gdalwarp-for-reprojecti > ng-netcdf-file with a sample netcdf file linked in the comments: > > The netcdf (really HDF5) contains lat and lon bands to r

[gdal-dev] Gdalwarp with geolocation Array and nodata value

Dear list, as a follow-up to https://gis.stackexchange.com/questions/319147/using-gdalwarp-for-reprojecting-netcdf-file with a sample netcdf file linked in the comments: The netcdf (really HDF5) contains lat and lon bands to reference the cells to WGS84 coordinates. Unfortunately, some rows

[gdal-dev] gdalwarp - Erroneous Outputs

Hello! I've been trying to use /gdalbuildvrt/ and /gdalwarp/ to merge, project, and crop a set of overlapping images with a new resolution. However, I've been running into an issue where the edges of the resulting image have nondeterministic, erroneous values (ie. very large and small values) and

[gdal-dev] Gdalwarp mosaic large GeoTIFF dataset into GeoPackage

Hi! I'm trying to mosaic a large GeoTIFF dataset into a GeoPackage with Gdalwarp (no reprojection). There are 512 .tif files, each with a single grayscale band, and 1 meter resolution. I'm using -cutline to clip the dataset to a slightly smaller extent. Gdalwarp initially outputs the dimensions

Re: [gdal-dev] GDALWarp Datasets

Hello, Okay, all of that is well-taken. Thank you for your response. > If you're not interested in the pixel values, using GDALSuggestedWarpOutput2() is a better fit. Yes, my question was worded a bit unclearly: I am essentially interested in retrieving warped tiles so the pixels are of primary

Re: [gdal-dev] GDALWarp Datasets

On vendredi 15 février 2019 00:06:28 CET James McClain wrote: > Hello, > > If I may, I would like to a few questions regarding how best to use the > GDALWarp function ( > https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalwarp_lib.cpp#L748-L7 > 70) and the datasets that it creates. > > In pa

[gdal-dev] GDALWarp Datasets

Hello, If I may, I would like to a few questions regarding how best to use the GDALWarp function ( https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalwarp_lib.cpp#L748-L770) and the datasets that it creates. In particular, I am experimenting with using such datasets to read warped extents on

Re: [gdal-dev] gdalwarp doesn't use the VSIL curl cache ?

On mardi 15 janvier 2019 09:49:53 CET Maxime Riché wrote: > I am developing a tile server for COGTiff. > When I open a dataset, the COGTiff metadata are cached in the curl cache. > The beginning of the file is only downloaded when the first tile is served > (using the same tiff). This is as I was e

[gdal-dev] gdalwarp doesn't use the VSIL curl cache ?

I am developing a tile server for COGTiff. When I open a dataset, the COGTiff metadata are cached in the curl cache. The beginning of the file is only downloaded when the first tile is served (using the same tiff). This is as I was expecting. But when I serve several time the same tile (only this

Re: [gdal-dev] gdalwarp -overwrite

Thank you Even. Shawn From: Even Rouault [even.roua...@spatialys.com] Sent: January-09-19 4:40 AM To: gdal-dev@lists.osgeo.org Cc: Gong, Shawn Subject: Re: [gdal-dev] gdalwarp -overwrite On mardi 8 janvier 2019 21:27:54 CET Gong, Shawn wrote: > Hi l

Re: [gdal-dev] gdalwarp -overwrite

On mardi 8 janvier 2019 21:27:54 CET Gong, Shawn wrote: > Hi list, > > I am switching from calling gdalwarp to using gdal.Warp( ) > One of the gdalwarp parameters is "-overwrite" but I can't find it in > gdal.WarpOptions > > Do I need it, is it a default option if I don't specify it? If you use

[gdal-dev] gdalwarp -overwrite

Hi list, I am switching from calling gdalwarp to using gdal.Warp( ) One of the gdalwarp parameters is "-overwrite" but I can't find it in gdal.WarpOptions Do I need it, is it a default option if I don't specify it? Thanks, Shawn This electronic correspondence, including any attachments, is in

[gdal-dev] Gdalwarp producing odd results around 0 degree longitude

Hello, I am warping ECMWF grib data (full globe, 0.25 degree resolution) to match the SEVIRI geostationary satellite projection. I use this command: gdalwarp -overwrite -ot Float32 -t_srs "+proj=geos +a=6378169 +b=6356583.8 +lon_0=0.0 +h=35785831" -te -5570248.832537 5570244.832537 5567248.4

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

Hi Even, What version of PROJ does your GDAL 2.3.2 build use ? PROJ 5 ? > And your GDAL 2.2.2 build: PROJ 4 ? > GDAL 2.3.2 uses PROJ 5.2.0. GDAL 2.2.3 uses PROJ.4 version 493 GDAL 2.2.2 uses PROJ.4 version 480 > If so, that might explain things. The ESRI:102164 translated as a proj > string >

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

On lundi 17 décembre 2018 14:25:02 CET Pedro Venâncio wrote: > Hi Andre, > > Given the magnitude of the shift, I suspected that could be due to the lack > of +towgs84 parameters of ESRI 102164. What version of PROJ does your GDAL 2.3.2 build use ? PROJ 5 ? And your GDAL 2.2.2 build: PROJ 4 ? If

  1   2   3   4   5   6   >