Re: [OSM-talk-fr] Code officiel géographique de l'Insee

[Jérôme Amagat]

Je comptais pas changer tous les noms des communes dont j'ai fait la liste,
si j'ai mis la liste c'est pour que d'autres vérifient si il n'y a pas des
erreurs.
d’ailleurs il y en avait une :) pour Cloyes-les-Trois-Rivières les tirets
sont dans le nom officiel mais pas dans osm, c'est corrigé.
Je voulais aussi savoir si on été toujours d’accord pour garder ces nom qui
respecte la typo officiel comme déjà débattu dans d'autres discussions. moi
personnellement j'ai pas vraiment d'avis, l'orthographe et moi  ça fait 2
ou plus ... ce qu'il me choque plus dans ces noms c'est plutôt certains
noms comme "Bairon et ses environs" ou "Jugon-les-Lacs - Commune nouvelle"
ou toutes ces commune avec un nom a rallonge parce que les petites communes
ne veulent pas que leurs noms disparaissent... Et je signale par contre que
Wikipédia a choisi les nom officiel comme nom d'article... (il donne aussi
les autres nom en début d'article)

j'ai aussi mis a jour toutes ces commune pour avoir dans official_name=* le
nom officiel quand il n'y été pas déja.

Le lun. 18 mars 2019 à 20:48,  a écrit :

> Le 18/03/2019 à 19:43, Rpnpif - rpn...@trob.eu a écrit :
>
> Le 17 mars 2019, Jérôme Amagat a écrit :
>
>
> L'insee a sorti son code officiel géographique pour 
> 2019https://www.insee.fr/fr/information/3720946
>  et j'ai regarder les différences avec osm.
> Sur les communes, 2 différences notables, 2 communes en moins dans osm à
> cause de 2 communes nouvelles créées au 28 février en Côte d'Or
> (Collonges-et-Premières et Neuilly-Crimolois). (Le cog c'est la situation
> au 1er janvier.)
>
> Pour les noms des communes beaucoup de petites différences avec le name=*
> de osm. Beaucoup de problèmes de tiret "-" présent dans osm et pas dans le
> cog sur les communes nouvelles, problème de majuscules aussi dans ces
> communes nouvelles. et aussi des différences d'orthographe entre les locaux
> et l'Etat :) (pas mal d'entre elles ont un tag alt_name ou official_name
> avec le nom officiel)
> je vous mets la liste :) (dans la 2e partie c'est que des problèmes de
> tiret) :
>
> code INSEEosmcog
> 29158Penmarc'hPenmarch
> 56046Crac'hCrach
> 56162PlœmeurPloemeur
> 56262Le BonoBono
> 64166ÇaroCaro
> 74112Épagny-Metz-TessyEpagny Metz-Tessy
> 85082Les ÉpessesLes Epesses
>
> Là on voit que le COG a des problèmes avec des lettres non ASCII.
>
> Comme dit Alain, à mettre dans official_name et sinon à regarder au cas
> par cas.
>
> c'h doit rester (se prononce normalement comme le ch allemand, et non
> comme le ch français).
>
> Plœmeur contrairement à Ploemeur se prononce comme il s'écrit. C'est la
> graphie retenue par la mairie. Sinon il y a risque de confusion avec
> Plomeur (heu, même avec ^^).
>
> Pareil pour les Ç et autres É :  à garder dans OSM.
>
> Pour Le Bono, voir plus bas.
>
> Pour les tirets, la version 2020 corrigera peut-être ces erreurs !
> Est-ce qu'on fait une page wiki pour statuer ?
>
> Lors de création de communes nouvelles, quelques communes ont du changer de
> département et l'insee leur a changé leur code quand elle sont devenues
> communes déléguées, c'est le cas de (avec leur nouveau code) :
> Le Fresne-sur-Loire49382
> Pont-Farcy50649
> Gernicourt51664
> Freigné44225
> Qu'est ce qu'il faut faire de ces codes et des anciens ?
>
> Là encore d'accord avec Alain pour les start et end date.
>
> est  ce que je fait les modifications pour coller au COG sans réfléchir ou
> pas?
>
>
oui mais comment ?
ref:INSEE="le nouveau", ref:INSEE:2018-01-01-="le nouveau" et
ref:INSEE:-2018-01-01="l'ancien" ?
ou utilisé old_ref:INSEE ou disused:ref:INSEE=* ...

> Pas systématiquement. Doit-on faire une page wiki pour statuer sur ce
> qu'on fait sur le name (sachant qu'on peut déjà mettre en official_name le
> COG) ?
>
> Une discussion précédente avait dit qu'on mettait le nom normlsié dans
> name=* et le nom officiel dans official_name=*
>
> C'est quoi le nom normalisé ?
>
> Par exemple sur le terrain tu trouves des panneaux Ploemeur à la place de
> Plœmeur.
>
> Tu cherches la page de la mairie pour voir ce qu'elle écrit ?
>
> Pour Le Bono , la commune
> a été créée comme Bono mais la mairie (et les locaux) utilisent Le Bono. On
> va au Bono pas à Bono.
>
> Il me semble qu'on doit avoir name=Le Bono, official_name=Bono.
>
> Actuellement Bono est seulement alt_name.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ***SPAM*** Re: Le Santerre

[Christian Rogel]

> Le 17 mars 2019 à 20:36, djakk djakk  a écrit :
> 
> Est-ce que ça existe dans d’autres pays ? Des régions avec des frontières non 
> administratives ?

Bien sûr. On peut citer les Costwolds, le Lake District et les Marshes en 
Angleterre, la Souabe et la Thuringe en Allemagne, la Kabylie et le M’Zab en 
Algérie, le Kamchatka en Russie, le Pays Dogon, au Mali, le Taklamaklan en 
Chine, les Appalaches aux EU (très vastes et àcheval sur plusieurs entités, 
comme les Alpes).
Pas réductible à l’idée qu’on a des pays en France

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

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

[deuzeffe]

Aucun avis sur la proposition (pas assez aguerrie, je suis).

En revanche, j'abonde avec le fait qu'on ne peut pas mettre 2x2 panneaux 
sur le même nœud, et pourtant sur le terrain, de nombreux panneaux 
doubles sont pile face à face sur le bas-côté droit de chaque voie. Et 
comme je ne sais pas faire, je n'y ai pas touché dans ma zone.

--
deuzeffe

Le 18/03/2019 à 21:36, Florimond Berthoux a écrit :

Bonjour,

J'ai pas tout suivit, mais visiblement il n'est pas décrit sur le wiki 
comment mettre plusieurs panneau sur un même nœud (un même poteau) ?

Chose très courante pourtant.
Il y a un trou dans la spec je dirais.

proposition:
traffic_sign:forward:1=toto
1 étant l'ordre de haut en bas sur le poteau.



Le lun. 18 mars 2019 à 19:24, Bernard Lefrançois 
mailto:bernard.lefranc...@free.fr>> a écrit :


N'oubliez pas que même si le panneau de sortie et celui d'entrée de
la commune suivante sont sur le même support, il s'agit de deux
panneaux distincts.
Si l'on ajoute des attributs il faut savoir de quel panneau on parle.

Même s'il sont sur le même poteau, je placerais deux nœuds
rapprochés avec:

pour la sortie
traffic_sign=city_limit
traffic_sign=FR:EB20

et pour l'entrée
traffic_sign=city_limit
traffic_sign=FR:EB10

Quant au tag name, est-ce vraiment le tag approprié?
Le nom écrit sur la plaque, c'est celui de la commune, pas celui de
la plaque.

Je verrais plutôt le tag inscription=Nomdeville
le wiki est assez large pour l'utilisation de ce tag /(//text of
inscriptions on buildings, memorials, advertising signs and other
objects)/.

Il y aurait bien aussi le champ [value] à placer après l'ID du
panneau, ce qui donnerait:
traffic_sign=FR:EB10[Nomdeville]
mais je ne sait pas si ce champ accepte des valeurs alphabétiques.



*direction* c'est en effet la direction du panneau tel que l'on peut
l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
réseau et aussi un autre modèle de saisie (valide) à condition de
renseigner la direction.

Qui plus est le problème reste le même que pour les intersections de
tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
ville en sortie de ville on a forcément un découpage au niveau du nœud
entrée sortie. D'où l'exploitation de cette modélisation.

Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
saisie left and right n'a aucun intérêt. Et du coup c'est la même
problématique avec forward-backward.

le panneau peut être placé à gauche ou à droite de la voirie généralement à
droite pour l'entrée. Mais dans certains cas comme toujours en France il y
a des exceptions. Le panneau peut être a l'opposé.

l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
des panneaux de sortie ou des panneaux d'entrée le cas échéant.

les panneaux d'entrée et de sortie sont normalisées donc normalement on
pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
par défaut pour l'entrée


Le lun. 18 mars 2019 à 18:01, https://lists.openstreetmap.org/listinfo/talk-fr>> a écrit :

