[gdal-dev] gdal2tiles with GeoTIFF which crosses antimeridian?

lars.schylberg at blixtmail.se lars.schylberg at blixtmail.se
Sat Nov 28 12:14:10 PST 2020


Good Evening,

If You want to get rid of the white areas you do -dstalpha in the penultimate gdalwarp step.
That setting is to get all the areas outside to be transparent when You warp.

gdalwarp -t_srs EPSG:3857 -overwrite -multi -wo NUM_THREADS=ALL_CPUS -dstalpha -wm 1024 -tr 169 169 --config GDAL_CACHEMAX 1024 -co TILED=YES temp.vrt rgb.tif

I was thinking about another method to shift the image yesterday based on this idea:
https://github.com/OSGeo/gdal/issues/1182 ( (https://github.com/OSGeo/gdal/issues/1182)Evens last comment).
But my experiments didn't work out, to shift Web Mercator (3857). But I guess the computation should be less if that worked.

/Lars S.
28 november 2020 kl. 16:44, "James Russo" <jr at halo3.net (mailto:jr at halo3.net?to=%22James%20Russo%22%20<jr at halo3.net>)> skrev:
Good Morning, 
I have a stackoverflow on this issue if anyone can give some info. It turns out that if you force the resolution in the warp, the resulting file does look good.
https://gis.stackexchange.com/questions/380002/issue-creating-tiles-from-geotiff-which-crosses-the-180th-meridian/ (https://gis.stackexchange.com/questions/380002/issue-creating-tiles-from-geotiff-which-crosses-the-180th-meridian/)  
 On Thu, Nov 26, 2020 at 10:01 AM James Russo <jr at halo3.net (mailto:jr at halo3.net)> wrote:   
Lars,
Sorry! My apologies. Despite double checking, there was a copy and paste error in the script. The second gdalwarp with the -te was outputting to the same path as the no sliced version. Corrected script below. I appreciate you looking into this with me! 
*additionally, My original reply directly to you also included a typo. This script should be good! 
-jr
---snip--- 
#!/bin/bash 
wget -SN https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip (https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip) && unzip -xo AK_WallPlan_2.zip  
 mv "Alaska Wall Planning Chart 2.tif" Alaska_Wall_Planning_Chart_2.tif
gdal_translate -expand rgb -strict -co TILED=YES -co COMPRESS=LZW -co BIGTIFF=YES Alaska_Wall_Planning_Chart_2.tif alaska_expanded_rgb.vrt
gdalwarp -t_srs EPSG:3857 -r lanczos -overwrite -multi -wo NUM_THREADS=ALL_CPUS -wm 1024 --config GDAL_CACHEMAX 1024 -co TILED=YES alaska_expanded_rgb.vrt alaska_warped.vrt
gdalwarp -t_srs EPSG:3857 -te -19979999 6016546 -13438444 11497579 -r lanczos -overwrite -multi -wo NUM_THREADS=ALL_CPUS -wm 1024 --config GDAL_CACHEMAX 1024 -co TILED=YES alaska_expanded_rgb.vrt alaska_warped_sliced_at_180.vrt
rm -rf alaska_tiles_no_slice
rm -rf alaska_tiles_sliced_at_180
gdalinfo alaska_warped.vrt
time gdal2tiles.py -vvv -z 0-9 --processes=16 -r lanczos -w leaflet alaska_warped.vrt alaska_tiles_no_slice
gdalinfo alaska_warped_sliced_at_180.vrt
time gdal2tiles.py -vvv -z 0-9 --processes=16 -r lanczos -w leaflet alaska_warped_sliced_at_180.vrt alaska_tiles_sliced_at_180  
---snip---     
 On Thu, Nov 26, 2020 at 9:55 AM <lars.schylberg at blixtmail.se (mailto:lars.schylberg at blixtmail.se)> wrote: 
Hi,

I tried to reproduce your experiment. It seems like the command that produces "alaska_warped_sliced_at_180.vrt" is missing in your script.
I guess that step could be vital to understand what is going on.

Best regards

/Lars Schylberg

