15
Going from what @user30184 said in the comment.
This issue is that the gdal2tiles.py script tells gdal to output 'mercator' as EPSG:900913. This is fine as long as it knows how to convert to this.
The fix is to change the following line in gdal2tile.py (line 785):
if self.options.profile == 'mercator':
self.out_srs.ImportFromEPSG(900913)
to:
if self....
8
I noticed that gdal2tiles numbers the tiles from south to north (according to the TMS specification), while Openstreetmap and others do it from north to south. For my personal use, I changed the code of gdal2tiles to get it right again.
See also: http://osgeo-org.1560.x6.nabble.com/gdal2tiles-tiles-in-wrong-hemisphere-and-or-Openlayers-problem-td3742809....
7
I think all you need to do is reproject it using:
gdalwarp -co TILED=YES -co COMPRESS=DEFLATE -t_srs EPSG:3857 newImage.tif image.tif
and then tile it:
gdal2tiles.py newImage.tif
If your file is very large it make take a while.
6
The main point is that by default OpenLayers 3 follows the widely-used Google grid where x 0 and y 0 are in the top left. Grids like TMS where x 0 and y 0 are in the bottom left can be used by using the {-y} placeholder in the URL template, and tileUrlFunction is only necessary when really a custom tile grid is utilized.
When using gdal2tiles, the following ...
5
I'm not sure why, but gdal2tiles does not seem to like a combination of -z and -p raster.
So I used call gdal2tiles.bat -p raster ibcso_background_hq.tif
and got the right picture in all zoom levels:
5
When you run gdal2tiles command, three extra (html) files along with an xml file are created. These html files are sufficient to view these tiles in browser of system connected to internet. These files are:
a) googlemaps.html
b) openlayers.html
c) leaflet.html
The folder structure looks like the below:
You just need to copy the javascript library of ...
5
You should simply change your url to:
url: './data/maps/7068/temp/{z}/{x}/{-y}.png',
Why?
Because XYZ tiling scheme differs from TMS scheme (produced by gdal2tiles) for tiles.
It's because Y numbering starts at the top for XYZ and at the bottom for TMS (hence the minus sign in suggested url change)
4
gdal2tiles uses the TMS specification for tile naming (bottom to top), while Maptiler allows you to use the Google/Openstreetmap tile naming system (top to bottom).
See my answer to this topic on how to modify gdal2tiles.py for Google/OSM tile naming:
GDAL2Tiles: MapTiles from BSB/KAP are Switched
4
What finally worked for @RobotCaleb was the following:
Apply mask to alpha (band 4):
gdal_translate -mask 4 stadium3857.tif stadium3857_RGB.tif
2. Compute a new alpha channel from NoData values:
gdalwarp -dstalpha stadium3857_RGB.tif stadium3857_RGBA.tif
edit: apparently gdal2tiles does not need an alpha channel in the input dataset but also ...
4
It's simply because FWTools is so old that it does not use osgeo Python namespace as illustrated at the bottom of the GDAL Python section about import
You should install GDAL via OSGEO4W or GIS internal instead of using the outdated FWTools
4
As you say, the bottleneck for tiles generation is usually I/O. GPUs are meant for computationally expensive calculations with rather low I/O. So adding GPU processing will not help for things like this.
4
It's not a standard XYZ grid, i.e. the largest tile 25.38836208458858 * 256 = 6499.42069365467648 is bigger than the extent 6729085.88076 - 6724227.18297 = 4858.69779 That wouldn't be a problem if the origin was top left, but yours is bottom left so using a {-y} placeholder in the url won't work correctly. Instead you will need to specify the origin and ...
4
The fact that your map appears at Madagascar and not France is the clue here. It means that your axes are swapped (Madagascar is about as far south as France is West). So you need to switch round the order of the coordinates in your bounding box (and I would use the shorter EPSG:4326 instead of the proj4 string).
So your command becomes
gdal_translate -of ...
3
This same error threw me off, too. Adding NODATA transparency value parameter to the call fixed it for me, so instead of
gdal2tiles.py -z 1-10 ~/hfp_wgs/hdr.adf hpf-tiles
I called
gdal2tiles.py -z 1-10 -a 0,0,0 ~/hfp_wgs/hdr.adf hpf-tiles
and it started working. Note that the value had to be three numbers, one for each of RGB channels.
3
If you are in doubt, apply a zoom level option of --zoom 8-12 and check all resulting output folders.
It always worked for me with this option.
3
In order to avoid huge temporary files, you can use VRT as format of the mosaic file, whose main advantage is that it's just an XML file that will be created immediately:
:: create the mosaic (optionally setting the target extent and resolution)
gdalbuildvrt [-te xmin ymin xmax ymax] [-tr xres yres] mosaic.vrt *.sid
:: generate tiles from mosaic
gdal2tiles....
3
for resolve the problem of black areas is necessary to proceed this way:
1) create a virtual mosaic of the images with the param -vrtnodata 255:
gdalbuildvrt test.vrt -vrtnodata 255 *.tif
this add a white background to the mosaic
see this explanation: http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023032.html
2) download the correct prj file from ...
3
You would probably be interested in Leaflet.Control.SideBySide plugin, it provides that exact functionality (demo).
However, it assumes that your tiles already perfectly match.
I do not know unfortunately how you can specify in gdal2tiles a Z, X, Y offset. But you might be interested in that post: Specifying Lat & Long for Leaflet TileLayer. Note that ...
3
Rather than reinvent the wheel, I strongly recommend Geoserver. It does exactly what you want, plus has integrated tile caching. It is open source and the de facto implementation of the various OCG web mapping protocols and can simplify your tool chain a lot (as you won't need to implement mapnik and mod_tile. It integrates well with PostGis too.
EDIT:
...
3
I would use gdal_translate http://www.gdal.org/gdal_translate.html with Virtual raster (.VRT) output http://www.gdal.org/gdal_vrttut.html as an interim format.
gdal_translate -of VRT -projwin ulx uly lrx lry input.png output.vrt
Place the upper left and lower right coordinates of the bounding box as -projwin values. Notice the order which is different from ...
3
I was using the wrong options in the OSGeo4W installer.
If going down the "Express Desktop Install" path, gdal2tiles either comes with the "QGIS", "OpenEV", or "GRASS GIS" option. It's not provided under the "GDAL" option.
3
Two things (and @rumski20) helped to get this going:
I was referencing Python27 not realizing that gdal2tiles requires Python36
I referenced every .exe or .py directly
Probably a better way to do this, but it works for now.
SET GDAL_DATA=C:\OSGeo4W64\apps\gdal-dev\data
SET GDAL_DRIVER_PATH=C:\OSGeo4W64\bin\gdalplugins
SET OSGEO4W_ROOT=C:\OSGeo4W64
SET ...
3
You have 13 band imagery, but to make a PNG tile you need to restrict it to just the 3 RGB values. You can build a VRT "virtual file" that selects just the RGB bands from the source:
gdalbuildvrt -b [red] -b [green] -b [blue] newFile.vrt newFile.tif
and then try to run gdal2tiles newFile.vrt on that.
You could also skip the gdal_warp step by including the ...
3
As you noticed from the gdal2tiles documentation https://gdal.org/programs/gdal2tiles.html, the Python script deals well only with 8-bit input images.
Note
Inputs with non-Byte data type (i.e. Int16, UInt16,…) will be
clamped to the Byte data type, causing wrong results. To awoid this it
is necessary to rescale input to the Byte data type using
...
2
It's because gdal2tiles generates the tiles in TMS format. You need to enable it on your map or do a small calculation on the fly in order to display the tiles.
2
Hopefully all you need to do is to set the tms option to true in Leaflet's L.tileLayer constructor. See docs here.
2
I just ran into this same/similar problem. What fixed my problem was to make the image large enough for the gdal2tiler to make proper tiles. I made my image evenly divisible by 256px, so this may have be necessary as well.
I initially had a 16128px wide image and was trying to create zoom levels between 0-7. The gdal2tiler worked as expected when I tiled ...
2
This is an old question, but I needed the same thing and found a solution. I modified the gdal2tiles.py file (as suggested by user30184). After changing all of the "256" values in the code to "512", I found that the modified gdal2tiles script did create the tiles in 512x512 resolution. I also tested this using MapBox and confirmed that the higher resolution ...
2
To run gdal2tiles.py on a multiple images, use gdalbuildvrt to build a virual raster from those images first. Then you can run gdal2tiles on the .vrt file.
gdalbuildvrt -o merged.vrt file1.jp2 file2.jp2 ....
gdal2tiles.py merged.vrt output_folder/
If you are running it on large files, check out the enhanced version of the script that uses parallel ...
Only top voted, non community-wiki answers of a minimum length are eligible