>/J'aurais aussi laissé l'entrée dans name tout simplement. 
/>//>/name:entrance et name:exit, sachant que entrance et exit ne sont
pas des />/codes de langue n'est pas vraiment ambigu mais peut entraîner des
problèmes />/pour les outils d'importation. />//>/name:fr:exit serait le nom en français 
de la commune de sortie. />//>/N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de 
la />/commune mais aussi le nom de l'agglomération suivi de "commune de
XXX". />//>/Exemple : https://www.openstreetmap.org/node/3347836570,
Guidel-Plages />/alors qu'il s'agit de la commune de Guidel. />/Ou avec Mapillary : 
/>/https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3
/>/. />/Oui un panneau de lieu-dit suffit mais le maire devait avoir un
tarif sur />/les panneaux ;-). />//>/Remarquez qu'on entre en français et 
breton mais on ne sort qu'en
français />/! />//>/D'ailleurs comment entreriez-vous : />//>/Guidel-Plages />/Commune de Guidel 
/>/? />//>/Vous laissez tomber "Cne de Guidel" ? />//>/Note : si on ne connait la direction du 
panneau, on ne sait si
c'est une />/entrée ou une sortie. Sur le Wiki on n'entre que le nom de
l'agglomération />/dans laquelle on entre. />/> on a donc croisé un panneau 
qui a donné son nom />/Et non, ça c'est seulement dans le cas droit où toute route menant
à X a />/son panneau d'entrée. />/Typiquement avec des panneaux indiquant 
des sous-parties de la
commune il />/n'est pas évitent que toutes les limites internes 

Re: [OSM-talk-fr] BAN(O): accompagnement des communes

[deuzeffe]

Le 18/03/2019 à 18:02, marc marc a écrit :


Donc si une commune est propriétaire d'un jeu de donnée d'addr,
elle peux l'introduire dans osm (ou le fournir à deuzeffe qui le
ferra :p) 


Gnagnagna.


et publier la même chose sous lo/ol ou autoriser quelqu'un
à le publier la donne initiale sous lo/ol.


Si j'étais mauvaise langue, je dirais que l'ODbL est aussi vicieuse que 
la GPL. Mais comme on n'est pas TrollDi, je m'abstiens.


Plus sérieusement, je ne sais toujours pas sous quelle forme ma commune 
détient sa base d'adresse :/ J'avais eu l'idée tordue d'attendre le 
1/1/20 et la sortie de la BAN (à jour, on peut l'espérer) en LO/OL, mais 
c'est loin :(


--
deuzeffe, qui piaffe et trépigne.

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

Re: [OSM-talk-fr] Les portes de Paris

[althio]

Presque pareil que Jean-Yvon pour moi :

> > Place=locality n'est pas un point, c'est un lieu sans habitant, les
> (quartiers) des "portes" de Paris sont maintenant habitées.
> Et actuellement personne n'habite sur une porte.
> Donc locality me va bien. Si par contre des quartiers s'appellent du nom
> de la porte d'à côté alors il faut mettre un contour et
> suburb/neighbourhood/quarter.
>

Un point avec place=locality : très bien pour les véritables lieux des
"Portes".
Je préfère un point, mais à la limite pourquoi pas un polygone qui englobe
les voies, le carrefour, de manière très étroite, mais pas les bâtiments.
C'est le point exact si on vise une navigation avec cette destination ou un
passage par ce point.

Un point (ou un polygone qui englobe les habitations du quartier) avec
place=suburb/neighbourhood/quarter : si et seulement si il y a un véritable
quartier avec une existence locale, qui répond à ce nom.
Pour Porte d'Orléans, tout à fait, il me semble que c'est suffisamment
reconnu pour être un nom de quartier ("J'habite à Porte d'Orléans", en plus
des commerces, aménités et arrêts de transport en commun qui reprennent le
nom).
Il y aurait quand même un travail de recensement des portes et de leur
reconnaissance en tant que quartier, pour affecter le bon niveau de
place=suburb/neighbourhood/quarter aux lieux qui pourraient en
bénéficier... et puis estimer leur "centre" ou leur "périmètre".

On Sun, 17 Mar 2019 at 11:13, djakk djakk  wrote:

> Salut !
>
> Un peu perdu dans toutes les sous-discussions, j’en relance une :)
>
> C’est moi qui avait initié la cartographie des portes de Paris.
> Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux
> routiers. Mais certaines portes sont très proches les une des autres : si
> la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge
> toute proche n’en est pas un. Elle ferait partie du quartier « porte
> d’Orléans » .
>
> @+
> Julien « djakk »
> ___
> 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] plusieurs traffic_sign sur un poteau

[François Lacombe]

Bonsoir,

On a le même problème pour les antennes télécoms installées sur un pylônes
ou un mât (qui sont eux-même tracés avec un noeud)

Le lun. 18 mars 2019 à 21:56, marc marc  a
écrit :

> - de mettre chaque panneau sur un nœud différent au même endroit (ce
> qui pose des soucis dans plusieurs éditeurs)
>

Pas au même endroit, mais autour du poteau ?
La plupart des éditeurs permettent de zoomer suffisamment.

Ce qui serait intéressant, ce serait que le nœud muni des tags "support"
devienne un aimant pour les panneaux positionnés suffisamment près.

Pour les transformateurs identiques accrochés sur le même poteau, c'est
devices=* qui permet de les dénombrer
https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dtransformer#Ensembles_de_transformateurs

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

Re: [OSM-talk-fr] plusieurs traffic_sign sur un poteau

[marc marc]

Le 18.03.19 à 21:36, Florimond Berthoux a écrit :
> comment mettre plusieurs panneau sur un même nœud (un même poteau) ?
> proposition:
> traffic_sign:forward:1=toto
> 1 étant l'ordre de haut en bas sur le poteau.

https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging#How_it_works._How_to_map
propose :
- un autre ordre traffic_sign:no:forward
- pas de :1 pour le premier (ce qui permet au moins à celui là
d'être utilisable par tous)
- de mettre chaque panneau sur un nœud différent au même endroit (ce
qui pose des soucis dans plusieurs éditeurs)

je me demande s'il y a la moindre app capable d'utiliser ce micro mapping.
perso je préfère rester dans le schéma classique hors propal
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 18.03.19 à 21:16, Ralf Treinen a écrit :
> On Mon, Mar 18, 2019 at 09:11:59PM +0100, Ralf Treinen wrote:
>> On Mon, Mar 18, 2019 at 04:05:34PM +0100, Charles MILLET wrote:
>>> Plutôt que name:in et name:out je crois que name:exit et name:entrance 
>>> seraient
>>> plus proche de ce que se fait déjà.
>>
>> Comment gérer le cas où le panneau est sur la frontière entre deux communes,
>> c-a-d la sortie d'une commune est l'entrée de l'autre ?
> 
> Désolé j'ai envoyé ce mail avant de voir la proposition de Bernard
> de mapper dans ce cas deux panneaux différents.

les exemples de Bernard sont des entrées/sortie d'agglomération,
pas de commune.
pour ma part je ne fais rien avec l'info commune,
elle existe déjà dans la relation de la commune.
mais c'est facilement ajouté dans le tag inscription=*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Florimond Berthoux]

Bonjour,

J'ai pas tout suivit, mais visiblement il n'est pas décrit sur le wiki
comment mettre plusieurs panneau sur un même nœud (un même poteau) ?
Chose très courante pourtant.
Il y a un trou dans la spec je dirais.

proposition:
traffic_sign:forward:1=toto
1 étant l'ordre de haut en bas sur le poteau.



Le lun. 18 mars 2019 à 19:24, Bernard Lefrançois 
a écrit :

> N'oubliez pas que même si le panneau de sortie et celui d'entrée de la
> commune suivante sont sur le même support, il s'agit de deux panneaux
> distincts.
> Si l'on ajoute des attributs il faut savoir de quel panneau on parle.
>
> Même s'il sont sur le même poteau, je placerais deux nœuds rapprochés avec:
>
> pour la sortie
> traffic_sign=city_limit
> traffic_sign=FR:EB20
>
> et pour l'entrée
> traffic_sign=city_limit
> traffic_sign=FR:EB10
>
> Quant au tag name, est-ce vraiment le tag approprié?
> Le nom écrit sur la plaque, c'est celui de la commune, pas celui de la
> plaque.
>
> Je verrais plutôt le tag inscription=Nomdeville
> le wiki est assez large pour l'utilisation de ce tag *(**text of
> inscriptions on buildings, memorials, advertising signs and other objects)*
> .
>
> Il y aurait bien aussi le champ [value] à placer après l'ID du panneau, ce
> qui donnerait:
> traffic_sign=FR:EB10[Nomdeville]
> mais je ne sait pas si ce champ accepte des valeurs alphabétiques.
>
>
> *direction* c'est en effet la direction du panneau tel que l'on peut
> l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
> de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
> réseau et aussi un autre modèle de saisie (valide) à condition de
> renseigner la direction.
>
> Qui plus est le problème reste le même que pour les intersections de
> tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
> ville en sortie de ville on a forcément un découpage au niveau du nœud
> entrée sortie. D'où l'exploitation de cette modélisation.
>
> Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
> saisie left and right n'a aucun intérêt. Et du coup c'est la même
> problématique avec forward-backward.
>
> le panneau peut être placé à gauche ou à droite de la voirie généralement à
> droite pour l'entrée. Mais dans certains cas comme toujours en France il y
> a des exceptions. Le panneau peut être a l'opposé.
>
> l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
> que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
> des panneaux de sortie ou des panneaux d'entrée le cas échéant.
>
> les panneaux d'entrée et de sortie sont normalisées donc normalement on
> pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
> par défaut pour l'entrée
>
>
> Le lun. 18 mars 2019 à 18:01,  > a écrit :
>
> >* J'aurais aussi laissé l'entrée dans name tout simplement.
> *>>* name:entrance et name:exit, sachant que entrance et exit ne sont pas des
> *>* codes de langue n'est pas vraiment ambigu mais peut entraîner des 
> problèmes
> *>* pour les outils d'importation.
> *>>* name:fr:exit serait le nom en français de la commune de sortie.
> *>>* N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de la
> *>* commune mais aussi le nom de l'agglomération suivi de "commune de XXX".
> *>>* Exemple : https://www.openstreetmap.org/node/3347836570, 
>  Guidel-Plages
> *>* alors qu'il s'agit de la commune de Guidel.
> *>* Ou avec Mapillary :
> *>* 
> https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3
>  
> 
> *>* .
> *>* Oui un panneau de lieu-dit suffit mais le maire devait avoir un tarif sur
> *>* les panneaux ;-).
> *>>* Remarquez qu'on entre en français et breton mais on ne sort qu'en 
> français
> *>* !
> *>>* D'ailleurs comment entreriez-vous :
> *>>* Guidel-Plages
> *>* Commune de Guidel
> *>* ?
> *>>* Vous laissez tomber "Cne de Guidel" ?
> *>>* Note : si on ne connait la direction du panneau, on ne sait si c'est une
> *>* entrée ou une sortie. Sur le Wiki on n'entre que le nom de l'agglomération
> *>* dans laquelle on entre.
> *>* > on a donc croisé un panneau qui a donné son nom
> *>* Et non, ça c'est seulement dans le cas droit où toute route menant à X a
> *>* son panneau d'entrée.
> *>* Typiquement avec des panneaux indiquant des sous-parties de la commune il
> *>* n'est pas évitent que toutes les limites internes soient indiquées, par
> *>* exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau
> *>* d'entrée dans l'autre zone.
> *>* Ceci dit je suis à peu-près sûr d'arriver à entrer via "Les Cinq Chemins -
> *>* Cne de Guidel" et à ressortir par "Guidel", il suffit de passer par des
> *>* petites 

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

