Ĝis : billet d’étape n°3 juillet 2022

Ĝis est un outil de saisie de données cartographique et territoriale. Vous lisez la troisième édition de la lettre mensuelle qui en raconte les développements, doutes, détails inutiles…

Que s’est-il passé en juillet ?

Canicule, pont, vacances estivales : ce mois-ci a été un peu plus calme.

Sur le plan du nom, rien n’a encore été décidé, même s’il semblerait qu’on penche vers coocarto.

Côté réalisations, deux fonctionalités structurantes sont arrivées.

Gestion des droits

Parce qu’un outil de collaboration en temps réel sans droit, c’était un peu limité. Vous pouvez désormais inviter des personnes et leur assigner des droits. Très bientôt vous pourrez également publier des cartes visibles par tout le monde, même sans compte sur Ĝis.

Toutes les modifications apportées par les autres personnes sont visibles en temps réel sur votre page. Ainsi vous réduisez le risque de conflit si vous travaillez sur les mêmes objets.

Gestion des territoires

Vous pouvez désormais créer une couche dont la donnée géographique est un territoire. Par exemple lorsque vous souhaitez que vos données soient associées à un département.

Nous pensons qu’une gestion éditorialisée du référentiel des territoires sera un élément fortement différenciant :

• Pour les instances auto-hébergées, les données métier de l’entreprise ou de l’administration pourront être mise à disposition, facilitant ainsi leur utilisation.
• Pour l’instance en SaaS, l’utilisateur trouvera très rapidement les données habituelles, sans devoir les chercher et importer soi-même.
• Dans les deux cas, les identifiants seront toujours les bons : finies les erreurs de saisies de code INSEE des communes et l’agacement des personnes devant utiliser la base que vous avez construite.

Une même couche peut porter sur plusieurs territoires. Par exemple, il est possible de choisir Commune et Intercommunalités.

Un focus technique : base de données

PostgreSQL est une base de données relationnelle libre réputée pour sa grande robustesse.

Nous essayons au maximum de nous appuyer dessus et en faire le moins possible au niveau du code.

Les géographies

Les données géographiques (points, tracés et polygones dessinés par l’utilisateur) sont stockées dans des colonnes grâce à l’extension spatiale PostGIS qui fait également des calculs (bounding box…) et des conversions (geojson).

Les attributs

Les données tabulaires associées à chaque objet ressemblent furieusement à une table de base de données.

Nous avons été très tentés de faire en sorte que chaque table d’attribut soit une table postgresql. C’est par exemple ce que fait NocoDB.

Cependant, cela pose de nombreuses limitations si l’on souhaite renommer une table, supprimer une colonne… En particulier le serveur backend devrait systématiquement recharger le schema de la base à chaque requête, et non pas au chargement.

Nous profitons donc d’un autre aspect où PostgreSQL brille tout particulièrement : les colonnes de type JSONB.

Ainsi, les données utilisateur sont stockées dans une structure en JSONB et les données techniques dans des tables « traditionnelles ».

Cartographe du mois : l’école majorquine

Plutôt que de parler d’un cartographe en particulier, nous présentons ici toute une famille de cartographes, tout à fait adaptée pour avoir les orteils dans le sable d’une plage.

L’école majorquine est connue pour ses portulans qui servaient à la navigation en indiquant les ports, les dangers potentiels et des caps à tenir.

Ce besoin de cap que les navires vont suivre (ou Loxodromie) rend les portulans incompatibles avec des planisphères représentants le monde entier ; du moins jusqu’à la révolution qu’a apportée Mercator, mais ce sera pour une autre édition.

Leurs portulans couvrent généralement la Méditerranée, mais vont parfois au-delà.

Conclusion

Comme en juin, nous sommes preneurs de retours, rapports de bugs, besoins concrets et d’idées pour un nom. N’hésitez pas à nous écrire !