Re: [OSM-talk-fr] harmonisation tag network Arc-en-ciel dans le département du Nord région Hauts-de-France

[Vincent Privat]

Pour: c'est simple, logique, la démarche est bien expliquée, ça suit les
bonnes pratique :)
A+
Vincent

Le 25 août 2017 à 01:38, marc marc  a écrit :

> Bonsoir,
>
> Je me propose de résoudre ce "doublon" "Arc en ciel"
> D'abord merci à Lenny qui a fait déjà fait la moitié du travail :-)
>
> Nom proposé pour le réseau : "Arc en Ciel (Nord)"
>
> La typographie (la majuscule et les espaces) vient de la valeur
> actuellement la plus présente.
> Le suffixe "Nord" vient de leur site et la page wikipedia
> qui indique qu'aujourd'hui (août 2017), c'est le département du Nord
> qui s'occupe du réseau.
>
> Critère de sélection :
> tag network ayant les 3 mots "arc en ciel" sans faire de différence
> entre les majuscules et minuscules.
> étendue de la sélection : la région Hauts-de-France
>
> Récurrence : possible si de nouveaux objets apparaissent
> avec la mauvaise valeur.
> J'essayerai bien évidement dans la mesure du possible
> de prévenir au préalable le contributeur.
>
> Raison du choix : essayer de contenter tout le monde
> C'est à la fois un nom pour humain (l'utilisateur sait
> facilement à quoi cela se rapporte) et c'est aussi
> un nom unique à ce jour et qui pourrait le rester.
>
> Il y a quelques valeurs qui renseignent le chiffre 2 parce
> que leur réseau est divisé en 4 secteurs (de 1 à 4).
> Si quelqu'un a une idée d'un sous-tag où mettre cette info,
> Je la migrerai dans un sous-tag.
> Si pas d'idée ou une majorité contre ou pas d'intérêt, je garderai
> cette info dans le tag network comme c'est le cas actuellement.
>
> Coïncidence, ce réseau changera au 1er septembre de couverture
> pour s'étendre à la région (source : leur site web).
> S'il y a une majorité avant cette date, je le renommerai avec "Nord"
> avant le 1er septembre puis en "Arc en Ciel (Hauts-de-France)"
> à partir du 1er septembre.
> Cela ne me dérange pas et cela m'arrange même histoire à la fois
> de ne pas attendre jusqu'au 1er septembre et à la fois d'avoir
> une opération réelle de modification de nom de réseau à documenter.
> Si la discussion traîne au delà du 1er septembre, je modifierai
> évidement le nom directement en "Arc en Ciel (Hauts-de-France)"
>
> L'opération ne concerne volontairement PAS :
> - quoi faire le jour où ce réseau s'étend hors de la région.
> - le réseau "Arc-en-ciel (Haute-Garonne)", par respect pour son travail,
> je verrai cela séparément avec Lenny.
> - regrouper tout dans une relation network <> des tag network
> Je sélectionne les objets avec le tag. je ne modifie ni à la hausse
> ni à la baisse le nombre ni de tag ni de relation (c'est un AUTRE sujet)
> - le tag operator (c'est une AUTRE sujet)
> - migrer des tags du mobilier vers stop_area (c'est une AUTRE sujet)
> - un tag avec une ref osm (autre discussion en cours)
> - wikidata ou pas, j'ignore même s'il y a un wikidata pour ce réseau.
> Si quelqu'un a envie de chercher/créer/mettre à jour, ce serrait
> bien venu. Ou attendre le 1er septembre pour pas changer 2 fois.
> Moi cela m'est égal. Mais je veux bien l'ajouter dans la foulée.
> - quelqu'un sait s'il y a des pages wiki où il faudrait mettre à jour
> le tag network de ce réseau ? un contributeur non présent ici
> à prévenir ? sinon je chercherai.
>
> N'ayant aucune connaissance de terrain des objets modifiés,
> ceux-ci seront uniquement sélectionnés par requête et vu
> le nombre, je modifierai l'ensemble des valeurs avec
> la fonction chercher de JOSM.
> Cette opération est donc un "changement mécanique" au sens de :
> > https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_
> des_modifications_automatis%C3%A9es
> C'est pourquoi, pour faire bien les chose, j'en parle ici avant.
> Je créerai la page wiki nécessaire à la documentation
> de cette opération s'il y a une majorité qui soutient l'idée.
>
> Donc je vous demande : pour ou contre ?
> Si vous êtes contre, merci de préciser si c'est :
> - le principe d'unification du tag network pour ce réseau
> - les critères
> - le nom choisi (si c'est seulement ce point qui pose problème,
> j'unifierai avec le nom le plus présent, ce serra déjà une avancée)
>
> Merci donc de me donner votre avis et... bon vote :-)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation network <> tags network

[Philippe Verdy]

Le 25 août 2017 à 01:20, marc marc  a écrit :

> Le 25. 08. 17 à 00:38, Philippe Verdy a écrit :
>  comment savoir alors les distinguer quand dans
>  les deux cas ce sont des objets très étendus
>  Par géographie, comme lorsqu'il y a 2 rues du même nom.
> >>> Pas du tout. tu oublies la contrainte "très étendue"
> >> Si pour toi c'est impossible de séparer arc en ciel Nord et
> >> Haute-Garonne, moi, pas au courant de la difficulté, je le fais
> > Ca c'est parce que tu t'intéresse à cette donnée en tant que
> > contributeur sur une zone précise.
> Je n'ai aucune affinité ni avec le sujet ni avec la zone précise.
> Je me propose pour le faire parce que
> 1) c'est utile pour améliorer la situation.
> 2) c'est simple et rapide.
>

Dans ton cas où tu t'intéresses à tes contributions dans une ville que tu
connais bien et que tu situes facilement tu n'as pas de difficultés à
ajouter un critère.

Dans une utilisation plus générale et vu des autres contributeurs qui
s'intéressaient à une autre zone, et tombe tout à coup sur des éléments
inattendus situés dans ton coin, là oui ça pose problème et ça peut les
bloquer: lequel des deux ira modifier le tag utilisé en conflit par
l'autre? On risque de faire du yoyo à coup de reverts mutuels stériles
entre les besoins des uns et des autres qui ont des outils et méthodes de
travail différents et pas concertés du tout, alors qu'on peut s'en prémunir
facilement.


> Mais malgré de nombreuses demandes, tu n'as aucun exemple
> de problème REEL à fournir, tu parles de potentiels futurs
> réseaux de bus mondiaux multiples avec le même nom.
>

Faux, j'en ai parlé. Et j'ai cité le cas des réseaux officiellement
multilingues (en Suisse et Belgique, il y en a aussi en Espagne). Le nom
n'est pas un identifiant unique comme on a cru le faire avec le tag
"network=*" pas fait pour ça.

Et maintenant ce que je critique c'est la nécessité de collectionner les
tags "network:=*" pour désigner en fin de compte un même réseau (quel
que soit le ou les noms qu'on lui donne) et de penser qu'on devra maintenir
ce fatras dans des tas d'objets. Wikidata, Wikipedia, et autre c'est bien
comme info, mais autant regrouper ça dans un seul objet OSM et pas des
centaines.

Et vu que tu préfère ignorer qu'on a AUSSI parlé d'un id unique,


C'est un peu fort de me dire ça à moi, alors que c'est moi qui ait
justement abordé ce problème qui commence à être un peu compris !

Et là dessus certains ont embarqué en proposant des identifiants externes
(hors OSM dans des bases qui ne sont pas mises à jour avec la même
politique d'inclusion, pas consultables avec les mêmes outils, pas
synchronisées, et pas connues de tout le monde et qui obligerait la
communauté à se diviser entre ceux qui connaissent et comprennent la base
tierce, et les autres à qui on demande d'accepter une politique d'édition
et de publication très différente, avec des interlocuteurs très différents
dont la majorité n'a que faire des besoins propres à OSM et ne veut pas
avoir à se charger de ce qu'OSM ne voudrait pas faire lui-même avec sa
propre communauté et ses propres outils partagés).

Cela n’empêche PAS que les relations ONT aussi des avantages.
> Qu'attends-tu pour proposer ton aide à son adoption ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] harmonisation tag network Arc-en-ciel dans le département du Nord région Hauts-de-France

[marc marc]

Bonsoir,

Je me propose de résoudre ce "doublon" "Arc en ciel"
D'abord merci à Lenny qui a fait déjà fait la moitié du travail :-)

Nom proposé pour le réseau : "Arc en Ciel (Nord)"

La typographie (la majuscule et les espaces) vient de la valeur 
actuellement la plus présente.
Le suffixe "Nord" vient de leur site et la page wikipedia
qui indique qu'aujourd'hui (août 2017), c'est le département du Nord
qui s'occupe du réseau.

Critère de sélection :
tag network ayant les 3 mots "arc en ciel" sans faire de différence 
entre les majuscules et minuscules.
étendue de la sélection : la région Hauts-de-France

Récurrence : possible si de nouveaux objets apparaissent
avec la mauvaise valeur.
J'essayerai bien évidement dans la mesure du possible
de prévenir au préalable le contributeur.

Raison du choix : essayer de contenter tout le monde
C'est à la fois un nom pour humain (l'utilisateur sait
facilement à quoi cela se rapporte) et c'est aussi
un nom unique à ce jour et qui pourrait le rester.

Il y a quelques valeurs qui renseignent le chiffre 2 parce
que leur réseau est divisé en 4 secteurs (de 1 à 4).
Si quelqu'un a une idée d'un sous-tag où mettre cette info,
Je la migrerai dans un sous-tag.
Si pas d'idée ou une majorité contre ou pas d'intérêt, je garderai
cette info dans le tag network comme c'est le cas actuellement.

Coïncidence, ce réseau changera au 1er septembre de couverture
pour s'étendre à la région (source : leur site web).
S'il y a une majorité avant cette date, je le renommerai avec "Nord" 
avant le 1er septembre puis en "Arc en Ciel (Hauts-de-France)"
à partir du 1er septembre.
Cela ne me dérange pas et cela m'arrange même histoire à la fois
de ne pas attendre jusqu'au 1er septembre et à la fois d'avoir
une opération réelle de modification de nom de réseau à documenter.
Si la discussion traîne au delà du 1er septembre, je modifierai 
évidement le nom directement en "Arc en Ciel (Hauts-de-France)"

L'opération ne concerne volontairement PAS :
- quoi faire le jour où ce réseau s'étend hors de la région.
- le réseau "Arc-en-ciel (Haute-Garonne)", par respect pour son travail, 
je verrai cela séparément avec Lenny.
- regrouper tout dans une relation network <> des tag network
Je sélectionne les objets avec le tag. je ne modifie ni à la hausse
ni à la baisse le nombre ni de tag ni de relation (c'est un AUTRE sujet)
- le tag operator (c'est une AUTRE sujet)
- migrer des tags du mobilier vers stop_area (c'est une AUTRE sujet)
- un tag avec une ref osm (autre discussion en cours)
- wikidata ou pas, j'ignore même s'il y a un wikidata pour ce réseau.
Si quelqu'un a envie de chercher/créer/mettre à jour, ce serrait
bien venu. Ou attendre le 1er septembre pour pas changer 2 fois.
Moi cela m'est égal. Mais je veux bien l'ajouter dans la foulée.
- quelqu'un sait s'il y a des pages wiki où il faudrait mettre à jour
le tag network de ce réseau ? un contributeur non présent ici
à prévenir ? sinon je chercherai.

N'ayant aucune connaissance de terrain des objets modifiés,
ceux-ci seront uniquement sélectionnés par requête et vu
le nombre, je modifierai l'ensemble des valeurs avec
la fonction chercher de JOSM.
Cette opération est donc un "changement mécanique" au sens de :
> https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des_modifications_automatis%C3%A9es
C'est pourquoi, pour faire bien les chose, j'en parle ici avant.
Je créerai la page wiki nécessaire à la documentation
de cette opération s'il y a une majorité qui soutient l'idée.

Donc je vous demande : pour ou contre ?
Si vous êtes contre, merci de préciser si c'est :
- le principe d'unification du tag network pour ce réseau
- les critères
- le nom choisi (si c'est seulement ce point qui pose problème, 
j'unifierai avec le nom le plus présent, ce serra déjà une avancée)

Merci donc de me donner votre avis et... bon vote :-)

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

Re: [OSM-talk-fr] relation network <> tags network

[marc marc]

Le 25. 08. 17 à 00:38, Philippe Verdy a écrit :
 comment savoir alors les distinguer quand dans
 les deux cas ce sont des objets très étendus
 Par géographie, comme lorsqu'il y a 2 rues du même nom.
>>> Pas du tout. tu oublies la contrainte "très étendue"
>> Si pour toi c'est impossible de séparer arc en ciel Nord et
>> Haute-Garonne, moi, pas au courant de la difficulté, je le fais
> Ca c'est parce que tu t'intéresse à cette donnée en tant que 
> contributeur sur une zone précise.
Je n'ai aucune affinité ni avec le sujet ni avec la zone précise.
Je me propose pour le faire parce que
1) c'est utile pour améliorer la situation.
2) c'est simple et rapide.

Mais malgré de nombreuses demandes, tu n'as aucun exemple
de problème REEL à fournir, tu parles de potentiels futurs
réseaux de bus mondiaux multiples avec le même nom.
Et vu que tu préfère ignorer qu'on a AUSSI parlé
d'un id unique, le jour où cela arrivera, l'id unique
fait que ce serra encore plus facile (= en une ligne)
pour les identifier que pour les réseaux "Arc en ciel".
Bref, la solution d'unicité est possible avant même
qu'une application qui n'existe pas encore ai un problème
pour séparer 2 réseaux de même noms lorsqu'ils auront
une étendues imbriquée. woaw la solution avant le problème.

Cela n’empêche PAS que les relations ONT aussi des avantages.
Qu'attends-tu pour proposer ton aide à son adoption ?

Bref on tourne en rond.
Si personne n'a envie de mettre ses mains dans le cambouis
pour faire avancer cette proposition, elle restera en l'état.
Sauf avancée, je ferrai un dernier résumé des pour<>contre au cas
où quelqu'un veux s'y mettre ou si le sujet reviens dans X temps.
Après cela, je pense que la discussion sur ce point est stérile.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de bus en site propre

[Jérôme Amagat]

Le 24 août 2017 à 22:48,  a écrit :

> Le 21/08/2017 à 00:48, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Sur la page : https://wiki.openstreetmap.org/wiki/Key:service
> il y a bien service=bus mais cela a été ajouté, si on regarde
> l'historique, le 17 mai 2017.
> Et la page : https://wiki.openstreetmap.org/wiki/Tag:service%3Dbus
> et un peu plus vieille novembre 2016 et donne comme raison pour la
> création de ce tag :
> "Some bus companies using OSM for routing exclude all highway
> =service
>  from their
> routers unless they are also tagged service
> =*bus*, so in order for
> these routers to work appropriately, service lanes at bus stations used by
> the mentioned companies need to be tagged with this."
> ça ne me semble pas être une bonne raison pour utiliser ce tag.
> Je pense donc que ce tag devrait disparaître du wiki.
>
> Fait pour https://wiki.openstreetmap.org/wiki/Key:service.
> Tu nettoies l'autre ? en précisant discouraged et en justifiant ?
> Le commentaire reste valable ;-)
>
> J'ai modifié la page en ajoutant des bandeaux :
https://wiki.openstreetmap.org/wiki/Tag:service%3Dbus
N’hésitez pas à modifier (mon anglais est mauvais), à compléter, à en faire
ce que vous voulez :)
La page existe aussi en japonnais :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation network <> tags network

