date:20200901

J'aurais tendance aussi à faire de ces courées des rues à part (pour leurs
propres adresses habitables, pas pour leur simple accès comme le 76 rue du
Caire, qui continue à faire partie de la rue du Caire mais n'est pas une
habitation ou une réelle adresse de résidence, leur seul "intérêt étant
leur porte d'accès (s'il y en a une).

Du moins si ces courées ont un statut public officialisé dans le cadastre
ou FANTOIR, ce sont des "rues" par elle-même même si elles sont uniquement
piétonnes et pas accessibles aux véhicules (hors 2 roues mais pas pour y
rouler).

Si la courée est privée (c'est une copropriété) alors ces adresses internes
sont comme des numéros d'appartement dans un même immeuble ou un ensemble
d'immeubles autour d'une partie commune: c'est une numérotation interne
(j'ai vécu dans un tel immeuble avec des parties communes dont une cour
partagée en copropriété aussi par deux maisons individuelles non
accessibles directement depuis la voie publique mais ayant un droit de
passage permanent par l'immeuble et leurs boites au lettres étaient
groupées dans l'immeuble avec celles des appartement, le courrier ne
mentionnait qu'un seul numéro, les numéros de porte/d'appartement étaient
optionnels, ce qui compte c'était le nom du destinataire sur la boite au
lettre mentionnant ensuite l'étage ou l'emplacement via la cour commune)

Sur une adresse postale, mettre les deux lignes c'est comme indiquer le
chemin à suivre avec un point intermédiaire sur une autre rue que le point
d'arrivée. Mais ça ressemble tout autant à mentionner un numéro
d'appartement dur une ligne supplémentaire avant l'adresse sur la rue
publique: le critère de distinction semble être la présence ou pas dans le
FANTOIR, qui ne détaille pas en principe les copropriétés (mais il peut y
avoir d'anciennes voies publiques privatisées en copropriétés (avec
l'accord des propriétaires et après accord et vente par la collectivité, et
la formation appropriée de la structure légale de gestion de la copropriété
qui sera taxée) souhaitant sécuriser un accès et aménager des installations
communes protégées et entretenues (cour, jardin, local technique, garage,
etc.)

Le mar. 1 sept. 2020 à 22:23,  a écrit :

> J'aurais tendance à voir ça comme une rue à part.
>
> Mais pour la double adresse, addr:full est la solution "crade" répondant
> au besoin.
>
> Si tu considères que c'est ici le 76 rue du Caire, tu le mets dans
> l'associatedStreet de la rue du Caire.
>
> Pour les X Cour Saint Henri, 76 Rue du Caire (ou un autre numéro pour
> l'autre entrée), tu pourrais mettre addr:flats
>  pour les numéros.
>
> Peut-être addr:place
>  pour "Saint
> Henri".
>
> Et donc pas d'associatedStreet pour ces cours car il n'y a pas
> d'associatedStreet pour les place=.
>
> addr:unit  me semble
> préférable.
>
> Du coup tu mettrais ici :
>
> addr:flats =X
> addr:unit =Cour Saint
> Henri
> addr:housenumber
> =76
>
> et le tout dans l'associatedStreet ? Osmose va râler.
>
> Alors faux positifs ou vous avez de meilleures idées ?
>
> Jean-Yvon
> Le 01/09/2020 à 17:51, Denis Chenu via Talk-fr - talk-fr@openstreetmap.org
> a écrit :
>
> Bonjour,
>
> Je suis en train de reprendre les adresses du Fantoir et de les ajouter
> sur Roubaix.
> Les adresses non encore répertorié sont souvent les courées 
> :https://fr.wikipedia.org/wiki/Cour%C3%A9e
>
> Sur le Fantoir : en général elles ont la double adresse:
> «Nom de courée Nom de la Rue»
>
> Lors de l'envoi postal, certains utilisent la double adresse
> 1 Courée nom de la Couré
> 42 rue de la rue
>
> Selon le BANO, j'ajoute ou non le nom de la rue.
> Mais je me pose la question de la double adresse ?
> Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
> Est sou quel format , quel tag utiliser ?
> peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?
>
>
> Autre chose : ces courées ont des entrées qui appartiennent à la rue
> principale.
>
> Je me pose la question d'ajouter ces entrées puis de les ajouter à la
> relation ?
> Ici : une entrée que j'ai taggué 
> :https://www.openstreetmap.org/node/7864474720
>
> En image : ce que peux donner une 
> entréehttps://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
> ouhttps://pic.infini.fr/7iDxlOYf/KMge9ehI.png
>
> Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
> ajoute dans la relation ?
>
> Merci,
> Denis
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/list

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-01 Par sujet Yannick

Le 02/09/2020 à 00:51, Marc Mongenet a écrit :
> 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

Bonsoir,

L'implicite est désormais quasi impossible à deviner. Prends les
nationales à 80 et des portions de départementales à 90. Je me mets à la
place de l'étranger pour qui c'est pire qu'un casse-tête chinois. On
finit par ne plus savoir la limite en vigueur sur telle ou telle portion
de route.
Je suis donc partisan de mettre systématiquement le maxspeed=* au moins
c'est clairement renseigné sans équivoque possible.

Amitiés


-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] maxspeed par défaut

2020-09-01 Par sujet Marc Mongenet

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] Affichage d'un name suivant le rendu

De façon pragmatique on peut admettre d'avoir simplement les deux (un noeud
et une surface), sans aucune relation, et faire en sorte que cela ne
s'affiche pas deux fois (un point parking trouvé dans une surface parking
peut être éliminé, peu importe si tous les autres tags dont le nom ne sont
pas identiques, on n'affichera qu'un seul nom (peut importe lequel même si
ça diverge un peu), en fusionnant "intelligemment" les tags trouvés (si
nécessaire on peut faire un log d'erreurs pour signaler les valeurs en
conflit même si on n'en retient qu'une arbirtrairement sur le rendu).

En revanche il peut être utile de conserver certains tags spécifiques (pas
tous) comme la délimitation des places réservées aux handicapés, ou les
parkings 2 roues sans avoir besoin d'afficher leur nom en doublon visible.

Dans tous les cas, pas besoin de label ni de relation.

