GoGoCarto

#1

Je reprends ici un chouette échange avec Sébastien Castro de TransiScope

Salut,

“mais comment faire en sorte que des éléments ajoutés sur une carte A (et dans une certaine catégorie) soient visibles sur une carte B et vice versa”

Les carte A et B doivent mettre à disposition leur données de manière dynamique (c’est une url, appelée API, qui renvoie toujours la dernière version des données)

Les cartes A et B doivent avoir un système d’import dynamique qui va chercher les données via l’API de l’autre carte, pour les afficher en plus de ses propres données

C’est justement ce qu’on fait sur transiscope, avec GoGoCarto.

Si les données des cartes A et B ne sont pas homogènes, on utilise grappe.io pour faire la transformation

Par exemple presdecheznous.fr (qui a environ 14000 point) affiche aussi les données de CapOuPasCap (4000 points supplémentaires)

Transiscope lui n’a aucun point en sa possesion, il ne contente d’importer les données de toutes les autres cartes

Chaque instance de gogocarto dispose d’une API, par exemple sur PDCN https://presdecheznous.fr/api

Et Chaque instance de GoGoCarto peut importer d’autres données, par exemple sur PDCN :

Ces import dynamique ils marchent comme ça : tous les 4 jours, je télécharge toutes les données de CapOuPasCap, je les compare avec la dernière version des données de CapOuPasCap que j’avais déjà récupéré, et je les met à jour si besoin

Est ce plus clair?

Sachant que l’on commence aussi a developper un système plus avancé de partage de données avec GoGoCarto, pour facilement interfacer des cartes gogocarto entre elles. Avec le système d’activityPub (utilisé par exemple sur Mastodon ou sur peertube) les cartes seront mises à jour de manière quasi instantanées.

Par exemple: j’ai une carte sous gogocarto (presdecheznous), je veux afficher les données d’une autre carte gogocarto (qui peut être sur un serveur different, par exemple incommons.gogocarto.fr).

Sur presdecheznous.fr, je vais entre l’adresse “incommons.gogocarto.fr”, ça va envoyer une demande à inCommon pour accepter le partage, puis ensuite a chaque fois que inCommon sera modifié, ça enverra un message a presdecheznous pour l’informer du changement (tel nouvel element ajouté, tel element supprimé ou modifié etc…). On y est pas encore, mais on déjà bien avancé !

bonne journée !

1 Like
Préparation de la rencontre InterMapping
Mardi en Commun 5
#2

Salut, votre recherche est intéressante mais pose quelques questions :

  • quelles sont les modalités de validation des données à synchroniser ?
  • comment gérer les « modifications locales » (par exemple, une description vérouillée à une version particulière qui fait autorité localement) ?
  • qui contrôle ces processus ?

Comme le faisait remarquer @fodevaux par ailleurs, il est important que chaque carte puisse disposer des données qui la concerne et ce, sans obligation de synchronisation. La synchronisation doit permettre de faciliter le partage de données « à jour », mais pas empêcher des divergences locales (par exemple, considérer les modalités de FedWiki à ce titre). J’ai l’impression que votre approche part du principe que la dernière version des données est la meilleure (voire, la seule).

D’autre part, les questions ci-dessus procèdent d’une réflexion que nous avons eu (et continuons d’avoir) au sein d’IN COMMON sur les modalités d’engagement collectif sur la création et la maintenance des données. Il nous semble fondamental que les « gestionnaires de données » forment des entités collectives de sorte que l’évolution de l’ensemble des données soit soumise à la décision collective, dans le sens d’une gestion des communs plus que dans l’esprit d’un contrôle décisionnel – il est notamment souhaitable de trouver un équilibre entre une prise de décision experte et démocratique, et entre une facilité de gestion d’un large corpus de données (ce qui ne manquera pas d’arriver) et une subsidiarité effective de son évolution (en restant au plus près des personnes concernées par ces données). Une solution de simple synchronisation entre plusieurs jeux de données est d’autant plus insuffisante que leur validation met en jeu des critères éthiques soumis à notre Charte ; la notion d’agent collectif comportant des rôles distincts permet d’assurer une gestion collective, voire transindividuelle, et de développer des correspondances entre cartes et agents qui intègrent la confiance entre act·eur·ice·s.