[Philippe Verdy]

Le 24 août 2017 à 23:47, marc marc  a écrit :

> Le 24. 08. 17 à 21:42, Philippe Verdy a écrit :
> > Le 24 août 2017 à 12:04, Jo a écrit :
> > S'il y a quelqu'un qui enlève un membre, combien de temps se
> > passe-t-il avant que l'on s'en rend compte?
> > Concernant les relations "type=network" on se rend compte
> > **immédiatement** qu'il manque
> Des objets network arc-en-ciel Haute-Garonne sont absente
> de la relation network, qui les as vu ?
> moi uniquement maintenant, sans utiliser la relation network.
>

Parce que tu travailles sur ces lignes. D'une façon générale il faut être
contributeur actif pour savoir qu'il y en a et qu'on en utilise. OSM étant
incrémental, et les réseaux étant à peine commencés dans OSM, c'est normal
qu'elles soient encore incomplètes. Mais quand un gros chantier est
entreprise localement, on ne peut pas ne pas les remarquer et en tirer
profit.


> Le 24. 08. 17 à 22:20, Philippe Verdy a écrit :
> Le 24 août 2017 à 12:29, marc marc a écrit :
> Le 23. 08. 17 à 21:43, Philippe Verdy a écrit :
>  >>> comment savoir alors les distinguer quand dans
>  >>> les deux cas ce sont des objets très étendus
>  >> Par géographie, comme lorsqu'il y a 2 rues du même nom.
>  > Pas du tout. tu oublies la contrainte "très étendue"
> Si pour toi c'est impossible de séparer arc en ciel Nord et
> Haute-Garonne, moi, pas au courant de la difficulté, je le fais dans le
> message suivant (alors qu'ils n'ont pas encore d'id unique
>

Ca c'est parce que tu t'intéresse à cette donnée en tant que contributeur
sur une zone précise. Si on veut en faire un usage plus générale dans des
outils de consultation grand public, il faudra bien régler ce problème de
cohérence pour que ces outils ne soient pas trompés par les ambiguïtés avec
des objets inattendus situés n'importe où dans le monde, l'outil pouvant
lui même avoir une utilisation globale (comme OSRM) en partant de n'importe
où dans le monde et aller n'importe où et profiter des transports en commun
à l'arrivée et des possibilités de corespondances pour son séjour: lors de
la recherche sur une destination, les noms des réseaux sont totalement
indéterminés.

Même un outil moins ambitieux (par exemple européen ou seulement national)
tombera sur ces difficultés: les réseaux sont de complexité et de taille
TRES différente (surtout si on tient compte de l'intermodalité: avions,
trains, voitures, bus, ferries, parcours à vélo ou à pied). Prévois un
voyage touristique et tu peux te demander s'il vaut mieux y aller en train
ou voiture, et selon ce choix et la durée maximale prévue pour ce séjour,
tu ne choisiras pas les mêmes hôtels, gites ou campings, tu n'auras pas le
même équipement à emporter ou trouver sur place, ni les mêmes visites sur
place. Si c'est pour travailler tu peux envisager un déménagement et tu
chercheras les services à proximité et comment y aller et organiser ta vie.

Les transports en commun ne se limitent pas à un itinéraire sur une seule
ligne, ils sont fortement liés à tes autres activités et besoins et
fonctionnent à des échelles très différentes qui se combinent entre elles.
Au lieu de lignes simples (instables et difficiles à maintenir), les
réseaux organisés offrent un vrai plus en terme de stabilité. Les sociétés
de transport justement se construisent non pas sur une seule ligne majeure
et quelques arrêts, mais sur un ensemble plus vaste relié au reste. Les
réseaux en plus associent de nombreux acteurs et des collectivités de
nature et taille très différentes.

Bref tu ne sauras pas que ce que tu cherches se limite à la Haute-Garonne
ou au Nord, même si dans cet exemple ces départements sont très éloignés.
Tu peux vouloir faire une application spécialisée pour ces deux zones, mais
les utilisateurs trouveront plus pratique une application globale
permettant de tout trouver, de la même façon qu'OSM est une base de données
mondiale qu'on consulte de n'importe où vers n'importe où.

Bref ton point de vue manque d'ambition et crois qu'on sera efficace en se
concentrant d'abord et seulement sur le détail sans s'intéresser en premier
lieu à la vision globale qui permet de planifier le travail à faire et le
rendre cohérent, sans retirer aucun intérêt pour les modifications locales
(qui n'ont pas beaucoup d'usage et de sens si on n'envisage même pas de les
relier au reste). Plus au aura de données, et plus le besoin de les
organiser de façon cohérente et sans ambiguïté se fera sentir, permettant
des recherches efficaces et précises.

Je pense que tu ne t'en rend pas compte encore car même en France seulement
le travail n'a commencé que dans les agglomérations les plus denses où les
transports sont les plus fréquentés. Mais même là on a des difficultés avec
les homonymies (notamment les noms des arrêts!) et les cas de
réorganisation des réseaux et évolutions des coopérations entre
collectivités et la concurrence des transporteurs imposée à l'échelle
européenne: les réseaux se chevauchent de plus en plus.

Re: [OSM-talk-fr] StreetComplete et les poteaux électriques

[marc marc]

ca c'est amusant comme coïncidence, j'ai commencé depuis quelques 
semaines/mois à faire la même chose pour les lampadaires, suite à une 
discussion ici sur un problème de tag "fourre-tout"
par contre j'ai utilisé support:material parce qu'il me semblait 
important de préciser que cela concernait le poteau et non le lampadaire.
je n'ai pas encore fait de publication wiki, j'attendais de roder un peu 
la chose et de terminer la discussion entre autre avec Jean-Yvon quand 
il y aura moins le feu :-)


