from:"Charles MILLET"


Je suis bien d'accord avec ça et le principe des exceptions.

Et donc tu utilises les forward/backward comme le dis Marc M. Moi c'est 
ce que je fais mais je n'ai jamais été très  sûr de moi ;)


Après JOSM ne le prend pas bien en compte et il n'y a pas de méthode 
claire sur l'ordre que doivent avoir les backward, leur position dans la 
liste des autres membres (forward par défaut) et sûrement d'autres 
choses. Tu as des pratiques ?


Charles

On 31/05/2020 14:27, Axel Listes wrote:

Bonjour,

Le 31/05/2020 à 13:53, Baptiste Jonglez a écrit :

En tout cas ça me paraît beaucoup plus simple que de faire une relation
aller et une relation retour, ce qui obligerait à dupliquer la majorité du
trajet dans les deux relations (ou alors j'ai mal compris).


Disons que les besoins ne sont pas les même que pour d'autres types de
transports, notamment les TEC qui doivent respectent un sens spécifique
concernant les arrêts.

En ce qui concerne les itinéraires cyclables, pour ma part je considère
qu’introduire les deux sens dans une unique relation suffit largement.
Les départager n'ajoute que de la complexité à la maintenance, ce dont
je sais à quoi je fais référence puisque je "maintiens" régulièrement
des Véloroutes nationales qui passent dans la région ou je vis.

Après on peut éventuellement faire des exceptions pour certains
itinéraires urbains, car il est vrai que les deux sens sont très souvent
départagés sur la majorité du parcours.

Axel.



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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM


Oui clairement, il faut bosser à la main l'essentiel du temps ;)

On 31/05/2020 20:45, Yves P. wrote:
Euh, ouais, non, deux relations c'est deux fois plus de travail, déjà 
que la maintenance n'est pas facile.

Avec la bonne méthode, une relation c'est mieux :)

Puis perso, je m'embête rarement à ordonner les chemins (c'est un 
travail d'ordinateur ça :).
Je me sert du bouton du bouton trier les membres, mais dans ce cas ça 
ne fonctionnait pas (relation trop cassée).
J'ai refais un essais, le tri fonctionne bien jusqu'à la fin de la 
première intersection Aller/retour, ensuite il faut aider JOSM.


__
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] Désaccord sur un highway=footway

Mini hors sujet... tu penses qu'on ne devrait pas utiliser le permissive 
en dehors de cette définition ? J'ai eu tendance à le faire pour me 
sortir de situations et j'ai l'impression que je ne suis pas le seul.


On 01/06/2020 23:02, Florimond Berthoux wrote:

Perdu, permissive ne veut pas dire toléré (illégal mais autorisé)
« permissive : Open to general traffic until such time as the owner 
revokes the permission which they are legally allowed to do at any 
time in the future. »
C'est un truc d'abord anglais où le propriétaire autorise l'accès 
public (et l'affiche) mais peut le fermer à tout moment.
Voir 
https://en.wikipedia.org/wiki/Rights_of_way_in_England_and_Wales#Permissive_path


Je ne dirais pas que ça n'existe pas en France, mais ça me semble très 
rare.


Le lun. 1 juin 2020 à 22:32, > a écrit :


/J'avais l'impression que les pistes cyclables à Paris ça servait
aussi aux voitures comme place de parking :-(. Ah, non seulement
les bandes !
/

Donc si on revient sur le coin d'où on est parti :

- y a-t-il un panneau autorisant les cycles ? Non
- y a-t-il un panneau interdisant les cycles ? Non

De partout on arrive sur ce qui ressemble soit à un trottoir soit
à une place piétonne.

Dans le premier cas bicycle=no (implicite, c'est un footway).

Dans le second cas bicycle=yes (implicite c'est un pedestrian).

Et comme c'est pas clair on met bicycle=permissive : pas fait pour
mais personne ne dit rien.

J'ai l'impression d'avoir suivi ta logique et j'aboutis à une
solution qui semblait convenir aussi à Eric.

Le 01/06/2020 à 21:19, Florimond Berthoux -
florimond.berth...@gmail.com 
a écrit :

Non, il n'y a pas de panneau "motocycle autorisé" donc tu ne tag
que highway=cycleway, de la même manière qu'il faut un panneau
"piéton interdit" pour tagguer foot=no sur un cycleway.
Et de plus tu verras aussi que les deux roues motorisés qui
roulent dessus se font verbaliser.
On tag la piste cyclable pas son interprétation légal.

___
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] Désaccord sur un highway=footway


Pas mal de démonstration par l'absurde globalement comme argument.

mes 2 centimes :

On tague la réglementation/loi tout ce que vous voulez d'un peu officiel 
quand elle n'est pas ambiguë et pas en contradiction avec le terrain.


On débat quand ce n'est pas le cas :)

Là je trouve que la situation est ambiguë et qu'une 
application/interprétation ou autre des textes ne permettent pas de 
trancher. Pour ma part je serais favorable à highway=footway + 
bicycle=yes/permissive + segregated=no + note="en débat :)"


Après j'ai tellement souvent eu tort dans mes choix ;)

On 01/06/2020 20:21, Stéphane Péneau wrote:

Le 01/06/2020 à 10:57, Florimond Berthoux a écrit :

C'est TON interprétation de la loi et j'en ai strictement rien à faire.
Car on ne tag pas la loi, on ne map pas avec le code de la route dans 
la main gauche et la souris dans la main droite.
Sinon il arrive ce qu'il arrive dans cette suite de mail un conflit 
d'interprétation que seul un juge peut régler, et c'est tout à fait 
hors de propos d'OSM.


Le terrain, rien que le terrain, seulement le terrain.

Hmmm, on est tout de même un peu obligé de se référer au code de la 
route.


Démonstration par l'absurde:

Je vais faire un tour à Paris, je me promène 5mn dans les rues pour 
regarder ce qui circule sur les pistes/bandes cyclables.


Qu'est-ce que je fais lorsque je rentre chez moi ? J'ouvre Josm, et 
ajoute moped=yes + motorcycle=yes sur tous les cycleways...


Tu es ok avec ça ?

Stf


___
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] aménagements cyclables et piétons temporaires

2020-05-18 Per discussione Charles MILLET

J'ai complété le Wiki dans ce sens car j'ai eu pas mal de retour de 
personnes qui avait interprété "piste cyclable temporaire" comme la 
valeur imposée. N'hésitez pas si vous avez des commentaires :)


Charles

On 23/04/2020 13:26, Florimond Berthoux wrote:


description est un tag à valeur libre, pour écrire du texte, ce que 
vous voulais, donc oui vous pouvez mettre "voie bus temporairement 
ouverte" ou "mise en sens unique et double sens cyclable temporaire" etc.

L’important pour moi en ordre de priorité :
1. tagguer le nouvel aménagement
2. préserver l’ancien aménagement avec was:*=*
3. ajouter le tag description:covid19=* pour retrouver les 
aménagements temporaires.


Le jeu. 23 avr. 2020 à 11:39, Laurence P > a écrit :


Bonjour,

oui cela peut concerner aussi des "bandes" temporaires pour
*piétons*, des élargissements de trottoir en prenant de la largeur
de chaussée, des zones de rencontre temporaires, mise en aire
piétonne etc

Cela peut donc impacter aussi la *circulation automobile *(si une
zone de rencontre est transformée en aire piétonne, si une rue est
mise en sens unique alors qu'elle était à double-sens, si une rue
est coupée sur une toute petite portion pour supprimer le trafic
de transit...). Ce ne sont que des hypothèses car ce sont des
mises en place plus complexes pour les collectivités puisque ça
change leur plan de circulation, mais ce n'est pas exclu.

peut-être qu'il faut donc utiliser un terme plus générique :
description:covid19= aménagement temporaire ?

Ce qui a aussi été évoqué hier pendant le webinaire, c'est du
*stationnement vélo événementiel* (donc mobile) qui pourrait être
implanté devant poles générateurs de déplacement et ajusté selon
la demande.

Cordialement,

Laurence

Le 23/04/2020 à 10:58, Axel Listes a écrit :

Bonjour,

Le 23/04/2020 à 10:28, Florimond Berthoux a écrit :

J’ai déjà réfléchi au problème le plus simple pour moi et de mettre la
donnée dans OSM comme n’importe qu’elle autre piste/bande cyclable.
Voir la doc

https://wiki.openstreetmap.org/wiki/France/Covid-19#Coronapiste_:_piste_cyclable_provisoire

Sujet intéressant et merci d'y avoir déjà travaillé, lorsque je regarde
le wiki je me pose une question concernant ce passage


Pour préciser l'information d'une piste temporaire utiliser :
description:covid19=piste cyclable temporaire

Est-ce un abus de langage, c'est-à-dire concerne tous les aménagements
provisoires, ou est-ce vraiment spécifique aux pistes cyclables ?

Car précisé juste dessus, les voies de bus temporairement ouverts aux
cycles ne sont pas des pistes cyclables.

Cela me parait très important de baliser TOUS les aménagements avec une
clef-valeur spécifique, pour ne pas "polluer" sur certains secteurs de
la cartographie, les données déjà très précises.

S'il s'agit d'un abus de langage, je corrigerais (ou faites si vous
voulez) le wiki pour bien préciser. Si non, c'est un problème !

Axel.

-- 
Laurence


___
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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-13 Per discussione Charles MILLET


Salut Thomas,

J'ai vu cet échange en effet. Mygeomatic est mon compte perso et j'avoue 
que déjà à cette époque je n'en pouvais plus de lui. Ces messages privés 
sont hyper pénibles, il s'en sert juste pour balancer tout un tas de 
trucs nuls ; je ne sais pas si tu as échangé avec lui en directe 
également. J'ai fait un signalement au DWG hier et j’attends leur retour 
pour faire un revert. Il m'a également signalé au DWG malheureusement et 
il semble critiquer le fait qu'à Carto’Cité nous contribuions dans un « 
cadre professionnel ». Je vais essayer également de perdre moins 
d'énergie avec ce type parce qu'il a réussi depuis plus de 2 ans 
maintenant à me faire perdre beaucoup de temps et c'est clairement son 
intention.


Bonne journée.

Charles MILLET
charlesmil...@free.fr

On 12/02/2020 23:41, Thomas Ruchin wrote:
Voici un des échanges que j'avais eu voici quelques mois avec ce 
contributeur :

https://www.openstreetmap.org/changeset/62907425
C'est dommage de perdre tant d'énergie, et plutôt désagréable de le 
croiser sur sa route.


Thomas


Le mercredi 12 février 2020, Stéphane Péneau 
mailto:stephane.pen...@wanadoo.fr>> a écrit :


Le 12/02/2020 à 13:31, Charles MILLET a écrit :


Je ne suis pas à l'aise avec l'idée de faire un
signalement au DWG car en dehos de ce genre de
comportement, ses contributions sont bonnes. Pensez-vous
qu'il faille le faire ?



Oui, mais j'ai un point de vue biaisé puisque partie prenante.

Stf


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


___
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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Per discussione Charles MILLET


Pardon, mauvais lien, voilà le bon :

https://www.openstreetmap.org/changeset/80853048

On 12/02/2020 13:24, Charles MILLET wrote:

Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était 
en question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a 
déjà été discuté avec lui pour des pratique identique à Caen et je 
suppose qu'il le fait malheureusement régulièrement. Je suis à la 
recherche des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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


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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Per discussione Charles MILLET


Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était en 
question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà 
été discuté avec lui pour des pratique identique à Caen et je suppose 
qu'il le fait malheureusement régulièrement. Je suis à la recherche 
des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-08 Per discussione Charles MILLET

Merci pour les conseils :)

On 07/02/2020 22:17, Jérôme Seigneuret wrote:

Dans ton cas de toute-façon il y a une signalisation verticale...
Ca reste de la dégradation sans justification.
Après discussion propose lui déjà de faire un revert de son changeset
en mettant les liens et notre discussion mail.

Si c'est pas fait tu le fais et si des modifications reviennent sans
justification tu pourras ouvrir une demande de gestion des conflits
auprès du DWG https://wiki.openstreetmap.org/wiki/Disputes

Le ven. 7 févr. 2020 à 21:29, Charles MILLET <mailto:charlesmil...@free.fr>> a écrit :

Merci Florimond pour ton retour. Il y a bien une ligne de
séparation qui est déjà bien effacée.

En fait je craque avec ce contributeur, il efface très
régulièrement des trucs juste parce que ça lui plaît pas et pas
mal de piste cyclables que des débutants OSM prennent le temps de
mapper pour les remplacer par du track même quand c'est même plus
justifiable pour du routage.

On 07/02/2020 20:30, Florimond Berthoux wrote:

Salut,

Merci pour le lien mapillary,

highway=path
bicycle=designated
foot=designated
seggregated=? (j'ai l'impression qu'il y a une ligne de démarcation)

sur le way de la route tu peux ajouter
bicycle=use_sidepath

cycleway:right=track me semble peu pertinent ici étant donné que
piétons et cyclistes sont mélangés sur la même chaussée.

Des fois c'est peut-être plus simple d'attendre et de changer
sans discuter.. ;)

Le ven. 7 févr. 2020 à 16:12, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>> a écrit :

https://www.mapillary.com/map/im/ZF99wjAm9RtiGhd-LmrDMw

https://www.openstreetmap.org/way/753746024

Après mettre highway=footway + bicycle=designated ou
highway=cycleway + foot=designated ... pour moi c'est du
débat idéologique. Ca reste de base un trottoir donc fait
pour les piétons avec une obligation pour les vélos d'y
circuler...
Au niveau exploitation des données d'y voit pas de différence.

Le ven. 7 févr. 2020 à 16:04, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>> a écrit :

marc il y a un lien mapilary

Pour moi c'est bien un Cycleway séparé de la voie sur un
trottoir avec accès piéton et ségrégation clairement
affiché sur panneau.
Il faut mettre une la voie routière cycleway=use_sidepath
car c'est une obligation de circuler sur le trottoir

Bonne journée

Le ven. 7 févr. 2020 à 16:02, marc marc
mailto:marc_marc_...@hotmail.com>> a écrit :

Le 07.02.20 à 15:49, Charles MILLET a écrit :
> Pour info cette "piste cyclable" est utilisable par
les piétons et donc
> nécessite un way séparé et la précision du
segregated=yes

il y a une erreur dans l'argument ?
photo classique récente du lieu ou uniquement vue sat ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr

--
Cordialement,

Jérôme Seigneuret

--
Cordialement,

Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr

--
Florimond Berthoux

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

--
Cordialement,
Jérôme Seigneuret

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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-07 Per discussione Charles MILLET

Merci Florimond pour ton retour. Il y a bien une ligne de séparation qui 
est déjà bien effacée.

En fait je craque avec ce contributeur, il efface très régulièrement des 
trucs juste parce que ça lui plaît pas et pas mal de piste cyclables que 
des débutants OSM prennent le temps de mapper pour les remplacer par du 
track même quand c'est même plus justifiable pour du routage.

On 07/02/2020 20:30, Florimond Berthoux wrote:

Salut,

Merci pour le lien mapillary,

highway=path
bicycle=designated
foot=designated
seggregated=? (j'ai l'impression qu'il y a une ligne de démarcation)

sur le way de la route tu peux ajouter
bicycle=use_sidepath

cycleway:right=track me semble peu pertinent ici étant donné que 
piétons et cyclistes sont mélangés sur la même chaussée.

Des fois c'est peut-être plus simple d'attendre et de changer sans 
discuter.. ;)

Le ven. 7 févr. 2020 à 16:12, Jérôme Seigneuret 
mailto:jerome.seigneu...@gmail.com>> a 
écrit :

https://www.mapillary.com/map/im/ZF99wjAm9RtiGhd-LmrDMw

https://www.openstreetmap.org/way/753746024

Après mettre highway=footway + bicycle=designated ou
highway=cycleway + foot=designated ... pour moi c'est du débat
idéologique. Ca reste de base un trottoir donc fait pour les
piétons avec une obligation pour les vélos d'y circuler...
Au niveau exploitation des données d'y voit pas de différence.

Le ven. 7 févr. 2020 à 16:04, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>>
a écrit :

marc il y a un lien mapilary

Pour moi c'est bien un Cycleway séparé de la voie sur un
trottoir avec accès piéton et ségrégation clairement affiché
sur panneau.
Il faut mettre une la voie routière cycleway=use_sidepath car
c'est une obligation de circuler sur le trottoir

