Documentation utilisateur [FR]
Gebruikersdocumentatie [NL]
User guide [EN]


For more technical (ie: developers infos), please refer to the readme about the server here and about the client applications here.

General settings



General settings


cartostation’s backend is built with Django.

The admin part is located at /admin, and you must be a registered user with staff permissions to access it.

Permissions : Users and Groups

Can be set up in /admin/auth/


Users can have 4 permission status

Active : will activate or de-activate the user account. If unchecked, it doesn’t delete it.
Staff : if checked, it will allow this user to log in the administration page. By default the user won’t be able to do anything. He will need to be part a group with permissions set up to be able to use part of the administration.
Superuser : grant all the permissions to this user.
Group(s) : see below


You can define groups with specific permissions. The permissions defined in the group page are about functionalities in the administration part.

If a user is part of several groups, it will be granted with the union of the privileges of the groups.

Some specific functionalities can be related to group per apps.

App access by group

CLIENTS configuration accept a “groups” key that takes a list of group names, thus limiting access to these apps to users belonging to these groups.

User and collaborators

Sometimes it is useful to let multiple people access a map in the studio. It is possible to add collaborators to the map in the ‘/admin/api/usermap’ section. Collaborators have the same rights as the user (generaly the creator) of the map, except that they can’t delete it.

Transparency in Atlas

We think it’s good practice to carefully choose the transparency in the Studio so that the user will not have to deal with it in the Atlas. But the possibility exists in the administration platform to add a widget to the atlas for some chosen layers, to let change the transparency in the Atlas. You only need to check the “Opacity selector” option in the layer page (section admin/api/layerinfo/).

Configure a WMS base-map layer

In the section admin/webservice/wmslayer/ you can configure WMS layers.



Name is the identifier of this layer, so it’s a good practice to keep it simple and accurate.

Display name

The (multi-lingual) name that might be shown to the users in the client applications.


Layers is multilingual, which means you can use a different layer per language.
It is also possible to stack layers together.


Configure the CRS of the WMS.
For now, only EPSG:31370 is supported.


No style yet. But an empty string is needed.


The service you want to connect to.

While you can do it on the fly, you might want to configure a service first in the section admin/webservice/service/add/:



The order of the basemap layer indicates the order of appearance of the basemap layer in the additional basemap menu when visualising a map (in the view or atlas)

Override message records

It is possible to override the default message records used in cartostation.
In any application, by adding ?debug=1 at the end of the url, you enter debug mode, which replace each editable content in the interface by its identifier, so it’s easier to find a specific identifier right from were it is used.

For example, in the view app, at url, the keys appear after the ‘TR:’, between brackets: illustration

The key should be structured this way : app_prefix/messageRecord

This key will be used to add (or change) an Edited Record in the administration plateform (in section /api/editedrecord/).

To quit debug mode, simply reload the page. The new record will appear directly.

NB: All the original key:value are stored in the /locale directory of the client applications.


A read-only WFS 2.0 with authentication is accessible on cartostation.

url : [HOST-NAME]/basic-wfs/

TIP : If needed a QGIS plugin is available to connect on a WFS 2.0 :

Configure base layers for a quick switch (in view and compose)

To get a “quick swich” between two base layers on the map, the chosen base layers have to be define in the admin. To do this, exactly two “highlighted base layers” have to be created. If you create only one, it will not appear. For the moment, the application does not support more than two layers either. This will be done in future developments

Maintenance Events

To prevent the use of the platform during a maintenance period, it’s possible to define a maintenance event. Therefore, a ‘maintenance’ group has to be defined in the admin (see ‘groups’). You can add any user in this group. This group has to be mentioned in the settings under the key MAINTENANCE_GROUP_NAME.

During the maintenance period, this page will be shown for all users but the ones in the maintenance group: admin-maintenance

The event itself has to be defined in the administration platform. An announcement should be defined, that will be shown between its start date and the start of the maintenance event, under the header of the app.

It is also possible to define a specific message for a given app, that will be shown during a given period.