date:20151110

En fait je me suis trompé, en relisant l'historique
http://www.openstreetmap.org/way/307302039/history
le contributeur Pinpin avait l'aire de dire que le nom avait était
vérifié sur le terrain, avec un "z", mais le contributeur Niconil est
revenu en arrière et a introduit l'incohérence. Il faudrait le
contacter.


Le 10 novembre 2015 20:21, Tyndare  a écrit :
> Bonjour,
>
> Cette incohérence est effectivement une erreur, et est signalée comme
> telle par le validateur JOSM et par Osmose.
> Mais à priori le contributeur de la relation associatedStreet était
> bien conscient de cette incohérence entre le nom du chemin présent
> dans la base OSM, et le nom associé aux adresses tel qu'importé depuis
> le cadastre (celui de la relation associatedStreet), c'est pourquoi il
> à rajouté une note à ce propos sur le chemin: à vérifier sur le
> terrain.
> Si tu trouves la bonne orthographe n'hésite pas à corriger celle qui
> est erronée.
>
> A noté qu'en pratique il peut être nécessaire d'avoir une relation
> associatedStreet avec un nom différent de celui de la rue si la rue en
> question à plusieurs noms, par exemple un nom différent de chaque côté
> (cas assez fréquent en limite de commune). La rue peut avoir un
> name:left, un name:right, un name="name:left - name:right", et en
> général on créé deux relations associatedStreet, une pour chacun des 2
> noms.
>
> Tyndare.
>
>
> Le 10 novembre 2015 19:09, Laurent Combe  a écrit :
>> bonjour à tous
>>
>> depuis quelques semaines je passe une partie de mon temps à dégommer du
>> rouge sur le rendu BANO
>> pour l'instant je me concentre sur l'aspect rapprochement des voies.
>>
>> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
>> d'adresse au numero
>>
>> et je suis tombé sur ça
>> http://www.openstreetmap.org/#map=18/43.75258/1.39305
>>
>> rien de bien spécial
>> il s'agit d'un way dénommé "Chemin de Gleyses"
>>
>> mais en regardant "un peu par hasard" avec JOSM
>> je voie que la relation associatedStreet porte son propre tag name
>> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
>>
>> je trouve cela bizarre que la relation porte
>> un tag name et indirectement au travers d'un de ses membres (le way) un
>> autre tag name
>> avec un risque possible d'incohérence comme dans ce cas
>>
>> ça me fait penser un  peu à de la double saisie...
>> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne doit
>> pas tester cela car je n'ai rien vu.
>>
>> Laurent
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>

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

Re: [OSM-talk-fr] relation associatedStreet

ok j'avais une vue Osmose très partielle ...
merci

Le 10 novembre 2015 20:18, Frédéric Rodrigo  a
écrit :

> Le 10/11/2015 19:09, Laurent Combe a écrit :
>
>> bonjour à tous
>>
>> depuis quelques semaines je passe une partie de mon temps à dégommer du
>> rouge sur le rendu BANO
>> pour l'instant je me concentre sur l'aspect rapprochement des voies.
>>
>> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
>> d'adresse au numero
>>
>> et je suis tombé sur ça
>> http://www.openstreetmap.org/#map=18/43.75258/1.39305
>>
>> rien de bien spécial
>> il s'agit d'un way dénommé "Chemin de Gleyses"
>>
>> mais en regardant "un peu par hasard" avec JOSM
>> je voie que la relation associatedStreet porte son propre tag name
>> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
>>
>> je trouve cela bizarre que la relation porte
>> un tag name et indirectement au travers d'un de ses membres (le way) un
>> autre tag name
>> avec un risque possible d'incohérence comme dans ce cas
>>
>> ça me fait penser un  peu à de la double saisie...
>> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne
>> doit pas tester cela car je n'ai rien vu.
>>
>
> Si Osmose fait bien ça :
>
> http://osmose.openstreetmap.fr/fr/map/#zoom=17=43.75258=1.39304==1%2C2%2C3
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation associatedStreet

Bonjour,

Cette incohérence est effectivement une erreur, et est signalée comme
telle par le validateur JOSM et par Osmose.
Mais à priori le contributeur de la relation associatedStreet était
bien conscient de cette incohérence entre le nom du chemin présent
dans la base OSM, et le nom associé aux adresses tel qu'importé depuis
le cadastre (celui de la relation associatedStreet), c'est pourquoi il
à rajouté une note à ce propos sur le chemin: à vérifier sur le
terrain.
Si tu trouves la bonne orthographe n'hésite pas à corriger celle qui
est erronée.

A noté qu'en pratique il peut être nécessaire d'avoir une relation
associatedStreet avec un nom différent de celui de la rue si la rue en
question à plusieurs noms, par exemple un nom différent de chaque côté
(cas assez fréquent en limite de commune). La rue peut avoir un
name:left, un name:right, un name="name:left - name:right", et en
général on créé deux relations associatedStreet, une pour chacun des 2
noms.

Tyndare.


Le 10 novembre 2015 19:09, Laurent Combe  a écrit :
> bonjour à tous
>
> depuis quelques semaines je passe une partie de mon temps à dégommer du
> rouge sur le rendu BANO
> pour l'instant je me concentre sur l'aspect rapprochement des voies.
>
> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
> d'adresse au numero
>
> et je suis tombé sur ça
> http://www.openstreetmap.org/#map=18/43.75258/1.39305
>
> rien de bien spécial
> il s'agit d'un way dénommé "Chemin de Gleyses"
>
> mais en regardant "un peu par hasard" avec JOSM
> je voie que la relation associatedStreet porte son propre tag name
> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
>
> je trouve cela bizarre que la relation porte
> un tag name et indirectement au travers d'un de ses membres (le way) un
> autre tag name
> avec un risque possible d'incohérence comme dans ce cas
>
> ça me fait penser un  peu à de la double saisie...
> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne doit
> pas tester cela car je n'ai rien vu.
>
> Laurent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

[OSM-talk-fr] relation associatedStreet

bonjour à tous

depuis quelques semaines je passe une partie de mon temps à dégommer du
rouge sur le rendu BANO
pour l'instant je me concentre sur l'aspect rapprochement des voies.

Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
d'adresse au numero

et je suis tombé sur ça
http://www.openstreetmap.org/#map=18/43.75258/1.39305

rien de bien spécial
il s'agit d'un way dénommé "Chemin de Gleyses"

mais en regardant "un peu par hasard" avec JOSM
je voie que la relation associatedStreet porte son propre tag name
et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')

je trouve cela bizarre que la relation porte
un tag name et indirectement au travers d'un de ses membres (le way) un
autre tag name
avec un risque possible d'incohérence comme dans ce cas

ça me fait penser un  peu à de la double saisie...
j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne
doit pas tester cela car je n'ai rien vu.

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

Re: [OSM-talk-fr] Import canaux cadastre pas terrible

