[OSM-dev] Slippy Map, automatic Tile Rendering
Thomas Walraet
thomas at walraet.com
Thu Jan 18 11:18:11 GMT 2007
Frederik Ramm a écrit :
>
> (That's the reason the low-detail zoom levels look so faint; on the
> other hand, if one were to define modified stylesheets for these
> levels, it would be next to impossible to download the amount of osm
> data needed to render one because of their large bounding box. This
> will probably only be possible if the OSM API did support some sort
> of filtering.)
As I understood, when tiles at home clients render an area, they picked up
the data from the API and render :
- 1 tile level 12
- 4 tile level 13
- ...
They could render one more tile at level 12 dedicated to the lowest
zoom. It should draw primary and secondary roads very large, display
name only for major cities, rails with just one black line, etc.
Bonus : If those tiles could include the land/sea data currently in use
on the mapnik db layer for zoom 1-9, it could look real nice. Or maybe
downloading the corresponding landsat tile and draw on it.
> (a) Which tiles are outdated? One could of course just re-generate
> all existing tiles but that would be very time-consuming (I guess
> about 20 days of round-the-clock computing for a modern PC; less of
> course if many take part in the distributed computing). I will try to
> evaluate the last-change-timestamp in the planet file and use that to
> determine which tiles are out of date.
A solution is to have a daily dump with modification of the day.
(addition, deletion, modification)
With the planet dump and those diff dumps, maps could be kept up to date
fairly easily. And renderer will stop hammering the DB through the API.
Diff dumps could even be more frequent than daily. If the frequency goes
up, the total size remain the same. With a dump every hour or two, the
RSS feed is no more needed.
--
Thomas Walraet
More information about the dev
mailing list