KoelnAPI / aedmap

Mobile web application for the display of automated external defibrillator (AED) locations
MIT License
4 stars 1 forks source link

Need fast tile server or cache #3

Closed marians closed 10 years ago

marians commented 10 years ago

We currently use Stamen's toner tiles. Especially when zoomed in to a deteiled level, it often takes more than 5 seconds before the tile server responds. The reason for that is most likely that the Stamen server is rendering the tiles on demand instead of serving them from a cache.

In order to make map navigation faster, we should look for a better option.

  1. Pre-rendered tiles would be fastest from a client perspective. This would require us to generate our own tile style (uwing TileMill, for example) or clone Stamen's Toner style (https://github.com/Citytracking/toner/tree/master/mapnik) as a basis. The pre-rendered tiles take up about 5 GB if rendered down to level 19. We would have to re-render every couple of months in order to pick up changes in OSM data (streets, buildings etc.).
  2. A caching proxy between the client and Stamen's server. However this would not speed up the first request, only subsequent tile requests would be faster.

EDIT: Stamen Toner tiles are available up to zoom level 19, which I find quite useful for our "pedestrian" usage szenario. So we would have to render up to level 19 as well in order to match the level of detail. That means 4 GB more, compared to level 18 only.

marians commented 10 years ago

As of now, custom pre-rendered tiles are used. The style is based on OSMBright and heavily adapts Stamen's Toner style. Building rendering is quite different though.

Only zoom levels from 8 to 18 are provided. We have to see if this is enough, or if we need to go the extra mile to render level 19 as well.