Le 24. 08. 17 à 23:27, François Lacombe a écrit :
> Bonsoir à tous,
> 
> Une petite info que je viens de voir passer
> StreetComplete a ajouté une quête questionnant l'utilisateur sur le 
> matériau constituant les poteaux électriques environnants.
> https://github.com/westnordost/StreetComplete/pull/493
> 
> La nouvelle version n'est pas encore publiée, encore un peu de patience.
> 
> Comme pour les routes avec la clé surface, le tag material sur les 
> supports de réseau a une grande valeur.
> Un croisement avec des landuse=forest permet assez facilement de repérer 
> les tronçons les plus sensibles aux chutes d'arbre (ou au feu, comme ces 
> dernières semaines) avec une faible résistance. Ainsi je connais déjà 
> quelques entreprises qui surveillent l'élagage et le risque feu avec 
> notre carto.
> 
> J'en ai profité pour traduire un peu mieux la version anglaise de 
> power=pole qui présente moult détails
> https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dpole
> 
> Bonne soirée
> 
> 
> *François*
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] relation network <> tags network

[marc marc]

Le 24. 08. 17 à 21:42, Philippe Verdy a écrit :
> Le 24 août 2017 à 12:04, Jo a écrit :
> S'il y a quelqu'un qui enlève un membre, combien de temps se
> passe-t-il avant que l'on s'en rend compte?
> Concernant les relations "type=network" on se rend compte 
> **immédiatement** qu'il manque
Des objets network arc-en-ciel Haute-Garonne sont absente
de la relation network, qui les as vu ?
moi uniquement maintenant, sans utiliser la relation network.

Le 24. 08. 17 à 22:20, Philippe Verdy a écrit :
Le 24 août 2017 à 12:29, marc marc a écrit :
Le 23. 08. 17 à 21:43, Philippe Verdy a écrit :
 >>> comment savoir alors les distinguer quand dans
 >>> les deux cas ce sont des objets très étendus
 >> Par géographie, comme lorsqu'il y a 2 rues du même nom.
 > Pas du tout. tu oublies la contrainte "très étendue"
Si pour toi c'est impossible de séparer arc en ciel Nord et 
Haute-Garonne, moi, pas au courant de la difficulté, je le fais dans le 
message suivant (alors qu'ils n'ont pas encore d'id unique)

Si tu as un exemple de 2 réseaux de bus ayant le même nom et ayant une 
couverture tellement "étendue" que TU n'arrive pas à les séparer 
géographiquement, donne leur nom stp.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] StreetComplete et les poteaux électriques

[François Lacombe]

Bonsoir à tous,

Une petite info que je viens de voir passer
StreetComplete a ajouté une quête questionnant l'utilisateur sur le
matériau constituant les poteaux électriques environnants.
https://github.com/westnordost/StreetComplete/pull/493

La nouvelle version n'est pas encore publiée, encore un peu de patience.

Comme pour les routes avec la clé surface, le tag material sur les supports
de réseau a une grande valeur.
Un croisement avec des landuse=forest permet assez facilement de repérer
les tronçons les plus sensibles aux chutes d'arbre (ou au feu, comme ces
dernières semaines) avec une faible résistance. Ainsi je connais déjà
quelques entreprises qui surveillent l'élagage et le risque feu avec notre
carto.

J'en ai profité pour traduire un peu mieux la version anglaise de
power=pole qui présente moult détails
https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dpole

Bonne soirée


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

Re: [OSM-talk-fr] aller à Europa-Park en voiture

[marc marc]

Le 24. 08. 17 à 23:11, Philippe Verdy a écrit :
> c'est pas trop mal comme résultat avec Mapzen
origine Paris
destination Europa-Park, Rust
algorithme Mapzen
réponse : Impossible de trouver une route entre ces deux lieux.

Si j'introduis cela dans un gps classique, cela fonctionne
Si je tape les coordonnées d'un point dans le parc, cela fonctionne
Si je tappe la ville d'arrivée "Rust, Allemagne", cela fonctionne

Je ne demande pas de deviner le lieu idéal où arrêter la voiture, 
j'espère juste trouver au moins les 544 premier km du trajet vers ce POI

Demander à l'utilisateur de bouger sa destination d'arrivée
de quelques mètres n'est pas une solution sérieuse.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] aller à Europa-Park en voiture

[Philippe Verdy]

Donc c'est pas trop mal comme résultat avec Mapzen (à condition de chercher
manuellement à partir d'où finir le trajet à pied). Mais avec OSRM là il y
a bien une anomalie énorme:

http://www.openstreetmap.org/directions?engine=osrm_car=48.25866%2C7.72151%3B48.25992%2C7.72235


Le 24 août 2017 à 23:05, Philippe Verdy  a écrit :

> C'est très clairement le cas ici: regardez où il termine la route trouvée,
> il ne franchit pas la barrière d'entrée du parc à quelques mètres de là (et
> ce n'est pas non plus l'endroit adéquat pour s'arrêter, évidemment le
> parking au nord-ouest est plus adéquat).
>
> http://www.openstreetmap.org/directions?engine=mapzen_car;
> route=48.25864%2C7.72148%3B48.26517%2C7.71972#map=19/48.26504/7.71996
>
> Si on déplace ce point d'arrivée n'importe où dans le parc, il cible
> l'arrivée uniquement sur un point quelconque (seulement plus près "à vol
> d'oiseau") autour du domaine privé. La recherche ignore les fins de
> parcours possibles à pied, la recherche est faire en fonction du trajet
> possible d'un véhicule quelconque.
>
> Changez pour un parcours à pied et on a bien un parcours adéquat passant
> par une entrée fermée par une barrière. mais le trajet à pied n'est pas
> optimum pour le parcours en partie en voiture.
>
>
>
> Le 24 août 2017 à 22:55, Philippe Verdy  a écrit :
>
>> Je pense que cela vient de l'heuristique utilisée: il y a bien un trajet
>> possible mais il faut un parcours en "épingle à cheveux", en s'éloignant
>> fortement des deux points de départ et d'arrivée, ça demande de passer par
>> un point qui sort très nettement du cadre de recherche par l'heuristique
>> utilisé.
>>
>> Il manque une option pour élargir la recherche à un cadre plus grand. Il
>> ne trouve aucun chemin permettant de rejoindre les rues publiques qui
>> entourent le parc et au mieux ne trouve qu'à un point situé à plusieurs
>> centaines de mètres de distance, sans même qu'existe un parcours possible à
>> pied.
>>
>> Sinon on devrait pouvoir ajouter un point intermédiaire.
>>
>> De plus il semble qu'il ne cherche aucun chemin sur les voies privées (et
>> les rues dans le parc sont toutes privées) et ne situe pas le point
>> d'entrée public connectant ces voies privées au réseau public.
>>
>> Le 24 août 2017 à 18:20, marc marc  a écrit :
>>
>>> Bonjour,
>>>
>>> une idée pourquoi Europa-Park Allemagne est non routable ?
>>>
>>> http://www.openstreetmap.org/directions?engine=mapzen_car
>>> ute=48.2588%2C7.7216%3B48.2640%2C7.7221
>>>
>>> Impossible de trouver une route entre ces deux lieux.
>>>
>>> il suffit de transformer le nom en coordonnées pour avoir la route
>>> jusqu'en bordure du parc.
>>>
>>> Cordialement,
>>> Marc
>>> ___
>>> 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] aller à Europa-Park en voiture