Bonne journée

Le ven. 7 févr. 2020 à 16:02, marc marc
mailto:marc_marc_...@hotmail.com>>
a écrit :

Le 07.02.20 à 15:49, Charles MILLET a écrit :
> Pour info cette "piste cyclable" est utilisable par les
piétons et donc
> nécessite un way séparé et la précision du segregated=yes

il y a une erreur dans l'argument ?
photo classique récente du lieu ou uniquement vue sat ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Cordialement,

Jérôme Seigneuret

-- 
Cordialement,

Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto: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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-07 Per discussione Charles MILLET

En gros si on regarde ça 
(http://resultmaps.neis-one.org/osm-discussion-comments?uid=412560) on 
voit qu'il ne répond qu'une fois sur 2. Et qu'il a bien eu cette 
pratique de supprimer les cycleway pour les remplacer par des track.


Ce changeset (https://www.openstreetmap.org/changeset/65441162) par 
exemple est truffé de piste supprimées.



On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà 
été discuté avec lui pour des pratique identique à Caen et je suppose 
qu'il le fait malheureusement régulièrement. Je suis à la recherche 
des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-07 Per discussione Charles MILLET


Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais ce 
n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà été 
discuté avec lui pour des pratique identique à Caen et je suppose qu'il 
le fait malheureusement régulièrement. Je suis à la recherche des 
discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et donc 
nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause de 
son ton ultra arrogant et différents reproches totalement délirant.


Charles


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

Re: [OSM-talk-fr] [Vélo] Comment cartographier une station Velib’ divisée en 2 parties

2019-04-07 Per discussione Charles MILLET

Merci pour vos retours, je vais continuer d'observer ce qui se fait. 
Pour information j'envisage d'organiser un petit mapathon pour 
l'intégration des bornes Vélib’, probablement le 23 avril de 19h à 23h 
sur Paris (je ne sais pas encore où).


@marc marc : désolé pour le manque de localisation, effectivement 
j'avais zappé d'ajouté le lien ;-)


Charles MILLET
charlesmil...@free.fr

On 04/04/2019 16:28, marc marc wrote:

[à propose d'une station en 2 parties avec 2 fois la ref dans osm]
Phys : un des gros défaut c'est que cela conduit à avoir une double ref
et c'est compliqué pour un contributeur ou un outil de qualité de savoir
au préalable si c'est une erreur à aller corriger ou si c'est "normal".
il faut regarder si les 2 objets sont semblable et proche pour déduire
que c'est peut-être normal... et encore rien ne dit que c'est pas la
station qui a été créé en doublon suite à un légèr déplacement par ex

Le 04.04.19 à 15:20, Thomas Ruchin a écrit :

- les bornettes d’arroches sont à modéliser par un/des ways ou polygones
avec les tags adaptés et rattachés à la station via son identifiant.

un exemple dans osm ?
___
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] [Vélo] Comment cartographier une station Velib’ divisée en 2 parties

2019-04-03 Per discussione Charles MILLET


Bonjour,

Est-ce que vous savez si il y a une pratique pour cartographier une 
station Velib’ qui est divisée en 2 parties comme ici par exemple, au 
carrefour de la Rue Jacquard et la Rue Ternaux (à observer avec la photo 
aérienne) ?


Pour l'instant j'ai placé le point sur une seule des 2 partie.

Bonne journée.

--
Charles


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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

2019-03-19 Per discussione Charles MILLET


J'ai vu cette remarque aussi mais merci de la faire remonter ici.

Je suis un peu partagé parce que j'ai déjà vu des cas où le 
opposite_lane était adapté et compréhensible même pour une route que 
n'est pas à sens unique ...bon il s'agissait peut-être d'un 
opposite_track mais je trouve que les différents « opposite » (si ils 
survivent à ces débats) devraient pouvoir suivre une même logique.


J'ai un peu arrêté d'avoir une opinion ferme sur ces sujets, je crois 
qu'il y a globalement une bonne approche dans les différents schémas... 
mais bref je cherche surtout à identifier la solution qui fait le plus 
consensus et qui ne soit pas poussée par la personne qui râle le plus 
fort même si la solution qu'elle présente est très bonne.


Charles MILLET
charlesmil...@free.fr

On 19/03/2019 11:10, marc marc wrote:

Le mer. 13 mars 2019 à 22:11, Charles MILLET


dans la pratique le opposite_lane est bien utilisé et parfaitement 
interprétable.

sur la ml tagging, une des critiques est que qui dit opposite_lane (les
vélos sont permis sur une bande dans le sens opposé au traffic),
dit que la route (pour les non-vélo) est en sens unique.
hors 6% de ces way n'ont pas le tag sens-unique.
pour couper l'herbe sous le pied de cette critique un peu légère (on ne
change pas de schéma parce qu'il y a qlq erreurs humaines) et améliorer
les données, Markus propose de les passer en revenue et de les corriger
(soit la rue n'est plus en sens unique et opposite_lane devient sans
doute lane, soit ajouter le tag manquant sens unique)
181 pour la France http://overpass-turbo.eu/s/H9e
___
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] améliorer les panneaux entrée et sortie de ville

2019-03-18 Per discussione Charles MILLET

Je crois qu'il n'y a pas que les langues puisqu'il y a aussi :left/right 
et je pense d'autres name space qui ne sont pas des langues.


Ok pour le principe de garder name pour la ville dans laquelle on entre.

Charles

On 18/03/2019 16:59, marc marc wrote:

Le 18.03.19 à 16:05, Charles MILLET a écrit :

il me semble qu'il n'y a pas d’ambiguïté donc des name:* devraient être bon.

Pourtant name:abc est "name" dans la langue "abc" (ex name:fr name:de)
Dans les zones multilingue, un panneau est parfois multilingue dont
multiple name. et un name:abc qui ne se rapport pas à un langue entre en
conflit avec cette logique bien établie.
Je n'ai tjs pas saisis l'intérêt, mais si on veux vraiment renseigner
le nom de la ville qu'on quitte lorsqu'on rentre dans une autre,
*:name me semble préférable pour éviter cet ambiguïté.

Et si on veux garder des données utilisable par une majorité d'app,
j'aurais gardé la ville entrante dans name tout simplement.
Au moins les utilisations des données qui ignorent cet "extension"
pourront quand même utiliser l'info initiale.
___
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] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

2019-03-18 Per discussione Charles MILLET


Merci pour les échanges.

Suite aux échanges sur la liste tagging, il y a eu un revert de fait sur 
la page anglais mais pas sur la française (et éventuellement d'autres 
langues concernées ni les autres pages concernées par la modification 
initiale).


Est-ce que vous pensez qu'il vaut mieux faire aussi un revert maintenant 
sur la page FR pour éviter des problèmes de confits techniques ou s'il 
faut attendre que le sujet avance un peu ?


Bonne journée.

Charles

On 15/03/2019 16:42, Phyks wrote:

Salut,


En tant que structuraliste opposite_* est intolérable.

Il y a un certain nombre de cas comme ça d'ailleurs sur les attributs
vélos. J'ai en tête par exemple aussi le `bicycle_parking` dont la
variante `motorcycle_parking` n'existe pas. On se retrouve donc avec des
`amenity=motorcycle_parking` et `bicycle_parking=stands` qui ne sont
absolument pas ouverts ou prévus pour des vélos.



Dans tous les cas, aujourd'hui je ne ressens aucun besoin de changer le
schéma opposite_*

Idem, je vois un petit intérêt à utiliser l'alternative avec
`cycleway:*:oneway`, mais cela ne vaut probablement pas de casser tout
l'écosystème basé sur le schéma actuel à mon avis (déjà que tous les
outils ne supportent pas les cycleway:left/right proprement…).



Il y avait récemment eu une discussion sur des différences entre la
version anglaise et française de la page "Bicycle" du wiki il me semble
(sur talk-fr, sur un autre cas, mais je ne le retrouve plus :/).



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

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-18 Per discussione Charles MILLET

Plutôt que name:in et name:out je crois que name:exit et name:entrance 
seraient plus proche de ce que se fait déjà.


Bon j'avoue avec une gène non dissimulée que le name:entrance, nous* 
l'avions utilisé pour décrire les nommages multiples de destinations qui 
servent pour "nommer" les entrées/sorties des gares. Depuis on a 
identifier la relation destination_sign [1] qui serait a priori très 
adaptée pour lever tout un tas d’ambiguïtés avec la notion d'entrée et 
de sortie (sortie du métro et entrer de gare ou l'inverse, etc.).


Dans le cas des panneaux d'entre de ville, il me semble qu'il n'y a pas 
d’ambiguïté donc des name:* devraient être bon.


Il me semblait que name:exit existait mais quand je vois le résultat de 
la requête overpass, je me rend compte que c'est aussi peut-être nous* 
qui l'avons introduit.


*nous c'est différents contributeurs qui ont travaillé sur les gares de 
la ligne C en fin d'année 2018.


[1] https://wiki.openstreetmap.org/wiki/FR:Relation:destination_sign

On 16/03/2019 14:16, djakk djakk wrote:

Salut !

« Direction » c’est l’angle du panneau par rapport au Nord c’est ça ?

Name:in et name:out, bonne idée !

Julien « djakk »



Le sam. 16 mars 2019 à 13:44, Francescu GAROBY > a écrit :


Bonjour,
D'où provient ce "name:2" ? C'est vous qui proposez ce nom de tag
? Je ne le trouve pas clair du tout !
Je préférerais "name:in" / "name:out", pour indiquer dans quelle
agglomération on entre/sort.
"Direction", c'est pour indiquer la référence de la route sur
laquelle on se trouve ? Pourquoi ne pas mettre plutôt le nom d'un
village/une ville un peu importante, et se trouvant dans ladite
direction ?

Francescu

Le ven. 15 mars 2019 à 17:46, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>>
a écrit :

Salut,

J'aimerai améliorer les affichage pour les panneaux d'entrée
et sortie de ville.


voici un cas  sur le même panneaux
direction=310
highway=traffic_sign
name:2=Jouy-en-Josas (sortie)
name=Les Loges-en-Josas (entrée)
traffic_sign=city_limit

merci

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Francescu

___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

Dans l'absolu sa proposition tient la route. C'est juste que c'est un 
peu lourd et que dans la pratique le opposite_lane est bien utilisé et 
parfaitement interprétable.


Et comme le dis marc c'est pas la bonne pratique, même quand on est 
convaincu qu'on a raison... parce qu'on est nombreux à être convaincu 
d'avoir raison :D


J'avais vu ta position sur la distinction entre le sens et l'infra et 
effectivement vous tombé plutôt d'accord. J'avais la même position il y 
a quelques années... et puis j'ai laissé tombé :) et en fait j'ai admis 
que la clé cycleway c'est qu'une clé et du moment qu'on est d'accord sur 
ce que signifient les tags qui l'utilisent et bien on peut renoncer un 
peu à cette logique. Donc vois si tu veux rester sur cette position mais 
dis toi que si elle n'est pas adoptée ça n'aura pas trop d'influence... 
on en reparle peut-être de vive voix bientôt ? ;)


