[OSM-talk-fr] idée idiote pour les apk

[Jacques Foucry]

Coucou,

J'utilise plusieurs applications qui utilisent OSM et chacune télécharge
les cartes dont j'ai besoin (en gros la France métropolitaine, soit 1,24
GB de données).

Multiplié par le nombre d'application, ça fini par faire beaucoup.

Ne serait-il pas bon de demander aux développeurs d'application de voir
(demander) si les cartes ne serait pas déjà présente et si c'est le cas
utiliser celles-ci.
Et à la désinstallation de l'application NE PAS supprimer les cartes si
une autre applications les utilisent.

Jacques

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

Re: [OSM-talk-fr] idée idiote pour les apk

[Eric Gillet]

On Sun, Jul 29, 2018 at 9:20 AM Jacques Foucry 
wrote:

> J'utilise plusieurs applications qui utilisent OSM et chacune télécharge
> les cartes dont j'ai besoin (en gros la France métropolitaine, soit 1,24
> GB de données).
>
> Ne serait-il pas bon de demander aux développeurs d'application de voir
> (demander) si les cartes ne serait pas déjà présente et si c'est le cas
> utiliser celles-ci.
>

Le problème c'est que quasiment chaque application a son propre format de
stockage de carte optimisé. Maps.me, OSMAnd par exemple ne sont pas
compatibles entre-elles, même si c'est Openstreetmap derrière.
Cette optimisation est nécessaire pour que la recherche, routage etc soit
rapide sur l'appareil, et rendre compatible les applis avec les différents
formats me semble pas envisageable en terme de temps de développement
malheureusement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] idée idiote pour les apk

[marc marc]

Le 29. 07. 18 à 11:04, Eric Gillet a écrit :
> On Sun, Jul 29, 2018 at 9:20 AM Jacques Foucry wrote:
> 
> J'utilise plusieurs applications qui utilisent OSM et chacune télécharge
> les cartes dont j'ai besoin (en gros la France métropolitaine, soit 1,24
> GB de données).
> 
> Ne serait-il pas bon de demander aux développeurs d'application de voir
> (demander) si les cartes ne serait pas déjà présente et si c'est le cas
> utiliser celles-ci.
> 
> 
> Le problème c'est que quasiment chaque application a son propre format 
> de stockage de carte optimisé. Maps.me, OSMAnd par exemple ne sont pas 
> compatibles entre-elles, même si c'est Openstreetmap derrière.

Il suffirait que les devs se mettent d'accord sur un format...
Mais sûrement que chaque dev trouvera que son format est le meilleur :(
sans compter que maps.me n'utilise pas réellement les données osm
mais un affreux hybride entre osm et des sources diverses, cfr le 
problème récurent des hôtels.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] idée idiote pour les apk

[Jo]

Si les devs étaient disposés à faire cela, ils l'auraient déjà fait il y a
longtemps, ou Maps.Me n'aurait pas inventé un nouveau format.

Bien sûr c'est rendu plus complqué par le fait que Android limite les
applications à leur propre espace 'home'. Il faudrait donc un troisième app
'service' pour stocker ces données.

Il serait déjà bien s'ils pouvaient faire cela pour l'imagerie aérienne.

Jo

Op zo 29 jul. 2018 om 11:54 schreef marc marc :

> Le 29. 07. 18 à 11:04, Eric Gillet a écrit :
> > On Sun, Jul 29, 2018 at 9:20 AM Jacques Foucry wrote:
> >
> > J'utilise plusieurs applications qui utilisent OSM et chacune
> télécharge
> > les cartes dont j'ai besoin (en gros la France métropolitaine, soit
> 1,24
> > GB de données).
> >
> > Ne serait-il pas bon de demander aux développeurs d'application de
> voir
> > (demander) si les cartes ne serait pas déjà présente et si c'est le
> cas
> > utiliser celles-ci.
> >
> >
> > Le problème c'est que quasiment chaque application a son propre format
> > de stockage de carte optimisé. Maps.me, OSMAnd par exemple ne sont pas
> > compatibles entre-elles, même si c'est Openstreetmap derrière.
>
> Il suffirait que les devs se mettent d'accord sur un format...
> Mais sûrement que chaque dev trouvera que son format est le meilleur :(
> sans compter que maps.me n'utilise pas réellement les données osm
> mais un affreux hybride entre osm et des sources diverses, cfr le
> problème récurent des hôtels.
> ___
> 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] idée idiote pour les apk

[Francois Gouget]

On Sun, 29 Jul 2018, Jo wrote:

