Re: [OSM-talk-fr] Problème de langue

[Damouns]

Moi je suis assez d'accord avec Jean-Yvon : je ne vois pas l'intérêt du
name= dans le cas d'un objet international comme ça. A la limite je verrais
bien des name:fr=, name:de=... mais pas de name= car en plus il est
redondant avec le ref.


Damouns

Le 26 janvier 2016 à 07:33, Dominique Faure  a
écrit :

> Donc si je résume par rapport à mon propos initial, il faudrait finir par
> avoir:
> => Une relation "name=European route 54", référençant:
> ==> 2 relations "name:fr=Route européenne 54" et "name:de=Europastraße 54"
> pour chaque portion nationale, référençant:
> ===> p segments élémentaires existants, nommés ou non suivant le cas.
>
> C'est ça?
> J'ai regardé un peu alentour, il semblerait que la route E60 présente déjà
> une structure similaire. Faut-il se caler dessus?
> Enfin, la question qui fâche, qui fait la modif? :)
>
>
> 2016-01-26 0:49 GMT+01:00 Philippe Verdy :
>
>>
>>
>> Le 25 janvier 2016 à 22:41, Jérôme Seigneuret 
>> a écrit :
>>
>>> Bonjour,
>>>
>>> J'appui Jean-Yvon pour le name
>>>
>>> Coté relation David à raison sur le fait de gérer des relations avec des
>>> niveaux multiples ce qui permet d'importer des portions ou de gérer des
>>> itinéraires logiques par étapes avec les différents niveau (local,
>>> régional, national...) d'où l'utilisation du name anglais sur une
>>> super-relation (en Europe quand ça traverse les frontières)
>>>
>>> Pour le check d'OSM c'est pas trivial sur le test du nom.
>>>
>>> Je reprends le cas de Philippe
>>> *Noms dans la langue locale et dans la langue par défaut différents*
>>> *way 83115947 *
>>> rawedit  josm
>>>  edit
>>> 
>>> *highway* = living_street
>>> *maxspeed* = 20
>>> *name* = Chemin des Bauches
>>> *name:fr* = Lotissement le Manoir
>>>
>>> Là on n'est vraiment pas sur une question de langue mais sur une
>>> incohérence de nom. C'est pas la traduction qui est testé mais juste une
>>> correspondance entre le territoire le name:[langue] et le name
>>>
>>
>> Je n'ai pas dit le contraire, seulement ton débat concernant le
>> territoire est hors sujet mais c'est pourtant le même test qui est fait :
>> trouver une correspondance entre un name:lang=* et le name=* Et Là Osmose
>> ne teste pas tous les name:lang=* mais se limite à chercher le name sur un
>> seul noeud pour lequel il détermine quelle devrait être "la" langue locale
>> et signale ensuite l'erreur sur la relation entière puisque alors le name=*
>> par défaut n'a pas la valeur du name:fr... Même si le noeud n'a qu'une
>> langue locale, ce n'est celle de la relation entière, hors le résultat
>> s'affiche pour la relation entière ou le chemin ou polygone entier. C'est
>> ça qui est défectueux: déterminer la langue locale d'une relation sur un
>> seul de ses noeuds (choisi en fait arbitrairement) ne peut pas marcher du
>> tout et donnera des résultats faux si l'objet n'est pas tout entier dans un
>> territoire linguistique unique (dans ce seul cas le noeud choisi
>> arbitrairement marchera puisqu'il fait partie de l'objet entièrement
>> contenu dans la même zone linguistique).
>>
>> Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
>> lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
>> sauf que la rue entière est dans le même territoire que le noeud choisi sur
>> ce chemin. Mais ça marche seulement à moitié.
>>
>> Je maintiens donc ce que je disais :
>>
>> - pas besoin de déterminer une langue locale (s'il y en a une malgré
>> tout, il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
>> langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
>> name=* qui peut rester différente (exemple courant : les noms par défaut en
>> Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
>> locale est le chinois ou l'arabe, mais il faudrait autant que possible
>> libeller précisément ce nom anglais aussi avec name:en=*)
>>
>> -  dans les pays ou régions officiellement multilingues on ne peut pas
>> déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
>> (pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
>> serait en fait une approximation grossière et que le nom romanisé serait en
>> fait issu d'une transliteration latine officielle telle que le romaji
>> japonais, ou les transliterations officielles ou universitaires du chinois
>> ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
>> et dans les échanges cartographiques internationaux, ou les
>> transliterations des organisemes internationaux pour l'aviation ou la
>> navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
>> dans les langues officielles mais il reste alors le choix du nom "par
>> défaut" qui 

Re: [OSM-talk-fr] Problème de langue

[Dominique Faure]

Donc si je résume par rapport à mon propos initial, il faudrait finir par
avoir:
=> Une relation "name=European route 54", référençant:
==> 2 relations "name:fr=Route européenne 54" et "name:de=Europastraße 54"
pour chaque portion nationale, référençant:
===> p segments élémentaires existants, nommés ou non suivant le cas.

C'est ça?
J'ai regardé un peu alentour, il semblerait que la route E60 présente déjà
une structure similaire. Faut-il se caler dessus?
Enfin, la question qui fâche, qui fait la modif? :)


2016-01-26 0:49 GMT+01:00 Philippe Verdy :

>
>
> Le 25 janvier 2016 à 22:41, Jérôme Seigneuret 
> a écrit :
>
>> Bonjour,
>>
>> J'appui Jean-Yvon pour le name
>>
>> Coté relation David à raison sur le fait de gérer des relations avec des
>> niveaux multiples ce qui permet d'importer des portions ou de gérer des
>> itinéraires logiques par étapes avec les différents niveau (local,
>> régional, national...) d'où l'utilisation du name anglais sur une
>> super-relation (en Europe quand ça traverse les frontières)
>>
>> Pour le check d'OSM c'est pas trivial sur le test du nom.
>>
>> Je reprends le cas de Philippe
>> *Noms dans la langue locale et dans la langue par défaut différents*
>> *way 83115947 * rawedit
>>  josm
>>  edit
>> 
>> *highway* = living_street
>> *maxspeed* = 20
>> *name* = Chemin des Bauches
>> *name:fr* = Lotissement le Manoir
>>
>> Là on n'est vraiment pas sur une question de langue mais sur une
>> incohérence de nom. C'est pas la traduction qui est testé mais juste une
>> correspondance entre le territoire le name:[langue] et le name
>>
>
> Je n'ai pas dit le contraire, seulement ton débat concernant le territoire
> est hors sujet mais c'est pourtant le même test qui est fait : trouver une
> correspondance entre un name:lang=* et le name=* Et Là Osmose ne teste pas
> tous les name:lang=* mais se limite à chercher le name sur un seul noeud
> pour lequel il détermine quelle devrait être "la" langue locale et signale
> ensuite l'erreur sur la relation entière puisque alors le name=* par défaut
> n'a pas la valeur du name:fr... Même si le noeud n'a qu'une langue locale,
> ce n'est celle de la relation entière, hors le résultat s'affiche pour la
> relation entière ou le chemin ou polygone entier. C'est ça qui est
> défectueux: déterminer la langue locale d'une relation sur un seul de ses
> noeuds (choisi en fait arbitrairement) ne peut pas marcher du tout et
> donnera des résultats faux si l'objet n'est pas tout entier dans un
> territoire linguistique unique (dans ce seul cas le noeud choisi
> arbitrairement marchera puisqu'il fait partie de l'objet entièrement
> contenu dans la même zone linguistique).
>
> Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
> lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
> sauf que la rue entière est dans le même territoire que le noeud choisi sur
> ce chemin. Mais ça marche seulement à moitié.
>
> Je maintiens donc ce que je disais :
>
> - pas besoin de déterminer une langue locale (s'il y en a une malgré tout,
> il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
> langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
> name=* qui peut rester différente (exemple courant : les noms par défaut en
> Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
> locale est le chinois ou l'arabe, mais il faudrait autant que possible
> libeller précisément ce nom anglais aussi avec name:en=*)
>
> -  dans les pays ou régions officiellement multilingues on ne peut pas
> déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
> (pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
> serait en fait une approximation grossière et que le nom romanisé serait en
> fait issu d'une transliteration latine officielle telle que le romaji
> japonais, ou les transliterations officielles ou universitaires du chinois
> ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
> et dans les échanges cartographiques internationaux, ou les
> transliterations des organisemes internationaux pour l'aviation ou la
> navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
> dans les langues officielles mais il reste alors le choix du nom "par
> défaut" qui devrait être comme c'est vu localement multilingue. Pour que ce
> nom par défaut corresponde à un des "name:lang=*" il suffit de l'indiquer
> aussi dans "name:mul=*", et le problème est résolu. Pas de problème ensuite
> pour n'afficher que l'anglais avec un "name:en=*" si nécessaire (notamment
> si le nom multilingue officiel utilise des écritures différentes telles que
> latin+arabe ou latin+sinogrammes).
>
> - quand le nom par 

Re: [OSM-talk-fr] wiki : page sur les frontières

[Vincent de Château-Thierry]

Bonjour,

Le 26/01/2016 03:20, Philippe Verdy a écrit :

Le 26 janvier 2016 à 02:16, Jérôme Amagat > a écrit :

C'était déjà décrit dans la page sur les boundary et d'autres
pages liées (y compris pour les EPCI)

Le 26 janvier 2016 à 01:25, Jérôme Amagat
> a écrit :

J'ai écrit une page qui liste les frontières françaises et
les tags qui vont avec :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives

il manque plein de choses encore mais je pense que ça
pourrait être pas mal d'avoir quelque chose de ce type.
comme le nouveau tag admin_type qui je crois n'apparait nul
part sur le wiki. la page n'est pas la ou elle serai le mieux.

la page :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
devrait évolué aussi et mettre en valeur le fait
qu'aujourd'hui ce qui compte c'est la creation de commune
nouvelle et la modification des communauté de communes et
autres EPCI.


Ta page est très claire. Il me semble qu'il manque le tag name pour les 
arrondissements de PLM.


Comme dit par Philippe une telle page existe déjà :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#R.C3.A9capitulatif_en_France_des_tags_selon_le_niveau_administratif

Il faudrait se servir de ta page pour rafraichir le contenu et la 
présentation de l'autre, pour au final n'avoir qu'une page. 2 pages pour 
la même info c'est à coup sûr une source de confusion sur la durée, avec 
des écarts de mise à jour et donc des contradictions.


vincent

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

Re: [OSM-talk-fr] Couverture voies et noms de voies

[Florent RICHARD]

Bonjour,

Pour le nom des voies, tu as ce site 
http://qa.poole.ch/?zoom=7=46.46741=3.77173=TFFFB0 qui 
affiche en rouge toutes les routes qui ne portent ni tag "name" ni de "ref" 
dans OSM. Il concerne toutes les voies, pas seulement les voies définies 
dans le FANTOIR.
Le rendu BANO 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#6/46.294/6.064 est 
fait pour les adresses mais il pourra t'indiquer si le nom d'une rue est 
absente d'OSM (tout ce qui est en rouge). voir la légende 
http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#L.C3.A9gende


Pour ce qui est des % par département, je ne connais pas d'outil.

Florent
-Message d'origine- 
From: Bruno

Sent: Monday, January 25, 2016 12:02 PM
To: Discussions sur OSM en français
Subject: [OSM-talk-fr] Couverture voies et noms de voies

Bonjour,

Dans le cadre d'un projet en entreprise et pour convaincre de l'utilité
d'OSM , j'aurais besoin de montrer de façon simple et visuelle la
couverture actuelle de la base OSM en ce qui concerne la voirie  et le
noms des voies , pas les adresses ni le bâti.

Un peu comme tiles et les zones à mapper mais juste le rouge et avec par
exemple un % de noms des voies par département.
http://tile.openstreetmap.fr/

Si il existe déjà quelque chose je suis preneur.

Cordialement,
Bruno.

___
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] Couverture voies et noms de voies

[Vincent de Château-Thierry]

Bonjour,

> De: "Florent RICHARD" 
> 
> Pour ce qui est des % par département, je ne connais pas d'outil.

Il y a bien ça :
http://cadastre.openstreetmap.fr/fantoir/stats_dept.html
mais ça n'a rien de visuel, juste des tableaux de chiffres. Et le niveau 
d'agrégation est la commune, même si la présentation est par département. On 
doit pouvoir simplement à partir du même matériau sortir des chiffres par 
département.
À noter spécifiquement sur NPDC les pages http://legosm.fr/bano5962/ dont 
http://legosm.fr/bano5962/tableauBord.php

vincent

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

Re: [OSM-talk-fr] Pb sur polygons.openstreetmap.fr ?

[Philippe Verdy]

normalement ce n'est pas par exclusion qu'il faut procéder mais par
inclusion : ne pas parcourir ce qu'on ne connait pas, juste ce qu'on
connait, donc juste le rôle vide par défaut (pour les membres de type way),
et les rôles "inner"/"outer" (pour les ways), "admin_centre" (pour les
noeuds : attention il est normal que certaines relations en ait deux), et
"subarea" (usage limité encore un seul trype de découpage, incompatible
avec plusierus découpages orthogonaux).
Le rôle "collection" est là en attendant de trouver mieux (j'avais pensé à
un rôle "subareas" au pluriel pour ces relations contenant des subareas
pour chaque type de découpage, plutôt qu'un type pour l'instant générique
"collection")

Noter aussi que pour certains découpages les membres "subarea" pevuent
êrtre eux-même de types différents (par exemple mélange de frontières
administrative sde niveaux différents, on a le cas en France avec les
cantons, aussi bien en ancienne et nouvelle version, car ils groupent des
communes, ou des fractions de communes, ou des communes déléguées ou des
communes associées). Les textes légaux font répférences à ces types
différents d'entités pour mentionner la composition effective d'une autre
entité plus grande ; on a le cas aussi pour les EPCI, notamment les
syndicats mixtes ; ou encore pour la Metropole du Grand Paris composée
d'une commune et d'une série d'EPT, eux-mêmes composés de communes). Comme
les découpages sont d'une grande complexité à suivre et gérer, il n'est pas
simple du tout de rétablir en se basant uniquement sur les admin_level des
ways (qui souvent sont supprimés et remplacés par d'autres qui n'ont pas
l'info) et souvent on n'a pas gardé de lien simple vezrs la source pour
revérifier.

Les découpages en "subarea" (groupés éventuellement en collections quand il
y a plusieurs découpages concurrents) sont une grande aide pour retrouver
le tout et vérifier la complétude et l'exactitude. Certes on a "
layers.openstreetmpa.fr" mais il omet de vérifier plein de choses et il ne
sait pas non plus analyser correctement les découpages politiques (cantons,
circonscriptions législatives) et n'nalyser pas non plus tout un tas
d'autres entités. Il ne sait pas plus analyser les découpages postaux, les
découpages de certains EPCI (notamment Nantes Métropole). De plus son temps
de réponse est très long pour se mettre à jour.

Enfin il y a des exceptions nombreuses au modèle hiérarchique. Un exemple:
les cantons avant 2015 sont la composante des arrondissements et des
circonscriptions législatives, mais ils ne correspondent plus aux nouveaux
cantons qui ne suivent plus les limites administratives; ces cantons sont
aussir restés formés sur des communes devenues aujourd'hui des communes
déléguées ou associées au niveau 9 et plus au niveau 8, ou qui ont fusionné
en fusion simple et sont passés en niveau 10. Quand les communes changes de
statut leur frontières sont aussi redessinées parfois et il est difficile
de suivre les modifs nécessaires sachant que d'autres entités sont
redéssinées (oui pour les EPCI mais il y a une période transitoire d'un
mois, mais non pour les cantons)


Le 19 janvier 2016 à 13:41, Jocelyn Jaubert  a
écrit :

> Bonjour,
>
> (désolé pour le retard, cet email était tombé dans ma boîte à spam :( )
>
> On Sun, Jan 03, 2016 at 03:32:54PM +0100, Antoine Riche wrote:
> > Le générateur de polygones a l'air d'avoir des soucis. sur une
> > relation qui semble correcte dans JOSM et
> > http://analyser.openstreetmap.fr/, le générateur de polygone
> > retourne une erreur. Par exemple
> > http://polygons.openstreetmap.fr/?id=4607815
>
> Je pense qu'il s'agit d'un souci avec la relation collection 4660205
> inclue par
> cette relation (le site web parcourt toutes les sous relations pour en
> sortir
> le polygone "général").
>
> On enlève déjà les roles suivants dans le parcours, peut-être qu'il
> faudrait
> rajouter "collection":
> ["subarea", "land_area", "disputed_exclave"])
>
>
> Je creuserais dans la soirée.
>
> --
> Jocelyn
>
> ___
> 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] Problème de langue

[Philippe Verdy]

En revanche Osmose a raison pour:

*Noms dans la langue locale et dans la langue par défaut différents*
*way 83115947 * rawedit
 josm
 edit

*highway* = living_street
*maxspeed* = 20
*name* = Chemin des Bauches
*name:fr* = Lotissement le Manoir
*service* = alley
*source* = cadastre-dgi-fr source : Direction Générale des Impôts -
Cadastre;mise à jour :2010
Signalement reporté le : 2016-01-25

Effectivement ce nom par défaut ne correspond pas au nom indiqué pour le
français (seule langue indiquée). Ce message est en fait trompeur car il
suppose une langue "locale" (une seule). Mais ici les deux noms sont en
français mais ne nomment pas la même chose (l'un une rue, l'autre un
lotissement autrement dit un nom approprié pour un point ou polygone
"place=*")

Le nom du lotissement est en trop et ne devrait pas être là. Le name=* est
suffisant car il n'y a pas d'autre langue que la langue par défaut (qu'il
n'est pas nécessaire de préciser comme étant "la" langue locale ni même
explicitement que c'est du français)

Autre problème avec des noms par défaut oficiellement multilingues
- Exemple name="België - Belgique - Belgien", alors qu'on a
"name:fr=Belgique", "name:nl=België", "name:de=Belgien" : la valeur par
défaut ne correspond à aucune des langues mentionnées, c'est une
concaténation des noms dans plusieurs langues avec un séparateur, Osmose ne
sait pas analyser ça, la formule est assez compliquée en fait car
combinatoire :
- l'ordre est quelconque et il y a 6 possibilités avec 3 noms,
- et les séparateurs du nom multilingue par défaut varient, selon les
endroits (exemple en Espagne entre l'espagnol castillan et le basque ou le
catalan), entre "-" ou "/" ou ";", avec ou sans espaces, voire juste une
espace comme dans les noms multilingues au Maroc en français, arabe et
tamazigh (on a aussi parfois aussi l'anglais plutôt que le français dans
les noms par défaut alors que l'anglais n'est pas officiel et pas mentionné
non plus dans "name:en=*" où il devrait être...)





Le 25 janvier 2016 à 20:04, Philippe Verdy  a écrit :

> Là Osmose a clairement tord, ce qu'il considère comme "langue locale" (et
> la seule possible) est celle au point qu'il indique alors que c'est un way
> qui couvre plusieurs pays.
>
> Cas particulier si une langue indiquée en "name:lang=*" est une langue
> régionale non officielle, et même si c'est la même valeur dans la langue
> locale officielle, il faudrait la copier aussi pour cette langue
> officielle, sinon le mécanisme de "fallback" ne fonctionne pas et risque de
> prendre l'autre valeur dans "name=*" si aucune autre name:lang=*" ne
> correspond à cetle langue officielel majeure.
>
> Exemple: "name:br=*" mentionne un nom en breton, et "name=*" donne le nom
> en anglais (cette valeur peut aussi être dans "name:en=*") qui servira
> aussi de langue par défaut pour le français, alors que même en français on
> utilise le nom breton: copier "name:br=*" dans "name:fr:*" (et alors peu
> importe si "name=*" reste la valeur en anglais, qui devrait cependant être
> aussi dans "name:en=*")
>
> Dans le cas présent, Osmose a trouvé un point situé en France et suppose
> que c'est nécessairement du français pour toute la route alors qu'elle est
> internationale et ne se limite pas à ce seul point. Osmose pourrait éviter
> son erreur en voyant qu'on a pourtant un "name:fr=*" indiqué même si elle
> est diférente de la valeur par défaut (il a déterminé pour cette route que
> ce seul point devrait avoir au moins une valeur en français, il ne dtoit
> pas conclure que c'est la seule valeur possible pour toute la route)
>
> La seule chose que devrait faire Osmose c'est vérifier que name="*"
> conrrespond à une des valeurs "name:lang=*".
> - soit il n'y a aucune "name:lang=*" alors il faut un "name=*" par défaut
> utilisable dans toutes les langues
> - soit il y a au moins une valeur "name:lang=*" alors il doit exister
> aussi une 'name=*" de même valeur que l'une QUELCONQUE (peut-être
> plusieurs, peu importe) des langues indiquées dans "name:lang=*"
>
>
> Le 25 janvier 2016 à 19:06, Gautier Pelloux-Prayer  a
> écrit :
>
>> Non, je ne crois pas :
>> http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==
>>
>> La langue anglaise est bien dans la liste, mais au moins
>> osmose.openstreetmap.fr n'est pas content. Ou alors tu parles uniquement
>> pour les highways...
>>
>>
>> Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a
>> écrit :
>>
>> Osmose est content quand au moins un des noms "name:lang=*" correspond à
>> celui indiqué dans "name=*".
>>
>> Bref renseigner un nom dans "name=*" (langue quelconque) et dans
>> "name:fr=*"
>>
>> Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
>> écrit :
>>

Re: [OSM-talk-fr] faire passer voie ferrée sur pont

[osm . sanspourriel]

Tu a aussi le droit de corriger ;-)

Le 25/01/2016 19:04, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Le 25/01/2016 18:42, lenny.libre a écrit :

josm m'envoie l'avertissement suivant :



Ce n'est qu'un avertissement. Ce n'est nullement lié à tes 
modifications de tes deux chemins, mais comme en modifiant une zone 
JOSM à téléchargé la voies ferrée, il t'annonce les avertissements de 
ce qu'il à chargé. Donc laisse JOSM te dire cela pour les voies ferrée.



Cordialement


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

Re: [OSM-talk-fr] faire passer voie ferrée sur pont

[Philippe Verdy]

Les avertissements portent sur un noeud. Un point ou un tunnel ne peut pas
être un noeud, ce doit être un segment de chemin...
Les noeuds dans les relations "route" sont pour les arrêts (stop : il faut
un rôle explicite, ne pas utiliser le rôle vide qui n'est admis en
compatibilité que pour les ways membres ; et c'esdt indépendant des
attributs du noeud lui-même qui peut ne pas avoir été chargé avec la
relation mais ce n'est pas nécessaire tant que le rôle est là et est
associé à un noeud même "incomplet").


Le 25 janvier 2016 à 19:04, David Crochet  a écrit :

> Bonjour
>
> Le 25/01/2016 18:42, lenny.libre a écrit :
>
>> josm m'envoie l'avertissement suivant :
>>
>
>
> Ce n'est qu'un avertissement. Ce n'est nullement lié à tes modifications
> de tes deux chemins, mais comme en modifiant une zone JOSM à téléchargé la
> voies ferrée, il t'annonce les avertissements de ce qu'il à chargé. Donc
> laisse JOSM te dire cela pour les voies ferrée.
>
>
> Cordialement
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de langue

[Philippe Verdy]

Là Osmose a clairement tord, ce qu'il considère comme "langue locale" (et
la seule possible) est celle au point qu'il indique alors que c'est un way
qui couvre plusieurs pays.

Cas particulier si une langue indiquée en "name:lang=*" est une langue
régionale non officielle, et même si c'est la même valeur dans la langue
locale officielle, il faudrait la copier aussi pour cette langue
officielle, sinon le mécanisme de "fallback" ne fonctionne pas et risque de
prendre l'autre valeur dans "name=*" si aucune autre name:lang=*" ne
correspond à cetle langue officielel majeure.

Exemple: "name:br=*" mentionne un nom en breton, et "name=*" donne le nom
en anglais (cette valeur peut aussi être dans "name:en=*") qui servira
aussi de langue par défaut pour le français, alors que même en français on
utilise le nom breton: copier "name:br=*" dans "name:fr:*" (et alors peu
importe si "name=*" reste la valeur en anglais, qui devrait cependant être
aussi dans "name:en=*")

Dans le cas présent, Osmose a trouvé un point situé en France et suppose
que c'est nécessairement du français pour toute la route alors qu'elle est
internationale et ne se limite pas à ce seul point. Osmose pourrait éviter
son erreur en voyant qu'on a pourtant un "name:fr=*" indiqué même si elle
est diférente de la valeur par défaut (il a déterminé pour cette route que
ce seul point devrait avoir au moins une valeur en français, il ne dtoit
pas conclure que c'est la seule valeur possible pour toute la route)

La seule chose que devrait faire Osmose c'est vérifier que name="*"
conrrespond à une des valeurs "name:lang=*".
- soit il n'y a aucune "name:lang=*" alors il faut un "name=*" par défaut
utilisable dans toutes les langues
- soit il y a au moins une valeur "name:lang=*" alors il doit exister aussi
une 'name=*" de même valeur que l'une QUELCONQUE (peut-être plusieurs, peu
importe) des langues indiquées dans "name:lang=*"


Le 25 janvier 2016 à 19:06, Gautier Pelloux-Prayer  a
écrit :

> Non, je ne crois pas :
> http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==
>
> La langue anglaise est bien dans la liste, mais au moins
> osmose.openstreetmap.fr n'est pas content. Ou alors tu parles uniquement
> pour les highways...
>
>
> Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a
> écrit :
>
> Osmose est content quand au moins un des noms "name:lang=*" correspond à
> celui indiqué dans "name=*".
>
> Bref renseigner un nom dans "name=*" (langue quelconque) et dans
> "name:fr=*"
>
> Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
> écrit :
>
>> Bonjour,
>>
>> Si cela peut aider au débat, il y a le "même" problème pour les Alpes :
>> http://www.openstreetmap.org/relation/2698607
>>
>> Osmose n'est pas content car on utilise par défaut le nom Anglais, mais
>> en même temps je vois pas de bonne solution pour qu'il le soit en l'état...
>> ? La solution de ne pas avoir de nom du tout serait pour moi la plus
>> logique, mais osmose ne sera toujours pas satisfait il me semble.
>>
>>
>> Le 25/01/2016 18:37, rainerU a écrit :
>>
>>> Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>>>
name=European route E 54

>>> Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
>>> le signalement Osmose et cela ne correspond à aucune réalité, car c'est
>>> une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
>>> anglais. La solution qui refléterait le mieux la réalité serait de ne
>>> pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
>>> faut absolument un attribut name=* il faut couper la relation en une
>>> partie française et une partie allemande et les regrouper dans une
>>> relation qui aura comme nom "Route européenne 54 / Europastraße 54".
>>>
>>> Le plus simple serait de faire comme pour d'autres routes du même type,
>>> c'est à dire de supprimer tous les attributs name. Si on veut on peut
>>> toujours construire un nom à partir des tags network et ref :
>>>
>>> https://www.openstreetmap.org/relation/2148632
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] live.openstreetmap.fr

[Laurent Combe]

oui le drapeau ce n'est pas vital mais dans l'imaginaire ça montre bien
qu'osm est international

christian : merci pour les marqueurs

Le 24 janvier 2016 à 17:55, Philippe Verdy  a écrit :

> Je veux dire que je vois la carte et les marqueurs, les noms des
> contributeurs, en revanche le drapeau du pays est juste blanc (ça n'a pas
> grande importance à mon avis, la géolocalisation des contributeurs est
> hasardeuse, intrusive si basée sur l'IP, ou souvent renseignée manuellement
> selon les zones d'intérêt du moment)
>
> Le 24 janvier 2016 à 17:22, Laurent Combe  a écrit
> :
>
>> Bonjour
>>
>> j'apprécie la page live.openstreetmap.fr
>> elle me sert quand je parle d'osm autour de moi
>>
>> par contre deux petits détails
>> les lieux de modifications ne font plus apparaitre de "marker" mais le
>> navigateur firefox affiche un symbole signifiant image non trouvée (c'est
>> moche)
>>
>> il y avait aussi un drapeau en face des contributeurs
>> maintenant les drapeaux ont disparu
>>
>> Peut-on rétablir le fonctionnement de live.openstreetmap.fr sur ces deux
>> points ?
>>
>> ___
>> 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] Problème de langue

[David Crochet]

Le 25/01/2016 19:09, David Crochet a écrit :

Bonjour

En faite il faut une relation-mère de type route, composé de
relation-filles de type route limité aux limites administratives, etc.
pour finir avec des relations de type route locales.

Cordialement



exemple : http://www.openstreetmap.org/relation/2521076 (car contre 
cette relation ne porte pas le bon nom car son nom officiel est « 
Central Europe Route » ).


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Problème de langue