Attention dans certains cas il y a des places réservées de façon
privées dans les parkings public (exemples: places réservées au personnel
porteurs d'une carte spécial, ou places protégées par une barrière ou un
plot levant (à clé ou télécommandé).En principe on devrait délimiter ces
places avec une autre surface séparée indiquant leur caractère privé. mais
si cela ne concerne qu'un ou deux emplacements, il y a un tag particulier
pour ces emplacements individuels placés dans un parking plus grand.

De même pour les aires de stationnement pour camions, bus et véhicules
longs ou à remorque (qui ne leur sont pas forcément réservés mais ces
véhicules ne peuvent pas se garer dans les plus petits emplacements). Ce
cas se présente notamment sur les aires d'autoroutes. Il peut arriver que
les emplacements pour véhicules de tourisme soient pleins et qu'il aillent
s'aligner plus loin sur les aires pour véhicule longs, mais en principe on
devrait éviter de laisser libre les emplacements longs partiellement
occupés, afin de laisser de la place pour les autres véhicules longs (comme
ces places sont souvent plus éloignées des points de service, naturellement
les véhicules remplissent d'abord les emplacements les plus proches et se
regroupent). Cela pose rarement des problèmes. Si c'est un stationnement
pour le repos, il y a des emplacements mieux adaptés que ces grandes places
souvent trop lumineuses et sans craindre de se faire déranger par des
camions ou des cars...



Le mar. 1 sept. 2020 à 09:58, Christian Quest  a
écrit :

> Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
>
> Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Bien souvent dans mes contributions, je remet des POI en surfacique alors
> qu'ils ne sont que ponctuels, la première étape consistant souvent à migrer
> un tag sur un bâtiment entier, mais la seconde, quand on le peut, consiste
> à délimiter plus largement l'emprise de tel ou tel POI. Cas typique: les
> écoles !
>
> J'allais dire ouille.
>
> Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.
>
> Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)
>
> Attention aussi à la traduction simpliste qu'on a fait de POI, non ?
>
> Réduire un POI à un unique point est quand même une façon minimaliste de
> décrire un lieu rarement ponctuel sur le terrain. J'ai toujours considéré
> qu'un ponctuel c'était bien pour apporter une info minimale, mais qu'une
> surface apporte bien plus d'infos (où commence le POI, où s'arrête-t-il,
> est-il étendu ou pas, etc).
>
>
> Si par contre tu parles d'objets de nature surfacique telles qu'un parking
> ou un jardin, on est d'accord.
>
> Pour une école je ne sais : tu mets ça sur le landuse ?
>
> Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le
> ponctuel à part de façon arbitraire ?
>
>
> Ceci dit souvent quand le PI est surfacique des cartographes (avec
> StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli ne
> montre que les PI ponctuels :-(.
>
> Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers le
> centroid, éventuellement son emprise aura un style surfacique en plus. Le
> nom doit être placé quelque part, il est donc ponctuel lui aussi mais
> déterminé à partir de l'emprise.
>
>
> La seule solution propre compatible avec les deux mais lourdingue pour les
> petits objets c'est de faire une relation type=boundary avec le nœud comme
> label et le contour en outer comme ici
> .
>
> Bof bof bof... que de complexité pour un usage quasi nul des rôles label,
> d'autant plus que remonter dans les relations est un exercice délicat pour
> les moteurs de rendu.
>
> Dans ce cas précis, je ne trouve pas que la position pour ce label soit
> bien choisie. Elle est trop proche de la route, donc collision avec le nom
> de celle-ci (identique d'ailleurs).
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/t

Re: [OSM-talk-fr] No U-turn vs BRouter

Le mar. 1 sept. 2020 à 14:04,  a écrit :

> TL;DR: overtaking=no
> Le 01/09/2020 à 12:35, Francois Gouget - fgou...@free.fr a écrit :
>
> On Sun, 30 Aug 2020, Francois Gouget wrote:
> [...]
>
> Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
> demi-tour là où les deux voies se rejoignent. Cela me parait très
> superflu.
>
> En fait les restrictions ne sont pas totalement superflues 
> :https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard&lonlats=-1.156756,45.785759;-1.158315,45.785505&profile=car-eco
>
> Si superflues car fausses (mauvais tag).
>

Je dis faux car mauvaise interprétation ! En France à moisn de 50 mètres du
rond-point c'est interdit (ça devrait être signalé par un panneau mais là
on n'indique pas dans OSM la position de ces panneaux d'approche d'un
rond-point.

Il suffirait déjà de mettre une limtie de 50 mètres par défaut pour
éliminer ces très mauvais conseils de parcours. Le routeur pourrait estimer
aussi la largeur de la chaussée, l'absence de zone latérale de dégagement
(stationnement le long de la voie, absence de voie cyclable, présence sur
la voie publique de bateaux d'entrées de voies privées ou de garage, où
l'arrêt est possible et même marqué au sol pour interdire non pas l'arrêt
mais le stationnement)

et l'angle du tracé doit servir à déterminer et un rayon de courbure
minimal doirt permetre d'estimer correctement la place nécesaire pour voir
si c'st possible de faire une maeuvre unique sans sortir de la voie
publique ou empiéter trottoirs ou voies cyclables et sans marche arrière.
Un autre indicateur est celui du nombre de voies (2 par défaut sur les
rues/routes bidirectionnelles, à moins qu'on ait mis autre chose, soit
seulement 3,5 mètre de largeur en moyenne par voie: pour faire un demi-tour
complet sans marche arrière, on est plus proche des 10 mètres avec une
voiture, il faut au moins 3 voies ou un dégagement latéral pour le faire
sans s'arrêter en bloquant  les deux voies et à moins de 50 mètres du
rond-point c'est trop dangereux.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] No U-turn vs BRouter

Le mar. 1 sept. 2020 à 12:36, Francois Gouget  a écrit :

> * Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
>   en sortie de rond-point. Mais s'il y a une ligne discontinue cela
>   serait-il vraiment interdit ?
>

En pratique oui, pour la police ou pour les assurances, si ils estiment que
la manœuvre était trop dangereuse (manque de visibilité, aux distances de
freinage bien connues et selon les limites de vitesse applicables).

Le code de la route précise bien que la signalisation, même si elle *peut*
être impérative (pour le cas courant) n'exclue pas le jugement et le
bon-sens du conducteur, et le respect des autres usagers (même quand ils
commettent des interdits, notamment les piétons et cyclistes qui eux n'ont
aucune assurance spécifique obligatoire pour couvrir les frais des
accidents et le //pretium doloris// ou les autres conséquences comme les
incapacités, arrêts de travail, pertes d'emploi ou inadéquations aux postes
pour lesquels ils sont formés et frais de réadaptation/rééducation).

Un conducteur disposant d'une assurance obligatoire est toujours
responsable devant quiconque n'a pas d'obligation à en avoir (cette
responsabilité sera prise en charge par son assurance mais des malus
peuvent cependant s'appliquer suite à cette prise en charge ou une
radiation ultérieure du contrat qui cependant reste applicable à ce dommage
couvert), et s'il n'est pas valablement assuré il commet un délit pénal qui
sera sanctionné en plus des réparations qu'on lui réclamera (et pas la
peine de chercher chez sont assureur, il fera tout pour nier toute
couverture s'il y a un délit quelconque, et c'est marqué dans ses contrats,
au mioeux il n'applisera qu'une responsabilité partagée pour son calcul de
malus à condition de faire appel de sa décision, ce qui nécessite souvent
de le poursuivre en justice et prendra du temps; pire, si on a plusieurs
assurances, elles se renverront entre elles la prise en charge du même
dommage et là aussi on doit aller en justice pour faire désigner un
assureur qui prendra en charge le dossier et négociera lui-même avec les
autres ou fera fonctionner ses systèmes de réasurances et demandera aussi à
être partie civile pour récupérer une partie des versements par la sécu ou
autres compensations publiques, y compris sur les indemnités journalières
ou de chomage; souvent c'est donnat-donnant, le principe étant juste de
couvrir l'urgent mais pas l'avenir, là encore il faut souvent aller en
justice si on estime que l'assureur nous doit plus et que ses demandes
étaient disproprotionnées ou mal évaluées).

Tout conducteur est normalement sensibilisé pendant sa formation sur la
conduite "avec prudence" qui est une obligation (guidée en partie mais pas
seulement par la réglementation obligatoire). Il doit rester maître de son
véhicule et connaitre ses capacités, apprendre à faire ses
manœuvres rapidement pour ne pas gêner ou créer de danger supplémentaire
pour les autres et il doit être prompt à réagir ou à signaler tout problème
technique. Faire un demi-tour en sortie de rond-point sur un espace exigu
ne permet souvent pas de le faire en sécurité (pour soi ou les autres) en
un temps court avant qu'un danger arrive (notamment des autres véhicules
sortant du rond-point qui ne sont pas sensés devoir stopper brutalement
même s'ils respectent les vitesses limités (cependant ceux qui sortent d'un
rond point doivent s'attendre à trouver un passage piétons protégé sur le Y
et leur laisser le passage, et s'il le faut en s'arrêtant sur l'anneau.
Mais s'ils ne voient aucun piéton, juste un véhicule devant eux, il peuvent
reprendre un peu de vitesse et ne s'attendent pas à voir ce véhicule piler
pour faire demi-tour en plusieurs manœuvres coupant les deux sens dont
souvent une marche arrière en contre-sens de la voie de sortie.

La ligne continue n'est pas une obligation des collectivités sur le
terrain, même si elles est prescriptive, c'est avant tout un rappel: à
moins de 50 mètres d'un rond-point (distance minimale de signalisation
utile selon la loi), il y a une interdiction de fait car le rond-point
lui-même était signalé avant d'y entrer, lui aussi à 50 mètres au moins: si
on n'a pas encore passé après avoir franchi le rond-point le panneau
alertant d'un rond-point à 50 mètres dans l'autre sens, on doit faire comme
si c'était une ligne continue (même si on ne voit pas la face de ce panneau
destinée à l'autre sens, il s'appliquera de toute façon après le demi-tour,
et il n'est pas prudent de faire demi-tour quand il y un panneau dans
l'autre sens qu'on n'a même pas encore vu et qui pourtant indique une zone
de danger pleinement signalée et applicable.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les courée de Roubaix : adresse et entrée


J'aurais tendance à voir ça comme une rue à part.

Mais pour la double adresse, addr:full est la solution "crade" répondant
au besoin.

Si tu considères que c'est ici le 76 rue du Caire, tu le mets dans
l'associatedStreet de la rue du Caire.

Pour les X Cour Saint Henri, 76 Rue du Caire (ou un autre numéro pour
l'autre entrée), tu pourrais mettre addr:flats
 pour les numéros.

Peut-être addr:place
 pour "Saint Henri".

Et donc pas d'associatedStreet pour ces cours car il n'y a pas
d'associatedStreet pour les place=.

addr:unit  me semble
préférable.

Du coup tu mettrais ici :

addr:flats =X
addr:unit =Cour Saint
Henri
addr:housenumber
=76

et le tout dans l'associatedStreet ? Osmose va râler.

Alors faux positifs ou vous avez de meilleures idées ?

Jean-Yvon

Le 01/09/2020 à 17:51, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Bonjour,

Je suis en train de reprendre les adresses du Fantoir et de les ajouter
sur Roubaix.
Les adresses non encore répertorié sont souvent les courées :
https://fr.wikipedia.org/wiki/Cour%C3%A9e

Sur le Fantoir : en général elles ont la double adresse:
«Nom de courée Nom de la Rue»

Lors de l'envoi postal, certains utilisent la double adresse
1 Courée nom de la Couré
42 rue de la rue

Selon le BANO, j'ajoute ou non le nom de la rue.
Mais je me pose la question de la double adresse ?
Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
Est sou quel format , quel tag utiliser ?
peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?


Autre chose : ces courées ont des entrées qui appartiennent à la rue
principale.

Je me pose la question d'ajouter ces entrées puis de les ajouter à la
relation ?
Ici : une entrée que j'ai taggué :
https://www.openstreetmap.org/node/7864474720

En image : ce que peux donner une entrée
https://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
ou
https://pic.infini.fr/7iDxlOYf/KMge9ehI.png

Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
ajoute dans la relation ?

Merci,
Denis



___
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] No U-turn vs BRouter

2020-09-01 Par sujet Frédéric Rodrigo


Le 01/09/2020 à 14:03, osm.sanspourr...@spamgourmet.com a écrit :

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
   en sortie de rond-point. Mais s'il y a une ligne discontinue cela
   serait-il vraiment interdit ?


Non, si la ligne est discontinue tu as le droit (enfin là tu es sur 
une départementale).


Mais tu ne dois pas le faire (en cas d'accident tu auras tort) car du 
fait du giratoire, tu ne peux voir assez les véhicules venant de 
l'arrière.


Sur Paris c'est interdit 
 
sauf à un carrefour (mais OSM ne connaît cette règle).


Ça dépend aussi du pays. Je voulez gérer ça dans Osmose. Mais je n'ai 
jamais trouver de liste de ce détails du code de la route par pays.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

> Pour les relations de transports, les arrêts dans le bon ordre ça suffit 
> (plan schématique) !
> 
Pour un gestionnaire de réseau, savoir exactement ou passe le bus est utile en 
cas de travaux, bouchons… ne serait-ce que pour estimer les retards ou 
simplement calculer les temps de trajet.

Pour un cycliste ou un randonneur (à pied, à cheval…) avoir le trajet exacte 
est précieux.
En théorie, l'itinéraire est balisé sur le terrain… en pratique ?
Pour la rando, il y a les dénivelés à prendre en compte pour adapter 
éventuellement son parcours.
Et quand il y a des conflits avec les propriétaires, c'est aussi important de 
passer au bon endroit :D
> Pour les réseaux de bus, oui Yves si on veut un parcours réaliste, c'est 
> bien, façon "plan du réseau",
> 
> sauf que pour le rendu il faudra lancer les calculs d'itinéraires (pour au 
> final stocker les différents chemins).
> 
Oui, au final la machine va effectivement gérer les morceaux de segments (les 
calculs peuvent-être réalisé qu'une seule fois).

Mais pour la personne qui maintient les relations ça change la donne : la 
découpe de chemins ne change rien…
On évitera de perdre bêtement du temps à réparer sans cesse les mêmes relations.
> Yves : et pour afficher le trajet de manière lisible sur osm.org, tu demandes 
> à Tom ? ;-)
> 
Je vais demander à Sarah, c'est elle qui a écrit Waymarked Trails :)

__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes


Bonjour, oui, il y a plusieurs niveaux qui se mêlent :

- le niveau surfacique. Là on n'en parle pas mais avec les chemins
piétons et éventuellement pistes cyclables dessinés à côté on s'en approche.

Avec la découpe des entrées-sorties au niveau des séparateurs de
chaussée triangulaires aussi.

- le niveau logique.

Là on va de telle route à telle route en passant par tel giratoire.

Représenter le giratoire comme un point suffit  :

Inutile d'avoir la découpe de la route en multiples sections.

Pour les relations de transports, les arrêts dans le bon ordre ça suffit
(plan schématique) !

Pour les réseaux de transport, ça va dépendre : coté métro on va
seulement grossièrement suivre les directions (à 45 °C près) et les
distances.

Pour les réseaux de bus, oui Yves si on veut un parcours réaliste, c'est
bien, façon "plan du réseau", sauf que pour le rendu il faudra lancer
les calculs d'itinéraires (pour au final stocker les différents chemins).

Mais à mon avis ce qui pêche un peu c'est le mélange d'infos de
précision variable : on n'a pas besoin dans un plan de bus de savoir
s'il va éviter le séparateur de chaussée par la gauche ou par la droite,
on espère sauf cas spécial

que ce sera par la droite.

Francois, pour le calcul d'itinéraire j'ai voulu tester un rond point
pour lequel manque réellement une patte de chemin piéton, aucun moteur
n'a réussi sauf BRouter en mode piéton
.

Yves : et pour afficher le trajet de manière lisible sur osm.org, tu
demandes à Tom ? ;-)

Jean-Yvon

Le 01/09/2020 à 19:44, Yves P. - yves.prat...@gmail.com a écrit :

C'est vite ingérable et pourtant j'ai tout le réseau en tête.

Oui.


Malheureusement je ne vois aucune solutions pour éviter cela.


Je propose de faire une relation route basée sur des noeuds : Exemple

Pour faire ce pseudo trajet de bus, il me faut décrire que 3 noeuds
(sans rien découper).

Avec les relations actuelles, je dois découper 3 chemins. Une des rues
à parcourir est composée de 2 segments.
Ça fait donc au final 5 way à décrire.

Ici j'utilise des nœuds qui font partie des chemins.

L'idéal serait d'utiliser des noeuds quelconques (que le nœud soit sur
le chemin ou pas) :

  * les arrêt de bus
  * les panneaux indicateurs de randonnées


A tester.

Donc une relation serait composée uniquement de noeuds, avec des rôles
comme arrêt ou point d'intersection.
Dans l'exemple, ,un a 2 "arrêts" (départ et arrivée) et une intersection.

Actuellement on a ça, avec les chemins en plus et les "intersections"
en moins.
Mais JOSM a du mal à trier le tout : il met tous les arrêts et
panneaux ensemble (dans quel ordre ???), puis tous les chemins qu'il
ordonne bien à condition que le trajet soit linéaire.

__
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] Rond point et relations routes