> Si les devs étaient disposés à faire cela, ils l'auraient déjà fait il y a
> longtemps, ou Maps.Me n'aurait pas inventé un nouveau format.

Maps.me est une chose : c'est une application propriétaire avec ses 
propres priorités et la compatibilité avec Osmand ne va forcément pas en 
faire partie.

Mais être obligé d'avoir de la data pour visualiser la carte dans 
StreetComplete alors que j'ai les cartes offline dans Osmand c'est assez 
idiot. Pareil pour la myriade d'autres applications OpenStreetMap 
open-source.

Bon je suppose que le problème c'est que StreetComplete ne fait que 
récupérer des tuiles alors qu'Osmand fait un rendu vectoriel, soit deux 
implémentations complètement différentes. C'est justement là qu'un 
service commun de rendu de fond de carte serait utile : moins de code, 
partage des cartes locales, cache de tuiles commun, réduction de la 
consommation de données, etc.


-- 
Francois Gouget   http://fgouget.free.fr/
   Be careful of reading health books, you might die of a misprint.
 -- Mark Twain___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[deuzeffe]

Bonjour,

En relation avec le projet du mois (voire de l'année ^^) et attentive à 
la QA d'osm, j'ai vu que le validateur de josm remontait des erreurs 
sous prétexte que operator=RTE est obsolète (ce en quoi il n'a pas tort, 
il me semble).


On est bien d'accord que pour ce qui est du transport on est passé d'EDF 
à ERDF puis à RTE puis à Enedis. J'ai bon ?


Pour ce qui est de mon département (le 87), il y presque 700 objets 
(points, lignes, polygones) encore attribués à RTE (ce qui est normal 
suivant la date de saisie des info.).


Donc, ne serait-il pas judicieux de corriger automatiquement ce tag 
operator=RTE (plus quelques ERDF qui traînent encore) en operator=Enedis ?


Et comme c'est celui (celle en l'occurrence) qui dit qui fait, je me 
propose de me lancer dans l'ae en question (en commençant petit, avec 
ceinture et bretelles et récolte de conseils et tuto kivonbien avant ^^).


Donc,
1/ on fait la correction ?
2/ qui la fait ?

Merci pour les réponses, quelles qu'elles soient.
--
deuzeffe


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

