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.
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