[David Crochet]

Bonjour

En faite il faut une relation-mère de type route, composé de 
relation-filles de type route limité aux limites administratives, etc. 
pour finir avec des relations de type route locales.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Problème de langue

[rainerU]

Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>   name=European route E 54

Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
le signalement Osmose et cela ne correspond à aucune réalité, car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
anglais. La solution qui refléterait le mieux la réalité serait de ne
pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 54".

Le plus simple serait de faire comme pour d'autres routes du même type,
c'est à dire de supprimer tous les attributs name. Si on veut on peut
toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







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

[OSM-talk-fr] faire passer voie ferrée sur pont

[lenny.libre]

Bonjour
J'ai mis à jour deux chemins qui passent sous sous un pont emprunté par 
une voie ferrée :

http://www.openstreetmap.org/way/392570058
http://www.openstreetmap.org/way/392570064

En fait, j'ai indiqué qu'ils passaient dans un tunnel, alors qu'ils 
passent sous un pont sur lequel circulent les voies ferrées :

http://www.openstreetmap.org/way/290368896
http://www.openstreetmap.org/way/225327281
Mais lorsque j'insère des point et que je partage les chemins pour 
ajouter sur la portion bridge=yes, josm m'envoie l'avertissement suivant :




Comment faut-il faire pour créer un pont sans perturber le réseau ferré 
existant ?