Re: [OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[Vincent Privat]

Le 29 juillet 2018 à 15:11, deuzeffe  a écrit :

> j'ai vu que le validateur de josm remontait des erreurs sous prétexte que
> operator=RTE est obsolète
>

Euh, je m'inscris en faux, JOSM ne fait pas ça. Si tu as eu des erreurs
c'est pour une autre raison.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] traduction et glossaire

[Julien Lepiller]

Bonjour à tous !

Étant motivé par la traduction (en particulier pour HebdoOSM, et de
manière moins soutenue pour les éditeurs), je me rends compte qu'il n'y
a pas beaucoup d'harmonisation des termes entre les projets de
traduction. S'il y a des traducteurs sur la liste, j'aimerais avoir
votre avis sur des termes courants dans le contexte d'OSM :

« a tag », « to tag », « tagging »

L'idée est de traduire toujours le même terme par un même terme, mais
avoir des traductions différentes pour des termes qui désignent des
concepts différents.

Pour ma part, je traduis toujours tag par attribut. Les deux autres
mots sont plus difficiles. Je trouve que « attribuer » ne correspond
pas au sens. Pour moi « étiqueter » ou « qualifier » correspondent
plus, mais je ne les ai encore jamais utilisés dans les traductions
parce que j'y trouve déjà des versions dérivées de l'anglais.

Des avis ?

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

Re: [OSM-talk-fr] traduction et glossaire

[marc marc]

Le 29. 07. 18 à 15:47, Julien Lepiller a écrit :
> « a tag », « to tag », « tagging »
> je traduis toujours tag par attribut.

je n'y avais pas pensé mais c'est une bonne traduction

to tag : renseigner, cartographier

c'est là qu'on rêve d'un système global pour la traduction osm
au lieu de faire x fois la même chose pour chaque projet :(
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] idée idiote pour les apk

[marc marc]

Le 29. 07. 18 à 14:05, Francois Gouget a écrit :
> On Sun, 29 Jul 2018, Jo wrote:
> 
>> Si les devs étaient disposés à faire cela, ils l'auraient déjà fait il y a
>> longtemps, ou Maps.Me n'aurait pas inventé un nouveau format.
> 
> Maps.me est une chose : c'est une application propriétaire avec ses
> propres priorités et la compatibilité avec Osmand ne va forcément pas en
> faire partie.

une partie est opensource, il y a d'ailleurs un fork android 
communautaire sans les bricolages problématiques (mais je nel'ai jamais 
testé, de ce que j'en ai eu, c'est pas tres stable niveau maj carte)

> Mais être obligé d'avoir de la data pour visualiser la carte dans
> StreetComplete alors que j'ai les cartes offline dans Osmand c'est assez
> idiot. Pareil pour la myriade d'autres applications OpenStreetMap
> open-source.

on ne perd rien à tenter de proposer cela sur la ml osm-dev et/ou sur 
les sites de l'un ou l'autre éditeur d'app

> Bon je suppose que le problème c'est que StreetComplete ne fait 
> que récupérer des tuiles

vraiment ?
ce ne serrait pas très efficace puisqu'en même temps streetcomplete
a besoin des données "brutes" pour pouvoir faire l'édition
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[François Lacombe]

Bonjour Deuzeffe,

Le 29 juillet 2018 à 15:11, deuzeffe  a écrit :

> Bonjour,
>
> En relation avec le projet du mois (voire de l'année ^^)


Et de l'incident de Montparnasse, il n'est pas un luxe de connaitre la
différence entre EDF, RTE et Enedis.


> j'ai vu que le validateur de josm remontait des erreurs sous prétexte que
> operator=RTE est obsolète (ce en quoi il n'a pas tort, il me semble).
>
Non, comme Vincent je pense qu'il ne fait pas ça.
Il doit y avoir une autre raison.


> On est bien d'accord que pour ce qui est du transport on est passé d'EDF à
> ERDF puis à RTE puis à Enedis. J'ai bon ?
>

Non, Enedis s'occupe de la distribution pour 95% de la population (70% du
territoire)
On est passé de EDF à RTE pour le transport uniquement. EDF exploite encore
ses systèmes privés, dans les centrales nucléaires ou hydraulique par
exemple.


> Pour ce qui est de mon département (le 87), il y presque 700 objets
> (points, lignes, polygones) encore attribués à RTE (ce qui est normal
> suivant la date de saisie des info.).
>
Et ils doivent le rester


> Donc, ne serait-il pas judicieux de corriger automatiquement ce tag
> operator=RTE (plus quelques ERDF qui traînent encore) en operator=Enedis ?
>

Uniquement operator=ERDF vers operator=Enedis après avoir soigneusement
regardé si Enedis était bien distributeur dans la commune concernée.
https://opendata.agenceore.fr/pages/g2_/

J'ai pu le faire sur Savoie / Haute-Savoir déjà, ca a entrainé un énorme
trou sur operator=ERDF pour la bonne cause
Tu peux continuer si tu trouves des objets avec operator=ERDF, en tout ca
ce ne sera pas inutile
Il faudra indiquer la source et un commentaire disant que ce n'est pas un
retag automatique dans le changeset pour pas que les administrateur s'en
inquiètent.

En espérant que ces précisions rendent les choses plus claires

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

Re: [OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[deuzeffe]

On 29/07/2018 15:40, Vincent Privat wrote:

Le 29 juillet 2018 à 15:11, deuzeffe  a écrit :


j'ai vu que le validateur de josm remontait des erreurs sous prétexte que
operator=RTE est obsolète



Euh, je m'inscris en faux, JOSM ne fait pas ça. Si tu as eu des erreurs
c'est pour une autre raison.


Damnède, tu as raison, j'ai confondu ERDF et RTE (oui, bon ça va). Je 
viens de reproduire l'erreur : le validateur dit bien que ERDF est 
déprécié et qu'il faut mieux utiliser Enedis à la place (par ex. Node 
2572266261).


Donc, est-ce que la correction s/ERDF/Enedis pour operator= est légitime ?

(merci WP de m'avoir appris que suivant la tension et donc si c'est 
transport ou distribution, la société qui gère n'est pas la même... 
Pourquoi faire simple quand on peu faire compliqué ?)


--
deuzeffe




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

Re: [OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[François Lacombe]

Le 29 juillet 2018 à 16:12, deuzeffe  a écrit :

> Damnède, tu as raison, j'ai confondu ERDF et RTE (oui, bon ça va). Je
> viens de reproduire l'erreur : le validateur dit bien que ERDF est déprécié
> et qu'il faut mieux utiliser Enedis à la place (par ex. Node 2572266261).
>

Ca oui, il y a bien une validation dans JOSM pour ça.

Donc, est-ce que la correction s/ERDF/Enedis pour operator= est légitime ?
>

Oui en vérifiant sommairement chaque objet
Il faut partir du principe que tu vas trouver des erreurs. Sinon c'est
qu'il faut revérifier jusqu'à en trouver une :)


> (merci WP de m'avoir appris que suivant la tension et donc si c'est
> transport ou distribution, la société qui gère n'est pas la même...
> Pourquoi faire simple quand on peu faire compliqué ?)


C'est du réglementaire, et l'ouverture du marché de l'électricité.
La production, le transport et la distribution (en plus de la vente) sont 3
fonctions indépendantes.

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

Re: [OSM-talk-fr] Correction massive de operator=RTE (ou ERDF) en operator=Enedis

[deuzeffe]

On 29/07/2018 16:16, François Lacombe wrote:


Donc, est-ce que la correction s/ERDF/Enedis pour operator= est légitime ?




Oui en vérifiant sommairement chaque objet


Donc, ok, pour la correction. Jusque là.


Il faut partir du principe que tu vas trouver des erreurs. Sinon c'est
qu'il faut revérifier jusqu'à en trouver une :)


Yep. Il en reste  (même des nœuds que tu as modifiés il y a bien 
longtemps ^^)



(merci WP de m'avoir appris que suivant la tension et donc si c'est
transport ou distribution, la société qui gère n'est pas la même...
Pourquoi faire simple quand on peu faire compliqué ?)
 
C'est du réglementaire, et l'ouverture du marché de l'électricité.

La production, le transport et la distribution (en plus de la vente) sont 3
fonctions indépendantes.


J'avais bien en tête la séparation de la fonction production des autres 
fonctions. En revanche, la subtile différence entre transport et 
distribution m'avait complètement échappé.


Va falloir maintenant que j'apprenne à me servir des outils qui vont bien...

--
deuzeffe, qui aime bien en apprendre tous les jours et se coucher moins 
ignorante.


___
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

[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

[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.



___
Talk-fr mailing list
Talk-fr@ope

Re: [OSM-talk-fr] Présentation rapide

[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] traduction et glossaire

[Philippe Verdy]

au sens propre "tag" c'est une étiquette (comprend aussi les "hashtags" qui
n'en sont qu'une forme particulière commençant par un symbole distinctif).
Attribut est le meilleur terme pour le nom, mais en tant que verbe je pense
que le meilleur terme le plus clair est "marquer" (on pourrait aussi
utiliser "étiqueter").

"Qualifier" correspond à une concept plus restrictif (qui s'oppose à
"quantifier", ou "identifier") et est destiné à apporter plutôt une
restriction sémantique, alors que tous les tags ne sont pas des
restrictions, juste des informations.
De plus "qualifier" peut inclure des éléments "subjectifs", alors que la
plupart des infos dans OSM devrait être "objectives".
En revanche l'anglicisme "tagguer" ou "taguer" ou "tagger" est horrible !

Je vois très bien en revanche le sens de "marquer les objets avec les
attributs suivants".


Le 29 juillet 2018 à 15:47, Julien Lepiller  a écrit :

> Bonjour à tous !
>
> Étant motivé par la traduction (en particulier pour HebdoOSM, et de
> manière moins soutenue pour les éditeurs), je me rends compte qu'il n'y
> a pas beaucoup d'harmonisation des termes entre les projets de
> traduction. S'il y a des traducteurs sur la liste, j'aimerais avoir
> votre avis sur des termes courants dans le contexte d'OSM :
>
> « a tag », « to tag », « tagging »
>
> L'idée est de traduire toujours le même terme par un même terme, mais
> avoir des traductions différentes pour des termes qui désignent des
> concepts différents.
>
> Pour ma part, je traduis toujours tag par attribut. Les deux autres
> mots sont plus difficiles. Je trouve que « attribuer » ne correspond
> pas au sens. Pour moi « étiqueter » ou « qualifier » correspondent
> plus, mais je ne les ai encore jamais utilisés dans les traductions
> parce que j'y trouve déjà des versions dérivées de l'anglais.
>
> Des avis ?
>
> ___
> 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] idée idiote pour les apk

[PanierAvide]

Le 29/07/2018 à 16:01, marc marc a écrit :

vraiment ?
ce ne serrait pas très efficace puisqu'en même temps streetcomplete
a besoin des données "brutes" pour pouvoir faire l'édition


Le fond de carte se base sur des tuiles vectorielles (Mapbox ?), et les 
données sont issues de requêtes Overpass. Ça peut sembler surprenant 
mais les tuiles vectorielles contiennent des infos "light", qui ne sont 
pas suffisantes pour le niveau de détail que demande StreetComplete.


Adrien.

--
PanierAvide
Géomaticien & développeur


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

Re: [OSM-talk-fr] Signalisation routiere

[David Crochet]

Bonjour


Le 28/07/2018 à 18:54, Philippe Verdy a écrit :
"private" ici (qui est faux dans ce cas, s'il s'agit en fait de 
navettes **publiques**)


« Private » ne veut pas dire « privée » mais  « Access is only with 
permission on an individual basis. » ce qui revient à dire «a qui on a 
donné la permission d'utiliser »


Cordialement

--
David Crochet


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

[OSM-talk-fr] Panneau de prescription - validité de la prescription après un carrefour

[David Crochet]

Bonjour

On parle actuellement des limitations de vitesse différente et remontée 
à 90 km/h dans la cas de 2 voies contiguës affectées à un même sens de 
circulation et sur ces seules voies.


Pour les prescriptions limitant les vitesses, il existent aussi une 
règle qui dit que la prescription disparaît naturellement lors d'un 
franchissement d'un carrefour (ce qui exclu les chemins privée non 
ouvertes à la circulation publique et les chemin de terre ) [ alinéa «e» 
de l'article 63 de l'instruction interministérielle sur la signalisation 
routière].