[Ralf Treinen]

On Mon, Mar 18, 2019 at 09:11:59PM +0100, Ralf Treinen wrote:
> On Mon, Mar 18, 2019 at 04:05:34PM +0100, Charles MILLET wrote:
> > Plutôt que name:in et name:out je crois que name:exit et name:entrance 
> > seraient
> > plus proche de ce que se fait déjà.
> 
> Comment gérer le cas où le panneau est sur la frontière entre deux communes,
> c-a-d la sortie d'une commune est l'entrée de l'autre ?

Désolé j'ai envoyé ce mail avant de voir la proposition de Bernard
de mapper dans ce cas deux panneaux différents.

-Ralf.

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

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

[Ralf Treinen]

On Mon, Mar 18, 2019 at 04:05:34PM +0100, Charles MILLET wrote:
> Plutôt que name:in et name:out je crois que name:exit et name:entrance 
> seraient
> plus proche de ce que se fait déjà.

Comment gérer le cas où le panneau est sur la frontière entre deux communes,
c-a-d la sortie d'une commune est l'entrée de l'autre ?

-Ralf

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

Re: [OSM-talk-fr] Places PMR ?

[marc marc]

> parking_space=disabled

dernier soucis avec ce tag, c'est que c'est une règle qui ne fonctionne 
que pour un objet précis.
si tu veux renseigner qu'un parking au complet est PMR,
cela ne fonctionne pas (parce que parking=* décrit le type d'infra 
(aérien, souterrain, multi-niveau)
Si tu veux renseigner une entrée, entrance=* ne va pas non plus.
si chaque objet à sa logique différente, c'est pas génial.
tous le reste utilisant un tag d'accès,je trouve + logique de faire 
pareil pour les parking_space
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

[marc marc]

Le 18.03.19 à 18:02, Vincent Bergeot a écrit :
> je n'imagine pas amenity=parking_space, capacity=8 et capacity:disabled=2

et pourtant si tu n'as d'image sat pour faire + précis,
tu peux faire un polygone devant l'entrée d'un magasin
et mettre de mémoire qu'il y a plusieurs places dont 2 PMR.
je trouve que c'est une erreur de se baser sur un tag capacity
pour décrire une restriction d'accès.

>   * parking_space=disabled

je trouve ce tag ambigu donc peux utilisable.
il a été utilisé avant d'être définit précisément.
du coup tu ne sais pas si le contributeur a voulu renseigner
la restriction d'accès ou l'accessibilité réelle.
et le site renseigné sur le wiki comme l'utilisant,
ne semble plus l'utiliser. ex
https://www.openstreetmap.org/node/1601704007
http://rollstuhlkarte.ch/?zoom=18=47.36616=8.53991=B00FFTT
(la surcouche est en 404)
c'est pour moi un bon candidat à être déprécié en faveur
de tag + précis :) mais c'est le + courant :-(

à propos de la restriction d'accès (disabled ou access:disabled)
j'avais vu je ne sais plus où un argument sur le conflit de mettre 
disabled dans le nom du tag parce que les tag d'accès à gauche (les 
clefs) sont des moyens de transport tandis que les usages sont à droite 
(en valeur).
la conséquence de mixer des utilisateurs dans la partie gauche
se pose par exemple lorsqu'on veux renseigner une place avec double 
condition : les places PMR d'un magasin access=destination + disable=yes
Selon la logique de tous les autres tag d'accès (ex access=destination 
foot=yes), c'est permis si on respecte au moins une condition non 
surchargée access=destination ou disable=yes
du coup tu ne sais pas décrire les conditions multiples.
la solution que j'avais vu et utilisé était :
access=no + access:conditional=designated␣@␣disabled (yes au lieu de 
designated fait aussi l'affaire)
215 utilisations mondiales dont sans doute bcp de moi
https://taginfo.openstreetmap.org/tags/access%3Aconditional=designated%20%40%20disabled

Du coup, je met pour le moment les 2 (parking_space=disabled et accces) 
en plus des 2 autres (capacity et wheelchair) pour favoriser 
l'utilisation des données, mais c'est vraiment pas top.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code officiel géographique de l'Insee

[osm . sanspourriel]

Le 18/03/2019 à 19:43, Rpnpif - rpn...@trob.eu a écrit :

Le 17 mars 2019, Jérôme Amagat a écrit :


L'insee a sorti son code officiel géographique pour 2019
https://www.insee.fr/fr/information/3720946
  et j'ai regarder les différences avec osm.
Sur les communes, 2 différences notables, 2 communes en moins dans osm à
cause de 2 communes nouvelles créées au 28 février en Côte d'Or
(Collonges-et-Premières et Neuilly-Crimolois). (Le cog c'est la situation
au 1er janvier.)

Pour les noms des communes beaucoup de petites différences avec le name=*
de osm. Beaucoup de problèmes de tiret "-" présent dans osm et pas dans le
cog sur les communes nouvelles, problème de majuscules aussi dans ces
communes nouvelles. et aussi des différences d'orthographe entre les locaux
et l'Etat :) (pas mal d'entre elles ont un tag alt_name ou official_name
avec le nom officiel)
je vous mets la liste :) (dans la 2e partie c'est que des problèmes de
tiret) :

code INSEEosmcog
29158Penmarc'hPenmarch
56046Crac'hCrach
56162PlœmeurPloemeur
56262Le BonoBono
64166ÇaroCaro
74112Épagny-Metz-TessyEpagny Metz-Tessy
85082Les ÉpessesLes Epesses


Là on voit que le COG a des problèmes avec des lettres non ASCII.

Comme dit Alain, à mettre dans official_name et sinon à regarder au cas 
par cas.


c'h doit rester (se prononce normalement comme le ch allemand, et non 
comme le ch français).


Plœmeur contrairement à Ploemeur se prononce comme il s'écrit. C'est la 
graphie retenue par la mairie. Sinon il y a risque de confusion avec 
Plomeur (heu, même avec ^^).


Pareil pour les Ç et autres É :  à garder dans OSM.

Pour Le Bono, voir plus bas.

Pour les tirets, la version 2020 corrigera peut-être ces erreurs !

Est-ce qu'on fait une page wiki pour statuer ?

Lors de création de communes nouvelles, quelques communes ont du changer de
département et l'insee leur a changé leur code quand elle sont devenues
communes déléguées, c'est le cas de (avec leur nouveau code) :
Le Fresne-sur-Loire49382
Pont-Farcy50649
Gernicourt51664
Freigné44225
Qu'est ce qu'il faut faire de ces codes et des anciens ?

Là encore d'accord avec Alain pour les start et end date.

est  ce que je fait les modifications pour coller au COG sans réfléchir ou
pas?
Pas systématiquement. Doit-on faire une page wiki pour statuer sur ce 
qu'on fait sur le name (sachant qu'on peut déjà mettre en official_name 
le COG) ?

Une discussion précédente avait dit qu'on mettait le nom normlsié dans
name=* et le nom officiel dans official_name=*


C'est quoi le nom normalisé ?

Par exemple sur le terrain tu trouves des panneaux Ploemeur à la place 
de Plœmeur.


Tu cherches la page de la mairie pour voir ce qu'elle écrit ?

Pour Le Bono , la commune 
a été créée comme Bono mais la mairie (et les locaux) utilisent Le Bono. 
On va au Bono pas à Bono.


