date:20100727

Le mardi 27 juillet 2010 10:22:15 sylvain letuffe, vous avez écrit :
 Je trouve que cette liste est donc plutôt un bon moyen de les contacter, et
 j'imagine que le cadastre n'a pas vectorisé qu'une et une seule commune ces
 derniers temps, ce qui veut dire que la demande, bien que semblant ne
 concerner qu'une commune peut tout à fait en concerner plusieurs, faisant
 de la demande une demande intéressante pour d'autres contributeurs

Bonjour,

Question sérieuse :
Comment peut-on connaître les communes vectorisées ?

Humour : Il y a un flux RSS par département ?

Merci

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet sylvain letuffe

Le mardi 27 juillet 2010 10:27:56, Nicolas Dumoulin a écrit :
 Question sérieuse :
 Comment peut-on connaître les communes vectorisées ?
 
 Humour : Il y a un flux RSS par département ?

Presque !

Bon, d'accord, pas tout à fait car ni dans le bon format, ni temps réél, mais 
c'est tout ce que j'ai à proposer :

http://beta.letuffe.org/cron/etat-communes/communes.csv.txt

La section FORMAT VECTEUR AU CADASTRE, indiquent celles qui sont au format 
vecteur et dont les limites ne sont pas encore dans OSM. Donc la liste des 
communes qui apparaissent sont soit :
- frontières encore jamais rentrées dans osm
- toute neuve de vectorisation du cadastre

PS: comme ça change pas tous les jours, j'ai un système de cache pour ne pas 
trop me faire repérer par le cadastre, il me suffit donc de le vider de temps à 
autre pour rafraichir le flux RSS

--
sly


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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Club Informatique Inter Communes / C2IC

Le mardi 27 juillet 2010 10:41:28 sylvain letuffe, vous avez écrit :
 Le mardi 27 juillet 2010 10:27:56, Nicolas Dumoulin a écrit :
  Question sérieuse :
  Comment peut-on connaître les communes vectorisées ?
  
  Humour : Il y a un flux RSS par département ?
 
 Presque !
 
 Bon, d'accord, pas tout à fait car ni dans le bon format, ni temps réél,
 mais c'est tout ce que j'ai à proposer :
 
 http://beta.letuffe.org/cron/etat-communes/communes.csv.txt
 
 La section FORMAT VECTEUR AU CADASTRE, indiquent celles qui sont au
 format vecteur et dont les limites ne sont pas encore dans OSM. Donc la
 liste des communes qui apparaissent sont soit :
 - frontières encore jamais rentrées dans osm
 - toute neuve de vectorisation du cadastre

Ha oui, c'est vrai, tout simplement.
Le top moumoute serait de connaître les communes qui deviennent vectorisées 
mais qui avait déjà des limites admin :-)

Au fait, qu'est-ce qui fait que le cadastre d'une commune devient vectorisé ?
Il y a un schéma directeur, ou c'est en fonction des volontés/sous de chaque 
commune concernée ?

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] video mapping

2010-07-27 Par sujet julien

 Il ne reste plus qu'a  un gentil developpeur de faire un plu gin pour
 synchroniser la video avec la trace GPS sur JOSM (maleureusement je n'ai
 pas les competences requise)

Je n'arrive plus a retrouver le lien, mais kkun l'a fait.
C'était un proto pas fini du tout, mais on voyait la trace GPS avec un
triangle représentant le cône de vision, et dans une fenêtre la vidéo,
image par image.

-- 
JB



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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Philippe Pary

Le mardi 27 juillet 2010 à 10:06 +0200, François Van Der Biest a écrit :
 2010/7/27 Philippe Pary philippe.p...@chtinux.org:
  Le lundi 26 juillet 2010 à 15:01 -0700, Eric V a écrit :
   Avant de quémander, je tiens à vous remercier tous, pour tout ce que vous
  faites pour  les contributeurs modestes comme moi, en mettant gracieusement
  fichiers et abondants conseils en ligne.
 
  Pour en venir au fait, la commune de La Croix sur Gartempe en Haute 
  Vienne
  vient juste d'être numérisée et l'aide d'une bonne âme pour recuperer le
  bati et les cours d'eau serait appréciable et appréciée.
 
  Les demandes sont malvenues sur la liste.
 
 Ha bon ?
 Je ne savais pas que cette nouvelle clause avait été ajoutée ...

Cf mail de Christophe Merlet en pièce jointe, il y a moins de 15 jours.

 
  Je t'invite plutôt à te
  rapprocher en privé des utilisateurs qui ont indiqué avoir  fait de
  grands imports sur le wiki
 
 Effectivement, mais il me semble que le mot malvenu est justement
 malvenu pour accueillir les nouveaux sur cette liste.
 Je pense que nous avons un déficit en terme d'accueil des nouveaux
 contributeurs (cf l'exemple récent aussi avec l'accueil de Lionel
 Rauch). Alors que nous devrions les accueillir à bras ouverts ...

J'ai du mal à saisir cette remarque. Chaque nouvel arrivant se
présentant sur la liste reçoit des réponses à son message. La plupart de
ces réponses sont personnalisées par rapport à ce que dit la personne.
Que devrions-nous faire de plus ?

Philippe
---BeginMessage---
Le mercredi 14 juillet 2010 à 21:58 +0200, Club Informatique Inter
Communes / C2IC a écrit :
 Salut du centre bretagne, 
 
 
 C'est mon premier message sur la liste que je lis avec attention
 depuis maintenant 2 semaines alors excusez moi d'avance !
 
 
 Comme j'ai vu un appel je me permet d'en envoyer un aussi pour
 améliorer le rendu par ici en centre ouest bretagne ! On a peut être
 pas de plages mais il y a de superbes lieux à découvrir et surtout pas
 mal de routes à tagguer !

Je voulais répondre à l'autre message, mais je vais le faire a celui
là...

== DISCLAIMER ==

Âmes sensibles, attention, je vais être encore une fois extrêmement
diplomate :)

Ceci n'est pas une attaque personnelle, mais un message d'ordre général.

== DISCLAIMER ==

La liste n'est pas là pour demander de l'aide pour cartographier sa
-plus belle- région.

Chacun cartographie son coin, il n'y a pas de zone prioritaire.
Avec un peu de bonne volonté, chacun est capable de couvrir sa commune
en 2/3 jours !

La liste est déjà suffisamment dense pour ne pas voir débarquer les
mouches du coche réclamant à tour de rôle aux abonnés de la liste de
travailler sur le plus beau quartier de France.

Il manque des routes PARTOUT en France.
Il manque des POIs PARTOUT en France.

Pa contre, il ne manque pas de nœuds et voies dupliqués à travers la
France grâce aux imports désordonnées d'un certains nombres de
contributeurs.
C'est de pire en pire.
http://matt.dev.openstreetmap.org/dupe_nodes/

Va t'il falloir distribuer des cartons rouges aux mauvais élèves ?


 Je représente ici l'association C2iC
 (http://www.openstreetmap.org/user/C2iC et
 aussi http://wiki.openstreetmap.org/wiki/User:C2iC et
 enfin http://www.c2ic.net/post/Rando-GPS ) au sein de laquelle nous
 sommes 3 ou 4 mappeurs ...
 
 
 Je dois avouer que depuis que nous avons commencé je suis presque
 devenu accro au point de m'acheter un GPS et un pocket PC dernièrement
 pour pouvoir mapper à chaque fois que je me déplace ...
 
 
 Entre le festival des Vieilles Charrues (http://osm.org/go/erJubqNk-)
 et la fête de la crêpe à Gourin (http://osm.org/go/erI9vtZB-) vous
 trouverez bien le temps de passer par ici, non ?
 
 
 J'offre mon champ (http://osm.org/go/erKUjAnaQ--) aux joyeux
 contributeurs et campeurs d'OSM ! 


Le mieux est de mettre ces informations dans le Wiki dans ta page
personnelle et dans la page de ta région.



Librement,


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
---End Message---
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet François Van Der Biest

2010/7/27 Philippe Pary philippe.p...@chtinux.org:
 Le mardi 27 juillet 2010 à 10:06 +0200, François Van Der Biest a écrit :
 2010/7/27 Philippe Pary philippe.p...@chtinux.org:
  Le lundi 26 juillet 2010 à 15:01 -0700, Eric V a écrit :
   Avant de quémander, je tiens à vous remercier tous, pour tout ce que vous
  faites pour  les contributeurs modestes comme moi, en mettant 
  gracieusement
  fichiers et abondants conseils en ligne.
 
  Pour en venir au fait, la commune de La Croix sur Gartempe en Haute 
  Vienne
  vient juste d'être numérisée et l'aide d'une bonne âme pour recuperer le
  bati et les cours d'eau serait appréciable et appréciée.
 
  Les demandes sont malvenues sur la liste.

 Ha bon ?
 Je ne savais pas que cette nouvelle clause avait été ajoutée ...

 Cf mail de Christophe Merlet en pièce jointe, il y a moins de 15 jours.

Tu cites ce message, mais tu oublies les suivants dans le même thread
qui ont fustigé cet accueil peu chaleureux (Vincent de
Chateau-Thierry, Pieren, Vincent Pottier ... ). Il ne fait donc pas
consensus au sein de la communauté et ne peut être érigé comme preuve
d'une nouvelle orienttation de la mailing liste.

  Je t'invite plutôt à te
  rapprocher en privé des utilisateurs qui ont indiqué avoir  fait de
  grands imports sur le wiki

 Effectivement, mais il me semble que le mot malvenu est justement
 malvenu pour accueillir les nouveaux sur cette liste.
 Je pense que nous avons un déficit en terme d'accueil des nouveaux
 contributeurs (cf l'exemple récent aussi avec l'accueil de Lionel
 Rauch). Alors que nous devrions les accueillir à bras ouverts ...

 J'ai du mal à saisir cette remarque. Chaque nouvel arrivant se
 présentant sur la liste reçoit des réponses à son message. La plupart de
 ces réponses sont personnalisées par rapport à ce que dit la personne.
 Que devrions-nous faire de plus ?

Je pousse un peu mais : wikilove [1] ...
Donc à Eric V. : un grand bienvenue dans le projet !

F.

[1] http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:WikiLove

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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Christophe Merlet

Le mardi 27 juillet 2010 à 11:22 +0200, Philippe Pary a écrit :
 Le mardi 27 juillet 2010 à 10:06 +0200, François Van Der Biest a écrit :
  2010/7/27 Philippe Pary philippe.p...@chtinux.org:
   Le lundi 26 juillet 2010 à 15:01 -0700, Eric V a écrit :
Avant de quémander, je tiens à vous remercier tous, pour tout ce que 
   vous
   faites pour  les contributeurs modestes comme moi, en mettant 
   gracieusement
   fichiers et abondants conseils en ligne.
  
   Pour en venir au fait, la commune de La Croix sur Gartempe en Haute 
   Vienne
   vient juste d'être numérisée et l'aide d'une bonne âme pour recuperer le
   bati et les cours d'eau serait appréciable et appréciée.
  
   Les demandes sont malvenues sur la liste.
  
  Ha bon ?
  Je ne savais pas que cette nouvelle clause avait été ajoutée ...
 
 Cf mail de Christophe Merlet en pièce jointe, il y a moins de 15 jours.

Mon coup de gueule n'est pas tombé dans l'oreille d'un sourd ;o)

Cela dit, je visais spécifiquement ceux qui se contente de demander aux
autres de venir cartographier leur bled en dehors du cadre d'une mapping
party conviviale et arrosée.

Ici, il semble s'agir d'une demande d'aide technique pour obtenir le
fichier osm du bâti. Je suis plus tolérant ;o)
Tout le monde n'est, malheureusement, pas sous GNU/Linux avec une
maitrise suffisante du shell et de l'OS pour faire tourner un script
Perl ayant de multiples dépendances au limite de l'ésotérisme.


Librement,
-- 
Christophe Merlet (RedFox)


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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Marc SIBERT

danger troll /

Le 27 juillet 2010 11:22, Philippe Pary philippe.p...@chtinux.org a écrit
:

 Le mardi 27 juillet 2010 à 10:06 +0200, François Van Der Biest a écrit :
  2010/7/27 Philippe Pary philippe.p...@chtinux.org:
   Le lundi 26 juillet 2010 à 15:01 -0700, Eric V a écrit :
Avant de quémander, je tiens à vous remercier tous, pour tout ce que
 vous
   faites pour  les contributeurs modestes comme moi, en mettant
 gracieusement
   fichiers et abondants conseils en ligne.
  
   Pour en venir au fait, la commune de La Croix sur Gartempe en Haute
 Vienne
   vient juste d'être numérisée et l'aide d'une bonne âme pour recuperer
 le
   bati et les cours d'eau serait appréciable et appréciée.
  
   Les demandes sont malvenues sur la liste.
 
  Ha bon ?
  Je ne savais pas que cette nouvelle clause avait été ajoutée ...

 Cf mail de Christophe Merlet en pièce jointe, il y a moins de 15 jours.


Un mail ne vaut pas règlement. Tiens d'ailleurs voici une nouvelle demande
(HS qui plus est) quelqu'un connait-il un moyen de faire une newletter
automatique et mensuelle sur cette liste qui rappellerais justement les bons
usages (ceux qui font consensus) et les bons liens pour ceux qui n'ont pas
encore trouvé le wiki, le forum ou l'IRC ?

Halte là aux intégrismes ! Moi aussi j'ai édité mon premier way et moi aussi
j'ai fait mon lot de doublons et j'ai surement cassé le travail de
certains d'entre-vous (un rond-point pas rond avec Sly) et surement plein
d'autre. Mais on apprend en se trompant et surtout en partageant. Alors
plutôt que d'interdire les usages permettons la communication par tous les
moyens (cette liste en est un).

PS : je tague avec Potlatch et j'aime ça, c'est beaucoup plus facile à
utiliser que d'autres outils...

...
 Chaque nouvel arrivant se
 présentant sur la liste reçoit des réponses à son message. La plupart de
 ces réponses sont personnalisées par rapport à ce que dit la personne.
 Que devrions-nous faire de plus ?

 Philippe

 Être aimable et accueillant, proposer notre aide et nos services pour les
plus compétents ; pas les envoyer vers le Wiki.


 -- Message transféré --
 From: Christophe Merlet red...@redfoxcenter.org
 To: Discussions sur OSM en français talk-fr@openstreetmap.org
 Date: Wed, 14 Jul 2010 22:25:32 +0200
 Subject: Re: [OSM-talk-fr] Et du côté de la Bretagne ?
 Le mercredi 14 juillet 2010 à 21:58 +0200, Club Informatique Inter
 Communes / C2IC a écrit :
  Salut du centre bretagne,
 
 
  C'est mon premier message sur la liste que je lis avec attention
  depuis maintenant 2 semaines alors excusez moi d'avance !
 
 
  Comme j'ai vu un appel je me permet d'en envoyer un aussi pour
  améliorer le rendu par ici en centre ouest bretagne ! On a peut être
  pas de plages mais il y a de superbes lieux à découvrir et surtout pas
  mal de routes à tagguer !

 Je voulais répondre à l'autre message, mais je vais le faire a celui
 là...

 == DISCLAIMER ==

 Âmes sensibles, attention, je vais être encore une fois extrêmement
 diplomate :)

 Ceci n'est pas une attaque personnelle, mais un message d'ordre général.

 == DISCLAIMER ==

 La liste n'est pas là pour demander de l'aide pour cartographier sa
 -plus belle- région.

 Chacun cartographie son coin, il n'y a pas de zone prioritaire.
 Avec un peu de bonne volonté, chacun est capable de couvrir sa commune
 en 2/3 jours !

Chacun cartographie où il a envie et ce qu'il connait ! Règle n°1 se faire
plaisir en contribuant, règle n°2 se référer à la règle n°1
...


 Pa contre, il ne manque pas de nœuds et voies dupliqués à travers la
 France grâce aux imports désordonnées d'un certains nombres de
 contributeurs.
 C'est de pire en pire.
 http://matt.dev.openstreetmap.org/dupe_nodes/

 Va t'il falloir distribuer des cartons rouges aux mauvais élèves ?


Il existe déjà des outils pour voir ses erreurs, sans distribution de PV
(quand *je* produit un top 10 de doublons de bâtiments, c'est parce que je
mets en œuvre l'outil nécessaire pour les supprimer, pas pour demander aux
auteurs de les corriger).

cf osmose, beta.letuffe.org, etc.




Librement,

Oui justement !

A+

-- 
Marc Sibert
m...@sibert.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Philippe Pary

Le mardi 27 juillet 2010 à 11:37 +0200, François Van Der Biest a écrit :
 2010/7/27 Philippe Pary philippe.p...@chtinux.org:
  Le mardi 27 juillet 2010 à 10:06 +0200, François Van Der Biest a écrit :
  2010/7/27 Philippe Pary philippe.p...@chtinux.org:
   Le lundi 26 juillet 2010 à 15:01 -0700, Eric V a écrit :
Avant de quémander, je tiens à vous remercier tous, pour tout ce que 
   vous
   faites pour  les contributeurs modestes comme moi, en mettant 
   gracieusement
   fichiers et abondants conseils en ligne.
  
   Pour en venir au fait, la commune de La Croix sur Gartempe en Haute 
   Vienne
   vient juste d'être numérisée et l'aide d'une bonne âme pour recuperer le
   bati et les cours d'eau serait appréciable et appréciée.
  
   Les demandes sont malvenues sur la liste.
 
  Ha bon ?
  Je ne savais pas que cette nouvelle clause avait été ajoutée ...
 
  Cf mail de Christophe Merlet en pièce jointe, il y a moins de 15 jours.
 
 Tu cites ce message, mais tu oublies les suivants dans le même thread
 qui ont fustigé cet accueil peu chaleureux (Vincent de
 Chateau-Thierry, Pieren, Vincent Pottier ... ). Il ne fait donc pas
 consensus au sein de la communauté et ne peut être érigé comme preuve
 d'une nouvelle orienttation de la mailing liste.

C'est exact. Mea culpa

   Je t'invite plutôt à te
   rapprocher en privé des utilisateurs qui ont indiqué avoir  fait de
   grands imports sur le wiki
 
  Effectivement, mais il me semble que le mot malvenu est justement
  malvenu pour accueillir les nouveaux sur cette liste.
  Je pense que nous avons un déficit en terme d'accueil des nouveaux
  contributeurs (cf l'exemple récent aussi avec l'accueil de Lionel
  Rauch). Alors que nous devrions les accueillir à bras ouverts ...
 
  J'ai du mal à saisir cette remarque. Chaque nouvel arrivant se
  présentant sur la liste reçoit des réponses à son message. La plupart de
  ces réponses sont personnalisées par rapport à ce que dit la personne.
  Que devrions-nous faire de plus ?
 
 Je pousse un peu mais : wikilove [1] ...
 Donc à Eric V. : un grand bienvenue dans le projet !

:-)
Bienvenu sur la ML Eric !