merci d'avance
Lenny
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de langue

[Gautier Pelloux-Prayer]

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les Alpes : 
http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, mais 
en même temps je vois pas de bonne solution pour qu'il le soit en 
l'état... ? La solution de ne pas avoir de nom du tout serait pour moi 
la plus logique, mais osmose ne sera toujours pas satisfait il me semble.


Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54

Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
le signalement Osmose et cela ne correspond à aucune réalité, car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
anglais. La solution qui refléterait le mieux la réalité serait de ne
pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 54".

Le plus simple serait de faire comme pour d'autres routes du même type,
c'est à dire de supprimer tous les attributs name. Si on veut on peut
toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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] live.openstreetmap.fr

[Philippe Verdy]

Je pense aussi que ces drapeaux demandent des informations sur
l'utilisateur dans la base de données, et que c'est aussi une perte de
temps en requêtes, il y a bien assez de données à récupérer mais celle-là
on peut s'en passer

D'autant que ça surcharge vite le navigateur et ralentit l'affichage (quand
la page se met à jour à chaque seconde, ça fait vite des milliers de
requêtes en quelques heures). Laissez tourner le live pendant une heure et
voyez la mémoire prise par le navigateur, ça explose assez vite en version
32 bits quand l'historique est bien chargé.

De ce côté-là, il y a peut-être moyen d'optimiser la place prise pour les
objets conservés dans l'historique, quitte à recharger les détails
seulement à la demande quand on sélectionne une des modifs, et en garder le
moins posisble pour n'avoir que la liste, il suffirait de ne garder que la
le nom d'utilisateur, l'horodatage en format le plus compact possible, et
le numéro de changeset pour pouvoir réafficher les détails à la demande (y
compris l'ID d'utilisateur donnant sa géolocalisation, ou la bounding box
permettant de réafficher la carte). LE reste utilisé seulement de façon
temporaire pour n'afficher que la vue actuelle, et jeté quand on passe à la
vue suivante.

