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 klokan, 15 years ago

Keywords: gdal2tiles added
Milestone: 1.6.1
Owner: changed from warmerdam to klokan

in reply to:  description comment:2 by hamish, 14 years ago

Replying to jbeverage:

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.

I'm not sure if it's the same place you are talking about, but this patch fixes it for tilemapresource.xml:

Index: trunk/swig/python/scripts/gdal2tiles.py
===================================================================
--- trunk/swig/python/scripts/gdal2tiles.py     (revision 19763)
+++ trunk/swig/python/scripts/gdal2tiles.py     (working copy)
@@ -1511,7 +1511,7 @@
          <Title>%(title)s</Title>
          <Abstract></Abstract>
          <SRS>%(srs)s</SRS>
-         <BoundingBox minx="%(south).14f" miny="%(west).14f" maxx="%(north).14f" maxy="%(east).14f"/>
+         <BoundingBox miny="%(south).14f" minx="%(west).14f" maxy="%(north).14f" maxx="%(east).14f"/>
          <Origin x="%(south).14f" y="%(west).14f"/>
          <TileFormat width="%(tilesize)d" height="%(tilesize)d" mime-type="image/%(tileformat)s" extension="%(tileformat)s"/>
          <TileSets profile="%(profile)s">

Hamish

comment:3 by warmerdam, 12 years ago

Component: defaultUtilities
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 hamish, 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:5 by hamish, 10 years ago

see also #4670

comment:6 by Jukka Rahkonen, 9 years ago

Cc: klokan 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 Jukka Rahkonen, 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 Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.