[Philippe Verdy]

C'est très clairement le cas ici: regardez où il termine la route trouvée,
il ne franchit pas la barrière d'entrée du parc à quelques mètres de là (et
ce n'est pas non plus l'endroit adéquat pour s'arrêter, évidemment le
parking au nord-ouest est plus adéquat).

http://www.openstreetmap.org/directions?engine=mapzen_car=48.25864%2C7.72148%3B48.26517%2C7.71972#map=19/48.26504/7.71996

Si on déplace ce point d'arrivée n'importe où dans le parc, il cible
l'arrivée uniquement sur un point quelconque (seulement plus près "à vol
d'oiseau") autour du domaine privé. La recherche ignore les fins de
parcours possibles à pied, la recherche est faire en fonction du trajet
possible d'un véhicule quelconque.

Changez pour un parcours à pied et on a bien un parcours adéquat passant
par une entrée fermée par une barrière. mais le trajet à pied n'est pas
optimum pour le parcours en partie en voiture.



Le 24 août 2017 à 22:55, Philippe Verdy  a écrit :

> Je pense que cela vient de l'heuristique utilisée: il y a bien un trajet
> possible mais il faut un parcours en "épingle à cheveux", en s'éloignant
> fortement des deux points de départ et d'arrivée, ça demande de passer par
> un point qui sort très nettement du cadre de recherche par l'heuristique
> utilisé.
>
> Il manque une option pour élargir la recherche à un cadre plus grand. Il
> ne trouve aucun chemin permettant de rejoindre les rues publiques qui
> entourent le parc et au mieux ne trouve qu'à un point situé à plusieurs
> centaines de mètres de distance, sans même qu'existe un parcours possible à
> pied.
>
> Sinon on devrait pouvoir ajouter un point intermédiaire.
>
> De plus il semble qu'il ne cherche aucun chemin sur les voies privées (et
> les rues dans le parc sont toutes privées) et ne situe pas le point
> d'entrée public connectant ces voies privées au réseau public.
>
> Le 24 août 2017 à 18:20, marc marc  a écrit :
>
>> Bonjour,
>>
>> une idée pourquoi Europa-Park Allemagne est non routable ?
>>
>> http://www.openstreetmap.org/directions?engine=mapzen_car
>> ute=48.2588%2C7.7216%3B48.2640%2C7.7221
>>
>> Impossible de trouver une route entre ces deux lieux.
>>
>> il suffit de transformer le nom en coordonnées pour avoir la route
>> jusqu'en bordure du parc.
>>
>> Cordialement,
>> Marc
>> ___
>> 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] aller à Europa-Park en voiture

[Philippe Verdy]

Je pense que cela vient de l'heuristique utilisée: il y a bien un trajet
possible mais il faut un parcours en "épingle à cheveux", en s'éloignant
fortement des deux points de départ et d'arrivée, ça demande de passer par
un point qui sort très nettement du cadre de recherche par l'heuristique
utilisé.

Il manque une option pour élargir la recherche à un cadre plus grand. Il ne
trouve aucun chemin permettant de rejoindre les rues publiques qui
entourent le parc et au mieux ne trouve qu'à un point situé à plusieurs
centaines de mètres de distance, sans même qu'existe un parcours possible à
pied.

Sinon on devrait pouvoir ajouter un point intermédiaire.

De plus il semble qu'il ne cherche aucun chemin sur les voies privées (et
les rues dans le parc sont toutes privées) et ne situe pas le point
d'entrée public connectant ces voies privées au réseau public.

Le 24 août 2017 à 18:20, marc marc  a écrit :

> Bonjour,
>
> une idée pourquoi Europa-Park Allemagne est non routable ?
>
> http://www.openstreetmap.org/directions?engine=mapzen_car;
> route=48.2588%2C7.7216%3B48.2640%2C7.7221
>
> Impossible de trouver une route entre ces deux lieux.
>
> il suffit de transformer le nom en coordonnées pour avoir la route
> jusqu'en bordure du parc.
>
> Cordialement,
> Marc
> ___
> 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] aller à Europa-Park en voiture

[marc marc]

Le 24. 08. 17 à 19:41, David Crochet a écrit :
> Le 24/08/2017 à 18:20, marc marc a écrit :
>> une idée pourquoi Europa-Park Allemagne est non routable ?
> 
> Et pourtant j'y vais : 
> http://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26915%2C7.71681#map=16/48.2640/7.7192
>  

Allez aux coordonnées d'un point fonctionne.

tapes "Europa-Park, rust" en destination, c'est cela qui ne va pas
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de bus en site propre

[osm . sanspourriel]

Le 21/08/2017 à 00:48, Jérôme Amagat - jerome.ama...@gmail.com a écrit :


Sur la page : https://wiki.openstreetmap.org/wiki/Key:service
il y a bien service=bus mais cela a été ajouté, si on regarde 
l'historique, le 17 mai 2017.

Et la page : https://wiki.openstreetmap.org/wiki/Tag:service%3Dbus
et un peu plus vieille novembre 2016 et donne comme raison pour la 
création de ce tag :
"Some bus companies using OSM for routing exclude all highway 
=service 
 from their 
routers unless they are also tagged service 
=*bus*, so in order 
for these routers to work appropriately, service lanes at bus stations 
used by the mentioned companies need to be tagged with this."

ça ne me semble pas être une bonne raison pour utiliser ce tag.
Je pense donc que ce tag devrait disparaître du wiki.

Fait pour https://wiki.openstreetmap.org/wiki/Key:service.
Tu nettoies l'autre ? en précisant discouraged et en justifiant ?
Le commentaire reste valable ;-)

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

Re: [OSM-talk-fr] ligne de bus : tag network

[Philippe Verdy]

Le 24 août 2017 à 10:45, lenny.libre  a écrit :

>
> Le 23/08/2017 à 13:52, Marc Gemis a écrit :
>
>> S'il faut aller dans wikidata pour créer et modifier ce qu'y nous est
>>> nécessaire dans osm !!! Je voulais faire de l'osm, pas du wikidata
>>>
>>
> J'arrête donc de contribuer sur OSM
> Adieu
>

Voilà à quoi on aboutit quand on ne veut pas régler simplement dans les
données OSM les problèmes propres à OSM et qu'on refuse d'utiliser un
système pourtant simple et très peu coûteux garantissant l'ouverture à tout
le monde avec le minimum d'effort pour chacun.

Un comportement qui sera similaire de la part des collectivités qui elles
aussi préféreront d'adresser à un exploitant commercial de base de données,
qui au moins fournira les outils simples et synthétiques adaptés à leur
demande, donnant une grande liberté ensuite pour étoffer les données par
les deux bouts (globalement et localement) avec des outils différents
adaptés à chaque niveau d'analyse.