Je n'ai pas regardé dans les détails mais il semble bien que l'historique
soit moins volumineux maintenant et que ça explose moins vite en mémoire
(surtout dans un navigateur 32 bits, même sur les OS 64 bits; sur un OS 32
bits, et notamment sur pas mal de tablettes, cela explose plus vite car la
mémoire limitée est aussi à partager avec les autres onglets utilisés pour
la navigation sur d'autres sites et pour d'autres applications
concurrentes: le processus ou les processus du navigateur sont restreints,
on ne peut pas tout faire en données javascript sinon ça se met à ramer dur
malgré les efforts du garbage collector). Pour le reste même si on ne
conserve pas les données en mémoire, cela ne provoquera pas beaucoup plus
de requêtes au serveur si les données obtenues sont cachables dans le cache
disque du navigateur.

L'idéal étant de pouvoir faire tourner facilement le live pendant quelques
heures en continu, cela devrait pouvoir stocker un historique de plusieurs
milliers de lignes (changesets). Au pire, ne garder en mémoire historique
que des numéros de changeset, et uniquement en mémoire le détail des lignes
qui sont sur les lignes visibles de l'historique ou une page ou deux avant
et après (en mode pause), le reste étant fait avec des requêtes serveur via
le cache du navigateur.

Idée à creuser... Mais je pense que l'auteur de l'outil a dû déjà chercher
car ça s'est amélioré.