Il me semble qu'on doit avoir name=Le Bono, official_name=Bono.

Actuellement Bono est seulement alt_name.

Jean-Yvon

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

Re: [OSM-talk-fr] Luftdaten: projet de science participative

[bruno Piguet]

Et comme dans tout bon projet avec des données géographiques, il y en a au
centre du golfe de Guinnée  :
https://france.maps.luftdaten.info/#6/0.000/0.000
;-)

Le lun. 18 mars 2019 à 08:40, PIERRE Sylvain via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Peut-être avez-vous déjà entendu parler du projet de science participative
> et citoyenne Luftdaten…
>
>
>
> Pics de pollution, alertes aux particules fines… Dans les grandes villes
> (ou  ailleurs), les valeurs limites et les seuils d’alerte sont souvent
> dépassés. Comment peut-on mesurer et interpréter la qualité de l’air?
>
>
>
> Pour répondre à cette question le OK Lab Stuttgart a mis en œuvre un
> projet collaboratif et citoyen de mesure des particules fines :
>
> https://luftdaten.info/fr/accueil/
>
>
>
> En résumé : il s’agit de construire soit-même un détecteur de particules
> qui alimentera une base de données qui peut être visualisées ici (très
> bel accès aux données avec un fond OSM) :
>
> https://france.maps.luftdaten.info/#7/48.673/9.437
>
> Le projet commence à se développer en France. La documentation est très
> bien faite. L’investissement est réduit à quelques dizaines d’euros pour le
> matériel. C’est ludique, contributif.
>
> Quelques liens supplémentaires :
>
> http://www.wiki-rennes.fr/images/c/ca/Notice_composants.pdf
>
> http://www.wiki-rennes.fr/Capteurs_Luftdaten
>
>
> https://fabmanager.csc49.fr/#!/projects/capteur-de-micro-particules-luftdaten-avec-abris-pour-l-ademe
>
>
>
> *→*  *Sylvain PIERRE*
>
>  Chef de projet système d’information
>
>  Direction des Systèmes d’Information
>
>  Service Projets et Applications Numériques
>
>*Conseil Départemental du Bas-Rhin*
>
> 
>
>  Hôtel du Département
>  1 place du Quartier Blanc 67964 Strasbourg Cedex 9
>  Tél : 03 88 76 68 88 - mobile :
>  Mobile : 06 30 96 31 76
>  Email : sylvain.pie...@bas-rhin.fr
>
>  www.bas-rhin.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] améliorer les panneaux entrée et sortie de ville

[marc marc]

qlq a une photo d'un panneau "fin city_limit=A" "city_limit=B" sur un 
même poteau ?
je me demande si c'est pertinant d'utiliser city_limit pour le panneau 
de fin c'est p'tre mieux de crer un traffic_sign=end_city_limit
puisqu'il y a 2 panneaux différents.

Le 18/03/2019 à 19:24, Bernard Lefrançois

> Je verrais plutôt le tag inscription=Nomdeville
c'est pertinent. qlq de motifier pour proposer la modif sur tagging ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Seigneuret]

En effet c'est un bon point sauf quand tout est sur un seul point (ou il
faut virtuellement en créer deux)? Même problème que sur les panneaux
d'orientation.
En effet pour moi si je crée deux points. Je traite tous mes cas.

Le lun. 18 mars 2019 à 19:39,  a écrit :

> Le 18/03/2019 à 19:24, Bernard Lefrançois - bernard.lefranc...@free.fr a
> écrit :
>
> Même s'il sont sur le même poteau, je placerais deux nœuds rapprochés
>
> +1 et d'abord la sortie, donc typiquement 2*2 points (entrée et sortie
> dans chaque sens).
>
> Quant au tag name, est-ce vraiment le tag approprié?
> Le nom écrit sur la plaque, c'est celui de la commune, pas celui de la
> plaque.
>
> Je verrais plutôt le tag inscription=Nomdeville
> le wiki est assez large pour l'utilisation de ce tag *(**text of
> inscriptions on buildings, memorials, advertising signs and other objects)*
> .
>
> Stricto sensu exact mais contraire au wiki
>  "
> Il est recommandé également d'ajouter le nom de la ville ou du hameau avec
> name =*, et si besoin
> alt_name =*" et au
> bon sens.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Photos ESRI et Tahiti

[Violaine_Do]

Hello,

Je suis de ce côté du globe ^^

Tu peux t'amuser à visiter Tefenua : 
https://www.tefenua.gov.pf/tefenua/# le geoportail du coin


Et rajouter les couches en WMTS dans QGis... 
http://www.tefenua.gov.pf/tefenua/api/wmts


Attention visualisation only...

Si certaines couches t'intéressent, le SAU (service de l'urba) fournit 
les siennes en licences compatible OSM.. N'hésite pas à me dire si ça te 
botte.


Et enfin j'en connais un qui adorerais faire cette rando, je t'avoue 
qu'elle me fait un peu peur, n'hésite pas à nous faire signe


Bises, bonne découverte!

Violaine

On 18/03/2019 06:37, jabali wrote:

Avec un compte, les données sont en haute résolution . Ce qui est quand même
plus précis.



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


--
Violaine_Do


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

Re: [OSM-talk-fr] Code officiel géographique de l'Insee

[Rpnpif]

Le 17 mars 2019, Jérôme Amagat a écrit :

> L'insee a sorti son code officiel géographique pour 2019
> https://www.insee.fr/fr/information/3720946
>  et j'ai regarder les différences avec osm.
> Sur les communes, 2 différences notables, 2 communes en moins dans osm à
> cause de 2 communes nouvelles créées au 28 février en Côte d'Or
> (Collonges-et-Premières et Neuilly-Crimolois). (Le cog c'est la situation
> au 1er janvier.)
> 
> Pour les noms des communes beaucoup de petites différences avec le name=*
> de osm. Beaucoup de problèmes de tiret "-" présent dans osm et pas dans le
> cog sur les communes nouvelles, problème de majuscules aussi dans ces
> communes nouvelles. et aussi des différences d'orthographe entre les locaux
> et l'Etat :) (pas mal d'entre elles ont un tag alt_name ou official_name
> avec le nom officiel)
> je vous mets la liste :) (dans la 2e partie c'est que des problèmes de
> tiret) :
> 
> code INSEEosmcog
> 05139Le DévoluyDévoluy
> 07011Vallées-d'Antraigues-AsperjocVallées-d’Antraigues-Asperjoc
> 07084ÉclassanEclassan
> 08116Bairon-et-ses-EnvironsBairon et ses environs
> 14281Formigny-la-BatailleFormigny La Bataille
> 16052Bors-de-MontmoreauBors (Canton de Tude-et-Lavalette)
> 16053Bors-de-BaignesBors (Canton de Charente-Sud)
> 16082Boisné-la-TudeBoisné-La Tude
> 17340Saint-Pierre-la-NoueSaint-Pierre-La-Noue
> 19252Sarroux-Saint-JulienSarroux - Saint Julien
> 22084Jugon-les-Lacs Commune nouvelleJugon-les-Lacs - Commune
> nouvelle
> 24269MialletMialet
> 27693Sylvains-lès-MoulinsSylvains-Lès-Moulins
> 28406Eole-en-BeauceÉole-en-Beauce
> 29021Plounéour-Brignogan-PlagesPlounéour-Brignogan-plages
> 29158Penmarc'hPenmarch
> 38273Nantes-en-RattierNantes-en-Ratier
> 42031ÇaloireCaloire
> 44066Grandchamp-des-FontainesGrandchamps-des-Fontaines
> 48116Pont-de-Montvert-Sud-Mont-LozèrePont de Montvert - Sud Mont
> Lozère
> 49160Ingrandes-le-Fresne-sur-LoireIngrandes-Le Fresne sur Loire
> 50090Buais-les-MontsBuais-Les-Monts
> 50168Ducey-les-ChérisDucey-Les Chéris
> 50209Gonneville-le-TheilGonneville-Le Theil
> 50431Remilly-les-MaraisRemilly Les Marais
> 56046Crac'hCrach
> 56162PlœmeurPloemeur
> 56262Le BonoBono
> 62705RétyRety
> 64166ÇaroCaro
> 71204Fragnes-la-LoyèreFragnes-La Loyère
> 74049BrisonBrizon
> 74112Épagny-Metz-TessyEpagny Metz-Tessy
> 79217Prailles-la-CouardePrailles-La Couarde
> 84151Vitrolles-en-LuberonVitrolles-en-Lubéron
> 85008Aubigny-les-ClouzeauxAubigny-Les Clouzeaux
> 85082Les ÉpessesLes Epesses
> 86265SossaySossais
> 97603BandréléBandrele
> 97607DembéniDembeni
> 
> 01015Arboys-en-BugeyArboys en Bugey
> 01130Bresse-VallonsBresse Vallons
> 01185Plateau-d'HautevillePlateau d'Hauteville
> 01286Parves-et-NattagesParves et Nattages
> 02053Vallées-en-ChampagneVallées en Champagne
> 02458Dhuys-et-Morin-en-BrieDhuys et Morin-en-Brie
> 04120Val-d'OronayeVal d'Oronaye
> 05118Val-Buëch-MéougeVal Buëch-Méouge
> 08491Vrigne-aux-BoisVrigne aux Bois
> 12177Palmas-d'AveyronPalmas d'Aveyron
> 12224Saint-Geniez-d'Olt-et-d'AubracSaint Geniez d'Olt et d'Aubrac
> 12270Sévérac-d'AveyronSévérac d'Aveyron
> 14061Souleuvre-en-BocageSouleuvre en Bocage
> 15108Val-d'ArcomieVal d'Arcomie
> 16175Val-des-VignesVal des Vignes
> 17295Réaux-sur-TrèfleRéaux sur Trèfle
> 24035Pays-de-BelvèsPays de Belvès
> 24064Brantôme-en-PérigordBrantôme en Périgord
> 24376Saint-Aulaye-PuymangouSaint Aulaye-Puymangou
> 24490Saint-Privat-en-PérigordSaint Privat en Périgord
> 25424Les Premiers-SapinsLes Premiers Sapins
> 27105Grand-BourgtherouldeGrand Bourgtheroulde
> 27191Clef-Vallée-d'EureClef Vallée d'Eure
> 27302Le Bosc-du-TheilLe Bosc du Theil
> 27638Le Thuit-de-l'OisonLe Thuit de l'Oison
> 28103Cloyes les Trois RivièresCloyes-les-Trois-Rivières
> 35257Maen-RochMaen Roch
> 38225Autrans-Méaudre-en-VercorsAutrans-Méaudre en Vercors
> 38359Saint-Antoine l'AbbayeSaint Antoine l'Abbaye
> 38439Crêts-en-BelledonneCrêts en Belledonne
> 39258Grande-Rivière-ChâteauGrande-Rivière Château
> 39378Les Trois-ChâteauxLes Trois Châteaux
> 46063Castelnau-Montratier-Sainte-AlauzieCastelnau Montratier-Sainte
> Alauzie
> 46252Les Pechs-du-VersLes Pechs du Vers
> 46268Saint-Géry-VersSaint Géry-Vers
> 48009Peyre-en-AubracPeyre en Aubrac
> 48061Florac-Trois-RivièresFlorac Trois Rivières
> 48139Saint-Bonnet-LavalSaint Bonnet-Laval
> 48152Ventalon-en-CévennesVentalon en Cévennes
> 48166Cans-et-CévennesCans et 

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