Je m'excuse de t'avoir ainsi rudoyé d'entrée de jeu

Philippe


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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet Eric V


Chers tous

Loin de moi, la volonté de semer la zizanie sur la liste.

 J'ai déjà longuement réfléchi avant de poster ( et il semble pas assez
longtemps!!)

Ce qui fait la force de cette liste, c'est bien sûr son coté vivant, coups
de gueule y compris.

Même si la première réponse m'a parru un tantinet séche, il n'y avait pas
non plus de quoi s'en offusquer. Je fais parti des gens pour qui les règles
de conduite de ces listes sont tout à fait étrangères et je me suis laissé
guider par ma version du bon sens en m'adressant à tous plutôt qu' à un en
particulier que je ne connais pas autrement que par son pseudo. Comment
demander à un en particulier un surplus de travail qui ne l'interresse peut
être pas ou plus?

 L'aide demandée était evidemment technique car le python pour moi reste une
variété de serpent que je crains. :)


Avec autant de plaisir de vous lire, à suivre sur la carte...

Eric


-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Demande-de-Bati-et-de-Riviere-tp5340002p5341778.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet GaelADT


Tout le monde répond b à la question 2

Cependant d'après les explications de Lapinos03 je pense qu'il s'attendait à
ce que vous répondiez la réponse c.

Ainsi je trouve que l'on n'avance pas beaucoup... En fait le seul est unique
problème est celui-ci : lorsque l'on utilise cycleway:left qu'est ce que
cela veut dire ? Si je lui colle la valeur lane/opposite_lane ou
track/opposite_track, qu'est-ce que ça veut dire ? Est-ce que le sens de
création du tronçon influe sur ces valeurs ? Est-ce que le tag oneway influe
sur ces valeurs ? Je me rend compte qu'il y a 2 visions différentes... Je
pense qu'il est temps pour la communauté de décider, de l'écrire noir sur
blanc sur le wiki et de s'y tenir !

Au passage, le cas n'est pas si rare que ça, sur Paris je compte 300
tronçons du route (intersection à intersection) où ce cas se présente.
Aujourd'hui Géovélo envoit les cyclistes au petit bonheur la chance dans le
bon sens ou dans un sens interdit en fonction de la vision du
contributeur. Peut-on se mettre d'accord une bonne fois pour toute :) ?

Gaël.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Suffixes-left-right-piqure-de-rappel-tp5327383p5341824.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

Salut !

+1 pour une liste des outils pertinents pour corriger ses erreurs quand on
débute !

J'ai découvert http://matt.dev.openstreetmap.org/dupe_nodes/ par le biais du
message d'accueil de Christophe et en fait c'est plaisant de trouver des
outils pour se corriger tout seul. J'ai aussi noté Géofabrik pour ce qui
concerne l'ajout de l'hydrographie ainsi qu'Osmose.

Le petit plus serait aussi de pouvoir expliquer comment corriger ces
erreurs visualisés par le biais de ces outils. Là dessus je prépare quelques
petits trucs mais il faudrait l'oeil avisé d'autres contributeurs pour
parfaire ces informations !

Voir http://www.c2ic.net/post/Attention-au-Duplicate-Node-! par exemple ...

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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet sly (sylvain letuffe)

On mardi 27 juillet 2010, Club Informatique Inter Communes / C2IC wrote:
 Salut !
 
 +1 pour une liste des outils pertinents pour corriger ses erreurs quand on
 débute !
 
 J'ai découvert http://matt.dev.openstreetmap.org/dupe_nodes/ par le biais du
 message d'accueil de Christophe et en fait c'est plaisant de trouver des
 outils pour se corriger tout seul. J'ai aussi noté Géofabrik pour ce qui
 concerne l'ajout de l'hydrographie ainsi qu'Osmose.

A noter cette page qui en recense une partie :
http://wiki.openstreetmap.org/wiki/FR:Outils_de_validation

On pourrait imaginer un petit laïus sur quels types de problème sont 
référencés, pourquoi, et comment les traiter.

yaka ;-)


-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Demande de Bati et de Rivière

2010-07-27 Par sujet julien


 A noter cette page qui en recense une partie :
 http://wiki.openstreetmap.org/wiki/FR:Outils_de_validation

 On pourrait imaginer un petit laïus sur quels types de problème sont
 référencés, pourquoi, et comment les traiter.

 yaka ;-)

j'avais commencé ca (et pas fini) pour osmose
http://wiki.openstreetmap.org/wiki/FR:Osmose

-- 
JB


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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet GaelADT


Ok donc ça veut dire que ce qu'à dit Lapinos ici :


Lapinos03 wrote:
 
 Sur le cas B3  de http://wiki.openstreetmap.org/wiki/Bicycle on devrait
 d'après toi avoir cycleway:left = opposite_lane

   
 Oui.
 

et là :


Lapinos03 wrote:
 
 Le seul défaut que je vois dans le cadre de ton schéma de tracé par
 rapport au shéma documenté est que tous les tag sont basé sur le sens de
 circulation de la voie principale
 http://wiki.openstreetmap.org/wiki/Key:cycleway cycleway=opposite_lane
 désigne donc une piste cyclable dans le sens inverse du trafic principal
 et non dans le sens inverse du tracé de la voie.
   
 Pas du tout. Tout se réfère par rapport au sens du tracé, lequel tracé 
 suit souvent le sens unique de circulation, le cas échéant, de façon à 
 pouvoir mettre [oneway]=yes et pas [oneway]=-1. Désolé s'il y a eu 
 malentendu.
 
 Donc, opposite_ signifie : circulation dans le *sens contraire du 
 tracé*.
 

C'est faux ? Qu'il ne faut pas faire comme ça ?

Gaël.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Suffixes-left-right-piqure-de-rappel-tp5327383p5342038.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet openstreetmap

Reste qu'avec une telle densité d'informations et de bâtiments, Potlatch 
devient bien souvent inutilisable... Quand on veut ajouter une Boîte aux 
lettres, on y passe des heures juste pour un point...

Ne serait-il pas intelligent de créer des layers pour le stockage des données 
? 
Par exemple, quand on veut travailler sur les Ways ou les Surfaces, on 
travaille en général uniquement sur les Highways, les Buildings, ou les Landuse.
Et les Nodes associés devraient probablement être qualifiés de Highways only, 
Buildings only, Landuse only, ou multi-usage.

Ainsi, pour ajouter ma boîte aux lettres, je demanderais à Potlatch de charger 
les Highways, et de me donner en image de fond une carte, et j'ajouterais le 
point sans douleur.

En fait, il s'agirait juste de rajouter un champ dans la base décrivant le 
layer.

Est-ce intelligent ?
Si ça l'est, on pourrait soumettre ça au niveau mondial pour voir si c'est 
implémentable...

Charlie Echo




- Mail Original -
De: sly (sylvain letuffe) sylv...@letuffe.org
À: talk-fr@openstreetmap.org
Envoyé: Lundi 26 Juillet 2010 15:00:44 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Yo,

888 Mo, c'est la taille du fichier osm compressé du france.osm.bz2 de cette 
nuit présent chez géofabrik.

Est-ce si extraordinaire ? le chiffre, ça, on s'en fout, par contre c'est la 
première fois que la taille du fichier france dépasse celui de l'allemagne 
(887Mo) , faisant du même coup du fichier france le plus gros fichier 
d'europe.

Hé ben, on a bien fait de rentrer des cathérales aux 1500 points ;-)

Bien sûr personne ne s'étonnera d'apprendre, sans que je le dise, d'où vient 
cette croissance récente du fichier...



-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Le mardi 27 juillet 2010, GaelADT a écrit :
 Ok donc ça veut dire que ce qu'à dit Lapinos ici :
 
 Lapinos03 wrote:
  Sur le cas B3  de http://wiki.openstreetmap.org/wiki/Bicycle on devrait
  d'après toi avoir cycleway:left = opposite_lane

  Oui.

Ça, pour moi, c'est superflu. Pas incorrect, mais superflu.

 Lapinos03 wrote:
  Pas du tout. Tout se réfère par rapport au sens du tracé, lequel tracé 
  suit souvent le sens unique de circulation, le cas échéant, de façon à 
  pouvoir mettre [oneway]=yes et pas [oneway]=-1. Désolé s'il y a eu 
  malentendu.
  
  Donc, opposite_ signifie : circulation dans le *sens contraire du 
  tracé*.

Ça, j'ai bien compris. Mais j'ai aussi compris que, sans le opposite*,
le sens des équipements est interprété comme identique à celui des
automobiles du même côté.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] devient : des layers car il est de plus en plus pénible de travailler sur les donn ées

