@althio mais on s'en fou complet du contexte réglementaire pour le routing en encore plus sur OSM et ça se voit encore mieux sur les voies verte et sur les "route pour automobile". D'où les conflit d’édition systématique... C'est bien pour ça que cette notion n'est pas à spécifier comme tel. De plus pour les panneaux il y a ce qu'il faut pour les ajouter.
Je sais pas si vous vous rendez compte que vous verrouillez un système à cause d'outil qui ne prend pas en compte actuellement une clé ou parce que vous voulez voir un rendu particulier pour des notions administratives. Pour moi c'est éléments sont en surcouche de visibilité si l'on veut les exploiter et donc sur d'autres clés. La mention voie verte route pour automobile et zone de rencontre ont des contextes règlementaires particuliers. Pourtant on n'a pas de highway=greenway pour les voies vertes et les routes pour automobiles sont mélangé avec des voies rapide intercommunales et des nationales à deux voies... Pour moi le contexte réglementaire on l'a aussi bien en mettant highway=living_street ou living_street=yes. Sauf que actuellement le premier cas casse le routing en mode itinéraire équilibré. Le deuxième évite de dégrader le schéma de base! D'où la double proposition. J'ai pas demandé à supprimer le système établi mais à compléter un cas mal pris en compte. secondary=yes. Ouai on va où là... Le contexte réglementaire... Aucune clé ne mentionne ça! Le modèle est là pour dire qui peut accéder à la voies et avec quels moyens et dans quelles conditions. Les conditions d'accès oui. Les priorité de l'un sur l'autre non. Coté réglementaire il y en à bien plus... Encore une fois (et on en a parlé plusieurs fois) si l'on veut inscrire cette notion réglementaire il faut le faire d'une autre manière. source:maxspeed le permet aussi et zone:maxspeed également pour les zone 30 sauf que comme c'est si bien mentionné dans les précédente discussion le contexte réglementaire ne porte pas que sur la vitesse. En fait le contexte réglementaire permet de définir des notions exploitable en routing en y définissant des valeurs implicites qui sont complétées ou corrigées par des panneaux supplémentaires. (qui dans certains cas sont mis à la suite d’arrêté et de décret d'application) On mentionne pas les décrets dans OSM (lol) mais on peut mettre ça dans description ;-) Si on parle de contexte réglementaire les zones urbaines à 50 km/h c'est aussi du réglementaire et on n'a pas créé un tag pour cela pour autant sur les tronçons de voie. Bref cette notion, si elle gène le schéma, (histoire de pas frustré les gens) doit pouvoir être mentionné autrement PS: coté réglementaire on à aussi des spécificités sur les chemins de halage, chemin communaux, chemin ruraux , chemin de servitudes, j'en passe car le sujet n'est pas traité pour le moment. Plus toutes les particularités pouvant être prises par arrêté et décret... Je vais encore sortir sur sujet mais on à également le libre choix laissé au département de choisir la vitesse de circulation sur route rural. ( Va t'on avoir un nouveau panneau à l'entrée des départements pour indiquer le choix de vitesse? On va donc devoir trouver des clés spécifiques pour mentionner aussi ces éléments... Le mer. 24 juil. 2019 à 19:31, althio <althio.fo...@gmail.com> a écrit : > 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 > -- Cordialement, Jérôme Seigneuret
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