[osm . sanspourriel]

Le 18/03/2019 à 19:24, Bernard Lefrançois - bernard.lefranc...@free.fr a 
écrit :

Même s'il sont sur le même poteau, je placerais deux nœuds rapprochés


+1 et d'abord la sortie, donc typiquement 2*2 points (entrée et sortie 
dans chaque sens).



Quant au tag name, est-ce vraiment le tag approprié?
Le nom écrit sur la plaque, c'est celui de la commune, pas celui de la 
plaque.


Je verrais plutôt le tag inscription=Nomdeville
le wiki est assez large pour l'utilisation de ce tag /(//text of 
inscriptions on buildings, memorials, advertising signs and other 
objects)/.


Stricto sensu exact mais contraire au wiki 
 " 
Il est recommandé également d'ajouter le nom de la ville ou du hameau 
avec name =*, et si 
besoin alt_name =*" 
et au bon sens.


Jean-Yvon


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

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

[Bernard Lefrançois]

N'oubliez pas que même si le panneau de sortie et celui d'entrée de la 
commune suivante sont sur le même support, il s'agit de deux panneaux 
distincts.

Si l'on ajoute des attributs il faut savoir de quel panneau on parle.

Même s'il sont sur le même poteau, je placerais deux nœuds rapprochés avec:

pour la sortie
traffic_sign=city_limit
traffic_sign=FR:EB20

et pour l'entrée
traffic_sign=city_limit
traffic_sign=FR:EB10

Quant au tag name, est-ce vraiment le tag approprié?
Le nom écrit sur la plaque, c'est celui de la commune, pas celui de la 
plaque.


Je verrais plutôt le tag inscription=Nomdeville
le wiki est assez large pour l'utilisation de ce tag /(//text of 
inscriptions on buildings, memorials, advertising signs and other objects)/.


Il y aurait bien aussi le champ [value] à placer après l'ID du panneau, 
ce qui donnerait:

traffic_sign=FR:EB10[Nomdeville]
mais je ne sait pas si ce champ accepte des valeurs alphabétiques.



*direction* c'est en effet la direction du panneau tel que l'on peut
l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
réseau et aussi un autre modèle de saisie (valide) à condition de
renseigner la direction.

Qui plus est le problème reste le même que pour les intersections de
tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
ville en sortie de ville on a forcément un découpage au niveau du nœud
entrée sortie. D'où l'exploitation de cette modélisation.

Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
saisie left and right n'a aucun intérêt. Et du coup c'est la même
problématique avec forward-backward.

le panneau peut être placé à gauche ou à droite de la voirie généralement à
droite pour l'entrée. Mais dans certains cas comme toujours en France il y
a des exceptions. Le panneau peut être a l'opposé.

l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
des panneaux de sortie ou des panneaux d'entrée le cas échéant.

les panneaux d'entrée et de sortie sont normalisées donc normalement on
pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
par défaut pour l'entrée


Le lun. 18 mars 2019 à 18:01, https://lists.openstreetmap.org/listinfo/talk-fr>> a écrit :

>/J'aurais aussi laissé l'entrée dans name tout simplement. />//>/name:entrance et name:exit, sachant que entrance et exit ne sont pas des />/codes de langue n'est pas vraiment ambigu mais peut entraîner des 
problèmes />/pour les outils d'importation. />//>/name:fr:exit serait le nom en français de la commune de sortie. />//>/N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de la />/commune mais aussi le nom de l'agglomération suivi de "commune de XXX". />//>/Exemple : https://www.openstreetmap.org/node/3347836570, Guidel-Plages />/alors qu'il s'agit de la commune de Guidel. />/Ou avec Mapillary : />/https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3 
/>/. />/Oui un panneau de lieu-dit suffit mais le maire devait avoir un tarif 
sur />/les panneaux ;-). />//>/Remarquez qu'on entre en français et breton mais on ne sort qu'en 
français />/! />//>/D'ailleurs comment entreriez-vous : />//>/Guidel-Plages />/Commune de Guidel />/? />//>/Vous laissez tomber "Cne de Guidel" ? />//>/Note : si on ne connait la direction du panneau, on ne sait si c'est une />/entrée ou une sortie. Sur le Wiki on n'entre que le nom de 
l'agglomération />/dans laquelle on entre. />/> on a donc croisé un panneau qui a donné son nom />/Et non, ça c'est seulement dans le cas droit où toute route menant à X a />/son panneau d'entrée. />/Typiquement avec des panneaux indiquant des sous-parties de la 
commune il />/n'est pas évitent que toutes les limites internes soient indiquées, par />/exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau />/d'entrée dans l'autre zone. />/Ceci dit je suis à peu-près sûr d'arriver à entrer via "Les Cinq 
Chemins - />/Cne de Guidel" et à ressortir par "Guidel", il suffit de passer par des />/petites rues. />//>/Le 18/03/2019 à 16:59, marc marc - marc_marc_irc at hotmail.com 
 a écrit : />//>/Le 18.03.19 à 16:05, Charles MILLET a écrit : />//>/il me semble qu'il n'y a pas d’ambiguïté donc des name:* devraient 
être bon. />//>/Pourtant name:abc est "name" dans la langue "abc" (ex name:fr name:de) />/Dans les zones multilingue, un panneau est parfois multilingue dont />/multiple name. et un name:abc qui ne se rapport pas à un langue entre en />/conflit avec cette logique bien établie. />/Je n'ai tjs pas saisis l'intérêt, mais si on veux vraiment renseigner />/le nom de la ville qu'on quitte lorsqu'on rentre dans une autre, />/*:name me semble préférable pour éviter cet ambiguïté. />//>/Et si 

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

[Jérôme Seigneuret]

*direction* c'est en effet la direction du panneau tel que l'on peut
l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
réseau et aussi un autre modèle de saisie (valide) à condition de
renseigner la direction.

Qui plus est le problème reste le même que pour les intersections de
tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
ville en sortie de ville on a forcément un découpage au niveau du nœud
entrée sortie. D'où l'exploitation de cette modélisation.

Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
saisie left and right n'a aucun intérêt. Et du coup c'est la même
problématique avec forward-backward.

le panneau peut être placé à gauche ou à droite de la voirie généralement à
droite pour l'entrée. Mais dans certains cas comme toujours en France il y
a des exceptions. Le panneau peut être a l'opposé.

l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
des panneaux de sortie ou des panneaux d'entrée le cas échéant.

les panneaux d'entrée et de sortie sont normalisées donc normalement on
pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
par défaut pour l'entrée


Le lun. 18 mars 2019 à 18:01,  a écrit :