Devons-nous appliquer cette règle qui indique que l'abaissement au 
préalable du carrefour devient caduque après la franchissement de 
celui-ci ? La règle d'usage prévaudrait que oui.


Or, il est souvent à constater qu'après ces carrefours, il y a 
quasi-généralement l'implantation d'un panneau de fin de prescription, 
comme si l'usage voudrait que la prescription ait encore cours sur ces 
lieux.


Qu'en est-il de l’application de cette règle de limitation de vitesse 
prescrite de facto et sans nouvelle prescription dans OSM ?


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Signalisation routiere

[Philippe Verdy]

access=no et access=private serait équivalent dans ce cas: toutes les voies
dans OSM sont accessibles par quelqu'un, sinon ce ne sont même pas des
voies !

je pense plutôt que "access=private" veut dire que cela ne fait pas partie
du domaine public, et que l'autorisation est à obtenir de l'occupant local
mais ne peut être donnée à distance à d'autres, et donc ne s'applique pas
par exemple aux voies construites sur le domaine privé mais avec un accès
destiné au public comme les voies de centres commerciaux, ou les voies
d'accès "visiteurs" désignées dans des sites d'entreprises ou parcs, où il
y a une claire séparation dans ce qui est accessible sans autorisation
individuelle préalable et ce qui est réservé aux seuls personnels habilités
(et normalement fermé par une barrière ou un panneau indicateur posé par
l'exploitant).

En ouvrant un accès destiné au public (aux visiteurs), un exploitant donne
une autorisation explicite (mais non individuelle) et doit dans ce cas se
soumettre à des obligations publiques en terme de signalisation et
sécurité, même si c'est construit sur son domaine privé.

On peut aussi ignorer le cas des accès d'urgence (autorisés partout en
France et à tout moment sans autorisation individuelle préalable, les
autorités pouvant alors compenser les éventuels dommages subis du fait du
passage des services publics d'urgence, mais c'est rare et en cas de
nécessité impérieuse, une décision préfectorale peut être prise et le
propriétaire pourra se retourner en justice de la réquisition publique de
sa voie privée; sinon il y a des cas d'urgence où ce sont les assurances
qui prennent en charge les dégats, par exemple pour permettre l'évacuation
par des terrains privés en cas de danger ou dégâts subis sur la voie
publique, la sécurité prime par exemple en cas d'incendie, avalanche,
inondation, glissement de terrain, pollution dangereuse, accident
industriel majeur, ou autres catastrophes et alertes de sécurité publique
qui nécessitent un plan d'évacuation: les propriétaires ont un devoir
d'assistance à personnes en danger même s'ils peuvent ensuite être
indemnisés, mais ils ne peuvent pas interdire ou empêcher le passage pour
ces cas, même si pour cela il faut casser une barrière, casser un mur/une
porte, une fenêtre, abattre des arbres ou piétiner une plantation... Ce
sont des compensations civiles, mais l'interdiction de passage d'un tiers
sur un terrain privé en cas de danger aurait une conséquence pénale pour le
propriétaire pour mise en danger de la vie d'autrui, ou non-assistance à
personnes en danger, ou refus de se soumettre à l'autorité de la sécurité
publique).

