Le lundi 24 août 2015 06:35:53, Mike Manning a écrit : > Hi guys, > > > > I've got an interesting one - I have some GeoTIFF Files that I've converted > to EPSG:3857 from GeoStationary as follows: > > > > # gdalwarp -tr 2000 2000 -co tfw=yes -t_srs epsg:3857 -te 10018754.17 > -7361866.11 20037508.34 -0.00 > /storage/sat_data/20150824/IDE00422.201508240100.tif > /storage/tmp/IDE00422.201508240100.tif > > > > Using gdalinfo reveals the following about the newly created GeoTIFF file: > > > > # gdalinfo IDE00422.201508240100.tif > > Driver: GTiff/GeoTIFF > > Files: IDE00422.201508240100.tif > > Size is 5009, 3681 > > Coordinate System is: > > PROJCS["WGS 84 / Pseudo-Mercator", > > GEOGCS["WGS 84", > > DATUM["WGS_1984", > > SPHEROID["WGS 84",6378137,298.257223563, > > AUTHORITY["EPSG","7030"]], > > AUTHORITY["EPSG","6326"]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433], > > AUTHORITY["EPSG","4326"]], > > PROJECTION["Mercator_1SP"], > > PARAMETER["central_meridian",0], > > PARAMETER["scale_factor",1], > > PARAMETER["false_easting",0], > > PARAMETER["false_northing",0], > > UNIT["metre",1, > > AUTHORITY["EPSG","9001"]], > > EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 > +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext > +no_defs"], > > AUTHORITY["EPSG","3857"]] > > Origin = (10018754.169999999925494,0.000000000000000) > > Pixel Size = (2000.000000000000000,-2000.000000000000000) > > Metadata: > > AREA_OR_POINT=Area > > Image Structure Metadata: > > INTERLEAVE=BAND > > Corner Coordinates: > > Upper Left (10018754.170, 0.000) ( 90d 0' 0.00"E, 0d 0' 0.01"N) > > Lower Left (10018754.170,-7362000.000) ( 90d 0' 0.00"E, 55d 0' 2.48"S) > > Upper Right (20036754.170, 0.000) (179d59'35.61"E, 0d 0' 0.01"N) > > Lower Right (20036754.170,-7362000.000) (179d59'35.61"E, 55d 0' 2.48"S) > > Center (15027754.170,-3681000.000) (134d59'47.81"E, 31d22'14.91"S) > > Band 1 Block=5009x1 Type=Byte, ColorInterp=Gray > > > > It looks like the map has the correct coordinates however when I run the > gdal2tiles program it errors out: > > > > gdal2tiles.py -k -g <api_key> IDE00422.201508240100.tif mercour > > > > ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files. Is this > a valid > > EPSG coordinate system? > > ERROR 6: No translation for an empty SRS to PROJ.4 format is known. > > ERROR 6: No translation for an empty SRS to PROJ.4 format is known. > > 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 2262, in <module> > > gdal2tiles.process() > > File "/usr/bin/gdal2tiles.py", line 478, in process > > self.generate_base_tiles() > > File "/usr/bin/gdal2tiles.py", line 1276, 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 796, in > WriteRaster > > buf_pixel_space, buf_line_space, buf_band_space ) > > TypeError: not a string > > > > I'm running "GDAL 1.10.1, released 2013/08/26" on Debian Jessie. I've read > that version 1.6 had this issue as it didn't know what EPSG:3857 is but I'm > running 1.10 so it can't be that.
Mike, apparently this is due to Debian packaging of GDAL where one ressource file that contains the definition of EPSG:900913 has been removed. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745702 and confirmed by https://packages.debian.org/jessie/i386/libgdal1h/filelist 2 possible workarounds : - download https://svn.osgeo.org/gdal/trunk/gdal/data/cubewerx_extra.wkt and copy it to /usr/share/gdal/1.10 so as to get 900913 - edit /usr/bin/gdal2tiles.py and replace all occurences of 900913 by 3857 Even > > > > Cheers, Mike -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