Pour l'instant j'essaie de prendre un peu le pouls sur cette approche du 
DSC puisque les calculateurs ne l'utilisent pas je pense alors que les 
cycleway:left/right=opposite_* sont plutôt admis (il me semble qu'au 
moins BRouter et Geovelo les prennent en compte mais je pense que 
d'autres le font).


On 13/03/2019 21:14, Florimond Berthoux wrote:

Bonsoir,

Et par ici aussi 
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Acycleway%3Dopposite_lane=revision=1820887=1639352
mais pas ici 
https://wiki.openstreetmap.org/wiki/Key:cycleway#Dedicated_cycle_lanes
Je trouve la communauté particulièrement coulante vis-à-vis de ce 
genre de modification unipersonnelle.


Après je comprend tout à fait son point de vue : la signification d'un 
tag devrait être la plus simple possible et ne pas comporter deux 
significations comme avec opposite_lane (sens et infrastructure).



Le mer. 13 mars 2019 à 15:04, Charles MILLET <mailto:charlesmil...@free.fr>> a écrit :


Bonjour à tous

Un contributeur a mis à jour la page wiki concernant la manière de
décrire les doubles sens cyclables sur bande :


https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997

Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car
cette valeur n'est pas documentée dans les valeurs des clé
cycleway:left/richt (même si elle l'est pour la clé cycleway)

Il recommande donc :

highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1

plutôt que

highway=* + oneway=yes + cycleway:left=opposite_lane

:'(

Je lui ai envoyé un message pour lui exprimé avec politesse que je
pense
qu'il vaudrait mieux admettre ou officialiser
cycleway:left=opposite_lane mais je m'attend que ce type de
contribution
traduise une volonté de respecter rigoureusement le wiki...

Je m'adresse à la liste pour avoir votre avis au regard de l'usage
qu'on
peut observer sur taginfo et quelle serait la démarche pour revoir
cette
modification et dans l'idéal valider dans les règles les tags
cycleway:left/right=opposite_lane

Bonne journée

Charles


___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto: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] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki


Re-bonjour

Quelques informations complémentaires :

Mes échanges avec le contributeur m'ont apporté quelques explications 
mais je ne suis pas encore sûr d'avoir intégré toutes les motivations.


Il m'a pointé ce ticket de JOSM 
(https://josm.openstreetmap.de/ticket/17307) dans lequel il justifie le 
fait de ne pas utiliser cycleway:left/right=opposite_* par "you can 
decode all the tags without caring about the value of oneway=* if it is 
present."


Je ne saurais pas dire si cette approche d'indépendance des tags pour 
des besoins d'interprétation soit une pratique courante voir admise. 
Pourquoi partir du principe qu'on peut ignorer certains tag d'un objet 
pour le "traduire" ?


Je suis assez perplexe parce qu'on a déjà beaucoup de mal à s'accorder 
sur des manières de décrire les aménagements cyclables et là cette 
vision me semble assez personnelle et pas le résultat d'une décision 
collective. Après les tags proposés fonctionnent mais c'est super lourd 
je trouve. Je comprend bien son approche de pouvoir lire l'information 
d'aménagement cyclable de manière indépendante mais c'est au détriment 
d'une simplicité (qui n'est déjà pas si évidente que ça).


Bon en plus je trouve les cycleway:left/right=opposite_* et j'aurais 
plutôt pensé qu'on allait les étendre aux valeurs shared_lane et même 
sidewalk (mais ok j'arrête c'est un autre sujet).


Charles

On 13/03/2019 15:37, Charles MILLET wrote:

Salut Marc,

Merci pour ton retour.

C'est lui qui a changé il me semble la version anglaise un peu plus 
tôt ce matin. Donc je trouve que l'harmonisation ne peut pas être 
retenue (j'aurais du le préciser dans mon premier message).


Mais sinon, je pense qu'à quelques exception près, tout le monde sera 
ok pour le principe d'avoir les mêmes pratiques :)


Charles

On 13/03/2019 15:24, marc marc wrote:

Bonjour,

Le 13.03.19 à 15:03, Charles MILLET a écrit :
https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997 


Il recommande

d'après le commentaire de sa modif, il a l'air de surtout chercher une
harmonie/synchronisation entre la version anglaise et française, chose
que je ne peux que être d'accord et même totalement soutenir.
peu importe le schéma retenu, il est contre-productif d'avoir une piste
cyclable tagé d'une manière en France et de devoir la couper en 2 pour
la tager d'une autre manière si elle passe la frontière.
cela nuit non seulement à l'utilisation des données (temps perdu niveau
devs pour faire du code pour gérer les différents schémas)
mais aussi à la création des données (nombreux sont les contributeurs
qui ne sont pas mono-pays... toute différente inutile entre les
pays/régions est donc source au minimum de temps perdu voir d'erreur).

donc à mon avis, on peux lister le pour et le contre des 2 schémas
mais au final, on ne peux pas faire l'impasse de "remonter" la recherche
d'une harmonie au niveau mondial (ml tagging).
si cela échoue au niveau mondial, il restera à voir si c'est pertinent
de modifier la page française mais aussi anglaise pour dire
"contrairement au reste du monde, tel pays fait ainsi, tel autre pays
fait comme cela"

PS: je n'ai pas été voir si l'un des 2 schémas était utilisé dans une
partie géographique restreinte ou non.

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


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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki


Salut Marc,

Merci pour ton retour.

C'est lui qui a changé il me semble la version anglaise un peu plus tôt 
ce matin. Donc je trouve que l'harmonisation ne peut pas être retenue 
(j'aurais du le préciser dans mon premier message).


Mais sinon, je pense qu'à quelques exception près, tout le monde sera ok 
pour le principe d'avoir les mêmes pratiques :)


Charles

On 13/03/2019 15:24, marc marc wrote:

Bonjour,

Le 13.03.19 à 15:03, Charles MILLET a écrit :

https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997
Il recommande

d'après le commentaire de sa modif, il a l'air de surtout chercher une
harmonie/synchronisation entre la version anglaise et française, chose
que je ne peux que être d'accord et même totalement soutenir.
peu importe le schéma retenu, il est contre-productif d'avoir une piste
cyclable tagé d'une manière en France et de devoir la couper en 2 pour
la tager d'une autre manière si elle passe la frontière.
cela nuit non seulement à l'utilisation des données (temps perdu niveau
devs pour faire du code pour gérer les différents schémas)
mais aussi à la création des données (nombreux sont les contributeurs
qui ne sont pas mono-pays... toute différente inutile entre les
pays/régions est donc source au minimum de temps perdu voir d'erreur).

donc à mon avis, on peux lister le pour et le contre des 2 schémas
mais au final, on ne peux pas faire l'impasse de "remonter" la recherche
d'une harmonie au niveau mondial (ml tagging).
si cela échoue au niveau mondial, il restera à voir si c'est pertinent
de modifier la page française mais aussi anglaise pour dire
"contrairement au reste du monde, tel pays fait ainsi, tel autre pays
fait comme cela"

PS: je n'ai pas été voir si l'un des 2 schémas était utilisé dans une
partie géographique restreinte ou non.

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] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki


Bonjour à tous

Un contributeur a mis à jour la page wiki concernant la manière de 
décrire les doubles sens cyclables sur bande :


https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997

Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car 
cette valeur n'est pas documentée dans les valeurs des clé 
cycleway:left/richt (même si elle l'est pour la clé cycleway)


Il recommande donc :

highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1

plutôt que

highway=* + oneway=yes + cycleway:left=opposite_lane

:'(

Je lui ai envoyé un message pour lui exprimé avec politesse que je pense 
qu'il vaudrait mieux admettre ou officialiser 
cycleway:left=opposite_lane mais je m'attend que ce type de contribution 
traduise une volonté de respecter rigoureusement le wiki...


Je m'adresse à la liste pour avoir votre avis au regard de l'usage qu'on 
peut observer sur taginfo et quelle serait la démarche pour revoir cette 
modification et dans l'idéal valider dans les règles les tags 
cycleway:left/right=opposite_lane


Bonne journée

Charles


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

Re: [OSM-talk-fr] Les voies vertes

2018-12-02 Per discussione Charles MILLET


Salut Axelos,

Je suis vraiment content que cette approche te convienne. C'est bête 
comme remarque mais nos capacités à faire évoluer nos visions sur la 
façon de cartographier est la clé de la réussite. On a des approches 
différentes en fonction de nos sensibilités et je crois que les 
compromis qu'on arrive à trouver sont finalement les meilleurs solutions.


Charles

On 27/11/2018 20:04, Axelos wrote:

L'ajout de traffic_sign=FR:C115 peut sembler fastidieux, mais c'est le seul moyen 
d'identifier les "Voies vertes selon l'aménageur" malgré la diversité des 
aménagements. L'intérêt est de pouvoir identifier, par une simple requête Overpass, des 
voies voies vertes autorisées aux véhicules à moteur comme celles-ci.

En revanche ne remet plus en question cette proposition:)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zone grise sur la BDOrtho en Île-de-France

2018-11-21 Per discussione Charles MILLET

J'ai trouvé une solution : se mettre au niveau de zoom le plus élevé 
avant le blanc, cliquer droit et décocher auto-zoom.


... bon en réalité c'est Stéphane P qui l'a trouvée :-D ! Merci 
Stéphane, tu gères ! 8-)


On 19/04/2018 11:06, marc marc wrote:

Le 19. 04. 18 à 10:37, Antoine Riche a écrit :

résolution native jusqu'au niveau 20
en bordure de la zone couverte à cette résolution, au lieu d'avoir
l'imagerie du zoom 19 qui s'adapte au zoom 20, les tuiles sont vides et
toutes grises. C'est par exemple le cas au niveau de la Rue Franklin
à Courbevoie (lien direct
JOSM ).

le problème est du au fait que la couche BDOrtho est définie comme
existant jusqu'au zoom20.
mais à cet endroit la tuile du zoom20 est blanche
https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/20/530896/360545.jpg

il y a 2 pistes à tester :
côté josm on peux définir  no-tile-checksum qui permet de détecter
les "fausses" tuiles. j'ignore cependant si josm va automatiquement
demander la tuile de zoom-1.

côté proxy, si on a un moyen de détecter l'erreur, on peux ajouter un
header qu'on définir dans  no-tile-header afin que le client en soie
informé.

pour iD, j'ignore s'il y a un moyen de passer l'info

Si quelqu'un est motivé, le premier point est facile à tester :)
___
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 taguer une piste cyclable à double sens sur chaussée ?



On 12/10/2018 11:25, marc marc wrote:

Le 12. 10. 18 à 11:15, Charles MILLET a écrit :

Le choix des way multiple est déjà celui recommandé ! (cf. T1
https://wiki.openstreetmap.org/wiki/Bicycle)

Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est
pas quelque chose qui a été introduit de manière cavalière mais on va
pas faire la même chose non plus dans l'autre sens.


Le 12. 10. 18 à 10:34, Charles MILLET a écrit :

Quelqu'un peut me dire où il est question de l'avis international en
faveur de "cycleway=track" ?

il n'existe pas un unique lieu d'avis international,
il y a :
- le wiki (tant la pagecycliste que la page qui explique
qu'on fait 2 way lorsqu'il y a un obstacle entre les 2)
- la mailling tagging
- et même s'il veux pas l'entendre, la communauté locale est un avis à
prendre en compte. on devrait s'uniformer au niveau mondial mais c'est
pas une raison pour ne pas tenir compte du local.
au lieu d'essayer de deviner ce qu'il prend comme source,
le mieux serrait de lui demander ou de lui montrer que sur la page des
cyclistes avec le cas T1 dit clairement que plusieurs ways sont recommandés,
l'utilisation d'un seul way étant une version simplifiée quand on n'a
pas tous les éléments" ou quand on veux faire "un premier jet simplifié
qu'on raffinera + tard
Je veux pas bitché mais ne vous attendez pas trop à avoir des échanges 
très constructifs avec ce contributeur... après je ne demande qu'à avoir 
tord. Le wiki offre suffisamment d'interprétation (et c'est bien aussi) 
pour que quelqu'un qui veut défendre son point de vue puisse trouver les 
élément qui vont dans son sens.



sens, puisqu'on a déjà du mal à définir des règles claire pour choisir
entre un way propre et un tag sur la chaussée, on va encore créer du
flou sur le sujet.

pourtant même moi le grand partisan d'un non excès des way séparé,
je trouve qu'il se trompe. mais ce n'est pas un avis international :)
Ça me fait vraiment plaisir de lire ça ! Je veux dire, le fait qu'on 
peut encore en discuter et continuer de peser le pour et le contre et de 
faire en sorte de définir les cas où il vaut mieux utiliser le track, etc.




___
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] Cartographie des arrêts de bus de substitution de la ligne RER C


Merci beaucoup pour tes précisions Marc !

Je suis globalement d'accord avec tes arguments pour ce qui est de la 
redondance, j'attends un peu d'avoir à nouveau les explications des 
"pour" avant d'avoir un avis définitif.


Effectivement ce serait assez cohérent d'utiliser substitution:route_ref

On 12/10/2018 12:58, marc marc wrote:

Bonjour,

Le 12. 10. 18 à 11:24, Charles MILLET a écrit :

Pour résumer tu n'est pas pour parce que tu n'est déjà
pas pour le route_ref ?

oui en résumé c'est exactement cela. je suis contre subtitution:lines
permanent parce que je suis contre l'utilisation permanente de route_ref

Si c'est un tag temporaire comme un étape intermédiaire renseignant
les informations destiné à la création des relations, c'est utile
mais autant garder la même logique et créer subtitution:route_ref
Et je passerai à la relation même imparfaite dès que possible.


https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
[route_ref=* can easily be added to individual bus stops without knowing
the whole route a service takes. It can serve as a basis to add the full
route relation LATER on]

je partage cet avis :
route_ref est utile quand il est utilisé temporairement "je suis passé
devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter
PLUTARD à la relation par ex avec un outil + adapté", c'est donc
à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
(même si je trouve qu'utiliser une clef spécifique pour une note/fixme
dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à
requêter" et si chaque catégorie de donnée utilisait une clef
différente, ce serrait pas génial)

mais quand il est permanent, c'est une donnée dupliquée avec la galère
que cela implique à chaque fois qu'il y a une différence entre les 2 :
si un utilisateur vire route_ref sans virer l'arrêt de la relation,
cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut
virer de la relation ? ou cela signifie-t-il qu'il a juste viré
une clef qu'il trouve inutile ?
Idem quand route_ref est présent mais différent des relations,
pour en avoir corrigé un bon paquet, quelle perte de temps à faire
une 2ieme fois les modifs en devinant le sens de la désynchro.
J'ai croisé des désynchro qui avait des années... c'est un peu
comme les notes non traitée, on a l'info mais faut quelqu'un
repasse une 2ieme fois pour que cela deviennent utilisable.


on est pas mal dans cette situation au final sauf qu'au lieu
d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter
cette clé, on propose d'utiliser : substitution=yes +
subtitution:lines=* qui ont une vocation plus temporaire
(1 an, 2 ans ?).

en temporaire oui pourquoi pas.
dans cette optique, autant aller jusqu'au bout avec
subtitution:route_ref qui dit clairement que cela a pour but
à terme d'être ajouté dans une relation de substitution.
mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"
hors on va le mettre dans le wiki comme façon de tager un arrêt
de substitution
puis il y aura la tentation de faire un umap
ou n'importe quoi d'autre pour montrer l'avancement..
et du coup le temporaire devient permanent...
Tu parles de 2 ans...
pq pas faire une relation imparfaite ? une relation ligne de bus
qui contient juste les quelques arrêts identifié dans le mois,
ce n'est pas complet mais c'est utilisable, un tag wiki sur
la relation vers la page qui explique l'expérimentation,
il serra toujours temps + tard d'affiner.
Mais je comprend/partage l'avis que la relation n'est pas
la priorité quand vous en êtes à l'étape d'identifier les arrêts.


Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile
de la rejeter, perdre son utilité juste pour gagner en "pureté"
de la données ?

Le problème principal ce n'est pas la pureté.
C'est le fait qu'avoir les données de 2 manières différentes implique
que par erreur ou par méconnaissance, certains contributeurs vont
modifié l'un, d'autre vont modifier l'autre et tu finis par avoir
des données de moindre qualité que si tu as une seule manière
de le renseigner.
Idem pour l'utilisation des données : certains vont utiliser l'un
parce que + présent au début, d'autre vont utiliser l'autre...
et donc les outils n'auront qu'une vision partielle des données,
sauf à devoir se farcir les 2 manières et donc le temporaire
devient "durable".


Bon voilà, j'oserai plus utiliser des notes ;)

:) à bon escient :)

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

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C


Merci pour ton retour (plus des commentaires dans le corps).

Pour résumer tu n'est pas pour parce que tu n'est déjà pas pour le 
route_ref ?


Pourtant si on regarde cette page 
https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :


[route_ref=* can easily be added to individual bus stops without knowing 
the whole route a service takes. It can serve as a basis to add the full 
route relation later on]


...on est pas mal dans cette situation au final sauf qu'au lieu 
d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter 
cette clé, on propose d'utiliser : substitution=yes + 
subtitution:lines=* qui ont une vocation plus temporaire (1 an, 2 ans 
?). Moi ça me semble plus adapté dans un premier temps plutôt que de 
mettre beaucoup d'énergie à mettre en place une relation (et j'aime les 
relations ;) qui sera encore plus difficile à maintenir. Je propose de 
voir ça dans un second temps.


J'attends aussi les arguments de Florian mais je crois qu'il est cloué 
au lit en ce moment.


On 11/10/2018 18:15, marc marc wrote:

Le 11. 10. 18 à 17:05, Charles MILLET a écrit :

Nous pensons utiliser quelque chose comme ça
substitution=yes

sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
en particulier, c'est un arrêt de bus, y dupliquer l'information
de tous les type de lignes pouvant éventuellement l'utiliser ne semble
à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque
changement, il faut veiller à dupliquer le changement pour garder
la cohérence, faire une analyse osmose ou autre pour surveiller
les inévitables désynchronisation entre les 2 et avoir quelqu'un
qui passe du temps à resynchroniser les données).
Je pense que l'utilisation des données du type de ligne qui passe
à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
Mais je sais qu'on a au moins 2 champions de la duplication dans
la communauté qui ne manqueront pas de faire valoir l'inverse :-)
Oui il faudrait une relation pour décrire ces lignes temporaires mais là 
il s'agit de décrire que l'arrêt de bus fait aussi l'objet d'un arrêt de 
substitution


Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile de la 
rejeter, perdre son utilité juste pour gagner en "pureté" de la données 
? Je crois que c'est un autre débat, comme je n'y ai pas trop participé 
je donne rapidement mon avis à ce sujet :  je suis pour la redondance 
des lignes sur les arrêts dans la mesure où elle ne pose pas de 
problèmes et apporte des informations très utiles.





subtitution:lines=RER C

pour les relations représentant les lignes,
Une possibilité serrait d'avoir exactement le même nom
et donc j'aurais plutôt vu quelque chose genre
name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
le nom, le from, le to, la ref et la branche...)
substitution=only (la ligne n'existe que quand l'autre est en panne)
substitution:of=train (elle remplace une relation train)
et éventuellement sur la relation du RER C:
substitution:by=bus
en ajoutant l'itinéraire de substitution dans la relation route_master
on pourrait sans doute faciliter une utilisation futur + poussée.
le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus
fils d'une relation route_master=train
ce serrait sans doute utile d'en discuter sur tagging
avec une exemple de relation bus comparable à la relation rer
histoire de rendre la chose compréhensible pour ceux qui n'ont
rien de semblable chez eux.
c'est sans doute un peu prématuré si pour le moment vous en êtes
aux arrêts de bus eux-même.
Les relations, si elles existent un jour, ne sont pas pour tout de 
suite, c'est un peu compliqué de me plonger dans une réflexion sur la 
façon de les taguer.



Ces tag pourrons être complétés par une note au besoin.

les notes peuvent être utile pendant l'expérience sur la première
relation mais à long terme, des outils/contributeurs considèrent
la note comme étant souvent le signe que c'est pas stable d’où
le besoin de transmettre une information et qu'il faut donc
un éventuel coup de main pour transformer la note en tag + adapté.
url=la page wiki sur le changeset serrait très utile pour le
contributeur qui veux en savoir plus sur le projet.

Bon voilà, j'oserai plus utiliser des notes ;)


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

Re: [OSM-talk-fr] ?==?utf-8?q? Comment taguer une piste cyclable à double sens sur chaussée ?

Le choix des way multiple est déjà celui recommandé ! (cf. T1 
https://wiki.openstreetmap.org/wiki/Bicycle)


Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est 
pas quelque chose qui a été introduit de manière cavalière mais on va 
pas faire la même chose non plus dans l'autre sens.


Bon en même j'ai pas pris de le temps de mettre en place un vrai débat à 
ce sujet la dernière fois qu'on en a parlé.. J'ai pas mal de boulot en 
retard sur ces sujets.


On 03/10/2018 17:34, Axelos wrote:

Coucou,

Le Mercredi, Octobre 03, 2018 09:19 CEST, Thomas Ruchin  a 
écrit:

Question subsidiaire. S'il persiste, puis je demander le soutien du DWG
avant que cela ne dégénère en guerre d'édition. De ce qu'il m'écrit, il
n'accepte que les argument de la communauté "internationale".

Je pense qu'il s'agit d'une incompréhension. Je te suggère de suivre son choix 
et de lui proposer de mettre à jour la page wiki version anglaise bicycle cas 
T2 en mettant le choix du chemin unique en recommandé, ce qui correspondra à 
l'avis international.


___
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] ?==?utf-8?q? Comment taguer une piste cyclable à double sens sur chaussée ?

