Project Proposal: Map Tile Distribution and Master Directory of Map Tile Distributors

During a recent mapping project implementation at work I realized the open source map content is limited and that the resources to share that content are even more limited. There a few map tile servers out there all of them using resources of open source volunteers, and those servers are being hammered by millions of users. The map content is not usualy a light content, it's all bitmap images the are already compressed.  Many servers go offline because they can't take the load or that they have reached their maximum bandwidth for the day.
The number of people volunteering to host the tiles is small because the tiles ocuppy about 1.2 TB of disk space . But that's for the whole world.

Here's the solution.

  1. Let's create a subdomain mdmtd.flossk.org  (for Master Directory of Map Tile Distributors)
  2. Let's create a little PHP script that allows volunteers fetch a protion of tiles from the main servers directly into their servers. Everyone needs to run this script on their own servers, we will share it when a new volunteer is registered.
  3. Let's also create a database to tell the world that this new regional tile distributor is mirroring tiles for x,y region with radius of m kilometers.
  4. Let's create and submit  patches for a few major javascript layers, like OpenLayers, Mapquest for OSM etc. so that these scripts lookup our database at mdmtd.flossk.org.

These volunteers most likely have created a program or a web application that may be specific to a region. Let's take http://prishtinabuses.info/ for example. Why would thousands of Prishtina citizens download Prishtina maps from California? Well, first of all there is no map tile server in Prishtina. Even if there was one, OpenLayers doesn't know about it.


Also, there seem to be a lot business applications that are used in large corporations inside their intranets. We can offload these corporations easily by redirecting them to their internal map server.

And just before I finish for tonight let me just say what we need:

  1. Issue tracker
  2. Bugzilla
  3. GIT or SVN server
  4. Subdomain (to be under FLOSSK for next thousand years)
  5. Mysql server
  6. Apache server
  7. 2 PHP programers
  8. 2 Javascript programers
  9. Web artist
  10. Technical writer
  11. Blogger
  12. Mailing list
  13. Support forum

This of course is a summary of an entire mapping ecosystem. I will continue with detailed design description for each item in the next blog/s. 

ClientSide Javascript - Getting the list of tile servers

This script is most likely going to be a patch for OpenLayers. This script is responsible of making an http request to the Master Tile Directory mdmtd.flossk.org with the following information:

mdmtd.flossk.org/getServerList.php
Longitude, Latitude, Radius, Zoom level, Tyle Style

getServerList.php will respond with a list of servers in json format in the following structure:

{
     "query": "Longitude, Latitude, Radius, Zoom level, Tyle Style",
     "serverList":
     [{
     "ID" : uuid,
     "Name": "Agrons New York Tile Server",
     "URL" : "http://url.toServer.com/TileStyle/GreenTileStyle",
     "Bandwidth"      : 150,
     "Speed": -1},
     {
     "ID" : uuid,
     "Name": "Obamas New York Tile Server",
     "URL" : "http://url.toAnotherServer.com/TileStyle/GreenTileStyle",
     "Bandwidth"      : 45,
     "Speed": -1}
     ],
     "mainServerList":
[{

"ID" : uuid, "Name": "University of Linux Programmers", "URL" : "http://url.toMainServerClone.com/TileStyle/GreenTileStyle", "Bandwidth" : 50, "Speed": -1}, { "ID" : uuid, "Name": "Main OSM Tile Server", "URL" : "http://tah.openstreetmap.org/Tiles/tile/",

     "Bandwidth"      : 10,
     "Speed": -1}
     ]
 

}


This script will, if local storage is enabled, test the servers on the list for speed and update the serverList[n].Speed value and then save the array to the local storage. Current time and date will be stored as well as the group Longitude, Latitude, Radius, Zoom level, Tyle Style as a reference key.
When local storage is enabled, it will be used first.
 

An example of localStorage:

 

var testObject = { 'one': 1, 'two': 2, 'three': 3 };
// Put the object into storage
localStorage.setItem('testObject', JSON.stringify(testObject));
// Retrieve the object from storage
var retrievedObject = localStorage.getItem('testObject');
console.log('retrievedObject: ', JSON.parse(retrievedObject));
 

The way getServerList.php generates the server list array is with most preferred first. If this client side Javascript uses the first list on the server it should be fine, but it should also test the speed from it's own location.

ClientSide Javascript - Choosing the fastest tile server

This script will send asinchronus http requests to every server on the list and it will donwload tile 0.png. It wil then compare and save the choice in a local storage file for at least a week. After a week this script should run again, but we need to let the user know that this script is going to take a minute.

PHP Script for managing the Volunteer Server

