Re: [OSM-talk] Thanks for cooperation to SOTM 2017

[Martijn van Exel]

Jun, 

It was my pleasure to meet you in Aizu-Wakamatsu and enjoy a very well 
organized, fun and educational SOTM. Among my personal highlights (besides the 
high quality talks)  were the group picture ceremony on the historic castle 
grounds, the group dinner and ensuing karaoke fun, and meeting many new 
community members. It was my first visit to Japan and I certainly hope it is 
not my last. 

Now that we're on the topic of SOTM: we had a good Local Chapters meeting 
following  the one in Brussels in 2016. This time, we collected OSM usernames / 
email addresses from everyone there (about 35 people from 20 countries!) so we 
can keep working together on helping each other build local communities and 
institutions to support OSM. If you weren't there but want to help (or need 
help), email me and I will add you to the list.

Thanks for all the hard work, and I look forward to Milan 2018!

Martijn

> On Aug 23, 2017, at 11:08, joost schouppe  wrote:
> 
> Great work all of you who made this possible!
> 
> For those who missed it, bulk videos are already available: 
> https://www.youtube.com/channel/UC0jDNhn6t-PLVvqMPL-ZWbg
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-in] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-GB] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-ie] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-ca] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[talk-ph] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-us] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] weeklyOSM #370 2017-08-15-2017-08-21

[weeklyteam]

The weekly round-up of OSM news, issue # 370,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9390/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and science

[Yves]

On Thursday 24 August 2017, Frederik Ramm wrote:


It is certainly good for OSM to offer a helping hand to scientists
who are seeking cooperation. I would also like us to develop a review
and fact check mechanism for scientific publications on OSM so that
those who don't bother to get their facts right are held accountable
for the bad science they inevitably produce.


No need to take it this way: it would be a way for publishers to get a review 
from the community while not being part of it. I 'm no expert in social 
science, and I  wouldn't necessarily judge badly this argument. 

Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] [SPAM] Re: Philippine multilingual place names (English/native language)

[Rally de Leon]

name=* is for "common name". It should reflect what is normally seen
on signboards (not entirely as we still have good practice in naming
conventions).

As pointed out by Roger, name prefixes/suffixes (which are part of the
default name values) are generally and majorly written in English in
PH. We still use Street, Avenue, Highway, Boulevard, Rotonda,
Expressway, School, Day Care Center, Health Center, Fire Station,
Boundary, etc etc.

Since name=* is also the "default name" shown by simple map apps (with
no custom rendering), localizing default name values (to FIlipino) can
work to our disadvantage during disasters ...if outside-emergency
responders would still "Google Search" or need an "online language
translator".

Take for example (by looking at Japan/Korea/China OSM Map): if a major
disaster happen there now, imagine yourselves as an outsider, mapping
for, or volunteering to help with the aid of an online map or using a
downloadable offline gps map; is it way harder for non-techie
individual to engage them (eg. Searching keywords for a particular
feature can be a pain -- if you still have to figure out the local
dialect and/or character-symbols.

It is good that Japan, Korea and alikes are technologically-capable of
helping themselves (and won't concern much with the worries of
outsiders not understanding them); because having a common local
language worked for them -- actually made them stronger as a nation.
Localizing default name-labels is an enabler for citizens of these
non-English speaking countries - to disseminate and consume
information efficiently, without a need for an English translator.

But for us who still needs outside help from time to time with
technical & financial aids, or attracting tourists. Introducing
"language-barrier" on maps becomes a dis-abler. Some Filipino words in
fact need translation even to those locals from NCR/Region 4.

Like it or not, English is/was already 'forced on us' through our
education systems; or by business / social pressure to use
technologies with english-default menu system. My impression is, only
a few would like to use Filipino menu-system even if it's available on
devices... well, I feel the same with a general-purpose maps. Besides,
a good number Filipino words are not character-efficient (too long to
write) for labeling purposes on maps + or needs a "glossary" to
understand. :-)

So in terms of naming-convention, I still like to see and use a more
universally readable English label (unless a particular local name
proves more popular) as OSM's default name. That (English) advantage
on naming priorities, has a slight edge over the noble effort for
heritage-preservation (language) advocacy using "default maps" as a
medium. We can always customize maps at the moment

