7 avr. 2025, 16:51:52 Philippe Bareille

Cartographie sur Lutèce

Table des matières

Introduction

Le plugin Carto et ses modules répondent à deux pratiques cartographiques récurrentes du web :

  • La consultation de données localisées sur un fond de carte tuilé, le plus souvent mondial.
  • La contribution de données spatiales par les utilisateurs d’un site.

Différentes cartes dynamiques ou interactives peuvent être présentées sur un même site :

  • Des cartes de localisation qui permettent de visualiser les ressources sur laquelle porte l’application (des lieux de rendez-vous, la localisation d’un événement, le lieu d’une intervention, le lieu d’une anomalie, etc.)
  • Des cartes interactives qui conjuguent la visualisation des ressources déjà enregistrées et d’autres éléments de localisation ainsi que des fonctionnalités de dessin et d’édition permettant d’ajouter des ressources en base ou de produire des documents dérivés de la carte.

L’affichage de données spatiales sur un fond de carte peut être réalisé sur la page front office suivante : Portal.jsp?page=coordinate&view=manageCoordonnees.

Le plugin Carto et ses modules peuvent être combinés au plugin Forms. Ainsi, la saisie d’informations spatiales peut être un élément de réponse à un formulaire comme dans le cas d’appel à participation citoyenne. La carte devient un support pour l’utilisateur qui complète sa proposition par une saisie sur une carte. Les informations saisies sur la carte sont soit des points, des lignes ou des zones. Cet aspect est configurable en Back-office selon les choix des administrateurs du site en fonction des besoins thématiques.

La bibliothèque Leaflet est utilisée comme moteur d’affichage.

L’indexation dans un Solr permet de gérer l’affichage en Front Office de tout ou partie des données contribuées.

Les modules

Le plugin carto exploite :

Construire une carte en back office

Deux menus du Back Office servent à la configuration de la cartographie : Référentiel de cartographie et Configuration de la cartographie.

Les référentiels de cartographie

Trois référentiels constituent les fondamentaux des cartes qui peuvent être construites : les types de couches de données, les types de géométrie et les fonds de carte.

Les types de couche de données

Référentiel de type de données

Le référentiel des types de couches de données recense les fonctionnalités d’interactivité avec la carte.

Une couche de type :

  • Consultation n’est pas modifiable via la carte en Front Office. Il s’agit d’une couche de données qui apporte du contexte dans le cadre d’une interactive ou qui sert à la localisation d’information sur un site.
  • Éditable par les usagers et consultable par tous les usagers est la couche de données pour laquelle il est possible de créer un nouvel objet géographique par l’utilisateur.
  • Inclusion définit un périmètre dans lequel il est possible de créer des données sur la couche de données éditable. Hors de ce périmètre il n’est pas possible d’éditer la couche de données.
  • Exclusion définit un périmètre dans lequel il n’est pas possible de créer des données sur la couche de données éditable. Hors de ce périmètre il est possible d’éditer la couche de données.

Afin de définir une zone d’exclusion ou d’inclusion, soit la donnée est déjà indexée dans le Solr connecté, soit il s’agit d’importer un fichier geojson délimitant la zone.

{
    "type": "Feature",
    "id": 0, 
    "properties": { }, 
    "geometry": {
        "type": "Polygon", 
        "coordinates": [ [ 
            [ 2.351876929823846, 48.836814955383176 ], 
            [ 2.355540683790891, 48.831349624682986 ], 
            [ 2.349474078196109, 48.829532935753519 ], 
            [ 2.33607996466724, 48.833213228500881 ], 
            [ 2.339719928024108, 48.838850599512739 ], 
            [ 2.347451876331182, 48.837206431832747 ], 
            [ 2.351876929823846, 48.836814955383176 ] 
        ]]
    }
}

Les types de géométrie

Vue du référentiel des types de géométrie