Le 25 janvier 2016 à 16:52, Laurent Combe  a écrit :

> oui le drapeau ce n'est pas vital mais dans l'imaginaire ça montre bien
> qu'osm est international
>
> christian : merci pour les marqueurs
>
> Le 24 janvier 2016 à 17:55, Philippe Verdy  a écrit :
>
>> Je veux dire que je vois la carte et les marqueurs, les noms des
>> contributeurs, en revanche le drapeau du pays est juste blanc (ça n'a pas
>> grande importance à mon avis, la géolocalisation des contributeurs est
>> hasardeuse, intrusive si basée sur l'IP, ou souvent renseignée manuellement
>> selon les zones d'intérêt du moment)
>>
>> Le 24 janvier 2016 à 17:22, Laurent Combe  a
>> écrit :
>>
>>> Bonjour
>>>
>>> j'apprécie la page live.openstreetmap.fr
>>> elle me sert quand je parle d'osm autour de moi
>>>
>>> par contre deux petits détails
>>> les lieux de modifications ne font plus apparaitre de "marker" mais le
>>> navigateur firefox affiche un symbole signifiant image non trouvée (c'est
>>> moche)
>>>
>>> il y avait aussi un drapeau en face des contributeurs
>>> maintenant les drapeaux ont disparu
>>>
>>> Peut-on rétablir le fonctionnement de live.openstreetmap.fr sur ces
>>> deux points ?
>>>
>>> ___
>>> 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] Problème de langue

[Gautier Pelloux-Prayer]

Non, je ne crois pas : 
http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==


La langue anglaise est bien dans la liste, mais au moins 
osmose.openstreetmap.fr n'est pas content. Ou alors tu parles 
uniquement pour les highways...



Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a 
écrit :
Osmose est content quand au moins un des noms "name:lang=*" 
correspond à celui indiqué dans "name=*".


Bref renseigner un nom dans "name=*" (langue quelconque) et dans 
"name:fr=*"


Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer 
 a écrit :

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les 
Alpes : http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, 
mais en même temps je vois pas de bonne solution pour qu'il le soit 
en l'état... ? La solution de ne pas avoir de nom du tout serait 
pour moi la plus logique, mais osmose ne sera toujours pas satisfait 
il me semble.



Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54
Pour moi, ce n'est pas la bonne solution. Cela ne fera pas 
disparaître
le signalement Osmose et cela ne correspond à aucune réalité, 
car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas 
de nom
anglais. La solution qui refléterait le mieux la réalité serait 
de ne

pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 
54".


Le plus simple serait de faire comme pour d'autres routes du même 
type,
c'est à dire de supprimer tous les attributs name. Si on veut on 
peut

toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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] Problème de langue

[Philippe Verdy]

Osmose est content quand au moins un des noms "name:lang=*" correspond à
celui indiqué dans "name=*".

Bref renseigner un nom dans "name=*" (langue quelconque) et dans "name:fr=*"

Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
écrit :

> Bonjour,
>
> Si cela peut aider au débat, il y a le "même" problème pour les Alpes :
> http://www.openstreetmap.org/relation/2698607
>
> Osmose n'est pas content car on utilise par défaut le nom Anglais, mais en
> même temps je vois pas de bonne solution pour qu'il le soit en l'état... ?
> La solution de ne pas avoir de nom du tout serait pour moi la plus logique,
> mais osmose ne sera toujours pas satisfait il me semble.
>
>
> Le 25/01/2016 18:37, rainerU a écrit :
>
>> Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>>
>>>name=European route E 54
>>>
>> Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
>> le signalement Osmose et cela ne correspond à aucune réalité, car c'est
>> une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
>> anglais. La solution qui refléterait le mieux la réalité serait de ne
>> pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
>> faut absolument un attribut name=* il faut couper la relation en une
>> partie française et une partie allemande et les regrouper dans une
>> relation qui aura comme nom "Route européenne 54 / Europastraße 54".
>>
>> Le plus simple serait de faire comme pour d'autres routes du même type,
>> c'est à dire de supprimer tous les attributs name. Si on veut on peut
>> toujours construire un nom à partir des tags network et ref :
>>
>> https://www.openstreetmap.org/relation/2148632
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] faire passer voie ferrée sur pont