> J'aurais aussi laissé l'entrée dans name tout simplement.
>
> name:entrance et name:exit, sachant que entrance et exit ne sont pas des
> codes de langue n'est pas vraiment ambigu mais peut entraîner des problèmes
> pour les outils d'importation.
>
> name:fr:exit serait le nom en français de la commune de sortie.
>
> N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de la
> commune mais aussi le nom de l'agglomération suivi de "commune de XXX".
>
> Exemple : https://www.openstreetmap.org/node/3347836570, Guidel-Plages
> alors qu'il s'agit de la commune de Guidel.
> Ou avec Mapillary :
> https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3
> .
> Oui un panneau de lieu-dit suffit mais le maire devait avoir un tarif sur
> les panneaux ;-).
>
> Remarquez qu'on entre en français et breton mais on ne sort qu'en français
> !
>
> D'ailleurs comment entreriez-vous :
>
> Guidel-Plages
> Commune de Guidel
> ?
>
> Vous laissez tomber "Cne de Guidel" ?
>
> Note : si on ne connait la direction du panneau, on ne sait si c'est une
> entrée ou une sortie. Sur le Wiki on n'entre que le nom de l'agglomération
> dans laquelle on entre.
> > on a donc croisé un panneau qui a donné son nom
> Et non, ça c'est seulement dans le cas droit où toute route menant à X a
> son panneau d'entrée.
> Typiquement avec des panneaux indiquant des sous-parties de la commune il
> n'est pas évitent que toutes les limites internes soient indiquées, par
> exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau
> d'entrée dans l'autre zone.
> Ceci dit je suis à peu-près sûr d'arriver à entrer via "Les Cinq Chemins -
> Cne de Guidel" et à ressortir par "Guidel", il suffit de passer par des
> petites rues.
>
> Le 18/03/2019 à 16:59, marc marc - marc_marc_...@hotmail.com a écrit :
>
> Le 18.03.19 à 16:05, Charles MILLET a écrit :
>
> il me semble qu'il n'y a pas d’ambiguïté donc des name:* devraient être bon.
>
> Pourtant name:abc est "name" dans la langue "abc" (ex name:fr name:de)
> Dans les zones multilingue, un panneau est parfois multilingue dont
> multiple name. et un name:abc qui ne se rapport pas à un langue entre en
> conflit avec cette logique bien établie.
> Je n'ai tjs pas saisis l'intérêt, mais si on veux vraiment renseigner
> le nom de la ville qu'on quitte lorsqu'on rentre dans une autre,
> *:name me semble préférable pour éviter cet ambiguïté.
>
> Et si on veux garder des données utilisable par une majorité d'app,
> j'aurais gardé la ville entrante dans name tout simplement.
> Au moins les utilisations des données qui ignorent cet "extension"
> pourront quand même utiliser l'info initiale.
> ___
> Talk-fr mailing 
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BAN(O): accompagnement des communes

[marc marc]

Bonjour,

Le 25.02.19 à 12:20, Magalie Dartus a écrit :
> - faire un extract de la BANO est une très bonne idée sauf que la 
> licence est Odbl et que la licence choisie par le CD31 est la LO/OL (pas 
> moyen de négocier ça)
> Du coup le problème principal est celui de la licence.
> Est-ce que vous avez des idées par rapport à cela?

Cela dépend de qui a possède la donnée initiale car celui qui la possède 
a toujours le droit de la publier sous multi-licence.
Exemple : si je vois sur le terrain le 1 rue de la gare,
j'ai le droit de l'ajouter dans osm en odbl + et de publier "le 1 rue
de la gare existe et se trouve là" ("là" ne venant pas d'osm) sous 
licence lo/ol.

Donc si une commune est propriétaire d'un jeu de donnée d'addr,
elle peux l'introduire dans osm (ou le fournir à deuzeffe qui le
ferra :p) et publier la même chose sous lo/ol ou autoriser quelqu'un
à le publier la donne initiale sous lo/ol.

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

Re: [OSM-talk-fr] Places PMR ?

[Vincent Bergeot]

Le 18/03/2019 à 14:19, osm.sanspourr...@spamgourmet.com a écrit :



Le 18/03/2019 à 14:12, PanierAvide - panierav...@riseup.net a écrit :
c'est quoi les 2 tags différents dont tu parles là ? car 
amenity=parking_space est pour moi assez différent de parking, c'est 
un peu comme forest et three :)


Je parlais de parking_space=disabled et capacity:disabled=*, c'est 
plus ou moins le même concept dans le sens où ça permet d'isoler le 
fait qu'il y ait une place PMR.



Plus ou moins effectivement.

Si capacity:disabled=capacity, oui, sinon ça veut seulement dire que 
quelque part dans le parking il y a des places PMR.




oui mais si c'est sur des parking_space, nous savons où elles sont,

j'ai ans doute une vision trop uniforme de parking_space et je n'imagine 
pas amenity=parking_space, capacity=8 et capacity:disabled=2


mais plutôt amenity=parking_space et capacity=6 sur les 6 places 
normales et amenity=parking_space, parking_space=disabled et capacity=2 
sur les 2 PMR


bon cela boucle encore un peu !

on reste sur le triplet

 * amenity=parking_space
 * parking_space=disabled
 * capacity:disabled=* (même pour 1)


à plus

--
Vincent Bergeot

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

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

[osm . sanspourriel]

J'aurais aussi laissé l'entrée dans name tout simplement.

name:entrance et name:exit, sachant que entrance et exit ne sont pas des 
codes de langue n'est pas vraiment ambigu mais peut entraîner des 
problèmes pour les outils d'importation.


name:fr:exit serait le nom en français de la commune de sortie.

N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de la 
commune mais aussi le nom de l'agglomération suivi de "commune de XXX".


Exemple : https://www.openstreetmap.org/node/3347836570, Guidel-Plages 
alors qu'il s'agit de la commune de Guidel.
Ou avec Mapillary : 
https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3.
Oui un panneau de lieu-dit suffit mais le maire devait avoir un tarif 
sur les panneaux ;-).


Remarquez qu'on entre en français et breton mais on ne sort qu'en français !

D'ailleurs comment entreriez-vous :

Guidel-Plages
Commune de Guidel
?

Vous laissez tomber "Cne de Guidel" ?

Note : si on ne connait la direction du panneau, on ne sait si c'est une 
entrée ou une sortie. Sur le Wiki on n'entre que le nom de 
l'agglomération dans laquelle on entre.


> on a donc croisé un panneau qui a donné son nom
Et non, ça c'est seulement dans le cas droit où toute route menant à X a 
son panneau d'entrée.
Typiquement avec des panneaux indiquant des sous-parties de la commune 
il n'est pas évitent que toutes les limites internes soient indiquées, 
par exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau 
d'entrée dans l'autre zone.
Ceci dit je suis à peu-près sûr d'arriver à entrer via "Les Cinq Chemins 
- Cne de Guidel" et à ressortir par "Guidel", il suffit de passer par 
des petites rues.


Le 18/03/2019 à 16:59, marc marc - marc_marc_...@hotmail.com a écrit :

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

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

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

Et si on veux garder des données utilisable par une majorité d'app,
j'aurais gardé la ville entrante dans name tout simplement.
Au moins les utilisations des données qui ignorent cet "extension"
pourront quand même utiliser l'info initiale.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Photos ESRI et Tahiti

[jabali]

Avec un compte, les données sont en haute résolution . Ce qui est quand même
plus précis.



--
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] améliorer les panneaux entrée et sortie de ville

[Charles MILLET]

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


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

Charles

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

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

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

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

Et si on veux garder des données utilisable par une majorité d'app,
j'aurais gardé la ville entrante dans name tout simplement.
Au moins les utilisations des données qui ignorent cet "extension"
pourront quand même utiliser l'info initiale.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

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

[marc marc]

Le 18.03.19 à 16:05, Charles MILLET a écrit :
> il me semble qu'il n'y a pas d’ambiguïté donc des name:* devraient être bon.

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

Et si on veux garder des données utilisable par une majorité d'app,
j'aurais gardé la ville entrante dans name tout simplement.
Au moins les utilisations des données qui ignorent cet "extension"
pourront quand même utiliser l'info initiale.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

si qlq est motivié, je pense qu'il est préférable de faire le revert.
parce que de la ml tagging, ce que pas grand monde ne remet en cause
c'est le fait qu'il y a 2 schémas utilisés et que donc les 2 doivent 
être décrit sur le wiki.
après se mettre d'accord sur considérer un l'un mieux que l'autre,
c'est une autre paire de manche.

Le 18.03.19 à 16:27, Charles MILLET a écrit :
> Merci pour les échanges.
> 
> Suite aux échanges sur la liste tagging, il y a eu un revert de fait sur 
> la page anglais mais pas sur la française (et éventuellement d'autres 
> langues concernées ni les autres pages concernées par la modification 
> initiale).
> 
> Est-ce que vous pensez qu'il vaut mieux faire aussi un revert maintenant 
> sur la page FR pour éviter des problèmes de confits techniques ou s'il 
> faut attendre que le sujet avance un peu ?
> 
> Bonne journée.
> 
> Charles
> 
> On 15/03/2019 16:42, Phyks wrote:
>> Salut,
>>
>>> En tant que structuraliste opposite_* est intolérable.
>> Il y a un certain nombre de cas comme ça d'ailleurs sur les attributs
>> vélos. J'ai en tête par exemple aussi le `bicycle_parking` dont la
>> variante `motorcycle_parking` n'existe pas. On se retrouve donc avec des
>> `amenity=motorcycle_parking` et `bicycle_parking=stands` qui ne sont
>> absolument pas ouverts ou prévus pour des vélos.
>>
>>
>>> Dans tous les cas, aujourd'hui je ne ressens aucun besoin de changer le
>>> schéma opposite_*
>> Idem, je vois un petit intérêt à utiliser l'alternative avec
>> `cycleway:*:oneway`, mais cela ne vaut probablement pas de casser tout
>> l'écosystème basé sur le schéma actuel à mon avis (déjà que tous les
>> outils ne supportent pas les cycleway:left/right proprement…).
>>
>>
>>
>> Il y avait récemment eu une discussion sur des différences entre la
>> version anglaise et française de la page "Bicycle" du wiki il me semble
>> (sur talk-fr, sur un autre cas, mais je ne le retrouve plus :/).
>>
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

