Bonjour,
J’avais envie de vous présenter un outil « cocarto » que nous développons au sein de ma coopérative Codeurs en Liberté. Évidemment vu le forum, je le prends sous l’angle de géocommuns 
C’est un outil pour maintenir simplement des base de données spatiales, assez petites pour tenir dans un tableaur, trop grandes pour être facilement mises à jour à plusieurs. Bien évidemment c’est libre (licence AGPL).
Origine
Au travers de différentes missions et actions militantes personnelles, on a vu la galère de maintenir des bases de tailles moyennes à plusieurs et de s’intégrer dans des systèmes carto et base de données existantes.
Souvent il s’agit de tableurs avec une colonne longitue/latitude copiée-collée, ou une adresse mal formatée, ou un code insee de commune qui perd son 0 initial à cause d’excel.
Ça peut être des données qui n’ont pas nécessairement raison d’exister dans OpenStreetMap (exemple concret: association cyclistes qui veut lister les aménagement insatisfaisant selon leurs critères, la collectivité responsables du blocage et l’association qui fait de la pédagogie auprès des élus pour améliorer les infrastructures).
Simplement
Il faut savoir utiliser un tableau, mais pas une base de données telle que postresql ou QGis.
Intégration autres systèmes
Import/export
Souvent les données viennent, ou bien sont consommées par des services cartographiques ou d’autres bases de données.
L’import et l’export sont donc un élement central. On gère ainsi du WFS, on peut ré-importer des données d’un autres service tout en conservant les colonnes d’enrichissement sur lesquelles on a passé beaucoup de temps.
Typage des colonnes
Tout comme Airtable et ses nombreaux clones (grist, nocodb, baserow…) chaque colonne (attribut) est typé. On ne peut-pas saisir « peut-être » dans une colonne Oui/Non, c’est une case à cocher.
On a aussi un type « territoire » pour saisir des communes et exporter les codes insee (aucun risque de se retrouver par accident avec un code postal).
Bref, la cohérence des données est essentielle et permet une bonne interopérabilité dans les deux sens.
Typage des couches
Alors, là, il faut l’avouer, ça a été un gros débat On a opté pour que chaque couche géographique soit d’un seul type (point, linestring, polygone…) et on ne permet pas des couches hétérogènes (comme on le pourrait par exemple avec un éditeur geojson).
Le but étant de guider un utilisateur peu expérimenté avec les SIG de produire une donnée qui sera facilement utilisée par des service cartographiques habitués aux shapefile ou geopackage aux couches homogènes.
Collaborativement
Les modifications sont visibles en live (tableau et carte), les permissions sont fines (lecture seule, contribution en append-only, etc.) avec la possibilité de générer des liens avec ces droits pour contribuer sans devoir se créer de compte.
Par exemple le lien suivant https://cocarto.com/fr/share/_zUCyV1K1zzfyrDj permet d’imaginer un usage où chacun peut ajouter son camping municipal sans modifier les données des autres (attention, ça a plutôt une vocation de démonstration. Les données sont issues de OpenStreetMap et donc soumises à l’ODbL avec les conditions particulières d’utilisation OSM)
Business model
Nous ne sommes pas une startup, mais une coopérative de service en informatique. C’est pour ça que c’est une évidence que cocarto est libre et que nous ne comptons pas gagner d’argent avec un modèle SaaS.
Nous souhaitons surtout nous financer avec des développement spécifiques, de l’accompagnement pour intégrer des données spécifiques…
Assez parlé
Si jamais les problèmes évoqués vous parlent, ça nous ferait plaisir d’échanger (même si ce n’est pas pour utiliser cocarto, juste pour qu’on découvre comment vous avez traité des problème similaires).
Et si vous voulez suivre d’une oreille distance ce qu’on fait, on a une newsletter Infolettre de cocarto • Buttondown (un peu moins d’un mail par mois) et un blog avec le même contenu cocarto · Codeurs en Liberté