Création d'une section "Informations complémentaires"
publié le , mis à jour⚙️ Ceci est une proposition de changement de code.
Rendez-vous sur sa page Coderberg pour l'osculter.
avec
- affichage des Coordonnées GPS / Plus Code en permanance
- Ajout de liens vers des services externes
- Déplacements de toutes les informations secondaire dans cette nouvelle section:
- SIREN/SIRET
- Code FANTOIR
- MGP
- code sandre
- ...
Plié:
Depliés:
pmiossec
Note:
- on peut encore plus faire le menage pour mettre le max de choses peu indispensables dans cette section....
- Ne pas faire attention aux icones manquantes qui cassent la mise en page (je ne sais pas pourquoi elles ne s'affichent pas en local)
etienneJr
@pmiossec wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8813061:
2. Ne pas faire attention aux icones manquantes qui cassent la mise en page (je ne sais pas pourquoi elles ne s'affichent pas en local)
Je pense que c'est expliqué ici : https://codeberg.org/cartes/web/src/branch/master/CONTRIBUTING.md#env-variables Il faut faire un bun install après avoir paramétré
DOWNLOAD_OSMAND_ICONS_ON_INSTALL = truePeux tu tester et me dire si ça marche ?@pmiossec wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8813061:
- on peut encore plus faire le menage pour mettre le max de choses peu indispensables dans cette section....
Quand j'y avais réfléchi une fois, je m'étais demandé si il fallait écrire une liste des tags primaires, ou une liste des tags secondaires. Je n'avais pas vu entre temps que @laem avait créé cette liste des tags secondaires.
Par exemple dans ta dernière capture
source:name:ocmériterait d'être dans les tags secondaires. Il va falloir "attraper" tous les tags qui ressemblent à ça ?D'ailleurs, hier @laem a fait une modif (pas encore fusionnée) sur ces tags contenant
:, j'imagine que tu l'as vue ? https://codeberg.org/cartes/web/pulls/1302/commits/7c7a910d8f8843bfaf1b6816b1d8bedc97a6d60elaem
Je ne suis pas vraiment convaincu par ce changement. Pour moi aujourd'hui, vu le manque d'infos global sur les lieux chez OSM vs Google Maps, je trouve au contraire que la fiche annuaire entreprise est une richesse.
Certes, c'est de l'information plutôt administrative par rapport à de l'information "client", mais c'est déjà ça. Pour le client, ça représente quand même un lien qui montre que ce commerce est officiel. Dans le futur, on pourrait pousser jusqu'à aller vérifier la cohérence de l'adresse du SIRET et le statut de l'entreprise, pour par exemple informer l'utilisateur sur le fait qu'OSM a du retard car l'établissement est fermé.
Le lien "annuaire entreprise" qu'on voit dans la capture semble alors manquant dans cette nouvelle version. Par rapport à lui, les informations "paiement par carte de x" sont peu pertinentes : en France sauf dans les marchés, les paiements par carte sont totalement généralisés.
Quand j'y avais réfléchi une fois, je m'étais demandé si il fallait écrire une liste des tags primaires, ou une liste des tags secondaires. Je n'avais pas vu entre temps que @laem avait créé cette liste des tags secondaires.
Oui c'est l'idée, pour l'instant SecondaryTags ne gère que les codes entreprise, on pourrait y mettre d'autres choses en changeant le composant, c'est le but, mais il faut qu'on garde le réflexe d'interpréter les tags avant de les y mettre. Dans l'implé actuelle le SIRET et SIRENT vont dans cet encart, mais le lien annuaire entreprise maintient l'information dans la fiche sans avoir à déplier.
Dans le même genre on pourrait mettre les 2 tags "carte de xx" dans les informations secondaires mais en créant avant un petit composant icône carte de crédit avec title="Accepte les cartes de x" :)
Le lien "annuaire entreprise" qu'on voit dans la capture semble alors manquant dans cette nouvelle version.
Il y est bien mais sous la forme du lien SIRET. J'ai meme rajouté le SIREN de la meme façon.
Oui c'est l'idée, pour l'instant SecondaryTags ne gère que les codes entreprise, on pourrait y mettre d'autres choses en changeant le composant
C'est le but de cette PR (mais y'en a enormement à gérer), de deplacer dans cette zone les infos non essentielles et de rajouter des liens comme "annuaires entreprises" si possible.
Donc y'a plus un enrichissement d'infos qu'une perte 😉
Après, l'annuaire d'entreprise me parait peu utile pour la majorité des utilisateurs c'est pourquoi j'ai decidé de le deplacer...
Le lien vers l'INSEE par exemple est vraiment cool car il donne acces à plein d'infos!
@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8820744:
Je pense que c'est expliqué ici : https://codeberg.org/cartes/web/src/branch/master/CONTRIBUTING.md#env-variables Il faut faire un bun install après avoir paramétré
DOWNLOAD_OSMAND_ICONS_ON_INSTALL = truePeux tu tester et me dire si ça marche ?c'est bon.
Pas mal de nouveaux tags mis dans
secondaryTags.yamlet support de nouveaux liens danssecondaryTags.yaml.Je pense que c'est mergeable maintenant...
@pmiossec sur la forme, est-ce que tu pourras à l'avenir procéder par commits unitaires ? J'ai l'impression que dans ta branche, tu fait des --amend sur le seul commit, ce n'est pas une bonne pratique, car ça ne permet pas de voir l'évolution de la PR.
Sur le fond, je ne suis pas sûr de comprendre ou de valider l'intention de cette PR, comme je le disais plus haut.
L'affichage de la fiche annuaire entreprise au premier plan était volontaire, ce n'était pas une erreur, cette PR propose une régression à cet égard.
Autre exemple : la zone RATP (ou STIF) me semble pertinente au premier plan pour les arrêts de transport.
Globalement, je suis davantage partisan de laisser la communauté OSM s'exprimer : si un tag est présent sur un lieu, c'est qu'il est pertinent de l'afficher. De notre côté, c'est à nous d'en améliorer l'affichage au fur et à mesure aussi bien qu'on peut.
J'avais créé le composant SecondaryTags plutôt pour donner un complément d'information sur des tags que nous avons mis au premier plan. Ainsi les codes SIRE* et NAF sont complémentaires au lien annuaire-entreprise qui est une amélioration de notre part de cet ensemble de tag. Il est vrai qu'on peut avoir l'impression que le composant reléguait le code NAF sans l'afficher au premier plan, mais pas tant car l'annuaire des entreprises donne bien le code NAF et son libellé dans la fiche entreprise.
@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946561:
la zone RATP (ou STIF) me semble pertinente au premier plan pour les arrêts de transport.
En l'occurence concernant ce tag, je pense qu'il n'est plus pertinent maintenant qu'ils n'y a plus de zones en IdF. Il faudrait probablement nettoyer OSM pour le supprimer partout ?!?
J'ai du mal à suivre le débat sur SIREN, NAF, etc car je ne connais pas ces tags. Ca m'embête que cette PR soit bloquée à cause de ça (juste de ça?), car sur le constat plus général, je suis d'accord avec @pmiossec que la fiche lieue est polluée par des tags illisibles ou sans intérêt qu'il faut absolument masquer pour que cette fiche lieu soit adaptée au grand public, donc ne ressemble pas à osm.org ou autre outil de consultation de la base OSM.
Est-ce qu'on peut trouver un compromis ? Si je comprends bien, il faudrait mettre en forme tous les SIRE*, NAF, etc dans un bloc unique "infos légales" (qui serait toujours visible), c'est ça ?
Si je comprends bien, il faudrait mettre en forme tous les SIRE*, NAF, etc dans un bloc unique "infos légales" (qui serait toujours visible), c'est ça ?
C'est déjà le cas avec le lien "annuaire entreprise", cette PR supprime ce lien.
je suis d'accord avec @pmiossec que la fiche lieue est polluée par des tags illisibles
Oui c'est vrai, mais discutons de chaque tag un par un en choisissant parmi :
- le cacher dans le <details, une décision forte qui l'invisibilise pour 99 % des utilisateurs
- l'utiliser dans un nouveau composant personnalisé (comme les étoiles du restaurant, super ajout !)
- le reléguer en bas de la liste visible sans le cacher (système de priorité des informations) : par exemple le type de cuisine d'un restaurant, c'est plus important que le fait qu'il accepte la carte ou pas car l'écrasant majorité des restos de France acceptent la carte.
Par exemple, si les zones RATP sont obsolètes, alors c'est le tag qu'il faut supprimer, ce n'est pas à nous de décider qu'il n'est pas pertinent. À ma connaissance, elles restent pertinentes.
@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946333:
@pmiossec sur la forme, est-ce que tu pourras à l'avenir procéder par commits unitaires ? J'ai l'impression que dans ta branche, tu fait des --amend sur le seul commit, ce n'est pas une bonne pratique, car ça ne permet pas de voir l'évolution de la PR.
Ma vision du commit est plutôt de garder ensemble (quand cela est possible) un ensemble cohérent de changements. J'ai effectivement amendé pour ne garder qu'un commit dans un état satisfaisant dans l'optique de le voir merger car les modifications réalisées était mineures et ne portaient quasiment que sur l'ajout de tags dans
secondaryTags.yaml. Mais c'est OK pour moi de laisser tels quel pour la revue et de retravailler l'historique si besoin et si possible pour avoir un historique plus lisible (si on doit le relire dans le futur) à partir du moment où la PR est validée.@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946561:
Sur le fond, je ne suis pas sûr de comprendre ou de valider l'intention de cette PR, comme je le disais plus haut.
Le but de cette PR est d'améliorer l'UX/UI de la majorité des utilisateurs en ne gardant visible directement que les informations les plus pertinentes et de reléguer derrière la section "Informations complémentaires" (soit à 1 click) toutes les informations plus techniques ou avancés. Soit, faire un tri pour ne pas avoir à lire un très gros pavé (avec pour le moment de nombreuses clés techniques) à la recherche des infos utiles.
@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946561:
L'affichage de la fiche annuaire entreprise au premier plan était volontaire, ce n'était pas une erreur, cette PR propose une régression à cet égard.
C'était une demande 😋 https://codeberg.org/cartes/web/pulls/1299#issuecomment-8787534 (et je suis plutôt aligné avec çà: je ne pense pas qu'il y a beaucoup d'utilisateurs qui aient besoin d'accéder au site de l'annuaire d'entreprise pour nécessité l'affichage par défaut). Mais ça ne me derrange pas de le remettre.
@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946561:
Globalement, je suis davantage partisan de laisser la communauté OSM s'exprimer : si un tag est présent sur un lieu, c'est qu'il est pertinent de l'afficher.
C'est pour ça que je n'ai rien enlevé. Pour moi, tout afficher ne veut pas forcement dire ne rien hierarchiser.
De notre côté, c'est à nous d'en améliorer l'affichage au fur et à mesure aussi bien qu'on peut.
C'est ce que je pensais avoir fait avec cette PR et elle n'est surtout pas incompatible avec çà (bien que je doute que beaucoup de ce qui a été caché mérite une meilleur mise en valeur et donc qu'on y alloue du temps à court terme) et on peut toujours rebouger les tags au fur et à mesure qu'ils sont traités et mis en valeur.
@laem wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8946561:
Autre exemple : la zone RATP (ou STIF) me semble pertinente au premier plan pour les arrêts de transport.
Je ne sais pas si c'est par chance mais c'est le seul tag pour lequel j'ai hésité ;) Je pense également qu'il devrait peut-être être dans les informations principale, même si je ne suis pas convaincu que c'est une information recherchée si souvent, mais je l'ai basculé dans les tags secondaires pour justement pouvoir le mettre en forme et le rendre lisible par tous (car la clé n'était pas parlante) ET que pour cela il fallait le mettre en tag secondaire. Mais je suis d'accord pour le bouger si je trouve (ou on m'indique) comment le mettre en forme s'il est dans la liste principale.
Je vais moi aussi prendre un exemple 😋 Le tag
check_date:shelterdans ton screenshot est l'exemple typique d'une donnée uniquement utile pour un contributeur OSM et je pense qu'aucun autre type d'utilisateur trouve cela utile et que donc c'est une donnée qui peut être releguée en information complémentaires (je vais l'ajouter 😁). Idem pour les notes et divers ref ou id qu'on ne peut pas exposer en tant que lien (comme j'en ai rajouté un certains nombres).Merci pour la réponse détaillée !
@pmiossec wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8958843:
C'était une demande :yum: #1299 (commentaire)
aïe oups tout est de ma faute 🫣 désolé !!
Donc le seul point de blocage est l'emplacement du lien vers l'annuaire entreprise, tu le rétablis et on peut merger, ok ?
@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8959515:
<img src="https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExM3hjNWwyMThxOHRrbG8xZTZ1bXliMzhkajRzd3Ezcmh5YzM5eWFxcCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/Dvw2lJqlTuJmo/giphy.gif" />aïe oups tout est de ma faute :face_with_peeking_eye: désolé !!
i.e. j'avais la même idée...
@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-8948112:
En l'occurence concernant ce tag, je pense qu'il n'est plus pertinent maintenant qu'ils n'y a plus de zones en IdF. Il faudrait probablement nettoyer OSM pour le supprimer partout ?!?
Il a moins d'interet car la RATP a mis l'accès à toutes les zones dès que tu achètes la zone 1 mais elles existent encore: https://www.ratp.fr/titres-et-tarifs/forfait-navigo-mois#2-attached-to-anchor
C'est déjà le cas avec le lien "annuaire entreprise", cette PR supprime ce lien.
Je l'ai remis...
C'est pour ça que je n'ai rien enlevé. Pour moi, tout afficher ne veut pas forcement dire ne rien hierarchiser.
Je pense que tu sur-estimes la proportion de gens qui vont ouvrir le <details "informations complémentaires" que tu proposes ici. Tout ce qui y sera mis reviendra à être caché pour 90 % des usages, avec beaucoup de faux négatifs (l'utilisateur n'a pas vu l'info, mais elle lui aurait été utile, mais il ne pourra pas le dire car il aura pensé qu'elle n'existe pas). C'est pour ça que j'insiste ici, désolé !
Le tag check_date:shelter dans ton screenshot est l'exemple typique d'une donnée uniquement utile pour un contributeur OSM
Exemple intéressant : étant donné qu'il y a un tag "abri" et qu'il est très utile, le check_date doit être rangé près du tag abri. Ça peut être avec un petit icône discret date qui affiche la date, ou plus simplement avec un texte <small>vérifié il y a 4 ans</small>
Ce n'est pas une information de premier plan, mais je ne pense pas qu'il faille la reléguer dans une section qui ne sera presque jamais ouverte.
Autre exemple : "addr:floor". J'imagine que tu l'as mis dans les informations secondaires car il existe "level" qui est la plupart du temps équivalent.
Mais d'une, d'après la doc osm "addr:floor" "semble prendre le pas sur l'attribut level", donc il serait dommage de l'invisibiliser. Et de deux, il existe déjà des noeuds qui n'ont pas le level mais ont le floor.
Bon c'est pas énorme, mais c'est dommage de l'invisibiliser.
Par exemple des toilettes au -1 ici : node 12486170681
Mieux vaudrait utiliser addr:floor dans notre buildAddress.ts / Address.tsx pour l'enrichir avec cette info hyper utile. Ainsi, le tag n'apparait plus de façon générique, mais directement dans l'adresse en en-tête du lieu :)
De même, tous les liens vers les BDD françaises me semble super intéressants. CF cette discussion sur le forum où j'ai traduit des tags, et où il faudrait intrepréter l'id des établissements français pour faire un lien vers les pages officielles de l'annuaire, par exemple https://data.education.gouv.fr/pages/fiche-etablissement/?code_etab=0571359T
Je vous rassure à nouveau, je suis aussi d'avis que des fiches lieu plus propres aideront beaucoup à parler au grand public, mais je veux invisibiliser le moins possible les données ajoutées par les contributeurs OSM, c'est important pour moi.
J'ai résucité cette PR car elle apportait quand même pas mal de plus value. J'ai retravaillé pour que l'amélioration des tags se fasse sur les tags principaux et les secondaires. Ce qui m'a permis de retirer la partie qui ne faisait pas consensus: plus aucun tag n'est déplacé dans la partie "Informations complémentaires" sauf les "metadata" purement spécifiques à OSM (ie. note, source, check).
Nouveau screenshots:
Cool, merci ! On pourra continuer à améliorer les tags les plus fréquents par la suite.
Juste une petite remarque sur les coordonnées : je pense qu'il faut pas les mettre au même niveau que les autres attributs. C'est rare à mon avis d'avoir besoin de les lires ou les copier. On pourrait les mettre soit dans le bouton "partager" (bof, je trouve que ça éloigne le fait de choper l'URL, l'usage principal) ou dans un nouveau bouton avec une icône "coordonnées" qui ouvrirait alors lat,lon et pluscode. Mais c'est pas urgent, pas besoin de le faire dans cette PR :)
Je suis d'avis de mettre en ligne, car au-delà des améliorations visibles tu as amélioré le code.
@laem je n'ai pas compris pourquoi cette PR est marquée "closed". Tu as intégré les modifs par ailleurs ?
@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1312#issuecomment-9752825:
@laem je n'ai pas compris pourquoi cette PR est marquée "closed". Tu as intégré les modifs par ailleurs ?
oui.
Je viens d'activer l'option de détection automatique de merge. C'était pas activé par défaut.