26 november 2020 kl. 03:42, "James Russo" <jr at halo3.net (mailto:jr at halo3.net?to=%22James%20Russo%22%20%3Cjr at halo3.net%3E)> skrev:
Good Evening, 
I'm just following up on this question from a few days ago with some more information and the script I am using which reproduces this issue. 
The example results can be found here at the s3 links below and are all generated from the same original GeoTIFF. The only difference is that on one of them I slice off all data left of the 180, the other one the map is left complete. The html files are set to the same example point and zoom level to show how that without slicing the file, the image quality is very poor. The one thing I notice is that if I include the 180 meridian, the number of tiles generated is far larger (46k vs 8k). 
Bad Results:  
http://halo3.net/alaska_tiles_no_slice/leaflet.html (http://halo3.net/alaska_tiles_no_slice/leaflet.html) 
Good Results: 
http://halo3.net/alaska_tiles_sliced_at_180/leaflet.html (http://halo3.net/alaska_tiles_sliced_at_180/leaflet.html) 
Below is the script I use to generate both tile sets. It will automatically download, unzip and process the input file I am using producing the same results shown at the links above. 
I'd appreciate any insight into the issue and how I might be able to get it resolved? I'm still quite a novice at all this GIS stuff, but it has been a fun experience so far. 
Thanks, 
-jr 
---snip--- 
#!/bin/bash 
wget -SN https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip (https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip) && unzip -xo AK_WallPlan_2.zip 
mv "Alaska Wall Planning Chart 2.tif" Alaska_Wall_Planning_Chart_2.tif
gdal_translate -expand rgb -strict -co TILED=YES -co COMPRESS=LZW -co BIGTIFF=YES Alaska_Wall_Planning_Chart_2.tif alaska_expanded_rgb.vrt
gdalwarp -t_srs EPSG:3857 -r lanczos -overwrite -multi -wo NUM_THREADS=ALL_CPUS -wm 1024 --config GDAL_CACHEMAX 1024 -co TILED=YES alaska_expanded_rgb.vrt alaska_warped.vrt
gdalwarp -t_srs EPSG:3857 -te -19979999 6016546 -13438444 11497579 -r lanczos -overwrite -multi -wo NUM_THREADS=ALL_CPUS -wm 1024 --config GDAL_CACHEMAX 1024 -co TILED=YES alaska_expanded_rgb.vrt alaska_warped.vrt
rm -rf alaska_tiles_no_slice
rm -rf alaska_tiles_sliced_at_180
gdalinfo alaska_warped.vrt
time gdal2tiles.py -vvv -z 0-9 --processes=16 -r lanczos -w leaflet alaska_warped.vrt alaska_tiles_no_slice
gdalinfo alaska_warped_sliced_at_180.vrt
time gdal2tiles.py -vvv -z 0-9 --processes=16 -r lanczos -w leaflet alaska_warped_sliced_at_180.vrt alaska_tiles_sliced_at_180 
---snip--- 
 On Tue, Nov 24, 2020 at 6:20 AM James Russo <jr at halo3.net (mailto:jr at halo3.net)> wrote: Good Evening,
GIS novice here. I have a GEOTiff that I'm trying to create tiles from which crosses the 180. It's a FAA sectional chart from the US used for aviation. If I slice off anything west of the 180, I can generate the tiles and they look good. If I don't the area of the tiles is super large and the resulting tile set is very pixelated. 
The source file is located here in zip form (https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip (https://aeronav.faa.gov/content/aeronav/Planning/AK_WallPlan_2.zip)) 
I've tried some of the solutions that specify to use the CONFIG_LONG option, but that doesn't seem to be impacting anything. The only solution I have come up with is to cut off the area which crosses the 180 which yields good results. 
I've included below the commands I've been using. I'm looking for any suggestions/guidance. I realize this is somewhat of a common problem. Even MapTiler had the problem, but they have sent an updated version which supposedly fixes it, but I can't afford that solution at this point so I'd like to stick to GDAL if possible. 
Thanks, 
-jr 
--- snip -- 
gdal_translate  
-expand rgb 
-strict 
-co TILED=YES 
-co COMPRESS=LZW 
-co BIGTIFF=YES 
alaska.tif alaska_expanded_rgb.vrt

gdalwarp 
-overwrite 
-cutline "Alaska_Wall_Planning_Chart.shp" 
-crop_to_cutline 
-cblend 10 
-r lanczos 
-dstalpha 
-co ALPHA=YES 
-co TILED=YES 
-multi 
-wo NUM_THREADS=ALL_CPUS 
-wm 1024 
--config GDAL_CACHEMAX 1024 
"alaska_expanded_rgb.vrt" 
"alaska_clipped.vrt"

gdalwarp 
-t_srs EPSG:3857 
-te -19497422 6016546 -13438444 11497579 
-r lanczos 
-overwrite 
-multi 
-wo NUM_THREADS=ALL_CPUS 
-wm 1024 
--config GDAL_CACHEMAX 1024 
-co TILED=YES 
"alaska_clipped.vrt" 
"alaska_warped.vrt" 
gdal2tiles.py -z 0-8 --processes=16 -r lanczos -w leaflet alaska_warped.vrt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201128/c5fb57fc/attachment.html>


More information about the gdal-dev mailing list