Opened 15 years ago
Closed 5 years ago
#2737 closed defect (wontfix)
BoundingBox and Origin elements of TMS output in GDAL2Tiles always in Lat/Lon even when map is in Mercator
Reported by: | jbeverage | Owned by: | klokan |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | Utilities | Version: | unspecified |
Severity: | normal | Keywords: | gdal2tiles |
Cc: | klokan |
Description
The Origin and BoundingBox elements of the tilemapresource.xml file generated by gdal2tiles are always in lat/lon even when the output map is Mercator.
Also, the X and Y coordinates are switched in both these tags. Currently, X=Latitude and Y=Longitude. The correct output should be X=Longitude and Y=Latitude.
Change History (8)
comment:1 by , 15 years ago
Keywords: | gdal2tiles added |
---|---|
Milestone: | → 1.6.1 |
Owner: | changed from | to
comment:2 by , 14 years ago
comment:3 by , 12 years ago
Component: | default → Utilities |
---|---|
Milestone: | 1.6.4 |
Removing milestone.
Hamish's patch seems reasonable but I'm not familiar enough with TMS to know if there is a reason this would be a bad idea.
comment:4 by , 10 years ago
x,y swap believed fixed in #5336.
lat/lon vs sph-merc for coords written to tilemapresource.xml remains an open issue. Is there any documentation on what tilemapresource.xml specifies, native projection or always lat/lon?
Hamish
comment:6 by , 9 years ago
Cc: | added |
---|
Specification is in http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification#TileMapService_Resource. Not only OGC writes unclear specifications, TMS spec does not really say literally anything about the SRS of the BoundingBox.
<TileMap>s have both a <BoundingBox> and an <Origin>. The <BoundingBox> is the extent of the data of interest -- it might be used by a client to set an initial spatial extent. The <Origin> is the lower-left corner of the 0/0 tile, and the upper right corner of tile -1/-1 (if you choose to configure your service so that negative tiles are required). The <Origin> may be outside of the visual region of interest (the <BoundingBox>), for reasons of implementation convenience.
However, in all examples BoundingBox is using the units of the SRS:
<SRS>EPSG:26910</SRS> <Face>0</Face> <BoundingBox minx="500000" miny="4800000" maxx="700000" maxy="5500000" /> <Origin x="500000" y="4800000" />
Feels like a bug in gdal2tiles. I add CC: to klokan from the list of commiters http://svn.osgeo.org/gdal/trunk/gdal/COMMITERS
comment:7 by , 6 years ago
I made a test with GDAL 2.3dev and I believe that this is fixex. However, the tilemapresource.xml file is generated only if the profile is "raster".
I wonder if there is some good reason for not creating the TMS capabilities for "mercator" and "geodetic".
comment:8 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
Replying to jbeverage:
I'm not sure if it's the same place you are talking about, but this patch fixes it for tilemapresource.xml:
Hamish