> C'est vite ingérable et pourtant j'ai tout le réseau en tête.
Oui.

> Malheureusement je ne vois aucune solutions pour éviter cela.

Je propose de faire une relation route basée sur des noeuds : Exemple 

Pour faire ce pseudo trajet de bus, il me faut décrire que 3 noeuds (sans rien 
découper).

Avec les relations actuelles, je dois découper 3 chemins. Une des rues à 
parcourir est composée de 2 segments.
Ça fait donc au final 5 way à décrire.

Ici j'utilise des nœuds qui font partie des chemins.

L'idéal serait d'utiliser des noeuds quelconques (que le nœud soit sur le 
chemin ou pas) :
les arrêt de bus
les panneaux indicateurs de randonnées

A tester.

Donc une relation serait composée uniquement de noeuds, avec des rôles comme 
arrêt ou point d'intersection.
Dans l'exemple, ,un a 2 "arrêts" (départ et arrivée) et une intersection.

Actuellement on a ça, avec les chemins en plus et les "intersections" en moins.
Mais JOSM a du mal à trier le tout : il met tous les arrêts et panneaux 
ensemble (dans quel ordre ???), puis tous les chemins qu'il ordonne bien à 
condition que le trajet soit linéaire.

__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] No U-turn vs BRouter

2020-09-01 Par sujet Francois Gouget

