noTile – The project database

Here I will describe how the project database defines the map project. As we have seen earlier data is stored in SQLite databases. So is also the information about the map project. That is information about where to find the databases with map data. At what scales to render the different layers. What layer is on when project loads. How to style the layers and some more.

The idea about a project database

Many map clients uses config-files or javascript files to define the mapping project. That is convenient. But here is my 2 reasons for not storing the project definition in a text file:

  1. We already handle SQLite in the project, so I didn’t have to search and evaluate any other formats and techniques when chosing SQLite.
  2. It is easy to maintain from many different interfaces. By SQL-query updating values direct. Or by sending another SQLite DB to the client, attach it to the one in production and copy rows between them. Or just exchange the whole db of course.

So, when starting the noTile client it takes the project db as an argument. By reading that project db it finds the other databases with data in.


The tables in the project database is:

Tables to manipulate when adding a new layer to the project

table “dbs”:
In this table paths to databases with data is stored.

table “layers”:
In this table a lot of information about the layers is stored. There is information about geometry type as integers as:

1 – Point
2 – Line
3 – Polygon

In this table is also information about at what scales the layer shall be rendered. For simplicity the value is just “units per pixel”. That means that if you use a meter based projection and sets maxScale to 30, the layer will only show when the scale gives less than 30 meters per pixel.

This table also keeps information about what dataabse to get data from of course, and the name of the table to read from. It also keeps information about the geometry column and if polygon about the triangle index column (more about that later).

We also keep information about what “program” to use for rendering. A program in this context is a combination of vertex shader and fragment shader in openGL. More about this later too.

The layer table also have information about what field to use for styling and in what order the layers shall be rendered (first layers gets in the back)

table “styles”

Here all styles is stored. Styles is very simple so far. It is just a color, an outline color, a linewidth and on what value the particular style is to be used. The value referenced here is the value in the column that is given in the layer table for styling. So, for now the client supports very few options for styling.

Tables that most times don’t need to be modified

table “shaders”

This is a table holding the source code for the shaders. maybe this is overkill to make this flexible. But when I have been reading about openGL I have understood that shaders is the heart of openGL. Shaders is small programs that gets loaded into the gpu at runtime. Those programs is what the gpu actually execute in the rendering process.

So, what I have done is to put the source code of the shaders into this project db. That means that there can be different shader programs for different layers. Maybe that can be usefull. But so far I have ily used simpliest possible shaders to reproject the vertex points to pixels and to set the right colors.

But, anyway, the possibilities is there to do something crazy with it, for someone with that knowledge.

table “programs”

Here we combine vertex shaders and fragment shaders to a “program”. Since vertex shaders and fragment shaders always is compiled together it makes sence to give the combination a unique id. This id is what the layers get. So a layer using “program 1” gets sources to vertex shader and fragment shader from table shaders referenced in table programs where programID is 1.

Ok, that was the story about the project database.

You can find an example project db in the repository
It is called “norge_proj.sqlite and is used to render the data in norge.sqlite in

Next post will probably be about how the clients selects and uses geometry data and how it gets rendered.