1

I am getting different X and Y values for tiles from gdal2tiles.py when in a PC (OSGeo4W - GDAL 1.9.2) environment and Linux (GDAL 1.10.1). It seems to me that the newer 1.10.2 x's and y's are wrong (not respecting the specified origin).

Is this a bug, which result is correct, and how do I get them to behave the same?

===

Details: I've created a sample tileset on a PC in windows using the tools from GDAL 1.9.2 in OSGeo4W for a map in projection NZTM2000 (EPSG:2193). The resulting tiles are generated as-per my expectations, and the origin from which the tiles are numbered is the origin of the projection (+lat_0=0 +lon_0=173).

Having perfected this with a small map area, I switched to a cloud server running linux and gdal1.10.1. The process appears to run successfully - tiles are generated, BUT the tile x and y numbers are different.

After much stuffing around, I've realised that the x and y values used match those used for the same geographic area when using the default EPSG:4326.

During troubleshooting I have run the gdal2tiles on the same single map sheet with the same command line options in both environments, manually specifying the SRS in case the definitions differ, and got two different results. I've also tested it using the built-in projection -s EPSG:2193.

python gdal2tiles.py test.tif -s '+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs' -z 5-10

PC / Windows / Cygwin:
mbriggs@forestero
/d/OSGeo4W/maps_past $ ls test/11/
1116/ 1117/ 1118/
mbriggs@forestero
/d/OSGeo4W/maps_past $ ls test/11/1116
1303.png* 1304.png*
mbriggs@forestero
/d/OSGeo4W/maps_past $

Linux:
mbriggs@dev:~$ ls
test/11
2022 2023 2024 2025
mbriggs@dev:~$ ls
test/11/2022
767.png 768.png 769.png
mbriggs@dev:~$



mbriggs@dev:~$ gdalinfo
test.tif
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 4193, 2861
Coordinate System is:
PROJCS["unnamed",
GEOGCS["GRS 1980(IUGG, 1980)",
DATUM["unknown",

SPHEROID["GRS80",6378137,298.257222101]],
PRIMEM["Greenwich",0],

UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",173],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",1600000],
PARAMETER["false_northing",10000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (1810357.092181787360460,5488467.918922254815698)
Pixel Size = (10.000000000000000,-10.000000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 1810357.092, 5488467.919)
(175d29'27.21"E, 40d43'40.29"S)
Lower Left ( 1810357.092, 5459857.919) (175d30'2.02"E, 40d59' 7.25"S)
Upper Right ( 1852287.092, 5488467.919) (175d59'12.51"E, 40d42'57.90"S)
Lower Right ( 1852287.092, 5459857.919) (175d59'54.22"E, 40d58'24.47"S)
Center ( 1831322.092, 5474162.919) (175d44'39.06"E, 40d51' 3.45"S)
Band 1 Block=4193x1 Type=Byte, ColorInterp=Red
Mask Flags: PER_DATASET ALPHA
Band 2 Block=4193x1 Type=Byte, ColorInterp=Green
Mask Flags: PER_DATASET ALPHA
Band 3 Block=4193x1 Type=Byte, ColorInterp=Blue
Mask Flags: PER_DATASET ALPHA
Band 4 Block=4193x1 Type=Byte, ColorInterp=Alpha
mbriggs@dev:~$

1 Answer 1

2

This is 'fixed' in gdal-bin/python-gdal version 1.11.2. The behaviour in linux using this version is the same as using oSGeo4W 1.9.2. - i.e. the tiles use the projection origin as their x=0/y=0.

Nothing I can see about it in the release notes, but clearly been resolved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.