Et donc on peut comprendre ensuite leur hésitation à aller vers l'Open Data
quand leurs fournisseurs de service commerical (répondant à leurs
problèmes) leur proposent dès maintenant des réductions tarifaires pour peu
qu'elles acceptent de leur céder un droit d'usage exclusif, entraînant
aussi l'obligation pour les collectivités et organismes de monétiser les
données qu'elles produisent, juste pour payer la facture (croissante) des
fournisseurs commerciaux, ou de les autoriser à filtrer les données selon
les profils et abonnements payants des utilisateurs pour mettre de la
publicité ciblée à la place (dont seul le fournisseurs de services
commercial tirera profit, tandis que les collectivités se verront imposer
des frais croissants d'usage et perdront même la main sur la qualité et la
disponibilité des données qu'elles voulaient rendre au public, et même la
notoriété qu'elles sont à l'origine des données et que les produire a eu un
coût non compensé par le fournisseur commercial qui taira les profits réels
qu'il en tire)...

Le fournisseur de service devenant de plus en plus gros (et incontournable)
peut imposer ses conditions et même les modifier unilatéralement quand bon
lui semblera. Regardez ce qui s'est passé dans l'hôtellerie, l'aérien et la
presse d'information, c'est révélateur de ce qui attend les collectivités:
l'ubérisation poussée à l'extrême aussi dans la cartographie, par des
monopoles commerciaux qui se sont imposés très vite et d'abord par leur
efficacité et le piège de la solution facile et pas chère à court terme
(qui pourtant coûtent très cher à ces fournisseurs mais qui ont pour eux
des budgets d'investissement énormes qui leur permet de faire ça pendant
longtemps à perte), puis par leur puissance financière accrue et la
capacité à orienter le marché comme ils veulent et faire taire sur tous les
médias l'émergence d'une réelle concurrence pérenne (et non basée sur
l'entente en petit comité comme maintenant dans les télécoms).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] aller à Europa-Park en voiture

[marc marc]

c'est ce que j'ai d'abord cru mais :
- quand tu demandes un trajet de 500km, je n'ai pas vu de routage qui te 
dit "non" simplement parce qu'il manque quelques mètres de route
généralement tous te guident jusqu'à proximité.
dans mon exemple j'ai volontairement rapproché l'origine de la 
destination afin de réduire le nombre de route concernée.
- je ne comprend pas pourquoi il y a une différence entre la destination 
"Europa-Park" et la même destination avec longitude/latitude.
c'est comme si le problème était que la destination Europa-Park était un 
landuse, je n'ai par exemple jamais rencontré ce problème avec un noeud 
ou un bâtiment
faut-il ajouter des nœuds d'entrée pour aider le routage ? je l'ignore.

Le 24. 08. 17 à 21:01, osm.sanspourr...@spamgourmet.com a écrit :
> Et pour les explications :
> 
> https://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26400%2C7.72210#map=15/48.2640/7.7190
> 
> Tu vois que le point que tu indiques (et pas celui du parking donné par 
> David) est loin de la route pour Mapzen, pas pour GraphHopper :
> 
> https://www.openstreetmap.org/directions?engine=graphhopper_car=48.2588%2C7.7216%3B48.2640%2C7.7221#map=16/48.2620/7.7235
> 
> OSRM est le moins tolérant :
> https://www.openstreetmap.org/directions?engine=osrm_car=48.2588%2C7.7216%3B48.2692%2C7.7168
> 
> Les moteurs acceptent tous de ne pas faire les derniers mètres avec le 
> moyen indiqué.
> Un moteur d'une célèbre entreprise s'amusait à répondre aux demandes 
> d'itinéraire entre l'Europe et l'Amérique un trajet réaliste sur les 
> deux continents et entre "nagez 5 000 km".
> 
> J'ai l'impression que certains moteurs tiennent compte du géocentre et 
> non de l'étendue de la place trouvée.
> En fait c'est sûr, il suffit de regarder les paramètres passés : c'est 
> un point.
> 
> Jean-Yvon
> 
> Le 24/08/2017 à 19:41, David Crochet - david.croc...@free.fr a écrit :
>> Bonjour
>>
>>
>> Le 24/08/2017 à 18:20, marc marc a écrit :
>>> une idée pourquoi Europa-Park Allemagne est non routable ?
>>
>> Et pourtant j'y vais : 
>> http://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26915%2C7.71681#map=16/48.2640/7.7192
>>
>> Cordialement
>>
> 
> 
> 
> ___
> 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] signification du tag network (nom <> ref unique)

[Philippe Verdy]

Le 24 août 2017 à 12:29, marc marc  a écrit :

> Le 23. 08. 17 à 21:43, Philippe Verdy a écrit :
>  > comment savoir alors les distinguer quand dans les deux cas ce
>  > sont des objets très étendus
>
> Par géographie, comme lorsqu'il y a 2 rues du même nom.
>

Pas du tout. tu oublies la contrainte "très étendue" et leur structure
géométrique très compliquée contrairement aux rues qui sont essentiellement
linéaires et ne sorte pas d'une bounding box très petite (exception faite
des longues avenues de Californie qui peuvent faire des centaines de
kilomètres mais connues aussi par un numéro de référence routière car on y
trouve aussi des segments nommés localement différemment, mais là encore
c'est essentiellement linéaire)

En comparaison un réseau couvre une zone très étendue avec un maillage
assez serré où il sera difficile de voir là où manque une ligne d'autant
que leur liste change souvent et leurs parcours aussi (difficulté certaine
sur les mises à jour, parfois plusieurs mises à jour la même année pour les
bus, mais beaucoup plus rare pour les trains/métros/trams dont le tracé ne
se change pas aussi facilement et qui se voit facilement sur l'imagerie ou
sur le terrain).

Les réseaux sont une réalité mondiale, mais OSM ne fait qu'à peine
effleurer leur existence alors qu'ils vont se multiplier et se densifier
partout par nécessité.

On a juste commencé à tenter de les représenter mais dans nombre d'endroits
on n'a même pas ébauché les lignes.

Pourtant c'est nettement plus facile de construire des objets "réseau" même
incomplets (dont on n'a pas encore détaillé complètement toutes les
lignes), et planifier facilement alors le travail sur les lignes
incomplètes qu'on énumère facilement avec des sources variées et la
connaissance locale (qui sait facilement quelle est la liste des lignes du
réseau même si le détail des itinéraires et des arrêts possibles ou aménagé
demande un gros travail de terrain car on ne peut pas se fier à sa mémoire
ou connaissance locale hormis des secteurs microscopiques uniquement près
de chez soi: faites juste 1 kilomètre, si vous n'êtes pas usager régulier
d'une ligne, vous ne savez pas exactement où elle passe et ne situez
vaguement de mémoire que quelques arrêts "repères")

Le travail à faire est immense, mais se contenter de le faire du point de
vue microscopique local ou uniquement en comptant sur la bonne volonté des
exploitants pour publier des données open data à jour, on n'avancera jamais
quand ceux-ci modifient les lignes très souvent et ne notifient que les
usagers réguliers ou leur site web privé ou se contentent de poser des
affiches à certains endroits. Et on n'aura jamais assez de monde partout et
toute l'année pour suivre ça ou lire les annonces de presse locales ou
aller consulter les délibérations des conseils municipaux sur les
affichages officiels devant la mairie, ou en allant demander dans une
agence de voyage ou appeler un numéro d'informations surtaxé, ou faire la
queue devant un guichet de vente de titres de transports !

Si on n'en reste là, on ne pourra compter que sur les applis et sites
dédiés des exploitants et sur les plans rarement à jour qu'on y trouve
(même la SNCF a du mal sur son réseau ferré pourtant totalement construit
en dur et rend encore compliqué la connaissance des trajets possibles dans
ses TGV, les services changeant également très souvent en fréquence et
dessertes).

Lisez une fiche horaire saisonnière d'un transporteur en bus, et regardez
le nombre de notes et astérisques: c'est pas facile à lire et encore moins
de trouver des correspondances adéquates pour planifier un voyage ou savoir
si on va s'y abonner ou réserver (et quand on va pouvoir réserver en étant
sûr d'avoir aussi les correspondances nécessaires). En revanche on s'abonne
facilement à un réseau.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation network <> tags network

[Philippe Verdy]

Le 24 août 2017 à 12:04, Jo  a écrit :

> Salut Lenny,
>
> J'espère que je vais pas troubler encore plus "l'eau"...
>
> Pour l'exemple de l'application:
> http://www.overpass-api.de/api/sketch-line?network=DLVB=318=
> http://www.overpass-api.de/public_transport.html
>
> Ce que moi je préfère avec la solution de tagger les objets c'est qu'il
> n'y a pas de relation à entretenir.
>
> Maintenir des relations est moins évident que cela ne le semble. S'il y a
> quelqu'un qui enlève un membre, combien de temps se passe-t-il avant que
> l'on s'en rend compte?
>

Concernant les relations "type=network" on se rend compte **immédiatement**
qu'il manque une ligne à la liste qui est très synthétique: ses membres
sont chacune des lignes numérotées (et normalement classées dans des
numéros de ligne, bien que ce ne soit pas une obligation), et on en connait
le nombre avant même d'avoir commencé à les tracer ou les chercher. On sait
immédiatement quelles lignes sont fermées et qu'on peu retirer.

Si toutes les lignes ont leur relations réseau attachées (et il ne doit y
encore qu'une sauf cas exceptionnel des lignes cogérées sur plusieurs
réseaux et qui reconnaissent sur ces lignes la validité des titres de
transport émis par l'un ou l'autre des réseaux...), on ne peut pas créer de
doublon sans que ça se voit aussi **immédiatement** dans la relation
parente.


> Les mettre dans les tags implique que des fois un object (arrêt, route)
> appartient à plusieurs réseaux, mais cela ne pose pas de problème. On peut
> les séparer par ;
>

- un unique tag "network=" par route (dans les liste de ses tags) ne
suffit pas on l'a vu, et n'est pas clair du tout, souvent erroné.
- une seule relation parente "type=route" par route (ou bien une seule
relation parente "super-route" ou "route_master", jamais simultanément)
suffit à tout et est clairement identifiée, on ne fait pas d'erreur et en
cas de doute on peut cliquer dessus pour en voir le contenu et les tags de
description et toutes ses références utiles. Ce n'est pas plus long ni plus
compliqué à éditer et jamais ambigu.
- la présence de l'un n'empêche pas l'autre mais en cas de doute ou
conflit, l'ambiguïté intrinsèque du tag (historique issu du schéma v1) ne
résout rien facilement, et le tag n'est pas nécessaire si on a la relation
parente, c'est juste une redondance pour la compatiblité v1, alors que la
relation parente est toujours non ambiguë.

Quant à la présence aussi bien du tag "network=*" ou d'une relation parente
"type=network" ailleurs que les relations "type=route" (ou
"type=super_route" ou "type=route_master"), elle ne se justifie pas dans
aucun des deux cas :
- Les arrêts et plateformes et sont référencés par les relations
"type=route" ou "type=stop_area" qui les incluent.
- il n'y a aucun arrêt ou plateforme dans une super_route ou route_master
dont les membres ne sont que des relations routes ou super_route.
Donc aucun ajout de tag ou ni de relation network nécessaire sur les arrêts
et plateformes (s'il y en a c'est de la redondance pour la compatibilité v1
sur les "highway=bus_stop" qui sont en fait des plateformes en v2, mais le
plus souvent les plateformes ne font pas partie directement d'un réseau
mais ne concernent qu'un "operator=*" exploitant).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] aller à Europa-Park en voiture

[osm . sanspourriel]

Et pour les explications :

https://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26400%2C7.72210#map=15/48.2640/7.7190

Tu vois que le point que tu indiques (et pas celui du parking donné par 
David) est loin de la route pour Mapzen, pas pour GraphHopper :


https://www.openstreetmap.org/directions?engine=graphhopper_car=48.2588%2C7.7216%3B48.2640%2C7.7221#map=16/48.2620/7.7235

OSRM est le moins tolérant :
https://www.openstreetmap.org/directions?engine=osrm_car=48.2588%2C7.7216%3B48.2692%2C7.7168

Les moteurs acceptent tous de ne pas faire les derniers mètres avec le 
moyen indiqué.
Un moteur d'une célèbre entreprise s'amusait à répondre aux demandes 
d'itinéraire entre l'Europe et l'Amérique un trajet réaliste sur les 
deux continents et entre "nagez 5 000 km".


J'ai l'impression que certains moteurs tiennent compte du géocentre et 
non de l'étendue de la place trouvée.
En fait c'est sûr, il suffit de regarder les paramètres passés : c'est 
un point.


Jean-Yvon

Le 24/08/2017 à 19:41, David Crochet - david.croc...@free.fr a écrit :

Bonjour


Le 24/08/2017 à 18:20, marc marc a écrit :

une idée pourquoi Europa-Park Allemagne est non routable ?


Et pourtant j'y vais : 
http://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26915%2C7.71681#map=16/48.2640/7.7192


Cordialement



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

Re: [OSM-talk-fr] aller à Europa-Park en voiture

[David Crochet]

Bonjour


Le 24/08/2017 à 18:20, marc marc a écrit :

une idée pourquoi Europa-Park Allemagne est non routable ?


Et pourtant j'y vais : 
http://www.openstreetmap.org/directions?engine=mapzen_car=48.25880%2C7.72160%3B48.26915%2C7.71681#map=16/48.2640/7.7192


Cordialement

--
David Crochet


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

[OSM-talk-fr] aller à Europa-Park en voiture

[marc marc]

Bonjour,

une idée pourquoi Europa-Park Allemagne est non routable ?

http://www.openstreetmap.org/directions?engine=mapzen_car=48.2588%2C7.7216%3B48.2640%2C7.7221

Impossible de trouver une route entre ces deux lieux.

il suffit de transformer le nom en coordonnées pour avoir la route 
jusqu'en bordure du parc.

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

Re: [OSM-talk-fr] [Hot-francophone] line=bus sur des ways à Dakar

[Jo]

Bonjour,

J'ai commencé d'utiliser le plugin PT_Assistant de JOSM à Dakar et j'en ai
fait des vidéos:

https://www.youtube.com/watch?v=WJ5tybiSZaE
https://www.youtube.com/watch?v=elSiStQr2dA

A un moment donné le premier vidéo devient un peu 'répétitif', n'hésitez
pas de passe au suivant à ce moment-là. Dans le deuxième je montre comment
améliorer/corriger les relations route.

N'hésitez pas d'ajouter cette vidéo à votre curriculum de formation pour
les cartographes au Sénégal, si elle vous plaît.

Jo



2017-08-24 0:52 GMT+02:00 Inno Diblo :

> Merci Jean Marc d'avoir attiré notre attention par rapport sur cet aspect.
> Je fais partie de ceux qui cartographient actuellement les lignes bus
> Dakar Dem Dikk.
> Effectivement les attributs sur les lignes bus s'appliquent sur les
> relations et non sur les les routes elles mêmes. A vérifier ton lien, la
> plupart des problèmes identifiés ont été cartographiés par
> jeanmariemancabou  il
> y a plus d'un an. Nous avons récemment suivi une formation pour permettre
> aux contributeurs locaux (y compris  jeanmariemancabou
>   et les  autes
> membres OSM Sénégal) de ne plus reproduire ces genres d'erreurs. Les
> problèmes signalés ont été corrigés. Si vous en rencontrer encore, prévenez
> nous pour qu'on puisse vérifier. Par contre, nous remarquons d'énormes
> doublons par d'autres contributeurs qui ne prennent pas le soin de vérifier
> de ce qui a été fait sur les arrêts et les lignes. Du coup nous nous
> retrouvons parfois sur une ligne avec plusieurs relations. Ce qui ne
> devrait pas être le cas.
>
> Merci à tous
> Rejoignez-nous
> .
>
> Le 17 août 2017 à 14:48, Jean-Marc Liotier  a écrit :
>
>> Bonjour, j'ai repéré à Dakar quelques ways étiquetés line=bus - il me
>> semble (et c'est aussi l'opinion du JOSM Validator) que cette étiquette
>> a plutôt sa place sur une relation... Mais je ne maîtrise pas du tout
>> les modèles de transports publics en évolution dans Openstreetmap alors,
>> comme j'ai cru voir que des efforts ont lieu actuellement à Dakar en la
>> matière, peut-être que l'un d'entre vous souhaitera se pencher sur la
>> question. J'ai appliqué un fixme aux ways concernés, que vous trouverez
>> rassemblés dans le changeset suivant:
>> https://www.openstreetmap.org/changeset/50713492
>>
>> ___
>> Hot-francophone mailing list
>> hot-francoph...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot-francophone
>>
>
>
>
> --
>
> *Innocent Soungalo DIBLONI*
>
> *Etudiant géographe*
>
> *Volontaire International de la Francophonie
> -promotion
> 2017*
>
> *Dakar (Sénégal)*
> *Contributeur OpenStreetMap
> *
> Email: innoc...@gmail.com
> Tél_SN:+221 77 471 73 48 <+221%2077%20471%2073%2048>
> Tel_BF: +226 71 49 76 79 <+226%2071%2049%2076%2079>
>
>
> ___
> Hot-francophone mailing list
> hot-francoph...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot-francophone
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] pistes cyclables à paris

[Nicolas Bétheuil]

J'ai initalisé un map contrib pour comparer OSM & l'open data
https://www.mapcontrib.xyz/t/841cf5-Reseau_cyclable_Paris

Qu'ai-je mis de trop pour que sur le layer OSM (overpass) ? j'ai des bulles
de POI : il n'y a que des ways, ni node, ni relations.

Merci

Le 24 août 2017 à 13:35, Nicolas Bétheuil  a écrit :

> Hello rogelio,
>
> En fait il y a de l'open data sur les pistes cyclables de Paris. Je viens
> de rechercher & trouver ça https://opendata.paris.fr/
> explore/dataset/reseau-cyclable
> Vais demander en interne comment je peux faire ça.
>
> Des reco les mappeurs sur la manière de procéder ?
> osmose pourrait aider pour partager le travail ?
>
> Le 23 août 2017 à 19:59, Rogelio Canedo  a
> écrit :
>
>> Salut Nico,
>> Je ne suis pas certain que les données de Paris vélo soient en open data.
>> Mappy a mis à disposition sur Mapillary toutes les images de la collecte
>> 2017 et de mémoire il y a Paris. Tu peux donc faire l'intégration via josm
>> en mode manuel :) N'hésite pas à demander un coup de main à Gilles où
>> Ulrich si tu galère avec l'outil.
>> C'est peut être aussi l'occasion d'organiser un mapathon chez Mappy? Non?
>>
>> @++
>>
>>
>> Le 23 août 2017 3:02 PM, "Nicolas Bétheuil"  a écrit :
>>
>> Bonjour,
>>
>> Comment sont gérées les pistes cyclables avec la mairie de paris ?
>> Il y en a beaucoup qui ne sont pas dans OSM
>> ex : http://www.parisavelo.net/carte-imprimable-pistes-cyclables.jpg
>>
>> il y en a de nouvelles https://twitter.com/latruelle/
>> status/900078511536386050
>>
>> C'est aussi de l'ajout manuel ?
>> Comment on peut procéder ?
>>
>> merci
>>
>> ___
>> 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] pistes cyclables à paris

