Bonjour,
il me trotte dans la tête depuis un moment de construire une webapp qui ferait interface avec les données OSM sur une thématique en particulier : d’une part pour accéder aux données déjà disponibles et d’autre part pour alimenter la base en données.
J’ai en tête des choses comme https://parc-epique.fr/ (mais qui ne me semble pas remonter les données vers OSM) ou www.mediamanif.com (pareil)
Est-ce que vous avez déjà connaissance de productions similaires ? Par quel bout démarrer la réflexion (selon ce qui est possible ou non avec OSM) ? Est-ce que c’est réaliste avec un niveau de connaissances encore limitées (d’OSM & des webapps, autant se le dire) ?
Merci de vos retours !
PS : pour cas d’usage, il s’agirait de donner la possibilité de localiser à proximité les lieux favorables à l’allaitement (‹ nursing_room ›, probablement) ainsi que les espaces permettant de changer un enfant (‹ changing_table ›, je suppose) quand on est dans au milieu de la jungle urbaine et qu’il fait faim ou que la couche a débordé… 
Bonjour,
Regarde du côté de mapcomplete, ça devrait convenir à tes besoins et te faire gagner du temps
Il existe aussi mapcontrib
https://www.mapcontrib.xyz/
2 « J'aime »
oui c’est exactement l’objectif que nous avions lors du développement de mapcontrib, pouvoir avoir des cartes, responsives, à la demande !
d’ailleurs il y en a quelques unes MapContrib mais qui fonctionnent pas bien (trop de requêtes parrallèles) donc le thème se fait bloquer.
1 « J'aime »
Salut,
Mapcontrib est super chouette mais implique que le contributeur ait un compte osm, c’est bien ça ? Ca permet de remonter directement les données dans OSM mais ça peut limiter l’envie de contribuer de ceux qui n’ont pas encore de compte, non ?
Pour https://playguide.eu (webapp des aires de jeux, équivalent à parc-epique) on voulait que tout le monde puisse contribuer sans compte à créer du tout, ça facilite la contribution dans la webapp, mais ça complique la contribution à OSM. On a une copie locale des données osm des aires de jeux qu’on synchronise régulièrement (tous les trimestres en gros). L’export d’osm est facile (quoique il faut faire attention aux node transformés en way, aux tags modifiés, etc).
L’import vers OSM est plus compliqué, car les données de nos utilisateurs (non sensibilisés à OSM) ne sont pas toujours très précises. Nous faisons donc les imports manuellement, à partir d’un geojson généré par la webapp, qu’on vérifie dans JSOM avec les vues aériennes (ça marche pour les aires de jeux vu que c’est en extérieur) avant de valider l’import.
1 « J'aime »
Aaaah, merci !
c’était sur MapContrib que j’avais commencé à creuser le sujet il y a quelques années mais je l’avais perdu de vue depuis
Très intéressant en effet.
En revanche, pour du grand public, on est d’accord que ça permet de restituer des données déjà en base mais pas de participer à l’alimenter sans s’être connecté avec un compte OSM ?
Très intéressant PlayGuide, ça me semble être assez proche de ce à quoi je pense.
Du reste, je n’ai pas réussi à trouver si votre appli avait une documentation technique pour voir si mon niveau technique me permettrait de m’en inspirer ?
Merci !
oui nous avons imaginé parfois l’idée d’un compte pour la carte, pour éviter que les gens aient des comtes à créer, comme cela a pu être fait avec CaresteOuvert par exemple et le compte CaResteOuvert qui alimentait OSM sans que les gens aient à se créer un compte.
cela pose pas mal de question de suivi, régulation de la donnée.
Nous creusons cette question aussi avec Gogocarto, pour permettre d’interroger la donnée osm et contribuer à osm à travers un compte OSM de la carte. Gogocarto ayant des systèmes de validations qui pourraient permettre de faciliter l’envoi des données sur OSM sans que cela soit non plus automatique
1 « J'aime »
Rendre notre code open-source était dans nos objectifs initiaux, mais on n’a pas fait l’effort de le rendre propre, de le documenter, et de le déposer qq part… Dans un premier temps on pourrait au moins faire un post de blog pour expliquer techniquement comment le site est codé.
De plus je vois plusieurs limites à une réutilisation :
- on avait réfléchi notre code spécifiquement pour les aires de jeux, je ne sais pas si il serait facilement transposable à d’autres éléments.
- les synchronisations ponctuelles entre osm et notre copie locale n’ont pas été pensées dès le début mais rajoutées après coup, et c’est galère. Avec l’expérience je ne le ferai pas de la même aujourd’hui, et je m’orienterais vers un système bcp plus interfacé, comme dans les exemples proposés par @vinber (même si techniquement j’imagine que c’est bien plus compliqué !)
1 « J'aime »