[David Crochet]

Bonjour

Le 25/01/2016 18:42, lenny.libre a écrit :

josm m'envoie l'avertissement suivant :



Ce n'est qu'un avertissement. Ce n'est nullement lié à tes modifications 
de tes deux chemins, mais comme en modifiant une zone JOSM à téléchargé 
la voies ferrée, il t'annonce les avertissements de ce qu'il à chargé. 
Donc laisse JOSM te dire cela pour les voies ferrée.



Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] Problème de langue

[Jérôme Seigneuret]

Bonjour,

J'appui Jean-Yvon pour le name

Coté relation David à raison sur le fait de gérer des relations avec des
niveaux multiples ce qui permet d'importer des portions ou de gérer des
itinéraires logiques par étapes avec les différents niveau (local,
régional, national...) d'où l'utilisation du name anglais sur une
super-relation (en Europe quand ça traverse les frontières)

Pour le check d'OSM c'est pas trivial sur le test du nom.

Je reprends le cas de Philippe
*Noms dans la langue locale et dans la langue par défaut différents*
*way 83115947 * rawedit
 josm
 edit

*highway* = living_street
*maxspeed* = 20
*name* = Chemin des Bauches
*name:fr* = Lotissement le Manoir

Là on n'est vraiment pas sur une question de langue mais sur une
incohérence de nom. C'est pas la traduction qui est testé mais juste une
correspondance entre le territoire le name:[langue] et le name

Le name ne donne pas d'information sur le territoire, hors la notion de
territoire est multi-échelle, multi-zonales comme celle des langues et ça
sans forcément de chevauchement. Si l'on prends la zone euro il n'y a pas
de langue officielle donc par défaut on prend la langue internationale qui
est l'anglais faute de mieux car l'espéranto n'a jamais percé.

Quand un objet se limite à un pays on prend en name sa langue officielle.
Quand l'objet traverse les territoires comme c'est le cas de certaines
relations, découper la relation pour avoir un affichage correspondant au
contexte du pays concerné et une au contexte global.

Jérôme



Le 25 janvier 2016 à 21:42,  a écrit :

> Quitte à remettre une couche : je ne suis pas un fana des duplications
> d'informations qui sont déjà là.
> Le E de E 54 veut dire route Européenne, European route, Europastrasse,...
> et a priori seule la référence figure sur le terrain :
> 
> https://fr.wikipedia.org/wiki/Route_europ%C3%A9enne_50#/media/File:RouteE50.JPG
>
> Il n'apporte donc rien. D'autant que le Wikidata donne les infos
> complémentaires si besoin (peut-être qu'Omose pourrait regarder la
> cohérence avec les Wikidata).
> On ne met pas non plus "route Nationale 19" pour la N19.
> Si on prend les EuroVélo, il est remarquable que sur le site ils utilisent
> par exemple EuroVelo 4.
>
> Plus important : la relation est cassée (en plusieurs morceaux) :
> 
> http://www.openstreetmap.org/relation/77040#map=17/47.63617/6.83655
>
> Pour ref=N 19, on ne met pas Route nationale non plus.
> Heu, a priori Christian a trouvé un endroit ou la N19 s'appelle Route
> nationale 19 : 
> http://www.openstreetmap.org/way/22729626.
> Mais est-utilisé sur le terrain ? Je vois un arrêt de bus "Santeny RN".
>
> Jean-Yvon
>
>
> Le 25/01/2016 13:04, Dominique Faure - dominique.fa...@gmail.com a écrit :
>
> Ok, j'ai renommé le trajet en anglais:
>
>   name=European route E 54
>
> et profité pour corriger quelques sens de circulation.
>
> Merci.
>
>
>
> 2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret :
>
>> Bonjour,
>>
>> J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
>> de modification. A moins de mettre le tag name en Anglais...
>>
>> Car cette alerte est à mon avis seulement valable pour les objets (node,
>> way, relation) se limitant à un territoire dont la langue est identifié
>> dans notre cas fr et non à des superpostion entre territoires
>>
>> Dans ton cas, la relation dépasse les frontières. Donc que choisir dans
>> ce cas... Le name en Anglais, le name du pays de départ (qui soit disant
>> passant est différent suivant le sens).
>>
>> J'aurais choisi un nom FR pour les tronçons en France un nom Allemand
>> pour les tronçons Allemand et pour la relation (Euro), le nom en anglais et
>> name:fr=* name:de=*
>>
>> le name:fr permet de toute manière de trouver cette relation dans
>> Nominatim
>>
>> Jérôme
>>
>> Le 25 janvier 2016 à 10:40, Dominique Faure < 
>> dominique.fa...@gmail.com> a écrit :
>>
>>> Bonjour,
>>>
>>> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
>>> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
>>> je sèche un peu...
>>>
>>> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
>>> lui redonner son nom et y rattacher quelques bâtiments dans une relation
>>> associatedStreet.
>>>
>>> Depuis cette modification, j'ai ce message d'erreur dans osmose (
>>> 
>>> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>>>
>>> =8<- - - - -
>>> Noms dans la langue locale et dans la langue par défaut 

Re: [OSM-talk-fr] Problème de langue

[osm . sanspourriel]

Quitte à remettre une couche : je ne suis pas un fana des duplications 
d'informations qui sont déjà là.
Le E de E 54 veut dire route Européenne, European route, 
Europastrasse,... et a priori seule la référence figure sur le terrain : 
https://fr.wikipedia.org/wiki/Route_europ%C3%A9enne_50#/media/File:RouteE50.JPG


Il n'apporte donc rien. D'autant que le Wikidata donne les infos 
complémentaires si besoin (peut-être qu'Omose pourrait regarder la 
cohérence avec les Wikidata).

On ne met pas non plus "route Nationale 19" pour la N19.
Si on prend les EuroVélo, il est remarquable que sur le site ils 
utilisent par exemple EuroVelo 4.


Plus important : la relation est cassée (en plusieurs morceaux) :
http://www.openstreetmap.org/relation/77040#map=17/47.63617/6.83655

Pour ref=N 19, on ne met pas Route nationale non plus.
Heu, a priori Christian a trouvé un endroit ou la N19 s'appelle Route 
nationale 19 : http://www.openstreetmap.org/way/22729626. 


Mais est-utilisé sur le terrain ? Je vois un arrêt de bus "Santeny RN".

Jean-Yvon

Le 25/01/2016 13:04, Dominique Faure - dominique.fa...@gmail.com a écrit :

Ok, j'ai renommé le trajet en anglais:

  name=European route E 54

et profité pour corriger quelques sens de circulation.

Merci.



2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret >:


Bonjour,

J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai
pas fait de modification. A moins de mettre le tag name en Anglais...

Car cette alerte est à mon avis seulement valable pour les objets
(node, way, relation) se limitant à un territoire dont la langue
est identifié dans notre cas fr et non à des superpostion entre
territoires

Dans ton cas, la relation dépasse les frontières. Donc que choisir
dans ce cas... Le name en Anglais, le name du pays de départ (qui
soit disant passant est différent suivant le sens).

J'aurais choisi un nom FR pour les tronçons en France un nom
Allemand pour les tronçons Allemand et pour la relation (Euro), le
nom en anglais et name:fr=* name:de=*

le name:fr permet de toute manière de trouver cette relation dans
Nominatim

Jérôme

Le 25 janvier 2016 à 10:40, Dominique Faure
> a
écrit :

Bonjour,

"Jeune" contributeur d'OSM pour son quartier et alentours,
j'ai pu me débrouiller par mes propres moyens jusqu'à
maintenant, mais là, j'avoue que je sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de
commune) pour lui redonner son nom et y rattacher quelques
bâtiments dans une relation associatedStreet.