Ce n'est pas tant qu'ils soient importés comme des aires
("waterway=riverbank" ou "water=riverbank") que le fait qu'ils forment des
sections discontinues, non connectées entre elles et qu'en revanche il
manque le filaire avant tout ("waterway=canal"...), et une éventuelle
relation rassemblant les segments et à la quelle on peut attacher un numéro
de référence hydrologique.
Le "pas beau" aurait été une géométrie trop peu précise mais cela n'est pas
le cas ici.

Le 10 novembre 2015 20:03, Léo Serre  a écrit :

> Bonjour à tous,
>
> Je me considère comme un contributeurs novice (dans le sens que je n'ose
> toucher qu'aux trucs simples).
> Je suis face à un import qui a importé des trucs pas très beaux :
>
>
> http://osmose.openstreetmap.fr/fr/map/#zoom=13=43.7347=1.7224=1220=3=Mapnik=T
>
> Savez-vous ce que je peux faire pour corriger toutes ces erreurs dues à
> ces canaux importés comme des aires ?
>
> Merci d'avance.
>
> Léo
>
> --
> [image: LSTRONIC logo]
>
> Léo SERRE
>
> [image: mail]   l...@lstronic.com
> [image: website]  lstronic.com
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation associatedStreet

2015-11-10 Par sujet Frédéric Rodrigo


Le 10/11/2015 19:09, Laurent Combe a écrit :

bonjour à tous

depuis quelques semaines je passe une partie de mon temps à dégommer 
du rouge sur le rendu BANO

pour l'instant je me concentre sur l'aspect rapprochement des voies.

Cependant de temps en temps je jette un oeil sur ce qui se fait en 
terme d'adresse au numero


et je suis tombé sur ça
http://www.openstreetmap.org/#map=18/43.75258/1.39305

rien de bien spécial
il s'agit d'un way dénommé "Chemin de Gleyses"

mais en regardant "un peu par hasard" avec JOSM
je voie que la relation associatedStreet porte son propre tag name
et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')

je trouve cela bizarre que la relation porte
un tag name et indirectement au travers d'un de ses membres (le way) 
un autre tag name

avec un risque possible d'incohérence comme dans ce cas

ça me fait penser un  peu à de la double saisie...
j'imagine qu'osmose est capable de faire le job mais dans mon cas il 
ne doit pas tester cela car je n'ai rien vu.


Si Osmose fait bien ça :
http://osmose.openstreetmap.fr/fr/map/#zoom=17=43.75258=1.39304==1%2C2%2C3

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

Re: [OSM-talk-fr] Import canaux cadastre pas terrible

note: pour reconnecter ces canaux ou petits ruisseaux, on ne peut pas les
tracer à la volé: si des segments ne sont pas dans le cadastre, c'est
souvent qu'ils sont souterrains (tunnel=yes, layer=-1) et pas
tracés/repérés.

Le 10 novembre 2015 20:14, Philippe Verdy  a écrit :

> Ce n'est pas tant qu'ils soient importés comme des aires
> ("waterway=riverbank" ou "water=riverbank") que le fait qu'ils forment des
> sections discontinues, non connectées entre elles et qu'en revanche il
> manque le filaire avant tout ("waterway=canal"...), et une éventuelle
> relation rassemblant les segments et à la quelle on peut attacher un numéro
> de référence hydrologique.
> Le "pas beau" aurait été une géométrie trop peu précise mais cela n'est
> pas le cas ici.
>
> Le 10 novembre 2015 20:03, Léo Serre  a écrit :
>
>> Bonjour à tous,
>>
>> Je me considère comme un contributeurs novice (dans le sens que je n'ose
>> toucher qu'aux trucs simples).
>> Je suis face à un import qui a importé des trucs pas très beaux :
>>
>>
>> http://osmose.openstreetmap.fr/fr/map/#zoom=13=43.7347=1.7224=1220=3=Mapnik=T
>>
>> Savez-vous ce que je peux faire pour corriger toutes ces erreurs dues à
>> ces canaux importés comme des aires ?
>>
>> Merci d'avance.
>>
>> Léo
>>
>> --
>> [image: LSTRONIC logo]
>>
>> Léo SERRE
>>
>> [image: mail]   l...@lstronic.com
>> [image: website]  lstronic.com
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Import canaux cadastre pas terrible

2015-11-10 Par sujet Léo Serre

Bonjour à tous,

Je me considère comme un contributeurs novice (dans le sens que je n'ose
toucher qu'aux trucs simples).
Je suis face à un import qui a importé des trucs pas très beaux :

http://osmose.openstreetmap.fr/fr/map/#zoom=13=43.7347=1.7224=1220=3=Mapnik=T

Savez-vous ce que je peux faire pour corriger toutes ces erreurs dues à
ces canaux importés comme des aires ?

Merci d'avance.

Léo

-- 
LSTRONIC logo

Léo SERRE

mail  l...@lstronic.com 
website  lstronic.com 

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

Re: [OSM-talk-fr] relation associatedStreet

Le 10 novembre 2015 20:38, Laurent Combe  a écrit :
> Niconil
> c'est moi

Ça simplifie grandement les choses pour résoudre le conflit ;-)

> La bonne nouvelle : j'ai accès au tableau de classement de la voirie de la
> commune.
> Après vérification c'est effectivement la version avec un 'z'
> je corrige ...

Vu que sur le cadastre le nom est mal orthographié avec un 's', ça
aurais était bien je pense de laisser la note ou de la remplacer par
le plus classique source:name=survey histoire de lever l'incohérence
avec le tag source actuel et dissuader d'autres
 tentatives de changement dans le futur.

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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

2015-11-10 Par sujet osm . sanspourriel

> Tu remarqueras aussi l'importance de la virgule pour le géocodage.
C'est effectivement un peu agaçant avec Nominatim, mais "36, route d'ifs, Caen" te sort bien la bonne adresse.

Route, pas rue.


Jean-Yvon


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

Re: [OSM-talk-fr] Rouen - Pont Mathilde - j'ai un doute sur 3 voies

2015-11-10 Par sujet Plop76


david.croc...@online.fr a écrit :

Bonjour

Vous en pensez quoi de ces trois voies :

https://www.openstreetmap.org/way/188324016 
https://www.openstreetmap.org/way/188324013

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

ils se suivent et des étiquettes ne sont pas "homogènes"


ça manquait en effet de cohérence. J'y suis pas passé depuis quelques 
mois, mais c'est une route normalement interdite uniquement aux 
piétons. J'ai corrigé.



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

Re: [OSM-talk-fr] relation associatedStreet

oui et comme rien n'est simple dans l'extraction FANTOIR on a les deux
versions
Gleyses et Gleyzes : un beau doublon

ok pour le source:name
j'y vais de ce pas

Le 10 novembre 2015 21:17, Tyndare  a écrit :

> Le 10 novembre 2015 20:38, Laurent Combe  a écrit :
> > Niconil
> > c'est moi
>
> Ça simplifie grandement les choses pour résoudre le conflit ;-)
>
> > La bonne nouvelle : j'ai accès au tableau de classement de la voirie de
> la
> > commune.
> > Après vérification c'est effectivement la version avec un 'z'
> > je corrige ...
>
> Vu que sur le cadastre le nom est mal orthographié avec un 's', ça
> aurais était bien je pense de laisser la note ou de la remplacer par
> le plus classique source:name=survey histoire de lever l'incohérence
> avec le tag source actuel et dissuader d'autres
>  tentatives de changement dans le futur.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

2015-11-10 Par sujet Ludovic Hirlimann

Est-il prévu de mettre maxspeed=50 automatiquement dans les zones urbaines ?


-- 
http://sietch-tabr.tumblr.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

2015-11-10 Par sujet osm . sanspourriel

Nous sommes d'accord, je disais juste qu'il fallait le préciser :

> Je suppose qu'il faut répondre "bêtement", à préciser dans l'aide.

 

Jean-Yvon

 
 

Gesendet: Dienstag, 10. November 2015 um 07:31 Uhr
Von: "David Crochet - david.croc...@free.fr" 
An: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] OpenSolarMap... (osm: message 5 of 20)