Le référentiel comprenant les types de géométrie répond à la séparation normée des systèmes d’information géographique. Actuellement, les trois types d’éléments fondamentaux en SIG sont intégrés : les points, les lignes et les polygones. Les données sont créées dans le système de coordonnées géographiques WGS84.

Fonds de carte

Vue de la bibliothèque de fonds de carte

Par défaut, le fond de carte OSM (OpenStreet Map) classique est proposé avec le plugin. Il s’agit d’un fond de carte libre et mis à disposition notamment pour des projets associatifs servant OSM. Il n’est pas recommandé d’utiliser ces tuiles en production au risque de consommer de nombreuses ressources sur les serveurs cartographiques de l’association OSM. Le référentiel des fonds de carte permet ainsi d’ajouter d’autres serveurs de tuiles raster. Il est également possible d’ajouter des tuiles limitées en accès par un token en ajoutant ce token dans l’URL déclarée dans ce menu.

Exemple de fonds de carte pour les tests : https://leaflet-extras.github.io/leaflet-providers/preview/.

Configuration de la cartographie - Créer une carte

Gestion des modèles de carte

Le modèle de carte est l’élément qui sera appelé pour l’affichage de la carte, soit directement dans une Xpage, soit dans un formulaire. Il porte les caractéristiques de base pour la définition d’une carte dans Leaflet. Un modèle de carte a pour attributs :

  • Un titre
  • Une description
  • Un fond de carte, sélectionné en fonction des fonds de carte listés dans le référentiel
  • Un niveau de zoom par défaut, définissant l’échelle à laquelle la carte sera affichée au chargement de la page
  • Un niveau de zoom minimum, permettant de forcer la lecture de la carte à une échelle minimum
  • Un niveau de zoom maximum, permettant de restreindre le zoom
  • Un centre, une adresse qui permettra de centrer la carte au premier chargement de la page

Paramètres nécessaires à la création d'un modèle de carte Liste des modèles de carte

Gestion des couches de données

Une couche de données correspond à la référence d’un ensemble de données depuis une base Solr. Une couche de données a pour attributs :

  • Un titre
  • Un tag Solr : Si des données sont déjà stockées dans la base Solr connectée, il est possible d’y faire appel en déclarant le tag. Autrement, à la création de données depuis l’application, celles-ci porteront le tag défini.
  • Un type de géométrie, choisi parmi les types enregistrés dans le référentiel
  • La vignette : Le contenu de la vignette qui s’affichera au clic sur l’objet cartographique est paramétrable. Si la carte est associée à un formulaire via le module generic attributes, il est possible d’utiliser les autres champs du formulaire pour alimenter la vignette.

Paramètres nécessaires à la création d'une couche de données

Liaison entre données et carte - Définir la représentation cartographique

La liaison permet d’ajouter une source de données à un modèle de carte, de définir la charte graphique de la couche de données et de définir l’interactivité qui sera possible sur cette couche de données dans le contexte du modèle de carte associé.

Une liaison entre un modèle de carte et une couche de données de type Point a pour attributs :

  • Modèle de carte
  • Couche de données
  • Pictogramme
  • Taille du pictogramme
  • Zoom minimum
  • Type de couche de données

Une liaison entre un modèle de carte et une couche de données de type Polygone a pour attributs :

  • Modèle de carte
  • Couche de données
  • Couleur
  • Épaisseur
  • Zoom minimum
  • Type de couche de données
  • JSON d’exclusion ou d’inclusion

Une liaison entre un modèle de carte et une couche de données de type Ligne a pour attributs :

  • Modèle de carte
  • Couche de données
  • Couleur
  • Épaisseur
  • Zoom minimum

Construction d'une liaison entre modèle de carte et couche de données

Utiliser un modèle de carte et créer de la données dans le cadre de Forms