2010-07-27 Par sujet sly (sylvain letuffe)

On mardi 27 juillet 2010, openstreet...@coutiere.com wrote:
 Reste qu'avec une telle densité d'informations et de bâtiments, Potlatch
 devient bien souvent inutilisable... Quand on veut ajouter une Boîte aux
 lettres, on y passe des heures juste pour un point...  

Je suis bien d'accord avec toi, on avait senti le problème venir avec les 
limites administratives, on avait commencé à bien se rendre compte du 
problème avec l'import de corine, et là, avec le bâti, on est en plein 
dedans :
- ça RAME !!

 Ne serait-il pas intelligent de créer des layers pour le stockage des
 données ?  

Il n'y a pas vraiment de notion de layer dans osm (à part la fourberie pour 
dire ce qui est au dessus et au dessous) par contre c'est bien plus souple 
que d'avoir des layers car chaque objet est identifié par ses tags.

 Est-ce intelligent ?
Le but et la fonctionnalité : oui
La méthode : à mon avis, non

 Si ça l'est, on pourrait soumettre ça au niveau mondial pour voir si c'est
 implémentable... 

J'ai peur que ce ne soit pas pour tout de suite, l'API 0.6 ne permet pas se 
genre de chose, et en changer, c'est un gros morceaux (XAPI en revanche le 
permettrait presque.)

Aujourd'hui, je ne vois que deux solutions :
- télécharger une zone
ou
- ne pas télécharger une zone

Pour en sortir, il faudrait pouvoir demander à l'API ce que l'on veut 
vraiment, et pouvoir ignorer le reste.

Et pour ça, il faudrait que l'API :
1) le permette ;-)
2) s'occupe de calculer les dépendances (un noeud qui appartient à une route 
et à un bâtiment doit être téléchargée même si on a demander : pas les 
bâtiments )
3) les éditeurs le supporter

Mais à mon avis, demander aux contributeurs d'ajouter un tag à la main pour 
faire le distinguons est inutile et utopique

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet GaelADT


Ok... donc tu dis que dans ce cas là que ça soit lane ou opposite_lane ça
doit être interprété de la même façon. Ce n'est pas un peu dangereux ?

Il me semble dangereux de dire :
- sans le opposite le sens est identique au sens de circulation des
voitures du même côté
- avec le opposite le référentiel devient le sens de création du tronçon
donc le sens est opposé à celui-ci.

Pourquoi ne pas avoir le même référentiel avec ou sans opposite ?
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Suffixes-left-right-piqure-de-rappel-tp5327383p5342147.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Le mardi 27 juillet 2010, GaelADT a écrit :
 Il me semble dangereux de dire :
 - sans le opposite le sens est identique au sens de circulation des
 voitures du même côté
 - avec le opposite le référentiel devient le sens de création du tronçon
 donc le sens est opposé à celui-ci.
 
 Pourquoi ne pas avoir le même référentiel avec ou sans opposite ?

C'est ce qui me semblerait le plus logique, avec pour référence le sens
de circulation associé au côté en question. Sauf que ce n'est
visiblement pas ce qui est utilisé.

En revanche, devoir noter systématiquement « opposite » pour les
équipements uniques dans le sens contraire au tracé, c'est pénible.
Quand on met une piste à gauche d'une rue double-sens, le cas normal
c'est qu'elle soit dans le sens contraire au tracé, c'est à dire dans le
même sens que les automobiles.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel



 

Bon, je me décide à entrer dans le débat parce que je suis celui avec qui 
Lapinos avait un différend, lequel différend l'a poussé à intervenir sur la 
mailing-list, afin de faire comme il dit une piqûre de rappel. Sauf que cette 
piqûre  a surtout rappelé que personne ne voit les choses de la même façon... 
(à moins que Lapinos ne nous dise qu'il est d'accord avec les réponses 2.b 
données par tout le monde à son fameux quiz).

 

Il me semble que l'enjeu de toute la discussion, qui est partie de la façon de 
définir les suffixes :right/:left, est de parvenir à bien identifier le sens de 
circulation des vélos (mais aussi, je le rappelle, des bus) à partir des tags 
conventionnés. 

Se mettre d'accord sur la signification des tags et leur usage permettra de 
savoir clairement comment se 'déduit' le sens de circulation vélo (et bus), 
dans tous les cas.

 

Or, dans la discussion qui a eut lieu jusqu'à présent, il y a trois normes 
différentes possibles, trois interprétations possibles des mêmes tags qui sont 
apparues. Interprétations entre lesquelles il va falloir trancher pour que tout 
le monde ait la même compréhension des conventions, et le même usage des tags :

 

 

   A. Soit les suffixes :right/:left indiquent uniquement un côté de la voie en 
fonction du tracé du way, et en aucun cas un sens de circulation implicite. Le 
sens de circulation vélo étant donné par les valeurs lane/opposite_lane (ça 
marche aussi avec track bien sûr), lesquelles se comprennent en fonction du 
sens du tracé : lane dans le sens du tracé, opposite_lane dans le sens 
contraire.

C'est, si je comprends bien, l'option de Lapinos03.

Du coup, trois cas typiques :

 

  1. Dans une rue à sens unique, la bande est placée sur le côté gauche. Si 
elle suit le sens du way (et donc de la circulation voiture), on écrit 
cycleway:left=lane. Si les vélos roulent dans le sens contraire, on met 
cycleway:left=opposite_lane (ou plus simplement cycleway=opposite_lane).

  2. Dans une rue à double sens, les vélos ne disposent d'une bande que 
d'un seul côté. Si elle est du côté droit, alors on met cycleway:right=lane, 
ou, plus simplement, cycleway=lane (puisque c'est seulement lane/opposite_lane 
qui donne le sens de circulation -- et que, a priori, comme on roule à droite 
en France, la bande qui va dans le sens du way est, elle aussi, à droite).

Si la bande est du côté gauche, alors on met cycleway:left=opposite_lane, ou, 
plus simplement, cycleway=opposite_lane (pour la même raison).

  3. Ce qui signifie que quand on a une bande des deux côtés (dans une voie 
à double sens toujours), on ne peut pas mettre cycleway=lane. On est obligé de 
mettre cycleway:right=lane et cycleway:left=opposite_lane.

 

Cette interprétation est cohérente, mais on peut lui faire plusieurs objections.

 D'une part elle est contradictoire avec ce qui est recommandé sur la page wiki 
(http://wiki.openstreetmap.org/wiki/Bicycle) en L1, et avec B3 pour 
cycleway:left. D'autre part, elle préconise un usage assez paradoxal ou nouveau 
de opposite-lane qui, du coup, ne signifie plus nécessairement dans le sens 
contraire au flux de voiture, mais seulement dans le sens contraire au tracé 
du way. Et enfin, elle oblige à créer un nouveau tag pour le cas où, dans une 
rue à double sens de circulation, il y a un couloir de bus à sens unique au 
milieu de la chaussée. Je n'ai pas d'exemple, mais si ce cas se présente, que 
fait-on : on met busway:middle=*, busway:centre=* ?

 

 

   B. Soit on maintient le schéma précédent, la définition restrictive des 
suffixes :right/:left comme désignant uniquement un côté (un side), mais on 
veut simplifier et rendre plus pratique, et on dit que le sens de circulation 
des vélos est toujours donné par lane/opposite_lane, mais que ces valeurs ne se 
définissent plus en fonction du tracé du way, mais seulement en fonction du 
sens de circulation des voitures, càd selon qu'on est en oneway=yes, ou pas.

C'est, si je comprends bien, la voie médiane à laquelle Gaël tend.

Du coup :

 

  1. Dans une rue à sens unique, la bande est placée côté gauche. On écrira 
la même chose que dans l'interprétation A.

  2. En revanche, double sens de circulation voiture, la bande n'est que 
d'un côté. Si elle est à droite, on pourra uniquement écrire 
cycleway:right=lane (et non plus cycleway=lane). Si elle est à gauche, on 
pourra uniquement écrire cycleway:left=lane (et non plus 
cycleway:left=opposite_lane, ni cycleway=opposite_lane).

  3. Du coup, double sens de circulation, si les bandes sont des deux 
côtés, on peut se permettre d'écrire simplement cycleway=lane.

 

Cette méthode est assez complexe, même si elle peut se défendre (elle est en 
accord relatif avec la page wiki, et elle redonne sa signification originelle à 
opposite_lane), mais elle comporte quand même une grosse faille.

Si on reprend le cas d'une voie à double sens de circulation voiture qui aurait 
un couloir de bus à sens unique au

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Le mardi 27 juillet 2010 15:19:47 openstreet...@coutiere.com, vous avez écrit 
:
 Reste qu'avec une telle densité d'informations et de bâtiments, Potlatch
 devient bien souvent inutilisable... Quand on veut ajouter une Boîte aux
 lettres, on y passe des heures juste pour un point...
 
 Ne serait-il pas intelligent de créer des layers pour le stockage des
 données ? Par exemple, quand on veut travailler sur les Ways ou les
 Surfaces, on travaille en général uniquement sur les Highways, les
 Buildings, ou les Landuse. Et les Nodes associés devraient probablement
 être qualifiés de Highways only, Buildings only, Landuse only, ou
 multi-usage.
 
 Ainsi, pour ajouter ma boîte aux lettres, je demanderais à Potlatch de
 charger les Highways, et de me donner en image de fond une carte, et
 j'ajouterais le point sans douleur.

Avec JOSM, on peut masquer des éléments. D'un point de vue purement affichage, 
c'est terriblement efficace ! J'utilise régulièrement un filtre pour masquer 
les bâtiments ou bien n'afficher que les bâtiments, masquer les CLC, …

Après, l'autre problème est la quantité de données à faire tenir en RAM (et le 
temps de traitement de certaines opérations) quand on édite de grandes zones 
comme pour les CLC. Pour les limites admin, en général, j'arrive dans des 
zones vierges :-)

En conclusion, de ce que j'ai compris, vous ne parlez pas de la même chose :
 - pour ajouter une boîte aux lettres, c'est au logiciel de masquer des 
éléments et restreindre peut-être la zone d'édition pour ne pas être dérangé
 - pour les grandes zones, il faudrait effectivement facilement télécharger 
uniquement des objets d'un type.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet openstreetmap

Si si, on parle de la même chose : le téléchargement gigantesque qu'il faut 
pour ajouter le moindre objet. Et je me concentrais sur Potlatch, mais c'est 
pareil pour JOSM, en fait. Le problème n'est pas un problème d'affichage, mais 
un problème de chargement (avec les lenteurs que ça implique).

De toutes façons, le problème va apparaître au grand jour dans 1 an : les 
données seront tellement lourdes, et ça coûtera tellement cher en bande 
passante et surtout en contraintes sur la Base, qu'il FAUDRA trouver une 
solution. C'est ridicule de charger 50 Mo de données pour le moindre ajout dans 
Paris, et ça va démotiver les débutants (même moi, qui ai débuté il y a 
longtemps déjà, je suis démotivé par cette lourdeur...)

Charlie Echo


- Mail Original -
De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net
En conclusion, de ce que j'ai compris, vous ne parlez pas de la même chose :
 - pour ajouter une boîte aux lettres, c'est au logiciel de masquer des 
éléments et restreindre peut-être la zone d'édition pour ne pas être dérangé
 - pour les grandes zones, il faudrait effectivement facilement télécharger 
uniquement des objets d'un type.


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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet sly (sylvain letuffe)

On mardi 27 juillet 2010, Nicolas Dumoulin wrote:
 Avec JOSM, on peut masquer des éléments. D'un point de vue purement
 affichage,  

Il est clair que JOSM s'en sort bien mieux, et même en téléchargeant et 
affichant tout, ça reste utilisable la plupart du temps (à condition d'être 
pas trop gourmand)

Avec un plugin de masquage, ça devrait aller encore mieux (je viens de tester 
ghost, c'est celui que tu utilises ? )

Le problème vient surtout de celui dont il faut taire le nom (et dont on 
parlait), je viens d'éssayer, et si tu cliques sur modifier en étant 
pourtant en zoom 18 au dessus de grenoble, c'est du domaine du pas 
utilisable.

Alors certes, il faudrait recommander d'utiliser JOSM plutôt que Ppp 
mais il reste l'editeur simple d'accès que les imports massifs de building 
rendent de moins en moins utilisable.

 Après, l'autre problème est la quantité de données à faire tenir en RAM (et
 le  

Pour JOSM, je pense qu'on a encore un peu de marge, bien que dans certaines 
zones, ça devient pénible et il faut de plus en plus réduire la fenêtre de 
téléchargement sous peine de faire péter soit le serveur OSM (erreur 500), 
soit JOSM (out of memory), mais disons que c'est gérable et comme on est 
encore loin de tagguer individuellement les pavés des rues, ça devrait nous 
laisser largement du temps.

Non, le problème, c'est le contributeur de passage, il connaît le coin, il 
veut juste indiquer une boite au lettre/resto/hotel/fontaine et n'a pas envie 
de se plonger loin dans le JOSM, ben il n'a que le modifier pour cliquer, et 
les yeux pour pleurer.

La solution n'est peut-être pas le découpage en layer, peut-être 
viendra-t-elle d'éditeurs simples, comme 
http://wiki.openstreetmap.org/wiki/Amenity_Editor que je viens juste de 
découvrir et qui est bien caché au fond du wiki

 En conclusion, de ce que j'ai compris, vous ne parlez pas de la même chose :
Si, il me semble qu'on s'est compris

  - pour ajouter une boîte aux lettres, c'est au logiciel de masquer des 
 éléments et restreindre peut-être la zone d'édition pour ne pas être dérangé

A condition qu'il sache faire !

  - pour les grandes zones, il faudrait effectivement facilement télécharger 
 uniquement des objets d'un type.

Voilà l'autre cas auquel je n'avais pas pensé, mais bon, on arrive à s'en 
sortir dès qu'il s'agit d'une relation en faisant : télécharger les membres 
+ zoom assez fort pour ne pas être perturber par tout le reste, mais c'est 
pas non plus l'extase car ajouter par exemple les inner d'une immense forêt, 
ben c'est dur si on n'a pas téléchargé les polygones à l'intérieure de cette 
forêt.


-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Le mardi 27 juillet 2010 16:13:58 openstreet...@coutiere.com, vous avez écrit 
:
 Si si, on parle de la même chose : le téléchargement gigantesque qu'il faut
 pour ajouter le moindre objet. Et je me concentrais sur Potlatch, mais
 c'est pareil pour JOSM, en fait. Le problème n'est pas un problème
 d'affichage, mais un problème de chargement (avec les lenteurs que ça
 implique).

 […]  C'est ridicule de charger 50 Mo de données pour le moindre ajout dans
 Paris,

