Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-11 Par sujet Dominique Faure 
Bonjour,
Je ne voudrais pas passer par le troll de service qui vient s'immiscer dans
la conversation (même si dans les faits ça y ressemble beaucoup), mais quid
des situations équivalentes chez nos voisins?

Sommes-nous à ce point leader dans la structuration des données d'OSM que
nous sommes en train de définir le modèle de données qui devra à terme être
étendu à l'ensemble de la couverture, ou s'agit-il d'une problématique
franco-franchouillarde qui n'aura qu'une portée nationale ?


2016-07-11 3:03 GMT+02:00 Jérôme Amagat :

> la relation que l'on voit là :
> http://scigrid.de/posts/2015-Jul-02_power-relations-in-openstreetmap.html
> ça ressemble beaucoup aux relations utilisées pour matérialiser une ligne
> de bus ou plutôt une ligne de metro (peu d'intercection), il y a des
> arrêts, les substastions et des morceaux de route (les line) pour aller de
> l'un à l'autre. ces morceaux de route peuvent servir pour plusieurs
> relations.
>
> Par contre, je viens de regarder comment c'est fait pour le chemin de fer.
> il y a des relations type=route route=train qui représentent les lignes
> train, avec le trajet du train et ses arrêts comme pour les bus , métro...
> Et il y a aussi les relations type=route route=railway qui représentent
> plutôt les ligne du point de vue des rails avec un nom du type "ligne de
> truc à machin" et un ref. ça ressemble beaucoup a ce qu'on dit qu'il faut
> pas faire avec les routes départementales. (par contre j'ai pas
> l'impression, avec 3 exemple :P, qu'il y ai des doublons info sur le way et
> sur la relation)
>
> ___
> 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] Le formulaire de recherche OSMand ignore la grande majorité des villes françaises

2016-02-12 Par sujet Dominique Faure 
Un petit tour sur http://download.osmand.net/list.php montre que la carte
"France addresses-nationwide Europe" ne semble plus être disponible.
La seule référence disponible ailleurs (
https://drive.google.com/folderview?id=0B4qLLBK6aTKJSV92VjRzUEhSY0k&usp=sharing&tid=0B3Km9qIKVYnOYnNUS1BwRmtEMjg#list)
date de 2014

En l'état, seules les adresses définies directement dans la carte sont
utilisables dans OsmAnd.



2016-02-11 23:54 GMT+01:00 :

> Le 11/02/2016 22:03, Jean-Michel Pouré - j...@poure.com a écrit :
>
> Bonsoir à tous,
>
> J'espère que c'est le bon endroit pour poser cette question :
>
> pas vraiment mais tu dois tomber sur une communauté d'utilisateurs qui
> sera aussi intéressée par les réponses.
> Méthode différente de celle de Philippe (je n'ai pas chargé la base dont
> il parle).
>
> Je viens de faire un test : carte Bretagne téléchargée (version complète
> mais ça ne doit pas changer grand chose), mode avion.
> Recher de Roscanvel (moins de 1 000 habitants, même code postal que
> Camaret-sur-Mer).
>
> Sur l'onglet PI (point d'intérêt) :
> Roscanvel est trouvé (2 hameaux, un port, un bureau de poste avec les
> heures d'ouverture, un village et un terrain de jeu).
>
> N'as-tu pas cherché par adresse ? Dans ce cas il faut cliquer sur
> "rechercher plus de villages et codes postaux" car il filtre sérieusement.
> J'en suis déjà à mon deuxième jour d'utilisation d'OSMAND.
>
> Attention : les géométries ne sont pas respectées lors de la recherche il
> ne semble tenir compte que du plus proche.
> De même les lieux-dits sont à chercher dans "ville" (non dans l'adresse de
> la rue).
> Il trouve des hamlet (pas de isolated_dweling même s'il est affiche sur la
> carte).
>
> Si on reprend Roscanvel il connaît un bon nombre de rue y compris les
> numéros ! Et les hameaux aussi.
>
> Donc oui il faut un brevet de pilote pour utiliser OSMAND mais ça vaut le
> coup de le passer.
>
> Pour le moment j'ai fait mon premier trajet guidé : il semble fiable mais
> muet.
> Il doit y avoir un truc dans un coin.
>
> Jean-Yvon
>
> ___
> 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] Doute sur le calage Bing/Cadastre

2016-02-08 Par sujet Dominique Faure 
Merci pour l'info, je vais tâcher des points de calages pertinents aux
alentours.

2016-02-08 10:53 GMT+01:00 Jérôme Seigneuret :