Une carte, définie en BO (back office) d’une application utilisant le plugin Forms et ses modules, peut être intégrée à un formulaire afin que la réponse au formulaire soit complétée par de la donnée localisée. Ainsi, l’usager pourrait saisir un point, une ligne ou une zone dans le cadre de sa saisie en FO. C’est également possible pour des utilisateurs BO. L’ensemble des règles de gestion liées à la carte s’appliquent également à la saisie dans un formulaire comme par exemple les zones d’exclusion. Techniquement, l’affichage et la saisie via la carte dans le cadre d’un formulaire de Forms sont permis par le generic attribute //Cartographie// disponible avec le module genericattributes-cartography ainsi que le module forms cartographie.

Dans la suite de cette documentation nous allons suivre l’exemple d’un appel à propositions de mobiliers urbains dans l’espace public d’un quartier. Compte tenu du sujet, la donnée créée par l’utilisateur FO sera de type ponctuel.

Modèle de carte, couches de données et liaison

Les éléments cartographiques seront :

  • À l’ouverture du formulaire, la carte est centrée à l’adresse correspondant au centre du quartier.
  • À l’ouverture du formulaire, la carte est au niveau de zoom 15, correspondant dans notre cas à l’échelle du quartier.
  • À la navigation, il n’est pas possible de dézoomer en dessous du zoom 10.

Définition des éléments de base de la configuration

  • Une couche thématique de contexte a été ajoutée : les limites du quartier.
  • Cette même zone délimite également l’emprise dans laquelle les idées peuvent être déposées.

Création d'une couche de données de contextualisation et qui limite la zone de création de données

  • La couche de données de contribution autorise des points par saisie d’une adresse ou au clic sur la carte.

Définition de la couche de données éditable

Un nouveau generic attribute : cartographie

Un nouveau generic attribute (ou type de question) a été créé afin de permettre la saisie de données spatiales selon les paramètres d’un modèle de carte.

Dans une étape d’un formulaire, il est ainsi possible d’ajouter une question de type “Cartographie”. Cette question permet la liaison entre la question et le modèle de carte. Puisque chaque modèle de carte ne peut porter qu’une seule couche de données éditable, l’utilisateur Front Office se verra autorisé à éditer cette couche de données. Si aucune couche de données n’est éditable, cette carte servira davantage d’illustration dans le formulaire.

Associer une question à un modèle de carte

Côté Front Office, la carte s’intègre dans le fil du formulaire. Dans notre cas, comme il s’agit de données ponctuelles, la saisie peut être réalisée soit au clic dans la carte soit au renseignement d’une adresse précise.

Saisie de données ponctuelles en FO

Workflow et indexation des réponses au formulaire

Les couches de données sont indexées dans un Solr. S’il existe déjà des données indexées correspondant au tag défini pour les couches alors celles-ci apparaîtront sur la carte. Pour les nouvelles données, il faut qu’elles soient indexées.

Deux paramétrages sont à réaliser pour assurer la remontée des données dans le Solr et donc sur la carte affichée en Front Office :

  • Choix des champs à indexer pour la publication :
    • Dans la configuration d’un formulaire, à l’onglet Publication, il est possible de choisir les champs du formulaire qui sont à indexer. Les champs autres que la donnée spatiale peuvent venir alimenter l’étiquette de celle-ci au clic sur l’objet.
  • Configuration du Workflow :
    • Un workflow est indispensable pour déclencher la publication des données qui sont alors visibles en Front Office. Il s’agit d’une tâche à ajouter dans une action manuelle ou automatique. La tâche est intitulée //(Forms) Mise à jour du status de publication// et permet soit la publication soit la dépublication d’une ressource.

Visualisation de la réponse

Comme dans un contexte classique d’utilisation du plugin Forms, il est possible de consulter les réponses depuis le Back Office. Dans le cas où une donnée spatiale a été saisie, une carte, centrée sur l’objet, s’affiche.

Visualisation des réponses et indexation

Organisation des modèles de carte