Je viens de faire le test dans Paris en chargeant une zone de 100mx100m, ça me 
donne 111ko, et pour 500mx500m ça me fait à peine 2Mo. Donc, selon moi, ça 
reste raisonnable pour ajouter un POI.

Le problème reste entier pour travailler avec de très grandes zones.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Merci pour cette clarification.

Le mardi 27 juillet 2010, jos sinet a écrit :
A. Soit les suffixes :right/:left indiquent uniquement un côté de la voie 
 en fonction du tracé du way, et en aucun cas un sens de circulation 
 implicite. Le sens de circulation vélo étant donné par les valeurs 
 lane/opposite_lane (ça marche aussi avec track bien sûr), lesquelles se 
 comprennent en fonction du sens du tracé : lane dans le sens du tracé, 
 opposite_lane dans le sens contraire.

Pour moi, c'est trop compliqué. Devoir marquer systématiquement de la
façon la plus complexe possible (un tag pour chaque côté plus une
précision de sens) le cas le plus simple qui existe (route double sens
avec piste cyclable de chaque côté), ce n'est pas normal.

B. Soit on maintient le schéma précédent, la définition restrictive des 
 suffixes :right/:left comme désignant uniquement un côté (un side), mais on 
 veut simplifier et rendre plus pratique, et on dit que le sens de circulation 
 des vélos est toujours donné par lane/opposite_lane, mais que ces valeurs ne 
 se définissent plus en fonction du tracé du way, mais seulement en fonction 
 du sens de circulation des voitures, càd selon qu'on est en oneway=yes, ou 
 pas.

Ce n'est pas clair. Vu tes examples, je comprends qu'une lane irait dans
le sens unique pour les oneway=yes/-1 et dans le sens des voitures du
même côté pour les double-sens.

Ça me semble le plus intuitif. Dans une rue à sens unique, une bande, à
gauche ou à droite, est habituellement comprise comme allant dans le
sens de la rue, sinon on parle de bande à contresens.

