= 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 ===

== base.py ==
A large part of the tile generation takes place in the gheat/base.py file.


Work in progress
Work in progress
Work in progress