Bonjour

Le 10/11/2015 00:25, Jérôme Seigneuret a écrit :
> Je ne suis par pour intégrer le contexte environnemental pour le moment
> car c'est juste de la détection de type de toit.

De même, sur le principe que l'on a pas implicitement la compétences
professionnelle pour juger la puissance calorifique reçu par le pan de toit.

Le moyen est de rentrer les paramètre OSM connu des élément autour
(hauteur des arbres, hauteur des bâtiments, hauteurs des murs.

Cordialement

--
David Crochet

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





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

Re: [OSM-talk-fr] relation associatedStreet

Niconil
c'est moi
La bonne nouvelle : j'ai accès au tableau de classement de la voirie de la
commune.
Après vérification c'est effectivement la version avec un 'z'
je corrige ...
Laurent



Le 10 novembre 2015 20:28, Tyndare  a écrit :

> En fait je me suis trompé, en relisant l'historique
> http://www.openstreetmap.org/way/307302039/history
> le contributeur Pinpin avait l'aire de dire que le nom avait était
> vérifié sur le terrain, avec un "z", mais le contributeur Niconil est
> revenu en arrière et a introduit l'incohérence. Il faudrait le
> contacter.
>
>
> Le 10 novembre 2015 20:21, Tyndare  a écrit :
> > Bonjour,
> >
> > Cette incohérence est effectivement une erreur, et est signalée comme
> > telle par le validateur JOSM et par Osmose.
> > Mais à priori le contributeur de la relation associatedStreet était
> > bien conscient de cette incohérence entre le nom du chemin présent
> > dans la base OSM, et le nom associé aux adresses tel qu'importé depuis
> > le cadastre (celui de la relation associatedStreet), c'est pourquoi il
> > à rajouté une note à ce propos sur le chemin: à vérifier sur le
> > terrain.
> > Si tu trouves la bonne orthographe n'hésite pas à corriger celle qui
> > est erronée.
> >
> > A noté qu'en pratique il peut être nécessaire d'avoir une relation
> > associatedStreet avec un nom différent de celui de la rue si la rue en
> > question à plusieurs noms, par exemple un nom différent de chaque côté
> > (cas assez fréquent en limite de commune). La rue peut avoir un
> > name:left, un name:right, un name="name:left - name:right", et en
> > général on créé deux relations associatedStreet, une pour chacun des 2
> > noms.
> >
> > Tyndare.
> >
> >
> > Le 10 novembre 2015 19:09, Laurent Combe  a
> écrit :
> >> bonjour à tous
> >>
> >> depuis quelques semaines je passe une partie de mon temps à dégommer du
> >> rouge sur le rendu BANO
> >> pour l'instant je me concentre sur l'aspect rapprochement des voies.
> >>
> >> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
> >> d'adresse au numero
> >>
> >> et je suis tombé sur ça
> >> http://www.openstreetmap.org/#map=18/43.75258/1.39305
> >>
> >> rien de bien spécial
> >> il s'agit d'un way dénommé "Chemin de Gleyses"
> >>
> >> mais en regardant "un peu par hasard" avec JOSM
> >> je voie que la relation associatedStreet porte son propre tag name
> >> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
> >>
> >> je trouve cela bizarre que la relation porte
> >> un tag name et indirectement au travers d'un de ses membres (le way) un
> >> autre tag name
> >> avec un risque possible d'incohérence comme dans ce cas
> >>
> >> ça me fait penser un  peu à de la double saisie...
> >> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne
> doit
> >> pas tester cela car je n'ai rien vu.
> >>
> >> Laurent
> >>
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tuto pour les ronds points

2015-11-10 Par sujet Vincent de Château-Thierry



Le 10/11/2015 21:03, Ludovic Hirlimann a écrit :

J'aimerais ajouter un ou deux ronds points, avec soit jsom ou
l'intreface web de base. Y a un tuto quelquepart ?


Oui, tu as ça :
http://wiki.openstreetmap.org/wiki/FR:Tag:junction%3Droundabout
et sa version anglaise plus complète, notamment pour indiquer quelle 
valeur de highway choisir :

http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout

vincent

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

Re: [OSM-talk-fr] OpenSolarMap...

2015-11-10 Par sujet osm . sanspourriel

Sur les pavé numériques 8/2=haut/bas=nord/sud, 4/6=gauche/droite=ouest/est.

Et donc je propose 5=toit plat.
Un bouton pour annuler (touche del) la dernière édtion serait sympa.

Et comme dit Pierre, c'est déjà très bien comme ça

Jean-Yvon

Gesendet: Dienstag, 10. November 2015 um 13:58 Uhr
Von: "Pierre Giraud - blueca...@gmail.com"
An: "Discussions sur OSM en français"
Betreff: Re: [OSM-talk-fr] OpenSolarMap... (osm: message 15 of 20)

Salut à tous,

Très chouette application, bravo. J'aime ce genre de petit outil simple et rapide.
Quand j'ai vu ce matin via tweet interposé qu'il y avait des raccourcis clavier, je me suis dit que le choix 1, 2, 3, 4 pouvait poser quelques problèmes, que les erreurs seraient faciles à faire et que le gain d'efficacité ne serait pas si grand que ça.

À mon avis, il serait probablement plus judicieux d'associer davantage la touche au choix à faire (si le but est d'être le plus efficace possible).

Voici une suggestion :

- Flêche haut ou bas pour les toits orientés nord/sud,

- Flêche droite ou gauche pour les toits orientés ouest/est,

- Barre d'espace pour les toits plats,

- Echap ou autre touche neutre pour les orientations non déterminées.

Un avantage à cette méthode est aussi d'utiliser deux mains et donc faire moins d'erreurs.

Mais évidemment, ça n'est pas valable avec les claviers réduits (sans pavé numérique) comme sur les portables.

Ma modeste contribution.

Sinon, c'est déjà très bien comme ça.

Pierre

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

[OSM-talk-fr] Tuto pour les ronds points

2015-11-10 Par sujet Ludovic Hirlimann

J'aimerais ajouter un ou deux ronds points, avec soit jsom ou l'intreface
web de base. Y a un tuto quelquepart ?

Ludo

-- 
http://sietch-tabr.tumblr.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rouen - Pont Mathilde - j'ai un doute sur 3 voies

2015-11-10 Par sujet Plop76