C'est pour ça que nombre d'installations privées ont déjà prévu des
passages faciles pour les cas d'urgence sans que cela leur cause des
dommages importants ni des difficultés pour ceux qui doivent les utiliser:
"access=emergency" (généralement sur des voies qui autrement sont privées,
ou fermées par des barrières maneuvrables facilement ou simplement
désignées comme fermées par un panneau ou une marque au sol.


Le 29 juillet 2018 à 19:20, David Crochet  a écrit :

> Bonjour
>
>
> Le 28/07/2018 à 18:54, Philippe Verdy a écrit :
>
>> "private" ici (qui est faux dans ce cas, s'il s'agit en fait de navettes
>> **publiques**)
>>
>
> « Private » ne veut pas dire « privée » mais  « Access is only with
> permission on an individual basis. » ce qui revient à dire «a qui on a
> donné la permission d'utiliser »
>
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Signalisation routiere

[David Crochet]

Bonjour


Le 29/07/2018 à 20:53, Philippe Verdy a écrit :
et que l'autorisation est à obtenir de l'occupant local mais ne peut 
être donnée à distance à d'autres,


Et quand t'invite des amis à venir chez toi, ce n'est pas une 
autorisation à distance ?


Et si l'indication à distance n'est pas possible, l'ami en question doit 
venir se présenter à la limite du "privé" et doit donc héler ?


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] traduction et glossaire