[Nicolas Bétheuil]

Hello rogelio,

En fait il y a de l'open data sur les pistes cyclables de Paris. Je viens
de rechercher & trouver ça
https://opendata.paris.fr/explore/dataset/reseau-cyclable
Vais demander en interne comment je peux faire ça.

Des reco les mappeurs sur la manière de procéder ?
osmose pourrait aider pour partager le travail ?

Le 23 août 2017 à 19:59, Rogelio Canedo  a écrit :

> Salut Nico,
> Je ne suis pas certain que les données de Paris vélo soient en open data.
> Mappy a mis à disposition sur Mapillary toutes les images de la collecte
> 2017 et de mémoire il y a Paris. Tu peux donc faire l'intégration via josm
> en mode manuel :) N'hésite pas à demander un coup de main à Gilles où
> Ulrich si tu galère avec l'outil.
> C'est peut être aussi l'occasion d'organiser un mapathon chez Mappy? Non?
>
> @++
>
>
> Le 23 août 2017 3:02 PM, "Nicolas Bétheuil"  a écrit :
>
> Bonjour,
>
> Comment sont gérées les pistes cyclables avec la mairie de paris ?
> Il y en a beaucoup qui ne sont pas dans OSM
> ex : http://www.parisavelo.net/carte-imprimable-pistes-cyclables.jpg
>
> il y en a de nouvelles https://twitter.com/latruelle/
> status/900078511536386050
>
> C'est aussi de l'ajout manuel ?
> Comment on peut procéder ?
>
> merci
>
> ___
> 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] signification du tag network (nom <> ref unique)

