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

Philippe Verdy verdyp at gmail.com
Ven 4 Sep 15:39:49 UTC 2020


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 <verdyp at 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.vdct at free.fr>
> a écrit :
>
>> Bonjour,
>>
>> > De: "Philippe Verdy" <verdyp at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200904/bae8f375/attachment-0001.htm>


Plus d'informations sur la liste de diffusion Talk-fr