[JB]

Le 29/07/2018 à 15:52, marc marc a écrit :

to tag : renseigner, cartographier
Euh, on se pose deux minutes et on se dit que cartographier, c'est « to 
map ». Que tagguer, c'est une autre histoire. Où la géométrie 
n'intervient pas vraiment, par exemple.


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

Re: [OSM-talk-fr] Panneau de prescription - validité de la prescription après un carrefour

[Philippe Verdy]

Ce n'est jamais bien clair: il y a nombre de carrefour où il manque même un
panneau de "rappel" de la limitation après le franchissement du carrefour:
C'est le cas notamment si le panneau de fin de limitation est à visible
depuis le carrefour (et à moins de 50 mètres). On ne peut pas poser un
panneau s'il n'y a pas de distance suffisante.
En pratique de plus en plus souvent on trouve des ralentisseurs (cousins,
gendarmes couchés, passages piétons surélevés...) avant et après le
carrefour, la présence du ralentisseur constituerait déjà lui même un
rappel, à observer pendant encore au moins 50 mètres après... sauf sur les
traversées de villages ou bordures de zones résidentielles peu denses dans
les sections limités à 70 (il y a cependant des carrefours qui ne sont pas
toujours avec des cédez-le-passage ou stops pour les voies publiques non
prioritaires)

Je ne sais pas ce qu'il en est des passages piétons "protégés" sur ces
voies, mais ils imposent une limitation de vitesse s'il n'y a pas de feux
et même les 70 deviennent 50 ou 30 pour les franchir... Le code de la route
n'est pas bien clair sur les passages protégés sans feux et les
ralentisseurs (y compris les giratoires qu'on ne devrait jamais franchir à
plus de 50 même s'il n'y a pas de panneaux de limitations, les flèches
bleues du giratoire devant suffire)... En revanche le code de la route
impose la prudence du conducteur à tout moment : une priorité de passage
n'est pas un droit de conserver sa vitesse, on doit toujours s'adapter à la
présence d'autres usagers.

Mais comme nombre de conducteurs méconnaissent les règles de prudence, et
qu'il y a manque de formation et d'information du public, les collectivités
ont usé et abusé de panneaux et signaux de plus en plus nombreux, souvent
plus gênants qu'utiles. Si les règles étaient mieux maîtrisées et les
conducteurs mieux formés et informés, on n'aurait pas besoin des limites de
vitesse, et après le franchissement du carrefour précédemment limité, on
devrait aussi maintenir cette limite après le franchissement pendant une
distance comparable (et au moins 50 mètres ou la distance nécessaire du
panneau de débit de limitation dans l'autre sens, qui généralement fait
vis-à-vis d'un panneau de fin d'interdiction dans l'autre sens (ou sinon il
y a un panneau de rappel).

Le 29 juillet 2018 à 20:50, David Crochet  a écrit :