[marc marc]

Pour éviter de se noyer, je divise en 2 :
relation network <> tag network c'est dans l'autre sujet.
Ici c'est quoi mettre dans le tag network.
Car il y a un besoin d'une clef pour le nom pour l'humain.
Et un besoin d'une référence unique pour les outils.

Le 24. 08. 17 à 10:45, lenny.libre a écrit :
 > Le 23/08/2017 à 13:52, Marc Gemis a écrit :
 >>> Oui mais https://www.wikidata.org/wiki/Wikidata:Notability
 >> 3. It fulfills some structural need
 >> Je pense dans ce cas ici, 3 est vrais.
 > Et en français ça veut dire quoi 3 ?

Il remplit un besoin structurel

 > Si un réseau change de nom il change aussi de wikidata

non il garde le même wikidata, quelqu'un modifiera sa page wikidata

 > Je voulais faire de l'osm, pas du wikidata
 > J'arrête donc de contribuer sur OSM
Mais non, le wikidata n'est pas obligatoire.
Celui qui le souhaite le rajoutera.
Continue sans wikidata comme tu le fais actuellement,
Cela ne t’empêche pas de faire du bon boulot !
Est-ce qu'une page wiki osm qui liste les réseaux te convient ?
Si tu n'as pas envie de l'éditer, quelqu'un le ferra,
il faut faire ce qu'on aime dans osm.

Le 22. 08. 17 à 15:33, Christian Quest a écrit :
 > Les ref stables et id wikidata permettent à des scripts
 > d'accéder sans  équivoque aux infos.

est-ce que l'idée "ajouter un wikidata pour ceux qui le veulent/peuvent, 
et utiliser ref:FR:network:bus (ou autre nom, qu'importe) pour les 
autres" satisfait-il les besoins que les scripts habituels ont ?
Si oui, quel nom pour la ref ? quel lieu pour la liste de valeur ?
je pensais à une page wiki avec un format "strict" afin d'être éditable 
pour un contributeur et lisible depuis un script.
est-ce qu'on met tjs qlq chose dans ref pour n'avoir qu'un tag à 
analyser ou avoir 2 tag n'est pas trop dérangeant ?
ou un osmdata.openstreetmap.fr ? plus long à faire.

Le 23. 08. 17 à 13:52, Marc Gemis a écrit :
 >> Oui mais https://www.wikidata.org/wiki/Wikidata:Notability
 > 3. It fulfills some structural need, for example: it is needed to make
 > statements made in other items more useful.
 > Je pense dans ce cas ici, 3 est vrais.

Oui tu as probablement raison, j'ai survolé un peu trop vite.

Le 23. 08. 17 à 17:27, frem a écrit :
 >> au lieu de créer un nouveau tag,
 >> - ne pourrait-on pas utiliser network:wikidata s'il existe
 >> - et pour ceux qui n'en ont pas, suivre la logique du tag ref avec
 >> quelque chose genre network:ref ou ref:FR:network:bus ?
 >> Ou si c'est plus pratique une seule clef pour les 2 cas,
 >> on crée une ref pour tout réseau, une sorte de wikidata version osm
 >> une page wiki où on ajoute chaque nouvel identifiant et ca roule.
 > Complètement d’accord. Si l’ajout dans Wikidata ne nous semble pas
 > pertinent ou si on connaît peu les règles de contribution à ce projet,
 > c’est sans doute une très bonne idée.

à faire : rajouter une explication sur la création d'un wikidata sur le 
wiki osm et/ou si cette page existe, inclure un lien "où ça va bien"
Préciser que c'est facultatif, pour ne pas refroidir ceux qui n'en 
veulent pas.

Le 23. 08. 17 à 21:43, Philippe Verdy a écrit :
 > comment savoir alors les distinguer quand dans les deux cas ce
 > sont des objets très étendus

Par géographie, comme lorsqu'il y a 2 rues du même nom.
S'il y a 2 réseau arc-en-ciel une même rue et que les utilisateurs
ont besoin de pouvoir les séparer et qui ont le même opérateur,
ce n'est pas la fin du monde si on écrit l'un "Arc-en-ciel"
et l'autre "Arc en ciel" afin de forcer une unicité.
Si ce genre de subtilité n'est pas possible (imaginons que
leur nom est toto), on utilisera le nom de leur site web.
Oui mais s'ils ont le même site www.toto.fr ?
alors c'est qu'ils ne sont qu'un réseau, cqfd !
Bref ce moment d'humour à 2 centimes à prendre au 2ieme degré
simplement pour dire d'éviter de rendre la situation dramatique.
Une fois précisé quel est le tag avec le nom et quel est le tag avec la 
référence unique, le problème des doubles arc-en-ciel est soluble.
Pour sélectionner tout le réseau arc-en-ciel Occitanie à partir
du tag network, c'est 2 lignes http://overpass-turbo.eu/s/rdw
Cela n'empêche pas, dans l'autre sujet, que les relations network
ont des avantages mais séparons les 2 problèmes pour résoudre
au moins l'un des 2, sinon on tourne en rond avec les 2.

Le 23. 08. 17 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :
 > Je ne connais personnellement que Overpass API qui a l'interface
 > sketchline pour produire des lignes de transport.
> https://wiki.openstreetmap.org/wiki/Overpass_API/Public_transport_example
Pour le fun, l'exemple de ligne ambiguë entre la France et l'Allemagne, 
n'est pas causé par un tag network non unique mais par son absence
http://www.overpass-api.de/api/sketch-line?ref=N12=

Le 23. 08. 17 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :
 > Parce que les noms sont en entrée libre, je suggère d'avoir un
 > network:wikidata afin de faire plus facilement du contrôle qualité.
 > si on ne veut pas ajouter un Wikidata, on 

Re: [OSM-talk-fr] relation network <> tags network

[Jo]

Salut Lenny,

J'espère que je vais pas troubler encore plus "l'eau"...

Pour l'exemple de l'application:
http://www.overpass-api.de/api/sketch-line?network=DLVB=318=
http://www.overpass-api.de/public_transport.html

Ce que moi je préfère avec la solution de tagger les objets c'est qu'il n'y
a pas de relation à entretenir.

Maintenir des relations est moins évident que cela ne le semble. S'il y a
quelqu'un qui enlève un membre, combien de temps se passe-t-il avant que
l'on s'en rend compte?

Les mettre dans les tags implique que des fois un object (arrêt, route)
appartient à plusieurs réseaux, mais cela ne pose pas de problème. On peut
les séparer par ;

Jo


2017-08-24 11:10 GMT+02:00 marc marc :

> Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> > Le 24 août 2017 à 01:31, marc marc a écrit :
> >
> > Si une app ne survit pas à l'absence de relation (qui n'existe quasi
> > pas), Philippe merci de donner son NOM pour ceux qui l'ignorent.
> > histoire de réfléchir au problème.
> > Je n'ai PAS DU TOUT évoqué ce problème, tu as compris de travers.
>
> Est-ce que tu peux alors stp me dire CLAIREMENT+SOMMAIREMENT
> quel argument/problème je n'ai pas compris lorsque j'ai essayé
> de résumer ton avis avec la phrase suivante :
> "les relations network ont des avantages (l'unicité même en cas de nom
> identique, sélectionner tout un réseau) pour un coût réduit donc
> utilisons les."
>
> Tu réponds en 3 pages allant du train à l'Europe.
> Mais après les avoir lues, je ne n'ai pas mieux compris mon erreur.
>
> Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> > problème des applis qui attendent une valeur précise
> Nous sommes visiblement au moins 3 à n'avoir toujours pas compris non
> plus de quel appli tu parles.
> pas d'exemple ? donc aucune ? donc on a toute liberté de mettre cela en
> ordre, c'est justement l'objet des 2 sujets (l'un pour le sens du tag
> network, celui-ci pour "choisir" relation network ou pas relation)
> Au niveau applicatif, la différence est :
> avec relation network : sélectionner relation type=network oü
> network=xyz + ses fils
> sans relation network : sélectionner relation type=route_master oü
> network=xyz + ses fils
> Une différence d'UN mot, les vrais problèmes sont ailleurs, non ?
>
> Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> > mythe façon OSM qui confond ça avec des collections ouvertes
> comme je te le disais, participe donc à la proposition relation network
> Parce que me redire leur utilité que je connais ne sert à rien.
> ___
> 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] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Le 23 août 2017 à 23:29, marc marc  a écrit :