On Tue, 1 Sep 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]
> > En fait les restrictions ne sont pas totalement superflues :
> > https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard&lonlats=-1.156756,45.785759;-1.158315,45.785505&profile=car-eco
> Si superflues car fausses (mauvais tag).

C'est plus relation incomplète dans ce cas précis : il manque le to.

L'exemple était peut-être mal choisi mais on observe le même problème 
sur les rond-points sans restriction.

> Sur Paris c'est interdit
> 
> sauf à un carrefour (mais OSM ne connaît cette règle).

HS : C'est pratique ces petites lois locales qui ne sont indiquées nul
 part sur la route ! Nul n'est sensé ignorer la loi mais quand elle 
 est publiée dans le classeur fermé à clef d'un sous-sol sans 
 éclairage...

-- 
Francois Gouget   http://fgouget.free.fr/
  E-Voting: Those who cast the votes decide nothing.
 Those who count the votes decide everything.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-01 Par sujet Georges Dutreix via Talk-fr


Bonjour,

J'ai souvent découpé des giratoires pour des lignes de bus : honte sur moi !
Promis, je ne le ferai plus ;-)

Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme 
moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
ou 
https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points 
?


Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki 
moi-même. Et il semblerait qu'il n'y ait pas consensus...
Peut-on écrire par ci par là que la bonne pratique en France est de, si 
possible, ne pas casser les rond points en plusieurs segments ?