If in the future perhaps, when the Philippines seemingly decides,
(trending at least 40%) in use of local dialects on signboards, then
we may take it as a sign to reconsider to "localize" the default
values for "name="; English will be secondary using name:en=*  --- but
only until then (that's just my opinion).

No issues with adding other local language on name:xx=*

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

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: [Talk-de] Krankenhaus - Eingang

[Walter Nordmann]

Bittschön:

https://wambachers-osm.website/emergency/#zoom=18=54.522479=9.570078=OpenStreetMap.org=TFFF 



Gruss
walter, der für heute die Schna.. von Inkscape voll hat



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

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

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

[François Lacombe]

2017-08-24 23:18 GMT+02:00 Daniel Patterson :

> Franccois,
>
>   In the lua profiles, you can set the `result.is_startpoint` property in
> `process_way` (used to be `way_function`) to determine whether you can snap
> to them.  We currently use this for ferry routes - paths can use them, but
> can't start/end on them.
>
>   Set `is_startpoint` to true for your substations way areas, and
> `is_startpoint` to false for the transmission lines.
>

That's exactly what I need, thank you


>   The route will start by following the outside edge of the substations
> area polygon, but it sounds like that doesn't matter too much to you.
>

It doesn't matter indeed.
But it may be an issue that power lines aren't actually connected to
substation perimeter ?

Like this one : https://www.openstreetmap.org/way/100500802
The outside edge of the substation is the fence surrounding it and power
lines goes above it without connection.

Should I preprocess my data to make it more accessible to osrm or there's
other way ?

Francois
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[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: [OSRM-talk] Use OSRM on rivers, railways, power lines

[Daniel Patterson]

Franccois,

  In the lua profiles, you can set the `result.is_startpoint` property in
`process_way` (used to be `way_function`) to determine whether you can snap
to them.  We currently use this for ferry routes - paths can use them, but
can't start/end on them.

  Set `is_startpoint` to true for your substations way areas, and
`is_startpoint` to false for the transmission lines.

  The route will start by following the outside edge of the substations
area polygon, but it sounds like that doesn't matter too much to you.

daniel


On Thu, Aug 24, 2017 at 1:40 PM, François Lacombe  wrote:

> Hi Daniel, Ricardo,
>
> Thank you for your answers.
>
> I completely agree on necessity of perfect connectivity between features.
> It has been a concern for me regarding power networks for years of
> contribution now.
>
> The challenge is currently to adapt car profile to power lines
> Voltage may act as the maxspeed key, and transformers as toll
>
> As you may see in the relation example I gave, there is two substations at
> the ends of line members.
> Differently from roads or rivers, you can't connect to power lines or
> pipelines anywhere. Start and end into substations is mandatory
> (power=substation or pipeline=substation, they are both areas)
> How can I told osrm to look for the nearest substation before starting
> routing in the graph exclusively composed of power lines or pipelines ?
>
> Guidance information isn't so relevant in such networks, then I will only
> focus on osrm path answer
>
> François
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> 2017-08-24 18:52 GMT+02:00 Ricardo Pereira :
>
>> We use OSRM to route within water only (Oceans and Rivers). It makes
>> absolute no difference what you are routing through as long as you can
>> provide a mesh with your topology.
>> Our Lua script therefore matches the tags that we create for own data,
>> nothing to do with OSM.
>>
>> Cheers
>>
>> On Thu, 24 Aug 2017 at 16:15 François Lacombe 
>> wrote:
>>
>>> Hi all,
>>>
>>> Since there is not only roads but many other topological networks mapped
>>> on OSM, I'm wondering how osrm may be usable on them.
>>>
>>> Example : a power route used to establish a link between two substations
>>> http://www.openstreetmap.org/relation/6694740
>>>
>>> I know pretty well how lua profiles are built, for cars, bike,
>>> pedestrian... but is there any profile available for power or gas pipelines?
>>> Let's say we have proper data, is the profile the only thing to change
>>> to use osrm on pipelines or rivers exclusively ?
>>>
>>> Many thanks for any answer regarding this question
>>>
>>>
>>> François
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

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: [OSRM-talk] Use OSRM on rivers, railways, power lines

[François Lacombe]

Hi Daniel, Ricardo,

Thank you for your answers.

I completely agree on necessity of perfect connectivity between features.
It has been a concern for me regarding power networks for years of
contribution now.

The challenge is currently to adapt car profile to power lines
Voltage may act as the maxspeed key, and transformers as toll

As you may see in the relation example I gave, there is two substations at
the ends of line members.
Differently from roads or rivers, you can't connect to power lines or
pipelines anywhere. Start and end into substations is mandatory
(power=substation or pipeline=substation, they are both areas)
How can I told osrm to look for the nearest substation before starting
routing in the graph exclusively composed of power lines or pipelines ?

Guidance information isn't so relevant in such networks, then I will only
focus on osrm path answer

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2017-08-24 18:52 GMT+02:00 Ricardo Pereira :

> We use OSRM to route within water only (Oceans and Rivers). It makes
> absolute no difference what you are routing through as long as you can
> provide a mesh with your topology.
> Our Lua script therefore matches the tags that we create for own data,
> nothing to do with OSM.
>
> Cheers
>
> On Thu, 24 Aug 2017 at 16:15 François Lacombe 
> wrote:
>
>> Hi all,
>>
>> Since there is not only roads but many other topological networks mapped
>> on OSM, I'm wondering how osrm may be usable on them.
>>
>> Example : a power route used to establish a link between two substations
>> http://www.openstreetmap.org/relation/6694740
>>
>> I know pretty well how lua profiles are built, for cars, bike,
>> pedestrian... but is there any profile available for power or gas pipelines?
>> Let's say we have proper data, is the profile the only thing to change to
>> use osrm on pipelines or rivers exclusively ?
>>
>> Many thanks for any answer regarding this question
>>
>>
>> François
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

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: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

[Mike Parfitt]

How (or who) do we ask for a definition of what the GB Multipolygon is supposed 
to represent within the OpenStreetMap universe ?

From: Stuart Reynolds 
Sent: 23 August 2017 12:05:24
To: Colin Smale
Cc: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

Indeed. I just wanted to ensure that there wasn’t a rush to “define” the GB 
multipolygon strictly according to MHW everywhere.

Cheers
Stuart



On 23 Aug 2017, at 10:56, Colin Smale 
> wrote:


Estuaries are a bit of a special case for the coastline. It is quite normal for 
there to be a straight line across the river mouth for some purposes, but this 
does not imply that waters above that line are not tidal of course.

I think what you are querying, is the link/relationship between:

a) the high-water line

b) the coastline

c) the maritime baselines

d) the "GB multipolygon"



There are of course many possible definitions of the boundary of GB. Coastline? 
(Local) government jurisdiction? Territorial waters? EEZ? AFAIK this polygon in 
OSM is based on the coastline, but I might be wrong...

--colin

On 2017-08-23 10:22, Stuart Reynolds wrote:

On 23 Aug 2017, at 09:00, Mike Parfitt 
> wrote:

If the GB multipolygon should follow the high tide line, then the vast majority 
of the nodes will be situated inshore of those for the administrative/MPA 
boundaries - i.e. all are normally above the water, except for one moment in 
Spring.