Cartographie la Transition francophone
#3

Salut @how !
Désolé je ne suis pas sur de comprendre parfaitement tes questions, je pense qu’on emploie pas les meme termes pour les meme choses :slight_smile: tu peux prendre des examples stp?

#4

Oui, c’est effectivement sur ce point que nous travaillons, et que j’ai un doute sur le fait que la « propreté des données » soit un facteur suffisant – car elle ne garantit aucunement la qualité éthique des données par exemple : là, il est très difficile d’imaginer une solution technique et d’éviter l’intervention humaine.

Comment les données à synchroniser (dans ta saisie d’écran « mis à jour ») sont-elles validées ? Par exemple, dans OSM 516 mis à jour, on parle de données géographiques, et on espère que les modifications sont valides. Dans ce cas là on fait confiance à la communauté des utilisateurs d’OSM qui fonctionnent selon des procédures connues. Dans d’autres cas rien n’est moins sûr. Par ailleurs, lorsqu’il s’agit de données non-géographiques mais localisées, une « nouvelle version » disponible n’est pas synonyme de meilleure qualité : si on prend l’expérience de WikiPédia, il est facile d’imaginer des « guerres éditoriales » sur « la bonne manière » de formuler les choses.

L’une des stratégies pour « valider » une donnée localement peut être d’en vérouiller la version, de sorte qu’un intermédiaire humain (dans le cas d’IN COMMON : le membre un agent) puisse faire le choix de refuser une mise à jour contraire à la politique éditoriale du site.

Existe-t-il des normes ou des règles pour faciliter ce filtrage des données ? Lorsqu’on est dans une situation de « noyade » face à un flot incessant de nouvelles données ou de correction de données existantes, il s’agit de bien comprendre comment la qualité des donnée (et non simplement leur format) peut être garantie. Dans IN COMMON, il s’agit d’un processus collectif et de choix granulaires sur la correspondance entre les données en provenance d’un certain agent (affectées ici à une catégorie A d’une carte 1) et une catégorie spécifique sur la carte 2 qui bénéficie de ces données mises à jour (par exemple, en autorisant une synchronisation automatique entre les données de la catégorie A de la carte 1, vers la catégorie B de la carte 2).

Est-ce que cela facilite ta compréhension de la problématique que nous souhaitons résoudre ?

Dans le cas d’exportation de données IN COMMON vers la Grappe, nous fournissons un jeu de données unique qualifié “IN COMMON” qui répond à la Charte et qui forme l’ossature commune de l’ensemble des cartes utilisées par les membres du collectif ; en revanche, il n’y a aucune garantie d’exhaustivité de ces données : il est même certain qu’une partie des données affichées sur l’une des cartes ne soit pas synchronisée avec la base de donnée commune, par exemple dans le cas de données qui ne répondent pas à la Charte.

Dans le cas d’importation de données depuis la Grappe vers IN COMMON, ces données rentreraient nécessairement dans la file des processus de gestion collective des données : car il me semble improbable que des données agrégées depuis n’importe où puissent intégrer directement un corpus de qualité sur les communs sans vérification préalable. Les processus internes à IN COMMON permettent de créer des assurances de qualité basées sur la confiance réelle que se portent les collectifs qui partagent leurs données, mais comment reporter cet aspect directement au niveau de la Grappe ?

#5

Merci pour les précisions ! Je comprend mieux les questions.

Pour moi, dans ce topic on parlait juste “technique”. En fait mon mail était une réponse à une question technique de l’utilisation de gogocarto.

Là tu soulève surtout des questions par rapport à la modération/validation. Ces questions sont évidemment primordiale, mais je sais pas si il est bon de parler des deux choses dans le meme topic!
De même ma remarque sur la propreté des données est bien sur la partie technique.

Pour la partie “éthique, validation, processus”, nous (Transiscope, PDCN) on fait “simple” : on se renseigne sur la source des données (charte, processus de modération…) et si ça nous va, on fait confiance et on intègre. Techniquement, on peut modérer a postériori les données ainsi importés : si l’on décide de manuellement supprimer certaines des données importées, elle ne le seront plus