___
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

[Charles MILLET]

Merci pour les échanges.

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


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


Bonne journée.

Charles

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

Salut,


En tant que structuraliste opposite_* est intolérable.

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



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

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



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



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

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

[Charles MILLET]

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


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


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


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


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


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

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

Salut !

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

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

Julien « djakk »



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


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

Francescu

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

Salut,

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


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

merci

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



-- 
Francescu

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


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

Re: [OSM-talk-fr] Places PMR ?

[osm . sanspourriel]

Le 18/03/2019 à 14:12, PanierAvide - panierav...@riseup.net a écrit :
c'est quoi les 2 tags différents dont tu parles là ? car 
amenity=parking_space est pour moi assez différent de parking, c'est 
un peu comme forest et three :)


Je parlais de parking_space=disabled et capacity:disabled=*, c'est 
plus ou moins le même concept dans le sens où ça permet d'isoler le 
fait qu'il y ait une place PMR.



Plus ou moins effectivement.

Si capacity:disabled=capacity, oui, sinon ça veut seulement dire que 
quelque part dans le parking il y a des places PMR.


Jean-Yvon

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

Re: [OSM-talk-fr] Places PMR ?

[PanierAvide]

Le 16/03/2019 à 11:56, Vincent Bergeot a écrit :


et moi plutôt l'autre :) transparence des intérêts !!!

C'est beau, si ça pouvait être comme ça dans tous les secteurs/domaines 
d'activité... :-)



c'est quoi les 2 tags différents dont tu parles là ? car 
amenity=parking_space est pour moi assez différent de parking, c'est 
un peu comme forest et three :)


Je parlais de parking_space=disabled et capacity:disabled=*, c'est plus 
ou moins le même concept dans le sens où ça permet d'isoler le fait 
qu'il y ait une place PMR.




  * amenity=parking_space
  * parking_space=disabled
  * capacity:disabled=*


pourquoi pas oui

cela signifie qu'une requête sur capacity:disabled=* donnera à voir 
des valeurs que cela soit des parking ou des places de parking ?


Oui, après de toute façon si on veut isoler que les places 
individuelles, la requête amenity=parking_space + capacity:disabled=* 
est pas plus compliquée.


À bientôt,

Adrien.

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

Re: [OSM-talk-fr] Adresses correspondant à des passage à Niveau

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

Bonjour,

La numérotation des PN n’est pas aussi simple qu’il y parait. On peut avoir par 
exemple 2 fois le même n° PN (à deux endroits différents bien entendu). Exe : 
PN 31 ou 38 sur la ligne 70 000 (Paris-Est-Strasbourg). On a des PN 0 aussi 
sans compter les quater,.. sexies jusquà nonies (ligne de fret au sud de Reims 
81 606)
Ce sont donc les références mais qui ne sont pas uniques, même pas sur une même 
ligne.
Perso, je mets plutôt railway :ref que ref tout court (selon 
https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Level_crossings)

Je me suis essayé aux panneaux de signalisation liés au PN (ex. pancarte PN xx 
à 450 m)
https://www.openstreetmap.org/node/6219032844/
https://www.openstreetmap.org/node/6219032843
https://www.openstreetmap.org/node/6219032842

Denis

De : Jérôme Seigneuret [mailto:jerome.seigneu...@gmail.com]
Envoyé : lundi 18 mars 2019 11:27
À : Discussions sur OSM en français 
Objet : [OSM-talk-fr] Adresses correspondant à des passage à Niveau

Bonjour,

Je viens de voir que pas mal de passages à niveaux (PNxx) sont renseignés comme 
des adresses

Je viens d'en corriger sur Jouy en Josas.

J'ai mis ref:xx

xx étant le numéro du PN et j'ai supprimé les adresses inutiles.

Dans la pratique il y a des ref particulières pour ces PN? Car ce numéro est un 
ordonnancement des PN depuis le début de chaque ligne ferroviaire. Même 
principe que la numérotation des poteaux BT/HT

exemple
node 34957661

Jérôme
---
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

[OSM-talk-fr] Adresses correspondant à des passage à Niveau

[Jérôme Seigneuret]

Bonjour,

Je viens de voir que pas mal de passages à niveaux (PNxx) sont renseignés
comme des adresses

Je viens d'en corriger sur Jouy en Josas.

J'ai mis ref:xx

xx étant le numéro du PN et j'ai supprimé les adresses inutiles.

Dans la pratique il y a des ref particulières pour ces PN? Car ce numéro
est un ordonnancement des PN depuis le début de chaque ligne ferroviaire.
Même principe que la numérotation des poteaux BT/HT

exemple
node 34957661

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

[OSM-talk-fr] SOTM-Fr appel à contributions

[Louis-Julien de la Bouëre]

Bonjour,

Le site du SOTM-Fr est lancé http://sotm2019.openstreetmap.fr. Petit 
rappel ça se passe cette année à Montpellier du 14 au 16 juin.


Comme chaque année, vous pouvez intervenir en proposant des exposés, 
animations d'ateliers, tables rondes et petites conférences, expositions 
de posters, parcours de terrain, ou d’autres formats que vous pourriez 
créer...


 * 12 mars 2019 : publication de l'appel à contribution
   

 * 15 avril 2019 : clôture de l'appel à contribution

Partagez avec la communauté : ce qui a fonctionné, ce qui a raté, et vos 
projets qui mûrissent.


Allez aussi voir les personnes qui font de belles choses avec 
OpenStreetMap, pour les inciter à proposer une intervention !


*Faites directement une proposition d'intervention* 



Merci au plaisir de se revoir là-bas ou ailleurs


--
Louis-Julien de la Bouëre
Tiriad
ljbou...@tiriad.org
http://www.tiriad.org
http://carterra.net
Portable : 06 58 79 80 56
Twitter : @assotiriad
OpenStreetMap : http://hdyc.neis-one.org/?Ljbouere
Mapillary : https://www.mapillary.com/app/user/ljbouere

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

Re: [OSM-talk-fr] [OSMTracker] [Android] Restrictions/Vitesses

[Shohreh]

Je ne l'ai jamais fait, mais il semble possible de modifier la config :

https://github.com/labexp/osmtracker-android/wiki/Custom-buttons-layouts



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

[OSM-talk-fr] State of the Map France : appel à propositions !

[Donat ROBAUX]

Bonjour à tous-tes,

La 7è (septième!) conférence annuelle organisée par OpenStreetMap
France se déroulera du *14 au 16 juin à Montpellier* (34), sur le
campus de l'Université Paul Valéry.


Cette conférence est ce que nous en faisons mais aussi et surtout ce
que vous en faites ! Ce sont en effet vos propositions qui vont
permettre de construire le programme de ces 3 jours.

Petite idée ou grande révolution, solutions simples ou problèmes
récurrents, projets ou action ponctuelle ? Faites nous parvenir vos
propositions d'intervention en 5', 25', 55' voire en atelier de 2
heures ! Les posters sont aussi les bienvenus.

Pour détailler vos propositions, rendez-vous ici et *jusqu'au 15
avril*: *https://sotm2019.openstreetmap.fr/contribution.html
*

Et si vous ne savez pas quoi proposer, vous pouvez aussi suggérer ce
que vous aimeriez suivre comme conférences. Proposez des thèmes : la
seule condition est qu'on y parle d'OpenStreetMap !

Pour ces suggestions ou toute autre question, une seule adresse : sotm
[at] openstreetmap.fr


Les inscriptions seront ouvertes dans peu de temps. Tenez-vous prêts-es!


Donat pour l'équipe d'organisation
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le Santerre

[Florimond Berthoux]

place=region semble être très utilisé en Irlande
http://overpass-turbo.eu/s/H6k

Mais bon, j'ai plutôt l'impression qu'il y a la quelque chose à inventer.
Modéliser une région naturelle/culturelle (non administrative) avec
frontière possiblement flou.

Le lun. 18 mars 2019 à 09:39, Dominique Rousseau  a
écrit :

> Le Sun, Mar 17, 2019 at 07:47:05PM +, marc marc [
> marc_marc_...@hotmail.com] a écrit:
> > place=county semble être un niveau hierarchique (les régions
> > administrative en France)
> >
> > je partirais sur place=region
>
> Bof.
>
> « This is a tag from the earliest days of OpenStreetMap, is used in
> various way, was never clearly defined and is rarely used by data
> consumers.  »
>
> https://wiki.openstreetmap.org/wiki/Tag:place%3Dregion
>
>
> En français, (en tout cas en Picardie ;-) on utiliserait « pays » (dans
> son sens "micro-région"[1])
>
>
> [1] https://fr.wikipedia.org/wiki/Pays#Micro-r%C3%A9gion
>
>
> --
> Dominique Rousseau
> d...@lee-loo.net - 06 82 43 12 27
>
> A l'instant où l'esclave décide qu'il ne sera plus esclave,
> ses chaînes tombent.  -- Mahatma Gandhi
>
> ___
> 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] On y parle de carto... future (SAUV Life)

[marc marc]