The River Thames is tidal as far as Teddington Lock in London. It therefore has 
high and low water marks, and the high water mark is up against the river walls 
in London and, even in Southend where I reside at the other end of the river, 
the mean high tide level is only about 10-20 feet away from the sea wall. Are 
we honestly suggesting that it is correct that the river is not within the GB 
boundary? Or, indeed, Southend Pier. Because that would be the effect of the GB 
boundary religiously following the high water mark!

The usual policy (as per OS) is to draw a north south line across the Thames 
Estuary, which irritates me for other reasons because it is a) artificial and 
b) frequently rendered, but it is better than a blanket assumption that the 
boundary must follow the high water mark.

Regards,
Stuart Reynolds
for traveline south east & anglia



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

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

[Talk-de] Hack-Weekend Karlsruhe 21/22 Oktober

[Frederik Ramm]

Hallo,

   Ende Oktober ist wieder ein Hack-Weekend in Karlsruhe angesagt, und
alle, die nicht ganz allein an ihrem Projekt basteln wollen, sind bei
uns willkommen. Alles weitere hier:

https://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2017

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

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] OSM and science

[Christoph Hormann]

On Thursday 24 August 2017, Frederik Ramm wrote:
>
> It is certainly good for OSM to offer a helping hand to scientists
> who are seeking cooperation. I would also like us to develop a review
> and fact check mechanism for scientific publications on OSM so that
> those who don't bother to get their facts right are held accountable
> for the bad science they inevitably produce.

One thought in that regard: It would in a way be nice if we could get 
members of the OSM community into the peer review process of scientific 
publications related to OSM.  This would allow competent review and 
fact checking of publications beforehand. The problem with that is 
twofold:

* scientific peer review is essentially a closed club you don't normally 
get into if you do not professionally work in the field yourself.
* doing peer review is laborious, thankless work and universally unpaid.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Mapping in HTML - a proposal for a new element

[James]

Specifically, that they have a working example:
https://www.w3.org/community/maps4html/



On Thu, Aug 24, 2017 at 2:22 PM, James  wrote:

> There has already been work like this started by Peter Rushforth over a
> year ago:
> https://www.w3.org/community/maps4html/author/prushfor/
>
> On Thu, Aug 24, 2017 at 1:59 PM, Andy Mabbett 
> wrote:
>
>> My friend Terence Eden has proposed a new HTML element for maps:
>>
>>https://shkspr.mobi/blog/2017/08/mapping-in-html-a-
>> proposal-for-a-new-element/
>>
>> I've already left some comments on his post.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
>
> --
> 外に遊びに行こう！
>



-- 
外に遊びに行こう！
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping in HTML - a proposal for a new element

[James]

There has already been work like this started by Peter Rushforth over a
year ago:
https://www.w3.org/community/maps4html/author/prushfor/

On Thu, Aug 24, 2017 at 1:59 PM, Andy Mabbett 
wrote:

> My friend Terence Eden has proposed a new HTML element for maps:
>
>https://shkspr.mobi/blog/2017/08/mapping-in-html-a-proposal-
> for-a-new-element/
>
> I've already left some comments on his post.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
外に遊びに行こう！
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Yves]

What an out of topic festival! Phone models, routers, rendering styles, what 
else? 
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and science

[Frederik Ramm]

Hi,

   commendable initiative.

On 08/24/2017 06:54 PM, joost schouppe wrote:
> Together, we outlined some very basic ideas about what we think we could
> do to help foster closer relations, and published them on my OSM diary:

I'm still fond of this 2011 advice for scientists by Muki Haklay:

https://povesham.wordpress.com/2011/07/16/observing-from-afar-or-joining-the-action-osm-and-giscience-research/

Quoting from that:

Rule 1: do some mapping
Rule 2: read (books, wiki, blog, mailing lists)
Rule 3: explore the data, then talk with someone in the community to
check that you've got it right!
Rule 4: put outputs in open access
Rule 5: publish and share data you have processed
Rule 6: be a "critical friend" to OSM
Rule 7: teach

This advice is often ignored. I have a feeling that there might be a
fundamental problem because scientists - especially junior ones - often
believe that if you interact too much with the object of your research,
you might lose objectivity and not be taken seriously. Taken to the
extreme, this would mean that you can't be a mapper if you want to
publish meaningful science about OSM, and ideally you shouldn't even be
friends with mappers. (I know one person who did their PhD on OSM and
who explicitly said to me, before that, that they didn't want to be
perceived as "part of the community" lest it would reflect badly on
their thesis.) On the other hand, a lack of communication by a scientist
looking at OSM is often perceived as arrogance on OSM's side (even more
so if the resulting talk/paper/article gets the facts wrong because of
this).

It is certainly good for OSM to offer a helping hand to scientists who
are seeking cooperation. I would also like us to develop a review and
fact check mechanism for scientific publications on OSM so that those
who don't bother to get their facts right are held accountable for the
bad science they inevitably produce.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[OSM-talk] Mapping in HTML - a proposal for a new element

[Andy Mabbett]

My friend Terence Eden has proposed a new HTML element for maps:

   
https://shkspr.mobi/blog/2017/08/mapping-in-html-a-proposal-for-a-new-element/

I've already left some comments on his post.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

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] OSM and science

[joost schouppe]

Hi,

OpenStreetMap is a hot topic to some research communities, and research
results can be hot topics within the OSM community - or sometimes they get
overlooked completely.

Peter Mooney, Frank Osterman and myself think there are benefits to
improved relations. The quite critical OSM community could for example be
more involved in creating research questions or suggesting methodologies,
which could lead to results that are more useful.

Together, we outlined some very basic ideas about what we think we could do
to help foster closer relations, and published them on my OSM diary:

http://www.openstreetmap.org/user/joost%20schouppe/diary/42134

We're looking forward to your ideas, both when it comes to methods for
improvement, as well as for  specific research ideas.

