Note : ce message est beaucoup trop loooooong et en plus, y'a plein de nouvelles réponses, c'est difficile de suivre et répondre au fur et à mesure. En espérant contribuer à la discussion.
Jérôme : > Ca reste la réalité et dans tous les cas. Les informations de vitesse sont > mentionné et la provenance de cette info aussi. > Vous avez oublié que la clé living_street est un simple raccourci pour avoir > des valeurs implicites D'abord, il y a des dispositions spécifiques, qui font qu'une zone de rencontre, c'est plus qu'une simple limitation à 20 km/h. On ne va pas forcément se contenter de maxspeed=20, et d'un attribut à peine documenté, pour représenter une zone de rencontre. Ainsi il manque des informations. D'ailleurs, quelles sont ces valeurs implicites ? Sur https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dliving_street je trouve une proposition de valeurs implicites. Vous remarquerez que le statut par défaut d'une zone de rencontre, ça peut être interprété comme une voie/aire piétonne, avec des ajouts pour les véhicules. highway=pedestrian bicycle=yes motorcycle=permissive motorcar=permissive maxspeed=* psv=yes (ceci est un exemple d'interprétation, puisque l'interprétation change en fonction des pays). Ou bien, admettons qu'à l'inverse, ça pourrait être interprété comme une voie de circulation générale, avec des ajouts pour les piétons. (Je trouve que c'est dévoyé, et illogique, mais admettons, étudions le cas). Ce n'est pas facile d'indiquer la priorité entre les modes de déplacement. J'aimerai bien voir la liste des attributs pour y arriver, à votre avis. highway=residential/tertiary/secondary/primary foot=yes/designated ? bicycle=yes/designated ? motorcycle=permissive/destination ? selon les cas motorcar=permissive/destination ? selon les cas maxspeed=* psv=yes > [Vous avez oublié que la clé living_street n'est] pas un modèle > juridico-administratif! Je ne comprends pas trop ce commentaire, alors peut-être que ma réponse est à côté de la plaque, mais j'essaie quand même. En France, highway=living_street, tel que défini et utilisé dans OSM, c'est "zone de rencontre". Et "Zone de rencontre", c'est défini et utilisé dans le Code de la route (= modèle juridico-administratif ?) Code de la route, Partie réglementaire, Livre Ier : Dispositions générales, Titre Ier : Définitions. Article R110-2 https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000023095873&cidTexte=LEGITEXT000006074228&dateTexte=20101117 C'est donc de l'ordre du réglementaire. Et si le Code de la route change la définition de "Zone de rencontre", mais que les panneaux restent : on change les valeurs par défaut, l'interprétation, en France, de highway=living_street. > Vous préférez casser le modèle routier pour des histoires de réalité physique. Heu mollo, quand même. On ne casse rien du tout, tout est connecté, décrit, utilisable par les moteurs de rendu et les moteurs de routage. Les moteurs de routage sont un peu mieux renseignés si la zone de rencontre est proprement décrite. Le calcul de routage dira peut-être que le meilleur itinéraire reste le passage par la voie primary/secondary/tertiary, même brièvement interrompue par une zone de rencontre. Ou bien le calcul donnera un itinéraire alternatif. > Une base de données c'est une abstraction faut pas l'oublier. Qui plus est > l'information est disponible. Je vois donc pas où est le problème. J'ai l'impression que certaines personnes pensent que maxspeed est suffisant, mais d'autres veulent décrire la situation plus précisément. Ils considèrent que l'information n'est pas disponible. Phyks a demandé : > Dans le deuxième cas, comment décrire finement l'aménagement (au-delà de la > seule maxspeed=20) ? Le code de route a défini : > Dans cette zone, les piétons sont autorisés à circuler sur la chaussée sans y > stationner et bénéficient de la priorité sur les véhicules. La vitesse des > véhicules y est limitée à 20 km/ h. Toutes les chaussées sont à double sens > pour les cyclistes, sauf dispositions différentes prises par l'autorité > investie du pouvoir de police. Les entrées et sorties de cette zone sont > annoncées par une signalisation et l'ensemble de la zone est aménagé de façon > cohérente avec la limitation de vitesse applicable. Un maxspeed=20, ça ne va pas suffire pour faire un bon routage. > On vas faire pareil sur toutes les zone 30 aussi !!! à quant le > highway=zone30 (humour noir) Cela n'est pas tout à fait comparable, il y a quand même des différences notable entre les définitions de zone 30 et zone de rencontre. Une zone 30 ne joue que sur la limitation de vitesse, pas sur la priorité et le droit des piétons de circuler sur la chaussée. Avec maxspeed=30, l'utilisation de soit source:maxspeed=sign soit source:maxspeed=FR:zone30 est plutôt cohérente : il y a peu de différences dans la réalité entre les deux cas. L'attribut source indique la présence du panneau, pas son effet, et aide la contribution, pas l'utilisation des données. Alors que pour maxspeed=20, source:maxspeed=sign et highway=living_street sont des réalités différentes. Et "source:maxspeed=FR:living_street" est un attribut source, un peu vide de sens pour l'utilisation des données. > La propositon de Marc est encore la plus cohérente. Au moins ça casse pas le > modèle et c'est exploitable! https://wiki.openstreetmap.org/wiki/Key:living_street destiné à highway=service (pour des voies spécifiques, encore plus restreintes) et https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:living_street%3Dyes Les exemples alors utilisés sont sur highway=residential, highway=unclassified et highway=service. Même si on peut envisager sur highway=tertiary (et highway=secondary... et highway=primary...), apparemment ce n'est pas l'esprit de la proposition (abandonnée) et de la documentation de l'attribut (usage : de facto). Voir aussi https://github.com/gravitystorm/openstreetmap-carto/issues/3514 Et la communauté allemande a l'air globalement contre https://forum.openstreetmap.org/viewtopic.php?id=64490 http://gis.19327.n8.nabble.com/Anderungen-highway-living-street-highway-service-living-street-yes-td5927548.html Mais bon, l'attribut living_street=yes est effectivement utilisé, parfois dans des pays où cette réglementation n'existe pas... une bonne discussion internationale sur la liste tagging arrivera peut-être un jour. Tout de même, il semble bon de noter : les usages et les discussions portent sur l'attribut living_street=yes en complément sur des voies mineures (service / residential / footway / unclassified). Les usages sont hyper-minoritaires sur des voies tertiary / secondary / primary Voir aussi https://taginfo.openstreetmap.org/tags/living_street=yes#combinations et des requêtes du type https://overpass-turbo.eu/s/L20 Dans OSM, sur le monde entier, living_street=yes est utilisé avec : 229769 highway=service 12535 highway=residential (équivalent à highway=living_street) 2065 highway=footway 1906 highway=unclassified 1677 highway=living_street (redondant) 246 highway=tertiary 25 highway=secondary 8 highway=primary En France : 2 cas avec highway=service 6 cas avec highway=residential (équivalent à highway=living_street) ~10 cas avec highway=tertiary 1 cas avec highway=secondary 2 cas avec highway=primary > Arrêtons de vouloir casser le modèle pour des conneries de "on représente le > terrain". Là on cherche pas à représenter le terrain et on casse la logique > s'itinéraire routier et le rendu qui en découle. Faux et grossier. Je veux bien discuter et entendre des arguments, mais pas là. > Ici on s'est refusé à casser les logiques de réseau. Sinon aucun intérêt de > définir des axes avec cardinalité. Si l'aménageur casse la logique de réseau dans la réalité, avec un coup de pelleteuse ou avec une zone de rencontre, il faut bien en tenir compte. Et ça ne va pas casser le routage pour autant. Et le routage et le rendu ne sont pas cassés, ils deviennent plus conforme à la réalité. > Pour une zone de rencontre: 1 panneau au début et à la fin... Pourquoi faire > compliqué quand on peut faire simple! Effectivement, avec une logique comme cela de la part des aménageurs, pas étonnant que les aménagements ne soient pas dans l'esprit d'une "zone de rencontre". Mais c'est le même tarif pour une zone 30 : 1 panneau au début et à la fin, non ? Ou alors il y avait une promotion sur les panneaux zone de rencontre ?!? Après, l'aménageur fait des aménagements délirants, à de multiples niveaux, ça arrive, malheureusement. La règle (le Code de la route) s'applique quand même. La zone de rencontre est là, sur le terrain, sur cette portion. Si elle est petite, elle est presque négligeable, à peine plus qu'un ralentisseur. Si elle est grande, elle influe fortement. On ne doit pas la cacher dans les données, dans les rendus et dans les routeurs. Et puis il y a le bon aménageur et le mauvais aménageur. Le bon aménageur, c'est une bonne volonté politique, et les bons aménagements arrivent à modifier le plan de circulation et les flux de trafic, pour un budget maîtrisé. Le mauvais aménageur, il met des panneaux, pas cher si possible. > Bref pour matérialiser certaines voies de type living_street qui en n'ont > gère la fonction, le mieux sera d'avoir une clé dédié pour éviter tous ces > débats qui mènent souvent à ne rien faire et avoir des conflits d'édition. Admettons, oui. Reprenons les propositions de Marc : > on peux se mettre d'accord > pour highway=secondary + living_street=yes > ou pour l'inverse, > cela reste un bricolage pour décrire une erreur administrative. Donc on peut aussi envisager que l'attribut principal soit highway=living_street pour la description du terrain et ensuite définir que cette portion de route appartiennent à une logique d'itinéraire routier ? Soit avec une clé dédiée (exemple au hasard, un truc du genre secondary=yes). Soit avec les relations, comme cela est fait pour les autres itinéraires (transport en commun, vélo, randonnée, ...) Et le meilleur commentaire à propos du routage, à mon avis, par Phyks : > Doit-on chercher à interpréter l'aménagement à ce point ? À mon avis, non. > C'est un aménagement de type "zone de rencontre" avec tout un cadre légal > associée et une pénalité au routage probablement justifiée pour du trafic de > transit. Si on annote différemment pour biaiser les routeurs, on tague pour > un outil, ce qui à mon avis ne fait que masquer le problème. S'il y a du > trafic de transit possible dans des rues parallèles encore moins adaptées, > c'est que le plan de circulation n'est pas correct et c'est à la puissance > publique d'agir, pas à OSM de chercher à masquer et corriger ces erreurs. +1 (ou à OSM de détailler le plan de circulation dans les rues parallèles, si besoin) -- althio _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