>
> oui, comme je disais : vas-y ! ou attends tu l'avis Bhynoteam ?
>
C'est envoyé :
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions#Flow_and_pipes_capacity

Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait rédigé
en 2015
https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655

Il y a certains points en commun avec la proposition... d'autres un peu
moins.


> et c'est là que emporté par le mouvement, tu vas rajouter une modif du
> tag pression parce que lui aussi n’aucune raison d'être préfixé.
> pressure sur une borne, c'est aussi précis que fire_hydrant:pressure
>

+1 Il faudrait que j'ajoute également un sujet sur la suppression des
namespaces.

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

Re: [OSM-talk-fr] relation network <> tags network

[François Lacombe]

Hello,

Je m'invite un peu dans la discussion.
Ca me rappelle cet échange de l'année dernière à la même période où il
était aussi question des relations vs utilisation de ref sur les routes
départementales

Le 24 août 2017 à 10:45, lenny.libre  a écrit :

> 1) Quand je vais sur le site du réseau que je consulte, je télécharge le
> plan des lignes (c'est un network) - dans osm si je consulte la relation
> network correspondante je vois les lignes qui la composent
> Ensuite sur le site, je prends une ligne, j'ai le tracé emprunté par la
> ligne et les arrêts - dans osm si je consulte la relation route, j'obtiens
> la même chose
> Je peux naviguer sur les lignes des deux réseaux sur la Haute-Garonne en
> partant des arrêts ou des relations que ce soit dans l'interrface d'osm
> https://www.openstreetmap.org/relation/3814393 ou dans josm, juste en
> cliquant sur les liens
>

Très bon point sur les fonctionnalités de visualisation d'osm.org qui
privilégie clairement les relations sur les communautés d'attributs


> 2) d'accord, mais je ne vois pas bien la différence entre une relation
> network et une relation route, je ne comprends pas pourquoi la relation
> network serait une relation catégories
>
Une relation de route est une suite nécessairement d'objets continus, et
avec bien souvent un seul itinéraire pour aller de A à B.
Un network n'est pas forcément continu et avec une multiplicité
d'itinéraires.

A+

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

Re: [OSM-talk-fr] relation network <> tags network

[marc marc]

Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> Le 24 août 2017 à 01:31, marc marc a écrit :
> 
> Si une app ne survit pas à l'absence de relation (qui n'existe quasi
> pas), Philippe merci de donner son NOM pour ceux qui l'ignorent.
> histoire de réfléchir au problème.
> Je n'ai PAS DU TOUT évoqué ce problème, tu as compris de travers.

Est-ce que tu peux alors stp me dire CLAIREMENT+SOMMAIREMENT
quel argument/problème je n'ai pas compris lorsque j'ai essayé
de résumer ton avis avec la phrase suivante :
"les relations network ont des avantages (l'unicité même en cas de nom 
identique, sélectionner tout un réseau) pour un coût réduit donc 
utilisons les."

Tu réponds en 3 pages allant du train à l'Europe.
Mais après les avoir lues, je ne n'ai pas mieux compris mon erreur.

Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> problème des applis qui attendent une valeur précise
Nous sommes visiblement au moins 3 à n'avoir toujours pas compris non 
plus de quel appli tu parles.
pas d'exemple ? donc aucune ? donc on a toute liberté de mettre cela en 
ordre, c'est justement l'objet des 2 sujets (l'un pour le sens du tag 
network, celui-ci pour "choisir" relation network ou pas relation)
Au niveau applicatif, la différence est :
avec relation network : sélectionner relation type=network oü 
network=xyz + ses fils
sans relation network : sélectionner relation type=route_master oü 
network=xyz + ses fils
Une différence d'UN mot, les vrais problèmes sont ailleurs, non ?

Le 24. 08. 17 à 02:41, Philippe Verdy a écrit :
> mythe façon OSM qui confond ça avec des collections ouvertes
comme je te le disais, participe donc à la proposition relation network
Parce que me redire leur utilité que je connais ne sert à rien.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de bus : tag network

[lenny.libre]

Le 23/08/2017 à 13:52, Marc Gemis a écrit :

Oui mais https://www.wikidata.org/wiki/Wikidata:Notability
1. Il contient au moins un lien de site valide vers une page de
Wikipédia, Wikivoyage, Wikisource, Wikiquote, Wiki-news, Wikibooks,
Wikiversité, Wiki-data, ou Wikimédia Commons. <...> une même page
Wikipédia ne peut être liée que par un seul lien de site sur Wikidata


En Anglais, on dit "ou"   " if it meets at least one of the criteria below:"

2. It refers to an instance of a clearly identifiable conceptual or
material entity.
ou
3. It fulfills some structural need, for example: it is needed to make
statements made in other items more useful.

Je pense dans ce cas ici, 3 est vrais.

Et en français ça veut dire quoi 3 ?
Utiliser wikidata pour gérer des identifiants osm me semble bizarre, 
d'autant plus que wikidata ne me parait pas très rigoureux, je peux 
faire ce que je veux, il y a une page 
https://www.wikidata.org/wiki/Q24716728 sur une news de création d'une 
ligne de bus, à ce rythme...
Il y a même une page avec les lignes 
https://www.wikidata.org/wiki/Q3250969 avec des erreurs "Ligne de bus 
Tisséo 1" devrait s’appeler "Ligne de bus Tisséo Linéo 1" ou "Ligne de 
bus Tisséo L1" la ligne 25 a été supprimé il y a pas mal de temps
Quand je vois tous les alias du réseau "Arc-en-Ciel" il a fallu que j'en 
modifie un pour avoir la majuscule sur le C

Si un réseau change de nom il change aussi de wikidata
S'il faut aller dans wikidata pour créer et modifier ce qu'y nous est 
nécessaire dans osm !!! Je voulais faire de l'osm, pas du wikidata


J'arrête donc de contribuer sur OSM
Adieu
leni

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

Re: [OSM-talk-fr] relation network <> tags network

[lenny.libre]

Le 24/08/2017 à 01:31, marc marc a écrit :

Dans le but d'éviter de noyer l'autre discussion avec ce point,
j'en fais un sujet séparé. Si je résumé les différents avis, il y a :

1) les relations network ont des avantages (l'unicité même en cas de nom
identique, sélectionner tout un réseau) pour un coût réduit donc
utilisons les.
2) les relations de catégorie sont pour l'instant refusée dans osm,
donc utile ou pas, il faut s'en passer.
3) l'important est d'avoir une ref unique (wikidata et/ou ref osn) ce
qui permet d'avoir les avantages des relations (même si coût + élevé)
Lever l’ambiguïté en cas de nom identique est possible avec cette ref
et/ou par géographique de la même manière que lorsqu'il existe 2 rues
avec le même nom.

est-ce que j'ai bien résumé la situation ?

Si une app ne survit pas à l'absence de relation (qui n'existe quasi
pas), Philippe merci de donner son NOM pour ceux qui l'ignorent.
histoire de réfléchir au problème.
Parce que les exemples théoriques, tout le monde est d'accord, une
relation est plus pratique que sélectionner les x route_master ayant le
tag du réseau. A l'inverse sélectionner x route_master d'un réseau n'est
pas un drame non plus.

Mon avis :
aucun consensus pour le 1 donc à éviter parce que sinon yo-yo entre les
pro-relation et les pro-tag-network.
mais rien ne t'empêche Philippe, voir même je te conseille, de raviver
la proposition à ce sujet afin d'essayer de la faire adopter.

d'accord avec le 2 et le 3
___
1) Quand je vais sur le site du réseau que je consulte, je télécharge le 
plan des lignes (c'est un network) - dans osm si je consulte la relation 
network correspondante je vois les lignes qui la composent
Ensuite sur le site, je prends une ligne, j'ai le tracé emprunté par la 
ligne et les arrêts - dans osm si je consulte la relation route, 
j'obtiens la même chose
Je peux naviguer sur les lignes des deux réseaux sur la Haute-Garonne en 
partant des arrêts ou des relations que ce soit dans l'interrface d'osm 
https://www.openstreetmap.org/relation/3814393 ou dans josm, juste en 
cliquant sur les liens
2) d'accord, mais je ne vois pas bien la différence entre une relation 
network et une relation route, je ne comprends pas pourquoi la relation 
network serait une relation catégories
3) je ne programme pas, à partir d'overpass, je sais retrouver des 
éléments qui ont une info, mais pas deux, je passe


d'accord avec 1 et 2
leni

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

[OSM-talk-fr] Mise à jour Route500...

[Christian Quest]

L'IGN a publié dernièrement l'édition 2017 des données Route500.

Je viens de mettre à jour le rendu "Route500" avec ces nouvelles données.

Plus d'infos sur ce rendu dispo sur le wiki:
https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Route500.E2.84.A2.C2.A9.C2.AE


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