We don't mean to say anyone is doing a bad job. We just think that with
your help we might be able to make life just that little bit easier for
both the OSM and the research community.

-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

[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: [Talk-GB] Public Rights of Way in Oxfordshire and Hampshire

[Robert Whittaker (OSM lists)]

On 23 August 2017 at 15:25, Philip Withnall  wrote:
> On Tue, 2017-06-27 at 11:30 +0100, Robert Whittaker (OSM lists) wrote:
>> Some of you have have already come across my Public Rights of Way
>> comparison tool at http://robert.mathmos.net/osm/prow/progress/ which
>> aims to help mappers trying to complete the mapping of Rights of Way
>> in their area.

> I’d be interested in the data for Cumbria and Lancashire being on
> there, though I’m unlikely to be able to devote any time to getting
> hold of the data or using the output from the tool for a month or two.
> I guess you can consider this a statement of interest. :-)

Lancashire have already released their data privately to rowmaps, so
would hopefully be amenable to providing it for use in OSM if someone
asked. Cumbria do have the GIS data, but might it might be more of a
problem getting them to release it judging by
https://www.whatdotheyknow.com/request/prow_data_14 . Since it might
take some time, I've put in an FOI/EIR request at
https://www.whatdotheyknow.com/request/public_rights_of_way_gis_data_an_2
and we'll see what happens.

BTW: To help keep track of where we are with data availability and
licensing from different councils, I've set up
http://robert.mathmos.net/osm/prow/progress/open-data . If you know of
any significant stuff that needs adding / updating there, please let
me know.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

[Daniel Patterson]

Hi Francois,

  In theory, yes, you could route on powerlines, gas lines, or any other
linear feature.  Ensuring connectivity could be problematic - often rivers
are not connected to paths in OSM.

  Waterways are a bit problematic as they're often modeled as areas - if
you modify the Lua script to include them in the routing graph, OSRM will
route around the edges of the polygon.

  Getting proper connectivity between all the elements you want to route
between can be problematic as well - very often, rivers/rail are not
connected to roads or paths inside OSM.

  The turn-by-turn instructions might also be a bit weird if you don't
route on roads/paths - the guidance code has been mostly focused on
sensible instructions for drivers.

daniel

On Thu, Aug 24, 2017 at 6:27 AM, François Lacombe  wrote:

> Hi all,
>
> Since there is not only roads but many other topological networks mapped
> on OSM, I'm wondering how osrm may be usable on them.
>
> Example : a power route used to establish a link between two substations
> http://www.openstreetmap.org/relation/6694740
>
> I know pretty well how lua profiles are built, for cars, bike,
> pedestrian... but is there any profile available for power or gas pipelines?
> Let's say we have proper data, is the profile the only thing to change to
> use osrm on pipelines or rivers exclusively ?
>
> Many thanks for any answer regarding this question
>
>
> François
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

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] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/08/17 15:16, Andy Townsend wrote:
> No idea what router you're using, but a common-or-garden Garmin satnav
> using OSM data is pretty much bang on timing-wise for rural routing
> around here.
> 
>>   - and get my blue motorway, green trunk and red
>> primary road back :)
>>
> I don't think we're actually short of map tiles with those colours :) 
> The UK/IE ones that I create are like that, and many others are too -
> either styles not updated since 2014 or deliberately chosen to look that
> way.

OSMAND on a Samsung S6 phone :)
My old dedicated sat nav did a good job as well as handling hands free
calls on the N900 mobile. Modern options are going down hill fast and
can't even do the basics! Simple reception of a signal would be nice to
have once again ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-ja] OSM編集ピアレビューのワークフローアイデア

[Satoshi IIDA]

いいだです。

ありがとうございます。
先程日記の方にコメントありまして、つい先日開発が行われ、次のバージョンのiDエディタでほぼ同様の機能が実装されるとのこと。

思わず笑ってしまいましたが、とても楽しみなかんじです。

日本コミュニティとして、日本でヘルプを求めているかたに日本語で手を差し伸べてゆくことができるようになるといいな、と思います。
Mapboxチームから英語ではコメントできると思うのですが、日本語のほうが対応しやすい場合もあるはず。

次のバージョンを待ちましょう！






2017年8月24日 20:42 :

> ほんとに一言だけ。
>
> これは面白そうなアイデアだなーと思いました。
>
> 2017年8月24日 18:05 +0900、Satoshi IIDA のメール:
>
>
> いいだです。
>
> SotM Aizuwakamatsuのなかで、Arunさん（Mapbox）と話す機会があり、
> OSM編集のピアレビューのワークフローを作れないかなー、という話のなかで、
> ひとつアイデアがでてきたので、軽く説明を書いてみました。
>
> 簡単に言うと、「変更セットに、レビュー希望のコメント入れるようにして、OSMChaで拾おうぜ」です (^^;
>
> http://www.openstreetmap.org/user/nyampire/diary/42126
>
> 英語での説明なのですが、なんとなく雰囲気はわかるかな、と思います。
>
> コメントなどあればいただけると嬉しいです。
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Andy Townsend]

On 24/08/2017 14:18, Lester Caine wrote:


The starting point is the raw data in OSM ... but when something does
not look right in using that data just where do you start? I know my own
problems are mainly how the data is used and if I had more time I would
look to adjust the assumptions to give a more realistic 'fastest' route
for UK rural areas


No idea what router you're using, but a common-or-garden Garmin satnav 
using OSM data is pretty much bang on timing-wise for rural routing 
around here.



  - and get my blue motorway, green trunk and red
primary road back :)

I don't think we're actually short of map tiles with those colours :)  
The UK/IE ones that I create are like that, and many others are too - 
either styles not updated since 2014 or deliberately chosen to look that 
way.


Best Regards,