C. Soit, c'est mon option, les suffixes :right/:left désignent aussi, et 
 même avant tout, un sens de circulation implicite : right pour le sens du 
 tracé du way, et :left pour le sens de circulation contraire. Ils désignent 
 un côté/direction (side/direction), comme il est sous-entendu sur la page de 
 discussion des suffixes 
 (http://wiki.openstreetmap.org/wiki/Proposed_features/right_left).

La seule différence avec l'option B, c'est la lane à gauche d'une voie à
sens unique. Il me semble contre-intuitif de la qualifier simplement de
lane si elle va à contresens de la rue.



Pour le cas des voies de bus au milieu, il me semble utopique de vouloir
représenter ça de façon pratique avec seulement des tags. Lorsque la
configuration est suffisamment particulière pour qu'ils soit nécessaire
de préciser que la voie de bus est au milieu, il me semble qu'il vaut
mieux faire des tracés dédiés.

Autrement dit, des bandes cyclables à droite, ou à contresens à gauche
ou à droite d'une rue à sens unique, c'est un aménagement standard. En
revanche, des voies de bus au milieu, ou des pistes cyclables au centre
d'un pont sous un viaduc ferroviaire — ce cas est fréquent à Paris —,
voire même partageant un bout d'un terre-plein de tramway, c'est une
configuration particulière, pas un aménagement classique. Dans ce cas,
il me semble raisonnable de laisser deux possibilités :
— soit ça s'intègre tellement bien dans l'aménagement que cette
  particularité ne mérite pas d'être mentionnée : on peut alors taguer
  comme un cas standard ;
— soit ça mérite d'être signalé : il vaut alors mieux faire un tracé
  dédié.
À moins de proposer un modèle des routes avec des sous-éléments (au sens
XML) pour chaque voie et piste, on ne peut pas tout représenter avec de
simples tags (au sens OSM) ou attributs (au sens XML).

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet openstreetmap

Je n'ai pas de quoi mesurer les données chargées sous la main. Il est vrai que 
50 Mo est un peu exagéré si on est en zoom maximal. Mais quand je cherche à 
modifier, avec Potlatch, la zone 
http://www.openstreetmap.org/?lat=48.852885lon=2.332884zoom=18layers=M
(zoom 18, maximum par l'interface)
Potlatch me dit lui-même la zone est très détaillée, le chargement sera long. 
Voulez-vous zoomer ? et il zoome à 20.
Comme quoi le problème a été identifié...

La zone en zoom 18 contient 1400 éléments... La requête sur la base doit être 
monstrueuse pour juste un point à ajouter... Plus que le volume, je présume que 
c'est la charge de la Base qui va poser problème...

Charlie Echo


- Mail Original -
De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Mardi 27 Juillet 2010 16:36:37 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Le mardi 27 juillet 2010 16:13:58 openstreet...@coutiere.com, vous avez écrit 
:
 Si si, on parle de la même chose : le téléchargement gigantesque qu'il faut
 pour ajouter le moindre objet. Et je me concentrais sur Potlatch, mais
 c'est pareil pour JOSM, en fait. Le problème n'est pas un problème
 d'affichage, mais un problème de chargement (avec les lenteurs que ça
 implique).

 […]  C'est ridicule de charger 50 Mo de données pour le moindre ajout dans
 Paris,

Je viens de faire le test dans Paris en chargeant une zone de 100mx100m, ça me 
donne 111ko, et pour 500mx500m ça me fait à peine 2Mo. Donc, selon moi, ça 
reste raisonnable pour ajouter un POI.

Le problème reste entier pour travailler avec de très grandes zones.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

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

Re: [OSM-talk-fr] devient : des layers car il est de plus en plus pénible de travailler sur les donn ées

2010-07-27 Par sujet Christian Quest

OSM s'alourdit s'est sûr et c'est quand même souhaitable !

Les bâtiments rendent effectivement de travail sur des zones importantes de
plus en plus délicat, mais le rendu pourrait aussi descendre un niveau de
zoom plus bas. J'ai testé mapnik avec un zoom 19 et 20 pour voir, car sur ma
ville, certains POI proches ne sont pas rendus.

Est-il envisageable qu'avec la future refonte de portail OSM France, on
puisse offrir un niveau de zoom de plus et que P(iiip) puisse démarrer ses
modifs un cran plus bas (voire 2, histoire d'anticiper).
Est-il envisageable d'avoir un P(iiip) légèrement modifié sur le site OSM
France ?

P(iiip) est un outil formidable pour les nouveaux contributeurs. Sa
simplicité d'accès permet de démarrer facilement, ça serait vraiment dommage
qu'il devienne inutilisable au fur et à mesure qu'OSM s'enrichit de données.
L'import massif des bâtiments peut inciter et faciliter l'ajout de POI et
autres données par de nouveaux contributeurs.


Autre réflexion sur le masquage/filtrage: je pense que cela peut aussi poser
pas mal de problème car si l'on masque des éléments comment être sûr que les
ajouts qui devraient leur être lié sont bien faits ?
Exemple: on masque les bâtiments génériques (ceux qui n'ont que le
building=yes) mais si on ajoute un POI du genre là il y a un garage et que
le garage c'est le bâtiment qui a été masqué... vous voyez où je veux en
venir ? Au final on peut même se retrouver à rajouter des infos déjà
présentes mais masquées par ailleurs (erreur que j'ai déjà commise avec JOSM
et un filtre activé).

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

Re: [OSM-talk-fr] devient : des layers car il est de plus en plus pénible de travailler sur les donn ées

2010-07-27 Par sujet Emilie Laffray

2010/7/27 Christian Quest christian.qu...@gmail.com

 OSM s'alourdit s'est sûr et c'est quand même souhaitable !

 Les bâtiments rendent effectivement de travail sur des zones importantes de
 plus en plus délicat, mais le rendu pourrait aussi descendre un niveau de
 zoom plus bas. J'ai testé mapnik avec un zoom 19 et 20 pour voir, car sur ma
 ville, certains POI proches ne sont pas rendus.

 Est-il envisageable qu'avec la future refonte de portail OSM France, on
 puisse offrir un niveau de zoom de plus et que P(iiip) puisse démarrer ses
 modifs un cran plus bas (voire 2, histoire d'anticiper).
 Est-il envisageable d'avoir un P(iiip) légèrement modifié sur le site OSM
 France ?

 P(iiip) est un outil formidable pour les nouveaux contributeurs. Sa
 simplicité d'accès permet de démarrer facilement, ça serait vraiment dommage
 qu'il devienne inutilisable au fur et à mesure qu'OSM s'enrichit de données.
 L'import massif des bâtiments peut inciter et faciliter l'ajout de POI et
 autres données par de nouveaux contributeurs.


P(iiip) 2 est en cours de développement actif.
http://random.dev.openstreetmap.org/potlatch2/potlatch2.html Je pense qu'il
serait intéressant a terme de voir si celui ci gère mieux la quantité de
donnée. Le lien donne n'est pour le moment pas connecte a la base de donnée
principale mais il serait trivial de pointer vers la base de donnée
principale. P(iiip)2 est plus rapide sur pas mal de point grâce au passage a
Action Script 3 avec l'effet secondaire (qui déplaît aux libristes) de ne
pas tourner sous Flash en open source (Gnash par exemple).
De plus, il y pas mal de boulot pour ajouter de nouvelles icônes et de
nouveaux presets (tout est configurable). Il serait donc tout a fait
possible de permettre un niveau de zoom supplémentaire avec une version
modifiée de P(iiip)2.
Traduire cela en Francais ou integrer le plugin Cadastre serait un bon
projet pour une hack week.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet hamster

openstreet...@coutiere.com a écrit :

Reste qu'avec une telle densité d'informations et de bâtiments, Potlatch
devient bien souvent inutilisable... Quand on veut ajouter une Boîte aux
lettres, on y passe des heures juste pour un point...

Ne serait-il pas intelligent de créer des layers pour le stockage des données ?
Par exemple, quand on veut travailler sur les Ways ou les Surfaces, on travaille en général uniquement sur les Highways, les Buildings, ou les Landuse.

Et les Nodes associés devraient probablement être qualifiés de Highways only, Buildings only,
Landuse only, ou multi-usage.

Ainsi, pour ajouter ma boîte aux lettres, je demanderais à Potlatch de charger
les Highways, et de me donner en image de fond une carte, et j'ajouterais le
point sans douleur.

En fait, il s'agirait juste de rajouter un champ dans la base décrivant le
layer.

si potlach ne sait pas gerer la grande densite de donnees c'est potlach
qu'il faut ameliorer, il n'est pas une bonne idee de vouloir adapter la
base aux defauts et limitations de potlach

Si si, on parle de la même chose : le téléchargement gigantesque qu'il faut
pour ajouter le moindre objet. Et je me concentrais sur Potlatch, mais c'est
pareil pour JOSM, en fait. Le problème n'est pas un problème d'affichage, mais
un problème de chargement (avec les lenteurs que ça implique).

pour ajouter une boite aux lettres avec JOSM, je choisis la zone avant
de la charger et je la choisis a peu pres grosse comme une maison, ca se
passe tres bien et tres vite
je comprend pas comment tu te debrouille pour faire des telechargements
gigantesques

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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Le mardi 27 juillet 2010 16:54:43 openstreet...@coutiere.com, vous avez écrit 
:
 Je n'ai pas de quoi mesurer les données chargées sous la main. Il est vrai
 que 50 Mo est un peu exagéré si on est en zoom maximal. Mais quand je
 cherche à modifier, avec Potlatch, la zone
 http://www.openstreetmap.org/?lat=48.852885lon=2.332884zoom=18layers=M
 (zoom 18, maximum par l'interface)
 Potlatch me dit lui-même la zone est très détaillée, le chargement sera
 long. Voulez-vous zoomer ? et il zoome à 20. Comme quoi le problème a été
 identifié...
 
 La zone en zoom 18 contient 1400 éléments... La requête sur la base doit
 être monstrueuse pour juste un point à ajouter... Plus que le volume, je
 présume que c'est la charge de la Base qui va poser problème...

Bon, en tout cas, ça montre peut-être une des limites de Potlach. Avec Josm, 
sur la même zone, on a les données en 15 secondes. Avec josm, tu peux affiner 
la zone de travail plus précisément. Si trop de gens trouve Josm compliqué, il 
faut qu'on améliore la doc, ou faire un mode light, mais ça me paraît vraiment 
une approche plus raisonnable. Mais bon, je voudrai pas lancer de troll :-)

Concernant la surcharge de la base, je ne suis pas sûr que ce soit si 
terrible, mais je ne suis pas assez au jus pour juger …


-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet Charlie Echo

De: hamster hams...@suna.fdn.fr
pour ajouter une boite aux lettres avec JOSM, je choisis la zone avant 
de la charger et je la choisis a peu pres grosse comme une maison, 

Certes, avec JOSM, c'est facile.
Mais je parlais ici de Potlatch : avec Potlatch, on doit charger un écran 
entier, avec un zoom finalement faible.
Et je ne parle pas vraiemnt de moi, mais plutôt des débutants rebutés par ces 
chargements longs.


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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet hamster


Charlie Echo a écrit :

avec Potlatch, on doit charger un écran entier


on est d'accord : le probleme est dans potlach, la solution doit donc 
etre dans potlach et non pas dans la base


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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

Le mardi 27 juillet 2010 16:31:10 sly (sylvain letuffe), vous avez écrit :
 Avec un plugin de masquage, ça devrait aller encore mieux (je viens de
 tester ghost, c'est celui que tu utilises ? )

Hmm, je ne vois pas de plugin spécifiquement installé. Ça m'a l'air d'être un 
outil intégré. C'est l'entonoir sur la barre d'outil. Perso, ça devient 
indispensable pour les zones avec bâti !


Le mardi 27 juillet 2010 16:31:10 sly (sylvain letuffe), vous avez écrit :
 On mardi 27 juillet 2010, Nicolas Dumoulin wrote:
  Après, l'autre problème est la quantité de données à faire tenir en RAM
  (et le
 
 Pour JOSM, je pense qu'on a encore un peu de marge

Sauf quand tu travailles sur le cadastre de plusieurs communes ;-)
Je pète vite des records moi.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] devient : des layers car il est d e plus en plus pénible de travailler sur les données

Le mardi 27 juillet 2010 17:07:27 Christian Quest, vous avez écrit :
 Autre réflexion sur le masquage/filtrage: je pense que cela peut aussi
 poser pas mal de problème car si l'on masque des éléments comment être sûr
 que les ajouts qui devraient leur être lié sont bien faits ?
 Exemple: on masque les bâtiments génériques (ceux qui n'ont que le
 building=yes) mais si on ajoute un POI du genre là il y a un garage et
 que le garage c'est le bâtiment qui a été masqué... vous voyez où je veux
 en venir ? Au final on peut même se retrouver à rajouter des infos déjà
 présentes mais masquées par ailleurs (erreur que j'ai déjà commise avec
 JOSM et un filtre activé).

Oui, effectivement il faut faire gaffe. Mon utilisation typique est de masquer 
les building quand je travail sur le filaire. Les CLC sont quasiment toujours 
masqués.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


Donc, si je comprends bien tu choisirais plutôt la méthode B. : on identifie le 
sens de circulation des vélos (de même pour les bus) avec lane/opposite_lane, 
en fonction du sens du flux de voitures adjacent à la bande, et right/left 
désigne uniquement un côté.

 

Et tu fais ce choix parce que tu te dis que pour ce cas hypothétique d'un 
couloir de bus au milieu, au pire, on lui trace un nouveau way (ce qui implique 
de mettre 3 ways au lieu d'un : un pour le bus, et un pour chaque sens de 
circulation voiture).

 

Il faudrait que tout le monde donne sa préférence.   

 

Jocelyn




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

[OSM-talk-fr] Osmose: erreurs par utilisateur qui ne marche plus ?

2010-07-27 Par sujet Christian Quest

J'ai pris l'habitude d'aller vérifier si j'avais fait des erreurs à l'aide
de la recherche par utilisateur d'osmose... mais depuis quelques temps elle
ne fonctionne plus.

Un soucis temporaire ?

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Le mardi 27 juillet 2010, jos sinet a écrit :
 Donc, si je comprends bien tu choisirais plutôt la méthode B. : on identifie 
 le sens de circulation des vélos (de même pour les bus) avec 
 lane/opposite_lane, en fonction du sens du flux de voitures adjacent à la 
 bande, et right/left désigne uniquement un côté.

Voilà. Pour moi, une piste cyclable « en opposition » l'est par rapport
aux voitures qui sont à côté. C'est le terme « opposite » qui me fait
voir ça ainsi.

 Et tu fais ce choix parce que tu te dis que pour ce cas hypothétique d'un 
 couloir de bus au milieu, au pire, on lui trace un nouveau way (ce qui 
 implique de mettre 3 ways au lieu d'un : un pour le bus, et un pour chaque 
 sens de circulation voiture).

Pas forcément, c'est pour les cas les plus compliqués. Par exemple, dans
le cas assez courant à Paris d'un couloir de bus central à double-sens,
je verrais bien un busway:middle=track. Et cycleway=share_busway s'il
est cyclable. En revanche, si ça commence à être du sens unique partiel,
cyclable seulement dans un sens, etc., soit on laisse tomber les
précisions de position, soit on trace à part.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel




 
Le mardi 27 juillet 2010, jos sinet a écrit :
 Donc, si je comprends bien tu choisirais plutôt la méthode B. : on identifie 
 le sens de circulation des vélos (de même pour les bus) avec 
 lane/opposite_lane, en fonction du sens du flux de voitures adjacent à la 
 bande, et right/left désigne uniquement un côté.
 
Voilà. Pour moi, une piste cyclable « en opposition » l'est par rapport
aux voitures qui sont à côté. C'est le terme « opposite » qui me fait
voir ça ainsi.
 
 Et tu fais ce choix parce que tu te dis que pour ce cas hypothétique d'un 
 couloir de bus au milieu, au pire, on lui trace un nouveau way (ce qui 
 implique de mettre 3 ways au lieu d'un : un pour le bus, et un pour chaque 
 sens de circulation voiture).
 
Pas forcément, c'est pour les cas les plus compliqués. Par exemple, dans
le cas assez courant à Paris d'un couloir de bus central à double-sens,
je verrais bien un busway:middle=track. Et cycleway=share_busway s'il
est cyclable. En revanche, si ça commence à être du sens unique partiel,
cyclable seulement dans un sens, etc., soit on laisse tomber les
précisions de position, soit on trace à part.
 
Oui, pourquoi pas, moi je veux bien. 
Mais il faudrait que cette proposition emporte l'adhésion générale, qu'on 
puisse se remettre à taguer...

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

Re: [OSM-talk-fr] 888 Mo (taille de l'extrait france.osm.bz2)

2010-07-27 Par sujet Thomas Clavier

Le 27/07/2010 17:29, hamster a écrit :
 Charlie Echo a écrit :
 avec Potlatch, on doit charger un écran entier

 on est d'accord : le probleme est dans potlach, la solution doit donc
 etre dans potlach et non pas dans la base

on est d'accord : le probleme est dans potlach, la solution doit donc
etre dans potlach et/ou dans l'API :-)

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783




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

[OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)

2010-07-27 Par sujet arno

salut,
comme je l'avais annoncé il y a quelques semaines sur la liste, je suis en 
train de faire un site web de partage d'itinéraires.

Il est loin d'être fini, mais il est suffisamment avancé pour que je vous le 
présente et que vous me disiez ce que vous en pensez. En le présentant dés 
maintenant, si vous avez des idées de choses à améliorer, à changer 
etc, ça sera plus facile pour moi que si j'attends qu'il soit fini !

L'idée du site, c'est qu'on trace un itinéraire sur un fond de carte osm, et 
ensuite, ça permet d'avoir un lien direct vers le tracé. Ça permet par 
exemple de montrer des trajets rando, des trajets vélo malin, ...

Le site est ici:
http://osm-syj.crans.org/

et voici des exemples de tracés qu'on peut obtenir:
http://osm-syj.crans.org/idx/1
http://osm-syj.crans.org/idx/3
http://osm-syj.crans.org/idx/6

Le site est uniquement un site de test et de présentation, il va sûrement
changer beaucoup d'ici la version finale, peut-être que même l'url va changer, 
et de toutes manières, je vais effacer les données d'ici quelques semaines. 
Donc, ne l'utilisez pas pour des données pérennes.

Qu'est-ce que vous en pensez, est-ce qu'il y a des choses à améliorer, des 
bugs ? est-ce que vous pensez que vous allez l'utiliser ? ou pas ? et pourquoi 
?

voila voila

et merci à étienne chové pour l'hébergement.

a+
arno


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Argumentaire pour des données libr es

2010-07-27 Par sujet Christophe Bayle

 From: François Van Der Biestfrancois.vanderbi...@camptocamp.com
 To: Discussions sur OSM en français talk-fr@openstreetmap.org

Bonsoir,

 J'embraye sur la suite dès que j'ai un peu de temps...

Génial, je viens d'ailleurs de me rendre compte que tu étais celui avait
crée le document sur le wiki de OSGeo, merci à toi =)

 Sinon, dans l'idée la preuve par les faits, le document suivant (en
 cours de finalisation avant publication dans le journal de l'EPFL)
 peut aider à convaincre des décideurs, surtout si on leur montre
 comment réutiliser les données OSM (maposmatic, serveur de tuiles, etc
 ...) : http://dl.free.fr/oeHMyR3pg - regarder essentiellement les
 figures 2 et 3 ... le reste est probablement déjà connu de vous tous.

Je m'y plonge dès que possible.

Tanguy n'hésite pas à passer sur le wiki pour faire tes remarques (meme si
je les ai bien notée et qu'au pire je les retranscrirais moi meme ;)

Merci également à Thomas qui à mis en forme le gros paté que j'avais
pondu...

Pour mémoire:
http://wiki.osgeo.org/wiki/Talk:Pourquoi_des_donnees_geographiques_libres_fr

Bien à vous,

-- 

Christophe Bayle
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] video mapping

2010-07-27 Par sujet Ab_fab

Dans le même genre, j'ai vu ceci dans le numéro de juillet de Science et Vie
http://www.gobandit.com/overview.html
http://www.gobandit.com/tecspecs.html

Le 26 juillet 2010 18:11, simon msr...@gmail.com a écrit :

 Bonjour

 Une petite photo de mon vélo pour cartographier et faire des video de
 mon parcours :)

 Il ne reste plus qu'à un gentil développeur de faire un plu gin pour
 synchroniser la vidéo avec la trace GPS sur JOSM (maleureusement je n'ai
 pas les compétences requise)

 Librement

 Simon

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




-- 
--
ab_fab

Il n'y a pas de pas perdus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel

2010-07-27 Par sujet simon

OpenStreetMap est un projet international, si un site allemand ou
anglais veut faire du routage pour vélo sur la france il utilisera les
spécification du wiki pour créer son algorithme. Donc il serait peut
être souhaitable de mapper comme l'indique le wiki ou de faire une
proposition sur la liste Tagging avant de créer une méthode typiquement
française.

Le wiki définie ceci : 

Pour le tag right/left
http://wiki.openstreetmap.org/wiki/Proposed_features/right_left

restreint le tag a un coté ou l'autre de la voie (respecte le sens du
way)


Pour le tag cycleway : 
http://wiki.openstreetmap.org/wiki/Key:cycleway

opposite_lane

The route is a lane, but bicycles may go in the direction opposite of
other traffic. Only applies where oneway=yes.

La route à une piste cyclabe dans la direction opposé aux AUTRES
TRAFIQUES

opposite

The route may be cycled in the direction opposite of other traffic, but
does not have a dedicated lane. Note - such streets are common in
Belgium, the Netherlands and Denmark, for example, but are rare in the
UK (although they do exist): often, instead, actually the street is
two-way as normal for its whole length except for the very short section
past the no-entry sign at the end, where cycles are excepted from the
no-entry by means of a short lane separated by an island. This is called
a cycle plug. In some places this has been represented as very short
oneway Way at the end with an adjacent cycleway, forming a little
triangle with the road they join to.

la route peut être prise a contre sens des AUTRES TRAFIQUES sans avoir
de voie dédié.

Ce qui nous donne comme synthèse la page
http://wiki.openstreetmap.org/wiki/Bicycle avec de jolie exemples.

Ensuite si chacun tag a sa manière sans respecter le consensus ou en
définissant un nouveau schéma pour chaque pays, région, ville ... je ne
vois pas l'intérêt d'avoir un projet mondial et collaboratif.

Ce schéma n'est bien sur pas complet pas complet et il reste quelque
point imprécis. Mais respectons la documentation la ou il y a consensus
et pour le reste faisons des propositions dans la partie proposed
feature et documentons le wiki.

Simon


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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet Stéphane Brunner


Hello,








Le 27. 07. 10 18:05, jos sinet [via GIS] a écrit :
 
 
 
 
 
 
  
 Le mardi 27 juillet 2010, jos sinet a écrit :
 Donc, si je comprends bien tu choisirais plutôt la méthode B. : on identifie 
 le sens de circulation des vélos (de même pour les bus) avec 
 lane/opposite_lane, en fonction du sens du flux de voitures adjacent à la 
 bande, et right/left désigne uniquement un côté.
  
 Voilà. Pour moi, une piste cyclable « en opposition » l'est par rapport
 aux voitures qui sont à côté. C'est le terme « opposite » qui me fait
 voir ça ainsi.
Sauf que cela ne respecte pas ce qui est décris sur la page
http://wiki.openstreetmap.org/wiki/Bicycle cas M3a par exemple !

CU
Sarge.

  
 Et tu fais ce choix parce que tu te dis que pour ce cas hypothétique d'un 
 couloir de bus au milieu, au pire, on lui trace un nouveau way (ce qui 
 implique de mettre 3 ways au lieu d'un : un pour le bus, et un pour chaque 
 sens de circulation voiture).
  
 Pas forcément, c'est pour les cas les plus compliqués. Par exemple, dans
 le cas assez courant à Paris d'un couloir de bus central à double-sens,
 je verrais bien un busway:middle=track. Et cycleway=share_busway s'il
 est cyclable. En revanche, si ça commence à être du sens unique partiel,
 cyclable seulement dans un sens, etc., soit on laisse tomber les
 précisions de position, soit on trace à part.
  
 Oui, pourquoi pas, moi je veux bien. 
 Mais il faudrait que cette proposition emporte l'adhésion générale, qu'on 
 puisse se remettre à taguer...
 
 ___ Talk-fr mailing list 
 Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr 
  
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 __
 View message @ 
 http://gis.638310.n2.nabble.com/Suffixes-left-right-piqure-de-rappel-tp5327383p5342798.html
 To start a new topic under France, email 
 ml-node+3070341-1406367393-41...@n2.nabble.com
 To unsubscribe from France, click  (link removed) ==
 


