22
The math is described at:
http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/
…including the source code for command line utility and an online demonstration.
It is also pretty simple math:
function tile2long(x,z) { return (x/Math.pow(2,z)*360-180); }
function tile2lat(y,z) {
var n=Math.PI-2*Math.PI*y/Math.pow(2,z);
return (...
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....
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 ...
6
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.
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 ...
4
Seems to be the classic case of stale or poor documentation.
After a good deal of trial and error, this seems to work:
gdalbuildvrt -resolution lowest test.vrt BX*.tif BY*.tif
gdal2tiles -p raster -s nztm.prj test.vrt out
To be safe, i got a fresh prj from http://spatialreference.org/ref/epsg/2193/ and put that in nztm.prj
TBH im not sure what was the ...
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
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
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 ...
3
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:
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
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
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
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
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 ...
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
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.
3
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)
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
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 ...
2
MapTiler could help here. I read on their Google Group that if you tiled that missing piece into the folder where the other tiles were already made, it'll merge the tiles nicely. .
If that doesn't work for you, but you have ImageMagick installed you can try the script I wrote for the same purpose.
2
I've never did it but it seems gdal merge could be appropriate :
This utility will automatically mosaic a set of images. All the images must be in the same coordinate system and have a matching number of bands, but they may be overlapping, and at different resolutions. In areas of overlap, the last image will be copied over earlier ones.
Let us know!
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
Reading the GDAL API tutorial, under the section Using Create(), you'll see the following line:
dst_ds = driver.Create( dst_filename, 512, 512, 1, gdal.GDT_Byte )
I presume the default type is GDT_Byte which is why you are getting what you are getting.
Only top voted, non community-wiki answers of a minimum length are eligible
