wiki:tilegen

Version 4 (modified by dennisw, 14 years ago) ( diff )

--

Tile Generation & Data flow

Let's assume that non-existed tiles will be generated realtime:

Website

It all starts at the website. A user opens the heatmap, and the browser starts requesting tiles. Let's say tile 1,1 at zoomlevel (x)1 is requested, using the classic colorscheme. The browser will request classic/1/1,1.png.

Note that these values are variables. In fact, in the gheat/urls.py, the following urlpattern is given: r'^(?P<color_scheme>\w+)/(?P<zoom>\d+)/(?P<x>\d+),(?P<y>\d+).png$'. So when the browser requests an image, the urlpattern is recognized and the url is sent to the serve_tile function in gheat.views, as declared in gheat/urls.py.

gheat/views.py

serve_tile

The serve_tile function is responsible for serving the tile images.

The function starts with a variable validation. Is the colorscheme existing? And are the zoomlevels, x, and y really digits? Is the zoomrange supported? If any error should occur, the tile will not be generated.

Since our variables passed the validation, and the tile doesn't exist yet, the data will be sent to the generate_tile function.

generate_tile

This function sends the variables to the backend class Tile: tile = backend.Tile(color_scheme, dots, zoom, x, y, fspath). The backend, declared in gheat/gheatsettings.py is the gheat/pygame_.py file. --This calculates the lat/lng bounds for the tile. After this, depending on existence, a tile will be rebuild and served or served from cache, or an empty will be served.--

gheat/pygame_.py & gheat/base.py

These two files will be explained in one section, since the Tile class in base.py is the base class for the Tile class in pygame.py.

It starts with translating the tile coords to pixel coords. It adds the image height and with to the pixel coords, and translates it to lat & lon. These values represent the boundaries of the tile.

still WIP

Note: See TracWiki for help on using the wiki.