begin:vcard
fn;quoted-printable:St=C3=A9phane Brunner
n;quoted-printable:Brunner;St=C3=A9phane
adr:;;Suisse
email;internet:courr...@stephane-brunner.ch
x-mozilla-html:FALSE
url:http://stephane-brunner.ch
version:2.1
end:vcard


 
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Suffixes-left-right-piqure-de-rappel-tp5327383p5343390.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel



 


 OpenStreetMap est un projet international, si un site allemand ou
 anglais veut faire du routage pour vélo sur la france il utilisera les
 spécification du wiki pour créer son algorithme. Donc il serait peut
 être souhaitable de mapper comme l'indique le wiki ou de faire une
 proposition sur la liste Tagging avant de créer une méthode typiquement
 française.
 
 Le wiki définie ceci : 
 
 Pour le tag right/left
 http://wiki.openstreetmap.org/wiki/Proposed_features/right_left
 
 restreint le tag a un coté ou l'autre de la voie (respecte le sens du
 way)


Entièrement d'accord sur le principe : on on se plie à ce que dit wiki, ou on 
en discute sur la page wiki si on n'est pas content.

Mais que fait-on si ce que dit wiki est ambigu, et qu'il faut interpréter ?

Et si il y a contradiction entre deux pages wiki ?

 

A mon avis, justement, c'est le pb auquel on est confronté :

 

La page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left donne 
l'exemple d'un cas où il est valide de taguer cycleway:left=track.

Il semble qu'il s'agisse d'une voie à double sens de circulation, où, sur le 
côté gauche il y a une piste cyclable. Et si on regarde la photo, pour voir 
dans quel sens roulent les vélos, on voit le panneau bleu de face, ce qui 
laisse penser que les vélos roulent donc du bas vers le haut de la photo, càd 
dans le sens du way, càd dans le sens contraire au flux de voiture adjacent.

Si c'est cela qui est difinit comme valide, on est dans le cadre de 
l'interprétation de Lapinos, car effectivement il est dit : The key 
key=value applies only to the left-hand side of the way, with respect to 
the direction of the way's direction. 

Autrement dit, on met track pour le sens du tracé du way, et, donc, 
opposite_track pour le sens contraire.

 (si, sur cette même piste, les vélos roulaient dans le même sens que les 
voitures à côté, il faudrait donc mettre cycleway:left=opposite_track)

 

Mais en même temps, cette même page laisse entendre, au niveau du rationale 
cette fois, que right/left désigne un côté/direction (side/direction), ce qui 
rentre en contradiction avec l'interprétation précédente du cycleway:left=track 
défini comme valide, car alors, pour l'exemple de la photo, si les vélos 
roulent bien du bas vers le haut, il aurait plutôt fallu mettre 
cycleway:left=opposite_track.

 

Du coup c'est pas très clair de savoir ce qui est vraiment valide et ce qui ne 
l'est pas.

 

Mais c'est encore pire si on commence à comparer avec ce qui est dit sur la 
page http://wiki.openstreetmap.org/wiki/Bicycle surtout avec les cas L1a et B3, 
parce qu'ils indiquent que dans une voie à double sens, si il y a une bande (ce 
qui est forcément pareil que si c'était un track) sur le côté gauche dans 
laquelle les vélos doivent circuler même sens que les voitures à côté, il faut 
la noter cycleway:left=lane.

(alors que sur la photo de l'autre page, même rue à double sens, une piste sur 
la gauche qui circulent dans le sens du way on mettrait le même genre de tag 
cycleway:left=track).

J'ai essayé de faire le poirier, je comprends pas mieux comment les deux 
peuvent être valides.

 

Donc il est peut-être légitime d'en discuter, pour trancher, quitte à faire 
remonter ça au niveau international.

 

Jocelyn

 

(excusez pour l'erreur de manip'...)

 


 


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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet Mikaël Cordon

Le mardi 27 juillet 2010 21:00:04, jos sinet a écrit :
  OpenStreetMap est un projet international, si un site allemand ou
  anglais veut faire du routage pour vélo sur la france il utilisera les
  spécification du wiki pour créer son algorithme. Donc il serait peut
  être souhaitable de mapper comme l'indique le wiki ou de faire une
  proposition sur la liste Tagging avant de créer une méthode typiquement
  française.
  
  Le wiki définie ceci :
  
  Pour le tag right/left
  http://wiki.openstreetmap.org/wiki/Proposed_features/right_left
  
  restreint le tag a un coté ou l'autre de la voie (respecte le sens du
  way)
 
 Entièrement d'accord sur le principe : on on se plie à ce que dit wiki, ou
 on en discute sur la page wiki si on n'est pas content.

+1

 
 Mais que fait-on si ce que dit wiki est ambigu, et qu'il faut interpréter ?
 
 Et si il y a contradiction entre deux pages wiki ?
 
 
 
 A mon avis, justement, c'est le pb auquel on est confronté :
 

+1

 
 
 La page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left
 donne l'exemple d'un cas où il est valide de taguer cycleway:left=track.
 
 Il semble qu'il s'agisse d'une voie à double sens de circulation, où, sur
 le côté gauche il y a une piste cyclable. Et si on regarde la photo, pour
 voir dans quel sens roulent les vélos, on voit le panneau bleu de face, ce
 qui laisse penser que les vélos roulent donc du bas vers le haut de la
 photo, càd dans le sens du way, càd dans le sens contraire au flux de
 voiture adjacent.
 
 Si c'est cela qui est difinit comme valide, on est dans le cadre de
 l'interprétation de Lapinos, car effectivement il est dit : The key
 key=value applies only to the left-hand side of the way, with respect
 to the direction of the way's direction. 
 
 Autrement dit, on met track pour le sens du tracé du way, et, donc,
 opposite_track pour le sens contraire.
 
  (si, sur cette même piste, les vélos roulaient dans le même sens que les
 voitures à côté, il faudrait donc mettre cycleway:left=opposite_track)
 
 
 
 Mais en même temps, cette même page laisse entendre, au niveau du
 rationale cette fois, que right/left désigne un côté/direction
 (side/direction), ce qui rentre en contradiction avec l'interprétation
 précédente du cycleway:left=track défini comme valide, car alors, pour
 l'exemple de la photo, si les vélos roulent bien du bas vers le haut, il
 aurait plutôt fallu mettre cycleway:left=opposite_track.
 
 
 
 Du coup c'est pas très clair de savoir ce qui est vraiment valide et ce qui
 ne l'est pas.
 
 
 
 Mais c'est encore pire si on commence à comparer avec ce qui est dit sur la
 page http://wiki.openstreetmap.org/wiki/Bicycle surtout avec les cas L1a
 et B3, parce qu'ils indiquent que dans une voie à double sens, si il y a
 une bande (ce qui est forcément pareil que si c'était un track) sur le
 côté gauche dans laquelle les vélos doivent circuler même sens que les
 voitures à côté, il faut la noter cycleway:left=lane.
 
 (alors que sur la photo de l'autre page, même rue à double sens, une piste
 sur la gauche qui circulent dans le sens du way on mettrait le même genre
 de tag cycleway:left=track).
 
 J'ai essayé de faire le poirier, je comprends pas mieux comment les deux
 peuvent être valides.
 

Je rajouterais les M3 :
Le tag oneway:bicycle=no m’indiquent explicitement que les cyclistes circulent 
dans les deux sens. Or sur les schémas ce n’est pas le cas.

 
 
 Donc il est peut-être légitime d'en discuter, pour trancher, quitte à faire
 remonter ça au niveau international.
 

Je trouve hallucinant qu’on ne modélise pas les voies pour les cyclistes 
(respectivement pour les bus, taxis, tramways, etc.) comme les véhicules 
habituels !
— pour les cyclistes : 
— cycleway={lane,track,share_*way} (comme 
highway={primary,secondary,tertiary,…}
— oneway:bicycle={1,yes,no,0,-1} (comme oneway={1,yes,no,0,-1}) 
par 
rapport au tracé. Si non précisé, la voie est en double sens !
— *way:left/:right (et pourquoi pas :both, :center, :none ?) le 
placement par rapport au tracé. Et pour être plus complet, si nécessaire, on 
pourrait indicer l’ordre des voies par rapport au tracé :left:2 → « deuxième 
voie supplémentaire à gauche » etc.
— pour les bus, taxis, tramways : c’est le même schéma !


Avantages : 
— générique : même schéma quelque soit le véhicule (seuls les balises 
et 
les valeurs sont adaptés)
— les sens et les placements sont dépendants du tracé seulement, ainsi 
pas 
de torture d’esprit lorsqu’on change la valeur d’un oneway
— international (le sens est directement déduit du schéma, et pas 
interprêté selon les lois-en-vigueur-du-pays-traversé-que-personne-ne-connaît-
totalement, visiblement)
— décrit une large gamme de situations de manière univoque (1 schéma ⇒ 
un 
ensemble de tags ; ce même ensemble de tags ⇒ le même schéma)
— on connaît déjà ce schéma, on l’utilise pour les highways !


Inconvénients

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


simon a écrit :

1- b
2- b,d
3- a,d
4- b
5- a
6- b
7- c
8- c
9- c
10- d
11- c
12- Je vais voir moi même sur le terrain :)

  

+1 pour la réponse 12 ;-)



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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


Tanguy Ortolo a écrit :

Le lundi 26 juillet 2010, Lapinos03 a écrit:
  

M'enfin, pourquoi c'est si compliqué ?



À cause de quelques rares oneway=-1

  
Effectivement, ce tag ONEWAY=-1 est problématique et je me demande bien 
quel peut-être son intérêt plutôt que de retourner le way et de mettre 
oneway=yes.

(A cause des gros paresseux?)



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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Ouille ouille! Stop les oneway:=1/-1 à gogo! Le but du jeu, c'est de 
faire simple et dans la concision, mais sans rogner sur la qualité et la 
précision.



Mikaël Cordon a écrit :
J’ai suivi un peu ce fil de discussion, et j’ai effectivement l’impression 
qu’une certaine obscurité reigne chez certains.


Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et 
bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je n’ai pas 
lu précisément le wiki à ce sujet, mais en dehors des vélos, j’ai une certaine 
expérience). Alors j’ai répondu au QUIZZ avec la sensation d’avoir des 
réponses et une modélisation cohérentes. J’ai lu les questions, posé les 
balises modélisant chaque objet et condition, et je les ai combiné.


1. Une rue à double-sens (highway=*) dispose d'une bande cyclable 
(cycleway=lane) que d'un côté,


highway=* ; cycleway=lane (on pourrait préciser :left ou :right)


2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable 
(cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1) et d'une 
piste (cycleway=track) pour aller du Nord vers la Sud (oneway:bicycle=-1). Je 
mappe :


highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1


3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de chaque 
côté (cycleway:left=track ; cycleway:right=track).


si le sens des pistes n’est pas précisé :
highway=* ; cycleway:left=track ; cycleway:right=track
si il est implicite qu’il y a un seul sens par piste :
	highway=* ; cycleway:left=track ; cycleway:right=opposite_track ; 
oneway:bicycle=1 (ou -1 selon le sens à donner alors)



4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable 
(cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1), placée côté 
gauche (cycleway:left=lane). Je mappe :


highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1


5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens unique 
(oneway=1), dispose d'une bande cyclable (cycleway=lane) en contre-sens 
(oneway:bicycle=-1). Je mappe :


highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1


6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés 
au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens de 
circulation (oneway:bicycle=1). Je mappe :


highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1
Comme cycleway n’apparaît pas on pourrait le faire apparaître comme 
suit :
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1


7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés 
au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens contraire de 
circulation (oneway:bicycle=-1). Je mappe :


Même chose que 6. mais le sens des cyclistes est opposé :
highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
Comme cycleway n’apparaît pas on pourrait le faire apparaître comme 
suit :
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1


8. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable 
(cycleway=lane) en sens contraire (oneway:bicycle=-1) à ses extrémités, sur 
10m (je découpe le « way »), puis de marquages répétés au sol, chevrons+sigle 
cycliste, sur le reste de la rue (bicycle=yes). Je mappe :


sur les extrémités coupées :
highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1
sur le reste :
highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1


9. Une rue à sens unique (highway=* ; oneway=1) dispose d'un couloir de bus 
(busway=lane) en sens contraire (oneway:bus=-1) autorisé au vélo 
(bicycle=yes). Je mappe :


	highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; bicycle=1 ; 
oneway:bicycle=-1 (ici on ne voit pas que le vélo partage la voie des bus)

ou
	highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; cycleway=share_busway 
; oneway:bicycle=-1



10. Une rue (highway=*), à sens unique (oneway=1), dispose d'un couloir de bus 
(busway=lane) pour aller du Sud vers le Nord (oneway:bus=1), placée côté 
gauche (busway:left=lane). Laquelle bande de bus dispose d'une bande cyclable 
(cycleway=share_busway), placée côté gauche sur cette même bande 
(cycleway:left=lane). Je mappe :


	highway=* ; oneway=1 ; busway:left=lane ; oneway:bus=1 ; 