Andy



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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/08/17 13:15, Greg Troxel wrote:
> I might experiment with a few roads.  But people should not worry that
> I'll do anything large scale (more than 30 minutes in JOSM, the unit of
> editing :-) -- I agree this is complicated and not resolved.  I view it
> as an eventual step towards better routing.

The starting point is the raw data in OSM ... but when something does
not look right in using that data just where do you start? I know my own
problems are mainly how the data is used and if I had more time I would
look to adjust the assumptions to give a more realistic 'fastest' route
for UK rural areas - and get my blue motorway, green trunk and red
primary road back :)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Greg Troxel]

Richard  writes:

> On Tue, Aug 22, 2017 at 08:09:25PM -0400, Greg Troxel wrote:
>> 
>> john whelan  writes:
>> 
>
>> > As someone who lives in a city street with one school in the middle and one
>> > at either end posted at 40 km/h with an average traffic speed of 60 km/h
>> > and over 100 km/h from some high school kids driving to and from school I
>> > would prefer it if traffic stuck to the posted speed limits.  Cars running
>> > across front lawns to avoid collisions are not unknown.
>> 
>> That sounds crazy, but I would guess that it isn't the people actually
>> paying attention going 48 that are the real issue!  But in all
>> seriousness, that sounds like an actual problem, not an OSM
>> representation problem.
>
> it would become an OSM problem if someone decides to tag this road 
> with maxspeed:practical=60. A router may then decide to route you 
> to this route instead of some alternative that would be much faster 
> for people who decide to respect speed limits at schools.

That's a fair point.  But, I wonder how waze and apple maps handle this.
I suppose one could find the dividing point experimentally and infer it.

In the end, though, if a router is actually faster when driving with the
flow of trafic, I don't see it as OSM's place to make it not seem that
way, and the above case really seems to need the attention of the
authorities.

> In cities I believe that maxspeed:practical can be usefull foremost
> in situations where traffic flow is for whichever reason much slower 
> than could be expected for an average city road tagged identically.
> That is because on average other factors like traffic lights, left
> turns, yielding etc determine the travelling speed much more then
> driving speed. None of those OSM and OsmAnd is particularly good at..

Agreed, mostly, but lights should be modeled by routers and if they
aren't, it isn't good to bury it in something else.  But for things that
aren't inferrable from tags I agree.

> Also consider the effect of the majority and other statistical effects. 
> If in Montana or wherever it is common to drive 20-40 miles faster 
> than posted on most rural roads than the router will probably do correct 
> routing decissions on average even without maxspeed:practical. 

You have a really good point and I agree that it's complicated.  But at
least around me, people drive a little bit faster than posted in most
places, and a lot on some roads.  Basically the speed limits are
sometimes correct (85% rule) and sometimes very much under.

I think your point about errors between (whatever tag, including
maxspeed) and reality being an error is valid even now, but I agree we
need to not make things much worse.

So I'm seeing a systematic bias (in fastest time mode) to slower,
shorter routes.

I should get some actual data and compare reality to OSM more
systematically.

> Tagging some roads with maxspeed:practical would have only the 
> effect to distort routing decissions. You owwould have to tag the 
> large majority of roads with this tag to achieve a similar effect 
> like not having it on any of those roads.h

That's a fair point in theory.  It's a good question how many roads need
to be adjusted to have things make sense.  Around me, adjusting the
interstates and route 2 would help vastly.

Maybe we need a "maxspeed:speed_limit_ought_to_be".  Really I mean
"people drive like the speed limit is X, and that's ok".  I'm sort of
joking, but will ponder.

I might experiment with a few roads.  But people should not worry that
I'll do anything large scale (more than 30 minutes in JOSM, the unit of
editing :-) -- I agree this is complicated and not resolved.  I view it
as an eventual step towards better routing.



signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [Talk-cz] Znaceni pruchodnosti was Re: WeeklyOSM CZ 367

[majka]

Podle mého je každá cesta do terénu i v Čechách riziko ohledně
průchodnosti, a dělat závěry jen na základě mapy či jakéhokoli pohledu z
dálky je problém.

Očekávat u hospodářského lesa v Čechách průchodnost se sice často dá, ale
těch z různých důvodů neprůchodných (a to nemyslím třeba někde na Šumavě či
v hloubi lesa) jich bývá víc než dost zrovna tam, kde se to nejméně hodí.
Pokud chce někdo konkrétní tip, můžu jich několik z letošního léta
poskytnout.

Obvykle na to narazím v okamžiku, kdy očekávám průchod po lesní cestě (či
pěšině), a ono to z nějakého důvodu nejde (3m vysoký plot přes lesní cestu
na obou stranách; plot čísi zahrady na kdysi průchozí polní/lesní cestě). V
obou případech okolo smrkový les, v tom druhém spíš soušky na stojato,
suché větve a větvičky až na zem. První jsem se silou prodrala, druhé jsem
se po delší době hledání průchodu vrátila.

A takové kácení v lese, ke kterému došlo třeba i před rokem, ale zůstala
paseka s pařezy a roštím, která spokojeně zarůstá vysokou trávou, dokáže
dostatečně zneprůchodnit i značené turistické stezky - kromě toho, že
samozřejmě přetne značení.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-ja] OSM編集ピアレビューのワークフローアイデア

[tarokawa]

ほんとに一言だけ。

これは面白そうなアイデアだなーと思いました。

2017年8月24日 18:05 +0900、Satoshi IIDA のメール:
>
> いいだです。
>
> SotM Aizuwakamatsuのなかで、Arunさん（Mapbox）と話す機会があり、
> OSM編集のピアレビューのワークフローを作れないかなー、という話のなかで、
> ひとつアイデアがでてきたので、軽く説明を書いてみました。
>
> 簡単に言うと、「変更セットに、レビュー希望のコメント入れるようにして、OSMChaで拾おうぜ」です (^^;
>
> http://www.openstreetmap.org/user/nyampire/diary/42126
>
> 英語での説明なのですが、なんとなく雰囲気はわかるかな、と思います。
>
> コメントなどあればいただけると嬉しいです。
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Andy Townsend]