Quelqu'un peut me dire où il est question de l'avis international en 
faveur de "cycleway=track" ? Parce que si on change le wiki dans ce 
sens, puisqu'on a déjà du mal à définir des règles claire pour choisir 
entre un way propre et un tag sur la chaussée, on va encore créer du 
flou sur le sujet.


On 03/10/2018 17:34, Axelos wrote:

Coucou,

Le Mercredi, Octobre 03, 2018 09:19 CEST, Thomas Ruchin  a 
écrit:

Question subsidiaire. S'il persiste, puis je demander le soutien du DWG
avant que cela ne dégénère en guerre d'édition. De ce qu'il m'écrit, il
n'accepte que les argument de la communauté "internationale".

Je pense qu'il s'agit d'une incompréhension. Je te suggère de suivre son choix 
et de lui proposer de mettre à jour la page wiki version anglaise bicycle cas 
T2 en mettant le choix du chemin unique en recommandé, ce qui correspondra à 
l'avis international.


___
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] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-11 Per discussione Charles MILLET


Bonjour,

cartographions actuellement avec Antoine (Carto'Cité), Florian (Jungle 
Bus) et Stéphane (V4M*) les arrêts de bus de substitution de SNCF 
Transilien. Ce sont -souvent- des arrêts de bus classiques, utilisés par 
ailleurs pour la desserte de bus SNCF remplaçant les trains lors de 
perturbations.


Cette action a pour but à termes de permettre du routage mais ça n'a pas 
d'influence.


Pour les besoins du démarrage de cette opération on a commencé en 
utilisant le tag substitution=yes qui ne me parait pas vraiment 
explicite. Nous pensons utiliser quelque chose comme ça

substitution=yes
subtitution:lines=RER C

Ces tag pourrons être complétés par une note au besoin.

Est-ce que ça vous semble acceptable et sinon que recommanderiez-vous ?

Nous avons remarqué également que certains créent des relations 
classiques de bus pour cela, ce qui me parait adapté pour ces bus aux 
itinéraires prédéfinis qui opèrent de manière irrégulière.
exemple : 
https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun#Bus_de_substitution_du_Tram 



Sans aller dans ce niveau de détail, nous cherchons dans un premier 
temps à qualifier les arrêts de bus eux-même.


À très bientôt

Charles


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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

2018-07-30 Per discussione Charles MILLET

Globalement le caractère bidirectionnel serait traité de la même manière 
que pour les track et les lanes ; c'est un des intérêts de passer par un 
modèle identique.


Dans certain de tes exemple on frise le cycleway=track je pense... (je 
vais me faire engueuler... ;) et justement le fait d'utiliser les 
différentes possibilités cycleway=lane/track/sidewalk, en plus de 
clarifier les voies cyclables, permet d'introduire des nuances de 
cyclabilité, tout comme de nombreux autre tag ; après il existe autant 
de nuance de cyclabilité que d'aménagement...


On 30/07/2018 10:19, Phyks wrote:

Bonjour,

Le 27/07/2018 à 19:22, marc marc a écrit :

Le 27. 07. 18 à 18:47, Charles MILLET a écrit :

  * cycleway:*=sidewalk + segregated=yes/no
Je préfère cycleway=sidewalk


cela me semble cohérent avec l'existant.
cycleway=sidewalk pour le cas général
et avec des préfixe si la situation n'est pas la même pour les 2
trottoirs : cycleway=sidewalk serrait un alias de cycleway:both=sidewalk


Je ne suis pas sûr que ceci permette de tagger une piste
bidirectionnelle sur trottoir, mais j'ai peut être raté un truc. Par 
exemple celle-ci
https://www.google.fr/maps/@48.8155768,2.3064629,3a,75y,215.99h,72.26t/data=!3m6!1e1!3m4!1s10YP8tp9kNTPUlpgbwimrQ!2e0!7i13312!8i6656 


ou
https://www.google.fr/maps/@48.8876042,2.3793176,3a,75y,236.5h,67t/data=!3m6!1e1!3m4!1sruTXObVZq4NYgkgL5tWTYg!2e0!7i13312!8i6656, 


bidirectionnelle à droite et trottoir de chaque côté. C'est un type
d'aménagement que je rencontre fréquemment.

De ce que j'ai repéré pour l'instant, il y a plusieurs cas de pistes
cyclables sur trottoirs, avec une qualité et une praticité inégale :

* Des pistes en bordure de trottoir, séparées par du marquage ou des
clous, comme
https://www.google.fr/maps/@48.8235666,2.3236568,3a,75y,143.58h,76.56t/data=!3m7!1e1!3m5!1sKhyac6Qw9VQo567DCJHumA!2e0!6s%2F%2Fgeo2.ggpht.com%2Fcbk%3Fpanoid%3DKhyac6Qw9VQo567DCJHumA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D358.2077%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656 



* Des pistes qui traversent réellement des trottoirs, comme
https://www.google.fr/maps/@48.8275762,2.3265773,3a,75y,229.77h,75.56t/data=!3m6!1e1!3m4!1sspbZdG3q161crzyRBBoO1w!2e0!7i13312!8i6656. 



* Des bidirectionnelles sur trottoir, comme celle ci-dessus.

* Déjà vu une fois ou deux, un des trottoirs est neutralisé et réservé
aux pistes cyclables et l'autre trottoir est conservé pour les piétons.

* Des aménagements vraiment partagés entre piétons et cyclistes, comme
https://www.google.fr/maps/@48.8917069,2.38638,3a,75y,33.44h,93.08t/data=!3m8!1e1!3m6!1sAF1QipM8WPH6KCj8cLqzXE7W5hoHrnGFgySaWUH2pXfU!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipM8WPH6KCj8cLqzXE7W5hoHrnGFgySaWUH2pXfU%3Dw203-h100-k-no-pi0-ya321.44794-ro-0-fo100!7i7168!8i2902. 



D'un point de vue cycliste, ces aménagements sont très différents en 
termes de confort d'utilisation (et de conflits avec les piétons), 
donc j'aurais tendance à penser qu'ils devraient idéalement pouvoir se 
distinguer assez facilement par les tags utilisés :)




Sinon moi j'ai une autre proposition :)
Un bon vieux highway=footway + footway=sidewalk + cycleway=track + en

général oneway=yes

Ça ne devrait pas être plutôt cycleway=lane vu que c'est une bande
peinte sur le trottoir ?

___
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] Présentation rapide

2018-07-29 Per discussione Charles MILLET

En fait OsmAnd permet même de filrer les POI en fonction des tags 
d'accessibilité (enfin la clé wheellchair en fait)


On 23/07/2018 23:02, deuzeffe wrote:

Le 23/07/2018 à 22:16, jacques+...@foucry.net a écrit :

On 07/23/2018 19:50, deuzeffe wrote:


Donc, tu utilises quelles applications et sous quel OS ?


OsmAnd~


Sous Osmand, dans les config. de la carte, si tu choisis OSM-FR comme 
fond de carte, tu verras les parking PMR clairement rendus (un P avec 
l'icône standard PMR).


#HTH



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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

2018-07-29 Per discussione Charles MILLET



On 27/07/2018 19:22, marc marc wrote:

Le 27. 07. 18 à 18:47, Charles MILLET a écrit :

   * cycleway:*=sidewalk + segregated=yes/no
Je préfère cycleway=sidewalk

cela me semble cohérent avec l'existant.
cycleway=sidewalk pour le cas général
et avec des préfixe si la situation n'est pas la même pour les 2
trottoirs : cycleway=sidewalk serrait un alias de cycleway:both=sidewalk

Super ! parfait !



   * highway=footway + footway=sidewalk +bicycle=yes/designated

selon le wiki cela nécessite un panneau "bleu piéton" qui est rarement
présent et donc même si c'est souvent utilisé, cela me semble souvent
erroné car tu provoques des problèmes pour les autres modes de
transports (genre les rollers qui ont un accès par défaut différent
selon les pays)


   * highway=cycleway + footway=sidewalk (je sais ça fait un peu bizarre
 et on pourrait aussi mettre cycleway=sidewalk) + oneway=yes/no +
 foot=yes/designated + segregated=yes/no

cela retombe dans le problème des voies vertes (est-ce un chemin piéton
avec des cyclistes ou une piste cyclable avec des piétons) et donc selon
moi à éviter


   * highway=path + foot=designated + cycleway=sidewalk + segregated=yes/no

cela me semble le mieux, sauf que j'aurais mis foot+cycleway
en =sidewalk ou les 2 en =designated mais pas un mix.
OK pourquoi pas. Je pencherais pour le =sidewalk dans ce cas pour ne pas 
perdre l'information qu'il s'agit justement d'un trottoir... et en 
attendant de faire encore un peu évoluer les solutions pour les voies 
vertes, cela aura l'autre avantage de ne pas créer une confusion.



Et on remet à un peu plus tard les critères pour choisir si on doit
traiter l'information sur un seul way ou plusieurs pour ne pas trop se
mélanger...

je n'ai pas l'impression qu'il y ai matière à débat même s'il y a 2
situations différentes mais donc oui c'est une bonne idée de diviser et
reporter ce point à plus tard histoire d'avancer sur lä ou c'est
possible. au pire cela terminera sur le wiki comme pour le reste avec
"cas recommandé et cas existant non recommandé".
Justement je pense qu'il y a encore besoin d'en discuter parce que, même 
si pour les enjeux du routage, la mutualisation du way est très 
pratique, il y a quand même d'autres arguments qui ne sont pas en 
faveur. J'ai compris qu'il s'agissait de ton argument et de ta 
motivation principale, je suis tout à fait d'accord avec toi et je 
trouve que c'est une très bonne raison... mais :) je pense aussi que ce 
n'est peut-être pas suffisent pour le justifier mais je ne vais pas 
rentrer dans les détails.


On pourra justement relancer une discussion à part pour vraiment peser 
le pour et le contre et recueillir les avis en faisant en sorte de bien 
se concentrer sur ce sujet uniquement ;)


Merci pour le travail de titan à chercher un compromis cohérent :-)

C'est moi qui te remercie pour faire vivre le sujet ;)

Et gardons à l'esprit :

« Ce  qui  fait  la  multiplicité  des  points  de  vue  ne  vient pas  
d’une  faiblesse de nos interprétations successives, mais bien de la 
richesse de l’objet lui-même. C’est parce qu’il est complexe qu’il 
génère autant de points de vue sur lui-même. Cette complexité est un 
éloge de l’objet et non pas un éloge des subjectivités qui le 
considéreraient de l’extérieur. »


La référence bibliographique est fausse mais vient de là : 
https://halshs.archives-ouvertes.fr/halshs-00841777/document — Merci 
Vincent Bergeot pour cet article qui permet de justifier tous les débats 
autour des tags ;)

___
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] Différencier aménagement cyclables sur trottoir des autres

2018-07-29 Per discussione Charles MILLET


On 28/07/2018 21:06, Axelos wrote:

Coucou, j'ai en effet un peu zappé la discussion :)

Le 27/07/2018 à 19:22, marc marc a écrit :

Le 27. 07. 18 à 18:47, Charles MILLET a écrit :

   * cycleway:*=sidewalk + segregated=yes/no
Je préfère cycleway=sidewalk

cela me semble cohérent avec l'existant.
cycleway=sidewalk pour le cas général
et avec des préfixe si la situation n'est pas la même pour les 2
trottoirs : cycleway=sidewalk serrait un alias de cycleway:both=sidewalk

À choisir entre les deux, moi aussi je préfère la seconde solution, pour
un peu près les mêmes raisons que vous (ça va je ne suis pas d'esprit de
contradiction ce soir !)

Bon bah c'est excellent ce début de consensus sur le cycleway:*=sidewalk
Quelle serait l'étape suivante selon vous s'il n'y a pas d'opinion 
différente dans les prochains jours ? Un travail de description en 
français puis en Anglais et un passage par le vote sur le Wiki ?





   * highway=footway + footway=sidewalk +bicycle=yes/designated

selon le wiki cela nécessite un panneau "bleu piéton" qui est rarement
présent et donc même si c'est souvent utilisé, cela me semble souvent
erroné car tu provoques des problèmes pour les autres modes de
transports (genre les rollers qui ont un accès par défaut différent
selon les pays)
Je continue de considérer que les notions d'accès passent après la 
description de l'aménagement dans la mesure où les tags d'accès et les 
valeurs par défauts des pays permettent de gérer ça très bien et sans 
ambiguïté. Mais je sais que certaines personnes préfèrent que ces 
notions d'accès soient prises en compte dès la description de la valeur 
du highway. Je respecte parfaitement ce point de vue mais je trouve que 
cette approche dégrade un peu l'« interprétation » des aménagements au 
mieux pour permettre une petite économie de tag. Continuons d'en 
d'abattre intelligemment et on finira bien par trouver des solutions :)



   * highway=cycleway + footway=sidewalk (je sais ça fait un peu bizarre
 et on pourrait aussi mettre cycleway=sidewalk) + oneway=yes/no +
 foot=yes/designated + segregated=yes/no

cela retombe dans le problème des voies vertes (est-ce un chemin piéton
avec des cyclistes ou une piste cyclable avec des piétons) et donc selon
moi à éviter


   * highway=path + foot=designated + cycleway=sidewalk + segregated=yes/no

cela me semble le mieux, sauf que j'aurais mis foot+cycleway
en =sidewalk ou les 2 en =designated mais pas un mix.

Pareil que Marc pour l'usage du path, mais pas d'accord pour le
commentaire supplémentaire : Si on met deux fois =designated ça équivaut
à un chemin partagé, et donc à la voie verte ... on retombe toujours sur
le même problème :)
Bon même si je continuerai de trouver dommage de conditionner l'usage de 
footway et cycleway à la présence de panneaux ou autres éléments 
similaires je pense qu'on peut partir sur du path et qu'on précisera 
l'aménagement à l'aide des autres tag (surface, etc.). Mais sinon pour 
distinguer les voies vertes on a toujours le tag du panneau ;) mais bon 
je dis ça pour plaisanter puisque de toute manière je préfère 
l'utilisation foot=sidewalk et bicycle=sidewalk comme évoquer mon 
message précédents car ils permettent de conserver l'information qu'il 
s'agit bien d'un trottoir.


Mais pourquoi segregated=yes/no ? Si il n'y a pas de séparation physique
sur le trottoir, alors il n'y a pas de piste cyclable et donc il s'agit
d'un trottoir, et donc on utilise highway=footway + footway=sidewalk
comme proposé précédemment par Antoine, et donc pas de segregated=no !
(si vous arrivez à suivre, respect !)
J'ai déjà vu des trottoir cyclables sans séparation... mais pour éviter 
de partir sur les différentes combinaisons logiques, on a qu'à partir du 
principe que de toute manière cela mérite toujours d'être précisé si la 
voie est partagée par les cyclistes et les piétons


Et c'est là aussi que rentre la subtilité du statut de l’aménagement,
officiellement même si c'est de la grosse daube, le machin séparé par de
la peinture est bel et bien une piste cyclable ...
cycleway=sidewalk pour une indication annexe depuis la chaussée
principale car il n'y a pas de séparation physique entre la chaussée et
le trottoir avec "piste cyclable" me semble plutôt convenable,
mais directement sur un chemin dédié car séparation physique de la
chaussée principale, là ça me parait bizarre !
C'est pour ça que je préfère me concentrer sur l'objet dans un premier 
temps et considérer l'accès et le code de la route dans un second temps 
et pas l'inverse puisque ça pose plus de problèmes que ça n'en résout ;)
Mais sinon pour être sûr que j'ai bien compris, tu veux dire que 
foot=sidewalk et bicycle=sidewalk ne seraient pas selon toi adaptés sur 
un way à part ?


Axel.

TL;DR

Sinon pour résumer on serait sur

way mutualisé > cycleway:*=sidewalk + etc.

way indépendant > highway=path + foot=sidewalk + bicycle=sidewalk etc.



___
Ta

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

2018-07-27 Per discussione Charles MILLET


Bonjour,

