Ca c'est jsute le point de vue théorique. Rien à voir avec le pragmatisme qui consiste à s'adapter à ce qu'on peut et sait faire en attendant de développer mieux.
Ton problème de comptage est un point de vue théorique uniquement qui oublie de prendre en compte le fait que tu peux parfaitement (et facilement en plus!) identifier les doublons. C'est une réponse de celui qui a juste pas envie, pas le courage de le faire. Pourtant c'est facile à documenter, et utile dans un *long* processus de transition où on n'aura jamais tout en même temps et tout de suite: c'est illusoire de croire qu'OSM sera complet, sinon c'est que le monde entier est mort (et n'a donc plus besoin d'OSM et n'a plus non plus aucun contributeur)! On en reparlera quand le monde ne sera plus peuplé que de robots et que l'espèce humaine aura disparu. Personne ne le souhaite ici et en fait on ne le verra jamais sur OSM, OSM sera mort bien avant ça. Être pragmatique c'est juste savoir minimiser l'impact en terme de conséquences, et ici les conséquences sont théoriques (pour un esprit trop borné à ne pas vouloir voir le reste et qui voudrait se comporter comme un robot). Mais un humain n'est pas induit en erreur, et on peut parfaitement apprendre à un robot à se comporter correctement, il faut juste lui dire et le faire travailler un peu plus, à peine plus en fait car c'est facile à trouver dans la base). Le ven. 4 sept. 2020 à 18:20, Vincent de Château-Thierry <osm.v...@free.fr> a écrit : > > > De: "Philippe Verdy" <ver...@gmail.com> > > > Ben non justement, ce n'est pas "taguer" pour le rendu car les deux > > méthodes sont indiquées comme valides et approuvées. Certes il y a > > des bogues dans le rendu puisque suivant les cas c'est l'une ou > > l'autre méthode qui est visible; mais si on voit les deux c'est > > moins grave que ne rien voir du tout. > > Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles > sont mutuellement exclusives : si on en choisit une pour un objet du > terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours > le "one feature, one element". > > > Et même hors du rendu (par exemple pour les recherches) cela n'a pas > > de conséquence: on trouve deux objets pratiquement au même endroit. > > Il y a au moins une conséquence : 2 objets pour la même réalité terrain, > ça fausse les statistiques. Avec un polygone "parking" incluant un point > "parking" la réponse à la simple question "combien y a t-il de parkings > dans la commune ?" devient compliquée, alors qu'elle devrait être > simplement la somme des noeuds "parking" et des polygones "parking" si on > respecte le principe du "one feature, one element". > > vincent > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