“mais comment reporter cet aspect directement au niveau de la Grappe” -> en attachant le nom de la source à la donnée? Ensuite tu peux choisir “je veux récupérer telle et telle catégorie dans telle ou telle source”. non?

#6

Il s’agit bien d’un sujet technique, la validation des données à deux aspects un aspect collectif et un aspect technique, c’est bien de ce dernier dont nous parlons ici.

c’est important que cela reste simple, mais il faut se rendre compte que si le nombre de données augmente ces processus ne seront plus applicables, le problème se pose également sur le long terme conserver des données valables au travers des différentes mutations des projets déménagements changements d¡équipe etc,

C’est à ce point que comme l’explique @how la structure des données doit intégrer des éléments permettant leur organisation et leur validation, comme les agents par exemple, et la gestion de ces éléments est une question qui doit être aborder collectivement, c’est a ce moment que l’on rentre dans l’organisation humaine.

Dans ce cas comme dans bien d’autre séparer les questions techniques et humaine est vraiment contre productif je crois,

1 Like
#7

« Juste “technique” » pour moi n’a aucun sens : les libertés collectives du logiciel libre s’appliquent au « juste technique », sans quoi on ferait du logiciel propriétaire et on n’aurait aucune notion de logiciel libre. C’est aux humains de définir ce qui est « juste technique », et notre manière de le faire, c’est d’engager le collectif dans la création technologique.

#8

Merci @Sebastian pour tes explicaion.

J’ai navigué hier à travers GogoCarto et je suis bluffé par l’outil (+doc +“soin” + performances +…) que vous avez mis en place. Impressionnant !!!

J’ai créé une carte sur http://www.gogocarto.fr et ai mis du temps à m’endormir en imaginant toutes les possibilités offertes par cet outil pour les nombreux collectifs et projets qui se développent chez nous. Je dois un peu digérer ça, mais je tiens déjà à saluer votre magnifique travail…

1 Like
#9

Merci @fodevaux pour ton retour !

how, natacha, moi ce que je voulais juste aborder ici c’est que

  • On a développé un outil pour faire de la carto et de l’interop -> GoGoCarto
  • Si vous avez des questions sur les fonctionnalités actuelles et les futurs développements prévus, je serai ravi de répondre à vos question
  • Si après avoir cerné l’outil, vous voulez l’utiliser, mais qu’il vous faut telle ou telle fonctionnalité supplémentaire, je serai également très content d’essayer de répondre à vos besoin (dans la limite de mon temps bénévole).

Pour ce qui est de la définition de votre besoin et de votre organisation, vous avez l’air d’être déjà bien investi et je n’ai pas l’intention de m’immiscer dans vos réflexions

Belle journée à tous

1 Like
#10

Nous sommes dans l’attente d’un gros financement pour IN COMMON. Il est orienté autour d’une stratégie de développement particulière. Selon ce que je perçois ici, dans l’enthousiasme de @fodevaux, dans les relations que nous sommes en train de former avec d’autres projets, dont celui-ci, il m’apparaît que si ce financement arrive, nous devrons reconsidérer cette stratégie afin de l’adapter à la situation la plus favorable à une insistance collective en cours de formation. Cela implique d’une part de réorienter notre approche technique vers l’intégration de GoGoCarto, et d’autre part d’assurer entre tous ces projets une possible collaboration. Dans cette optique, nous devons envisager non seulement des modalités techniques (adapteurs, transformateurs de données…) mais surtout des ambitions communes; c’est pourquoi nous devons, me semble-t-il, favoriser l’émergence d’un collectif au-delà des différentes approches techniques, même si une convergence technique est envisagée; les semaines prochaines sauront nous indiquer quelle sera l’ampleur de notre effort… J’invite donc à imaginer un changement d’échelle possible et à terme un événement qui rassemblera les act·eur·rice·s de la cartographie des communs – ceci se fera sans doute sous la bannière d’InterMap comme l’a proposé par ailleurs @yala.

2 Likes
#11

Tout à fait aligné avec ces éléments, Hellekin !

1 Like