> Bonjour
>
> On parle actuellement des limitations de vitesse différente et remontée à
> 90 km/h dans la cas de 2 voies contiguës affectées à un même sens de
> circulation et sur ces seules voies.
>
> Pour les prescriptions limitant les vitesses, il existent aussi une règle
> qui dit que la prescription disparaît naturellement lors d'un
> franchissement d'un carrefour (ce qui exclu les chemins privée non ouvertes
> à la circulation publique et les chemin de terre ) [ alinéa «e» de
> l'article 63 de l'instruction interministérielle sur la signalisation
> routière].
>
> Devons-nous appliquer cette règle qui indique que l'abaissement au
> préalable du carrefour devient caduque après la franchissement de celui-ci
> ? La règle d'usage prévaudrait que oui.
>
> Or, il est souvent à constater qu'après ces carrefours, il y a
> quasi-généralement l'implantation d'un panneau de fin de prescription,
> comme si l'usage voudrait que la prescription ait encore cours sur ces
> lieux.
>
> Qu'en est-il de l’application de cette règle de limitation de vitesse
> prescrite de facto et sans nouvelle prescription dans OSM ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Signalisation routiere

[Philippe Verdy]

Je veux dire "d'autres **inconnus**" (qui n'ont pas eu de contact avec le
propriétaire ou locataire pour avoir cette autorisation).
Et "à distance" voulait dire une autorisation donnée par un tiers non
clairement déterminé comme l'autorité publique.

Le 29 juillet 2018 à 21:00, David Crochet  a écrit :

> Bonjour
>
>
> Le 29/07/2018 à 20:53, Philippe Verdy a écrit :
>
>> et que l'autorisation est à obtenir de l'occupant local mais ne peut être
>> donnée à distance à d'autres,
>>
>
> Et quand t'invite des amis à venir chez toi, ce n'est pas une autorisation
> à distance ?
>
> Et si l'indication à distance n'est pas possible, l'ami en question doit
> venir se présenter à la limite du "privé" et doit donc héler ?
>
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Correction massive de operator= ERDF en operator=Enedis

[deuzeffe]

Yep. Il en reste  (même des nœuds que tu as modifiés il y a bien 
longtemps ^^)


Je viens de tomber sur ces 3 lignes :
- https://www.openstreetmap.org/way/250874421
- https://www.openstreetmap.org/way/250874422
- https://www.openstreetmap.org/way/250874423

C'est du 90 kV (avant le transfo Enedis, si j'ai bien vu), mais noté 
operator=ERDF. So ?