> Bonjour,
>
> Attention sur les zones de montagne
>
> J'ai déjà vu des décalages de fou autant sur l'ortho, le cadastre, que les
> données GPS. Il est très difficile de savoir comment rectifier
> correctement. On l'observe sur certaines jointures de photo Bing; Sur le
> Cadastre ce sont les limites de communes qui montre bien le problème; Le
> GPS quant à lui est complètement foireux quand la couverture est opéré par
> des satellite ne sont pas assez écartés et peut causer des décalages de
> plusieurs dizaines de mètres (on voit un écartement entre les traces prise
> sur différents jours voir même différentes heures pour une même position).
> Pour rappel, c'est pas la richesse en nombre de satellites qui est gage de
> qualité pour la localisation.
>
> Je vous invites à vous renseigner sur les contraintes et les limites des
> différents systèmes avant de choisir un calage comme étant une source
> d'information. En effet la source des points géodésiques reste la meilleure
> source (et pour le moment la seule qui fournie une info de qualité)
>
> Sur le cadastre il me semble que les points repérés avec des infos
> géodésiques de levé de géomètre sont entourés au niveau des limites de
> parcelles.
>
> Cordialement,
> Jérôme
>
> Le 7 février 2016 à 22:46, GarenKreiz  a écrit :
>
>> Bonsoir,
>>
>> A priori il faut se recaler sur les bornes géodesiques RGF quand on
>> arrive à les repérer sur la couche photographique. Dans le coin, les
>> plus exploitables pourraient être le sommet du Moutet (Mont-de-Lans I)
>> et la Grande Aiguille (Mont-de-Lans V) qui semblent indiquer un
>> décalage d'une quinzaine de mètre vers l'est des photos. Mais ces
>> repères sont assez loins : il faudrait aller repérer sur le terrain et
>> les photos la borne la plus proche du hameau (Mont-de-Lans II).
>>
>> Ceci étant, si beaucoup de choses des environs ont été saisies d'après
>> les photos sans recalage, cela va être délicat de garder la cohérence
>> de la carte!
>>
>>
>> Le 6 février 2016 à 18:56, Dominique Faure  a
>> écrit :
>> > Bonjour,
>> >
>> > Voulant donner plus de détails autour d'un hameau alpin
>> > (http://www.openstreetmap.org/#map=17/45.03642/6.09351), je me suis
>> aperçu
>> > dans JOSM qu'à la fois les couches Bing et cadastrale étaient décalées
>> par
>> > rapport aux traces GPS.
>> >
>> > Je me doute que par sa situation quasiment au fond d'une gorge, les
>> traces
>> > GPS manquent cruellement de précision.
>> >
>> > De plus, d'après le sujet déjà abordé ici quelques années auparavant
>> > (http://gis.19327.n5.nabble.com/Alignement-cadastre-tt5729650.html),
>> je ne
>> > peux pas m'appuyer sur le cadastre non plus.
>> >
>> > Que puis-je / dois-je / ai-je le droit de faire dans ce cas?
>> >
>> > --
>> > 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
>>
>
>
> ___
> 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

[OSM-talk-fr] Doute sur le calage Bing/Cadastre

2016-02-06 Par sujet Dominique Faure 
Bonjour,

Voulant donner plus de détails autour d'un hameau alpin (
http://www.openstreetmap.org/#map=17/45.03642/6.09351), je me suis aperçu
dans JOSM qu'à la fois les couches Bing et cadastrale étaient décalées par
rapport aux traces GPS.

Je me doute que par sa situation quasiment au fond d'une gorge, les traces
GPS manquent cruellement de précision.

De plus, d'après le sujet déjà abordé ici quelques années auparavant (
http://gis.19327.n5.nabble.com/Alignement-cadastre-tt5729650.html), je ne
peux pas m'appuyer sur le cadastre non plus.

Que puis-je / dois-je / ai-je le droit de faire dans ce cas?

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

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

2016-01-26 Par sujet Dominique Faure 
En pratique, y a-t-il dans la cartographie actuelle une route européenne
dont la structure puisse servir de modèle pour les autres?

2016-01-26 16:00 GMT+01:00 Otourly Wiki :

> Les spécificités du Québec ne répondent pas à la problématique des routes
> européennes qui sont multiculturelles et multilingues, je pense.
>
> Florian Farge aka Otourly
> #WeAreFairphone
>
>
> Le Mardi 26 janvier 2016 14h54, Pierre Béland  a écrit
> :
>
>
> La langue officielle en France est le français.
> donc pour le territoire français, name contient la dénomination française,
> portion allemande, l'allemand. et si vous le voulez, name:en peut être
> ajouté.
>
> Nous procédons ainsi au Canada. Québec en français.
>
>
>
> Pierre
>
>
>
> --
> *De :* Damouns 
> *À :* Discussions sur OSM en français 
> *Envoyé le :* mardi 26 janvier 2016 2h53
> *Objet :* Re: [OSM-talk-fr] Problème de langue
>
> 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 <http://www.openstreetmap.org/browse/way/83115947>* rawedit
> <http://osmose.openstreetmap.fr/fr/map/#> josm
> <http://localhost:8111/load_object?objects=w83115947> edit
> <http://osmose.openstreetmap.fr/fr/map/#>
> *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 lan

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

2016-01-25 Par sujet 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 défaut est une romanisation adaptée à l'usage
>

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

2016-01-25 Par sujet 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

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

2016-01-25 Par sujet 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