Le 18.03.19 à 09:12, Romain MEHUT a écrit :
> Jacques Lavignotte wrote
>> J'ai l'appli depuis 6 mois, et elle demande aux utilisateurs de
>> répertorier et localiser les DAE dans leur voisinage. ChristanQuest sur
>> le Twitter et moi même par SMS leur avons signalé la base des DAE sur
>> OSM, sans réaction.
> 
> Sinon, il y a aussi AEDMAP (StayingAlive et BonSamaritain) avec une réaction
> ici : https://twitter.com/aedmap/status/1103647738753892352 comme
> d'habitude, la question de la licence...

3 bases de données différente, carton rouge de l'inefficacité.
allez petit peuple, contribuez à ce combat d'égo...
c'est pas comme si on parlait de sauver des vies, ça c'est accessoire.

la plus grande utilité que je vois à ces 2 autres bases c'est de repérer
les manques d'osm pour aller sur place les ajouter dans osm.
ceci dit osm est bien "en retard" sur la problématique. que 5k en France
il y a de l'opendata imposé pour les installateurs ou collectivités ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le Santerre

[Dominique Rousseau]

Le Sun, Mar 17, 2019 at 07:47:05PM +, marc marc [marc_marc_...@hotmail.com] 
a écrit:
> place=county semble être un niveau hierarchique (les régions 
> administrative en France)
> 
> je partirais sur place=region

Bof.

« This is a tag from the earliest days of OpenStreetMap, is used in
various way, was never clearly defined and is rarely used by data
consumers.  »

https://wiki.openstreetmap.org/wiki/Tag:place%3Dregion


En français, (en tout cas en Picardie ;-) on utiliserait « pays » (dans
son sens "micro-région"[1])


[1] https://fr.wikipedia.org/wiki/Pays#Micro-r%C3%A9gion


-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] On y parle de carto... future (SAUV Life)

[Romain MEHUT]

Jacques Lavignotte wrote
> J'ai l'appli depuis 6 mois, et elle demande aux utilisateurs de 
> répertorier et localiser les DAE dans leur voisinage. ChristanQuest sur 
> le Twitter et moi même par SMS leur avons signalé la base des DAE sur 
> OSM, sans réaction.

Sinon, il y a aussi AEDMAP (StayingAlive et BonSamaritain) avec une réaction
ici : https://twitter.com/aedmap/status/1103647738753892352 comme
d'habitude, la question de la licence...


Jacques Lavignotte wrote
> A coté de SauvLife poussée par les SAMU les Pompiers organisent « Permis 
> de Sauver » et eux s'appuient sur OSM. Ca a déjà été évoqué ici.
> 
> Il y nettement concurrence entre eux sur ce sujet. Y compris sur un mêm 
> département.

Par chez moi, les pompiers font la promotion de StayingAlive et
BonSamaritain cf. https://twitter.com/SDIS54/status/1106859330597519362

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] Tuiles cadatsre sans réponse sur JOSM

[Cyrille37 OSM]

Merci !!

Le 18/03/2019 à 00:13, Vincent Privat a écrit :

Hello,
Le problème vient d'être corrigé: 
https://github.com/osm-fr/infrastructure/issues/99#issuecomment-473724712

Plus besoin de bidouiller les options de lancement de JOSM :)

Le sam. 16 mars 2019 à 11:17, Vincent Privat > a écrit :


Hello,
Désactiver le SNI côté JOSM est une solution de contournement
temporaire, il faudrait surtout qu'on corrige
https://github.com/osm-fr/infrastructure/issues/99 sur l'infra OSM-FR.

Le ven. 15 mars 2019 à 18:45, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Tu le lances comment ?

Si c'est via le .jnlp, tu peux ajouter le paramètre dedans.

Si c'est via le jar, tu ajoutes l'argument indiqué en lançant
la commande (typiquement dans un .bat sur PC, dans un .sh sur
Linux).

Si c'est par un exécutable, tu te ramènes au cas précédent
;-). Il y a peut-être moyen de mettre l'argument si tu crées
un raccourci.

Le 15/03/2019 à 17:37, Jérôme Seigneuret -
jerome.seigneu...@gmail.com
 a écrit :

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr
mailto:talk-fr@openstreetmap.org>> a écrit :

Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: 
unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le 
lancement de JOSM comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

___
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

___
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] On y parle de carto... future (SAUV Life)

[Jacques Lavignotte]

Le 18/03/2019 à 00:20, marc marc a écrit :

Le 17.03.19 à 20:46, Jacques Lavignotte a écrit :

Poitiers : SAUV Life, une application pour les citoyens sauveteurs

   « Une cartographie des défibrillateurs est intégrée à l’application.
On va avoir un vrai maillage. »

https://www.lanouvellerepublique.fr/vienne/poitiers-sauv-life-une-application-pour-les-citoyens-sauveteurs




la position des défibrillateurs est une Xieme base de donnée ou c'est
les infos d'osm ?


J'ai l'appli depuis 6 mois, et elle demande aux utilisateurs de 
répertorier et localiser les DAE dans leur voisinage. ChristanQuest sur 
le Twitter et moi même par SMS leur avons signalé la base des DAE sur 
OSM, sans réaction.


A coté de SauvLife poussée par les SAMU les Pompiers organisent « Permis 
de Sauver » et eux s'appuient sur OSM. Ca a déjà été évoqué ici.


Il y nettement concurrence entre eux sur ce sujet. Y compris sur un mêm 
département.


J.

--
GnuPg : C8F5B1E3 Because privacy matters.


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

[OSM-talk-fr] Luftdaten: projet de science participative

[PIERRE Sylvain via Talk-fr]

Peut-être avez-vous déjà entendu parler du projet de science participative et 
citoyenne Luftdaten…

Pics de pollution, alertes aux particules fines… Dans les grandes villes (ou  
ailleurs), les valeurs limites et les seuils d’alerte sont souvent dépassés. 
Comment peut-on mesurer et interpréter la qualité de l’air?

Pour répondre à cette question le OK Lab Stuttgart a mis en œuvre un projet 
collaboratif et citoyen de mesure des particules fines :
https://luftdaten.info/fr/accueil/

En résumé : il s’agit de construire soit-même un détecteur de particules qui 
alimentera une base de données qui peut être visualisées ici (très bel accès 
aux données avec un fond OSM) :
https://france.maps.luftdaten.info/#7/48.673/9.437
Le projet commence à se développer en France. La documentation est très bien 
faite. L’investissement est réduit à quelques dizaines d’euros pour le 
matériel. C’est ludique, contributif.
Quelques liens supplémentaires :
http://www.wiki-rennes.fr/images/c/ca/Notice_composants.pdf

http://www.wiki-rennes.fr/Capteurs_Luftdaten
https://fabmanager.csc49.fr/#!/projects/capteur-de-micro-particules-luftdaten-avec-abris-pour-l-ademe

→  Sylvain PIERRE
 Chef de projet système d’information
 Direction des Systèmes d’Information
 Service Projets et Applications Numériques
   Conseil Départemental du Bas-Rhin

[cid:image003.jpg@01D4DD66.1EFE6C20]

 Hôtel du Département
 1 place du Quartier Blanc 67964 Strasbourg Cedex 9
 Tél : 03 88 76 68 88 - mobile :
 Mobile : 06 30 96 31 76
 Email : sylvain.pie...@bas-rhin.fr
 www.bas-rhin.fr


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

Re: [OSM-talk-fr] Vidéosurveillance

[Shohreh]

marc marc wrote
> pour une ville de taille réduite, cela semble réaliste de faire une 
> carto "mappons les dépenses inutiles" [1] afin d'avoir une idée du nombre
> 
> [1] pour ceux qui ne savent pas, les caméras ne sont pas diminuer la
> criminalité, elles la déplacent

J'ai surtout beoin de savoir /où/ se trouvent ces caméras.

Donc, légalement, la mairie n'a pas obligation de révéler leur emplacement ?



--
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] Tuiles cadatsre sans réponse sur JOSM

[Jozeph via Talk-fr]

Super ! Merci, c'est reparti ...

Bonne journée

Joseph




Le 18/03/2019 à 00:13, Vincent Privat a écrit :

Hello,
Le problème vient d'être corrigé: 
https://github.com/osm-fr/infrastructure/issues/99#issuecomment-473724712

Plus besoin de bidouiller les options de lancement de JOSM :)

Le sam. 16 mars 2019 à 11:17, Vincent Privat > a écrit :


Hello,
Désactiver le SNI côté JOSM est une solution de contournement
temporaire, il faudrait surtout qu'on corrige
https://github.com/osm-fr/infrastructure/issues/99 sur l'infra OSM-FR.

Le ven. 15 mars 2019 à 18:45, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Tu le lances comment ?

Si c'est via le .jnlp, tu peux ajouter le paramètre dedans.

Si c'est via le jar, tu ajoutes l'argument indiqué en lançant
la commande (typiquement dans un .bat sur PC, dans un .sh sur
Linux).

Si c'est par un exécutable, tu te ramènes au cas précédent
;-). Il y a peut-être moyen de mettre l'argument si tu crées
un raccourci.

Le 15/03/2019 à 17:37, Jérôme Seigneuret -
jerome.seigneu...@gmail.com
 a écrit :

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr
mailto:talk-fr@openstreetmap.org>> a écrit :

Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: 
unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le 
lancement de JOSM comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

___
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

___
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