Depuis cette modification, j'ai ce message d'erreur dans
osmose (http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -

​ A noter que ma modification à eu lieu ici:
http://www.openstreetmap.org/way/391928538


Merci d'avance pour vos éclaircissements.
-- 
Dominique


___
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




--
Dominique


___
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] Problème de langue

[osm . sanspourriel]

Un autre intérêt d'avoir plusieurs niveaux dans les relations c'est de 
limiter les risques de trous.
Si la zone est suffisamment petite il y a des chances que les 
contributeurs chargent toute la relation et voient donc si elle est cassée.
Si on oublie un pays par exemple sur une route européenne, ça se verra 
facilement.
De plus si quelqu'un casse une relation la restaurer sera plus simple 
par un contributeur ordinaire.


Jean-Yvon


Le 25/01/2016 22:41, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit :

Bonjour,

J'appui Jean-Yvon pour le name

Coté relation David à raison sur le fait de gérer des relations avec 
des niveaux multiples ce qui permet d'importer des portions ou de 
gérer des itinéraires logiques par étapes avec les différents niveau 
(local, régional, national...) d'où l'utilisation du name anglais sur 
une super-relation (en Europe quand ça traverse les frontières)


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

Re: [OSM-talk-fr] Problème de langue

[Philippe Verdy]

Le 25 janvier 2016 à 22:41, Jérôme Seigneuret  a
écrit :

> Bonjour,
>
> J'appui Jean-Yvon pour le name
>
> Coté relation David à raison sur le fait de gérer des relations avec des
> niveaux multiples ce qui permet d'importer des portions ou de gérer des
> itinéraires logiques par étapes avec les différents niveau (local,
> régional, national...) d'où l'utilisation du name anglais sur une
> super-relation (en Europe quand ça traverse les frontières)
>
> Pour le check d'OSM c'est pas trivial sur le test du nom.
>
> Je reprends le cas de Philippe
> *Noms dans la langue locale et dans la langue par défaut différents*
> *way 83115947 * rawedit
>  josm
>  edit
> 
> *highway* = living_street
> *maxspeed* = 20
> *name* = Chemin des Bauches
> *name:fr* = Lotissement le Manoir
>
> Là on n'est vraiment pas sur une question de langue mais sur une
> incohérence de nom. C'est pas la traduction qui est testé mais juste une
> correspondance entre le territoire le name:[langue] et le name
>

Je n'ai pas dit le contraire, seulement ton débat concernant le territoire
est hors sujet mais c'est pourtant le même test qui est fait : trouver une
correspondance entre un name:lang=* et le name=* Et Là Osmose ne teste pas
tous les name:lang=* mais se limite à chercher le name sur un seul noeud
pour lequel il détermine quelle devrait être "la" langue locale et signale
ensuite l'erreur sur la relation entière puisque alors le name=* par défaut
n'a pas la valeur du name:fr... Même si le noeud n'a qu'une langue locale,
ce n'est celle de la relation entière, hors le résultat s'affiche pour la
relation entière ou le chemin ou polygone entier. C'est ça qui est
défectueux: déterminer la langue locale d'une relation sur un seul de ses
noeuds (choisi en fait arbitrairement) ne peut pas marcher du tout et
donnera des résultats faux si l'objet n'est pas tout entier dans un
territoire linguistique unique (dans ce seul cas le noeud choisi
arbitrairement marchera puisqu'il fait partie de l'objet entièrement
contenu dans la même zone linguistique).

Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
sauf que la rue entière est dans le même territoire que le noeud choisi sur
ce chemin. Mais ça marche seulement à moitié.

Je maintiens donc ce que je disais :