Jérôme Seigneuret a exposé le 09/11/2015 :

Bonjour,

acces=no sur le dernier est très bizarre


C'était en effet bizarre, même s'il y avait motor_vehicule=yes :)


Les ruptures des niveaux highway=primary,secondary,tertiary est
incompréhensible


Le pont est lui-même une route pour automobile donc trunk (quoi que 
dans le sens sud-nord je ne crois pas qu'il y ait le panneau) qui 
permet de rejoindre soit un boulevard secondaire interdit aux poids 
lourds (boulevard de l'europe) qui dessert rouen rive gauche, soit une 
route principale qui permet de traverser tout Rouen par les quais d'est 
en ouest.


Ce sont pas plutôt les nouvelles couleurs du rendu osm.org qui sont 
incompréhensibles :) ? Tous ces dégradés de rouge/orange, j'ai du 
mal...



Le problème s'étant au Sud de Rouen.


C'est à dire ?


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

Re: [OSM-talk-fr] Tuto pour les ronds points

Les astuces qui simplifient la vie avec JOSM c'est de tracer un chemin
entre 2 points pour représenter la diagonale du rond-point et de
cliquer dans le menu Outils/Créer un Cercle (Maj-O), ensuite on peut
utiliser les combinaisons de touches Controle-Shift ou Controle-Alt
pour changer avec la souris l'orientation ou la taille du cercle.
Sinon il y a le préréglage Préréglages/Routes/Routes/Giratoire (pas
besoins de précisé qu'il est a sens unique, c'est toujours le cas par
défaut)
L'important c'est de bien faire les connexions avec les routes arrivant dessus.

Le 10 novembre 2015 21:03, Ludovic Hirlimann  a écrit :
> J'aimerais ajouter un ou deux ronds points, avec soit jsom ou l'intreface
> web de base. Y a un tuto quelquepart ?
>
> Ludo
>
> --
> http://sietch-tabr.tumblr.com/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Parking/Aire de covoiturage

2015-11-10 Par sujet Nicolas Dumoulin

Salut,

Le lundi 9 novembre 2015 20:08:01 Gautier a écrit :
> Nicolas Dumoulin, sur le forum, m'a proposé la solution
> http://www.openstreetmap.org/way/128277712 à savoir :

Je reposte ici mon dernier message où je donne l'origine de mon choix d'époque :
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Carpool[1] 
Aujourd'hui, ça n'est plus très approprié, je suis preneur de mieux :-)

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


[1] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Carpool
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

2015-11-10 Par sujet Nicolas Dumoulin

Bonjour,

Le lundi 9 novembre 2015 11:08:12 lenny a écrit :
> >   * *les zones 30*
> >   
> > maxspeed=30
> > source:maxspeed=FR:zone30
> 
> C'est ce source là dont je ne vois pas l'utilité, car dans les zones 30,
> il aura toujours la même valeur (qu'elle en est la valeur ajoutée ?)

C'est plus évident pour le FR:urban, mais là aussi ça peut avoir son intérêt 
en cas de changement de la legislation par exemple. bien sûr, ça ne remettrait 
pas en cause le maxspeed, puisque explicite sur le panneau "zone 30", mais un 
autre changement pourrait être plus facile. Par ailleurs, une simple limite à 
30 n'implique pas d'aménagement supplémentaire, alors qu'une zone 30 amène le 
gestionnaire à créer des aménagements supplémentaires pour pacifier la 
circulation.
Ça permet donc de distinguer dans la base le type de maxspeed=30. Et puis, de 
toutes façons, on tague le terrain, on verra après à quoi ça sert ;-)

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

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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

2015-11-10 Par sujet Vincent de Château-Thierry

Bonjour,