On 24/08/2017 11:49, Richard wrote:


it would become an OSM problem if someone decides to tag this road
with maxspeed:practical=60. A router may then decide to route you
to this route instead of some alternative that would be much faster
for people who decide to respect speed limits at schools.


If a router uses a higher maxspeed:practical in preference to a lower 
maxspeed log a bug with it :)



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

Re: [Talk-cz] Znaceni pruchodnosti was Re: WeeklyOSM CZ 367

[Miroslav Suchy]

Dne 23.8.2017 v 21:00 Jan Macura napsal(a):
V ČR se vzrostlý neprůchodný les vyskytuje velmi vzácně. Neprůchodná bývá spíš mladší vegetace s křovinami na rumištích 
nebo polomech, což je ovšem převážně dočasný stav.


Nesouhlasím. Pod pojmem průchodné si představuji "projdu tam se vztyčenou hlavou aniž bych se musel bát, že mě něco 
šlehne nebo abych ohýbal větve". Nebo-li "kam můžu jít pohodlně na houby".
Těch neprůchodných oblastí je hodně. Buď to je mladá smrčina před pořízkou (větve až na zem). Nebo starý les s vysokým 
podrostem (maliní, ostružiní). Případně zejména kolem potoků dost často bývá hodně kopřiv, což je také neprůchozí.


Mirek

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Richard]

On Tue, Aug 22, 2017 at 08:09:25PM -0400, Greg Troxel wrote:
> 
> john whelan  writes:
> 

> > As someone who lives in a city street with one school in the middle and one
> > at either end posted at 40 km/h with an average traffic speed of 60 km/h
> > and over 100 km/h from some high school kids driving to and from school I
> > would prefer it if traffic stuck to the posted speed limits.  Cars running
> > across front lawns to avoid collisions are not unknown.
> 
> That sounds crazy, but I would guess that it isn't the people actually
> paying attention going 48 that are the real issue!  But in all
> seriousness, that sounds like an actual problem, not an OSM
> representation problem.

it would become an OSM problem if someone decides to tag this road 
with maxspeed:practical=60. A router may then decide to route you 
to this route instead of some alternative that would be much faster 
for people who decide to respect speed limits at schools.

In cities I believe that maxspeed:practical can be usefull foremost
in situations where traffic flow is for whichever reason much slower 
than could be expected for an average city road tagged identically.
That is because on average other factors like traffic lights, left
turns, yielding etc determine the travelling speed much more then
driving speed. None of those OSM and OsmAnd is particularly good at..

Also consider the effect of the majority and other statistical effects. 
If in Montana or wherever it is common to drive 20-40 miles faster 
than posted on most rural roads than the router will probably do correct 
routing decissions on average even without maxspeed:practical. 
Tagging some roads with maxspeed:practical would have only the 
effect to distort routing decissions. You would have to tag the 
large majority of roads with this tag to achieve a similar effect 
like not having it on any of those roads.

Richard

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

[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-ja] JOSMの妥当性検査のルールはどこ?(bridge:name,tunnel:nameタグの警告を消したい)

[Jun NOGATA]

野方です。

とりあえず橋とトンネルは直しました。
https://josm.openstreetmap.de/wiki/Presets/Japan?action=diff=3

さて、

2017年8月23日 21:15 Satoshi IIDA :
> あるいはいっそプリセットごと外す、というのもひとつの手ではありますが、
> JOSMを初めて触るかたにとってプリセットは非常に有益でもあり、使い続けるほうがよいかな？という印象です。
> ご意見いただけると嬉しいです。

twitterでは「外しましょう」と書きましたが、現状、個人では使わないほうが
いいと思ったので外しましょうと書きましたが、プリセット自体から外すのは
もう少し考えてもいいかなと思います。

ただ、残すにしてもHow to Map Aからの変換自動化とか考えないと、
現状に追従できなくて使えなくなるパターンになりそうなので、
なにか、いい案があればいいのですが。

単純に表を変換しても書式がマチマチになってたりするので
なにかしら手作業が発生しそうな感じ。



2017年8月23日 21:15 Satoshi IIDA :
>
> いいだです。
> 調査ありがとうございます。
>
> うーん、ちょっと本腰入れて修正かけないといけないかんじがしますね。
> まずは現行のHow to Map Aの内容をプリセットに反映させる、という方向でいったん状況を直すのがよいのかな、と思います。
> （次に、How to Map Aをもう一度見直して、細かい修正をもう一度プリセットに反映する）
>
> あるいはいっそプリセットごと外す、というのもひとつの手ではありますが、
> JOSMを初めて触るかたにとってプリセットは非常に有益でもあり、使い続けるほうがよいかな？という印象です。
> ご意見いただけると嬉しいです。
>
>
>
>
> 2017年8月23日 20:35 Jun NOGATA :
>>
>> 野方です。
>>
>> わかりました。
>> タグ付けプリセットに「日本語五十音」を入れてましたが、妥当性検査はプリセット
>> データを見てるらしく、日本語五十音が間違っているせいでエラーになってた
>> ということのようです。
>>
>> 原因としては、ググってたらみつけたこれと同じようで
>>
>> * [OSM-ja] JOSM 日本語五十音プリセットの不具合:
>>
>> https://lists.openstreetmap.org/pipermail/talk-ja/2015-September/009067.html
>>
>> 日本語五十音プリセットは長くメンテされてないようですし、問題もあるので、
>> 外してもらうか何か対策をしないといけないかもですね。
>>
>> # タグ付けには使わないからいいやと放っておいたらこんな罠があったとは…
>>
>>
>> 2017年8月23日 10:21 Jun NOGATA :
>> > こんにちは。野方です。
>> >
>> > 変更セットのコメントで「橋の名前とトンネルの名前タグにbridge_name,
>> > tunnel_nameタグを使ってましたが、bridge:name, tunnel:nameに修正しました」
>> > とコメントをいただきました。
>> > http://www.openstreetmap.org/changeset/50036674
>> >
>> > 確かJOSMの妥当性検査で警告が出て直した記憶があったので確認すると、
>> > tunnel:nameタグの部分で
>> > 「プロパティキーの綴り間違い-'tunnel:name'キーは'tunnel_name'ではないでしょうか」
>> > と警告が出ます
>> >
>> > bridge:name, tunnel:nameの警告を無効にしたいと思うのですが、
>> > ルールはJOSMのどこで定義されているのでしょうか。
>> >
>> > --
>> > 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
>> >  - web: http://www.nofuture.tv/diary/
>>
>>
>>
>> --
>> 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
>>  - web: http://www.nofuture.tv/diary/
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>
>
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>