Le 01/09/2020 à 11:24, Yves P. a écrit :

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 😁

__
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] Rond point et relations routes

2020-09-01 Par sujet Gad Jo

Pour avoir mis en place l'ensemble du réseau de bus sur Narbonne c'est la mort 
dans l'âme que j'ai du segmenter en plusieurs section des routes ou rue. C'est 
vite ingérable et pourtant j'ai tout le réseau en tête.
Pour les giratoire c'est totalement inutile de les segmenter sauf cas très très 
particulier. Le routage fonctionne très bien tel quel.

Avec les restrictions de vitesse, bande cyclable et autre info (trottoir, 
revêtement, éclairage) ça multiplie les découpes

Malheureusement je ne vois aucune solutions pour éviter cela.

Le September 1, 2020 9:44:37 AM UTC, Christian Rogel 
 a écrit :
>
>> Le 1 sept. 2020 à 11:25, Yves P.  a écrit :
>> Je tombe sur des itinéraires vélos, bus… qui passent par des
>ronds-points.
>> 
>> Ces derniers sont coupés en petits morceaux pour avoir un bel
>itinéraire.
>> Ça part d'une bonne intention (j'ai fait la même chose au début),
>mais c'est ingérable !
>> 
>> S'il vous plait ne serez pas le sécateur quand vous croisez un
>giratoire.
>> Merci pour lui et son intégrité 😁
>
>
>Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour
>agir ainsi, soit appartenir à la team 1er degré, soit être certain que
>le RP est positionné correctement. Et surtout au bon diamètre.
>Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
>Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les
>autres contributeurs, laissé dans l’état normal.
>
>Christian R.
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Les courée de Roubaix : adresse et entrée

2020-09-01 Par sujet Denis Chenu via Talk-fr

Bonjour,

Je suis en train de reprendre les adresses du Fantoir et de les ajouter
sur Roubaix.
Les adresses non encore répertorié sont souvent les courées :
https://fr.wikipedia.org/wiki/Cour%C3%A9e

Sur le Fantoir : en général elles ont la double adresse:
«Nom de courée Nom de la Rue»

Lors de l'envoi postal, certains utilisent la double adresse
1 Courée nom de la Couré
42 rue de la rue

Selon le BANO, j'ajoute ou non le nom de la rue.
Mais je me pose la question de la double adresse ?
Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
Est sou quel format , quel tag utiliser ?
peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?


Autre chose : ces courées ont des entrées qui appartiennent à la rue
principale.

Je me pose la question d'ajouter ces entrées puis de les ajouter à la
relation ?
Ici : une entrée que j'ai taggué :
https://www.openstreetmap.org/node/7864474720

En image : ce que peux donner une entrée
https://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
ou
https://pic.infini.fr/7iDxlOYf/KMge9ehI.png

Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
ajoute dans la relation ?

Merci,
Denis



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fwd: Des nouvelles de transport.data.gouv.fr ! | Info-lettre Août 2020

Des nouvelles de transport.data.gouv.fr !
Des nouvelles du Point d'Accès National aux données de transport !
Bonjour à toutes et à tous,