> De: "Nicolas Moyroud" 
> 
> Personnellement j'ai fait exactement comme ça à plusieurs occasions.
> Je ne suis pas convaincu par la solution landuse. Si la zone est déjà
> couverte par un landuse=residential plus grand, je ne vois pas de
> raison de faire du sur-découpage d'un landuse entouré par d'autres juste
> pour pouvoir ajouter un nom de résidence. Je préfère la relation type=site
> avec un chemin jouant le rôle du perimeter.
> Par contre j'avoue que c'est juste un "goût" personnel et que je n'ai
> pas regardé ce qui est préconisé sur le wiki. :-[

Dans BANO, les surfaces avec landuse=residential + name=* sont considérées [1]
justement pour appréhender les résidences. Mais c'est clairement un choix faute 
de
mieux. Je ne désespère pas qu'on trouve mieux, car à mon avis on est face à un 
faux ami.
On en a pas mal parlé l'année dernière, mon avis n'a pas trop bougé [2].

vincent

[1] : https://github.com/osm-fr/bano/issues/86
[2] : https://lists.openstreetmap.org/pipermail/talk-fr/2014-May/067983.html

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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

2015-11-10 Par sujet Francescu GAROBY

Bonjour,
J'étends un peu la question en rajoutant celle de l'adressage : sur quel
élément placez-vous le tag "addr:housenumber" d'une résidence ?
Récemment, j'ai taggué cette résidence
, et je me suis plus tard rendu
compte que Nominatim est incapable de trouver son adresse (une recherche
sur "36 route d'ifs, Caen" ne trouve pas ladite résidence, mai seulement
les différents tronçons de la rue).
Du coup, j'envisage de déplacer le tag "addr:housenumber" sur le bâtiment
résidentiel proprement dit, et non plus sur le way, ce qui est tout à
faisable ici car il n'y a qu'un seul bâtiment habitable (les 2 autres sont
les garages). Mais dans l'absolu, une telle chose ne serait pas toujours
possible (cas des résidences composées de plusieurs immeubles : pas
question de doublonner le tag "addr:housenumber"!)
Ou alors, on place le tag "addr:housenumber" sur un point représentant
l'entrée dans la résidence ? Ce qui aurait le mérite de fonctionner, mais
dissocierait la résidence (son nom, son emprise, ...) de son adressage, non
?

Francescu


Le 10 novembre 2015 11:21, Jérôme Seigneuret  a
écrit :

> Pareil c'est plus une contrainte qu'une bonne pratique. En cas de
> changement il faut aussi pouvoir prendre en considération les étiquetages
> qui pour le moment sont géré avec place=*
>
> Pour le moment j'ai choisi landuse par défaut (c'est dans la pratique de
> tous les contributeurs) J'avais poussé à utiliser place=neighbourhood passé
> un temps mais:
> - c'est pas l'usage et pour l'étiquetage c'est pourri et pas géré sur les
> polygones. (Je sais on ne tag pas pour la carto mais bon tous est lié.)
> - C'est pas vraiment fait pour ça et il n'y a pas de multi-niveau. Du coup
> une résidence aura le même niveau d'étiquetage qu'un sous-quartier voir
> qu'une zone d'activité si tel est l'usage
>
> Il faut pousser une réflexion sur la gestion des étiquettes
>
> Hors dans une relation type=site, on prend quoi en terme de clés ?
> (étiquette et emprise de la résidence en question)
>
> 2 landuses superposées posent un conflit, d'où mon découpage actuel. C'est
> pas un choix c'est une contrainte. Certains s'en foute royalement mais
> bon...
>
> Les besoins sont les suivant pour migrer vers site:
>
>- Pouvoir avoir un étiquetage cohérent avec le type de landuse comme
>c'est déjà le cas
>   - residential
>   - retail
>   - industrial
>   - ... autres à préciser
>- Pour avoir un étiquetage par level
>   - cas des résidences situé dans des parcs d'activités
>- Pouvoir définir une emprise de la résidence en question sans pour
>autant découper un landuse...
>
> Bonne journée
> Jérôme
>
>
>
> Le 10 novembre 2015 10:56, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Nicolas Moyroud" 
>> >
>> > Personnellement j'ai fait exactement comme ça à plusieurs occasions.
>> > Je ne suis pas convaincu par la solution landuse. Si la zone est déjà
>> > couverte par un landuse=residential plus grand, je ne vois pas de
>> > raison de faire du sur-découpage d'un landuse entouré par d'autres juste
>> > pour pouvoir ajouter un nom de résidence. Je préfère la relation
>> type=site
>> > avec un chemin jouant le rôle du perimeter.
>> > Par contre j'avoue que c'est juste un "goût" personnel et que je n'ai
>> > pas regardé ce qui est préconisé sur le wiki. :-[
>>
>> Dans BANO, les surfaces avec landuse=residential + name=* sont
>> considérées [1]
>> justement pour appréhender les résidences. Mais c'est clairement un choix
>> faute de
>> mieux. Je ne désespère pas qu'on trouve mieux, car à mon avis on est face
>> à un faux ami.
>> On en a pas mal parlé l'année dernière, mon avis n'a pas trop bougé [2].
>>
>> vincent
>>
>> [1] : https://github.com/osm-fr/bano/issues/86
>> [2] :
>> https://lists.openstreetmap.org/pipermail/talk-fr/2014-May/067983.html
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?


Salut,

Personnellement j'ai fait exactement comme ça à plusieurs occasions. Je 
ne suis pas convaincu par la solution landuse. Si la zone est déjà 
couverte par un landuse=residential plus grand, je ne vois pas de raison 
de faire du sur-découpage d'un landuse entouré par d'autres juste pour 
pouvoir ajouter un nom de résidence. Je préfère la relation type=site 
avec un chemin jouant le rôle du perimeter.
Par contre j'avoue que c'est juste un "goût" personnel et que je n'ai 
pas regardé ce qui est préconisé sur le wiki. :-[


Nicolas

-
Nicolas Moyroud
Site web libre@vous : http://libreavous.teledetection.fr
-

Le 09/11/2015 19:39, Julien Noblet a écrit :

Bonjour,
Je viens vers vous pour savoir comment taguer une résidence ou une 
cité de plusieurs bâtiments.

J'avais pensé à une relation de "type"="site"
name=
Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle 
building.
Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = 
Bâtiment A/B/C/D...


Quels tags devraient être ajoutés la relation?

Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un 
addr:place ou addr:X=?


Merci par avance.
Librement.

Julien_N




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

Re: [OSM-talk-fr] OpenSolarMap...


Salut Christian,

J'ai un peu testé et question amélioration intéressante je proposerai la 
possibilité de faire son choix avec des raccourcis claviers. Ça irait 
vachement plus vite que d'avoir à cliquer sur des icônes, aussi gros 
soit-il ! ;-)
Après à voir quelles seraient les meilleures touches à définir : a,z,e,r 
dans l'ordre des icônes ou peut-être 1,2,3,4.


Mes 3 pesos (oui j'étais au Mexique il n'y a pas longtemps),
Nicolas

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

Re: [OSM-talk-fr] OpenSolarMap...

2015-11-10 Par sujet Pierre GRANJON

Bonjour Nicolas,
Les raccourcis clavier dont tu parles existent déjà, il s'agit des touches
1,2,3,4, clavier numérique ou au dessus des lettres. Ils permettent en
effet d'aller plus vite, mais j'ai remarqué que je faisais plus d'erreurs
ainsi, donc je suis revenu au clic sur les icônes.
On est pressés de voir la suite Christian :)

Pierre

Le 10 novembre 2015 11:16, Nicolas Moyroud  a écrit :

> Salut Christian,
>
> J'ai un peu testé et question amélioration intéressante je proposerai la
> possibilité de faire son choix avec des raccourcis claviers. Ça irait
> vachement plus vite que d'avoir à cliquer sur des icônes, aussi gros
> soit-il ! ;-)
> Après à voir quelles seraient les meilleures touches à définir : a,z,e,r
> dans l'ordre des icônes ou peut-être 1,2,3,4.
>
> Mes 3 pesos (oui j'étais au Mexique il n'y a pas longtemps),
> Nicolas
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

Pareil c'est plus une contrainte qu'une bonne pratique. En cas de
changement il faut aussi pouvoir prendre en considération les étiquetages
qui pour le moment sont géré avec place=*

Pour le moment j'ai choisi landuse par défaut (c'est dans la pratique de
tous les contributeurs) J'avais poussé à utiliser place=neighbourhood passé
un temps mais:
- c'est pas l'usage et pour l'étiquetage c'est pourri et pas géré sur les
polygones. (Je sais on ne tag pas pour la carto mais bon tous est lié.)
- C'est pas vraiment fait pour ça et il n'y a pas de multi-niveau. Du coup
une résidence aura le même niveau d'étiquetage qu'un sous-quartier voir
qu'une zone d'activité si tel est l'usage

Il faut pousser une réflexion sur la gestion des étiquettes

Hors dans une relation type=site, on prend quoi en terme de clés ?
(étiquette et emprise de la résidence en question)

2 landuses superposées posent un conflit, d'où mon découpage actuel. C'est
pas un choix c'est une contrainte. Certains s'en foute royalement mais
bon...

Les besoins sont les suivant pour migrer vers site:

   - Pouvoir avoir un étiquetage cohérent avec le type de landuse comme
   c'est déjà le cas
  - residential
  - retail
  - industrial
  - ... autres à préciser
   - Pour avoir un étiquetage par level
  - cas des résidences situé dans des parcs d'activités
   - Pouvoir définir une emprise de la résidence en question sans pour
   autant découper un landuse...

Bonne journée
Jérôme



Le 10 novembre 2015 10:56, Vincent de Château-Thierry  a
écrit :

> Bonjour,
>
> > De: "Nicolas Moyroud" 
> >
> > Personnellement j'ai fait exactement comme ça à plusieurs occasions.
> > Je ne suis pas convaincu par la solution landuse. Si la zone est déjà
> > couverte par un landuse=residential plus grand, je ne vois pas de
> > raison de faire du sur-découpage d'un landuse entouré par d'autres juste
> > pour pouvoir ajouter un nom de résidence. Je préfère la relation
> type=site
> > avec un chemin jouant le rôle du perimeter.
> > Par contre j'avoue que c'est juste un "goût" personnel et que je n'ai
> > pas regardé ce qui est préconisé sur le wiki. :-[
>
> Dans BANO, les surfaces avec landuse=residential + name=* sont considérées
> [1]
> justement pour appréhender les résidences. Mais c'est clairement un choix
> faute de
> mieux. Je ne désespère pas qu'on trouve mieux, car à mon avis on est face
> à un faux ami.
> On en a pas mal parlé l'année dernière, mon avis n'a pas trop bougé [2].
>
> vincent
>
> [1] : https://github.com/osm-fr/bano/issues/86
> [2] :
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-May/067983.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

2015-11-10 Par sujet Pierre Giraud

Salut à tous,

Très chouette application, bravo. J'aime ce genre de petit outil simple et
rapide.
Quand j'ai vu ce matin via tweet interposé qu'il y avait des raccourcis
clavier, je me suis dit que le choix 1, 2, 3, 4 pouvait poser quelques
problèmes, que les erreurs seraient faciles à faire et que le gain
d'efficacité ne serait pas si grand que ça.

À mon avis, il serait probablement plus judicieux d'associer davantage la
touche au choix à faire (si le but est d'être le plus efficace possible).
Voici une suggestion :
 - Flêche haut ou bas pour les toits orientés nord/sud,
 - Flêche droite ou gauche pour les toits orientés ouest/est,
 - Barre d'espace pour les toits plats,
 - Echap ou autre touche neutre pour les orientations non déterminées.
Un avantage à cette méthode est aussi d'utiliser deux mains et donc faire
moins d'erreurs.
Mais évidemment, ça n'est pas valable avec les claviers réduits (sans pavé
numérique) comme sur les portables.

Ma modeste contribution.

Sinon, c'est déjà très bien comme ça.

Pierre


2015-11-10 11:25 GMT+01:00 Pierre GRANJON :

> Bonjour Nicolas,
> Les raccourcis clavier dont tu parles existent déjà, il s'agit des touches
> 1,2,3,4, clavier numérique ou au dessus des lettres. Ils permettent en
> effet d'aller plus vite, mais j'ai remarqué que je faisais plus d'erreurs
> ainsi, donc je suis revenu au clic sur les icônes.
> On est pressés de voir la suite Christian :)
>
> Pierre
>
> Le 10 novembre 2015 11:16, Nicolas Moyroud  a écrit :
>
>> Salut Christian,
>>
>> J'ai un peu testé et question amélioration intéressante je proposerai la
>> possibilité de faire son choix avec des raccourcis claviers. Ça irait
>> vachement plus vite que d'avoir à cliquer sur des icônes, aussi gros
>> soit-il ! ;-)
>> Après à voir quelles seraient les meilleures touches à définir : a,z,e,r
>> dans l'ordre des icônes ou peut-être 1,2,3,4.
>>
>> Mes 3 pesos (oui j'étais au Mexique il n'y a pas longtemps),
>> Nicolas
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Pierre GIRAUD
http://www.camptocamp.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parking/Aire de covoiturage

Bonjour,

J'ai fait une proposition:

amenity=parking (ou parking_space)
park_ride =hov
name=Aire de Covoiturage
access=hov

Je vous invite à voir le contenu du tag hov


Je pense qu'il faudrait aussi compléter la page
http://wiki.openstreetmap.org/wiki/Key:access

Cette clé doit être présente (donc à ajouter) dans la liste "*motor_vehicle
=*** (category: any
motorized vehicle) *--> *By use*

Jérôme

Le 10 novembre 2015 09:20, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Salut,
>
>
>
> Le lundi 9 novembre 2015 20:08:01 Gautier a écrit :
>
> > Nicolas Dumoulin, sur le forum, m'a proposé la solution
>
> > http://www.openstreetmap.org/way/128277712 à savoir :
>
>
>
> Je reposte ici mon dernier message où je donne l'origine de mon choix
> d'époque :
>
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Carpool
>
> Aujourd'hui, ça n'est plus très approprié, je suis preneur de mieux :-)
>
>
>
> --
>
> Nicolas Dumoulin
>
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

Perso j'ajoute les maxspeed=50 + source:maxspeed=FR:urban et les panneau
d'entrée de ville

C'est long et chiant mais une fois fait c'est plus à faire sauf
modification explicite (avec de panneaux supplémentaires ou déplacement par
extension de la zone urbaine et donc le l'entrée de ville pour des
questions de sécurité)

Ça permet aussi de voir qu'à certains endroit comme pour le village et
villes il manque de la signalisation.

Je prend l'exemple d'un village où la signalisation est présente sur les
grands axes mais pas sur les routes d'exploitation, ou les chemins
viticoles. Du coup, il n'existe pas de signalisation entrée-sortie du
village et on ne sait pas si on peut rouler à 90 ou si l'on est toujours à
50 et inversement... C'est plus la logique et la connaissance locale qui
permet de dicter la vitesse limite... Un peu pourri comme solution surtout
au niveau juridique.

En clair pour moi ça permet de faire de la vérification et des alertes et
le tag zone:maxspeed ou les noeuds traffic_sign=* entrent dans ce contexte.

traffic_sign sur la voirie pose un problème  quand il s'agit de vitesse car
le nœud correspond au découpage de la voie. Ce qui empêche de gérer
proprement le tag direction=forward|backward

L'un des moyen serait d'utiliser la direction avec l'angle par rapport au
nord mais là en terme de contributions...
L'autre moyen serait de gérer ça en relation. Mais là c'est pareil pour les
contributions on peut s'accrocher et la pérennité est moins assurée (je me
retrouve assez souvent confronté à des ruptures de relations) si un système
de tag existe pour ne pas avoir de relation, je préfère ajouter des tags.
On peut voir cette problématique sur le rattachement des adresses et de la
voirie (même si j'utilise les relations associatedStreet car c'est l'usage)

Jérôme



Le 10 novembre 2015 09:29, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Bonjour,
>
> Le lundi 9 novembre 2015 11:08:12 lenny a écrit :
> > >   * *les zones 30*
> > >
> > > maxspeed=30
> > > source:maxspeed=FR:zone30
> >
> > C'est ce source là dont je ne vois pas l'utilité, car dans les zones 30,
> > il aura toujours la même valeur (qu'elle en est la valeur ajoutée ?)
>
> C'est plus évident pour le FR:urban, mais là aussi ça peut avoir son
> intérêt
> en cas de changement de la legislation par exemple. bien sûr, ça ne
> remettrait
> pas en cause le maxspeed, puisque explicite sur le panneau "zone 30", mais
> un
> autre changement pourrait être plus facile. Par ailleurs, une simple
> limite à
> 30 n'implique pas d'aménagement supplémentaire, alors qu'une zone 30 amène
> le
> gestionnaire à créer des aménagements supplémentaires pour pacifier la
> circulation.
> Ça permet donc de distinguer dans la base le type de maxspeed=30. Et puis,
> de
> toutes façons, on tague le terrain, on verra après à quoi ça sert ;-)
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

Ah ben chez moi ça marche pas sous Firefox, mon navigateur habituel... 
Je viens de tester Chromium et là ça fonctionne ! Bon il doit y avoir un 
truc qui bloque quelque part.

OK donc je garde mes 3 pesos pour la prochaine fois :-)

Nicolas

Le 10/11/2015 11:25, Pierre GRANJON a écrit :

Bonjour Nicolas,
Les raccourcis clavier dont tu parles existent déjà, il s'agit des 
touches 1,2,3,4, clavier numérique ou au dessus des lettres. Ils 
permettent en effet d'aller plus vite, mais j'ai remarqué que je 
faisais plus d'erreurs ainsi, donc je suis revenu au clic sur les icônes.

On est pressés de voir la suite Christian :)

Pierre




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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

En effet c'est pas la bonne pratique de mettre l'adresse dans landuse.
Landuse en l'état c'est ok juste avec le nom.

J'aime pas mettre l'adresse sur un bâtiment ou sur d'autre type.
Je préfère la mettre au point d'entrée le plus fin possible. Donc sur un
noeud avec entrance=main (C'est un choix mais c'est pas le cas de tous)


L'Adressage le plus complet :
Appartement 1 Entrée A Etage 1, Batiment A, Résidence X,
Numéro 1, Rue B,
Quartier (ou|et Zone),
Lieudit | Ville,Code Postal, (Code Postal et Ville Pouvant être inversé au
niveau découpage géographique),
Département, Région,
Pays

Sachant que les appartement ne sont en principe pas saisie sauf précision
connu dans un bâtiment public par exemple avec une gestion 3D et le schema
indoor

Tu remarqueras aussi l'importance de la virgule pour le géocodage.



addr:door  = numéro de
l'entrée pour l'appartement
addr:flats  = une plage
de numéro d'entrée dans l'aile ou le batiments (1-10) manque la gestion des
adresses d'appartement spéciale genre dans mon bâtiment 210B

addr:unit  = aile dans un
bâtiment avec une entrée principale
addr:entrance = plusieurs entrées sur le bâtiment
addr:floor = étage
addr:housename  =
nom du bâtiment
addr:housenumber  =
numéro de rue
addr:street  = rue

addr:place  = pour toute
les zones territoriale qui ne sont pas de type city donc les zones, les
îles, voisinages  > mais *place *chez nous n'est pas utilisé pour les zones
et les résidences,
cependant il existe des usages de addr:neighbourhood


addr:suburb = quartier quand celui-ci a été renseigné
addr:hamlet = quand c'est un lieudit


Jérôme
...


Le 10 novembre 2015 11:35, Francescu GAROBY  a écrit :

> Bonjour,
> J'étends un peu la question en rajoutant celle de l'adressage : sur quel
> élément placez-vous le tag "addr:housenumber" d'une résidence ?
> Récemment, j'ai taggué cette résidence
> , et je me suis plus tard
> rendu compte que Nominatim est incapable de trouver son adresse (une
> recherche sur "36 route d'ifs, Caen" ne trouve pas ladite résidence, mai
> seulement les différents tronçons de la rue).
> Du coup, j'envisage de déplacer le tag "addr:housenumber" sur le bâtiment
> résidentiel proprement dit, et non plus sur le way, ce qui est tout à
> faisable ici car il n'y a qu'un seul bâtiment habitable (les 2 autres sont
> les garages). Mais dans l'absolu, une telle chose ne serait pas toujours
> possible (cas des résidences composées de plusieurs immeubles : pas
> question de doublonner le tag "addr:housenumber"!)
> Ou alors, on place le tag "addr:housenumber" sur un point représentant
> l'entrée dans la résidence ? Ce qui aurait le mérite de fonctionner, mais
> dissocierait la résidence (son nom, son emprise, ...) de son adressage, non
> ?
>
> Francescu
>
>
> Le 10 novembre 2015 11:21, Jérôme Seigneuret  a
> écrit :
>
>> Pareil c'est plus une contrainte qu'une bonne pratique. En cas de
>> changement il faut aussi pouvoir prendre en considération les étiquetages
>> qui pour le moment sont géré avec place=*
>>
>> Pour le moment j'ai choisi landuse par défaut (c'est dans la pratique de
>> tous les contributeurs) J'avais poussé à utiliser place=neighbourhood passé
>> un temps mais:
>> - c'est pas l'usage et pour l'étiquetage c'est pourri et pas géré sur les
>> polygones. (Je sais on ne tag pas pour la carto mais bon tous est lié.)
>> - C'est pas vraiment fait pour ça et il n'y a pas de multi-niveau. Du
>> coup une résidence aura le même niveau d'étiquetage qu'un sous-quartier
>> voir qu'une zone d'activité si tel est l'usage
>>
>> Il faut pousser une réflexion sur la gestion des étiquettes
>>
>> Hors dans une relation type=site, on prend quoi en terme de clés ?
>> (étiquette et emprise de la résidence en question)
>>
>> 2 landuses superposées posent un conflit, d'où mon découpage actuel.
>> C'est pas un choix c'est une contrainte. Certains s'en foute royalement
>> mais bon...
>>
>> Les besoins sont les suivant pour migrer vers site:
>>
>>- Pouvoir avoir un étiquetage cohérent avec le type de landuse comme
>>c'est déjà le cas
>>   - residential
>>   - retail
>>   - industrial
>>   - ... autres à préciser
>>- Pour avoir un étiquetage par level
>>   - cas des résidences situé dans des parcs d'activités
>>- Pouvoir définir une emprise de la résidence en question sans pour
>>autant découper un landuse...
>>
>> Bonne journée
>> Jérôme
>>
>>
>>
>> Le 10 novembre 2015 10:56, Vincent de Château-Thierry 
>> a écrit :

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?





J'aime pas mettre l'adresse sur un bâtiment ou sur d'autre type.
Je préfère la mettre au point d'entrée le plus fin possible. Donc sur 
un noeud avec entrance=main (C'est un choix mais c'est pas le cas de tous)


J'ai choisi aussi de faire comme ça, mais je ne mettais pas mis le 
entrance=main, juste parce que je n'y avais jamais pensé...


Nicolas

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

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

Il y a des limites de 50 km/h hors des zones urbaines aussi, par exemple
aux sorties d'autoroutes près des zones de péages, qui peuvent être en
pleine campagne, hors de toute agglomération, ou sur certains ouvrages
(ponts, tunnels, virages dangereux, routes étroites, bretelles
d'échangeurs, routes dégradées, passages à gué qui peut être inondé et
infranchissable épisodiquement, ou traversée de certains espaces naturels
avec animaux sauvages, voies privées...). On peut même avoir moins encore
(autour des centres commerciaux)...


Le 10 novembre 2015 20:58, Ludovic Hirlimann  a
écrit :

> Est-il prévu de mettre maxspeed=50 automatiquement dans les zones urbaines
> ?
>
>
> --
> http://sietch-tabr.tumblr.com/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

2015-11-10 Par sujet Christian Quest

Les améliorations du soir:

- la page ne se recharge plus pour chaque bâtiment, et l'enchainement se
fait vers le bâtiment suivant le plus proche
On gagne en rapidité d'affichage, la carte ne fait que "glisser" au
bâtiment suivant.

- ajout d'un pointillé sur l'emprise du polygone de bâti à renseigner et
redimensionnement du cercle

Vous pouvez voir tout le détail sur github:
https://github.com/opensolarmap/solfront/commits/master


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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

On fait bel et bien du découpage de pour nommer les plages (beach); certe
ce n'est pas du landuse, mais du natural, mais le problème est identique.
Même chose pour nommer les forêts qui sont souvent accolées .

Techiquement, redécouper un landuse n'est pas différent de la pratique de
redécouper un highway pour distinguer les lanes ou les limites de vitesse
ou autres restrictions d'accès ou de circulation, ou des itinéraires de
bus, même si tous les segments ont le même nom de voie: Mais quand on veut
pouvoir retrouver facilement une voie dans son entier on crée une relation
pour regouper les segments et y mettre les tags communs
(type=associatedStreet), une autre pour rassembler les segments format un
itinéraire (type=route), et il n'est pas nécessaire de garer sur les
segments découpés les tags communs qui sont dans la relation qui les
rassemble.

Sinon concernant spécifiquyement les landuse, il y a très peu d'intérêt à
rassembler tous les morceaux jointifs, le découpage dupliquera quelques
tags mais les landuse sont difficiles à regrouper dans des relations sans
créer des doublons de relations difficilement distingables. Pour les
landuse géant, il est même intéressant de les redécouper sur les limites
administratives de commune plutôt que sur des traits de découpe
arbitraires, cela donne des polygones plus petits, plus facilement gérables
et si une toponymie leur est appliquée, c'est plus simple et plus conforme
de ne l'appliquer que dans les limites administratives (selon les communes,
un même landuse aura des classifications et noms différents).

Même remarque sur le découpage des surfaces de cours d'eau (alias
"riverbank" bien que le terme riverbank était mal choisi en signifiant
normalement autre chose: juste les berges  partiellement couvertes ou qui
peuvent se découvrir et non le cours central quasi-permanent, hors dans OSM
on ne cartographie pas actuellement les berges autrement que par un
linéaire et non par leur surface réelle, on a abusé de ça pour dire que les
zones incluses entre ces berges linéraires était la surface du cours d'eau,
pour laquelle on préfère maintenant le tag water=* plutôt que
waterway=riverbank qui ne sert plus que pour les relations groupant les
segments linéaires de cours central et éventuellement collecter les
polygones de surfaces d'eau).


Le 10 novembre 2015 10:24, Nicolas Moyroud  a écrit :

> Salut,
>
> Personnellement j'ai fait exactement comme ça à plusieurs occasions. Je ne
> suis pas convaincu par la solution landuse. Si la zone est déjà couverte
> par un landuse=residential plus grand, je ne vois pas de raison de faire du
> sur-découpage d'un landuse entouré par d'autres juste pour pouvoir ajouter
> un nom de résidence. Je préfère la relation type=site avec un chemin jouant
> le rôle du perimeter.
> Par contre j'avoue que c'est juste un "goût" personnel et que je n'ai pas
> regardé ce qui est préconisé sur le wiki. :-[
>
> Nicolas
>
> -
> Nicolas Moyroud
> Site web libre@vous : http://libreavous.teledetection.fr
> -
>
>
> Le 09/11/2015 19:39, Julien Noblet a écrit :
>
>> Bonjour,
>> Je viens vers vous pour savoir comment taguer une résidence ou une cité
>> de plusieurs bâtiments.
>> J'avais pensé à une relation de "type"="site"
>> name=
>> Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
>> building.
>> Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
>> A/B/C/D...
>>
>> Quels tags devraient être ajoutés la relation?
>>
>> Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
>> addr:place ou addr:X=?
>>
>> Merci par avance.
>> Librement.
>>
>> Julien_N
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

Le 10 novembre 2015 11:46, Jérôme Seigneuret  a
écrit :

> traffic_sign sur la voirie pose un problème  quand il s'agit de vitesse
> car le nœud correspond au découpage de la voie. Ce qui empêche de gérer
> proprement le tag direction=forward|backward
>
C'est vrai seulement si tu utilise le noeud de découpage pour ça, mais ça
ne l'est plus si tu tague plutôt le segment/chemin dont la direction est
explicite et distingue clairemetn la direction sans avoir besoin de
préciser une direction par un angle au nord, pas facile à estimer ou
maintenir et vérifier (les angles approchants sont souvent erronés et pas
maintenus correctement que le dessin d'une route est affiné ou modifié
localement, même avec une précision limitée aux 8 principaux octants
géographiques ou pire avec les 4 points cardinaux).

Bref autant que possible taguer le chemin, les noeuds de découpage n'ont
besoin de rien hormi pour indiquer la position d'un panneau d'entrée
d'agglomération, lequel devrait indiquer une limite de vitesse qu'il vaut
mieux taguer explicitement sur les chemins du bon côté du panneau et dans
la direction souhaitée. De fait ces panneaux d'entrée n'ont même pas besoin
d'être placé sur le chemin lui même mais plutôt sur le bon côté de la voie,
et ne désigne que le panneau lui-même là où il est réellement observable
(sinon on pourra croire que le panneau est observable d'assez loin où on
voit le centre de la route mais pas le bas-côté où il est réellement posé.

Un panneau d'entrée d'agglomération ne devrait être posé sur le chemin QUE
s'il est placé au dessus de la voie (panneau suspendu ou sous le tablier
d'un pont), pas sur le côté... L'angle mentionné pour le noeud où est posé
le panneau devrait correspondre à son orientation réelle et non celle de la
route (souvent il y a un angle non perpendiculaire à la chaussée, de
l'ordre de 15-20 degrés). le seul moyen d'éviter de préciser cet angle
d'orientation du panneau pour sa viosibilité serait de les tracer non pas
comme des noeuds mais comme de petits segments orientés en adoptant une
convention que le panneau est lisible à droite du segment (dans sa
direction de tracé), mais là encore les risques d'erreur d'orientation de
se segment sont élevés et pourraient conduire à rendre le panneau visible
dans la direction opposée non orientée vers la route !

L'autre solution serait de tracer des polygones englobant toutes les routes
(mais aussi le bati et les voies privées où ces limties ne s'appliquent
pourtant pas, mais cela donnerait un enchevêtrement de polygones
complexifiant la lisibilité des cartes lors de l'édition. En pratique on ne
le fait QUE pour les aires piétonnes, mais pas pour les limites
d'agglomération qui incluent de nombreuses exceptions selon les voies.

On n'a pas de solution idéale pour taguer les vitesses avec la position ou
l'orientation des panneaux, et finalement la solution la plus simple est de
taguer les vitesses sur les chemins (ou éventuellement sur les collections
de chemins formant une relation (on pourait le faire pour les relations
associatedStreet, si la vitesse est limitée de façon uniforme sur toute la
rue, mais il y a tellement d'exception maintenant en ville avec divers
ralentisseurs locaux que c'est finalement sur le plus chemin qu'il est plus
simple de s'y retrouver de façon cohérente).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

En ce qui me concerne j'ai testé le 1,2,3,4 et je trouve ça pratique. Je 
n'ai pas l'impression d'avoir fait plus d'erreurs, mais en tout cas ça 
va beaucoup plus vite !


Nicolas

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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?