# Talk:Slippy map tilenames

*Discuss Slippy map tilenames*

## Contents

## Compare with QuadTiles

It ocurrs to me that this tile scheme (as used by slippy map area) has some similarities with QuadTiles. We're chopping each tile into four at each successive zoom level.

So maybe tile 8/1/1.png is covering the quadtile region AAAAAAAA (north west corner at zoom level 8) ?

Might be fun to code a converter, and then have alternative tile service which returns tiles by their QuadTile address. It might even be useful as visualisation tool, if we were to start using a QuadTile addressing scheme for anything else. The quadtile addressing would have to follow the same projection assumptions.

-- Harry Wood 12:58, 18 September 2007 (BST)

- Turns out it's not that simple. At least not with the way quadtiles are actually implemented by TomH. I chatted to him briefly about it. Although both schemes involve chopping the world in 4, due to the projections used for the tiles, tile 8/1/1.png is
*not*covering exactly the quadtile region AAAAAAAA. -- Harry Wood 09:45, 14 November 2007 (UTC)

Google currently use a Quadtile url system for their satellite tiles. Take a look at the Google Mapki article. --Thomas Wood 18:45, 18 September 2007 (BST)

## Derivation of tile names

It's correct? Now is:
*x* = (*x* + π) / π

but I think it's:

*x* = (*x* + π) / 2π
--wiso 10:21, 2 August 2008 (UTC)

## Maplint tiles

In the section "Tiles" 3 examples are given:

- Mapnik
- Osmarender/Tiles@Home
- Maplint tiles

However the last link does not point to the maplint tile. Also on the main map page the option to show maplint does not work. It does work on informationfreeway.org but not on openstreetmap.org.

Richard

## Correctness of pseudocode ?

Hi- I believe there seems to be at least one mistake in this pseudocode:

In paragraph Implementations, Pseudo-Code, lon/lat to tile numbers:

ytile should read:

ytile = { [ 1 - (log(tan(lat_rad) + sec(lat_rad)) / π) ] / 2 } * n

Note that n is now outside the big thing over 2, otherwise the code divides by n instead of multiplying. (Used { and [ for more clarity).

I was almost going to correct this, but then I saw that most code samples below do this as well. Have they ever been tested ? Am I delusional ?

- User:Americci Vespugo 2009-02-25 20:12 (GMT+1)

## Correctness of Mathematics ?

In paragraph Mathematics:

I think the formula for ytiles ist wrong: Instead of tan (lat * 180 / PI) it should be tan (lat / 180 * PI). The same error appears inside of cos( .. )

- User:Chilobo 18:27, 5 December 2010

- I've correct my mistake . Sorry --Didier2020 12:17, 9 December 2010 (UTC)

## Correctness of "tile size in degrees"

The Zoom Levels table has a column named "tile size in degrees." For zoom level n, it says the formula for the tile height in degrees is 170.1022/2^{n}°.
This is incorrect. That gives the average tile height in degrees, which is misleading, and not of much use. Tiles that are different distances from the equator will have different heights, as measured in degrees latitude.

Off the top of my head, the way to determine a tile's height in degrees latitude is to calculate abs(latitude of bottom edge - latitude of top edge). The formula for calculating a tile's top edge is provided. The latitude of the bottom edge of a tile would simply be the latitude of the top edge of the tile immediately below it, or if it is in the bottom row of tiles, the latitude of its bottom edge would be -85.0511.

I've only been dabbling in this stuff for about a day, so I don't feel confident enough to edit the actual page. But I hope someone does, for the sake of others. I wasted a lot of time trying to track down a bug in my code, not knowing that my code was based on an incorrect formula.

## Lots of languages

We've got this same code implemented in lots of different languages. Rather a stupid number of different languages actually. Is there some way we could make this more compact? What makes it particularly daft is that it's not actually done in ruby, the language we do OSM server stuff in!

-- Harry Wood 19:41, 9 January 2011 (UTC)

- really? The more languages it is translated into the better! (but feel free to move away onto another wiki page)
- -- Hamish 6 June 2012 (updated Jan 2013)
- OK we now have a ruby section there. We also now have a gigantic hairball of bash script somebody's quaffed onto the page which seems to be going above and beyond the basic coordinate translation task. The page needs cleanup and splitting out onto other pages somehow. -- Harry Wood (talk) 15:04, 23 January 2014 (UTC)
- Don't really see the need to split it. It's not hard at all to find the one language you're interested in at the time. --Tordanik 14:41, 24 January 2014 (UTC)

- Pulled out the large script which didn't really belong in there as it wasn't an example of coordinate translation, it did much other stuff. Pnorman (talk) 22:06, 4 May 2015 (UTC)

- OK we now have a ruby section there. We also now have a gigantic hairball of bash script somebody's quaffed onto the page which seems to be going above and beyond the basic coordinate translation task. The page needs cleanup and splitting out onto other pages somehow. -- Harry Wood (talk) 15:04, 23 January 2014 (UTC)

## Copyright?

It would be useful to reuse the code found on this page in e.g. GPL projects, but without explicit licensing terms we can't (doesn't meet DFSG standards). Do we assume CC-By-SA 2.0 as the wiki page is licensed as? (not really meant for code) Or do we assume it is a trivial method which can't be implemented functionally in any other way and so without copyright? thanks,

-- Hamish 02:19, 16 January 2013 (UTC)

- I consider this basic mathematics and not really copyrightable. But ianal. --Tordanik 20:59, 31 January 2013 (UTC)

## EPSG:3857 or EPSG:4326?

It seems to me that the article provides formulas and pseudocode for converting "real" coordinates - WSG84 (EPSG:4326) while OSM and other applications use Mercator projection (EPSG:3857).

So additional conversion to EPSG:3857 is needed.

--Vanuan (talk) 20:18, 2 February 2013 (UTC)

- OSM coordinates (and coordinates in many other tools that are used world-wide) are in WGS84 (EPSG:4326). Tile rendering is indeed done in Web-Mercator, so screen coordinates are in web-mercator. But this article is talking about conversion between the geographical WGS84 coordinates and tile coordinates. So no change is needed. --Sanderd17 (talk) 14:26, 15 December 2015 (UTC)

## Derivation of tile names

Shouldn't the necessary reprojection of coordinates be the other way around? From EPSG:3857 (Web-Mercator) to EPSG:4326 (Global Mercator)? Since coordinates in OpenLayers are retrieved in the former projection and the calculation of tile indices is based on the latter?

-- tiiv