-- 
野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
 - web: http://www.nofuture.tv/diary/
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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: [talk-ph] [SPAM] Re: Philippine multilingual place names (English/native language)

[Ronny Ager-Wick]

I would like to chime in here. I agree with Eugene - I don't think listing 
multiple names in the name=* tag is a good practice, maybe except in a few 
very specific cases where it is hard to say whether a name is actually a 
common name even in English texts, but I don't think there should be many of 
those cases, if any. Tagalog should be avoided completely in non-Tagalog areas 
(and even those that were *originally* non-tagalog, as place names tend to lag 
far behind language shifts).
It makes good sense to use the English name as default, as Eugene mentioned, 
it is an official language, and it doesn't bear the same political connotation 
as the use of Tagalog. Of course, English is not the native language either; 
Cebuano, Ilocano, Kapampangan, etc. are. I find though that many place names 
are used in their English form even by locals - with exceptions of course.
Eugene's suggestion to use native form "when the native form is overwhelmingly 
used even in English texts" makes perfect sense to me. There's no point 
translating a commonly used name to English. I can think of a few, like 
"Pulung Maragul" in Angeles, which in Kapampangan means "Big Island" - a name 
nobody would recognize, or "Patio" in Magalang - which is the Town Plaza, but 
everyone of course calls it Patio. Or Cong Dadong Dam - I have never heard 
anyone call it anything else. Even kids who do not speak English calls it "dam".
At least in Pampanga, which is the place I know, everybody including locals 
refer to the road names as "___ Road" or "___ Street", not "Dalan ___", which 
would be the local name, and certain natural places like a water fall is 
referred to by locals as "___ Falls", not to mention "Mount Arayat", which is 
technically "Bunduk Arayat" in Kapampangan, but most people use the English 
name, so using English as default here seems perfectly logical.


That said, from a linguistic heritage point of view, I would prefer if roads 
in Pampanga would be called "Dalan Arayat", etc. instead of "Arayat Road", and 
similar in other areas with other languages, but this is simply not the case, 
and maps should reflect reality, so personal preference is not relevant here.


It must be said that I neither am nor look like a Filipino, so people may 
choose to use English names around me for that reason, but given that I 
generally speak Kapampangan (with a great number of grammatical mistakes, I'm 
sure, but still) when in Pampanga, I don't think this is much of a problem. 
Still worth considering.


In essence, the priority list could be:
1. Commonly used local name (even in English texts)
2. In the absence of the above, English

Ref:
Pulung Maragul:  http://www.openstreetmap.org/node/963007863
Patio, Magalang: http://www.openstreetmap.org/way/28855819
Cong Dadong Dam: http://www.openstreetmap.org/way/262208377

Another thing to consider - what about places and roads officially named after 
politicians (typically), but which name locals have not adopted (and perhaps 
never will)? I would tend to prefer the name actually in use, ignoring the 
"official" name.

One pretty prominent example: http://www.openstreetmap.org/way/312897853
I think it's officially named Diosdado Macapagal International Airport, but I 
have yet to hear a single person refer to it as anything but "Clark".


Ronny.


On 2017-08-23 14:03, ianlopez wrote:
In a lot of cases, I'm going with the "what locals call it" plus "official 
name" rule of thumb when using the name=* tag, aside from the numerous name:xx 
tags used in mapping the Philippines. Aside from Eugene's examples, another 
specific case would be Taal, Batangas where the street names in its poblacion 
area are appended with "Calle" instead of "Street".



-
Blog: http://ianlopez1115.wordpress.com/
OpenStreetMap/Twitter: ianlopez1115
Facebook: ian.lopez


--
*From:* Eugene Alvin Villar 
*To:* Jherome Miguel 
*Cc:* talk-ph 
*Sent:* Wednesday, August 23, 2017 11:10 AM
*Subject:* Re: [talk-ph] Philippine multilingual place names (English/native 
language)


On Wed, Aug 23, 2017 at 9:23 AM, Jherome Miguel > wrote:



It already looks important to have place names under the name= tag be
bilingual or multilingual, not just in English, especially when taking
regard speakers of native languages (Tagalog, Cebuano, Hiligaynon,
Kapampangan, Ilocano, etc.), and use of native. I am proposing a scheme
where the name under the place tag would have English as first name, and
second name in the Tagalog (usually formal), and the third name in the
native language (on places other than those in Tagalog speaking areas)


[Oops. Sent too early.]

So in essence, you want to propose something like what is done in Belgium?

I don't agree. I want the name=* to use just a single name, 

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

[talk-au] Collaborative Australian Protected Areas Database (CAPAD) 2016

[nwastra]

