Et noter que le "POI" ne désignent pas la cartographie physique, ils sont juste des points au centre d'une aire (de taille non spécifiée) qui n'est pas délimitée nécessairement par un objet physique (un seul batiment, plusieurs, des services annexes rattachés, y compris leurs boites aux lettres qui peuvent être ailleurs, et qui ne couvrent pas non plus leur aire d'influence ou de chalandise et ne dit souvent rien de leur importance relative vis à vis de leur environnement économique ou social)
Hors on ne peut pas taguer comme un POI tous les objets physiques et les découper ou regroupe ne fait souvent pas de sens non plus car on n'est pas capable de faire une réelle délimitation: c'est pour ça qu'on les réduit à un seule noeud assez souvent. Pourtant ils peuvent être bien plus grands et avoir eux-même une structure interne plus fine (exemple: une école ou une zone hospitalière avec divers services, et même pas mal de zones commerciales: l'usage des lieux n'est pas forcément unique non plus et on ne peut pas séparer géographiquement ces services qui pourtant y sont situés et se recouvrent partiellement, que ce soit territorialement ou dans le temps). On ne peut donc pas déprécier une méthode plutôt qu'une autre. Malheureusement, traiter les points et les polygones/surfaces, c'est très différent dans les rendus. Et pour créer des filtres efficaces, ce n'est pas facile car on ne les verra pas toujours simultanément dans toute sélection d'objets depuis la base (au plan purement géométrique, les points sont trop petits ils peuvent être oubliés, les surfaces sinon ne sont qu'indicatives le plus souvent et parfois trop grande relativement à l'importance d'autres objets voisins ou qui y sont inclus: on ne peut pas figer ces règles de filtrage dans les rendus, donc autant permettre cette flexibilité: c'est aux rendus qui voient les deux types d'objets de mieux gérer les filtres au cas où il voient des doublons, et ils n'en voient pas toujours puisqu'ils ne sélectionnent pas tous la même chose). Enfin les POI tagués comme simple noeud n'ont toujours indication d'une taille relative (au moins un rayon), et leur "importance" relative par rapport au reste ne peut pas non plus être décrétée par le système de tagging, sinon on aurait partout le même carte unique dans tous les rendus, les mêmes filtres appliqués à tous les niveaux de zopom, et trop de détail visibles pour tous les usages qui n'en ont pourtant pas besoin: ce qu'on ferait serit de recréer une carte "à la Google" avec ses critères imposés ou téléguidés par des choix externes (ou des politiques commerciales selon les intérêts des autres et pas du visiteur réutilisateur; OSM serait beauoup moins riche). Le ven. 4 sept. 2020 à 17:25, Philippe Verdy <ver...@gmail.com> a écrit : > 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. > > 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. > > C'est similaire à d'autres objets où on tague les deux (y compris les > "labels" qui ont été utilisés et sont encore approuvés dans les relations > boundary même si on n'en a plus besoin pour les rendus les plus courants ni > pour les recherches pour les outils classiques comme Nominatim. Ce qui doit > être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où > ils trouvent les deux objets (de type différents) au même endroit et la > façon dont ils gèrent les priorités d'affichage (car de toute façon ils > font toujours des choix, ils ont tous des filtres et ce sont ces filtres > qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore > besoin puisqu'ils ne "voient" qu'une partie des objets). > > Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon > de **détourner** des tags prévus pour désigner tout autre chose a fin de > forcer un affichage. Ce n'est pas du tout le cas ici: les deux > méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une > pour l'autre. > > > Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry <osm.v...@free.fr> > a écrit : > >> Bonjour, >> >> > De: "Philippe Verdy" <ver...@gmail.com> >> >> > Ce rappel était inutile. Ce sont deux objets de nature différente >> > même s'ils ont le même nom mais pas la même fonction. Et ce >> > "doublon" n'est pas gênant: si on crée une surface délimitée par un >> > polygone, ce n'est pas un noeud de plus qui change la donne en terme >> > de volumétrie et il n'y a pas d'ambiguité réelle. >> >> Dans ton précédent mail tu dis : "un point parking trouvé dans une >> surface parking" donc on parle bien de 2 objets décrivant la même réalité >> sur le terrain. Leur nature géométrique est différente mais ce sont bien >> des doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué >> par Christian. >> >> > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des >> > limites et qu'elles ne vont pas se régler tout de suite. Je préfère >> > nettement avoir deux objets (de nature différents mais positionnés >> > presque au même endroit, cela n'induit personne en erreur) que de >> > n'en voir aucun de façon aléatoire ou ne pas le trouver si on >> > cherche avec les outils qu'on a actuellement (en attendant qu'ils >> > soient corrigés). >> >> Le fait de "voir ou pas" les objets est de la responsabilité du logiciel >> qui les affiche, ça n'est pas au contenu lui-même de palier les limites des >> chartes graphiques. Sinon ça revient à tagguer pour le rendu. >> >> 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