Le système d’appel de couches de données conçu offre de la souplesse et permet la réutilisation des mêmes données pour la création de plusieurs cartes. Ainsi, une couche de données peut être éditable dans le cadre d’un modèle de carte. Le modèle de carte sert à cette édition des données et la charte est conçue pour valoriser la couche éditable. Par ailleurs, la couche de données peut devenir une couche de contexte pour un autre modèle qui permettrait soit l’édition d’une autre carte, soit une synthèse de plusieurs couches de données éditables dans d’autres contextes. Dans un projet de participation citoyenne, cette souplesse permet de proposer à la fois des cartes éditables les plus simples possibles, au service de la précision de la saisie et des cartes valorisant la richesse des propositions et des thématiques.

Schéma d'une organisation possible

Stockage des données spatiales et indexation

Les tables du plugin Carto

TableDescription
carto_basemapConfigurations d’affichage du fond de carte
carto_coordonneeStockage des coordonnées des objets créés via la XPage (hors FormResponse)
carto_data_layerDéfinition de chaque layer (tag solr, type de géométrie, contenu de la popup)
carto_data_layer_map_templateTable de lien entre les couches (layers), la représentation graphique et la carte
carto_data_layer_typeListe des types de couches
carto_geometry_typeListe des types de géométries
carto_map_templateDéfinition globale de la carte (centre, niveau de zoom)

Stockage des données du generic attribute Cartography

À la saisie d’un champ generic attribute de type Cartography, deux champs de la base de données Lutece sont alimentés : coordinates_geojson et DataLayer. Le champ coordinates_geojson contient la géométrie en format geojson de l’objet saisi. Le champ DataLayer contient l’information de la couche de données visée.

{{{ info|En fonction du champ status dans la table genatt_response, la donnée est envoyée ou non dans Solr. Si le status est à 1, la donnée sera indexée. Cela correspond à la configuration de la publication dans le BO.}}}

Extrait de la table genatt_response

id_response, response_value, id_entry, iteration_number, id_field, id_file, status, sort_order
1, {"geometry":{"coordinates":[2.3851318355445987,48.85827758964043],"type":"Point"},"properties":{"address":""},"type":"Feature"}, 3, -1, 13, , 1, 0
2, Coffee, 3, -1, 14, , 1, 0

Indexation dans un Solr

Sont indexées dans Solr, les valeurs enregistrées dans le champ response_value de la table genatt_response. Dans l’exemple ci-dessous, la valeur du champ response_value pour l’individu 1 de l’exemple ci-dessus se retrouve au tag entry_code_question_3_iter_0_geojson. Le tag DataLayer_text contient l’information de la couche de données à laquelle la géométrie est associée.

{
    "uid": "Demo_1_FORMS_FORM_RESPONSE",
    "date": "2023-10-25T10:24:38Z",
    "type": "FORMS_FORM_RESPONSE_1",
    "title": "formResponse 1",
    "site": "Demo",
    "role": "formResponse",
    "url": "jsp/site/Portal.jsp?page=formsResponse&id_response=1",
    "content": {
        "geometry": {
            "coordinates": [2.3851318355445987, 48.85827758964043],
            "type": "Point"
        },
        "properties": {
            "address": ""
        },
        "type": "Feature"
    },
    "id_resource": "1",
    "id_form_response_long": 1,
    "entry_code_question_3_iter_0_geojson": {
        "geometry": {
            "coordinates": [2.3851318355445987, 48.85827758964043],
            "type": "Point"
        },
        "properties": {
            "address": ""
        },
        "type": "Feature"
    },
    "response_creation_date_long": 1698229478000,
    "id_workflow_state_long": 2,
    "entry_code_question_3_iter_0_address_text": "",
    "title_workflow_state_string": "Publié",
    "entry_code_question_3_iter_0_geoloc": [48.858278, 2.385132],
    "DataLayer_text": "Coffee",
    "form_title_string": "Proposition de localisation d'un café",
    "response_update_date_long": 1698229559000,
    "id_form_long": 1
}