Alors pour les aménagement sur trottoir que fait-on ? De ce que j'ai vu 
dans taginfo et la discussions les possibilités principales lorsqu'on le 
tag sur le way qui décrit la route seraient :


 * sidewalk:*:bicycle=yes  + segregated=yes/no
 * cycleway:*=sidewalk + segregated=yes/no

Je préfère cycleway=sidewalk finalement car il préserve la manière 
actuelle de décrire les aménagement cyclables lorsqu'ils sont décrits 
sur le way de la route (cycleway=lane, cycleway=track, 
cycleway=share_busway, etc.) et il évite ainsi d'hésiter sur le 
placement du letf/right dans la clé. Je ne suis pas sûr que 
share_sidewalk soit plus intéressant que juste sidewalk puisque que le 
caractère partagé est explicite s'agissant d'un trottoir...


Pour ce qui est du way indépendant :

 * highway=footway + footway=sidewalk +bicycle=yes/designated +
   oneway:bicycle=yes/no + segregated=yes/no(bicycle=yes/designated à
   discuter et je pense en fonction de la simple présence de peinture
   ou d'un panneau) lorsque clairement il s'agit d'un ancien trottoir
   qui a servi pour
 * highway=cycleway + footway=sidewalk (je sais ça fait un peu bizarre
   et on pourrait aussi mettre cycleway=sidewalk) + oneway=yes/no +
   foot=yes/designated + segregated=yes/no
 * highway=path + foot=designated + cycleway=sidewalk + segregated=yes/no

Est-ce qu'on en est à peu près là dans les réflexions ou je suis passé à 
coté d'autres propositions ?


Et on remet à un peu plus tard les critères pour choisir si on doit 
traiter l'information sur un seul way ou plusieurs pour ne pas trop se 
mélanger...


Charles MILLET
charlesmil...@free.fr
06 10 38 81 56
02 51 78 06 38

Le 21/06/2018 à 19:29, osm.sanspourr...@spamgourmet.com a écrit :


De tels aménagements sont fréquents en Allemagne, je suis pour cette 
manière de tagguer.


Jean-Yvon

Le 21/06/2018 à 17:11, Antoine Riche - antoine.ri...@zaclys.net a écrit :

Le 10/06/2018 à 13:42, Axelos a écrit :


Soit les trottoirs ne sont pas séparées de la chaussée, et me vient une
idée provenant de le la Grande-Bretagne :
cycleway:both=share_sidewalk à placer sur l'unique chemin. Les trottoirs
y sont implicites.
Le concept est similaire aux voies de bus, on indique que les cyclistes
partagent le trottoir et se soumettent aux obligations de ce dernier.
Une autre approche, documentée sur 
https://wiki.openstreetmap.org/wiki/Key:sidewalk, est d'utiliser 
sidewalk:bicycle=yes. On peut distinguer les 2 côtés de la chaussée 
avec sidewalk:left:bicycle et sidewalk:right:bicycle, on peut 
également décrire le type de revêtement, etc. Ces tags sont nettement 
plus utilisés, notamment en Allemagne : http://overpass-turbo.eu/s/zJX


Antoine.



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Garanti sans virus. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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


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

Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-16 Per discussione Charles MILLET

D'accord, justement il s'agit d'utiliser le tag sur le chemin... après 
ça n'empêche pas de l'utiliser pour décrire l'emplacement du panneau.


On 16/07/2018 15:33, Axelos wrote:

Le 16/07/2018 à 10:49, Charles MILLET a écrit :

C'est très pratique ; c'est forcément un petit peu plus complexe à
cartographier que seulement l'aide de points mais l'information est
globalement plus précise. Encore une fois ça permet de distinguer les
voies vertes des autres aménagements et, comme pour la plupart des
panneaux, il n'y a pas d'ambiguïté à le relier avec un chemin
(t'exagères pas un peu là ? ;-))

Je n'ai pas été assez précis dans mon message, la complexité fait
référence à la signalisation verticale sur nœud; si directement sur le
chemin il n'y a pas de problème.

À plus.

___
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] Cartographier les voies vertes

2018-07-16 Per discussione Charles MILLET


On 16/07/2018 15:54, Axelos wrote:

Ba moi perso, je vais plutôt dans ce cas précis interpeller
l'institution qui va bien avant de chercher à retranscrire sur la carto
cet illogisme !
Justement, bien identifier les voies vertes à l'aide du tag du panneau 
traffic_sign=FR:C115 :

— évite d’introduire un nouveau tag ;
— respecte l'utilisation de la clé traffic_sign et est conforme aux 
usages actuels ;

— est sans ambiguïté.

Couplé à la description des aménagements tels qu'ils sont sur le terrain 
(sans laisser les droits d'accès être les seuls éléments qui influencent 
nos choix) permet de répondre à tous les « besoins » tout en respectant 
la philosophie d'OpenStreetMap.


Les tags des accès sont très riches et permettent parfaitement de gérer 
les droits d'accès justement. Il suffit que demain les militants 
motocross s'approprient OSM et décident qu'il n'y a pas de raison que 
les path ne soient pas accessibles à leur usage et le modèle tombe à 
l'eau...


La voie verte est un peu un élément bâtard entre l'aménagement et 
l'itinéraire, utiliser une clé « transversale » tel que traffic_sign un 
peu plus systématiquement permettrait de bien l'identifier sans 
compromettre une bonne description du type d'aménagement. Ainsi chacun a 
la possibilité de révéler les linéaires d'aménagement tels que les voies 
vertes mais aussi éventuellement de les critiquer en montrant bien de 
quoi elles sont composées.


Je crois que nous tous contributeurs somme souvent tentés par une forme 
de rigidité et que le code de la route ou les panneaux sont des éléments 
tangibles et confortables sur lesquels s'appuyer ; mais ils ont tendance 
à nous détourner de la réalité du terrain. Les solutions proposées 
permettent de traduire l'ensemble des questionnements autours des voies 
vertes sans introduire de nouveaux tags et en respectant le fait de 
décrire le terrain et le réel.


En résumé selon moi, pour décrire les voies vertes, l'utilisation de 
traffic_sign rend le modèle bien plus robuste est sans ambiguïté et sans 
biais.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-16 Per discussione Charles MILLET

Je ne vois pas de différence fondamentale avec les différentes 
informations concernant les limitations de vitesse qu'on affecte 
pourtant bien à des tronçons de route.


C'est très pratique ; c'est forcément un petit peu plus complexe à 
cartographier que seulement l'aide de points mais l'information est 
globalement plus précise. Encore une fois ça permet de distinguer les 
voies vertes des autres aménagements et, comme pour la plupart des 
panneaux, il n'y a pas d'ambiguïté à le relier avec un chemin 
(t'exagères pas un peu là ? ;-))


On 14/07/2018 14:32, Axelos wrote:

Coucou,

Le 12/07/2018 à 20:06, Charles MILLET a écrit :

Une précision par rapport au message original : un des objectifs de
cette réflexion sur les voies vertes vient du fait que les collectivités
et autres acteurs sont très demandeurs pour arriver à distinguer ces
aménagements en se basant sur leur vocabulaire, c'est à dire les
classiques pistes cyclables, bandes cyclables, aires piétonnes... et
voies vertes. Le choix retenu pour décrire les voies vertes ne permet
pas bien aujourd'hui de le distinguer d'autres aménagements qui
présenteraient les mêmes combinaisons de tags. C'est pour cela le
recours au traffic_sign serait une solution assez efficace... et cette
solution résisterait même aux remarques tels que "on ne mappe pas
pour..." puisqu'il n'apporterait pas une information fausse ;)

J'ai assez peu utilisé la clef traffic_sign jusqu'à maintenant. De ce
que j'ai pu constater de ce j'ai déjà rencontré sur la base, il s'agit
principalement d'un nœud représentant l’emplacement d'un panneau.

Bref il est assez compliqué en tant que contributeur de pouvoir relier
le panneau et le chemin pour lequel il s'applique, et donc complique la
contribution. Et c'est aussi le cas pour la réutilisation des données,
je possède une carte cyclable locale, honnêtement je n'ai aucune idée de
savoir comment relier ces deux informations sans devoir coder des trucs
hypers complexes.
Ce n'est donc pas pertinent, avis personnel.

En lisant le wiki, le tableau
https://wiki.openstreetmap.org/wiki/FR:Key:traffic_sign#Human-readable_values
confirme mes écrits.
Si maintenant, il est collectivement décidé d'accepter que la balise
traffic_sign C115 soit applicable sur les chemins Voies Vertes, alors,
dans ce cas je suis ok pour cette nouvelle approche, qui en effet ne
posera plus aucun doute sur la nature de la voie.

Axel.

___
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] Cartographier les voies vertes

2018-07-12 Per discussione Charles MILLET


Bonsoir,

Une brève parenthèse au sujet du highway=track qui serait destiné à 
décrire les chemins agricoles ; je crois que c'est une traduction un peu 
rapide de la page en anglais mais surtout le wiki précise que finalement 
c'est plus une question de largeur... Pour ma part j'utilise track non 
pas pour son usage agricole mais lorsqu'un chemin est peu carrossable et 
assez large pour une voiture. La vocation agricole est quand même super 
compliquée à établir en plus !


Selon moi certaines voies vertes empruntent clairement un aménagement 
qu'on qualifierait de track si le panneau ne nous faisait pas en débattre.


Bonne soirée.

On 21/06/2018 20:08, Axelos wrote:

highway=track ? Non ce n'est pas un chemin agricole mais une route.



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

Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-12 Per discussione Charles MILLET


Bonjour à tous,

Une précision par rapport au message original : un des objectifs de 
cette réflexion sur les voies vertes vient du fait que les collectivités 
et autres acteurs sont très demandeurs pour arriver à distinguer ces 
aménagements en se basant sur leur vocabulaire, c'est à dire les 
classiques pistes cyclables, bandes cyclables, aires piétonnes... et 
voies vertes. Le choix retenu pour décrire les voies vertes ne permet 
pas bien aujourd'hui de le distinguer d'autres aménagements qui 
présenteraient les mêmes combinaisons de tags. C'est pour cela le 
recours au traffic_sign serait une solution assez efficace... et cette 
solution résisterait même aux remarques tels que "on ne mappe pas 
pour..." puisqu'il n'apporterait pas une information fausse ;)


La suite de la réflexion était de se dire que puisqu'on a ce tag qui 
nous permet d'identifier une voie verte, pourquoi ne pas essayer de 
décrire l'aménagement de manière classique (path, track, unclassified, 
etc.) et d'utiliser les tags d'accès pour préciser l'accès justement. 
Comme ces panneaux ont fleuri un peu partout, cela pourrait éviter de 
dégrader une information qui n'est pas fausse. Cette approche semblait 
trouver un consensus lors des échanges physiques.


Bonne soirée.

Charles

On 21/06/2018 17:48, Antoine Riche wrote:


Bonjour,

Lors de l'atelier "vélo-tags" qui s'est déroulé lors de SOTM FR le 
samedi 2 juin, le sujet des voies vertes a été discuté. Le constat 
partagé lors des échanges est qu'une voie verte est identifiée par le 
panneau C115 (cf. 
https://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France), et que 
son aménagement peut être très différent : sentier, piste, voie de 
service, etc.


Le consensus des participant.e.s à cet atelier est de ne pas 
restreindre la valeur de la clef highway à path, et de préciser la 
présence du panneau par la clef traffic_sign. Je propose donc de 
modifier la section 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes pour 
indiquer qu'une voie verte est mappée par :


highway=*
foot=designated
bicycle=designated
traffic_sign=FR:C115

Ainsi nous affinons la description du terrain (on peut par exemple 
ajouter un tracktype si highway=track) et pouvons répondre aux 
attentes des collectivités qui souhaitent pouvoir identifier les voies 
vertes qu'elles ont balisées.


Des objections ou clarifications ?

Antoine.



 
	Garanti sans virus. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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] conflit de précision de données a cause d'une clé

2018-02-22 Per discussione Charles MILLET

Merci pour les photos Francescu. J'ai fait aussi quelques photos 360 
dans le secteur et qui sont dans Mapillary. Je connais un peu le secteur 
pour y avoir fait quelquse cartoparties.


Clairement, même si le débat entre cycle=track et highway=cycleway est 
justifié dans bien des cas si l'on considère l'objectif de routage, dans 
la situation présente on penche très largement pour le second choix.


Au sujet du débat, je suis un peu gêné que le terme de "séparation 
physique", qui est déjà bien ambiguë se transforme en "obstacle entre 
les 2 qui empêche de passer de l'un à l'autre" qui l'est encore plus et 
qui va nous faire retomber dans les aspects réglementaires, les cas 
extrêmes, etc.


Je suis assez d'accord que pour le routage ça pose un problème mais je 
ne trouve pas que cela justifie une telle régression dans la précision 
de la description des aménagements. Pour utiliser très régulièrement des 
calculateurs d'itinéraire pour le vélo, j'ai toujours trouvé que ce 
phénomène était négligeable mais je comprends qu'on puisse exiger 
l'excellence d'OSM ;)


Sinon sur la page https://wiki.openstreetmap.org/wiki/FR:Bicycle il y a 
bien le "recommandé" et le reste.


Bref, je ne devrais pas dire ça mais bon voilà, je connais un peu le 
contributeur concerné et il y a peu de chance qu'il fasse un revert sur 
sa contribution pour le dire simplement. Donc pour répondre à la 
question initiale de David, je dirais qu'un /revert/ peut être justifier.


Bonne journée et bonne contribution à tous...

Charles MILLET
charlesmil...@free.fr

Le 21/02/2018 à 12:14, Francescu GAROBY a écrit :

