[OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Le mar. 8 sept. 2020 à 09:24, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> Le 07/09/2020 à 10:53, osm.sanspourriel at spamgourmet.com a écrit :
> > Salut,
> >
> > Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
> > talk-fr at openstreetmap.org a écrit :
> >> Aucune raison de faire les 2.
> >
> > Si, certains systèmes ne traitent qu'un et donc les utilisateurs
> > débutants ajoutent l'autre.
> >
> La plus mauvaise raison selon moi.
>
> Le wiki est clair, pas de double objet, un POI est prioritairement
> surfacique sauf si le wiki indique pour le tag en question qu'il n'est
> que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux
> d'évoluer.
>

Donc tu te fais une remarque à toi-même concernant le rendu carto français
(celui par défaut sur openstreetmap.fr).


> Quand on met les 2, ça pénalise les outils qui suivent les règles à des
> traitements supplémentaires de dédoublonnage... merci !
>

La "pénalisation" est déjà en place et minime (et même possible puisque
Osmose sait le détecter et je ne pense pas que ça lui demande tant de
travail que ça.


> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> > là j'ai indiqué un contournement possible).
>
> Quel problème sur les place=* et le rendu FR ?  Il manque la prise en
> compte des polygones ?
>

Justement c'est bien ça, cette "règle" n'est  pas appliquée; pour s'éviter
d'avoir à gérer des doublons, il ne charge qu'une partie des données
valides et oublient les autres.
Si l'outil DOIT charger à la fois les points et les polygones pour les
mêmes tags, forcément il va devoir détecter et gérer les pseudo-"doublons"
proprement. C'est un phase de validation au même titre que le travail de
préparation et d'intégration dans les contributions d'OSM.

Et il y a des tas de raisons pour lesquelles même ces "doublons" sont
involontaires, notamment:
- des tas de noeuds non trouvés à la position attendue pour une recherche,
qui font qu'ils sont réajoutés
- le cas du serveur de données OSM qui ne charge pas tout (exemple très
régulièrment avec iD il manque des données ou on se retrouve avec une carte
totalement vide, le serveur a tronqué les données retournées (sans produire
aucune erreur, les erreurs qu'on voit dans la console sont essentiellement
celles de chargement des tuiles du fond de carte, des erreurs "mixed
content" sur certains fonds de carte (notamment les tuiles OrthoBD); l'API
de chargement de données n'est pas si stable que ça et les navigateurs ont
également renforcé récemment leur sécurité pour bloquer toute sorte de
choses silencieusement (et accélérer le reste du rendu sans épuiser les
ressources du poste client).
- la plupart des erreurs ne produisent aucun message dans le journal de la
console, des gestionnaires d'exception internes à l'appli les capture pour
ne pas planter l'appli, mais oublient de signaler ne serait-ce que sur la
console (que seuls les utilisateurs avancés vont consulter car la plupart
ne comprennent rien à ce qui y est affiché s'ils ne sont pas "développeurs
web".

Je parlais d'ID mais on a le même problème aussi dans JOSM (où là aussi
tout n'est pas chargé, et c'est même pas un bogue mais "par design"
pusique c'est conçu pour que ce soit l'utilisateur qui demande lui-même les
données) du fait ds limites du serveur OSM.org (divers "quotas"
d'utilisation appliqués silencieusement).

Tout n'est pas parfait, et je ne vois pas comment un rendu conforme peut
valablement se passer de charger les deux types d'objets et éviter une
phase de validation/dédoublonnage pour avoir un rendu correct (et s'il fait
un rendu incorrect, forcément les utilisateurs qui ne voient rien seront
tentés de rajouter à nouveau ce qui parait manquer).

Si le rendu ne fait les choses qu'à moitié, on reporte les problèmes et là
encore c'est fait silencieusement. Et pas la peine de renvoyer alors les
utilisateurs à une "faute" de leur part alors que ce qu'ils font est
parfaitement conforme à ce qui est documenté et ce qu'ils voient (dans les
limites qui lui sont imposées par les outils utilisés). Les "politiques"
d'OSM sont avant tout et en premier lieu à faire appliquer aux outils avant
d'incriminer les utilisateurs qui font du mieux qu'ils peuvent pour la
plupart.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200908/1f5b4c52/attachment.htm>