#6731 closed defect (invalid)
gdal2tiles error with EPSG:3857
Reported by: | DevonF | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 2.1.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
I have generated a GeoTiff using QGIS's Georeferencer plugin (which uses GDAL). It's projection was set to ESPG:3857.
If I do gdal2tiles.py -z 11 image.tif tiles, I get the error:
Generating Base Tiles: ERROR 5: Illegal values for buffer size ERROR 5: Illegal values for buffer size Traceback (most recent call last): File "/usr/bin/gdal2tiles.py", line 2436, in <module> main() File "/usr/bin/gdal2tiles.py", line 2433, in main gdal2tiles.process() File "/usr/bin/gdal2tiles.py", line 481, in process self.generate_base_tiles() File "/usr/bin/gdal2tiles.py", line 1309, in generate_base_tiles dsquery.WriteRaster(wx, wy, wxsize, wysize, data, band_list=list(range(1,self.dataBandsCount+1))) File "/usr/lib/python2.7/dist-packages/osgeo/gdal.py", line 1996, in WriteRaster buf_pixel_space, buf_line_space, buf_band_space ) TypeError: not a string
Same thing happens if I specify -s EPSG:3857. However if I specify -s EPSG:4326 or start with a geotiff with that projection, there is no problem. Thus gdal2tiles.py -s EPSG:4326 -z 11 file.tif tiles works for EPSG:3857
using GDAL 2.1.1, released 2016/07/07 on Ubuntu 16.10
Attachments (5)
Change History (16)
by , 7 years ago
by , 7 years ago
Attachment: | to EPSG3857 added |
---|
by , 7 years ago
Attachment: | to EPSG4326 added |
---|
by , 7 years ago
Attachment: | original.tif added |
---|
comment:2 by , 7 years ago
I attached the output from gdalinfo. The original is what was output by the georeferencer plugin which is in EPSG:3857 format (I scaled image significantly for uploading). The 'to EPSG3857' and 'to EPSG4326' are after using gdal_translate with the respective -s parameter. Only the EPSG:4326 works as it, the other two fail with the error mentioned above unless the -s EPSG:4326 is given to gdal2tiles.py
comment:3 by , 7 years ago
I believe that there has been some trouble with the QGIS georeferencer. The coordinates in "to EPSG3857" do not make sense. They seem to be EPSG:4326 longitude-latitude degrees but only marked in the metadata as if they were meters in EPSG:3857. With that information GDAL believes that your image in very close to the Null Island https://en.wikipedia.org/wiki/Null_Island and the size of the whole image is about 40 centimeters by 20 centimeters.
Origin = (-76.058164576309238,45.586147307354906) Pixel Size = (0.000049190291904,-0.000049190291904) ...Corner Coordinates: Upper Left ( -76.0581646, 45.5861473) ( 0d 0' 2.46"W, 0d 0' 1.47"N) Lower Left ( -76.0581646, 45.3802859) ( 0d 0' 2.46"W, 0d 0' 1.47"N) Upper Right ( -75.6625762, 45.5861473) ( 0d 0' 2.45"W, 0d 0' 1.47"N) Lower Right ( -75.6625762, 45.3802859) ( 0d 0' 2.45"W, 0d 0' 1.47"N) Center ( -75.8603704, 45.4832166) ( 0d 0' 2.45"W, 0d 0' 1.47"N)
comment:4 by , 7 years ago
Ya they don't look good. But I used gdal_translate to go from the original EPSG:3857 to EPSG:4326 then back to EPSG:3857 and it looks the same as the "to EPSG3857". I also tried a few things with gdal_warp but didn't get any luck either. And I thought the georeferencer plugin uses gdal_translate.
When I run gdal2tiles.py using EPSG:4326, the tiles visually appear to be pretty bang-on when overlayed on another map.
I should note that those gdalinfo outputs are from the original full sized image, not the scaled one. So just the dimensions and pixel size should be different.
comment:5 by , 7 years ago
The main problem is that the tiff file "original.tif" from the QGIS georeferencer cannot have correct georeferencing. You must fix it first. All work you are doing with experimenting with gdal2tiles is wasting your time.
I suggest to ask from QGIS-users mailing list or perhaps from gis.stackexchange site advice for using the georeferencer correctly. I guess that you have claimed that you have measured the ground control points in EPSG:3857 but you have really measured them in EPSG:4326, or something like that.
comment:6 by , 7 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
by , 7 years ago
Attachment: | original.png added |
---|
comment:7 by , 7 years ago
In addition to the original image for knowing what went wrong you should describe what did you with the georeferencer. It should show the gdal_translate and gdalwarp commands which it is going to perform when you run the georeferencing. But still this is wrong forum for discussion. I recommend QGIS users.
comment:8 by , 7 years ago
Here it is from scratch without involving QGIS. I uploaded 'original.png' which is the original plain png before georeferencing. I simplified it dramatically to save space.
The convert command is required because gdal2tiles can't handle palleted images:
convert original.png -type truecolor PNG24:original_rgb.png
I verified the GCP points were correct using GIMP.
gdal_translate -of GTiff -gcp 4461.4 1584.9 -75.8 45.45 -gcp 1415.4 1218.3 -75.95 45.52 -gcp 2279.6 353.9 -75.88 45.53 -gcp 3755.7 104.89 -75.80 45.52 original_rgb.png temp.tif
At this point the temp.tif has no SRS, just GCPs
gdalwarp -t_srs EPSG:3857 temp.tif out.tif
Now it has the SRS, no more GCPs
gdal2tiles.py -z 11 out.tif tiles
I get the same error unless I use:
gdal2tiles.py -s EPSG:4326 -z 11 out.tif tiles
comment:10 by , 7 years ago
Your error is in this
gdalwarp -t_srs EPSG:3857 temp.tif out.tif
You have inserted GCPs which are probably in EPSG:4326 but now you claim (by not giving the source srs with -s_srs) that they are in EPSG:3857.
comment:11 by , 7 years ago
You were right, I'm barking up the wrong tree. I didn't understand the projections well enough. I just assumed it did reprojections but always using lat/long.
When I see code crashing like that with python debug errors I tend to be think it's a programming mistake. I'm used to seeing sanity checks which would suggest it's my fault.
Thanks for your help.
Add at least gdalinfo report about your EPSG:3857 file, even better with a link to the image itself.
Usually it is better to write first to gdal-dev mailing list and discuss a bit before making a bug report. Sometimes what looks like a bug may be caused by faulty data or some other reason.