Bonjour Axel (et les autres),
Ça tombe bien que tu demandes des photos, car je comptais dès hier 
soir vous en faire ce matin, vu que le Cours Montalivet est justement 
mon itinéraire quotidien à vélo. Les voici donc, hébergées sur framapic.
Pour commencer, il faut savoir qu'il n'existe aucun aménagement 
cyclable coté sud du Cours Montalivet : uniquement des contre-allées, 
ouvertes à tous, permettant de desservir les magasins qui s'y 
trouvent. Mon trajet se fait donc dans le sens ouest -> est, au nord 
du Cours (entre ce dernier et l'Orne).


* 1ère photo <https://framapic.org/5LD33BlWZlhf/WdpV98ctUhXe.jpg> 
(prise ici 
<https://www.openstreetmap.org/?mlat=49.17931=-0.34844#map=19/49.17931/-0.34844> 
dans le sens sud -> nord), la jonction entre le Cours et la piste 
cyclable se fait par un feu tricolore commun avec les piétons et, du 
fait des travaux actuels, il est même demandé aux cyclistes de 
traverser pied à terre.
* 2ème photo <https://framapic.org/vuESNpzv1TZY/fYl9Gyillcpg.jpg> 
(prise ici 
<https://www.openstreetmap.org/?mlat=49.17953=-0.34857#map=19/49.17953/-0.34857>), 
la piste est bidirectionnelle, et large (1m80, avec tout de même 
quelques rétrécissements, parfois dangereux, à certains endroits. Mais 
jamais moins de 1m de large). À noter aussi la bande de terre herbeuse 
et arborée, qui sépare la piste de la chaussée. Par endroit, le 
trottoir dépasse les 20cm de hauteur !
* 3ème <https://framapic.org/dtCkIGuutQWH/0X3gWXqQp8Jb.jpg> et 4ème 
<https://framapic.org/lFopgQAbLpAv/XUaLuuE6cHwY.jpg> photos (prises 
ici 
<https://www.openstreetmap.org/?mlat=49.17962=-0.34817#map=19/49.17962/-0.34817> 
et là 
<https://www.openstreetmap.org/?mlat=49.17951=-0.33435#map=17/49.17951/-0.33435>) 
: pour comparaison, le Cours a lui aussi un terre-plein central 
herbeux et arboré. Puis uniquement herbeux et de la hauteur d'une 
petite motte de terre. Facilement franchissable par n'importe qui ! 
Même type de séparation, mais personne ne conteste la séparation 
physique des 2 axes de circulation.
* 5ème photo <https://framapic.org/lANFF7Q7ov59/gONaPRRXSuoB.jpg> : la 
piste a son propre revêtement. Il est séparé de la chaussée, pas 
refait au même moment, et même, par endroits, composé uniquement de 
plaques de béton, et non de bitume ! On voit d'ailleurs sur la photo 
qu'il a aussi son propre état : les racines des arbres soulèvent le 
bitume. Comme le Cours est plus souvent refait que la piste, ça ne se 
remarque que sur cette dernière...
* 6ème photo <https://framapic.org/oKLXhIyUmJ63/fj3I5ey4seLg.jpg> 
(prise ici 
<https://www.openstreetmap.org/?mlat=49.18284=-0.31795#map=18/49.18284/-0.31795>) 
: cependant, les 20-30 derniers mètres de la piste, à l'approche de sa 
jonction avec le carrefour Cours Montalivet/Route de Cabourg, sont 
différents, en effet. Plus de séparation physique par un terre-plein. 
Là, qu'on dise que c'est du "track", pourquoi pas.


Bref, pour moi, il est clair qu'il s'agit d'une piste cyclable 
("highway=cycleway"), et non d'autre chose (mis à part les 20-30 
derniers mètres, à l'extrémité est). D'ailleurs (j'ai oublié de 
prendre une photo spécifique, pour ça), les jonctions entre le Cours 
et la piste sont inexistantes (mis à part aux extrémités et aux rares 
passages-piéton

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

C'était bien le nœud il semble car sur www.mapcat.com on voit bien Mer 
Noire. Merci encore marc marc.


On 24/01/2018 12:31, Charles MILLET wrote:
Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
<https://fr.wikipedia.org/wiki/Frison_septentrional>, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET <charlesmil...@free.fr
<mailto:charlesmil...@free.fr>> a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com <http://www.mapcat.com>), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est 
bien

 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je 
pense
 que le problème d'affichage du nom en français vient peut-être 
de la

 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


___
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



___
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] Mer Noire / Black Sea – Problème d'affichage du nom français

Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
<https://fr.wikipedia.org/wiki/Frison_septentrional>, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* "name:fr"...

Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET <charlesmil...@free.fr
<mailto:charlesmil...@free.fr>> a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com <http://www.mapcat.com>), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est bien
 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je pense
 que le problème d'affichage du nom en français vient peut-être de la
 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


___
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



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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

Merci Francescu pour l'info. Je suis curieux de savoir comment tu as 
trouvé la référence au code, je ne l'ai pas vue dans la page 
https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages 
internet dédiées aux codes (peut-être trop orientées pays).


Concernant le problème d'affiche, j'avais imaginé la même hypothèse que 
toi... mais marc marc a remarqué que le nœud en doublon n'avait pas la 
clé name:fr



On 24/01/2018 11:52, Francescu GAROBY wrote:

Bonjour,
"frr" est le code pour le frison septentrional 
<https://fr.wikipedia.org/wiki/Frison_septentrional>, une langue 
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et 
"name:frr" devraient être traités distinctement. Sauf à penser que le 
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET <charlesmil...@free.fr 
<mailto:charlesmil...@free.fr>> a écrit :


Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
vérifié aussi sur www.mapcat.com <http://www.mapcat.com>), la Mer
Noire n'est pas nommée en français alors que la clé name:fr est
bien renseignée. Par contre il y a le tag name:frr=Suart Sia. Et
j'ai cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je
pense que le problème d'affichage du nom en français vient
peut-être de la présence de cette clé mais je n'ai pas de piste
pour corriger le problème sans me mettre à dos tout un pays... Si
quelqu'un a une idée je suis preneur.

Bonne journée.


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




--
Francescu


___
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] Mer Noire / Black Sea – Problème d'affichage du nom français


Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié 
aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français 
alors que la clé name:fr est bien renseignée. Par contre il y a le tag 
name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je 
n'ai rien trouvé. Je pense que le problème d'affichage du nom en 
français vient peut-être de la présence de cette clé mais je n'ai pas de 
piste pour corriger le problème sans me mettre à dos tout un pays... Si 
quelqu'un a une idée je suis preneur.


Bonne journée.


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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

2018-01-23 Per discussione Charles MILLET


Bonjour,

Je témoigne de la bonne volonté de Stéphane :)

Je pense qu'on est tous globalement impartiaux ; ce qui varie ce sont 
nos sensibilités et dans le cas présent c'est notre sensibilité à 
vouloir traduire plus ou moins strictement la réglementation dans les tags.


@Stéphane : rassure-toi, le ton dans les discussions peut parfois 
sembler un peu « inquisiteur » mais tant que tu es dans l'échanges et le 
partage de point de vue, tu es libre de t'exprimer, de débattre et de 
défendre ton point de vue :)


Bon courage.

Charles MILLET
charlesmil...@free.fr
06 10 38 81 56
02 51 78 06 38

Le 23/01/2018 à 14:34, Gwenrannad a écrit :
Pour conclure, je pense que la communauté OSM nantaise pourrait vous 
témoigner de ma bonne volonté et de mon impartialité afin qu'une 
éventuelle étiquette "politique" ne me soit pas "collée", car si tel 
était le cas, j'en serais fort attristé.



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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

C'est sûr que les deux exemples sont sans ambiguïtés mais au final on 
trouve beaucoup d'aménagements équivalents que je ne trouve pas plus 
ambiguë d’ailleurs l'illustration de la page footway ne comporte pas de 
panneau : https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway


Je comprends bien la tentation de s'appuyer sur des éléments concrets 
comme des panneaux mais je crois que je préfère encore débattre sur la 
nature d'un chemin et la pratique ;)


On 17/01/2018 18:35, marc marc wrote:

Bonsoir,

Le 17. 01. 18 à 15:19, Charles MILLET a écrit :

éviter les débats pour savoir si un voie est un footway ou un cycleway

ce serrait pourtant facile en se basant :
sur la largeur : trop étroit pour un véhicule -> path
sur les panneaux
footway
https://wiki.openstreetmap.org/wiki/File:Path-footdesignated.jpg
cycleway
https://wiki.openstreetmap.org/wiki/File:Path-bicycledesignated.jpg
et donc sans panneau ou vélo+piéton-> path


je ne sais pas elle fait consensus.

Hélas non.
https://wiki.openstreetmap.org/wiki/FR:Path_controversy
___
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] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

J'aurais du creuser un peu, je vois que la page francophone dédiée 
living_street 
(https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street) 
cite cette relation.


On 18/01/2018 10:19, Charles MILLET wrote:

Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté 
de ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits 


https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET <charlesmil...@free.fr>:

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 
n'est pas

nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de 
ne pas
se basé sur les spécificités locales pour considérer des valeurs 
implicites
de cette importance. Mais je voulais avoir vos avis avant d'en 
parler dans
la partie discussion ou directement avec le contributeur. Bon je 
pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas 
trouvé de

référence claire, ça pourra faire l'objet d'un rappel :)

--
Charles MILLET
charlesmil...@free.fr


___
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



___
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] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France


Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté de 
ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET <charlesmil...@free.fr>:

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
se basé sur les spécificités locales pour considérer des valeurs implicites
de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
la partie discussion ou directement avec le contributeur. Bon je pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
référence claire, ça pourra faire l'objet d'un rappel :)

--
Charles MILLET
charlesmil...@free.fr


___
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



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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

En fait c'est la condition de la signalisation qui me gène un peu. Il y 
a tellement de voies, disons "piétonnes", qui n'ont aucune signalisation 
— une très large majorité selon mon ressenti — que je ne sais plus 
vraiment à quoi sert le highway=footway si ce n'est pour signaler qu'il 
y a un panneau. J'avais tendance à l'utiliser pour les aménagement 
dédiés aux piétons (même sans panneau explicite) et effectivement selon 
la pratique (plus ou moins observée ou ressenti) à préciser que les 
cyclistes y sont autorisés.


Ça ne me dérange pas vraiment d'utiliser path mais j'ai l'impression 
qu'on perd un peu de subtilité.


On 17/01/2018 21:00, Romain MEHUT wrote:

Bonsoir,

Je trouve au contraire que c'est le meilleur compromis quand il n'y a 
effectivement pas de signalisation en place.


C'est aussi à mon sens plus compréhensible que d'associer par exemple 
highway=footway + bicycle=yes.


Romain

Le 17 janvier 2018 à 15:19, Charles MILLET <charlesmil...@free.fr 
<mailto:charlesmil...@free.fr>> a écrit :


Bonjour,

Je sais qu'il y a une discussion en cours concernant
spécifiquement les pistes cyclables sur les trottoirs et je ne
veux pas faire de doublon. Mais je voulais avoir votre avis sur
une récente modification de la page FR:Bicycle avant de contacter
le contributeur ou de discuter sur la page. Voici la page de
modification pour référence :

https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110

<https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110>

La modification concerne cette phrase dans la partie Voies
piétonnes partagées

(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es

<https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es>)
:

"En l'absence d'indication de nature de la voie, utiliser
l'attribut highway
<https://wiki.openstreetmap.org/wiki/FR:Key:highway>=path
<https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpath> qui
autorise cyclistes et piétons à circuler ensemble"

Même si cette approche est assez commode car elle permet d'éviter
les débats pour savoir si un voie est un footway ou un cycleway,
je la trouve assez catégorique et je ne sais pas elle fait consensus.

-- 
Charles MILLET

charlesmil...@free.fr <mailto:charlesmil...@free.fr>


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




___
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] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

2018-01-17 Per discussione Charles MILLET


Bonjour,

Je sais qu'il y a une discussion en cours concernant spécifiquement les 
pistes cyclables sur les trottoirs et je ne veux pas faire de doublon. 
Mais je voulais avoir votre avis sur une récente modification de la page 
FR:Bicycle avant de contacter le contributeur ou de discuter sur la 
page. Voici la page de modification pour référence : 
https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110


La modification concerne cette phrase dans la partie Voies piétonnes 
partagées 
(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es) 
:


"En l'absence d'indication de nature de la voie, utiliser l'attribut 
highway <https://wiki.openstreetmap.org/wiki/FR:Key:highway>=path 
<https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpath> qui autorise 
cyclistes et piétons à circuler ensemble"


Même si cette approche est assez commode car elle permet d'éviter les 
débats pour savoir si un voie est un footway ou un cycleway, je la 
trouve assez catégorique et je ne sais pas elle fait consensus.


--
Charles MILLET
charlesmil...@free.fr

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

[OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

2018-01-17 Per discussione Charles MILLET

Un contributeur a précisé l'information suivante dans la page du Wiki 
FR:Bicycle


"Utiliser l'attribut highway 
<https://wiki.openstreetmap.org/wiki/FR:Key:highway>=living_street 
<https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street>, 
l'attribut maxspeed 
<https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed>=20 
<https://wiki.openstreetmap.org/w/index.php?title=FR:Tag:maxspeed%3D20=edit=1> 
*n'est pas nécessaire* car valeur par défaut en France"


De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne 
pas se basé sur les spécificités locales pour considérer des valeurs 
implicites de cette importance. Mais je voulais avoir vos avis avant 
d'en parler dans la partie discussion ou directement avec le 
contributeur. Bon je pense que le sujet a déjà du être beaucoup débattu 
mais comme je n'ai pas trouvé de référence claire, ça pourra faire 
l'objet d'un rappel :)


--
Charles MILLET
charlesmil...@free.fr

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

Re: [OSM-talk-fr] Hiérarchie des relations d’itinéraire cyclistes

2018-01-16 Per discussione Charles MILLET

Je raccroche le sujet avec un peu de retard. C’est un super travail que 
tu as fais axelos. Les commentaires qui suivent ne vont malheureusement 
pas vraiment dans ton sens mais ils n’ont pas du tout pour objectif de 
simplement argumenter contre mais bien de faire un retour d’expérience 
de ma tentative très proche de la tienne mais que tu as bien mieux 
documentée :)


J’avais brièvement évoqué le sujet dans cet échange :

https://www.mail-archive.com/search?l=talk-fr@openstreetmap.org=subject:%22Re%5C%3A+%5C%5BOSM%5C-talk%5C-fr%5C%5D+Quelques+questions%22=newest=1


Mon retour d'expérience concernant la mise à jour des itinéraires 
cyclables des Pays de la Loire : J'avais dans un premier temps essayer 
d'avoir l'approche que tu propose qui est au final la bonne approche et 
celle conseillée dans la constitution de routes en général. Je pensais 
que c'était possible car certains itinéraire correspondaient bien à ce 
modèle comme par exemple l'EV1 qui a un beau découpage en étapes. Et 
très vite j'ai constaté que pour la plupart des autres itinéraires ce 
n'était pas vraiement possible à moins de tout découper (cf. données de 
l'ON3V des DRC présentées plus bas). En résumé, ça fonctionne dans le 
cas des grands itinéraires mais ça devient très complexe là où le réseau 
d'itinéraires cyclables est dense. Pour ma part j'en été arrivé à faire 
une relation par itinéraire "officiel" et à ne plus chercher à 
mutualiser des portions d'itinéraire... mais je veux bien revenir sur 
cette pratique si on s'entend pour dire qu'il faut vraiment mutualiser 
les portions d'itinéraire.



Le problème principale est le fait que chaque échelon administratif est 
autonome pour décrire des itinéraires : international, national, et tous 
les échelons de collectivités locales (Région, département, ComCom, 
etc.) ce qui est bien pour la richesse des itinéraires mais implique une 
absence de hiérarchie dans leur tracé. Ainsi, même si il y a une 
mutualisation des aménagement et en partie des itinéraires, l'approche 
est en réalité très pragmatique.



Les pièges autres : les différentes collectivités ne nomment pas et ne 
découpent les itinéraires de la même manière ce qui fait qu'on manque 
souvent d'une données de référence.



Données de l'ON3V des DRC :


Les Départements et Régions Cyclables (DRC) se sont frottés à la 
rationalisation des itinéraires et tente de maintenir à jour un 
référentiel des Véloroutes et Voies Vertes à travers l’Observatoire 
National des 3V (ON3V). Mais ils ont été obligés de traiter la données 
de manière très "géomatique" et de la décliner sous la forme de 
plusieurs bases de données. Leur travail est diffusé en "Open Data" 
(selon leurs termes) et on peut le télécharger dans différents formats 
depuis la page suivante :



https://www.departements-regions-cyclables.org/observatoires/observatoire-national-des-veloroutes-et-voies-vertes/


Pour les utilisateur de SIG type QGIS, la couche la plus intéressante 
est N_3V_SEGMENT_L.shp. De cette couche on peut faire une analyse 
thématique sur le champ "ID_ITI" puisque chaque valeur unique de ce 
champ correspond à une "continuité" pour laquelle les way appartiennent 
au/aux même(s) itinéraire(s) cyclable(s). Le rendu avec des couleurs 
aléatoires peut être observé à l'aide des liens suivants :



https://framapic.org/S7Uw3VeKvi0A/zqecqRI1Qrbd.jpg

https://framapic.org/S7Uw3VeKvi0A/zqecqRI1Qrbd?dl


Chaque portion devrait correspondre aux éléments de base, c'est-à-dire 
les enfants pour constituer les itinéraires parents. Le problème est 
qu'ils ne représentent plus rien de concret et sont donc compliqués à 
maintenir. Sans oublier que les données de l'ON3V ne présentent pas tous 
les itinéraires cyclables et ignorent très probablement un grand nombre 
d'itinéraires locaux.



Ma conclusion est qu’on peut découper les itinéraires pour mais on va 
créer énormément de petites relations pour lesquelles les tags restent 
encore affiner. Pour ma part j’aurais tendance à uniquement découper les 
grands itinéraires sur la base des étapes lorsqu’elles existent mais de 
créer une relation par itinéraire pour les plus petits itinéraires. 
C’est un sujet que j’aimerais bien travailler avec vous lors du prochain 
SotM.


On 26/12/2017 20:03, Axelos wrote:

Coucou,

Au sujet de ce sujet, j'avance j'avance, doucement mais sûrement.
J'ai donc copié mon brouillon sur une nouvelle page de proposition,
j'ai traduit en anglais, mais comme je ne maîtrise pas cette langue, il
y a de fortes chances que ce ne soit pas très compréhensible …

Si des personnes veulent bien m'aider en finalisant la traduction, ce
serait bien sympa !
La prochaine étape sera de porter ce travail au niveau OSM international.

https://wiki.openstreetmap.org/wiki/Hierarchies_route%3Dbicycle

Cordialement.

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


___

Re: [OSM-talk-fr] Portiques canténaires gare Asnieres sur Seine

2018-01-11 Per discussione Charles MILLET


Bonjour François,