(j'ai corrigé ma bévue dans le titre...)
--
deuzeffe

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

Re: [OSM-talk-fr] Correction massive de operator= ERDF en operator=Enedis

[François Lacombe]

Bonsoir Deuzeffe,

C'est normal et une situation un peu particulière.
Il faut bien remplacer operator=ERDF par operator=Enedis (comme les
transfos qui se trouvent à l'extrémité des lignes).

Il y a des éléments de compréhension ici :
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Attribution_de_l.27op.C3.A9rateur
Et sur l'image illustrant le paragraphe


François


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 29 juillet 2018 à 22:32, deuzeffe  a écrit :

> Yep. Il en reste  (même des nœuds que tu as modifiés il y a bien longtemps
>> ^^)
>>
>
> Je viens de tomber sur ces 3 lignes :
> - https://www.openstreetmap.org/way/250874421
> - https://www.openstreetmap.org/way/250874422
> - https://www.openstreetmap.org/way/250874423
>
> C'est du 90 kV (avant le transfo Enedis, si j'ai bien vu), mais noté
> operator=ERDF. So ?
>
> (j'ai corrigé ma bévue dans le titre...)
> --
> deuzeffe
>
> ___
> 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] traduction et glossaire

[Vincent Calame]

Le 29/07/2018 à 15:47, Julien Lepiller a écrit :

Pour ma part, je traduis toujours tag par attribut. Les deux autres
mots sont plus difficiles. Je trouve que « attribuer » ne correspond
pas au sens. Pour moi « étiqueter » ou « qualifier » correspondent
plus, mais je ne les ai encore jamais utilisés dans les traductions
parce que j'y trouve déjà des versions dérivées de l'anglais.

Des avis ?


Personnellement, je trouve aussi que « attribut » est la meilleur 
traduction. Cela correspond bien à ce que c'est : des données attachées 
à un objet (comme les attributs des balises HTML). « étiquette » est 
aussi la traduction de « label », il y a des risques de confusion.


Pour to tag, j'aime bien « renseigner » même si l'académie française 
nous dit que « renseigner un formulaire » est incorrect 
(http://www.academie-francaise.fr/renseigner-un-formulaire).


Sinon, il y a « caractériser » et « caractérisation ». Ou tout 
simplement « décrire » et « description  ». De toute façon, c'est 
toujours bien d'avoir à disposition des synonymes, le français n'aime 
pas trop les répétitions.


Il y a aussi « relever », « faire de relevés » quand le contexte est 
celui de récolter des informations sur le terrain.


Vincent

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

Re: [OSM-talk-fr] Panneau de prescription - validité de la prescription après un carrefour

[marc marc]

Le 29. 07. 18 à 20:50, David Crochet a écrit :
> Devons-nous appliquer cette règle qui indique que l'abaissement au 
> préalable du carrefour devient caduque après la franchissement de 
> celui-ci ? La règle d'usage prévaudrait que oui.

pour ma part je mape la vitesse avant carrefour uniquement sur le way 
d'avant-carrefour. je ne prolonge pas cet effet au delà du carrefour 
puisque la limite ne s'y applique plus

> Or, il est souvent à constater qu'après ces carrefours, il y a 
> quasi-généralement l'implantation d'un panneau de fin de prescription, 
> comme si l'usage voudrait que la prescription ait encore cours sur ces 
> lieux.

j'ai toujours considéré celle comme une sorte de rappel "vous aviez vu 
une limite, elle ne s'applique plus" même si c'est déjà le cas avant
le panneau.
une sorte de "rappel 50km/h" mais version "rappel la limite précédente a 
expirée"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger voie bus/vélo/taxis uniquement?

[Shohreh]

djakk wrote
> je serai partisan de changer la vision des choses, quand c’est la même
> assiette (chaussée + accotement + terre plein + talus + fossés en
> campagne) je mettrai une seule « way » en détaillant dans les tags comment
> les voies sont reparties.

Merci pour les infos.

Malheureusement, BRouter refuse d'envoyer des cyclistes dans une voie de bus
partagée pour cette raison :
===
/It's just the oneway penalty, that adds costfactor 50 for primary roads,
which is only good for very short tracks.

If oneway is not for bikes, brouter knows 4 options to tell him:

- cycleway=opposite|opposite_lane|opposite_track
- oneway:bicycle=no
- oneway:bicycle=no is used there, but only for small sections, not for mos
of the distance.
- cycleway:left=share_busway is not knowm as well, but that does not make
the strong avoidance./
===

Dommage, parce que c'est un bon outil par ailleurs.




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Signalisation routiere

[marc marc]

Le 29. 07. 18 à 21:14, Philippe Verdy a écrit :
> Je veux dire "d'autres **inconnus**" (qui n'ont pas eu de contact avec 
> le propriétaire ou locataire pour avoir cette autorisation).

il n'y a pas + compliqué comme critère à évaluer pour choisir le tag ?

> Le 29 juillet 2018 à 21:00, David Crochet a écrit :
> l'ami en question doit venir se présenter à la limite du "privé" et doit donc 
> héler ?

+1
arrêtons de complexifier et supposer un code de la route fictif !
un panneau rond rouge sur fond blanc =no
cad personne même pas son propriétaire ne peux y passer.

un panneau avec accès privé ou information similaire =private

on ne se préoccupe pas de savoir qui est le propriétaire, quel est on 
intention ou je ne sais quel autre critère, on map la présence du 
panneau et/ou sa conséquence tel que devrait faire n'importe qui (on 
pourrait éventuellement discuter des cas oü il y y une erreur manifeste)
___
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

[Axelos]

Salut les dingos du vélo,

Le 29/07/2018 à 18:11, Charles MILLET a écrit :
>
> 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 ?

Oui cela me convient.

>> 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 bien justement non tu n'as jamais vu de trottoir cyclable sans
séparation car ça n'existe pas ! Tu as certainement vu des trottoirs
avec des beaux desseins et / ou des panneaux fantaisistes qui n'ont pas
de valeur !
Bon pour en revenir sur la question de l'usage de segregated=yes, c'est
je pense une information qui devrait être implicite à l'aménagement car
pas d'alternative, mais l'ajouter ne me pose pas de problème.

>> 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 ?

Je n'ai volontairement pas laissé de commentaire à ce cas de double
bicycle=sidewalk car je ne sais pas trop ...
Ça me semble tout de même plus logique qu'un double *=designated ou
combo foot=designated / bicyle=sidewalk

Sinon moi j'ai une autre proposition :)
Un bon vieux highway=footway + footway=sidewalk + cycleway=track + en
général oneway=yes

En soi, une piste cyclable sur un trottoir !

À plus.

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