WIP osm-journal

laem

J'ai bossé le début de la fonctionnalité côté serveur.

Tous ces noeuds ont été récupérés par notre algorithme Overpass "récupère tous les nouveaux lieux OSM dans le grand ouest".

https://pmtiles.io/#url=https://serveur.cartes.app/gtfs/newOsmPlaces.pmtiles&map=7.35/47.847/-1.35

L'idée maintenant c'est de l'afficher à l'utilisateur pour deux usages : d'une, un journal des nouveautés mensuelles (hebdo ?) dans son quartier. De deux, directement sur le fond de carte pour combler l'écart d'une semaine qu'il y a le jeudi avec OSM.

• créer une nouvelle entrée dans les QuickFeatures à côté du bouton "photos"
• qui va afficher les noeuds sélectionnés par useMapContent (travail déjà commnencé avec map.querySourceFeatures mais qui serait mieux avec queryDisplayed) dans le style des résultats de catégorie, dans l'encart comme sur la carte (donc mapContent.journal doit être mélangé au state ~categoryFeatures de Container)
• trouver pourquoi mon log "fuschia" et les nouveaux lieux ne s'affichent qu'à zoom 10 sur cartes.app mais à tous les zoom sur pmtiles viewer (source de vérité)
• publier une démo et faire tester, on a beaucoup à ajuster sur l'expérience utilisateur, sur la sélection de ce qu'est un nouveau lieu (on pourrait aussi récupérer les diff' d'horaires pour en avoir bcp plus à afficher, car là les nouveaux lieux je me rend compte qu'il y en a pas 36 non plus, peu de chances d'en avoir dans sa rue).
• chose très importante : il faut surtout indexer les lieux qui changent de nom ou de type. Un restaurant qui change de propriétaire, un restaurant qui devient bar, un hangar qui devient salle d'escalade, etc. Pas de changement OSM, mais un changement important à signaler dans le journal.

1. laem

   Deuxième point important : cette BDD OSM (qui n'est qu'un fichier JSON sur notre serveur, MAJ tous les jours) constitue également une BDD cachée bien plus performante qu'Overpass.

   Faut qu'on fasse le pont avec l'annuaire : sur l'annuaire on veut aussi montrer le stock, pas que le flux. Ce stock, il faut qu'on le mette en cache.

   Soit c'est nous qui faisons les recherche chaque mois (restaurants à Chartres, etc.), soit on laisse les indexeurs indexer à leur guise mais on met tout en cache pour que le prochain (ou le même qui revient, ils sont trop cons c'est ouf) n'impose pas une requête OSM à nouveau.

   Je suis plutôt favoriable à l'option 2 : dans l'option 1 on risquerait de générer une immense BDD pour pas grand chose, car si les Sushis dans le Perche n'intéressent personne, inutile de le requêter.

   Pour faire l'option 1), on pourrait en fait carrément renverser la logique : parcourir tous les lieux OSM d'un pays et les ranger dans le bon sac. Et donc pas utiliser Overpass mais un dump statique osm.pbf mensuel.

2. laem

   Enfin, ce journal, il faudrait l'indexer. S'il est important d'avoir le stock via l'annuaire, il est peut-être encore plus important d'avoir les nouveautés qui peuvent être exclusives !

   C'est de là qu'est né notre new-osm-places.

   L'avoir dans le sitemap c'est une chose, mais le montrer sur l'annuaire, c'est mieux. Le sitemap n'est que le complément de liens qui doivent être affichés dans le HTML.

3. etienneJr

   Est ce que ça pourrait t'aider d'utiliser clearance ? La prés de Frédéric au SOTM : https://peertube.openstreetmap.fr/w/uMfmHvtWgSA4wCFWCAc9Ps Tu y avais assisté ?

4. laem

   MMMh, l'essentiel étant déjà fait côté serveur, je ne crois pas. Mais je garde en tête pour l'implé. C'est surtout de l'UX qui reste.

5. laem

   C'est sûr que ça pourrait aider pour les rapprochement sémantiques plus complexes. Mais notre back sur le coup est tellement simple qu'on pourra brancher une v2 de l'UI sur clearance si besoin. Je pense que 90 % des nouveautés d'un quartier seront attrapées avec un algo simple "nouveau POI", "changement de nom".