cycleway=share_busway ; cycleway:left=lane ; oneway:bicycle=1 (ici c’est la 
combinaison de cycleway=share_busway et cycleway:left=lane qui permet de 
déduire que la bande cyclable est sur la voie de bus)



11. Un couloir de bus à double-sens (busway=lane) n'autorise les vélos 
(bicycle=yes) dans le sens

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


Pieren a écrit :
2010/7/26 Mikaël Cordon mikael.cor...@gmail.com 
mailto:mikael.cor...@gmail.com


En confrontant les réponses avec les figures de cette page:
http://wiki.openstreetmap.org/wiki/Bicycle

1. Une rue à double-sens (highway=*) dispose d'une bande cyclable
(cycleway=lane) que d'un côté,

   highway=* ; cycleway=lane (on pourrait préciser :left ou
:right)


C'est pas 'on peut'. C'est 'on doit'. Sinon on tombe sur le cas L1a 
avec simplement cycleway=lane.

Exactement. Pieren, lui, a tout compris. ;-)




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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

Le mardi 27 juillet 2010, Mikaël Cordon a écrit :
 Je trouve hallucinant qu’on ne modélise pas les voies pour les cyclistes 
 (respectivement pour les bus, taxis, tramways, etc.) comme les véhicules 
 habituels !
   — pour les cyclistes : 
   — cycleway={lane,track,share_*way} (comme 
 highway={primary,secondary,tertiary,…}
   — oneway:bicycle={1,yes,no,0,-1} (comme oneway={1,yes,no,0,-1}) 
 par 
 rapport au tracé. Si non précisé, la voie est en double sens !
   — *way:left/:right (et pourquoi pas :both, :center, :none ?) le 
 placement par rapport au tracé. Et pour être plus complet, si nécessaire, on 
 pourrait indicer l’ordre des voies par rapport au tracé :left:2 → « deuxième 
 voie supplémentaire à gauche » etc.
   — pour les bus, taxis, tramways : c’est le même schéma !

Pfiou, ça n'a pas l'air simple.

 À propos de dupliquer les tracés pour modéliser des voies supplémentaires : 
   — mauvaise idée : 
   — topologiquement c’est une erreur de séparer deux voies qui 
 suivent 
 le même tracé.
   — allourdissement du schéma, et de la base (mais c’est 
 secondaire)
   — masque aux utilisateurs (calculateurs, GPS, etc.) qu’ils 
 peuvent 
 éventuellement passer d’une voie à l’autre (si nécessaire ; par ex. travaux 
 sur une voie et passer sur celle d’à côté)
   — pas si mauvaise idée pour les cas vraiment complexes, ou les voies 
 physiquement séparées (tracks).

Pluzun.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

2010-07-27 Par sujet Mikaël Cordon

Le mardi 27 juillet 2010 23:26:01, Lapinos03 a écrit :
 Ouille ouille! Stop les oneway:=1/-1 à gogo! Le but du jeu, c'est de
 faire simple et dans la concision, mais sans rogner sur la qualité et la
 précision.

Faire simple pour qui ? Pour nous ? Pour les futurs utilisateurs (lecteurs, 
développeurs, GPS) ?

Mais alors comment indiquer les sens de circulation de chacune des voies alors 
? En faisant tout hériter les sens de circulation des unes des autres ? En 
jouant avec les opposite_* ?

Évidemment, si on veut préciser le sens des voies dans un système multiple, il 
faut un moyen d’identifier le sens de chacune des voies du groupe, sachant 
qu’on ne peut pas déduire le sens dans toutes les situations, ou alors il faut 
jouer avec les « opposite_* », mais alors ça revient à multiplier les valeurs 
plutôt que les tags ; c’est un choix, mais si on veut rester cohérent avec le 
modèle des highways…

Je trouve que les oneway ont le mérite d’être simple et sans équivoque : 
oneway=1 ou yes ⇒ dans le sens du tracé, point.
oneway=-1 ou no ⇒ dans le sens opposé du tracé, point.
Si oneway n’est pas précisé, alors aucun sens privilégié ⇒ les deux sens, 
point.

Je ne vois pas ce qu’il y a de compliqué là-dedans, il suffit de préciser. Il 
n’y a aucun calcul d’héritage de sens circulation ou de déduction, il suffit 
de lire.

Ne me dites pas que vous êtes flemmard pour 1 tag par voie ? Vous qui avez 
déjà créé des milliers de tracés et de nœuds :)

 
 Mikaël Cordon a écrit :
  J’ai suivi un peu ce fil de discussion, et j’ai effectivement
  l’impression qu’une certaine obscurité reigne chez certains.
  
  Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et
  bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je
  n’ai pas lu précisément le wiki à ce sujet, mais en dehors des vélos,
  j’ai une certaine expérience). Alors j’ai répondu au QUIZZ avec la
  sensation d’avoir des réponses et une modélisation cohérentes. J’ai lu
  les questions, posé les balises modélisant chaque objet et condition, et
  je les ai combiné.
  
  1. Une rue à double-sens (highway=*) dispose d'une bande cyclable
  (cycleway=lane) que d'un côté,
  
  highway=* ; cycleway=lane (on pourrait préciser :left ou :right)
  
  2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande
  cyclable (cycleway=lane) pour aller du Sud vers le Nord
  (oneway:bicycle=1) et d'une piste (cycleway=track) pour aller du Nord
  vers la Sud (oneway:bicycle=-1). Je
  
  mappe :
  highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1
  
  3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de
  chaque côté (cycleway:left=track ; cycleway:right=track).
  
  si le sens des pistes n’est pas précisé :
  highway=* ; cycleway:left=track ; cycleway:right=track
  si il est implicite qu’il y a un seul sens par piste :
  highway=* ; cycleway:left=track ; cycleway:right=opposite_track ;
  
  oneway:bicycle=1 (ou -1 selon le sens à donner alors)
  
  
  4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande
  cyclable (cycleway=lane) pour aller du Sud vers le Nord
  (oneway:bicycle=1), placée côté
  
  gauche (cycleway:left=lane). Je mappe :
  highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1
  
  5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens
  unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) en
  contre-sens
  
  (oneway:bicycle=-1). Je mappe :
  highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
  ou
  highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1
  
  6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages
  répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens
  de
  
  circulation (oneway:bicycle=1). Je mappe :
  highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1
  Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit
  : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1
  
  7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages
  répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens
  contraire de
  
  circulation (oneway:bicycle=-1). Je mappe :
  Même chose que 6. mais le sens des cyclistes est opposé :
  highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
  Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit
  : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1
  
  8. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande
  cyclable (cycleway=lane) en sens contraire (oneway:bicycle=-1) à ses
  extrémités, sur 10m (je découpe le « way »), puis de marquages répétés
  au sol, chevrons+sigle
  
  cycliste, sur le reste de la rue (bicycle=yes). Je mappe :
  sur les extrémités coupées :
  highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
  ou
  highway=* ; oneway=1 ;

Re: [OSM-talk-fr] [JM2L 2010] Invitation de conf érencier

2010-07-27 Par sujet arno

Le mercredi 21 juillet 2010, à 15:40:50 +0200, Organisation a écrit : 
 Contact : talk + Arno- projet Openstreetmap
 
 Bonjour :-)

bonjour,


 Nous avons le plaisir de t'inviter à faire une présentation de
 Openstreetmap durant notre prochaine JM2L qui aura lieu dans
 une école d'ingénieurs de Sophia Antipolis:
 
 http://jm2l.linux-azur.org
 
 Il s'agira de la cinquième édition des Journées Méditerranéennes du
 Logiciel Libre.
 
 Tu pourras choisir la date:
   - soit le vendredi 26 novembre 2010
   - soit le samedi 27 novembre 2010
   - ou bien les deux
 
 Tu peux demander un espace stand avec goodies à vendre, créer un
 atelier, faire une démo, préférer une conférence et, cumuler les
 actions.
 

je suis intéressé pour venir. Comme je ne sais pas encore si je pourrais venir 
le vendredi, je préfère dire que je viens le samedi.

Je ne sais pas encore si nous serons assez nombreux pour tenir un stand toute 
la journée, mais ça me dit bien, d'organiser, un atelier d'environ une heure 
pour apprendre à utiliser les outils qui permettent de contribuer à 
openstreetmap (josm notamment).

 i) La conférence sera d'une durée de 40-45 minutes suivie d'une plage
 de 10 minutes pour les QA) . Nous avons aussi besoin d'un petit
 résumé-annonce (deux ou trois phrases) que nous insérerons dans le
 site Web dédié à la manifestation (jm2l.linux-azur.org).


J'aimerais profiter de l'occasion pour présenter, en plus d'openstreetmap, 
syj, mon projet de partage d'itinéraires si je l'ai bien avancé d'ici là. 
Sinon, il y'a toujours d'autres projets qui utilisent osm, du coup, je propose 
un intitulé du style (à adapter si besoin):

OpenStreetMap, le projet de cartographie libre et collaborative. Découvrez
l'histoire de la carte, comment la carte est créée au jour le jour, et 
comprenez son intérêt à travers la présentation de projets concrets utilisant 
OpenStreetMap

c'est bien ?

a+
arno


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


GaelADT a écrit :

Tout le monde répond b à la question 2

Cependant d'après les explications de Lapinos03 je pense qu'il s'attendait à
ce que vous répondiez la réponse c.

  

Oui, la bonne réponse est C.

Ainsi je trouve que l'on n'avance pas beaucoup... En fait le seul est unique
problème est celui-ci : lorsque l'on utilise cycleway:left qu'est ce que
cela veut dire ? 

...qu'il est à gauche du tracé.

Si je lui colle la valeur lane/opposite_lane ou
track/opposite_track, qu'est-ce que ça veut dire ?

...le sens de circulation, peu importe que ce soit à gauche ou à droite.

 Est-ce que le sens de
création du tronçon influe sur ces valeurs ? Est-ce que le tag oneway influe
sur ces valeurs ? Je me rend compte qu'il y a 2 visions différentes... Je
pense qu'il est temps pour la communauté de décider, de l'écrire noir sur
blanc sur le wiki et de s'y tenir !

  
Sur quoi se base oneway? Sur le tracé. Pareillement, lane/opposite_lane 
doit (devrait) le faire aussi pour éviter toute *interdépendance* de tags!

Au passage, le cas n'est pas si rare que ça, sur Paris je compte 300
tronçons du route (intersection à intersection) où ce cas se présente.
Aujourd'hui Géovélo envoit les cyclistes au petit bonheur la chance dans le
bon sens ou dans un sens interdit en fonction de la vision du
contributeur. Peut-on se mettre d'accord une bonne fois pour toute :) ?

Gaël.
  

C'est le but de ce fil... ;-)




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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel


Tanguy Ortolo a écrit :

Le mardi 27 juillet 2010, GaelADT a écrit :
  

Tout le monde répond b à la question 2

Cependant d'après les explications de Lapinos03 je pense qu'il s'attendait à
ce que vous répondiez la réponse c.



Rappel de la question :
  

2. Une rue à sens unique dispose d'une bande cyclable pour aller du Sud
   vers le Nord et d'une piste pour aller du Nord vers la Sud.
   b. [cycleway:right]=lane [cycleway:left]=track
   c. [cycleway:right]=lane [cycleway:left]=opposite_track
  


Et rappel des règles :
  

1. LANE / TRACK suivent le sens de la circulation automobile, le sens
   directeur maître étant celui du tracé. Evidemment, dans une
   circulation à double-sens, le sens du tracé n'a que peu
   d'importance.  Avec un [oneway]=yes, cela devient significatif.
   Par défaut, LANE / TRACK suivent la même règle que la circulation
   automobile, en direction(s) et en nombre de voies.
2. OPPOSITE / OPPOSITE_LANE / OPPOSITE_TRACK indique un sens
   contraire au sens du tracé pour éloigner toute équivoque.
  


Dans un tel cas, indiquer qu'il y a à gauche une piste, et à droite une
voie est suffisant : d'après la règle 1, elles suivent le sens de la
circulation automobile.

Effectivement, compte tenu de la règle 2, on pourrait indiquer que la
piste de gauche est orientée en sens contraire au tracé, mais c'est là
une information superflue, cette précision n'étant nécessaire que pour
les équipements qui ne suivent pas le sens de la circulation automobile.

  

En fait, le point (1) faisait référence au cas de figure :
highway=*
cycleway=lane
On aura 2 lanes dès lors qu'il y a double-sens de circulation du 
highway. 1 lane dans le cas contriare. C'est en cela que le schéma du 
lane suit celui du highway. C'est une règle qui date de l'origine. Si 
l'on voudrait spécifier chacun des lane gauche et droite, on devrait mettre:

cycleway:right=lane
cycleway:left=opposite_lane

Et s'il fallait dissocier highway en highway:left et highway:right, vous 
(-tout le monde-) mettriez quoi?


Mais la question (2) présente une configuration à 2 types de piste, ce 
qui nous oblige à distinguer les côtés gauche et droit.




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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


Tanguy Ortolo a écrit :

En revanche, devoir noter systématiquement « opposite » pour les
équipements uniques dans le sens contraire au tracé, c'est pénible.
Reviens à mon post initial et donne-moi le(s) tag(s) que tu mettrais 
pour décrire la StreetView (3). Je veux savoir que la piste est bien à 
gauche et pas à droite.




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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


simon a écrit :

OpenStreetMap est un projet international, si un site allemand ou
anglais veut faire du routage pour vélo sur la france il utilisera les
spécification du wiki pour créer son algorithme. Donc il serait peut
être souhaitable de mapper comme l'indique le wiki ou de faire une
proposition sur la liste Tagging avant de créer une méthode typiquement
française.
  
Justement, il n'y a rien de typiquement français, le méthode est 
internationale.
Le wiki définie ceci : 


