Re: [OSM-talk-fr] Bretelles d'autoroutes
Le dim. 6 nov. 2022 à 16:17, Eric SIBERT a écrit : > > En marge de la discussion sur la vitesse des voies de sortie, je me pose > des questions sur la modélisation fine des bretelles d'entrée/sortie et > des échangeurs d'autoroutes et autres voies express. À l'heure du GNSS > centimétrique, on peut savoir dans quelle voie on circule... si on sait > où est la voie. > > On a des premiers éléments ici: https://wiki.openstreetmap.org/wiki/FR:Lanes#Autoroute > > Sinon en anglais, qui illustre en plus change:lanes=* pour exprimer les restrictions imposées par les lignes blanches continues: https://wiki.openstreetmap.org/wiki/Lanes#Motorway_with_lanes_and_destinations > Mais ça ne parle pas de où on met le(s) way(s). Il existe déjà la règle générale qui dit de ne dessiner 2 routes qu'en cas de séparation physique. Reste effectivement la question de centrage du segment dans la partie voie voie de présélection. En général on continue de centrer par rapport aux voies principales, c'est plus simple. Et un moteur de rendu qui voudrait être précis pourrait deviner que la voie de présélection se greffe à droite. > J'avais tendance à > mettre la voie de sortie dès le début de l'apparition de la voie de > sortie mais j'accepte le modèle où on ne fait apparaître la nouvelle > voie que quand commence la ligne continue comme ça: > > > https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg > > Faire apparaître une nouvelle route quand commence la ligne continue viole aussi la règle de ne tracer 2 routes qu'en cas de séparation physique. Je n'interprète cependant pas https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg ainsi. Je dirais plutôt qu'une tangente à la fin de la courbe de la bretelle a été tracée. On peut aussi penser que ceux qui ont tracé la ligne blanche sur le terrain se sont aussi basés sur cette tangente. Je ne vois pas de raison de faire des sorties d'autoroute un cas spécial. On est dans un cas d'intersection avec une voie de présélection comme il existe un peu partout: sur autoroute, sur nationale, en ville. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bretelles d'autoroutes
Le lun. 7 nov. 2022 à 12:34, Georges Dutreix via Talk-fr < talk-fr@openstreetmap.org> a écrit : > > Je suis personnellement pour une représentation la plus simple possible > (KISS). Les clés lanes et turn:lanes auxquelles on peut éventuellement > ajouter width:lanes me semblent permettre une représentation extrêmement > fine de la géométrie des voies. Cela suppose de tracer le highway au > milieu de la chaussée principale (bande de roulement sans les voies de > sortie/entrée, d'arrêt d'urgence ou autres), Pareil. > et de faire démarrer les > sorties/entrées à l'extrémité de la ligne continue. > Ça dépend. Parfois la ligne continue s'étend sur bien plus de cent mètres. La carte montre alors deux chaussées alors qu'il n'y en a qu'une, et elle introduit une erreur de plus de cents mètres quant à la position de la séparation des chaussées sur le terrain. Ça commence à faire beaucoup (trop pour moi qui tique dès qu'il y a plus de quelques décamètres d'imprécision). > Le seul cas à l'heure actuelle, où je n'ai pas de solution élégante, est > l'arrivée sur un péage d'autoroute, où on passe graduellement à 12 ou 15 > voies... sachant en plus que sur certains péages, cela change entre les > départs en vacances et les retours :-) > > Ah oui, les péages, je n'ai jamais su comment faire. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bretelles d'autoroutes
Le dim. 6 nov. 2022 à 16:17, Eric SIBERT a écrit : > On a des premiers éléments ici: > > https://wiki.openstreetmap.org/wiki/FR:Lanes#Autoroute > > (Et aussi, dans les voies d'autoroute proposées plus haut, on a la zone > 5 avec ligne continue au milieu mais un seul way.) > > Je ne connaissais pas cet exemple. J'ai un doute quant aux tags destination qui ne figurent pas dans les segments 2 et 5. Les destinations restent-elles implicitement tant qu'il y a le même nombre de lanes? Ou bien est-ce une indication qui n'est que ponctuellement utile? Le manque de tag turn:lanes dans le segment 5 ne pourrait-il laisser faussement penser que tout le monde peut à nouveau aller où il veut, et donc passer la double ligne blanche continue? Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)
Le dim. 6 nov. 2022 à 14:33, a écrit : > > Avant : inutile, c'est le milieu de la bande de roulement.Marc : tu > parles du milieu de chaussée, en fait c'est de la bande de roulement - > il doit y avoir un terme plus exact -, on ne tient pas compte des bandes > d'arrêt d'urgence shoulder=right). > > > Oui c'est très juste, pour les autoroutes et 2x2 voies avec bande d'arrêt d'urgence, j'ai toujours vu le filaire placé au milieu de la bande de roulement, et pas au milieu de la chaussée. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)
Le jeu. 3 nov. 2022 à 22:58, a écrit : > Le 03/11/2022 à 21:34, Marc Mongenet - marc.monge...@gmail.com a écrit : > > > Enfin, je suppose qu'avec la généralisation des tags lanes et turn:lanes > > (et peut-être placement dans le futur) cela va être progressivement > > corrigé, et les lignes blanches ne seront plus utilisées comme > > pseudo-séparations de voies. > Les lignes blanches sont des vraies séparations de voies. Mais on est > plus d'accord que ce que ne semble indiquer cette phrase. > Oui je me suis mal exprimé. Ce que je voulais dire, c'est que dans OSM, on trace deux routes parallèles quand il y a deux chaussées avec une séparation en dur (un muret, de l'herbe ou une glissière), ce que n'est pas une ligne peinte. > > - tu donnes une règle (les lignes représentant le centre des routes) > sauf que tu donnes l'image du haut et non celle du bas qui précise "If > one tries to draw the OSM-way as often as possible in the middle of the > road". > > Oui en fait c'était l'application correcte de la règle d'angle d'intersection qui m'intéressait dans https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg (aussi bien que dans https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_2.jpeg ). Concrêtement, je mapperais la sortie 21 ainsi: https://wiki.openstreetmap.org/wiki/File:Sortie-francilienne-21.png > Est-ce que la sortie 21 devrait être à la hauteur de la séparation de la > voie avec "placement=transition" en amont sur la partie entre 2 et 3 > voies ? > > Où est le "milieu de la voie" : pour la voie qui continue et a deux > voies c'est le trait pointillé centre de ces deux voies. > > J'ai toujours hésité avec les milieux de chaussée concernant les autoroutes. Je fais un peu comme tout le monde en suivant généralement la ligne centrale, ce qui déroge effectivement à la stricte règle du milieu de chaussée. Je fais notamment cela car la bande d'arrêt d'urgence peut être de largeur irrégulière, et suivre systématiquement le milieu de la chaussée introduirait des petits virages assez peu compréhensibles. > Donc pourquoi pas mais il faudrait un exemple clair : > > - ou place-t-on le motorway_junction (sortie) : où la voie commence à se > diviser ? Quand elle se divise ? ÀMHA quand elle commence. Ainsi dans ce > cas précis la voie principale reste à deux voies. > Je ne me souviens pas avoir placé de motorway_junction alors je ne me suis jamais posé la question. Dans https://wiki.openstreetmap.org/wiki/Tag:highway=motorway_junction je lis: This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn. > Avoir un simple trait quasi parallèle pour aller de l'endroit où il y a > 2 voies à l'endroit ou il y en a 2 + 1 serait graphiquement très proche > et placement=transition et serait suffisant. > > D'autres avis plus éclairés ? > > Pour ma part je trace les traits comme dans https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg plutôt que https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_2.jpeg car: - c'est plus simple - l'autoroute ne tourne pas - je trouve que le turn:lanes=none|none|slight_right est suffisamment explicite Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie
Le jeu. 3 nov. 2022 à 23:42, Marc_marc a écrit : > Bonsoir, > > Le 03.11.22 à 19:09, didier a écrit : > > Cf www.mapillary.com/app/?pKey=172038741799101 > > > > 110 tout droit et 90 pour ceux qui vont emprunter la sortie. > > je ne lis pas "90 pour ceux qui *vont* emprunter > la sortie". mais "90 quand tu *es* sur la bande de sortie". > > Cordialement, > Marc > > > C'est aussi ce que je comprends de https://www.equipementsdelaroute.developpement-durable.gouv.fr/IMG/pdf/iisr_1epartie_vc_20210409_cle2b4269.pdf Dans le cas où on impose une limitation de vitesse sur une voie de décélération, on peut exceptionnellement signaler cette prescription par un panneau B14 complété par un panonceau directionnel M3a placé sur accotement conformément aux indications données par l'article 9-1, paragraphe B.3.a. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie
Le jeu. 3 nov. 2022 à 20:21, a écrit : > > La vitesse de la voie > https://www.openstreetmap.org/way/623900993#map=19/48.70338/2.59662 est > J'ai une question sans rapport immédiat avec la vitesse, mais avec la façon bizarre dont la voie de sortie est mappée. Pourquoi dans les cas d'entrée/sortie, et uniquement dans ces cas à ma connaissance, voit-on souvent un virage en S être inventé à la jonction avec la voie principale? Ça crée des virages qui n'existent pas et donne l'impression erronée qu'il faut brusquement tourner à droite puis à gauche pour sortir (ou à gauche puis à droite en arrivant sur la route principale). L'observation de l'orthophoto donne l'impression que la ligne continue blanche entre la voie principale et l'entrée/sortie est considérée comme une séparation de voie. Et dès la fin de la ligne continue, un angle plus ou moins arbitraire (disons entre 30° et 60°) est imprimé pour rejoindre la voie principale. Je devine d'ailleurs que le mappeur ne met pas un angle de 90° car il se rend bien compte qu'il est en train de faire qqch d'inélégant. La règle de mapper le centre de la chaussée, et pas les lignes blanches, me semble pourtant aussi vieille que OSM. Il me semble aussi que la règle des jonctions de routes est très ancienne : on conserve l'angle à l'intersection pour poursuivre tout droit les lignes représentant le centre des routes. Bref, il me semble que les règles disent depuis toujours qu'il faut mapper comme dans https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg . Dans la même région, on voit d'ailleurs sur https://www.openstreetmap.org/#map=19/48.67452/2.54959 que l'intersection entre la rue de Quincy et l'avenue de Jarcy est mappée selon les règles. Enfin, je suppose qu'avec la généralisation des tags lanes et turn:lanes (et peut-être placement dans le futur) cela va être progressivement corrigé, et les lignes blanches ne seront plus utilisées comme pseudo-séparations de voies. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6
Le mer. 12 oct. 2022 à 23:09, Rene Chalon a écrit : > Re-bonsoir, > > On 12/10/2022 22:52, osm.sanspourr...@spamgourmet.com wrote: > > > > Et ici pour éviter que Lyon et ARA ne soient affichés au même endroit. > > > > Sans doute faut-il décaler plus le texte vers le sud-ouest (autant > > laisser les locaux juger où le placer). > > Il y a longtemps que j'ai déplacé le label d'AURA plus au sud vers > Annonay mais visiblement l'algo de rendu n'est tient pas compte : > https://www.openstreetmap.org/relation/3792877#map=7/45.302/5.982 > > CyclOSM et le rendu humanitaire semblent en revanche en tenir compte. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6
Bonjour Le mer. 12 oct. 2022 à 23:21, Marc_marc a écrit : > > > marquer le nœud de Villeurbanne comme "place=town" et on aurait plus de > conflits. > > je suis peut-être le cartographe zelé dont tu parles :) dont > le changement de tag pour le rendu n'enchante guerre ! > Je trouve extrêmement cavalier d'écrire "tag pour le rendu" tout en omettant l'argumentaire qui montrait qu'il ne s'agit pas de cela: "Use the place=city tag to identify the largest settlement or settlements within a territory, including national, state and provincial capitals, and other major conurbations." Il serait donc logique d'avoir uniquement "Lyon" comme "place=city". Je pense aussi depuis longtemps qu'il serait logique que seul Lyon soit "city". Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Villeurbanne au niveau de zoom 6
Bonjour, J'ai remarqué que le rendu par défaut de https://www.openstreetmap.org au niveau de zoom 6 affichait "Villeurbanne" au lieu de "Lyon". Je suppose que c'est dû au fait que la place de "Lyon" est prise par "Auvergne-Rhône-Alpes". Est-il possible de déplacer le texte "Auvergne-Rhône-Alpes"? J'ai l'impression que c'est positionné par un label. Pourquoi ne pas simplement supprimer le label? Toujours à propos de "Villeurbanne", le rendu CyclOSM place "Villeurbanne" un vingtaine de kilomètres au sud de "Lyon" en zoom 8. Mais je suppose qu'il s'agit là d'un bug dans l'algorithme de placement, n'est-ce pas? Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Bonjour Le jeu. 8 sept. 2022 à 17:19, Marc_marc a écrit : > Bonjour, > > Le 07.09.22 à 21:02, Marc Mongenet a écrit : > > relation type=site qui représente et fait exactement > > ce qu'il faut. > > https://wiki.openstreetmap.org/wiki/Relation:site#Rationale > pour les cas oü l'objet ne peux pas être représenté > par une géométrie ou par des multipolygone :) > ex : les noeuds d'un parc éolien > Pour mon marais ça tombe bien puisque je ne pouvais pas le représenter par une géométrie (j'ai besoin de plusieurs (natural=wetland;wetland=swamp) et (natural=wetland;wetland=reedbed), ni par un multipolygone (car pour une obscure raison les polygones d'un multipolygone ne doivent pas partager des côtés). Et puis la restriction "ne peux pas être représenté par" me paraît trop arbitraire pour être respectée sans autre motivation. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Bonjour Le mar. 6 sept. 2022 à 07:19, David Marchal via Talk-fr < talk-fr@openstreetmap.org> a écrit : > > Comme une telle forêt n’est pas nécessairement intégralement boisée ou > même intégralement exploitée, je n’ai pas trouvé mieux que découplér sa > représentation des landuse=forest/natural=wood. De plus, boundary=forest > tel qu’approuvé me semble correspondre aux besoins de Marc Mongenet. > > En fait, pour l'instant, je n'ai eu besoin de nommer qu'un marais. Et j'ai finalement utilisé une relation type=site qui représente et fait exactement ce qu'il faut. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Bonjour, Le lun. 5 sept. 2022 à 07:21, David Marchal via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Bonjour, Marc. > > C’est précisément pour ce genre de cas que j’avais conçu le tag > boundary=forest (cf > https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour > plus d’info) : tu cartographies le terrain avec landuse=forest, > natural=wetland, natural=grassland… avec autant de polygones différents > qu’il le faut pour représenter le terrain (par exemple les variations de > leaf_type), puis tu ajoutes par dessus un (multi)polygone type=boundary + > boundary=forest + name=… pour représenter le fait que l’ensemble est une > seule et unique forêt, en dépit des variations de terrain, et quand bien > même le terrain n’est pas landuse=forest ou natural=wood (clairières, zones > marécageuses, étangs…). > > Oui, cela semble correspondre exactement à ce que je cherche, au petit détail près que j'en ai d'abord besoin pour un marais (boundary=wetland ?). > Un exemple ici : https://www.openstreetmap.org/j'attendrelation/13897472 > <https://www.openstreetmap.org/relation/13897472> > > Soit dit en passant, on peut constater la mauvaise circulation des infos > dans l’écosystème OSM : ce tag a été approuvé il y a des mois, à la > troisième proposition avec la première datant de près de deux ans > maintenant, et pourtant sa simple existence n’est généralement pas connue. > Certes, l’écosystème OSM est complexe, mais il n’empêche… > Je remarque que le nom de la forêt n'apparaît pas sur la carte. S'il n'y a aucun rendu, question circulation de l'information, c'est presque comme si le tag n'existait pas. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Le dim. 4 sept. 2022 à 21:42, a écrit : > Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des > sous-parties sans nom et de même clé principale avec les deux types de > plantations ? > > Jean-Yvon > > Et bien le mixed ne fonctionne pas dans le cas de la zone humide. Et puis si la forêt n'a aucune zone mixed, mais des zones bien délimitées de needleleaved (plantation d'épicéas par exemple) et de broadleaved, ça ne fonctionne pas non plus. Et surtout, je veux qu'à la fin, quand on recherche le nom de la forêt, ça entoure toute la forêt. Et je veux aussi que le nom de la forêt apparaisse dessus, bien centré, et d'une taille proportionnelle à la forêt. Bref, je cherche une solution propre, pas une bidouille. Je pensais au multipolygone qui entoure tout, comme suggéré par pepilepi...@ovh.fr, mais alors je suppose que le nom de la forêt (du marais) sera rattaché à un multipolygone sans attribut et ne représentera rien, n'est-ce pas ? Marc Mongenet > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Mouais, le place=locality n'est pas du tout satisfaisant. Déjà, c'est un tag pour le rendu. Et en plus ça ne donne pas le bon rendu aussi bien au niveau taille que couleur des caractères. Pour ce qui est du landuse=forest vs natural=wood, comme je m'occupe énormément d'occupation des sols, j'utilise landuse pour residential, vineyard, farmland, farmyard, meadow, quarry... du coup je reste dans le landuse pour forest par habitude. Cela dit, j'utilise occasionnellement natural=wood lorsqu'il y a des arbres si serrés dans un autre landuse que ça forme un petit bois. Par exemple dans du residential. Marc Mongenet Le dim. 4 sept. 2022 à 20:19, Marc_marc a écrit : > Bonjour, > > Le 04.09.22 à 20:07, Marc Mongenet a écrit : > > Comment mapper une forêt dont certaines parties sont broadleaved et > > d'autres needleleaved? > > Tout cela en donnant un nom unique à la forêt. > > un place=locality pour le nom > des natural=wood pour les zones boisées broadleaved et needleleaved > > > Le plus logique serait un grand landuse=forest > > non landuse=forest n'a rien de logique :) > landuse c'est forestry ou loisir ou chasse ou un peu tout cela à la fois > > > même question se pose pour une zone humide natural=wetland > > avec des parties wetland=swamp et d'autres wetland=reedbed. > > des natural=wetland pour les différents sous-type > et un objet place=locality pour héberger le nom > > Cordialement, > Marc > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Bonjour Comment mapper une forêt dont certaines parties sont broadleaved et d'autres needleleaved? Tout cela en donnant un nom unique à la forêt. Le plus logique serait un grand landuse=forest name=Foo avec des parties leaftype=broadleaved et d'autres leaftype=needleleaved. Mais ça ne semble pas prévu par OSM. Un pis-aller possible avec les forêts serait leaftype=mixed. Mais la même question se pose pour une zone humide natural=wetland avec des parties wetland=swamp et d'autres wetland=reedbed. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?
Le mar. 12 juil. 2022 à 20:29, a écrit : > > Le 12/07/2022 à 19:40, Marc Mongenet - marc.monge...@gmail.com a écrit : > > Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de > > précision sur les limites de forest dans le canton de Genève. > > Tu as de la chance de vivre dans une zone ou le contraste peut être fort > en hiver, où les arbres en hiver offrent une telle transparence et > d'avoir une telle ortho. > > Si tu peux le faire proprement, je n'ai rien contre. > > Ce qui me déplait c'est de fabriquer de la fausse information au > prétexte que c'est plus rigoureux d'un point de vue topologique. > > Oui, la fausse information est un vrai problème, il y a d'ailleurs eu une discussion à ce propos tout récemment dans la mailing list suisse. > Un autre soucis c'est qu'on n'a pas une rigueur constante concernant les > landuse, on le voit souvent au niveau des residential en zone rurale où > les limites sont les parcelles ou le bâti ou quelque chose d'approximatif. > > La précision variable est un problème général. Avec une bonne ortho on arrive à une précision de 5-10 cm pour les routes, et encore, les chemins de fer. Mais dans une vallée reculée à l'ombre, on n'arrive pas toujours à voir les routes, sans parler des pistes en forêt. > > Pas vraiment car dans les cas simples (je ne parle pas d'autoroute mais > de route de campagne, de chemins), la largeur de la route définit > l'emprise. > > C'est peut-être propre à certaines régions, mais avec les fossés et talus, l'infrastructure routière est facilement 50% à 100% plus large que le goudron. Après, il y en a qui mettent un landuse=grass sur cette partie. :-) Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?
Le lun. 11 juil. 2022 à 18:50, a écrit : > Le 11/07/2022 à 16:41, Marc_marc - marc_m...@mailo.com a écrit : > > > > > PS: on le fait correctement avec les landuse=railway : le champs ne va > > pas jusqu'au milieu des rails > > > > niveau pratique : faire une bonne géométrie pour la route, dupliquer > > 2x la route et décaler les copies de la largeur de l'emprise routière, > > cela fait souvent une très bonne géométrie de départ en peu de temps > > Pas trop d’accord. Le « problème » est celui soulevé par David : la > route est modélisée en filaire et les landuse en surfacique. > > Quand on arrête le landuse=farmland là où s'arrête le champ, alors le vide autour du filaire de la route correspond simplement à ce que serait un landuse=highway s'il existait dans OSM. Je me demande d'ailleurs depuis longtemps pourquoi il n'existe pas de landuse=highway. > Tant qu’on fait ça, la représentation la plus logique est de faire aller > les landuse jusqu’à la route. Et c'est parce que du as des > landuse=railway que tu ne vas pas jusqu'au rails. > Ce n'est pas parce qu'on n'a pas de landuse=highway que l'on doit faire déborder les autres landuse. Cela dit, je vais jusqu'au fil pour les track, et très occasionnellement pour des petites routes, mais c'est hors de question pour les autoroutes. > Et si plus tard on veut faire du surfacique pour la route, alors on va > arrêter le surfacique des côtés au surfacique de la route (comme c’est > fait pour les rails). > Il ne s'agit pas de surfacique pour la route, mais pour l'infrastructure routière, qui est généralement plus large (beaucoup plus dans le cas d'un échangeur autoroutier). > Mettre une largeur (width=) à une route tout en conservant le filaire me > semble préférable : la cartographie c’est une modélisation du monde, pas > du dessin. > Oui, le width manque à la plupart des routes, c'est bien dommage, mais c'est sans rapport avec les landuse. > Je mets au défi quiconque de faire proprement du surfacique quand la > route longe une forêt : pour que ce soit propre vous allez partir du > centre de la route et dériver les limites via la largeur > (essentiellement constante) de la route, vous n’allez pas essayer > d’estimer la limite de la forêt par les troncs ou le houppier. > Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de précision sur les limites de forest dans le canton de Genève. Ça dépend des circonstance: au bord d'une route la limite de la forêt est souvent très nette, c'est moins clair au bord d'un pré. Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?
Le lun. 11 juil. 2022 à 16:13, Volker Schmidt a écrit : > Je suis dans le "métier" des voies cyclables, lesquelles souvent, en un > premier instant sont taggués sur la route avec cycleway=track. Dans une > deuxième phase on ajoute la cyclable comme way séparé et les landuse > attaqués à la route te rendent fou. > Et on peut aussi penser à ajouter des guardrails ou des murs ecc. > > > De même, j'évite de coller les landuse aux routes car ça rend la maintenance plus difficile. Le pire du pire étant les landuse en multipolygone qui réutilisent des segments de routes, d'autres landuse, etc. Je n'ai jamais réussi à les modifier significativement, et quand je dois le faire, je supprime le multipolygone et reprend tout à zéro. Je suppose que ça s'appelle mapper pour la maintenance. :-) A moins que ce soit dû à mon incompétence avec les multipolygon. Je ne sais pas. Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Flopées de highway=pedestrian qui n'en sont pas
Le lun. 27 juin 2022 à 20:57, Ralf Treinen a écrit : > Bonsoir, > > On Mon, Jun 27, 2022 at 06:54:00PM +0200, deuzeffe wrote: > > > tombe sur des flopées de highway=pedestrian qui n'en sont pas, toujours > > mappées par la même personne. > > > > Ça peut être un bout d'herbe en bordure de voie : > > https://www.openstreetmap.org/way/904660169 > > ou un grand trottoir : > https://www.openstreetmap.org/way/905604363/history > > ou https://www.openstreetmap.org/way/905538162 > > > > On est bien d'accord que le tagging n'est pas correct ? > > Plutot mettre "highway=footway" et "footway=sidewalk", plus "area=yes" > le cas du surfacique échéant. Voir > > https://wiki.openstreetmap.org/wiki/FR:Trottoirs > > "highway=pedestrian" est pour les rues qui sont principalement pour des > pietons : > > https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpedestrian > > Oui, highway=pedestrian est une rue indépendante des autres, avec un nom, et qui a souvent été une rue ouverte au trafic motorisé dans le passé. Je vois plus highway=footway pour les allées et sentiers réservés aux piétons, qui sont souvent anonymes. Et pour le cas d'une aire comme https://www.openstreetmap.org/way/905604363/history, comme elle est dépendante de la rue, j'aurais mis highway=footway area=yes. Cela dit, j'ai plus l'habitude de mapper la campagne et d'utiliser des highway=path et highway=track. Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rues en landuse residential
Bonjour Le sam. 12 sept. 2020 à 14:40, Georges Dutreix via Talk-fr a écrit : > > Je viens de tomber sur ça à La Ciotat : > https://www.openstreetmap.org/way/433148353/history#map=18/43.17743/5.60195 > une emprise de rue en landuse=residential > > Tout le quartier est comme ça, je trouve ça assez lourd, et ça me semble même > être un contresens puisque la zone "résidentielle" serait justement toute la > zone en dehors de l'emprise des rues et trottoirs. > > Qu'en pensez-vous ? > Doit-on laisser tel quel ? le signaler à l'auteur puis corriger ? Je fais beaucoup de landuse, mais je n'ai jamais fait, et jamais vu, ça. Je ne suis pas pour. Si comme le pense Philippe c'est pour nommer les landuse, alors ce n'était pas nécessaire, ni même désirable, d'exclure les rues. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] maxspeed par défaut
Bonjour > Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org a > écrit : > > +1 avec les avis précédents: en extra-urbain, l'implicite est devenu > tellement incompréhensible qu'il vaut mieux coder explicitement. > Par défaut c'est 80 km/h sur les chaussées à double sens: > - sauf sur certaines portions de départementale dans certains départements Oui, mais je suppose que la source sera alors toujours un panneau. Mais si le panneau n'est pas répété après une intersection, je suppose que ça retombe à 80. > - sauf quand il y a un une voie supplémentaire pour faire un créneau de > dépassement 90 km/h dans ce cas. > - pareil pour les routes pour automobile (panneau C107) à double-sens? De ce que j'ai compris de l'Article 5 (voir mon autre message), C107 implique le 110 km/h sauf limitation explicite. > - On peut imaginer une route à double-sens avec un terre-plein temporaire > pour un carrefour. Ce n'est pas pour autant que le long du terre-plein, > la limite va passer à 90 km/h. Effectivement, dans ce cas ça passe carrément à 110 km/h d'après R413-2 ! > Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur. > Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas > là. Je ne sais pas quelle maxspeed mettre dans certains cas. C'est pour cette raison que je pense préférable de ne pas essayer de deviner la limite explicite, mais plutôt indiquer "maxspeed=FR:rural". Le mer. 2 sept. 2020 à 10:54, a écrit : > > > - On peut imaginer une route à double-sens avec un terre-plein > > temporaire pour un carrefour. Ce n'est pas pour autant que le > > long du terre-plein, la limite va passer à 90 km/h. > > En théorie tu as raison. En pratique... Je ne sais si un gars a eu une > offre spéciale pour réutiliser les anciens panneaux ! A noter que ce cas ne correspond pas à l'exemple avec un terre-plein temporaire ; c'est le cas à plusieurs voies dans le même sens. Le panneau 90 est ici superflu, maxspeed=FR:rural + lanes:forward=2 impliquant 90 km/h. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] maxspeed par défaut
Le mer. 2 sept. 2020 à 01:16, Yannick a écrit : > L'implicite est désormais quasi impossible à deviner. > Je suis donc partisan de mettre systématiquement le maxspeed=* au > moins c'est clairement renseigné sans équivoque possible. Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne connaissent pas suffisamment bien le code de la route pour expliciter correctement l'implicite! D'ailleurs, en relisant les textes réglementaires avant de poster, je me suis rendu compte que je ne suis pas tout à fait au clair moi-même. Ainsi, je pense que https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse se trompe en écrivant: > hors agglomération : 80 km/h sur les routes sans séparateur > de voie, 90 km/h sur les routes avec séparateur En effet l'article R413-2 donne 110 et pas 90 km/h: > Hors agglomération, la vitesse des véhicules est limitée à [] > 110 km/ h sur les routes à deux chaussées séparées par > un terre-plein central ; Le cas n'est pas théorique, je connais une occurrence près de chez moi: https://www.google.fr/maps/@46.1980371,6.2917578,3a,75y,342.01h,94.36t/data=!3m6!1e1!3m4!1sifBdoBwUx_iYoXFBxbB-lA!2e0!7i16384!8i8192 Il y a aussi la question des routes à accès réglementé, signalées par le panneau C107 (le carré bleu avec une auto). Est-ce qu'une route à accès réglementé dont la chaussée contient une voie dans chaque sens sans terre-plein central est limitée à 80 ou 110 km/h? Je pense que c'est 110 km/h par application de l'Article 5 de l'Arrêté du 24 novembre 1967 relatif à la signalisation des routes et des autoroutes: > Ce signal annonce le début d'une section de route autre > qu'une autoroute, réservée à la circulation automobile, > sur laquelle les règles de circulation sont les mêmes que > celles prescrites aux articles R. 412-8, R. 417-10, R. 421-2 > (à l'exception de 9°), R. 421-4 à R. 421-7, R. 432-1, R. 432-3, > R. 432-5, R. 432-7 et R. 433-4 (1°) du code de la route et sur > laquelle, sauf indication contraire, la vitesse maximale des > véhicules est fixée à 110 km / h. Mais le cas est peut-être théorique, car je ne connais pas de telle route sans limitation explicite. Le 02/09/2020 à 07:16, Gad Jo a écrit : > Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout > où la vitesse est à 80. Je suppose que tu voulais écrire source:maxspeed=FR:rural, non? Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit : > Quand la vitesse est implicite, il y encore plus générique que mettre > explicitement la vitesse. Mais plutôt : > maxspeed=FR:urban Est-ce que maxspeed=FR:rural seul est OK pour une route rurale? Ou bien maxspeed=FR:rural + source:maxspeed=FR:rural est meilleur? Un simple maxspeed=FR:rural me semble déjà implicitement indiquer que la source est la vitesse implicite, mais bon. En fait, ce qui m'intéresse beaucoup avec FR:rural, c'est 1. la simplification induite pour les créneaux de dépassement ; 1.1. Au lieu de maxspeed:forward=90 + maxspeed:backward=80 ; simplement maxspeed=FR:rural ; 2. De ne pas devoir choisir entre 80, 90, et 110, pour les routes à chaussées séparées ; 2.2. Sur la route visible avec l'URL google que j'ai donné ci-dessus, je pense que la loi dit 110, mais les automobilistes vont pratiquement tous à 80. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] maxspeed par défaut
Bonjour, Près de chez moi passe la route D 903 avec une succession de portions à accès réglementé en 2x2 voies séparées (https://www.openstreetmap.org/way/825204700), à 2+1 voies (https://www.openstreetmap.org/way/24205655), à 1+1 voies (https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées (https://www.openstreetmap.org/way/654772946), sans compter les voies d'insertion, etc. De nombreuses portions ont une limite de vitesse implicite car il n'y a pas de panneau limitant la vitesse, et les règles générales s'appliquent (R413-2). Le problème est que ces règles sont mal connues, et presque tout a été mal mappé avec maxspeed=80. Pour l'instant j'ai supprimé ce qui était faux. Mais est-ce que ça vaut la peine de mapper les limitations par défaut? Informatiquement parlant, ça me semble profondément contre-productif: c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut tout de même taguer qqch pour faire la différence entre une route de maxspeed inconnue, et une route de maxspeed implicite. Ma question est donc: Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est une bonne pratique? PS: Les règles du code de la route sont si mal connues que https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse contient une erreur de 20 km/h. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment orthographier un nombre ordinal
Bonjour, Les ouvrages de conventions typographiques françaises que je connais donnent "28ᵉ" (ou "28e" si l'on n'a pas d'exposant). Je n'ai jamais vu "28ème" dans un ouvrage de référence, même si c'est très utilisé dans les textes qui ne suivent pas de convention typographique. Idem pour "28ième". Je ne crois jamais avoir vu "28Eme" ni "28Ème", quel que soit le texte. Voir aussi https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#Adjectifs_num%C3%A9raux_ordinaux Bonne soirée Marc Mongenet Le sam. 13 juin 2020 à 19:42, blef a écrit : > > Bonjour, > > Je cherche la meilleure façon d'orthographier le "Quai du 28ème Bataillon de > Chasseurs". > > 28ème comme ci-dessus avec accent (ma préférence) > 28Eme, 28Ème, 28E > Sans espace, avec espace. > > En tout cas la graphie actuelle 28° ma parait la pire. > > Qu'en pensez-vous? > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cycleway, footway ou path ? — Re: Désaccord sur un highway=footway
Bonjour Yves, Ce que tu décris correspond à ma manière de taguer (dans les Alpes). Je sais qu'il existe d'autres pratiques, mais je trouve que celle-ci convient bien. Pour être un peu plus précis, je tague en highway=unclassified les chemins goudronnés avec entretien hivernal (ou highway=residential si le chemin sert uniquement à des habitations), et en highway=track tracktype=grade1 les autres (qui servent généralement à accéder aux cultures et forêts). Marc Mongenet Le lun. 1 juin 2020 à 10:52, Yves P. a écrit : > > > Dans tous les cas, il me semble préférable de ne pas essayer de traduire, car > highway=path n'est pas un mot anglais c'est un tag, un mot clé d'un langage > intermédiaire entre machine et humain qui sert à modéliser et simplifier le > monde. > > On est d'accord, mais quel usage en fait-on, du moins en Europe ? > > highway=path s'inscrit dans la hiérarchie des highways, le niveau le plus > bas, d'usage mixte et non motorisé, c'est tout. > > Oui, mais alors quelle est la différence avec highway=footway ? > > highway=path ou track : je prends mes chaussures de rando ou un VTT > > highway=footway ou cycleway : je peux y aller avec chaussures de ville, un > vélo route > > Je ne saurais dire en français la différence entre sentier et chemin. > > Il y a aussi les noms locaux ;D > > Pour moi : > > chemin, chemin blanc (dans le Jura les locaux appellent ça comme ça car les > graviers sont plutôt blancs), "piste agricole" (traduction dans JOSM), piste > highway=track > c'est un chemin suffisamment large pour faire passer un tracteur, une > voiture, pas forcément carrossable (4X4) > c'est en terre, gravier, boue, herbe… > > sentier, (chemin) > highway=path > chemin étroit, seul des piétons, vélos, animaux… peuvent y passer. (trace au > sol faite à force de passer au même endroit) > > chemin piéton, voie piétonne > highway=footway > chemin dédié aux piétons, calibré/aménagé > c'est goudronné, bétonné, parfois en graviers > > piste cyclable, voie cyclable… > highway=cycleway > voie dédiée aux cyclistes, calibrée/aménagée > goudronnée, bétonnée, (en graviers ??) > > voie verte > highway=cycleway, footway,… > voie dédiée à la mobilité douce (piétons, vélos…), calibrée/aménagée > > __ > Yves > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?
Un voie de service peut recevoir bien plus de trafic qu'une résidentielle, tout dépend du service. Par exemple une aire de service d'autoroute, un accès à une station service fréquentée, un accès à un hypermarché. Et un bon indice que l'on a affaire à une voie de service, c'est qu'elle n'a pas de nom, donc non, on n'en a pas peu à faire. D'ailleurs, mon éditeur m'avertit lorsque je sauvegarde une route sans nom, mais pas s'il s'agit d'une voie de service. Mais surtout, une voie dans une agglomération, ouverte à la circulation, qui dessert des habitations, qui n'est pas dans un lotissement fermé ou un autre cas un peu particulier, c'est a priori une voie résidentielle. La taguer comme service parce qu'elle est étroite, je trouve que ça sent fort le tag pour le rendu. Marc Mongenet Le dim. 12 avr. 2020 à 18:21, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > C'est surtout une question de hiérarchie des voies une residential est > plus grosse et reçoit plus de trafic en tous genre qu'une service qui est > plus petite et reçoit un trafic plus spécifique. > En dessous de service il reste que les chemins. > La notion public, nommée ou non n'a que peu à faire ici. > > > Le dim. 12 avr. 2020 à 15:36, Marc Mongenet a > écrit : > >> En général j'évite d'utiliser highway=service pour une rue publique, qui >> a un nom. >> En général il s'agit simplement d'une rue résidentielle étroite. >> >> D'ailleurs, jusqu'en 2013 >> https://wiki.openstreetmap.org/w/index.php?title=Tag:service%3Dalley=502309 >> la définition higway=service service=alley n'indiquait que les allées >> d'accès de service. >> >> Je trouve que la nouvelle définition hybride ne fait qu'entériner un tag >> pour le rendu (le rendu étroit des allées de service). >> >> Marc Mongenet >> >> >> Le sam. 11 avr. 2020 à 23:24, Florimond Berthoux < >> florimond.berth...@gmail.com> a écrit : >> >>> Merveilleux on a une image >>> https://www.mapillary.com/app/?lat=48.70657111071199=2.071755502185397=18.2080345940791=7aJzk-PQW4MJ8bw4A_vM_A=0.2830141895413684=0.5381063618623757=1.2625482625482622=photo >>> >>> Je mettrais aussi >>> highway=service >>> service=alley >>> https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley >>> >>> Et grâce à l'imagerie et des calculs hautement scientifique (50cm le >>> carreau de peinture de cédez le passage) je calcul 2,6m à l'entrée, >>> probablement 3m ensuite :) >>> >>> Le sam. 11 avr. 2020 à 21:40, a >>> écrit : >>> >>>> > N'y aurait-il pas aussi des panneaux B15 >>>> <https://fr.wikipedia.org/wiki/Panneau_de_c%C3%A9dez_le_passage_%C3%A0_la_circulation_venant_en_sens_inverse_en_France> >>>> et C18 >>>> <https://fr.wikipedia.org/wiki/Panneau_d%27indication_de_priorit%C3%A9_par_rapport_%C3%A0_la_circulation_venant_en_sens_inverse_en_France> >>>> à cartographier ? >>>> C'est facultatif. >>>> >>>> J'ai un <https://www.openstreetmap.org/way/380002227> exemple où les >>>> panneaux sont des B11 >>>> <https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_largeur_en_France> >>>> indiquant que la largeur maxi est de 3,2 m. >>>> >>>> C'est la largeur de la voirie, pas de la voie (bon il y a des camions >>>> qui en plus de respectent pas le 3,5 T et qui élargissent au niveau des >>>> toitures...). >>>> >>>> D'où l'utilisation de width (bon on peut ajouter maxwidth). >>>> >>>> Le B15/C18 n'est pas obligatoire : dans un cas le véhicule ne doit pas >>>> s'engager car un autre est déjà dans la voie. >>>> >>>> À propos de lane, il y avait aussi lane=1,5. ÀMHA à proscrire. >>>> >>>> Comme déjà dit narrow=yes si là c'est plus étroit, pas si c'est étroit >>>> partout. >>>> >>>> width= c'est le plus objectif et c'est ce qui est conseillé dans le >>>> wiki >>>> <https://wiki.openstreetmap.org/wiki/FR:Key:lanes#Routes_.C3.A9troites> >>>> . >>>> >>>> > Non il n'y a aucun panneau aux entrées du passage. Côté sortie par >>>> contre il y a deux panneaux de "céder le passage". >>>> Donc entrée prioritaire et on y reste ? On aura tout vu. >>>> >>>> Jean-Yvon >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> >>> >>> -- >>> Florimond Berthoux >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?
En général j'évite d'utiliser highway=service pour une rue publique, qui a un nom. En général il s'agit simplement d'une rue résidentielle étroite. D'ailleurs, jusqu'en 2013 https://wiki.openstreetmap.org/w/index.php?title=Tag:service%3Dalley=502309 la définition higway=service service=alley n'indiquait que les allées d'accès de service. Je trouve que la nouvelle définition hybride ne fait qu'entériner un tag pour le rendu (le rendu étroit des allées de service). Marc Mongenet Le sam. 11 avr. 2020 à 23:24, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Merveilleux on a une image > https://www.mapillary.com/app/?lat=48.70657111071199=2.071755502185397=18.2080345940791=7aJzk-PQW4MJ8bw4A_vM_A=0.2830141895413684=0.5381063618623757=1.2625482625482622=photo > > Je mettrais aussi > highway=service > service=alley > https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley > > Et grâce à l'imagerie et des calculs hautement scientifique (50cm le > carreau de peinture de cédez le passage) je calcul 2,6m à l'entrée, > probablement 3m ensuite :) > > Le sam. 11 avr. 2020 à 21:40, a écrit : > >> > N'y aurait-il pas aussi des panneaux B15 >> <https://fr.wikipedia.org/wiki/Panneau_de_c%C3%A9dez_le_passage_%C3%A0_la_circulation_venant_en_sens_inverse_en_France> >> et C18 >> <https://fr.wikipedia.org/wiki/Panneau_d%27indication_de_priorit%C3%A9_par_rapport_%C3%A0_la_circulation_venant_en_sens_inverse_en_France> >> à cartographier ? >> C'est facultatif. >> >> J'ai un <https://www.openstreetmap.org/way/380002227> exemple où les >> panneaux sont des B11 >> <https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_largeur_en_France> >> indiquant que la largeur maxi est de 3,2 m. >> >> C'est la largeur de la voirie, pas de la voie (bon il y a des camions qui >> en plus de respectent pas le 3,5 T et qui élargissent au niveau des >> toitures...). >> >> D'où l'utilisation de width (bon on peut ajouter maxwidth). >> >> Le B15/C18 n'est pas obligatoire : dans un cas le véhicule ne doit pas >> s'engager car un autre est déjà dans la voie. >> >> À propos de lane, il y avait aussi lane=1,5. ÀMHA à proscrire. >> >> Comme déjà dit narrow=yes si là c'est plus étroit, pas si c'est étroit >> partout. >> >> width= c'est le plus objectif et c'est ce qui est conseillé dans le wiki >> <https://wiki.openstreetmap.org/wiki/FR:Key:lanes#Routes_.C3.A9troites>. >> >> > Non il n'y a aucun panneau aux entrées du passage. Côté sortie par >> contre il y a deux panneaux de "céder le passage". >> Donc entrée prioritaire et on y reste ? On aura tout vu. >> >> Jean-Yvon >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?
Bonjour, Le sam. 11 avr. 2020 à 14:13, Philippe Verdy a écrit : > J'aurais bien vu un "oneway=alternated" pour indiquer le passage par > alternance (il doit y avoir une zone d'attente à taguer ne plus pour > le croisement. > > Ce cas se présente de plus en plus souvent en ville pour pas mal de > rues qui ont été réduites volontairement avec de telles zones > (cependant avec un passage prioritaire dans un sens, pas toujours par > un panneau mais avec une alternance des côtés et donc la nécessité de > zigzaguer. La réduction s'est faite en mettant des places de > stationnement ou limitées et des obstacles tous les ~50 mètres (au > passage la nombre totale de places de stationnement est > considérablement réduit aussi). > > A noter que ce cas peut être tagué sémantiquement https://wiki.openstreetmap.org/wiki/FR:Key:traffic_calming chicane Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?
A propos de vidéosurveillance, il existe le panneau officiel français CE9 "parc de stationnement sous vidéosurveillance". Si un jour je le croise, je le prendrai en photo, mais je ne l'ai encore jamais vu. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bon usage de tracktype
Bonjour surface=asphalt indique bien le "goudronnées", mais pas le fait que la voie est conçue pour la desserte agricole et forestière, et pas pour le transit. Si l'on essaie de prendre un raccourci par une voie de desserte, on risque de se retrouver bloqué 15 minutes par un tracteur ou un camion qui charge du foin ou du bois, et l'on se fera regarder de travers comme le gêneur que l'on est. Sur une simple petite route de campagne, c'est différent. Marc Mongenet Le mar. 18 févr. 2020 à 11:04, Christian Quest a écrit : > surface=asphalt ! > > KISS ;) > > > > > Comment tu déclares les voies de desserte agricole et forestière > > goudronnées? > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Christian Quest - OpenStreetMap France > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bon usage de tracktype
Le mar. 18 févr. 2020 à 10:31, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > > Mais je n’en suis pas totalement satisfait, un chemin revêtu complétement > d’herbe mais avec un sol en dur (caillou) et plat sera plus roulant (ou > marchable) qu’un chemin ornièré de 50cm en terre sans herbe. > > par exemple > > https://lh3.googleusercontent.com/proxy/Ga9BFfPnZU8E2AULT9ip53bFkuaLChiDMHGhdzLee0z1kcw-6nAxZqGjdmN0I566YCURNpryM7DIvpDLlrUhzQosWDLAjAbdTDtqAER559ZEnpF93ZF18ZxPoj6lqrj6JRRZjP9ovF1D8FGj8w > vs > https://cdn.pixabay.com/photo/2015/06/30/07/31/green-826261_960_720.jpg > > J'avais lu il y a longtemps que gradeN servait à rendre compte de la visibilité d'une piste, et pas de sa qualité (ornières). C'est vrai que c'est une limite parfois ennuyante. Cela dit, une piste grade5 en herbe bien lisse, après 2 jours de pluie et le passage de quelques dizaines de véhicules, n'est plus du tout lisse. Elle devient aussi plus visible, pour un temps. Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bon usage de tracktype
Le mar. 18 févr. 2020 à 10:22, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Salut, > > Tagguer grade1 une route en gravier (non "paved") c’est aussi induire en > erreur le GPS ou le lecteur d’une carte qui s’attend à trouver une route en > dur facilement carrossable. > Qu’il soit, piéton, cycliste ou automobiliste. > Par exemple sur CyclOSM je considère un grade1 comme un chemin roulant et > lisse pour les vélo de route à pneu fin. > > En moto aussi ce serait aussi une très mauvaise surprise de se retrouver sur une route en gravier lorsqu'on attend du dur. Le gravier sur le goudron frais est déjà une telle galère... Marc Mongenet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bon usage de tracktype
Bonsoir, Je cartographie depuis une bonne dizaine d'années le Grand Genève, et pour les chemins agricoles et forestiers j'utilise toujours: * track grade1 lorsque la chaussée est revêtue, ce qui donne généralement des bords de chaussée distincts en photo aérienne; * track grade2 lorsque toute la chaussée est en terre ou gravier, mais sans herbe; * track grade3 lorsque le centre de la chaussée est en herbe mais pas les traces de pneus; * track grade4 lorsque les traces de passage sont discernables mais discontinues * track grade5 lorsque la piste est indiscernable ou à peine (de l'herbe partout) En bref, je me fonde sur les photos du wiki, qui n'ont pas varié depuis bien longtemps (toujours?) Je passe parfois des chaussées au revêtement particulièrement dégradé, ou recouvert de terre, en grade2. Bien sûr ces critères dépendent du climat local. Pour moi, https://www.mapillary.com/app/?focus=photo=IKTSczR_C0BrDrSTYcyDPg=42.72720613999894=2.712138949997893=17 est sans hésitation du track grade2. Parmi les erreurs que je rencontre souvent, il y a: highway=service au lieu de track grade1, probablement pour mapper en fonction du joli rendu de highway=service. highway=path au lieu de track grade3 à grade5, probablement par erreur ou manque d'information (mapping de traces GPS prises à pied/vélo). Marc Mongenet Le lun. 17 févr. 2020 à 07:34, rainerU a écrit : > Bonjour, > > Dans les départements 11 et 66, un utilisateur a récemment ajouté ou > modifié un > grand nombre de pistes de montagne. Les valeurs qu'il utilise pour > tracktype > sont généralement un ou deux niveaux supérieurs à celles que > j'utiliserais, > c'est à dire, là ou je mets grade3 ou grade2 il met grade1. J'ai laissé un > commentaire sur un de ses changeset avec des liens vers des images > Mapillary : > > https://www.openstreetmap.org/changeset/79978741 > > J'ai déjà eu le même genre de discussion avec lui en 2013. En gros, sa > règle est > : ce qui est goudronné est unclassifed, lest track c'est tout ce qui n'est > pas > goudronné, donc le grade1 est pour les "chemins empierrées larges, > roulables en > voiture standard". Moi, je me tiens à la définition du wiki de grade1 : > "revêtement dur de type asphalte ou composée de matériaux très compactés". > > Comme je ne suis pas entièrement sur d'avoir la bonne vision des règles > d'utilisation de tracktype et avant d'entamer une guèrre d'édition, je > vous > demande votre avis sur ces modifications. > > Rainer > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