Hi
I had been expecting that valid explicit permission to use Collaborative 
Australian Protected Areas Database (CAPAD) 2016 to edit and add information to 
the OpenStreetMap would have been obtained by now but I assume that the legal 
licence compatibility issues need to be resolved. 
Is there an estimated timeframe to resolution?

regards
Nev Wedding
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-ja] OSM編集ピアレビューのワークフローアイデア

[Satoshi IIDA]

いいだです。

SotM Aizuwakamatsuのなかで、Arunさん（Mapbox）と話す機会があり、
OSM編集のピアレビューのワークフローを作れないかなー、という話のなかで、
ひとつアイデアがでてきたので、軽く説明を書いてみました。

簡単に言うと、「変更セットに、レビュー希望のコメント入れるようにして、OSMChaで拾おうぜ」です (^^;

http://www.openstreetmap.org/user/nyampire/diary/42126

英語での説明なのですが、なんとなく雰囲気はわかるかな、と思います。

コメントなどあればいただけると嬉しいです。


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] State of the Map2017 in Aizuwakamatsu開催報告と御礼

[Satoshi IIDA]

いいだです。

みなさまおつかれさまでした！
OSMF本家からも感謝コメントのブログが公開されています。

これからよりよい地図を、みんなで一緒に、楽しみながら作れたらうれしいです。

https://blog.openstreetmap.org/2017/08/23/thanks-
sotm2017-organisers/?lang=ja


また、上記のブログでも触れられていますが、
カンファレンスの写真が、Facebookのグループ中心に公開されています。

https://www.facebook.com/groups/SotM2017Aizu/?fref=ts
(Flickrにもあります) https://www.flickr.com/photos/tags/sotm2017


ぜひぜひご覧ください！


2017年8月23日 6:03 jun meguro :

> State of the Map2017 in Aizuwakamatsu実行委員会代表の目黒です。
>
> 去る8月18日から20日にかけて、State of the Map2017 in Aizuwakamatsu（以下SOTM）が開催されました。
>
> 概算ではありますが、来場者数は200名、3日間のべ参加者数は550名に登り、交通面での不利をものともしない盛大な規模となりました。（
> この他、スタッフボランティア参加38名、発表41件、ライトニングトーク16件、ワークショップ10件、県立博物館オプショナルツアー37名）
>
> また今回のSOTMは通算10回目の開催というだけでなく、過去に例のない同一国での2回目の開催という快挙でもありました。
>
> 世界30カ国から集った参加者は、カンファレンスで知識を共有し、史跡鶴ケ城で歴史に触れ、そしてコミュニケーションを更に深めた後、
> 再び各々のホームグラウンドへと戻っていきました。
>
> 開催にあたり、地元福島のローカルコミュニティをはじめ、OSM-FJの皆さんと、またOSMに携わる全国・全世界のコミュニティの協力を頂きました。
>
> この中の誰が欠けても同じクオリティを作り上げることは難しく、最高のメンバーとコミュニティによって継続されてきた活動の、
> ひとつの結実であったと感じています。
>
> ここ数日胸に去来するのは、大きな達成感と、また裏腹の物寂しい喪失感であるかも知れません。
> しかし我々マッパーが満たすべき空隙は広く、胸中に火点が灯るのはすぐさまの事だろうと思います。
>
> 昨年の今頃、我々が感じていた不安と熱はいま、ミラノへ移りました。
> 遠い友人達と再び相まみえるまで、手足が届く限りの空間を、今はマッピングして行きましょう。
>
> あらためて皆様、ご協力ありがとうございました。
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Philip Barnes]

On 24 August 2017 01:09:29 BST, Greg Troxel  wrote:
>
>My impreession is that in the UK, there were A/B/C/U, and then later M
>were created, and I'm not sure when trunk happened.
>
The term trunk goes back long before OSM, they date back to The Trunk Roads Act 
1936.

On the ground trunk roads are denoted by green signs and are mostly A roads, 
but there are exceptions such as a B road linking the trunk A6 to the M6 near 
Shap. 

Other A roads have white signs. 

HTH Phil (trigpoint) 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [osm-ve] duda sobre el abae y el satelite francisco de mranda

[Wladimir Szczerban]

Hola Michael,

No se que tipo de licencia tienen las imágenes del abae. Me imagino que es
una licencia abierta (de atribución o similar) y que sólo tendrías que
poner en las ediciones el source (
http://wiki.openstreetmap.org/wiki/Key:source) que corresponda (Ej. source:
abae).

La cosa es ver la licencia de las imagenes y si es compatible con la de OSM.


El 24 de agosto de 2017, 7:29, Michael Ramirez 
escribió:

> mi pregunta es: es posible utilizar las imagenes y datos que brinda el
> satelite francisco de miranda a traves del abae para enriquecer la base
> de datos de osm sobre venezuela, por decirlo de alguna manera... y si no
> se pudiera hacerlo, me gustaria saber cuales serian los inconvenientes
> que lo impedirian...?
>
>
> Atte.
>
> Michael Ram??rez.
> http://about.me/radical_michael
>
> ___
> Talk-ve mailing list
> Talk-ve@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ve
>
>


-- 
Saludos,

Bolo
www.geoinquiets.cat
___
Talk-ve mailing list
Talk-ve@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ve

Re: [Talk-de] OSGeo/FOSSGIS/OSM-Stand auf der FrOSCon

[lars lingner]

Hallo zusammen,

ich habe die Froscon leider nur aus der Ferne verfolgt und bin sehr
dankbar für die aufgenommenen Videos [1]. Einige habe ich auch noch vor mir.

So einen Drucker dabei zu haben verursacht echt Aufwand. Aber wenn alles
läuft, lockt die Neugier doch viele Besucher an. Schön das es geklappt
hat, auch mit wenig "Ausbeute".


Viele Grüße

Lars


[1] https://media.ccc.de/c/froscon2017


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