Pour le tag right/left
http://wiki.openstreetmap.org/wiki/Proposed_features/right_left

restreint le tag a un coté ou l'autre de la voie (respecte le sens du
way)


Pour le tag cycleway : 
http://wiki.openstreetmap.org/wiki/Key:cycleway


opposite_lane

The route is a lane, but bicycles may go in the direction opposite of
other traffic. Only applies where oneway=yes.

La route à une piste cyclabe dans la direction opposé aux AUTRES
TRAFIQUES

opposite

The route may be cycled in the direction opposite of other traffic, but
does not have a dedicated lane. Note - such streets are common in
Belgium, the Netherlands and Denmark, for example, but are rare in the
UK (although they do exist): often, instead, actually the street is
two-way as normal for its whole length except for the very short section
past the no-entry sign at the end, where cycles are excepted from the
no-entry by means of a short lane separated by an island. This is called
a cycle plug. In some places this has been represented as very short
oneway Way at the end with an adjacent cycleway, forming a little
triangle with the road they join to.

la route peut être prise a contre sens des AUTRES TRAFIQUES sans avoir
de voie dédié.

Ce qui nous donne comme synthèse la page
http://wiki.openstreetmap.org/wiki/Bicycle avec de jolie exemples.

Ensuite si chacun tag a sa manière sans respecter le consensus ou en
définissant un nouveau schéma pour chaque pays, région, ville ... je ne
vois pas l'intérêt d'avoir un projet mondial et collaboratif.

Ce schéma n'est bien sur pas complet pas complet et il reste quelque
point imprécis. Mais respectons la documentation la ou il y a consensus
et pour le reste faisons des propositions dans la partie proposed
feature et documentons le wiki.

Simon
  
Tout à fait, la wiki est incomplète et doit être étoffée au fil du temps 
afin de couvrir tous les cas de figures dans la globalité du monde, 
sous-entendu l'ensemble des particularités de chaque pays. C'est à ce 
prix que OSM sera un digne challenger des concurrents commerciaux.





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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel


jos sinet a écrit :


 
Bon, je me décide à entrer dans le débat parce que je suis celui avec 
qui Lapinos avait un différend, lequel différend l'a poussé à 
intervenir sur la mailing-list, afin de faire comme il dit une piqûre 
de rappel. Sauf que cette piqûre  a surtout rappelé que personne ne 
voit les choses de la même façon... (à moins que Lapinos ne nous dise 
qu'il est d'accord avec les réponses 2.b données par tout le monde à 
son fameux quiz).

f-u-meux quiz :-)
 
Il me semble que l'enjeu de toute la discussion, qui est partie de la 
façon de définir les suffixes :right/:left, est de parvenir à bien 
identifier le sens de circulation des vélos (mais aussi, je le 
rappelle, des bus) à partir des tags conventionnés.
Se mettre d'accord sur la signification des tags et leur 
usage permettra de savoir clairement comment se 'déduit' le sens de 
circulation vélo (et bus), dans tous les cas.
 
Or, dans la discussion qui a eut lieu jusqu'à présent, il y a trois 
normes différentes possibles, trois interprétations possibles des 
mêmes tags qui sont apparues. Interprétations entre lesquelles il va 
falloir *trancher* pour que tout le monde ait la même compréhension 
des conventions, et le même usage des tags :
 
 
   A. Soit les suffixes :right/:left indiquent uniquement un côté de 
la voie en fonction du tracé du way, et en aucun cas un sens de 
circulation implicite. Le sens de circulation vélo étant donné par les 
valeurs lane/opposite_lane (ça marche aussi avec track bien sûr), 
lesquelles se comprennent en fonction du sens du tracé : lane dans le 
sens du tracé, opposite_lane dans le sens contraire.

C'est, si je comprends bien, l'option de Lapinos03.

Exactement.

Du coup, trois cas typiques :
 
  1. Dans une rue à sens unique, la bande est placée sur le côté 
gauche. Si elle suit le sens du way (et donc de la circulation 
voiture), on écrit cycleway:left=lane. Si les vélos roulent dans le 
sens contraire, on met cycleway:left=opposite_lane (ou plus simplement 
cycleway=opposite_lane).

Exact.
  2. Dans une rue à double sens, les vélos ne disposent d'une 
bande que d'un seul côté. Si elle est du côté droit, alors on 
met cycleway:right=lane, ou, plus simplement, cycleway=lane (puisque 
c'est seulement lane/opposite_lane qui donne le sens de circulation -- 
et que, a priori, comme on roule à droite en France, la bande qui va 
dans le sens du way est, elle aussi, à droite).
Faux. Par héritage de la règle initiale, cycleway=lane sera dans le même 
sens ou dans les 2 sens selon que la highway est à sens unique ou à 
double-sens. Donc, ici, il faut préciser cycleway:right=lane
Si la bande est du côté gauche, alors on met 
cycleway:left=opposite_lane, ou, plus simplement, 
cycleway=opposite_lane (pour la même raison).
Si la circulation cycliste est en sens opposé du tracé, oui, que le 
highway soit oneway ou non.
  3. Ce qui signifie que quand on a une bande des deux côtés (dans 
une voie à double sens toujours), on ne peut pas mettre cycleway=lane. 
On est obligé de mettre cycleway:right=lane *et* 
cycleway:left=opposite_lane.

Faux. C'est l'héritage de la règle initiale (la Map_features).
 
Cette interprétation est cohérente, mais on peut lui faire plusieurs 
objections.
 D'une part elle est contradictoire avec ce qui est recommandé sur la 
page wiki (http://wiki.openstreetmap.org/wiki/Bicycle) en L1, et avec 
B3 pour cycleway:left. D'autre part, elle préconise un usage assez 
paradoxal ou nouveau de opposite-lane qui, du coup, ne signifie plus 
nécessairement dans le sens contraire au flux de voiture, mais 
seulement dans le sens contraire au tracé du way. Et enfin, elle 
oblige à créer un nouveau tag pour le cas où, dans une rue à double 
sens de circulation, il y a un couloir de bus à sens unique au milieu 
de la chaussée. Je n'ai pas d'exemple, mais si ce cas se présente, que 
fait-on : on met busway:middle=*, busway:centre=* ?
 
Il faudrait déjà un exemple pour savoir si le cas est véridique. Après, 
on avise.
 
   B. Soit on maintient le schéma précédent, la définition restrictive 
des suffixes :right/:left comme désignant uniquement un côté (un 
side), mais on veut simplifier et rendre plus pratique, et on dit que 
le sens de circulation des vélos est toujours donné par 
lane/opposite_lane, mais que ces valeurs ne se définissent plus en 
fonction du tracé du way, mais seulement en fonction du sens de 
circulation des voitures, càd selon qu'on est en oneway=yes, ou pas.

C'est, si je comprends bien, la voie médiane à laquelle Gaël tend.
Du coup :
 
  1. Dans une rue à sens unique, la bande est placée côté gauche. 
On écrira la même chose que dans l'interprétation A.
  2. En revanche, double sens de circulation voiture, la bande 
n'est que d'un côté. Si elle est à droite, on pourra uniquement écrire 
cycleway:right=lane (et non plus cycleway=lane). 

Exact.
Si elle est à gauche, on pourra uniquement écrire cycleway:left=lane 
(et non plus cycleway:left=opposite_lane, ni

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel


Tanguy Ortolo a écrit :

Merci pour cette clarification.

Le mardi 27 juillet 2010, jos sinet a écrit :
  

   A. Soit les suffixes :right/:left indiquent uniquement un côté de la voie en 
fonction du tracé du way, et en aucun cas un sens de circulation implicite. Le 
sens de circulation vélo étant donné par les valeurs lane/opposite_lane (ça 
marche aussi avec track bien sûr), lesquelles se comprennent en fonction du 
sens du tracé : lane dans le sens du tracé, opposite_lane dans le sens 
contraire.



Pour moi, c'est trop compliqué. Devoir marquer systématiquement de la
façon la plus complexe possible (un tag pour chaque côté plus une
précision de sens) le cas le plus simple qui existe (route double sens
avec piste cyclable de chaque côté), ce n'est pas normal.

  

highway=* cycleway=lane . Rien de plus simple. Qui dit le contraire?

   B. Soit on maintient le schéma précédent, la définition restrictive des 
suffixes :right/:left comme désignant uniquement un côté (un side), mais on 
veut simplifier et rendre plus pratique, et on dit que le sens de circulation 
des vélos est toujours donné par lane/opposite_lane, mais que ces valeurs ne se 
définissent plus en fonction du tracé du way, mais seulement en fonction du 
sens de circulation des voitures, càd selon qu'on est en oneway=yes, ou pas.



Ce n'est pas clair. Vu tes examples, je comprends qu'une lane irait dans
le sens unique pour les oneway=yes/-1 et dans le sens des voitures du
même côté pour les double-sens.

Ça me semble le plus intuitif. Dans une rue à sens unique, une bande, à
gauche ou à droite, est habituellement comprise comme allant dans le
sens de la rue, sinon on parle de bande à contresens.

  

   C. Soit, c'est mon option, les suffixes :right/:left désignent aussi, et 
même avant tout, un sens de circulation implicite : right pour le sens du tracé 
du way, et :left pour le sens de circulation contraire. Ils désignent un 
côté/direction (side/direction), comme il est sous-entendu sur la page de 
discussion des suffixes 
(http://wiki.openstreetmap.org/wiki/Proposed_features/right_left).



La seule différence avec l'option B, c'est la lane à gauche d'une voie à
sens unique. Il me semble contre-intuitif de la qualifier simplement de
lane si elle va à contresens de la rue.

  

Tout à fait !


Pour le cas des voies de bus au milieu, il me semble utopique de vouloir
représenter ça de façon pratique avec seulement des tags. Lorsque la
configuration est suffisamment particulière pour qu'ils soit nécessaire
de préciser que la voie de bus est au milieu, il me semble qu'il vaut
mieux faire des tracés dédiés.

  
Je n'ai connaissance que de très peu de cas de ce genre. Pour le coup, 
ces couloirs à double sens sont séparés du trafic automobiles par des 
digues (bourrelets, ilôts - je ne sais quel terme exact) de béton. En 
conséquence de quoi, ils doivent être tracés indépendamment.





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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel

2010-07-27 Par sujet hamster


Lapinos03 a écrit :
Dans les questions qui suivent, la rue est tracée à la verticale et 
s'étire du Sud vers le Nord. On fera fi du tag [highway]=* et 
[oneway]=yes pour les rues à sens niques, le cas échéant. Les 
pistes/bandes cyclables sont naturellement placées en fonction du 
système de conduite, sauf mention contraire. Plusieurs réponses sont 
parfois possibles mais il faut donner la plus pertinente. Qui fera un 
sans-faute ? ;-)


---

1. Une rue à double-sens dispose d'une bande cyclable que d'un côté, 
pour aller du Sud vers le Nord. Je mappe :


[cycleway]=lane sur le way qui represente la bande cyclable en question, 
le sens du way indique le sens de circulation


2. Une rue à sens unique dispose d'une bande cyclable pour aller du 
Sud vers le Nord et d'une piste pour aller du Nord vers la Sud. Je mappe :


[cycleway]=lane sur le way qui represente la bande cyclable et 
[cycleway]=track sur le way qui represente la piste,  le sens des ways 
indiquent les sens de circulation


3. Une rue, à double-sens, dispose d'une piste cyclable de chaque 
côté. Je mappe :


a. [cycleway]=track sur chaque way reprensentant les pistes, les sens 
des ways indiquent les sens de circulation


4. Une rue, à sens unique, dispose d'une bande cyclable pour aller du 
Sud vers le Nord, placée côté gauche. Je mappe :


[cycleway]=lane sur le way qui represente la bande cyclable en question, 
le sens du way indique le sens de circulation


5. Je suis en Angleterre. Une rue, à sens unique, dispose d'une bande 
cyclable en contre-sens. Je mappe :


[cycleway]=lane sur le way qui represente la bande cyclable en question, 
le sens du way indique le sens de circulation


6. Une rue à sens unique dispose de marquages répétés au sol, 
chevrons+sigle cycliste, dans le même sens de circulation. Je mappe :


b. [bicycle]=yes sur le way qui represente la voie des voitures

7. Une rue à sens unique dispose de marquages répétés au sol, 
chevrons+sigle cycliste, dans le sens contraire de circulation. Je mappe :


[bicycle]=opposite

8. Une rue à sens unique dispose d'une bande cyclable en sens 
contraire à ses extrémités, sur 10m, puis de marquages répétés au sol, 
chevrons+sigle cycliste, sur le reste de la rue. Je mappe :


pour les extremites sur 10 m : [cycleway]=lane sur le way qui represente 
la bande cyclable en question, le sens du way indique le sens de circulation

pour le reste : [bicycle]=opposite

9. Une rue à sens unique dispose d'un couloir de bus en sens contraire 
autorisé au vélo. Je mappe :


[bicycle]=yes sur le way qui represente le couloir de bus

10. Une rue, à sens unique, dispose d'un couloir de bus pour aller du 
Sud vers le Nord, placée côté gauche. Laquelle bande de bus dispose 
d'une bande cyclable, placée côté gauche sur cette même bande. Je mappe :


a. [cycleway]=lane sur le way qui represente la bande cyclable en 
question, le sens du way indique le sens de circulation


11. Un couloir de bus à double-sens n'autorise les vélos dans le sens 
sud-nord. Je mappe :


a. [bicycle]=yes sur celui des 2 ways de couloir de bus qui va dans le 
bon sens


12. Une rue est mappée [oneway]=-1 et [cycleway]=opposite_lane. Je 
retourne la rue et modifie [oneway]=yes. Que devient cycleway?


un way a part

c'est tellement plus simple !

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel