[OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Violaine_Do]

Bonjour tout le monde,

Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM (sur 
osm.org) en fonction de conditions locales (cf profil voiture utilisé 
sur OSM.org 1)


Pour le moment primary, secondary et tertiary ne montent par défaut pas 
a plus de 65km/h, les exceptions rurales sont souvent au dessus.. (cf 
wiki speed limits : 2, par exemple pour les routes rurales en france on 
a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc avec maxspeed 
on dépasse la vitesse par défaut du type de route tertiary, secondary, 
primary. Mais pour avoir fait un petit test, je comprends pas le calcul, 
par exemple avec un tronçon en particulier (3) : je ne trouve pas la 
vitesse attendue (j'aimerais que le calcul prenne en compte la vitesse 
rurale c'est à dire 80km/h plutôt que la vitesse du type de route 
secondary qui est à 55km/h, information qui est présente sur ce 
tronçon). Est-ce que c'est parce que primary/secondary/tertiary sont 
prioritaires/contraignent le reste? (en gros faudrait il changer les 
vitesses par defaut primary/secondary/tertiary pour permettre 
l'utilisation des maxspeed?). J'espère que je suis assez compréhensible...


Bonne soirée/journée,

Violaine

1: 
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua 



2:https://wiki.openstreetmap.org/wiki/Speed_limits

3: 
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=49.6435%2C3.3967%3B49.6206%2C3.4528#map=14/49.6343/3.4309 



--
Violaine_Do


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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

au top! Merci marc

Le jeu. 14 mars 2019 à 23:21, marc marc  a
écrit :

> Le 14.03.19 à 23:13, Jérôme Seigneuret a écrit :
>
> > définir des adresses dans un aéroport ou un aérodrome?
>
> si l'adresse n'as pas de nom de rue,
> c'est addr:place qu'il convient d'utiliser
> https://wiki.openstreetmap.org/wiki/Key:addr
>
> > J'ai des adresses mais ça match pas avec nomminatim et ça remonte pas
> > correctement dans BANO.
> >
> https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972
>
> un no sans rue/lieu ne peux à mon avis pas matcher.
> nominatime gère addr:palce
> aucune idée pour bano
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[marc marc]

Le 14.03.19 à 23:13, Jérôme Seigneuret a écrit :

> définir des adresses dans un aéroport ou un aérodrome?

si l'adresse n'as pas de nom de rue,
c'est addr:place qu'il convient d'utiliser
https://wiki.openstreetmap.org/wiki/Key:addr

> J'ai des adresses mais ça match pas avec nomminatim et ça remonte pas 
> correctement dans BANO.
> https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972

un no sans rue/lieu ne peux à mon avis pas matcher.
nominatime gère addr:palce
aucune idée pour bano
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

Bonjour,

Quelle est la règle pour définir des adresses dans un aéroport ou un
aérodrome?

J'ai des adresses mais ça match pas avec nomminatim et ça remonte pas
correctement dans BANO.

exemple
https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972
https://c.layers.openstreetmap.fr/bano/20/530455/361219.png


Merci
Bonne soirée
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[Florimond Berthoux]

Non, je ne dis pas ça.
Au risque de me répéter : il y a des gens qui habitent porte de la
Chapelle, des gens qui habitent à l'est des rails, et des gens qui habitent
au nord de la rue d'Oran, et ces gens n'habitent pas le quartier usuel de
la Goutte d'Or.

«Les 80 quartiers administratifs constituent le niveau le plus fin de
l'administration publique à Paris. Chacun contient un poste de police.
Chaque arrondissement parisien compte quatre quartiers administratifs.

Ces 80 quartiers (historiques et encore utilisés au sein de la préfecture
de Paris, et de populations très différentes) sont distincts à la fois des
121 conseils de quartier de Paris (plus équilibrés en termes de population)
et des 18 circonscriptions législatives pour l’élection des députés à
l’Assemblée nationale. »

Il n'est pas dit que le poste de Police soit l'admin_centre du quartier, il
y a une différence entre contenir quelque chose et que ce quelque chose
gère le contenant.
De plus il est écrit qu'il existe deux notions de quartier d'un point de
vue de l'administration de la commune et de la préfecture les "quartiers
administratifs" et les quartiers des "conseils de quartier".
Je vous laisse rajouter les quartiers des conseils de quartier de Paris. :]


Le jeu. 14 mars 2019 à 22:02,  a écrit :

> Tu nous dis que les gens ne considèrent pas les rails comme étant du
> quartier, difficile de prendre un exemple moins convaincant.
>
> Selon
> https://fr.wikipedia.org/wiki/Liste_des_quartiers_administratifs_de_Paris,
> un quartier administratif c'est juste la zone d'activité d'une poste de
> police donc l'admin_centre de ce machin c'est le poste de police
>  ^^.
>
> Il n'est pas loin du nœud "La Goutte d'Or".
>
> Peut-être que vos quartiers ont d'autres raisons d'être mais je n'ai pas
> trouvé.
> Le 14/03/2019 à 21:45, Florimond Berthoux - florimond.berth...@gmail.com
> a écrit :
>
>
> Voici en orange le périmètre du quartier administratif nommé la Goutte
> d'Or,
> en bleu le quartier usuel (limite floue) :
> https://imgur.com/WxrNrtw
>
>
> Le jeu. 14 mars 2019 à 15:53, Romain MEHUT  a
> écrit :
>
>> althio wrote
>> > et la modélisation possible est :
>> >
>> > 1. un truc compliqué et administratif
>> > Relation: type=boundary + boundary=administrative + admin_level=10 +
>> > name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
>> > définir la géométrie
>> > (pas de membre admin_center)
>> > (optionnel un membre label)
>> >
>> > 2. un truc simple et humain
>> > Point: place=suburb|* + name=*
>> > (pas d'admin_level, pas de ref:INSEE, pas de relation)
>>
>> En représentation cela donne ceci aujourd'hui
>> https://overpass-turbo.eu/s/GZD
>>
>> Partant de ce constat, et toujours dans l'optique de comprendre, en
>> prenant
>> à nouveau pour exemple le quartier de la Goute d'Or, quel est l'intérêt
>> d'avoir à la fois une relation et un noeud pour définir ce que
>> j'interprète
>> comme étant la même chose ? La page wikipédia
>> https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
>> plus.
>>
>> D'autres avis que ceux déjà exprimés seraient bienvenus !
>>
>> Romain
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

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

[marc marc]

Le 14.03.19 à 21:57, Florimond Berthoux a écrit :
> 'il y a une différence de clé pour définir le sens de circulations des 
> voies entre les voies vélos par cycleway:*:oneway et les voies générales 
> ou est plutôt utilisé lanes:forward|backward.

cela représente 2 choses différentes :
l'un (oneway) s'il y a ou pas une interdiction sens unique ou pas
l'autre (lanes) décrit le nombre de bande.. on peux imaginer qu'une rue 
large ai des bandes forward et backward des 2 côtés même si en l'état, 
cela n'intéresse peu être pas encore grand mondede renseigner ce niveau 
de détail, l'important étant d'abord de savoir si c'est permis de rouler
et l'infra concernée
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[osm . sanspourriel]

Tu nous dis que les gens ne considèrent pas les rails comme étant du 
quartier, difficile de prendre un exemple moins convaincant.


Selon 
https://fr.wikipedia.org/wiki/Liste_des_quartiers_administratifs_de_Paris, 
un quartier administratif c'est juste la zone d'activité d'une poste de 
police donc l'admin_centre de ce machin c'est le poste de police 
 ^^.


Il n'est pas loin du nœud "La Goutte d'Or".

Peut-être que vos quartiers ont d'autres raisons d'être mais je n'ai pas 
trouvé.


Le 14/03/2019 à 21:45, Florimond Berthoux - florimond.berth...@gmail.com 
a écrit :


Voici en orange le périmètre du quartier administratif nommé la Goutte 
d'Or,

en bleu le quartier usuel (limite floue) :
https://imgur.com/WxrNrtw


Le jeu. 14 mars 2019 à 15:53, Romain MEHUT > a écrit :


althio wrote
> et la modélisation possible est :
>
> 1. un truc compliqué et administratif
> Relation: type=boundary + boundary=administrative + admin_level=10 +
> name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
> définir la géométrie
> (pas de membre admin_center)
> (optionnel un membre label)
>
> 2. un truc simple et humain
> Point: place=suburb|* + name=*
> (pas d'admin_level, pas de ref:INSEE, pas de relation)

En représentation cela donne ceci aujourd'hui
https://overpass-turbo.eu/s/GZD

Partant de ce constat, et toujours dans l'optique de comprendre,
en prenant
à nouveau pour exemple le quartier de la Goute d'Or, quel est
l'intérêt
d'avoir à la fois une relation et un noeud pour définir ce que
j'interprète
comme étant la même chose ? La page wikipédia
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne
m'aide pas
plus.

D'autres avis que ceux déjà exprimés seraient bienvenus !

Romain




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

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



--
Florimond Berthoux

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

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

[Florimond Berthoux]

En tant que contributeur je préfère cycleway:*=opposite_* que de devoir
taper deux tags.
En tant que structuraliste opposite_* est intolérable.
En tant que consommateur de donnée OSM je n'ai pas assez d'expérience.

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

Je remarque d'ailleurs qu'il y a une différence de clé pour définir le sens
de circulations des voies entre les voies vélos par cycleway:*:oneway et
les voies générales ou est plutôt utilisé lanes:forward|backward.

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

> Dans l'absolu sa proposition tient la route. C'est juste que c'est un peu
> lourd et que dans la pratique le opposite_lane est bien utilisé et
> parfaitement interprétable.
>
> Et comme le dis marc c'est pas la bonne pratique, même quand on est
> convaincu qu'on a raison... parce qu'on est nombreux à être convaincu
> d'avoir raison :D
>
> J'avais vu ta position sur la distinction entre le sens et l'infra et
> effectivement vous tombé plutôt d'accord. J'avais la même position il y a
> quelques années... et puis j'ai laissé tombé :) et en fait j'ai admis que
> la clé cycleway c'est qu'une clé et du moment qu'on est d'accord sur ce que
> signifient les tags qui l'utilisent et bien on peut renoncer un peu à cette
> logique. Donc vois si tu veux rester sur cette position mais dis toi que si
> elle n'est pas adoptée ça n'aura pas trop d'influence... on en reparle
> peut-être de vive voix bientôt ? ;)
>
> Pour l'instant j'essaie de prendre un peu le pouls sur cette approche du
> DSC puisque les calculateurs ne l'utilisent pas je pense alors que les
> cycleway:left/right=opposite_* sont plutôt admis (il me semble qu'au moins
> BRouter et Geovelo les prennent en compte mais je pense que d'autres le
> font).
> On 13/03/2019 21:14, Florimond Berthoux wrote:
>
> Bonsoir,
>
> Et par ici aussi
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Acycleway%3Dopposite_lane=revision=1820887=1639352
> mais pas ici
> https://wiki.openstreetmap.org/wiki/Key:cycleway#Dedicated_cycle_lanes
> Je trouve la communauté particulièrement coulante vis-à-vis de ce genre de
> modification unipersonnelle.
>
> Après je comprend tout à fait son point de vue : la signification d'un tag
> devrait être la plus simple possible et ne pas comporter deux
> significations comme avec opposite_lane (sens et infrastructure).
>
>
> Le mer. 13 mars 2019 à 15:04, Charles MILLET  a
> écrit :
>
>> Bonjour à tous
>>
>> Un contributeur a mis à jour la page wiki concernant la manière de
>> décrire les doubles sens cyclables sur bande :
>>
>>
>> https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997
>>
>> Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car
>> cette valeur n'est pas documentée dans les valeurs des clé
>> cycleway:left/richt (même si elle l'est pour la clé cycleway)
>>
>> Il recommande donc :
>>
>> highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1
>>
>> plutôt que
>>
>> highway=* + oneway=yes + cycleway:left=opposite_lane
>>
>> :'(
>>
>> Je lui ai envoyé un message pour lui exprimé avec politesse que je pense
>> qu'il vaudrait mieux admettre ou officialiser
>> cycleway:left=opposite_lane mais je m'attend que ce type de contribution
>> traduise une volonté de respecter rigoureusement le wiki...
>>
>> Je m'adresse à la liste pour avoir votre avis au regard de l'usage qu'on
>> peut observer sur taginfo et quelle serait la démarche pour revoir cette
>> modification et dans l'idéal valider dans les règles les tags
>> cycleway:left/right=opposite_lane
>>
>> Bonne journée
>>
>> Charles
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Quartiers à Paris

[Florimond Berthoux]

Voici en orange le périmètre du quartier administratif nommé la Goutte d'Or,
en bleu le quartier usuel (limite floue) :
https://imgur.com/WxrNrtw


Le jeu. 14 mars 2019 à 15:53, Romain MEHUT  a
écrit :

> althio wrote
> > et la modélisation possible est :
> >
> > 1. un truc compliqué et administratif
> > Relation: type=boundary + boundary=administrative + admin_level=10 +
> > name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
> > définir la géométrie
> > (pas de membre admin_center)
> > (optionnel un membre label)
> >
> > 2. un truc simple et humain
> > Point: place=suburb|* + name=*
> > (pas d'admin_level, pas de ref:INSEE, pas de relation)
>
> En représentation cela donne ceci aujourd'hui
> https://overpass-turbo.eu/s/GZD
>
> Partant de ce constat, et toujours dans l'optique de comprendre, en prenant
> à nouveau pour exemple le quartier de la Goute d'Or, quel est l'intérêt
> d'avoir à la fois une relation et un noeud pour définir ce que j'interprète
> comme étant la même chose ? La page wikipédia
> https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
> plus.
>
> D'autres avis que ceux déjà exprimés seraient bienvenus !
>
> Romain
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

[OSM-talk-fr] GogoCarto

[Cédric Frayssinet]

Bonsoir à tous,

Le projet ne semble pas être passé par cette liste. Voici GogoCarto, un
chouette projet, très joli, un peu à la uMap, qui permet de faire de
jolies cartes : https://gogocarto.fr/projects

Il a été développé pour la carte 'Près de chez nous'.

Le code source est ici : https://gitlab.adullact.net/pixelhumain/GoGoCarto

Et les vidéos tutos ici :
https://video.colibris-outilslibres.org/video-channels/gogocarto_channel/videos

Cédric


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] Quartiers à Paris

[marc marc]

Le 14.03.19 à 17:45, Jean-Marc Liotier a écrit :
> le rôle est "label" permet de positionner arbitrairement

position arbitraire pour forcer un résultat particulier d'un rendu
c'est pour cette raison que osmcarto est ses dérivés ne l'utilisent pas.
osmcarto par ex place le label au milieu de l'aire.
libre à chaque style de choisir sa règle (par ex utiliser admin_center)
donc en pratique le rôle label est surtout source de confusion inutile.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[Jean-Marc Liotier]

On Thu, March 14, 2019 3:52 pm, Romain MEHUT wrote:
> althio wrote
>
>> 1. un truc compliqué et administratif
>> Relation: type=boundary [..]
>>
>> 2. un truc simple et humain
>> Point: place=suburb|* + name=* [..]
>
> quel est l'intérêt d'avoir à la fois une relation
> et un noeud pour définir ce que j'interprète
> comme étant la même chose ?

Aucune idée concernant la Goutte d'Or, mais je regardais aujourd'hui la
relation Sénégal (https://www.openstreetmap.org/relation/192775) et elle
comporte le noeud https://www.openstreetmap.org/node/432425075 dont dont
j'ai appris de
https://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members que
le rôle est "label" permet de positionner arbitrairement la légende d'une
surface biscornue (le Sénégal étant concave avec la Gambie incrustée en
plein milieu)... Donc il existe des cas où tel nœud est légitime, même si
c'est entièrement pour le rendu.

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

Re: [OSM-talk-fr] Quartiers à Paris

[Romain MEHUT]

althio wrote
> et la modélisation possible est :
> 
> 1. un truc compliqué et administratif
> Relation: type=boundary + boundary=administrative + admin_level=10 +
> name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
> définir la géométrie
> (pas de membre admin_center)
> (optionnel un membre label)
> 
> 2. un truc simple et humain
> Point: place=suburb|* + name=*
> (pas d'admin_level, pas de ref:INSEE, pas de relation)

En représentation cela donne ceci aujourd'hui
https://overpass-turbo.eu/s/GZD

Partant de ce constat, et toujours dans l'optique de comprendre, en prenant
à nouveau pour exemple le quartier de la Goute d'Or, quel est l'intérêt
d'avoir à la fois une relation et un noeud pour définir ce que j'interprète
comme étant la même chose ? La page wikipédia
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
plus.

D'autres avis que ceux déjà exprimés seraient bienvenus !

Romain




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

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

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

[Antoine Riche via Talk-fr]

J'ai ajouté un sujet sur sa page de discussion : 
https://wiki.openstreetmap.org/wiki/User_talk:Cmuelle8#Changes_to_bicycle_pages


La seule chose qui m'intéresse à ce stade est de savoir si cette 
modification a été débattue et agréée avec la communauté.


Antoine.

Le 13/03/2019 à 22:11, Charles MILLET a écrit :


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


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


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


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


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

Bonsoir,

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


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



Le mer. 13 mars 2019 à 15:04, Charles MILLET > a écrit :


Bonjour à tous

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


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

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

Il recommande donc :

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

plutôt que

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

:'(

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

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

Bonne journée

Charles


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



--
Florimond Berthoux

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


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

[OSM-talk-fr] name et Nominatim

[osm . sanspourriel]

Le 14/03/2019 à 11:27, althio - althio.fo...@gmail.com a écrit :


1. un truc compliqué et administratif
Relation: type=boundary + boundary=administrative + admin_level=10 +
name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
définir la géométrie
(pas de membre admin_center)
(optionnel un membre label)

Pourquoi ajouter "Quartier de" ? suburb ou neighbourhood l'indique.
On ne met pas "Pays de France" ou "Ville de Paris". Si le nom du 
quartier comporter Quartier, OK. Mais sauf erreur on peut parler de 
Bellevue et on comprend qu'il s'agit du quartier de Bellevue.


Par contre je mettrais "Arrondissement de " pour les arrondissement de 
département. Voir ci-dessous.


Le 14/03/2019 à 12:09, althio - althio.fo...@gmail.com a écrit :

Marc, Léo et quelques autres :

en résumé : je suis pour l'ajout s'il a un consensus permettant d'en  définir 
l'étendue. ajouter une info qui provoque des réponses parfois  fausse 
impossible à corriger, c'est pire que ne pas avoir l'info.

Je trouve que tu décris un problème de consommateur de données
(Nominatim) qui fait des approximations ou des hypothèses
pragmatiques, mais pas toujours correctes, ou une présentation mal
adapté de ces résultats.


+1, en théorie Nominatim utilise les places les plus proches. En 
pratique j'ai vu des erreurs, c'est un problème Nominatim pas de 
représentation.


Ce qui me gène le plus souvent, mais pas pour Paris c'est le nom de la 
(sous-préfecture) qui sert à la recherche et au géocodage inverse : on 
cherche quelque chose dans le chef-lieu de département ou la 
sous-préfecture et on se retrouve avec des résultats de tout 
l'arrondissement et non seulement de la ville.


Ce n'est pas pour moi un problème de Nominatim mais de modélisation : 
comme en Allemagne où ils ajoutent Landkreis on devrait à mon avis 
ajouter "Arrondissement de " : si on dit Brest, on parle de la ville pas 
de l'arrondissement de Brest.


Votre avis ?

Jean-Yvon

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

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Jacques Lavignotte]

Le 14/03/2019 à 12:24, Stéphane Péneau a écrit :

Le 14/03/2019 à 12:08, Jacques Lavignotte a écrit :



;)


:-)

J'aurais choisi unclassified


Le commentaire dans JOSM :

« Passé de « unclassied » à « tertiary » et maintenant le contraire. »


Stf


J.

ps : cette petit route/rue est très fréquentée comme contournement à 
quelques bouchons à l'heure de sortie des CHU et CH Laborit.



--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Stéphane Péneau]

Le 14/03/2019 à 12:08, Jacques Lavignotte a écrit :



Le 14/03/2019 à 11:18, Stéphane Péneau a écrit :

Hmm non, pas vraiment, cette route n'est pas là pour relier deux 
villes. C'est plutôt l'avenue Jacques Coeur qui est là pour ça.


Et donc ?

J.

;)


:-)

J'aurais choisi unclassified


Stf



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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)]

Le ticket a déjà été créé
https://josm.openstreetmap.de/ticket/17460 

wait  & see 

-Message d'origine-
De : FR via Talk-fr [mailto:talk-fr@openstreetmap.org] 
Envoyé : jeudi 14 mars 2019 11:25
À : talk-fr@openstreetmap.org
Cc : FR 
Objet : Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

Merci 1000 fois:

Pour les utilisatrices et utilisateurs d'Ubuntu ça donne:
/usr/bin/java -Djsse.enableSNIExtension=false -jar /home/.../josm-tested.jar 
(... = chemin où est rangé JOSM)

Mais comme savoir bidouiller des lignes de commande n'est pas un pré-requis 
pour contribuer à OSM serait-il possible de faire quelque chose pour résoudre 
le problème à la source ? ;-)

Françoise


Le 13/03/2019 à 08:36, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE 
PPE) a écrit :
> Hello,
> 
> Oui j’ai résolu (après avoir cherché sur le Net) par un paramètre 
> supplémentaire dans le lancement de JOSM :
> 
> -Djsse.enableSNIExtension=false
> 
> Par exemple : D:\JAVA1.8\bin\java  -Djsse.enableSNIExtension=false 
> -Djosm.home="D:\JOSM" -Xmx4096M -jar josm-tested.jar
> 
> En revanche, il faut pas me demander pourquoi ni comment. Je crois 
> encore à la magie  En tout cas, ça refonctionne.
> 
> Denis
> 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

> Le 13 mars 2019, Florimond Berthoux a écrit :
>
> > Vaut mieux un centre imprécis, que pas d'infos du tout.
> > De toutes manières calculer un centre précis est absurde, voire impossible.
> > Nous ne faisons pas des cartes que pour les ordinateurs.

+1

Et encore, je dirais que, à l'échelle où ces infos sont intéressantes
(repérage de quartiers ou de lieu-dits dans une région plus vaste,
urbaine ou rurale), la modélisation par un repère ponctuel est la
meilleure solution.

Marc, Léo et quelques autres :
> en résumé : je suis pour l'ajout s'il a un consensus permettant d'en  définir 
> l'étendue. ajouter une info qui provoque des réponses parfois  fausse 
> impossible à corriger, c'est pire que ne pas avoir l'info.

Je trouve que tu décris un problème de consommateur de données
(Nominatim) qui fait des approximations ou des hypothèses
pragmatiques, mais pas toujours correctes, ou une présentation mal
adapté de ces résultats.
Je ne vois pas pourquoi on ne devrait pas garder ces points. On peut
les passer à des polygones SI c'est possible, d'accord. Les garder en
points, sinon. Les supprimer, pas d'accord.

> Le problème pour les quartiers c'est que les tags sont sur un node donc 
> impossible de savoir la taille de quartier, il n'y a pas moyen de le déduire 
> de quoi que ce soit pour le rendu.

Il y a tout de même une gradation dans les niveaux de place=* pour
l'importance des quartiers.
Et puis la taille d'un quartier dense ou d'un quartier étendu, ça ne
va pas tout régler non plus.

> Je pense qu'on devrait ignorer "l'avis des gens".

Argh ! On est dans OpenStreetMap, c'est un projet par les gens, pour les gens.

> Même si ce n'est pas OpenAdministrationMap, il y a une certaine "rigueur" de 
> terrain à conserver. Hors, comme il est impossible de délimiter précisément 
> un "quartier usuel", le point qu'on plaçerait pour l'identifier ne serait 
> qu'une information approximative et donc peu fiable.

Vouloir un polygone quand il n'y pas de définition administrative (cas
de tous les quartiers "informels" et les lieu-dits), on est d'accord,
c'est inadapté.

Refuser d'indiquer les quartiers parce que "la modélisation ne vous
convient pas", "on n'indique pas les choses avec des contours flous",
"c'est subjectif", "c'est une info qui provoque des effets parfois
bizarres dans certains outils", "c'est pas assez précis" : je trouve
que vous vous trompez de bataille.

Je trouve que c'est une vue jusqu'au-boutiste et contre-productive de
vouloir pousser la "qualité des données" à des critères inatteignables
ou hors de proportion. La "bonne qualité" ce n'est pas quand on a
enfin placé le point central d'un quartier usuel, après un sondage de
1000 personnes et des relevés au GPS haute précision. La "bonne
qualité" ce n'est pas quand on supprime une information de la carte
alors qu'il y a un consensus local pour estimer que une représentation
correcte et suffisante.

Le niveau de qualité intéressant, c'est quand on fournit une information utile.

-- althio

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

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Jacques Lavignotte]

Le 14/03/2019 à 11:18, Stéphane Péneau a écrit :

Hmm non, pas vraiment, cette route n'est pas là pour relier deux villes. 
C'est plutôt l'avenue Jacques Coeur qui est là pour ça.


Et donc ?

J.

;)


--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[FR via Talk-fr]

Merci 1000 fois:

Pour les utilisatrices et utilisateurs d'Ubuntu ça donne:
/usr/bin/java -Djsse.enableSNIExtension=false -jar /home/.../josm-tested.jar
(... = chemin où est rangé JOSM)

Mais comme savoir bidouiller des lignes de commande n'est pas un 
pré-requis pour contribuer à OSM serait-il possible de faire quelque 
chose pour résoudre le problème à la source ? ;-)


Françoise


Le 13/03/2019 à 08:36, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / 
DT GE PPE) a écrit :

Hello,

Oui j’ai résolu (après avoir cherché sur le Net) par un paramètre 
supplémentaire dans le lancement de JOSM :


-Djsse.enableSNIExtension=false

Par exemple : D:\JAVA1.8\bin\java  -Djsse.enableSNIExtension=false 
-Djosm.home="D:\JOSM" -Xmx4096M -jar josm-tested.jar


En revanche, il faut pas me demander pourquoi ni comment. Je crois 
encore à la magie  En tout cas, ça refonctionne.


Denis





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

Re: [OSM-talk-fr] Cas des transformateurs du Puy de Dôme

[marc marc]

Bonjour,

Le 13.03.19 à 22:35, François Lacombe a écrit :
> très probablement depuis l'open data Enedis

c'est un point important à vérifier.

> Le soucis c'est qu'il n'a mis que power=transformer au lieu de 
> power=substation et Osmose détecte toutes ces contributions en erreur.
> https://www.openstreetmap.org/way/63205617
> 
> J'ai laissé un commentaire sur l'un des changeset, mais il y a beaucoup 
> de corrections à faire.

il y a actuellement 1821 way 
["power"="transformer"][building=yes](user:fred63)
https://overpass-turbo.eu/s/GYX

> Quelle serait la meilleure solution?
> Tous les building=yes + power=transformer devraient avoir les tags :

ce serrait pratique de faire une édition de masse mais généralement
tu n'es pas chaud. cependant tu fais 2 suppositions

> building=service

comment savoir si tous ce qu'il a vu était bien dans un bâtiment
de service ? il pourrait y avoir l'une ou l'autre tour.
je pense qu'il est préférable de pas toucher ce tag à l'aveugle.
un pic4review est sans doute plus adapté, du moins s'il existe des 
photos de cet endroit.

> power=substation
> substation=minor_distribution
> operator=Enedis

ils sont tous géographiquement proche
https://overpass-turbo.eu/s/GYZ
mais cela signifie-t-il qu'il n'y a aucun risque d'avoir dans le lot
des équipement non Enedis ? ou une cabine industrielle pour l'aéroport ?
ou une de traction pour le chemin de fer ?

> location=indoor

je trouve ce tag incohérent.
le transformation (pièce d'équipement parfois représenté par un noeud) 
est bien location=indoor mais vu que l'objet est un bâtiment,
le bâtiment lui-même n'est pas location=indoor

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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

Bon et bien merci Marc et Florimond ^^

C'est le meilleur résumé (par Marc) de notre point de vue :

> il y a 2 choses "renseignable" :
> la limite administrative et le lieu-dit
> mais l'un n'est pas l'admin_center de l'autre

et la meilleure explication (par Florimond) de notre point de vue :

> 1. Il faut les limites du quartier administratif, car c'est une réalité qui 
> est possible de trouver sur le terrain et est pratique.
> Sans admin_centre car il n'y a pas de lieu institutionnel qui le gère (pas de 
> chef de quartier qui travail dans le bureau du quartier).

> 2. Il faut définir les quartiers usuels, réalité du terrain, les gens se 
> disent habitant de tel quartier.
> Ces quartiers sont différents des quartiers administratifs, les dénomination 
> ou périmètre sont différents.
> Ils n'ont pas un périmètre bien défini (donc pas de frontière a tracer), il 
> faut les représenter par un nœud central au quartier.
> Ce nœud n'est pas l'admin_center d'un quartier administratif.

et la modélisation possible est :

1. un truc compliqué et administratif
Relation: type=boundary + boundary=administrative + admin_level=10 +
name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
définir la géométrie
(pas de membre admin_center)
(optionnel un membre label)