- pas besoin de déterminer une langue locale (s'il y en a une malgré tout,
il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
name=* qui peut rester différente (exemple courant : les noms par défaut en
Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
locale est le chinois ou l'arabe, mais il faudrait autant que possible
libeller précisément ce nom anglais aussi avec name:en=*)

-  dans les pays ou régions officiellement multilingues on ne peut pas
déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
(pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
serait en fait une approximation grossière et que le nom romanisé serait en
fait issu d'une transliteration latine officielle telle que le romaji
japonais, ou les transliterations officielles ou universitaires du chinois
ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
et dans les échanges cartographiques internationaux, ou les
transliterations des organisemes internationaux pour l'aviation ou la
navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
dans les langues officielles mais il reste alors le choix du nom "par
défaut" qui devrait être comme c'est vu localement multilingue. Pour que ce
nom par défaut corresponde à un des "name:lang=*" il suffit de l'indiquer
aussi dans "name:mul=*", et le problème est résolu. Pas de problème ensuite
pour n'afficher que l'anglais avec un "name:en=*" si nécessaire (notamment
si le nom multilingue officiel utilise des écritures différentes telles que
latin+arabe ou latin+sinogrammes).

- quand le nom par défaut est une romanisation adaptée à l'usage
international (BPCN, aviation civile, etc.), là on a un "int_name=*" qui
n'est pas non plus forcément le nom anglais ! C'est une (pseudo-)langue à
part (qui n'est ni "name:mul=*", ni "name:en=*"), à usage technique
spécialisé (équivalent à un "name:int=*") pour un certain nombre de normes
de toponymie (ces normes utilisent plus de diacritiques que l'anglais,
exemple avec les noms japonais en internationalisés en romaji, avec les
macrons sur les voyelles longues, autres exemples avec la romanisation du
russe, autre exemple avec la romanisation du serbe dont il existe une
transcription latine officielle avec des haceks et carons, alors que
l'anglais les 

Re: [OSM-talk-fr] wiki : page sur les frontières

[Philippe Verdy]

C'était déjà décrit dans la page sur les boundary et d'autres pages liées
(y compris pour les EPCI)

Le 26 janvier 2016 à 01:25, Jérôme Amagat  a écrit
:

> J'ai écrit une page qui liste les frontières françaises et les tags qui
> vont avec :
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives
>
> il manque plein de choses encore mais je pense que ça pourrait être pas
> mal d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui
> je crois n'apparait nul part sur le wiki. la page n'est pas la ou elle
> serai le mieux.
>
> la page :
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
> devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
> compte c'est la creation de commune nouvelle et la modification des
> communauté de communes et autres EPCI.
>
> ___
> 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] wiki : page sur les frontières

[Jérôme Amagat]

tous les tags sont décrit ailleurs (sauf peut être admin_type) c'est vrai,
cette page resume ce qui est fait pour la france.
Et la page sur les epci c'est celle la :
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlocal_authority
c'est con ca parle que de la france et c'est qu'en anglais.

Le 26 janvier 2016 à 01:45, Philippe Verdy  a écrit :

> C'était déjà décrit dans la page sur les boundary et d'autres pages liées
> (y compris pour les EPCI)
>
> Le 26 janvier 2016 à 01:25, Jérôme Amagat  a
> écrit :
>
>> J'ai écrit une page qui liste les frontières françaises et les tags qui
>> vont avec :
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives
>>
>> il manque plein de choses encore mais je pense que ça pourrait être pas
>> mal d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui
>> je crois n'apparait nul part sur le wiki. la page n'est pas la ou elle
>> serai le mieux.
>>
>> la page :
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
>> devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
>> compte c'est la creation de commune nouvelle et la modification des
>> communauté de communes et autres EPCI.
>>
>> ___
>> 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] wiki : page sur les frontières

[Jérôme Amagat]

J'ai écrit une page qui liste les frontières françaises et les tags qui
vont avec :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives

il manque plein de choses encore mais je pense que ça pourrait être pas mal
d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui je
crois n'apparait nul part sur le wiki. la page n'est pas la ou elle serai
le mieux.

la page :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
compte c'est la creation de commune nouvelle et la modification des
communauté de communes et autres EPCI.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème de langue

[Dominique Faure]

Bonjour,

"Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
je sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
lui redonner son nom et y rattacher quelques bâtiments dans une relation
associatedStreet.

Depuis cette modification, j'ai ce message d'erreur dans osmose (
http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -

​A noter que ma modification à eu lieu ici:
http://www.openstreetmap.org/way/391928538


Merci d'avance pour vos éclaircissements.
-- 
Dominique
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de langue

[Florent RICHARD]

Bonjour,

Pour un objet situé en France, le nom par défaut (tag “name”) doit correspondre 
au nom en langue française (tag “name:fr”). 
Dans ton cas, l’objet est nommé par défaut en allemand.

Florent

From: Dominique Faure 
Sent: Monday, January 25, 2016 10:40 AM
To: talk-fr@openstreetmap.org 
Subject: [OSM-talk-fr] Problème de langue

Bonjour,


"Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me 
débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que je 
sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour lui 
redonner son nom et y rattacher quelques bâtiments dans une relation 
associatedStreet.


Depuis cette modification, j'ai ce message d'erreur dans osmose 
(http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -


​A noter que ma modification à eu lieu ici: 
http://www.openstreetmap.org/way/391928538



Merci d'avance pour vos éclaircissements.
-- 

Dominique



___
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] Problème de langue

[Jérôme Seigneuret]

Bonjour,

J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
de modification. A moins de mettre le tag name en Anglais...

Car cette alerte est à mon avis seulement valable pour les objets (node,
way, relation) se limitant à un territoire dont la langue est identifié
dans notre cas fr et non à des superpostion entre territoires

Dans ton cas, la relation dépasse les frontières. Donc que choisir dans ce
cas... Le name en Anglais, le name du pays de départ (qui soit disant
passant est différent suivant le sens).

J'aurais choisi un nom FR pour les tronçons en France un nom Allemand pour
les tronçons Allemand et pour la relation (Euro), le nom en anglais et
name:fr=* name:de=*

le name:fr permet de toute manière de trouver cette relation dans Nominatim

Jérôme

Le 25 janvier 2016 à 10:40, Dominique Faure  a
écrit :

> Bonjour,
>
> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
> je sèche un peu...
>
> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
> lui redonner son nom et y rattacher quelques bâtiments dans une relation
> associatedStreet.
>
> Depuis cette modification, j'ai ce message d'erreur dans osmose (
> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>
> =8<- - - - -
> Noms dans la langue locale et dans la langue par défaut différents
>
> e-road:class = A-intermediate
> name = Europastraße 54
> name:de = Europastraße 54
> name:fr = Route européenne 54
> network = e-road
> ref = E 54
> route = road
> type = route
> wikidata = Q664865
> wikipedia = fr:Route européenne 54
> =8<- - - - -
>
> ​A noter que ma modification à eu lieu ici:
> http://www.openstreetmap.org/way/391928538
>
>
> Merci d'avance pour vos éclaircissements.
> --
> Dominique
>
> ___
> 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] Couverture voies et noms de voies

[Bruno]

Bonjour,

Dans le cadre d'un projet en entreprise et pour convaincre de l'utilité 
d'OSM , j'aurais besoin de montrer de façon simple et visuelle la 
couverture actuelle de la base OSM en ce qui concerne la voirie  et le 
noms des voies , pas les adresses ni le bâti.


Un peu comme tiles et les zones à mapper mais juste le rouge et avec par 
exemple un % de noms des voies par département.

http://tile.openstreetmap.fr/

Si il existe déjà quelque chose je suis preneur.

Cordialement,
Bruno.

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

Re: [OSM-talk-fr] Problème de langue

[Dominique Faure]

Ok, j'ai renommé le trajet en anglais:

  name=European route E 54

et profité pour corriger quelques sens de circulation.

Merci.



2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret :

> Bonjour,
>
> J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
> de modification. A moins de mettre le tag name en Anglais...
>
> Car cette alerte est à mon avis seulement valable pour les objets (node,
> way, relation) se limitant à un territoire dont la langue est identifié
> dans notre cas fr et non à des superpostion entre territoires
>
> Dans ton cas, la relation dépasse les frontières. Donc que choisir dans ce
> cas... Le name en Anglais, le name du pays de départ (qui soit disant
> passant est différent suivant le sens).
>
> J'aurais choisi un nom FR pour les tronçons en France un nom Allemand pour
> les tronçons Allemand et pour la relation (Euro), le nom en anglais et
> name:fr=* name:de=*
>
> le name:fr permet de toute manière de trouver cette relation dans Nominatim
>
> Jérôme
>
> Le 25 janvier 2016 à 10:40, Dominique Faure  a
> écrit :
>
>> Bonjour,
>>
>> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
>> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
>> je sèche un peu...
>>
>> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
>> lui redonner son nom et y rattacher quelques bâtiments dans une relation
>> associatedStreet.
>>
>> Depuis cette modification, j'ai ce message d'erreur dans osmose (
>> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>>
>> =8<- - - - -
>> Noms dans la langue locale et dans la langue par défaut différents
>>
>> e-road:class = A-intermediate
>> name = Europastraße 54
>> name:de = Europastraße 54
>> name:fr = Route européenne 54
>> network = e-road
>> ref = E 54
>> route = road
>> type = route
>> wikidata = Q664865
>> wikipedia = fr:Route européenne 54
>> =8<- - - - -
>>
>> ​A noter que ma modification à eu lieu ici:
>> http://www.openstreetmap.org/way/391928538
>>
>>
>> Merci d'avance pour vos éclaircissements.
>> --
>> Dominique
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] wiki : page sur les frontières

[Philippe Verdy]

J'ai utilisé quelques modèles standards pour référencer les pages
"Key:" et "Tag:=". A voir pour la suite. Si on veut
référencer les versions françaises de ces pages on peut ajouter kl=fr et
vl=fr.
A compléter pour les autres sections.

Le 26 janvier 2016 à 02:16, Jérôme Amagat  a écrit
:

> tous les tags sont décrit ailleurs (sauf peut être admin_type) c'est vrai,
> cette page resume ce qui est fait pour la france.
> Et la page sur les epci c'est celle la :
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlocal_authority
> c'est con ca parle que de la france et c'est qu'en anglais.
>
> Le 26 janvier 2016 à 01:45, Philippe Verdy  a écrit :
>
>> C'était déjà décrit dans la page sur les boundary et d'autres pages liées
>> (y compris pour les EPCI)
>>
>> Le 26 janvier 2016 à 01:25, Jérôme Amagat  a
>> écrit :
>>
>>> J'ai écrit une page qui liste les frontières françaises et les tags qui
>>> vont avec :
>>>
>>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives
>>>
>>> il manque plein de choses encore mais je pense que ça pourrait être pas
>>> mal d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui
>>> je crois n'apparait nul part sur le wiki. la page n'est pas la ou elle
>>> serai le mieux.
>>>
>>> la page :
>>>
>>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
>>> devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
>>> compte c'est la creation de commune nouvelle et la modification des
>>> communauté de communes et autres EPCI.
>>>
>>> ___
>>> 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