[OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

Éric Gillet e+talkfr2314 at linuxw.info
Lun 28 Sep 09:38:09 UTC 2020


Le 28/09/2020 à 11:02, Axel Listes a écrit :
> Bonjour,
>
> Le 28/09/2020 à 09:40, Éric Gillet a écrit :
>>>> Donc, dans le schéma d'origine que je découvre, il faudrait trois
>>> relations.
>>>
>>> Mais les éditeurs facilitent la création de telles relations.
>> Exactement ça me semble être une question d'éditeurs plus qu'une
>> question de tags/objets OSM.
> Alors voici globalement les « défauts » qui en découlent :
> - Les multiples césures des chemins, il faut les couper à l'emplacement
> du point « via » de la relation.

Dans la plupart des cas l'intersection sera composée de 2 voies de la 
manière suivante : -|-, donc ça fait 2 coupures au maximum. J'ai 
l'impression que les intersections plus complexes avec + de voies (donc 
plus dangereuses) n'ont pas de cédez-le-passage tout-droit ou à gauche.

> - La maintenance, comme toutes relations, celles-ci sont susceptibles
> d’être cassées lorsque qu'un contributeur débutant ou non vigilant
> intervient sur l'un des éléments intégrés dans la relation.

Oui en effet, mais ça malheureusement il n'y a pas de solution. Même 
avec une myriade d'avertissement des contributeurs arrivent 
régulièrement à fusionner des nœuds de routes 1km plus loin sur iD. 
Pourtant ce sont des opérations simple (fusion de nœuds) sur des 
"données simples" (nœuds, pas de relation), donc je ne suis pas sûr que 
ce soit un problème de complexité du modèle de données.

Si l'éditeur a une vue dédiée aux cédez-le-passage, il serait sûrement  
facile de mettre cette vue lors d'erreurs de validation pour faire 
corriger le contributeur.

> Les systèmes
> de suivi d’éditions ont plus de difficultés à donner des informations
> concernant des éditions de relations que de points (Achavi, OSMcha ...)
Oui en effet. Je pense que c'est l’œuf et la poule, il y a beaucoup plus 
de modifications (et donc d'erreurs à surveiller) sur les nœuds et 
voies, donc plus d'attention est portée à leur rendu.
> - La complexité de l'usage des relations, honnêtement pourquoi
> obligatoirement passer par un système hyper complexe alors que l'on peut
> juste ajouter une balise sur un point pour arriver au même résultat ?
> L'exemple d'Éric est intéressant, car il permet de se poser cette
> question : Une balise sur un point déjà existant ou trois relations ?

C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire 
"hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est 
forcément cartographiable facilement. Par exemple on pourrait dire qu'il 
serait plus simple de cartographier les arbres de la manière suivante :

natural=tree
espece=platane

Au lieu de :

natural=tree
genus=Platanus
species=Platanus × hispanica
deciduous=leaf_cycle
leaf_type=broadleaved

Mais ça me semble pas pertinent pour une base de données.

Pour revenir sur les panneaux, il faut se demander ce que l'on veut 
cartographier : le panneau (ce que tu suggères si j'ai bien compris) ou 
son effet.

Panneau :

  * Plus simple à cartographier
  * Ne représente que le panneau, et nécessite donc une interprétation
    pour savoir quelle voie sont concernées. Cette interprétation est
    potentiellement différente par pays/état.

Relations:

  * Plus complexe à cartographier
  * Pas d'ambiguïté pour les utilisateurs

Certains pourraient suggérer une approche hybride (panneau quand pas 
d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire 
implémenter logiciellement (et faire comprendre aux contributeurs) les 
deux manières de cartographier, ce qui me semble empirer le problème.

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200928/a0b6f8f4/attachment-0001.htm>


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