2. un truc simple et humain
Point: place=suburb|* + name=*
(pas d'admin_level, pas de ref:INSEE, pas de relation)


Romain,

Tu parles de chronologie d'insertion dans OSM entre deux éléments.
- Mais si les deux éléments ont une raison valable d'exister, la date
de création de l'un ou l'autre objet a peu d'intérêt.
- Si au contraire, ils sont redondants, ils devraient fusionner en
gardant le meilleur des deux éléments (géométrie, attributs,
historique de contribution)
Bien sûr, pour moi le nœud n'est pas en doublon de la relation.

Enfin, hors OSM, dans la réalité, la chronologie est intéressante : le
lieu-dit ou quartier existe *avant* le quartier administratif, et il
lui prête son nom.
Par exemple, le quartier de la Goutte-d'Or existe avant 1860, avant
d'être rattaché à Paris, avant la création du quartier administratif.

Les quartiers administratifs pourraient être redécoupés, renommés, le
18e arrondissement pourrait retrouver son "indépendance" en tant que
commune de "La Chapelle" ou être rattaché à une autre commune...
Tout cela changerait peut-être la Relation: type=boundary +
boundary=administrative + admin_level=10 et son name* ...
Mais tout cela ne changerait rien pour le lieu-dit et notre noeud place=* :
l'appellation "quartier de la Goutte-d'Or" serait toujours dans les
esprits, et pendant un certain temps.

-- althio

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

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Stéphane Péneau]

Le 14/03/2019 à 09:52, Rpnpif a écrit :

Le 13 mars 2019, marc marc a écrit :


taggée 'Residentiel' or pour plus de 70% elle est bordée de champs.
Y'a t-il un autre choix ?

"unclassified" me semble + adapté.

tertiary ?

Hmm non, pas vraiment, cette route n'est pas là pour relier deux villes. 
C'est plutôt l'avenue Jacques Coeur qui est là pour ça.


Route500 semble du même avis : 
http://tile.openstreetmap.fr/?zoom=16=46.54856=0.39895=00B00TF



Stf



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

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Jacques Lavignotte]

Le 14/03/2019 à 09:52, Rpnpif a écrit :


"unclassified" me semble + adapté.


tertiary ?


Done.


--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Quartiers

[marc marc]

Le 14.03.19 à 09:47, Rpnpif a écrit :
> Et quand une commune, assemblage de villages, devient une « place » dans
> le sens où son nom est utilisé dans la vie quotidienne des habitants
> comme un lieu géographique de vie (par exemple, un livreur veut un
> emplacement pour la nouvelle commune sachant que l'admin_center n'a
> pas le même nom), que fait-on ?

je comprend pas le problème.
si une commune A est un assemblage des villages B (l'admin_center) C D,
Rien n’empêche le livreur de chercher A.

PS: j'ai la naïve impression que le livreur va plutôt chercher no,rue, 
village plut'ot que le nom de la commune :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Changement nom de voies de 'Route' en 'Rue'.

[Rpnpif]

Le 13 mars 2019, marc marc a écrit :

> > taggée 'Residentiel' or pour plus de 70% elle est bordée de champs.  
> > Y'a t-il un autre choix ?  
> 
> "unclassified" me semble + adapté.

tertiary ?

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Quartiers à Paris

[Rpnpif]

Le 13 mars 2019, Florimond Berthoux a écrit :

> Vaut mieux un centre imprécis, que pas d'infos du tout.
> De toutes manières calculer un centre précis est absurde, voire impossible.
> Nous ne faisons pas des cartes que pour les ordinateurs.

+1

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Quartiers

[Rpnpif]

Le 13 mars 2019, marc marc a écrit :

> Le 13.03.19 à 19:39, osm.sanspourr...@spamgourmet.com a écrit :
> > Si une commune de plus de 10 000 habitants à plusieurs villages mais le 
> > centre aggloméré ne fait a lui seul plus de 10 000 habitants, doit-on 
> > mettre town ou village ?  
> 
> place=* ne désigne pas une commune dont exit la commune dans le problème.
> reste plusieurs villages et pour chacun d'eux on peux choisir le bon place=*
> après certains voudraient faire des places=* relatif.
> un lieu de 1M d'habitant à côté d'une ville de 10M d'habitant aurait un 
> tag inférieur à un autre lieu à l'autre bout du même pays n'ayant que 1k 
> d'habitant mais qui est le plus gros village à des km à la ronde.
> cela me semble une mauvaise idée.

Et quand une commune, assemblage de villages, devient une « place » dans
le sens où son nom est utilisé dans la vie quotidienne des habitants
comme un lieu géographique de vie (par exemple, un livreur veut un
emplacement pour la nouvelle commune sachant que l'admin_center n'a
pas le même nom), que fait-on ?
C'est le cas de nouvelles communes qui a une problématique qui rejoint
celle des quartiers de Paris (avec des différences bien sûr).

Tout cela pour dire que l'utilisation actuelles des place= et le
repérage est soit trop restreint (boundary seul), soit ambiguë.

Cette discussion est donc très utile.
-- 
Alain Rpnpif

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