Meersbrook est un contributeur assez actif sur la gare d'Asnière et 
d'autres gares parisiennes que l'on suit à Carot’Cité pour SNCF 
Transilien. Je suis de temps en temps amené à être en contact avec lui 
et je ne pense pas qu'il suive la list de discussion. Je te propose de 
lui transférer tes remarques dans le cadre de nos échanges.


Charles MILLET
charlesmil...@free.fr

Le 09/01/2018 à 12:31, François Lacombe a écrit :

Bonjour,

J'ai remarqué ces lignes déclarées sur les voies de part et d'autre de 
la gare d'Asnieres sur Seine.

http://www.openstreetmap.org/way/546842791

Elles doivent correspondre aux portiques qui supportent la caténaire, 
mais pourtant sont taguées avec power=line.
Les portiques de ce genre : 
http://www.duchene-sa.be/images/travaux/123_1283351800.jpg doivent 
être décris avec power=portal + operator=SNCF Reseau

Il n'y a pas lieu d'ajouter voltage ou frequency.

En revanche, ces éléments :
https://www.maketis.com/5805-large_default/poteau-pour-catenaire-25000-volts-dr20a-ou-dr20b-monte-jv-lybe-20abm.jpg
http://a407.idata.over-blog.com/1/61/14/74/cat-naires/P1070681.jpg
Sont décris avec power=catenary_mast + operator=SNCF Reseau

Si d'aventure certains voulaient tracer la caténaire elle-même, les 
connexions entre cette caténaire et les portiques peut se faire avec 
power=insulator sur le noeud.


Je ne peux pas corriger Asnieres dans l'immédiat, peut-être y a-t-il 
une page du wiki à modifier également ou d'autres cas en France ?



François


___
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] highway=path + bicycle=yes

2017-12-16 Per discussione Charles MILLET

Oui oui oui, je ne parle pas du tout de la modélisation du calculateur 
même si c'est la raison pour laquelle la discussion a été démarrée ; je 
parlais du fond de la question : qu'est qu'on met à la place de 
highway=path + bicycle=yes dans la situation décrite. On va pas 
reprendre toute la discussion, je disais simplement que mtb:scale=0 
serait, à mon avis et suite aux premiers échanges, une bonne solution 
envisageable, tu dis que selon toi mtb:scale=0 c'est bon pour les vélos 
de route, on a un petit peu argumenté à ce sujet et c'est la bonne 
pratique je pense mais là tu reparles de calculateur alors la discussion 
n'a plus trop de sens... Je pense qu'on est d'accord au final :) c'est 
plus qu'une question de curseur.



On 16/12/2017 16:34, marc marc wrote:

Bonjour,

Je ne saisis pas ce que tu proposes. d'ignorer purement et simplement
tous les chemins parce qu'ils ne sont parfois pas adapté à certains ?

Moi je proposais de faire comme pour les voitures : un bonu/malus selon
justement l'aspect "très adapté <> moins adapté".
Plusieurs calculs d’itinéraire voiture utilisent des bonus/malus selon
le type de route (autoroute > primary > track)
Il suffit de faire la même chose pour les vélos (piste cyclable > bande
cyclable > chemin).
Cela permet de proposer une itinéraire avec 100m dans un chemin de terre
plutôt qu'un détour de 10km de piste cyclable pour l'éviter.
Cela permet d'utiliser un maximum de données lorsqu'elles existent sans
"bloquer" lorsque des infos manquent.

Pour en revenir au sujet de départ, je ne vois pas ce qu'on peux tirer
comme "sens caché non documenté" d'un highway=path + bicycle=yes
On a vu différentes variantes (accès par défaut documenté dupliqué <>
peut-être le rendu <> peut-être la praticabilité).
Un outil qui utiliserait un de ces sens alternatif est voué à avoir un
gros taux d'erreur.
Ou on peux faire des outils qui encouragent l'utilisation des bons tags.
Pour moi le choix me semble limpide.

Si certains pensent qu'un bicycle:scale=0 est nécessaire pour rassurer
les craintes vis-a-vis d'un mtb:scale=0+surface+smothness, suffit de
proposer, mais j'ai l'impression qu'il y a déjà pas mal d'info existante
à utiliser.

Cordialement,
Marc

Le 16. 12. 17 à 15:20, Charles MILLET a écrit :

Il s'agit d'une description relative à la pratique du VTT, il faut donc
relativiser par définition. J'ai comme l'impression que la description
de mtb:scale=0 correspond justement aux cas décrits par Simon concernant
les chemins en forêt ; ceux pour lesquels certains ont précisé
bicycle=yes probablement pour que les calculateurs d'itinéraires les
prennent mieux en compte (ou pour du rendu aussi, c'est possible).

On peut mettre de coté la notion de pente, ça reste des chemins en
gravier ou en terre. Et encore une fois, il n'est pas question de dire
qu'ils ne sont pas praticables pour un vélo de ville mais bien
d'identifier qu'ils ne sont pas les plus adaptés.

Ensuite ça devient du débat pour le débat : quelle est la différence
entre « praticable » et « tout à fait praticable » ? Si on laisse un peu
les mots de coté pour regarder l'illustration, je n'enverrais pas
n'importe quel cycliste là dessus sous prétexte que la description
permet de conclure que c'est praticable ;)

Après on c'est pas mal éloigné du sujet maintenant :)

On 15/12/2017 16:48, marc marc wrote:

La description de mtb:scale=0, valeur la + base, me donne l'impression
que c'est tout a fait praticable en vélo de ville.
En tout cas pour ma part, un chemin sans pente, sans racine ni rocher,
sans virage sec etc, cela se pratique aisément en vélo électrique qui
est pourtant à l’opposé de la maniabilité d'un vtt.
Je pense donc que mtb:scale=0 -> adapté à tout type de vélo
tandis qu'à partir de 1 et +, ce n'est utilisable qu'en vtt.


___
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



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

Re: [OSM-talk-fr] highway=path + bicycle=yes

2017-12-16 Per discussione Charles MILLET

Il s'agit d'une description relative à la pratique du VTT, il faut donc 
relativiser par définition. J'ai comme l'impression que la description 
de mtb:scale=0 correspond justement aux cas décrits par Simon concernant 
les chemins en forêt ; ceux pour lesquels certains ont précisé 
bicycle=yes probablement pour que les calculateurs d'itinéraires les 
prennent mieux en compte (ou pour du rendu aussi, c'est possible).


On peut mettre de coté la notion de pente, ça reste des chemins en 
gravier ou en terre. Et encore une fois, il n'est pas question de dire 
qu'ils ne sont pas praticables pour un vélo de ville mais bien 
d'identifier qu'ils ne sont pas les plus adaptés.


Ensuite ça devient du débat pour le débat : quelle est la différence 
entre « praticable » et « tout à fait praticable » ? Si on laisse un peu 
les mots de coté pour regarder l'illustration, je n'enverrais pas 
n'importe quel cycliste là dessus sous prétexte que la description 
permet de conclure que c'est praticable ;)


Après on c'est pas mal éloigné du sujet maintenant :)

On 15/12/2017 16:48, marc marc wrote:

La description de mtb:scale=0, valeur la + base, me donne l'impression
que c'est tout a fait praticable en vélo de ville.
En tout cas pour ma part, un chemin sans pente, sans racine ni rocher,
sans virage sec etc, cela se pratique aisément en vélo électrique qui
est pourtant à l’opposé de la maniabilité d'un vtt.
Je pense donc que mtb:scale=0 -> adapté à tout type de vélo
tandis qu'à partir de 1 et +, ce n'est utilisable qu'en vtt.



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

Re: [OSM-talk-fr] highway=path + bicycle=yes

2017-12-15 Per discussione Charles MILLET


Bon ça répond à la question de l'utilisation du tag mtb=yes

Peut-être que pour l'aspect calculateur d'itinéraire, il faut considérer 
que mtb:scale=0 ce n'est pas très praticable par les vélos de route et 
qu'à partir de mtb:scale=1 ce n'est plus praticable. Le problème c'est 
que je ne vois presque jamais cette clé utilisée...



On 15/12/2017 12:34, Axelos wrote:

Le 15/12/2017 à 12:08, Simon Réau a écrit :

De nombreux sentier et chemin en forêt sont tagué avec highway=path +
bicycle=yes comme ici par exemple
http://www.openstreetmap.org/#map=15/49.0292/2.2712


J'ai déjà vu des cas où étaient utilisés carrément highway=cycleway pour
ce type de chemin !



Je me pose la question de la pertinence du bicycle=yes étant donné que tous
les types de vélo ne peuvent pas circulé. C'est chemins sont difficilement
praticables en vélo de ville ou vélo de route.
Pour le calcule d'itinéraire chez Géovélo cela nous pose un problème pour
définir les chemins praticables ou non. Le problème est contournable, mais
nous perdons en précision.

J'avais envie de remplacer le tag bicycle=yes par mtb=yes. Cela vous semble
t'il correcte ?

Pour ton cas, j'aurais plutôt tendance à décrire le chemin si possible,
c’est-à-dire donner des infos sur le revêtement du chemin et la qualité
du chemin.
http://wiki.osm.org/wiki/FR:Key:surface
http://wiki.osm.org/wiki/FR:Key:smoothness

En cherchant un peu sur le wiki, j'ai retrouvé cette page :
http://wiki.osm.org/wiki/Proposed_features/mtb
"Cette clé n'est plus nécessaire. Il n'est laissé que pour archivage.
Utilisez Proposed_features/mtb:scale à la place. Pour les restrictions
d'accès légales, utilisez bicycle=oui/non…"

Perso je n'ai jamais utilisé les balises pour les VTT, je ne m'avance
donc pas sur ce terrain.

___
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] highway=path + bicycle=yes

2017-12-15 Per discussione Charles MILLET

C'est vrai qu'on trouve souvent bicycle=yes sur des highway=path. Le 
problème du tag bicycle=yes est qu'il est strictement sensé précisé le 
caractère autorisé du vélo mais que souvent il est utilisé pour définir 
le caractère praticable et c'est là que les différentes pratiques du 
vélo entre en jeu...


mtb=yes pourrait effectivement permettre de commencer à distinguer les 
pratiques (ça fait un peu peur de mettre le doigt dans cet engrenage) 
sinon, c'est plus la clé surface qui devrait orienter la pratique. 
Taginfo indique que mtb=yes a déjà été souvent utilisé même s'il n'est 
pas documenté donc dans l'état des choses je dirais bien oui, dans ce 
genre de situation pourquoi pas procéder à ce replacement.


La question que je me pause, c'est : est-ce qu'on devrait compléter un 
peu le wiki et introduire ce tag et est-ce qu'on doit passer par le 
processus de vote ? Si tu es motivé on peut regarder pour mettre en 
place la proposition.


Bonne journée.


On 15/12/2017 12:08, Simon Réau wrote:

Bonjour,

De nombreux sentier et chemin en forêt sont tagué avec highway=path + 
bicycle=yes comme ici par exemple 
http://www.openstreetmap.org/#map=15/49.0292/2.2712


Je me pose la question de la pertinence du bicycle=yes étant donné que 
tous les types de vélo ne peuvent pas circulé. C'est chemins sont 
difficilement praticables en vélo de ville ou vélo de route.
Pour le calcule d'itinéraire chez Géovélo cela nous pose un problème 
pour définir les chemins praticables ou non. Le problème est 
contournable, mais nous perdons en précision.


J'avais envie de remplacer le tag bicycle=yes par mtb=yes. Cela vous 
semble t'il correcte ?



Cordialement

Simon



___
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] Problème de GPS = problème de cartographie ?

2017-11-27 Per discussione Charles MILLET

Super, avec les tag lanes et tout. J'ai un peu complété, reste plus qu'à 
attendre qu'OsmAnd mette à jour et tester.


Charles MILLET
charlesmil...@free.fr

Le 27/11/2017 à 09:16, david.croc...@free.fr a écrit :

Bonjour

J'ai rectifié 3 échangeurs, mais quand je vois le suivant, j'ai plus le 
morale...
Je verrais plus tard si j'ai envie

Cordialement



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

Re: [OSM-talk-fr] Ligne de bus Lila inexistante

2017-11-05 Per discussione Charles MILLET


Bonjour Adrien,

Il me semble que si ces lignes n'existent définitivement plus (et le 
site Lila semble l'indiquer) tu peux supprimer les relations.


Normalement toute action détectée suffisamment tôt doit pouvoir être 
annulée avec un "/revert/"... j'imagine qu'il doit bien y avoir quelques 
exceptions pour confirmer la règle.


Bonne journée.

Charles MILLET
charlesmil...@free.fr

Le 05/11/2017 à 12:08, Adrien Grellier a écrit :

Bonjour,

J'essaye de cartographier au mieux la ville de Sucé sur Erdre, au Nord
de Nantes.


Dans OpenStreetMap des lignes de bus régionale Lila passe à Sucé (ligne
40/41 notamment), mais ces lignes ont été supprimées il y a quelques
années, avec l'arrivée du tram-train.

Ces relations ont été marquées avec un FIXME=obsolete. Je suppose donc
qu'on peut la supprimer tranquillement ?

D'une manière générale, si je supprime une relation par erreur, il y a
des moyens pour annuler ma suppression ?


Bonne journée

Adrien

















___
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] 3 jours de carto partie à Caen – 13-15 oct.

2017-10-17 Per discussione Charles MILLET


Un bref retour sur les 3 jours de TurFu Festival à Caen :

J'ai pas les nombres exacts mais a priori plus de 2000 personnes sont 
passées. En plus des participants aux ateliers OSM, une centaine de 
personnes sont passés découvrir OSM pendant les 3 jours. Concernant les 
participants aux ateliers, environ 60 personnes le vendredi et samedi 
pour l'atelier cartoparti des arbres, deux naturalistes sont intervenus 
pour aider à l'identification des arbres, beaucoup d'étudiants le 
vendredi et une dizaine de personnes sur la thématique déchets du 
dimanche... et pas mal de "badges" ont été délivrés...


Merci beaucoup à Francescu Garoby et David Crochet pour leur aide pour 
accompagner les participants, merci à Vincent Bergeot et à ses contacts 
de francophonelibre.org pour l'accès au Tasking Manager.


Pour le retour d'expérience et la partage je dirais qu'un MapContrib qui 
tourne avec la bonne thématique c'est toujours bien utile pour initier 
les personnes de passage ; le Tasking Manager est un peu surdimensionné 
mais bien utile et pédagogique quand même surtout lorsqu'il est couplé 
avec un atlas papier. Enfin, plus on a d'écrans et d'ordinateurs pour 
faire tourner des outils, mieux c'est. Sinon, coup de chance, l'imagerie 
du Calvados de 2016 avait été ajoutée au fond Ortho IGN avant 
l'événement et on a pu en profiter.


Je me répète un peu mais voilà, le Dôme de Caen est vraiment un lieu 
super adapté pour organiser des événements type cartoparties et les 
acteurs sont de plus en plus convaincus et impliqués dans OpenStreetMap. 
On va d'ailleurs lancer une réflexion sur les Open Badge qui à mon avis 
sont un super outil mais c'est un autre sujet...


Charles MILLET
charlesmil...@free.fr

Le 03/10/2017 à 13:55, Charles MILLET a écrit :

Bonjour,

Je me permets encore d'utiliser la liste pour ce rappel : la 
cartopartie des arbres et la cartopartie « déchets » de la presqu'île 
de Caen sont dans une dizaine de jour.


Bonne journée

Charles MILLET
charlesmil...@free.fr

Le 13/09/2017 à 19:23, Charles MILLET a écrit :

Bonjour,

Le Dôme de Caen organise 3 jours de carto partie :
– 2 jours dédiés à la cartographie des arbres de la presqu'île de 
Caen (vendredi 13 et samedi 14 octobre) ;
– 1 jour pour la cartographie liée aux déchets (point d'apport 
volontaire, poubelle, etc.).


Le principe est entre autres d'utiliser OpenStreetMap comme un 
support de type « état des lieux » pour du dialogue autour de 
l'aménagement.


Ces carto parties sont organisées dans le cadre du Turfu Festival à 
l'invitation de Société Publique Locale d'Aménagement de la 
Presqu’île de Caen et de Suez. Le Turfu Festival est une 
manifestation portée par Le Dôme dans le cadre de la Fête de la 
science et co-organisée par Relais d’sciences et Casus Belli.


Voici les liens :

https://turfu-festival.fr/ateliers/carto-partie-les-arbres-de-la-presquile/ 


