• General settings
  • Generalities
  • Permissions : Users and Groups
    • Users
    • Groups
    • App access by group
    • User and collaborators
  • Transparency in Atlas
  • Configure a WMTS base-map layer
    • Display name
    • Sort index
    • Recommended
    • Webservice set
    • Service Layers links
    • Setting up the service layers
      • Layers
      • Crs
      • Styles
      • Service
  • Override message records
    • Message record key
  • WFS 2
  • Configure base layers for a quick switch (in view and compose)
  • Maintenance Events

General settings

Generalities

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

Users can have 4 permission status

• Active
• Staff
• SuperUser
• Group(s)

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

Groups

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 WMTS base-map layer

In the section admin/webservice/ you can configure basemap layers. The basemap layers can then be selected in the compose to be displayed in the view

The base layer is where the basemap is configured. The following elements are described: display name, sort index, recommended, webservice set, service layer links

Display name

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

Sort index

The index indicates the level of the base layer in listings. An index of 1 will place the base layer on top of the list.

Recommended

If ticked, the base layer will be pre-selected by default in the studio for any new map.

Webservice set

The webservice sets allow to group a set of base layers, for example on a thematic basis, that will be displayed in the compose or view.

You can create one on the fly, or create them in the section admin/webservice/wmslayercategory/add/

Service Layers links

The layers you want to add to the basemap. The sort index allows you to define which layer is on top. An index of 1 will place the layer at the bottom (it is the first one to be drawn). A bigger index will place the layer on top.

The layers can be configured in the section admin/webservice/servicelayer/add

Setting up the service layers

Layers

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

Crs

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

Styles

No style yet. But an empty string is needed.

Service

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/:

Override message records

Some of the structuring text elements in cartostation are message records. It is possible to override the default message records used in cartostation and replace them with edited content in the administration part (in section admin/api/editedrecord/), by entering the message’s key and then the text that should replace the default message: the record.

Message record key

In any application, by adding ?debug=1 at the end of the url, you enter debug mode, which replaces each editable content (the default message records) in the interface by its key.

This debug mode can be used to find a specific key right from where it is used.

For example, in the view app, at url https://geodata.environnement.brussels/client/view/?debug=1, the keys appear after the ‘TR:’, between brackets:

The key should be structured this way : app_prefix/messageRecord

For example, the title of the applications in the view app has the key view/applicationsListTitle

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

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

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

WFS 2

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 : http://plugins.qgis.org/plugins/wfsclient/

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

To get a “quick switch” 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:

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.