This script is something like webmin or myPhpAdmin, but it's duty is to provide simple tile managing tools over the web. We will call it myTileAdmin.php (all in lowercase). This script will be distributed from mdmtd.flossk.org and it will provide the following functions:

  1. Link to volunteers account at mdmtd
  2. configure the bandwidth and let mdmtd know about it
  3. choose regions and styles volunteer wishes to copy and share
  4. create the directory structure of the tiles
  5. do the actual copy/mirroring of tiles of and keeping them organized in styles
  6. notify mdmtd that a new tile update is available
  7. listen to notifications from mdmtd

All information needed will be saved on the volunteer server in a .conf file.
It is important to stress that each of the volunteer servers will be serving multiple regions.

Linking to account at mdmtd

A volunteer will initially register at mdmtd.flossk.org by creating a user account and choosing a password. Ideally this would an OpenID solutions but a simple username or email and a passord will do. With myTileAdmin.php user will enter the same credentials as in mdmtd. The script will encode the password and save it in the .conf file.

Setup

myTileAdmin.php will ask the user for the ammount of the bandwidth he/she wishes to share, styles and regions. Also, the desired location on the local storage. On submit / save the script will generate a new .conf file for apache so that the new folder and files (soon to be copied) are accesable by the world.

Choosing the regions

This page show an OpenStreet Map that will allow the user to zoom, pan and put a circle and set its radius on the map. The user will be able to put any number circles on the map. He can also delete them. When the page is saved the regions are saved locally in .conf file as well as at mdmtd.

Comments

HI Agron,
this looks interesting. I agree that tiles are gold. Lets look into this more.

mike

Why a center and radius and not a rectangular lat/lon?  Seems that tile display engines would index a regional server better with a rectangular area available than with a center and radius.

Also, would the regional servers be running mod_tile and storing meta-tiles (fewer files to deliver and update, possibly enabling dirty flagging) or an explicit z/x/y.png tree structure of individual tiles?

Lynn (D)

I think because SQL expression for a center and radius is way simpler than for a rectangular area. I may be wrong I never tested the two for performance but I assumed the center and radius would perform better just because it has 4 comparison operators less than the other.

The other reason is that lets say if there was a regional server for Japan, neither a circle nor a rectangle would be fit if they didn't to serve tiles of other countries. To accommodate that we would have to also add polygons. A SQL expression for searching a point inside a polygon would be a lot more complex and it would probably choke the server.

So I gave up on the idea of supporting rectangles and polygons for now.

I like mod_tile a lot. Especially it's ability to render on the fly. Usage of this mod is upto the volunteer that owns the regional server/s. I would recommend to never expire the planet.

We are going to use the style/z/x/y tree structure where style is something like mapnik, osmarender etc. And we'll use plain file copy from the main tile server down to every regional server.

I'm actually in the process of bringing up my own OSM tile server based on mod_tile right now and was (pleasantly) surprised to discover that it doesn't actually store all of the individual z/x/y.png files, but instead uses a 5 part hierarchy to access a meta-tile file that containes multiple individual PNG tiles.  mod_tile invokes mapnik to render a multiple tile area at once and virtually dispenses the z/x/y.png tiles from inside the meta tiles when necesary.

So, why not distribute the rendered meta tiles as this is fewer files and would then be directly servable by mod_tile?  In fact, if the core OSM tile servers could be modified to serve out both the z/x/y.png tiles and the meta tiles, the volunteer servers could just fetch updated meta-tile files when necessary.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

I'm not sure why the "who has..." line goes to the server that has the tiles and not back to the asker?  Then the asker would take that information and go direct to the server that has the tiles just as it goes to osm tile servers today.

From what I see in this diagram, mdmtd.flossk.org better have some killer bandwidth to handle being the front-end for ALL tile queries.

And I've not seen any web architecture that would allow a query sent to one server (End user to mdmtd) to be forwarded to another server (volunteer or OSM) and have the answer go directly back to the original requester?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

That's just for making the diagram simpler.

End user asks the mdmtd for servers that cover the region, and mdmtd will answer back to the asker with json list of the following structure:

[{
     "ID" : uuid,
     "Name": "Agrons New York Tile Server",
     "URL" : "http://url.toServer.com/TileStyle/GreenTileStyle",
     "Bandwidth"      : 150,
     "Speed": -1},
     {
     "ID" : uuid,
     "Name": "Obamas New York Tile Server",
     "URL" : "http://url.toAnotherServer.com/TileStyle/GreenTileStyle",
     "Bandwidth"      : 45,
     "Speed": -1}
     ]
}]}]}]

The asker/enduser or even another volunteer/regional server being setup or 
updated will use the above json list to get the map tiles by making a 
direct http request to the regional server.

We will also provide a speed testing javascript to automatically choose 
between the servers on the list. But will run this script once in a while 
because it might take 20 seconds or so to run.


Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.