https://turfu-festival.fr/living-room/carto-partie/
https://turfu-festival.fr/living-room/carto-partie-environnement-dechets/ 



C'est sur inscription mais c'est relativement souple. N'hésitez pas à 
me contacter si vous avez des questions au sujet de ces carto 
parties. N'hésitez pas à partager, twitter, etc.


C'est la troisième fois que le dernier étage du Dôme (super toit 
terrasse avec une partie abritée) est mis à disposition pour des 
opérations d'initiation à OSM telles qu'une cartopartie et le lieu 
est bien adapté – un tout petit peu éloigné du centre mais puisqu'on 
s'intéresse plus particulièrement à la presqu'île, ce n'est pas très 
grave. La dernière fois j'ai eu le plaisir de croiser quelques 
contributeurs de la communauté Caennaise qui m'ont bien aidé et j'en 
profite pour les remercier et les inviter à nouveau.


Au delà de la carto partie j'invite la communauté à venir découvrir 
le Dôme qui est un lieu excellent à la philosophie très "libre" 
(http://ledome.info/).


PS: Il y a de l'imagerie HD récente en Normandie qui pourrait être 
utile. Je vois si son utilisation est simple et possible dans JOSM 
et/ou iD mais si quelqu'un a une remarque ou un conseil à ce sujet je 
suis preneur (j'ai vu que le sujet était un peu actif sur le talk, il 
faut que je reprenne ça).


Amicalement.




___
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] 3 jours de carto partie à Caen – 13-15 oct.

2017-10-03 Per discussione Charles MILLET


Bonjour,

Je me permets encore d'utiliser la liste pour ce rappel : la cartopartie 
des arbres et la cartopartie « déchets » de la presqu'île de Caen sont 
dans une dizaine de jour.


Bonne journée

Charles MILLET
charlesmil...@free.fr

Le 13/09/2017 à 19:23, Charles MILLET a écrit :

Bonjour,

Le Dôme de Caen organise 3 jours de carto partie :
– 2 jours dédiés à la cartographie des arbres de la presqu'île de Caen 
(vendredi 13 et samedi 14 octobre) ;
– 1 jour pour la cartographie liée aux déchets (point d'apport 
volontaire, poubelle, etc.).


Le principe est entre autres d'utiliser OpenStreetMap comme un support 
de type « état des lieux » pour du dialogue autour de l'aménagement.


Ces carto parties sont organisées dans le cadre du Turfu Festival à 
l'invitation de Société Publique Locale d'Aménagement de la Presqu’île 
de Caen et de Suez. Le Turfu Festival est une manifestation portée par 
Le Dôme dans le cadre de la Fête de la science et co-organisée par 
Relais d’sciences et Casus Belli.


Voici les liens :

https://turfu-festival.fr/ateliers/carto-partie-les-arbres-de-la-presquile/ 


https://turfu-festival.fr/living-room/carto-partie/
https://turfu-festival.fr/living-room/carto-partie-environnement-dechets/

C'est sur inscription mais c'est relativement souple. N'hésitez pas à 
me contacter si vous avez des questions au sujet de ces carto parties. 
N'hésitez pas à partager, twitter, etc.


C'est la troisième fois que le dernier étage du Dôme (super toit 
terrasse avec une partie abritée) est mis à disposition pour des 
opérations d'initiation à OSM telles qu'une cartopartie et le lieu est 
bien adapté – un tout petit peu éloigné du centre mais puisqu'on 
s'intéresse plus particulièrement à la presqu'île, ce n'est pas très 
grave. La dernière fois j'ai eu le plaisir de croiser quelques 
contributeurs de la communauté Caennaise qui m'ont bien aidé et j'en 
profite pour les remercier et les inviter à nouveau.


Au delà de la carto partie j'invite la communauté à venir découvrir le 
Dôme qui est un lieu excellent à la philosophie très "libre" 
(http://ledome.info/).


PS: Il y a de l'imagerie HD récente en Normandie qui pourrait être 
utile. Je vois si son utilisation est simple et possible dans JOSM 
et/ou iD mais si quelqu'un a une remarque ou un conseil à ce sujet je 
suis preneur (j'ai vu que le sujet était un peu actif sur le talk, il 
faut que je reprenne ça).


Amicalement.




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

[OSM-talk-fr] 3 jours de carto partie à Caen – 13-15 oct.

2017-09-13 Per discussione Charles MILLET


Bonjour,

Le Dôme de Caen organise 3 jours de carto partie :
– 2 jours dédiés à la cartographie des arbres de la presqu'île de Caen 
(vendredi 13 et samedi 14 octobre) ;
– 1 jour pour la cartographie liée aux déchets (point d'apport 
volontaire, poubelle, etc.).


Le principe est entre autres d'utiliser OpenStreetMap comme un support 
de type « état des lieux » pour du dialogue autour de l'aménagement.


Ces carto parties sont organisées dans le cadre du Turfu Festival à 
l'invitation de Société Publique Locale d'Aménagement de la Presqu’île 
de Caen et de Suez. Le Turfu Festival est une manifestation portée par 
Le Dôme dans le cadre de la Fête de la science et co-organisée par 
Relais d’sciences et Casus Belli.


Voici les liens :

https://turfu-festival.fr/ateliers/carto-partie-les-arbres-de-la-presquile/
https://turfu-festival.fr/living-room/carto-partie/
https://turfu-festival.fr/living-room/carto-partie-environnement-dechets/

C'est sur inscription mais c'est relativement souple. N'hésitez pas à me 
contacter si vous avez des questions au sujet de ces carto parties. 
N'hésitez pas à partager, twitter, etc.


C'est la troisième fois que le dernier étage du Dôme (super toit 
terrasse avec une partie abritée) est mis à disposition pour des 
opérations d'initiation à OSM telles qu'une cartopartie et le lieu est 
bien adapté – un tout petit peu éloigné du centre mais puisqu'on 
s'intéresse plus particulièrement à la presqu'île, ce n'est pas très 
grave. La dernière fois j'ai eu le plaisir de croiser quelques 
contributeurs de la communauté Caennaise qui m'ont bien aidé et j'en 
profite pour les remercier et les inviter à nouveau.


Au delà de la carto partie j'invite la communauté à venir découvrir le 
Dôme qui est un lieu excellent à la philosophie très "libre" 
(http://ledome.info/).


PS: Il y a de l'imagerie HD récente en Normandie qui pourrait être 
utile. Je vois si son utilisation est simple et possible dans JOSM et/ou 
iD mais si quelqu'un a une remarque ou un conseil à ce sujet je suis 
preneur (j'ai vu que le sujet était un peu actif sur le talk, il faut 
que je reprenne ça).


Amicalement.

--
Charles MILLET
charlesmil...@free.fr


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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

2017-08-11 Per discussione Charles MILLET

Je fais parti des 1% des 0,01% et qui en plus habite en zone rural. j'en 
conclu que je suis peut-être le seul ;) mais je suis pas sûr...


Charles MILLET
charlesmil...@free.fr

Le 10/08/2017 à 19:58, osm.sanspourr...@spamgourmet.com a écrit :

Le 08/08/2017 à 02:22, Philippe Verdy - verd...@wanadoo.fr a écrit :
C'est moins la question du copyright que le fait que le contenu de 
l'URL est hors de contrôle et peut contenir n'importe quoi. Et aussi 
ne pas être facilement accessible (les données OISM ne sont pas 
destinées à n'être utilisée que online, on fait quoi pour les cartes 
embarquées?)
On parle bien des 1 % de gens qui utilisent une carte embarquée pour 
voir les horaires de 0,01 % des descriptions qui dépasserait 255 
caractères ?
De plus comme OSMAND peut prendre un extrait de page Wikipédia hors 
ligne, un outil pourrait récupérer une version simplifiée de la page 
horaires. Oui en prenant les précautions idoines ce qui n'est pas simple.


Fantasque ou pas, on a des tas de trucs comme ça dans le monde rural 
où les hoaires ne sont pas aussi larges que dans les grandes villes, 
compliqués par la présence d'une seule personne qui va travailler 
partiellement pour la structure et en fonction des besoins.

ainsi nombre de (...) vont changer régulièrement les horaires

Dans ce cas :
- si c'est vraiment rural, il est peut probable qu'un contributeur 
saisisse les horaires (on a moins de contributeurs dans le monde rural)
- si ça change, ça ne fait pas plus de 255 caractères, ça fait un tag 
à redéfinir régulièrement. On n'a pas besoin en août 2017 de savoir 
qu'en juillet 2017, untel n'était pas dispo car en juillet 2018 ce ne 
sont pas les horaires de 2017 qui s'appliqueront.


Tu nous fais des stats sur la longueur du tag ?
J'ai vu à la 65ième page de taginfos :
opening_hours=Nov-Jan␣07:45-18:00;␣Feb␣07:45-18:30;␣Mar␣1-15␣07:45-19:00;␣Mar␣16-31␣07:45-19:30;Apr␣07:45-20:00;May␣07:45-20:30;Jun-Aug␣07:45-21:00;Sep␣1-15␣07:45-20:30;␣Sep␣16-30␣07:45-19:30;Oct␣1-15␣07:45-19:00;Oct␣16-31␣07:45-18:30
220 caractères.

En partant de l'autre bout on tombe logiquement plus vite sur de 
grandes chaînes :

Nov␣01-Feb␣29␣Mo-Fr␣08:00-12:00,13:00-18:00;␣Nov␣01-Feb␣29␣Sa␣09:00-16:00␣"Werkstatt␣geschlossen";␣Mar␣01-Oct␣31␣Mo-Fr␣08:00-12:00,13:00-18:30;␣Mar␣01-Oct␣31␣Sa␣08:00-16:00␣"Werkstatt␣geschlossen";␣Dec␣01-Jan␣31␣Mo␣off;␣PH␣off
Tu m'expliqueras comment le logiciel sait que la partie atelier est 
fermée ;-). 226 caractères.
Les solutions propres ressemblent au cas proposé pour Emmaüs. Et oui 
si on prend un {repair=no}


Relâcher la contrainte de 255 caractères est sans doute possible dans 
tous les logiciels utilisés, mais est-ce que ça ne va pas pénaliser 
les performances ? Mais planter des logiciels (ou corruption des 
données par outil pas à jour) pour quelques valeurs semble faire 
pencher la balance du côté du statuquo.


Jean-Yvon


___
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] Valeur opening_hours supérieure à 255 caractères

Merci pour les différentes versions. Je ne connaissais pas cette façon 
de « contourner » la limite des 255.


Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 15:19, Philippe Verdy a écrit :

Autre solution si ce n'est pas assez clair avec des "@":

opening_hours=Sep-Jun {opening_hours["en période scolaire"]};Jul-Aug 
{opening_hours["durant l'été"]}
opening_hours["en période scolaire"]=Mo,Th 11:30-14:00;Tu 
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours["durant l'été"]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th 
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su 
09:00-12:00,14:00-19:00


Là on utilise des {accolades} pour indiquer explicitement le nom du 
tag complet (le sous-tag est un nom libre, éventuellement entre 
guillemets pour indiquer un libellé pouvant être affiché tel quel 
destiné à l'utilisateur et pouvant contenir des caractères "spéciaux 
ou des espaces), mais pouvant aussi bien être interprété de façon 
opaque si on ne l'affiche pas car la langue n'est pas adaptée), ou 
juste (le nom du tag complet est déduit du contenu des accolades on 
peut reprendre les crochets et éliminer les guillemets.


opening_hours=Sep-Jun [en période scolaire];Jul-Aug [durant l'été]
opening_hours[en période scolaire]=Mo,Th 11:30-14:00;Tu 
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours[durant l'été]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th 
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su 
09:00-12:00,14:00-19:00


C'est un problème générique, mais la syntaxe doit être claire et 
légère avant de l'adopter.


Le 26 juillet 2017 à 15:07, Philippe Verdy <verd...@wanadoo.fr 
<mailto:verd...@wanadoo.fr>> a écrit :




Le 26 juillet 2017 à 15:03, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :

Noter qu'on ne serait pas obligé non plus de factoriser les
conditions, et il suffirait aussi de référencer  des régles
autosuffisantes:

opening_hours=@1;@2
opening_hours:1=Sep-JunMo,Th 11:30-14:00;Sep-JunTu
11:30-14:00,16:45-21:00;Sep-JunWe 11:30-14:15;Sep-JunFr
11:30-13:30,17:30-20:15;Sep-JunSa 14:00-18:00;Sep-JunSu
09:30-12:30,15:00-18:00
opening_hours:2=Jul-AugMo,Sa 14:00-19:00;Jul-AugTu
10:00-11:30;Jul-AugWe,Th 10:00-11:30,14:00-19:00;Jul-AugFr
10:00-11:30,14:00-21:00;Jul-AugSu 09:00-12:00,14:00-19:00


Ou même encore:

opening_hours=Sep-JunMo,Th 11:30-14:00;Sep-JunTu
11:30-14:00,16:45-21:00;Sep-JunWe 11:30-14:15;Sep-JunFr
11:30-13:30,17:30-20:15;Sep-JunSa 14:00-18:00;Sep-JunSu
09:30-12:30,15:00-18:00;@2
opening_hours:2=Jul-AugMo,Sa 14:00-19:00;Jul-AugTu
10:00-11:30;Jul-AugWe,Th 10:00-11:30,14:00-19:00;Jul-AugFr
10:00-11:30,14:00-21:00;Jul-AugSu 09:00-12:00,14:00-19:00


 le @2 permettant d'indiquer dans quel tag (opening_hours:2) se
situe la suite (sans lui adjoindre aucun critère "factorisé")




___
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] Valeur opening_hours supérieure à 255 caractères


Ok, ça m'a échappé dans le Wiki, j'approfondirai ça.

Merci encore pour ton retour.

Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 15:22, David Crochet a écrit :

Bonjour

Sauf que tu n'avais pas mis les ":" à tes définitions ce qu'il fait 
qu'ils faut les répéter après chaque ";".


Avec le ":", si je ne me trompe pas, l'attribut va jusqu'au ":" 
suivant quel que soit le nombre de ";" entre



Cordialement




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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères


Merci pour vos retours.

J'avais pensé à factoriser mais je pensais aussi  les ";" sont là pour 
marquer des ensembles fermes et que les deux période "Sep-Jun:" et 
"Jul-Aug:" en début de période ne devaient pas être suffisamment explicites.


Par contre effectivement pour es espaces en trop il faudra que je fasse 
attention.


Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 14:42, Philippe Verdy a écrit :
C'est une autre façon de "factoriser" les mois, mais cette syntaxe est 
aussi une extension, et je ne suis pas convaincu car le ";" sépare 
TOUS les éléments et rien n'indique que "Sep-Jun:" s'applique comme 
critère à tous ce qui suit mais pas à la partie commençant par 
"Jul:Aug:". (noter encore que les espaces après ";" sont excédentaires)


Je pense que l'éclatement (avec un @ pour référencer une sous-règle) 
donne quelque chose de plus clair et plus facilement maintenable, 
chaque sous-règle restant elle-aussi indépendante indépendamment du 
filtre qu'on lui applique dans une règle "mère".



Le 26 juillet 2017 à 14:35, David Crochet <david.croc...@free.fr 
<mailto:david.croc...@free.fr>> a écrit :


Bonjour


Le 26/07/2017 à 14:07, Charles MILLET a écrit :

Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00;
Sep-Jun We 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15;
Sep-Jun Sa 14:00-18:00; Sep-Jun Su 09:30-12:30,15:00-18:00;
Jul-Aug Mo,Sa 14:00-19:00; Jul-Aug Tu 10:00-11:30; Jul-Aug
We,Th 10:00-11:30,14:00-19:00; Jul-Aug Fr
10:00-11:30,14:00-21:00; Jul-Aug Su 09:00-12:00,14:00-19:00


Sep-Jun: Mo,Th,Tu 11:30-14:00; Tu 16:45-21:00; We 11:30-14:15; Fr
11:30-13:30,17:30-20:15; Sa 14:00-18:00; Su
09:30-12:30,15:00-18:00; Jul-Aug: Mo,Sa,We,Th,Su 14:00-19:00;
We,Th,Fr,Tu 10:00-11:30; Fr 14:00-21:00; Su 09:00-12:00

Cordialement

-- 
David Crochet



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




___
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] Valeur opening_hours supérieure à 255 caractères