<div dir="ltr"><div dir="ltr">Le mar. 8 sept. 2020 à 09:24, Christian Quest <<a href="mailto:cquest@openstreetmap.fr">cquest@openstreetmap.fr</a>> a écrit :<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 07/09/2020 à 10:53, <a href="mailto:osm.sanspourriel@spamgourmet.com" target="_blank">osm.sanspourriel@spamgourmet.com</a> a écrit :<br>
> Salut,<br>
><br>
> Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -<br>
> <a href="mailto:talk-fr@openstreetmap.org" target="_blank">talk-fr@openstreetmap.org</a> a écrit :<br>
>> Aucune raison de faire les 2.<br>
><br>
> Si, certains systèmes ne traitent qu'un et donc les utilisateurs<br>
> débutants ajoutent l'autre.<br>
><br>
La plus mauvaise raison selon moi.<br>
<br>
Le wiki est clair, pas de double objet, un POI est prioritairement <br>
surfacique sauf si le wiki indique pour le tag en question qu'il n'est <br>
que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux <br>
d'évoluer.<br></blockquote><div><br></div><div>Donc tu te fais une remarque à toi-même concernant le rendu carto français (celui par défaut sur <a href="http://openstreetmap.fr">openstreetmap.fr</a>).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Quand on met les 2, ça pénalise les outils qui suivent les règles à des <br>
traitements supplémentaires de dédoublonnage... merci !<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais<br>
> là j'ai indiqué un contournement possible).<br>
<br>
Quel problème sur les place=* et le rendu FR ? Il manque la prise en <br>
compte des polygones ?<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Et il y a des tas de raisons pour lesquelles même ces "doublons" sont involontaires, notamment:</div><div>- des tas de noeuds non trouvés à la position attendue pour une recherche, qui font qu'ils sont réajoutés</div><div>- 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).</div><div>- 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".</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div>