L'été touche à sa fin et la rentrée arrive avec son lot de nouveaux
chantiers ! Nous avons cet été pu concentrer nos efforts sur le
développement de nouvelles fonctionnalités et l'élaboration de nouveaux
schémas pour des données d'intérêt comme les aménagements cyclables ou
l'autopartage. La période de la rentrée se prête également à la mise à jour
des données d'horaires théoriques ; nous vous invitons à participer à notre
prochain atelier le 8 septembre sur ce sujet (détails en bas de
l'info-lettre).
*☀ *Un été de nouvelles fonctionnalités !

*Le nouveau validateur de données*

Garantir la qualité des jeux de données du Point d'Accès National, c'est
proposer des outils pour mieux comprendre les erreurs qu'ils peuvent
contenir. Une visualisation géographique est désormais disponible sur les
défauts que notre Validateur

 identifie dans les fichiers GTFS. Qu'il s'agisse de temps de trajets nuls
entre deux stations, d'arrêts trop proches, en double, inutilisés... tous
ces problèmes sont désormais visualisables sur une carte.


*La carte nationale des réseaux de transports sur le Point d'Accès National*

Petite nouveauté parmi les jeux de données édités par transport.data.gouv.fr
: un extract pour toute la France de la position des arrêts et des tracés
des lignes

de
tous les jeux de données de transports en commun disponibles sur la
plateforme. Nous vous avions présenté dans la Newsletter de Juin notre
outil d'extraction automatique des géométries des jeux de données GTFS. Ce
fichier national est la simple agrégation de tous les fichiers GeoJSON qui
avaient été ainsi générés. Attention : cette méthode peut créer des doublons
certaines stations étant présentes dans différents jeux de données !
*🚲 *Une rentrée à vélo
*De nouveaux schémas pour les données d'aménagements et stationnements
cyclables.*

L'une des activités de l'été a été de travailler sur l’élaboration d'un schéma
national pour les données concernant les aménagements cyclables (bandes et
pistes cyclables...) et le stationnement des vélos (arceaux et autres
dispositifs). C'est une thématique qui suscite beaucoup d'engagements et
nous avons pu bénéficier de la motivation de producteurs et de
réutilisateurs de données !

Un schéma de données a été établi lors du quatrième atelier sur
l'harmonisation des données d'infrastructures cyclables
.
Il a été défini grâce au travail initié par Vélo & Territoires

et au groupe de travail composé de producteurs et réutilisateurs de données.
Vous trouverez ici le schéma retenu : lien

.

Nous travaillons actuellement sur :

   - L’établissement du dictionnaire de données ;
   - La mise en place d’une photothèque pour les différents types
   d’aménagements cyclables référencés.

Si vous voulez contribuer à cette définition et illustration des données
d'aménagements cyclables, vous pouvez Miryad, en charge de l'investigation
de ces données à cette adresse : miryad@beta.gouv.fr.

Par ailleurs un travail d'investigation a été mené sur les données de
stationnement
vélo. A partir de l'analyse des données locales publiées sur de nombreux
portails et des données présentes sur OpenStreetMap, un schéma de données a
été proposé pour standardiser la publication de ce type de données. Un espace
de discussion

a été créé sur le projet Github de schema.data.gouv.fr. Nous vous
encourageons vivement à regarder ce schéma

et proposer des modifications si nécessaire !

*🔢 *Des chiffres sur notre déploiement *Quelques statistiques pour mieux
suivre l'avancement du projet transport.data.gouv.fr
*


Nous vous proposerons désormais à chaque Newsletter un petit aperçu
statistique de l'état d'avancement du projet.

📆 Nos futurs rendez-vous

   - *Mardi 8 septembre *- atelier pour les producteurs de données sur la
   gestion de leurs mises à jour.

Cet atelier permettr

[OSM-talk-fr] Projet du mois : la presse comme source de données

Bonjour,

La recherche "défibrillateur dae" dans Google News permet de trouver des 
articles concernant l'installation de nouveaux DAE, ou leur utilisation.
La plupart indiquait des DAE inconnus GeoDAE et d'OSM.

Avis aux contributeurs qui aimeraient continuer, je me suis arrêté au 8 juin : 
Près de Dieppe, le stand de tir s’équipe d’un défibrillateur 


Peut-être que Twitter permettrait d'en trouver ?

__
Yves





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

Il y a quelques exceptions connues pour certains giratoires avec des
sections très différentes (certaines parties qui sont des ponts ou ayant
des restrictions spécifies avec des changements de voies).

La plupart des ronds-points son homogènes et ne nécessite aucun découpage
(et surtout pas pour les lignes de bus: le rond point reste entier et sur
les parcours est vu comme un point unique même si en zoomant on voit une
boucle à la place du point sur les diagrammes.

Le découpage est très rarement nécessaire. J'ai vu quelques exemples où ça
se justifie pour de très grands ronds-points multiniveaux (par exemple un
rond-point au dessus de la rocade sud de Rennes, car il n'y a pas moyen
d'unifier les tags dessus sans créer d'anomalies sur les autres voies qui
passent dessous ou transitent dessus, ni moyen de positionner correctement
les barrières de protection). Cependant le découpage est réduit au minimum,
juste pour les tags qui doivent changer de valeur sur certaines sections.
Et c'est parce que les tags actuellement approouvés et reconnus ne
permettant pas de faire facilement autrement. Ce cas est trop exceptionnel
pour justifier de façon suffisante une demande de modification de la
documentation et des usages. Parfois un nouveau tag règle le problème et
permet d'annuler un tel découpage.

D'une façon générale aussi j'enlève ces découpages qui le plus souvent ont
cassé les routes (sauf certaines des lignes qui y passent). Par exemple
quand il y a une voie centrale de bus qui traverse le rond-point, et des
deux ou arrêts sur la boucle. Cela ne concerne de toute façon que les très
grands-ronds-points (plus de 75 mètres de diamètre), et sinon beaucoup de
ronds-points en Angleterre (avec des deux et stops sur la boucle) et aux
USA (parfois des règles plus compliquées (même sur les
"turbo-roundabounts", sensés "optimiser" le traffic en donnant plus de
priorités à certaines voies traversantes ou certains tourne-à-gauche mais
en ajoutant là encore des cédez le passages et stop rapprochés ou
successifs pour entrer dans la boucle, et parfois même des impossibilités
d'aller d'une direction à une autre alors que ces directions sont sur des
voies bidirectionnelles: il faut rejoindre un autre rond-point
suivantet faire des kilomètres en plus).

Il y a d'autres exceptions dans des ronds-points géants en Asie, et
certains ronds-points en montagne (avec des sections de la boucle dans des
tunnels, d'autres sur des ponts, d'autres de plein-pied), on en voit près
d'Andorre, en Suisse et certaines villes côtières italiennes, là c'est
compliqué aussi par la coexistence d'autres réseaux, ferroviaires par
exemple, parfois aussi des canaux, des passerelles piéton, ça se superpose
sur divers niveaux), et dans les ronds-points d'interconnexion
autoroutières aux USA qui n'ont rien en commun avec nos giratoires français
habituels (qui font plus de la moitié de tous les ronds-points du monde, et
il s'en construit encore massivement, nombre de communes les utilisent pour
enlever les feux et réduire la pollution, le bruit, les accidents, et comme
moyen de réduire la vitesse).

Une exception connue en France est le rond-point de l'étoile en haut des
Champs-Elysée: un "rond-point" peut être mais pas du tout un "giratoire"
car avec des arrêts imposés au milieu de la boucle ou pour en sortir et des
restrictions pour les changements de voies et des voies réservés sur
certaines sections. Paris fait même figure d'exception en France parmi les
villes qui gardent encore des feux de circulation un peut partout (et qui
pourtant congestionnent la circulation et entraîne beaucoup de bruit et
pollution: la mairie de Paris ne fait rien pour changer ça sans doute à
cause du coût pharaonique que représenterait les acquisitions de terrains
pour aménager les ronds-points; elle préfère fermer des voies à la
circulation auto pour les réserver aux cyclistes, piétons et bus (mais
encore avec des feux, donc les accidents ne baissent pas et pas vraiment
non plus le bruit et la pollution qui sont seulement déplacés en concentrés
ailleurs avec encore plus de congestion). Paris est encore géré comme on le
faisait dans les années 1960-1970 quand la voiture était reine, le
carburant pas cher, et on ne se souciait pas trop d'environnement (et Paris
a toujours été bruyante et très polluée depuis des siècles).

Mais Paris refuse de regarder ce qui se fait dans d'autres grandes agglos
(même Lyon, Marseille, ou d'autres capitales à densité comparable comme
Londres, Bruxelles, Madrid, Rome, Milan) et vit encore dans l'illusion de
la "ville-lumière" des siècles passés (elle se donne juste des excuses avec
quelques "voies vertes" et son réseau cyclable est très mal fichu et pas
protégé du tout, c'est encore la ville des conducteurs de carosses qui
s'engueulent à chaque carrefour entre eux et avec les piétons, en guise de
façon de régler les priorités). Pourtant de nombreux carrefours à Paris
pourraient devenir des giratoires sans nécessiter d'acquisition de terrains

Notez

Re: [OSM-talk-fr] [VélOSM] Rond point et relations routes

> Découper un rond point est malheureusement parfois nécessaire  :
> l'aménageur a fait une bande cyclable en double sens sur une partie seulement 
> du rond point...

C'est un cas particulier, une exception à la règle ?
Il pourrait-être contourné en ajoutant un arc de cercle avec les tags 
appropriés ?

En pratique cet aménagement ne se voit pas encore sur les photos : je suis 
curieux de voir ça.


> Je crois que le problème est plus général avec les routes

Ce n'est pas gênant car JOSM met à jour la relation.

Pour les "giratoires", l'éditeur de relations de JOSM n'affiche plus ça comme 
un giratoire…
On arrive à recouper plein de fois un rond point avec beaucoup de sorties… pour 
rien (le calculateur d'itinéraire sait comment circuler dedans)

Quand le giratoire contient beaucoup de relations ça devient vite l'enfer :
Je vous invite à réparer les lignes de bus d'Annecy.

Un moyen d'éviter ces prises de tête avec les itinéraire serait ne ne pas le 
décrire par les segments de voies, mais par des points clés :
On indiquerait ±précisément les endroits où tourner, et un calculateur 
d'itinéraire ferait le reste.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] No U-turn vs BRouter

TL;DR: overtaking=no

Le 01/09/2020 à 12:35, Francois Gouget - fgou...@free.fr a écrit :

On Sun, 30 Aug 2020, Francois Gouget wrote:
[...]

Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
demi-tour là où les deux voies se rejoignent. Cela me parait très
superflu.

En fait les restrictions ne sont pas totalement superflues :
https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard&lonlats=-1.156756,45.785759;-1.158315,45.785505&profile=car-eco

Si superflues car fausses (mauvais tag).

Je pensais que BRouter prenait en compte ce genre de connection aux
rond-points. Cela dit je comprends tout à fait que ce ne soit pas le
cas: trop d'exceptions à coder à la main. Et puis le cas où le point de
départ est en sens unique en sortie de rond-point ne doit pas se
produire souvent.

Je ne suis tout de même pas sûr que ces restrictions soient justifiées :
* Doit-on mettre une interdiction de faire demi-tour à chaque fois qu'il
y a une ligne blanche ?

Non, non et non, une ligne blanche c'est overtaking=no (interdiction de
doubler/passer sur l'autre voie).

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
en sortie de rond-point. Mais s'il y a une ligne discontinue cela
serait-il vraiment interdit ?

Non, si la ligne est discontinue tu as le droit (enfin là tu es sur une
départementale).

Mais tu ne dois pas le faire (en cas d'accident tu auras tort) car du
fait du giratoire, tu ne peux voir assez les véhicules venant de l'arrière.

Sur Paris c'est interdit

sauf à un carrefour (mais OSM ne connaît cette règle).

* Ni la page du wiki sur les rond-points, ni celle sur les relations
restriction ne parlent de ce cas. La version anglaise de la page sur
les rond-points montre un exemple assez complet mais n'indique pas de
mettre des no-left-turn sur leurs sorties.

https://wiki.openstreetmap.org/w/images/2/2f/Roundabout-tagging.png

Donc il ne semble pas y avoir de règle établie dans un sens ou dans
l'autre.

Du coup que faire ?

overtaking=no s'il y a une ligne continue.

Ce n'est pas spécifique aux ronds-points. A mettre le cas échéant sur
les voies d'accès. Tu peux le préciser sur le wiki si tu veux.

Mon plan serait de :
* Supprimer les no_u_turn sur la voie qui mène à la paire de sens
uniques car elles sont fausses : à partir du moment où il n'y a pas de
ligne blanche on peut faire demi-tour. En l'absence de photo il
faudrait peut-être quand me vérifier qu'il n'y a pas de panneau
interdisant de faire demi-tour.
https://www.openstreetmap.org/relation/7488796

Oui

* Supprimer les restrictions no_u_turn lorsqu'il n'y a qu'une voie qui
mène au rond-point (au lieu d'une paire de sens uniques) car elles
cassent le routage et sont fausses.
https://www.openstreetmap.org/relation/7488797

Oui

* Corriger les autres restrictions incorrectes. Par exemple :
https://www.openstreetmap.org/relation/7347721

Oui, c'est à dire les remplacer par overtaking=no.

* Ne pas mettre de restriction lorsque je crée des rond-points.

Alors certains vont dire que je me répète : le problème figure en
méta-données du changeset :

created_by iD 2.3.2

Car iD incite à ajouter de telles relations.

Et les personnes en toute bonne foi se mettent à décrire (mal) une
interdiction qui est portée non par le giratoire mais par la ligne blanche.

Et tant qu'à corriger tu peux signaler le problème au créateur de la
relation.

Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes


Tu veux parler de giratoires ? ;-)

Je crois que le problème est plus général avec les routes : on n'arrête
pas de les couper pour des limites de vitesse, stationnement, files...

C'est qu'il manque un niveau d'information : la rue, le giratoire, à
distinguer du segment de route.

Pour la rue on a associatedStreet. Mais pour le rendu on utilise le nom
de chaque segment avec n fois Rue Tartempion sur la carte.

Et le découpage des giratoires est fait en fonction des trajets de bus,
pas des segments (si deux routes se croise et que le bus route, on va
avoir un segment d'un côté et trois de l'autre).

On pourrait ici avoir 4 segments dans une relation round-about.

Ce serait propre et utilisable si les outils le supportaient.

Je crains qu'il vaille mieux s'en tenir à l'existant.

Usuellement je ne découpe que si le reste du trajet de bus les
giratoires sont découpés.

Jean-Yvon

Le 01/09/2020 à 11:24, Yves P. - yves.prat...@gmail.com a écrit :

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 😁

__
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] anomalie du serveur OSM sur iD (données partielles/incomplètes)

oui ça remarche ce midi, hier soir l'internet était un enfer à naviguer.
(sauf les sites Google, et le reste était extrèmmeent lent, surtout le DNS
et presque tout ce qui transitait par les gros datacenters d'Amsterdam)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Projet du mois : Près d’un tiers des défibrillateurs ne seraient pas opérationnels en France !

Alors qu’une loi oblige depuis le 1er janvier les établissements recevant du 
public à s’équiper de défibrillateurs automatiques externes, 20 à 30% des 
machines déjà installées en France ne seraient pas en état de marche en raison 
d’un défaut de maintenance.

https://www.capital.fr/economie-politique/pres-dun-tiers-des-defibrillateurs-ne-seraient-pas-operationnels-en-france-1360334

__
Yves



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] No U-turn vs BRouter

2020-09-01 Par sujet Francois Gouget

On Sun, 30 Aug 2020, Francois Gouget wrote:
[...]
> Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
> demi-tour là où les deux voies se rejoignent. Cela me parait très
> superflu.

En fait les restrictions ne sont pas totalement superflues :
https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard&lonlats=-1.156756,45.785759;-1.158315,45.785505&profile=car-eco

Je ne suis tout de même pas sûr que ces restrictions soient justifiées :
* Doit-on mettre une interdiction de faire demi-tour à chaque fois qu'il
y a une ligne blanche ?

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
en sortie de rond-point. Mais s'il y a une ligne discontinue cela
serait-il vraiment interdit ?

https://wiki.openstreetmap.org/w/images/2/2f/Roundabout-tagging.png

Donc il ne semble pas y avoir de règle établie dans un sens ou dans
l'autre.

Du coup que faire ?

* Corriger les autres restrictions incorrectes. Par exemple :
https://www.openstreetmap.org/relation/7347721

* Ne pas mettre de restriction lorsque je crée des rond-points.

--
Francois Gouget http://fgouget.free.fr/
If it stinks, it's chemistry. If it moves, it's biology.
If it does not work, it's computer science.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-01 Par sujet Christian Rogel


> Le 1 sept. 2020 à 11:25, Yves P.  a écrit :
> Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.
> 
> Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
> Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
> ingérable !
> 
> S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
> Merci pour lui et son intégrité 😁


Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour agir 
ainsi, soit appartenir à la team 1er degré, soit être certain que le RP est 
positionné correctement. Et surtout au bon diamètre.
Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les autres 
contributeurs, laissé dans l’état normal.

Christian R.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rond point et relations routes

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 😁

__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Par sujet Jacques Lavignotte




Le 01/09/2020 à 11:01, Christian Quest a écrit :

Je ne sais pas quel usage
tu en faisais, si il correspondait à son but initial et à quel point 
c'est bloquant.


Bonjour Christian,

Mon usage du machin-aux-points-colorés :

Au hasard de mes errances Osmosiennes je profite de la portion de carte 
téléchargé dans JOSM à ce moment là pour monter les points colorés du 
rendu BANO et numéroter la/les rue/s.


Ma demande - très personnelle (?) - le retour du confort du contributeur 
très lambda ( ou même 'oméga' )


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Par sujet Christian Quest


Le 01/09/2020 à 10:26, Jacques Lavignotte a écrit :
Je crois que je n'appréhende pas tous les aspects du orojet BAN0 que 
je ressens comme important, la preuve étant l'effervescence actuelle 
sur le sujet. 



Voici de quoi clarifier...

A la base, l'objectif de BANO est de fournir une base d'adresses la plus 
complète possible sous licence ODbL, car à l'époque (2014) rien de tel 
n'existait.


Pour ça, dès le départ, plusieurs sources sont mixées:

- les adresses déjà présentes dans OSM

- les adresses que les collectivités ont mis en opendata

- les adresses extraites du cadastre par des scripts qui s'appuient sur 
les PDF téléchargeables sur cadastre.gouv.fr


C'est ça le coeur de BANO.


A partir de ça, on a pu établir la liste des noms de rues manquants dans 
OSM ainsi que les adresses manquantes et plusieurs outils périphériques 
ont donc été développés pour accompagner les contributions sur cette 
thématique:


- ceux qui permettent d'avoir un suivi statistique,

- ceux qui permettent de rentrer dans le détail commune par commune sur 
le rapprochement FANTOIR (pour compléter les noms de rues et lieux-dits 
dans OSM)


- ceux qui permettent de préparer des points d'adresses pour les 
intégrer dans OSM,


- et le rendu qui permet de montrer là où il y a des améliorations 
possibles dans OSM (le rouge à dégommer pour déjà compléter les noms de 
rues).



Pour la partie "utilisation" des données, j'ai aussi mis en place 
différents géocodeurs sur bano.addok.xyz ou demo.addok.xyz qui 
permettent d'utiliser les données de BANO.


Ceci s'est dans un esprit "d'escalier"... on créer la base, qui du coup 
permet de détecter certains manques, qui du coup nous pousse à mettre en 
place un outil pour faciliter leur comblement, etc, etc. Au final, cela 
fait tout un engrenage avec de multiples ramifications.


La partie constituant la base a été largement refondue, ainsi que la 
majorité des outils, mais pas encore le rendu. Je ne sais pas quel usage 
tu en faisais, si il correspondait à son but initial et à quel point 
c'est bloquant.


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Par sujet Jacques Lavignotte




Le 31/08/2020 à 22:40, Vincent de Château-Thierry a écrit :

Bonjour,


>
> Pour essayer de répondre aux débats, remarques et suggestions :



De: "Yves P." 



> au moins on peut essayer d'avoir un avancement minimum.


Le 28/08/2020 à 19:08, Jacques Lavignotte a écrit :
>
>


Merci aux uns et aux autres, chacun à leur manière de participer au débat.


Je crois que je n'appréhende pas tous les aspects du orojet BAN0 que je 
ressens comme important, la preuve étant l'effervescence actuelle sur le 
sujet.


Me concernant je recentre ma/mes demande/s résumé ici :

> Le 28/08/2020 à 18:44, Vincent de Château-Thierry a écrit :
>
>> Je suppose que tu parle du rendu carto de BANO, les points colorés et
>> les zones rouges à dégommer. Si c'est ça, en effet c'est en panne.
>
> Pour moi comme pour quelques autres (je l'ai déjà dit) les points
> colorés c'était ma seule utilisation de BANO.

Je soutiens l'appel de Jérôme - maintenant inscrit à l'ODJ du prochain 
CA - et souhaite - très égoistement -  son aboutissement prochain au 
moins sur « les points colorés ».


Bonne journée,  Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-01 Par sujet Christian Quest


Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :

Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
Bien souvent dans mes contributions, je remet des POI en surfacique 
alors qu'ils ne sont que ponctuels, la première étape consistant 
souvent à migrer un tag sur un bâtiment entier, mais la seconde, 
quand on le peut, consiste à délimiter plus largement l'emprise de 
tel ou tel POI. Cas typique: les écoles !


J'allais dire ouille.

Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.


Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)

Attention aussi à la traduction simpliste qu'on a fait de POI, non ?

Réduire un POI à un unique point est quand même une façon minimaliste de 
décrire un lieu rarement ponctuel sur le terrain. J'ai toujours 
considéré qu'un ponctuel c'était bien pour apporter une info minimale, 
mais qu'une surface apporte bien plus d'infos (où commence le POI, où 
s'arrête-t-il, est-il étendu ou pas, etc).



Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?

Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le 
ponctuel à part de façon arbitraire ?



Ceci dit souvent quand le PI est surfacique des cartographes (avec 
StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli 
ne montre que les PI ponctuels :-(.


Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers 
le centroid, éventuellement son emprise aura un style surfacique en 
plus. Le nom doit être placé quelque part, il est donc ponctuel lui 
aussi mais déterminé à partir de l'emprise.



La seule solution propre compatible avec les deux mais lourdingue pour 
les petits objets c'est de faire une relation type=boundary avec le 
nœud comme label et le contour en outer comme ici 
.


Bof bof bof... que de complexité pour un usage quasi nul des rôles 
label, d'autant plus que remonter dans les relations est un exercice 
délicat pour les moteurs de rendu.


Dans ce cas précis, je ne trouve pas que la position pour ce label soit 
bien choisie. Elle est trop proche de la route, donc collision avec le 
nom de celle-ci (identique d'ailleurs).



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)