Re: [Talk-cz] Nadrzovy dvur

[Marián Kyral]

Dne 27.3.2018 v 21:44 jzvc napsal(a):
> Dne 26.3.2018 v 14:56 Mikoláš Štrajt napsal(a):
>>
>>  > To, ze je v natural napsano water, bych neresil.
>>     Já bych to teda viděl jako nevhodné.
>>     Tohle použití podle mě typický trolltag -
>>     https://wiki.openstreetmap.org/wiki/Cs:Trolltag
>>     Nejdříve řeknu, že je to voda a pak druhým tagem, že vlastně není.
>>     Myslím, že vetšina uživatelů to bude pak zpracovávat jako vodu,
>>     protože značku reservoir_type=chemical nepochopí.
>>
>>     To už bych to spíše radši značil tímhle
>>     https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dbasin
>>
>>
>> tak to jsem viděl spíš landuse=basin
>
> Cus, ten je taky jenom vodni ...
>
> "An area of land artificially graded to hold water."
>
> To je typickej problem tagovani OSM, ze ho nikdo moc nepromysli, zacne
> se to pouzivat a pak se na to narazi.

Definice na wiki se dá (po diskusi) upravit. Třeba tak, že je to nádrž
na tekutiny, kde tekutina je specifikována tagem xy a pokud není
specifikována, jedná se o vodu.
Ten dodatečný tag bych asi nedával "water=yes", "chemical=yes", protože
pak dojde k situaci, kdy se tam ty tagy objeví oba.
Ale dalo by se třeba použít schéma: "basin:for=chemical". Případně jiné

Marián


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

[talk-ph] Fwd: [OSM-talk] New MapRoulette version

[Eugene Alvin Villar]

-- Forwarded message --
From: Martijn van Exel 
Date: Thu, Mar 29, 2018 at 1:44 AM
Subject: [OSM-talk] New MapRoulette version
To: OSM Talk 


Hi all,

MapRoulette v3 is now in public beta. I wrote a diary highlighting the main
new features. Please give it a try and let me know what you think about it.
Thanks!

Diary: https://www.openstreetmap.org/user/mvexel/diary/43596
Link to beta: http://maproulette.org/mr3
Github repo: https://github.com/maproulette/maproulette3
OSM wiki (still need to update): https://wiki.openstreetmap.
org/wiki/MapRoulette

--
  Martijn van Exel
  m...@rtijn.org

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

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Martijn
Si je comprends bien ton message, tu proposes que la communauté canadienne 
accepte de réaliser les projets de Telenav, sinon, votre équipe prendra le 
contrôle ?  À mon avis, cette proposition ignore le rôle des communautés 
locales dans le projet OSM, et le réduit à celui d'exécutants.

Les commentaires des contributeurs canadiens allaient tous dans le même sens. 
Nous ne comprenons pas ce que vous visez exactement. Si une simple relation 
Transcanadienne répond à vos besoins, je penses que vous pouvez le réaliser 
facilement. 
Par contre, les contributeurs canadiens ont exprimé leur désaccord à ce que 
vous modifiez systématiquement les routes pour normaliser les noms selon les 
besoins de votre équipe. 
Pierre 
 

Le mercredi 28 mars 2018 15 h 43 min 31 s HAE, Martijn van Exel 
 a écrit :  
 
 Pierre, 

Consistency in the data is the main goal. This benefits all the things you 
mention, including map rendering and parsing by navigation software such as 
ours but also OSMAnd, maps.me and others.
There is a master relation for the Trans-Canada Highway / Route 
Transcanadienne[0] but it is incomplete and broken. One idea would be to repair 
it, and the province-level relations that would be the members of it. Would you 
be interested in coordinating that?

[0] https://www.openstreetmap.org/relation/1307243
--
  Martijn van Exel
  m...@rtijn.org
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Nelson A. de Oliveira]

2018-03-28 20:35 GMT-03:00 Fidelis Assis :
> Bem, acho que não fui muito claro. O que eu sugeri antes em outras palavras
> foi esquecer essa palava câmera :). E passar a interpretar o mapeamento de
> sensor de velocidade em nó de via não como mapeamento de câmera e sua
> direção mas do sensor mesmo! Aqueles sensores magnéticos ou de peso que
> ficam sob o asfalto na grande maioria dos "radares" fixos de trânsito.

Mas aí vai mudar a semântica do speed_camera.
Da mesma forma que vai mudar se usar backward/forward como a direção a
que ela se aplica.

Vai ser outra jabuticaba no Brasil, diferente do resto do mundo :-)

No dia 31 de janeiro tinha 28 câmeras com backard/forward no Brasil.
Hoje já tem 41.

Eu tentei pedir para que isso ficasse um pouco mais explícito no iD,
mas não consegui.
https://github.com/openstreetmap/iD/issues/4757

A relação de enforcement é mais complexa, mas já é o modelo válido
para se definir para que sentido se aplica ou não o aviso (e existe
desde 2009 
https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:enforcement)

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

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Fidelis Assis]

Em 28 de março de 2018 14:50, Nelson A. de Oliveira 
escreveu:

> 2018-03-28 13:57 GMT-03:00 Flavio Bello Fialho :
> > Dessa forma, para highway=speed_camera, recomendo usar
> > direction=forward ou direction=backward, em casos de via de mão dupla
>
> Isso não serve pra nada :-)
> O direction para speed_camera não indica a direção a que se aplica o
> radar. É apenas o lado para onde a câmera está apontando.
>

Bem, acho que não fui muito claro. O que eu sugeri antes em outras palavras
foi esquecer essa palava câmera :). E passar a interpretar o mapeamento de
sensor de velocidade em nó de via não como mapeamento de câmera e sua
direção mas do sensor mesmo! Aqueles sensores magnéticos ou de peso que
ficam sob o asfalto na grande maioria dos "radares" fixos de trânsito.

Quebrando essa associação de sensor de velocidade com câmera evitamos essa
confusão de direção do alerta com direção da câmera, já que esta é
realmente irrelevante para alertas. Aí então passaríamos a falar de direção
do sensor ao usar forward/backward, indicando a direção do tráfego que ele
fiscaliza.

Creio que se alguém desejar mapear direção da câmera propriamente dita pode
então usar uma relação de enforcement que define naturalmente a direção do
alerta e inserir a direção da câmera com direction no device.

Abraços,
-- Fidelis
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 28. Mar 2018, at 18:40, Cascafico Giovanni  wrote:
> 
> Sul nome, in effetti il dataset contiene il campo "nome impianto", ma sono 
> decisi da i gestori e mi sembrano troppo eterogenei



in realtà sono sempre i gestori a decidere il nome di un esercizio commerciale, 
negozio , ristorante ecc.

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Fidelis Assis]

Em 28 de março de 2018 13:57, Flavio Bello Fialho 
escreveu:

> A direção que a câmera está apontando é irrelevante. O que importa, na
> prática é o sentido da via que está sendo monitorado. Dessa forma, para
> highway=speed_camera, recomendo usar direction=forward ou
> direction=backward, em casos de via de mão dupla, ou não usar o tag, em
> caso de vias de mão simples (nesse caso, o sentido é óbvio). Em qualquer
> caso, o tag maxspeed deve sempre ser especificado.
>

Interpretamos da mesma forma.


>
> Quanto aos sinais de Pare (highway=stop), o pressuposto é que eles sempre
> se aplicam ao cruzamento mais próximo, sendo geralmente desnecessário o uso
> do tag direction. A exceção é caso de dois cruzamentos muito próximos em
> uma via de mão dupla, com o highway=stop no meio, em que o cruzamento alvo
> não é óbvio. Nesses casos, recomenda-se usar direction=forward ou
> direction=backward, para indicar a direção do cruzamento ao qual se aplica
> o highway=stop. Lembro ainda que, no caso de um "all-way stop", em que
> todos devem parar, o tag "highway=stop" deve ser colocado no cruzamento, ao
> passo que em outros casos deve ser colocado na via, um pouco antes do
> cruzamento.
>

Aqui também interpretamos a wiki da mesma forma. Uso os 3 mecanismos para
identificar a direção na hora da extração desse alerta e mais alguns, pela
ordem:

1- se for mão mão única, este é o critério;
2- se houver direction, esta define a direção;
3- se não for nó de cruzamento, o nó mais próximo define a direção;
4- se nó de cruzamento com stop=minor ou highway=priority alertas são
gerados apenas para as vias menos prioritárias;
5- se for nó de cruzamento, alertas são gerados para todas as vias;

Há ainda um outro complicador que são nós de junção que podem parecer
cruzamentos (para o algoritmo de extração, não visualmente) mas não são.
Nesse caso tem um tratamento especial para os nós extremos do via.

As direções são calculadas pelos dois nós envolvidos de cada via, o do stop
e o antecessor ou sucessor. Quando a direction é considerada e o valor está
em graus, aí podemos ter problema pois depende de como o mapeador
interpreta, se sentido do tráfego ou "olhar" do alerta.

Com relação à definição da direção por proximidade eu gosto desse método e
tenho usado porque é simples e prático de mapear. Mas tem um inconveniente
que me faz pensar duas vezes: não é à prova de mapeadores inexperientes ou
mesmo de experientes distraídos ou ainda de mim mesmo revisitando um trecho
:). Um simples ajuste de traçado para adequar melhor uma curva ou incluir
um novo ponto por qualquer razão pode inverter a proximidade e a direção
calculada. O mais seguro é forward/backward.

Abraços,
-- Fidelis
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

On Mar 25, 2018, at 11:09 PM, Greg Morgan  wrote:
> I wonder what to do with some of the routes.  For example, additional tracks 
> were added in the Tucson area. If we add a route, say, us 60 then an east and 
> west relation is created along with a master route. Do we do the same with 
> rail routes or are all the rails thrown into the same relation?

Hi again, Greg:

What I see in Tucson is "Sun Link" tram/streetcar, 
https://www.osm.org/relation/3920972 added over a year ago.  It is tagged as a 
public_transport:version=2 relation, though I don't think it is as I don't see 
a master_route relation.  If you want to take a look at that and check it / fix 
it up (even to simply retag it as a correct/ed v1 route), that would be great!  
If by "some of the routes" (in the Tucson area) you mean some other rail 
infrastructure, I'm curious to know which you mean.  Union Pacific rail through 
Tucson remains poorly tagged from its original TIGER import days and can use 
cleanup as described in our

https://wiki.osm.org/wiki/WikiProject_United_States_railways#Editing_Railroads_starting_from_TIGER_data
 .

Yes, assembling railway=rail into route=railway and route=train (light_rail, 
tram, monorail...) relations can be tedious and a bit confusing until you get 
the hang of it.  Good news:  we wiki-document how to do this fairly well.  In 
"other" news, there remains a great deal of work to do in USA Rail!

Not to sound too much like a "lonely heart rail mapper" calling across the 
chasms of talk-us, looking for more kindred spirits who OSM rail in the USA, I 
am doing that here and now, as I'd like to better establish contact with 
additional active USA rail mappers.  In the last few years OSM has grown 
statewide rail wikis (now at eight, nine...so, still forty-something to go!) 
and I know I'm not the only mapper who wants to keep momentum going to 
wiki-document all 50 states' rail infrastructure and passenger routes.

Thanks in advance for any answer/mapping you might offer,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] Odp: Nominatim - censorship at github pages

[cm-sanitas]

Hi,  This time I am not rising issue of badly managed project. So advice about 
forking is not really applicable. I think it would be quite stupid to create 
and maintain fork only to have a place where my comments wont be 
unjustifiably deleted.   The Nominatim github project is under openstreetmap 
organization. I thought that it would mean there are some fair and standardized 
community rules applied. I did not expect that project maintainers can do 
whatever they want without any oversight and accountability. It is also sad 
that nobody sees that such setup is toxic and single person should not have a 
power to do whatever (s)he wants in open project like that.   Anyway, 
thank you for advice regarding the issue. I hope one day having project under 
openstreetmap would mean something. For now I understand it is how it is, if I 
dont like it I can make my own fork.  M
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

Et cela ne concerne pas que l'ODBL-1.0 mais aussi l'ODC-1.0 (Open Data
Content) et l'ODC-PDDL (version "Public Domain", avec attribution "BY",
sans la clause "SA")

Cela touche donc nombre de jeux de données libres.

Voir les liens "officiels" des licences normalement supportées par l'OKFN
sur le site http://opendefinition.org/licenses/

De toutes les licences, seules les licences Creative Commons sont
accessibles (dont CC-BY-SA-4.0, qu'OSM n'a pas voulu avec la clause "SA"
telle qu'elle était formulée alors quand on a abandonné CC-BY-SA dans sa
version antérieure omettant de couvrir les bases de données et les
conditions d'alors ne prévoyant pas les "extraits significatifs"...), mais
plus aucune des licences développées par l'OKFN et acceptées par OSM.

Faut-il soulever le lièvre et reproposer CC-BY-SA-4.0 à la fondation OSM?
Que faire des données OSM importées sous ODC-1.0 ou ODbL-1.0 et toutes
celles qu'on crée encore maintenant par défaut ? Je crains que si on fasse
un nouveau changement, abandonner l'ODbL 1.0 signe l'arrêt de mort d'OSM,
mais qu'on devrait étudier la possibilité d'accepter CC-BY-SA-4.0 comme
licence compatible (et nettement plus connue que l'ODbL-1.0)...


Le 29 mars 2018 à 00:23, Philippe Verdy  a écrit :

> Note: j'ai trouvé une copie de l'ODbL 1.0 (modifiée pour remise en forme
> minimale et intégration sur ce site) sur https://spdx.org/licenses/
> ODbL-1.0.html
>
>
> Le 29 mars 2018 à 00:15, Philippe Verdy  a écrit :
>
>> Note: il semble que l'Open Knowledge Foundation (OKN) ne veuille plus
>> soutenir le projet OpenDataCommons et que ce site aurait été arrêté (l'OKN
>> indique que la licence Creative Commons 4.0 serait suffisante). Voir cette
>> discussion lancée en fin janvier 2017 (et quelques remarques postées
>> concernant OSM en mai 2017):
>>
>> https://discuss.okfn.org/t/maintenance-and-future-of-the-ope
>> n-data-commons-licences/4460
>>
>> Que va devenir LA licence d'OSM ? Il faudrait en rapatrier une copie
>> officielle chez OSM si c'est encore la licence de référence et si le site
>> web d'OpenDataCommons  est en fin de compte arrêté. Ou se préparer à
>> passer OSM en CC 4.0 qui couvre maintenant le droit spécifique des bases de
>> données !
>>
>> J'ai tenté de joindre l'OKN via leurs compte Twitter, Facebook et IRC
>> mais j'attends une réponse concernant le site web mort (c'est peut-être
>> temporaire, espérons-le...) et en tout cas si c'est une décisions d'arrêt,
>> on aurait aimé être averti pour faire la transition.
>>
>>
>>
>> Le 28 mars 2018 à 23:53, Philippe Verdy  a écrit :
>>
>>> Le site opendatacommons.org n'est pas accessible plus accessible en
>>> HTTP qu'en HTTPS.
>>>
>>> Tout cela me semble indiquer un défaut de configuration ou plantage d'un
>>> routeur ou parefeu chez opendatacommons.org pour sa connexion entre le
>>> frontal proxy externe et le serveur web. Dommage car Cloudflare est sensé
>>> éviter de se retrouver devant ce problème en permettant de continuer la
>>> navigation avec au moins les contenus statiques en cache, mais ces caches
>>> ont aussi expiré (la panne peut donc être là depuis un bon moment pour que
>>> Cloudflare ait purgé son cache et demande maintenant une connexion
>>> effective au serveur backend, qui se fait maintenant bloquer sans doute sur
>>> le parefeu d'opendatacommons par excès du nombre de tentatives en échec).
>>>
>>> Si quelqu'un a une copie fiable de l'ODbL qui puisse être chargée sur un
>>> serveur tiers, ce serait bien de mentionner une URL alternative.
>>> Même Wikipédia n'en a aucune copie (son cache externe chez "Wikiwix" est
>>> tout aussi vide pour le moment ou affiche une version partielle datant d'il
>>> y a deux mois le 28 janvier et Wikiwix peine à l'afficher correctement)
>>>
>>>
>>>
>>> Le 28 mars 2018 à 23:40, Philippe Verdy  a écrit :
>>>
 Note: Cloudflere ne signale aucune anomalie de connectivité sur son
 noeud parisien.
 De même ping et traceroute depuis mon PC vers opendatacommons.org
 fonctionne très bien aussi bien en IPv4 qu'en IPv6.
 Donc tout semble lié au serveur web de ce site qui est lié à un proxy
 frontal auquel il ne répond plus du tout (serveur Apache planté chez
 opendatacommons.org alors que l'hôte répond sur son interface IP?).


 Le 28 mars 2018 à 23:31, Philippe Verdy  a écrit :

> L'ODbL est officiellement sur https://opendatacommons.org/ mais
> OpenDataCommons. est inacessible, sans même aucune version en cache sur 
> son
> proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
> problème de connectivité avec une erreur serveur 502)
>
> Qui contacter, Cloudflare ou OpenDataCommons ?
> Pourquoi ces licences normalement stables ne sont pas sur un proxy
> cache stable ?
> Ne devrait-on pas héberger une copie locale de cette licence sur nos
> sites?
>


>>>
>>
>

Re: [Talk-de] Navads-Tankstellenimport

[Tom Pfeifer]

On 28.03.2018 23:06, Falk Zscheile wrote:

Am 28. März 2018 um 21:58 schrieb Harald Hartmann
:

Hmm, geht's wohl schon in die nächste Runde?

weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de


Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
wurden, gibt es auch :-)


Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige, werde ich mit 
Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt, von dessen Existenz ich bisher nicht 
einmal geahnt habe. Nach lokaler Überprüfung sieht das dann nicht mehr aus.


tom

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

Re: [OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

Note: j'ai trouvé une copie de l'ODbL 1.0 (modifiée pour remise en forme
minimale et intégration sur ce site) sur
https://spdx.org/licenses/ODbL-1.0.html


Le 29 mars 2018 à 00:15, Philippe Verdy  a écrit :

> Note: il semble que l'Open Knowledge Foundation (OKN) ne veuille plus
> soutenir le projet OpenDataCommons et que ce site aurait été arrêté (l'OKN
> indique que la licence Creative Commons 4.0 serait suffisante). Voir cette
> discussion lancée en fin janvier 2017 (et quelques remarques postées
> concernant OSM en mai 2017):
>
> https://discuss.okfn.org/t/maintenance-and-future-of-the-
> open-data-commons-licences/4460
>
> Que va devenir LA licence d'OSM ? Il faudrait en rapatrier une copie
> officielle chez OSM si c'est encore la licence de référence et si le site
> web d'OpenDataCommons  est en fin de compte arrêté. Ou se préparer à
> passer OSM en CC 4.0 qui couvre maintenant le droit spécifique des bases de
> données !
>
> J'ai tenté de joindre l'OKN via leurs compte Twitter, Facebook et IRC mais
> j'attends une réponse concernant le site web mort (c'est peut-être
> temporaire, espérons-le...) et en tout cas si c'est une décisions d'arrêt,
> on aurait aimé être averti pour faire la transition.
>
>
>
> Le 28 mars 2018 à 23:53, Philippe Verdy  a écrit :
>
>> Le site opendatacommons.org n'est pas accessible plus accessible en HTTP
>> qu'en HTTPS.
>>
>> Tout cela me semble indiquer un défaut de configuration ou plantage d'un
>> routeur ou parefeu chez opendatacommons.org pour sa connexion entre le
>> frontal proxy externe et le serveur web. Dommage car Cloudflare est sensé
>> éviter de se retrouver devant ce problème en permettant de continuer la
>> navigation avec au moins les contenus statiques en cache, mais ces caches
>> ont aussi expiré (la panne peut donc être là depuis un bon moment pour que
>> Cloudflare ait purgé son cache et demande maintenant une connexion
>> effective au serveur backend, qui se fait maintenant bloquer sans doute sur
>> le parefeu d'opendatacommons par excès du nombre de tentatives en échec).
>>
>> Si quelqu'un a une copie fiable de l'ODbL qui puisse être chargée sur un
>> serveur tiers, ce serait bien de mentionner une URL alternative.
>> Même Wikipédia n'en a aucune copie (son cache externe chez "Wikiwix" est
>> tout aussi vide pour le moment ou affiche une version partielle datant d'il
>> y a deux mois le 28 janvier et Wikiwix peine à l'afficher correctement)
>>
>>
>>
>> Le 28 mars 2018 à 23:40, Philippe Verdy  a écrit :
>>
>>> Note: Cloudflere ne signale aucune anomalie de connectivité sur son
>>> noeud parisien.
>>> De même ping et traceroute depuis mon PC vers opendatacommons.org
>>> fonctionne très bien aussi bien en IPv4 qu'en IPv6.
>>> Donc tout semble lié au serveur web de ce site qui est lié à un proxy
>>> frontal auquel il ne répond plus du tout (serveur Apache planté chez
>>> opendatacommons.org alors que l'hôte répond sur son interface IP?).
>>>
>>>
>>> Le 28 mars 2018 à 23:31, Philippe Verdy  a écrit :
>>>
 L'ODbL est officiellement sur https://opendatacommons.org/ mais
 OpenDataCommons. est inacessible, sans même aucune version en cache sur son
 proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
 problème de connectivité avec une erreur serveur 502)

 Qui contacter, Cloudflare ou OpenDataCommons ?
 Pourquoi ces licences normalement stables ne sont pas sur un proxy
 cache stable ?
 Ne devrait-on pas héberger une copie locale de cette licence sur nos
 sites?

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

Re: [OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

Note: il semble que l'Open Knowledge Foundation (OKN) ne veuille plus
soutenir le projet OpenDataCommons et que ce site aurait été arrêté (l'OKN
indique que la licence Creative Commons 4.0 serait suffisante). Voir cette
discussion lancée en fin janvier 2017 (et quelques remarques postées
concernant OSM en mai 2017):

https://discuss.okfn.org/t/maintenance-and-future-of-the-open-data-commons-licences/4460

Que va devenir LA licence d'OSM ? Il faudrait en rapatrier une copie
officielle chez OSM si c'est encore la licence de référence et si le site
web d'OpenDataCommons  est en fin de compte arrêté. Ou se préparer à passer
OSM en CC 4.0 qui couvre maintenant le droit spécifique des bases de
données !

J'ai tenté de joindre l'OKN via leurs compte Twitter, Facebook et IRC mais
j'attends une réponse concernant le site web mort (c'est peut-être
temporaire, espérons-le...) et en tout cas si c'est une décisions d'arrêt,
on aurait aimé être averti pour faire la transition.



Le 28 mars 2018 à 23:53, Philippe Verdy  a écrit :

> Le site opendatacommons.org n'est pas accessible plus accessible en HTTP
> qu'en HTTPS.
>
> Tout cela me semble indiquer un défaut de configuration ou plantage d'un
> routeur ou parefeu chez opendatacommons.org pour sa connexion entre le
> frontal proxy externe et le serveur web. Dommage car Cloudflare est sensé
> éviter de se retrouver devant ce problème en permettant de continuer la
> navigation avec au moins les contenus statiques en cache, mais ces caches
> ont aussi expiré (la panne peut donc être là depuis un bon moment pour que
> Cloudflare ait purgé son cache et demande maintenant une connexion
> effective au serveur backend, qui se fait maintenant bloquer sans doute sur
> le parefeu d'opendatacommons par excès du nombre de tentatives en échec).
>
> Si quelqu'un a une copie fiable de l'ODbL qui puisse être chargée sur un
> serveur tiers, ce serait bien de mentionner une URL alternative.
> Même Wikipédia n'en a aucune copie (son cache externe chez "Wikiwix" est
> tout aussi vide pour le moment ou affiche une version partielle datant d'il
> y a deux mois le 28 janvier et Wikiwix peine à l'afficher correctement)
>
>
>
> Le 28 mars 2018 à 23:40, Philippe Verdy  a écrit :
>
>> Note: Cloudflere ne signale aucune anomalie de connectivité sur son noeud
>> parisien.
>> De même ping et traceroute depuis mon PC vers opendatacommons.org
>> fonctionne très bien aussi bien en IPv4 qu'en IPv6.
>> Donc tout semble lié au serveur web de ce site qui est lié à un proxy
>> frontal auquel il ne répond plus du tout (serveur Apache planté chez
>> opendatacommons.org alors que l'hôte répond sur son interface IP?).
>>
>>
>> Le 28 mars 2018 à 23:31, Philippe Verdy  a écrit :
>>
>>> L'ODbL est officiellement sur https://opendatacommons.org/ mais
>>> OpenDataCommons. est inacessible, sans même aucune version en cache sur son
>>> proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
>>> problème de connectivité avec une erreur serveur 502)
>>>
>>> Qui contacter, Cloudflare ou OpenDataCommons ?
>>> Pourquoi ces licences normalement stables ne sont pas sur un proxy cache
>>> stable ?
>>> Ne devrait-on pas héberger une copie locale de cette licence sur nos
>>> sites?
>>>
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

Le site opendatacommons.org n'est pas accessible plus accessible en HTTP
qu'en HTTPS.

Tout cela me semble indiquer un défaut de configuration ou plantage d'un
routeur ou parefeu chez opendatacommons.org pour sa connexion entre le
frontal proxy externe et le serveur web. Dommage car Cloudflare est sensé
éviter de se retrouver devant ce problème en permettant de continuer la
navigation avec au moins les contenus statiques en cache, mais ces caches
ont aussi expiré (la panne peut donc être là depuis un bon moment pour que
Cloudflare ait purgé son cache et demande maintenant une connexion
effective au serveur backend, qui se fait maintenant bloquer sans doute sur
le parefeu d'opendatacommons par excès du nombre de tentatives en échec).

Si quelqu'un a une copie fiable de l'ODbL qui puisse être chargée sur un
serveur tiers, ce serait bien de mentionner une URL alternative.
Même Wikipédia n'en a aucune copie (son cache externe chez "Wikiwix" est
tout aussi vide pour le moment ou affiche une version partielle datant d'il
y a deux mois le 28 janvier et Wikiwix peine à l'afficher correctement)



Le 28 mars 2018 à 23:40, Philippe Verdy  a écrit :

> Note: Cloudflere ne signale aucune anomalie de connectivité sur son noeud
> parisien.
> De même ping et traceroute depuis mon PC vers opendatacommons.org
> fonctionne très bien aussi bien en IPv4 qu'en IPv6.
> Donc tout semble lié au serveur web de ce site qui est lié à un proxy
> frontal auquel il ne répond plus du tout (serveur Apache planté chez
> opendatacommons.org alors que l'hôte répond sur son interface IP?).
>
>
> Le 28 mars 2018 à 23:31, Philippe Verdy  a écrit :
>
>> L'ODbL est officiellement sur https://opendatacommons.org/ mais
>> OpenDataCommons. est inacessible, sans même aucune version en cache sur son
>> proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
>> problème de connectivité avec une erreur serveur 502)
>>
>> Qui contacter, Cloudflare ou OpenDataCommons ?
>> Pourquoi ces licences normalement stables ne sont pas sur un proxy cache
>> stable ?
>> Ne devrait-on pas héberger une copie locale de cette licence sur nos
>> sites?
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Navads-Tankstellenimport

[Rainer]

Ja, und jetzt beamt's mich nach einem Edit nicht mehr 5000 km zu 
irgendeiner Tanke, die ich bestimmt nicht kenne, sondern nur noch ein 
paar 100 km ;)


Der Fahrradladen aus der ersten Runde, der zur Tanke mutieren sollte ist 
jedenfalls mit "the last reviewer rejected this ..." rausgenommen.


Oft ist es hier nur brand, das fehlt und einige Male zweifle ich an den 
24/7 Öffnungszeiten, aber es könnte sein, daß eine Zapfsäule, an der man 
mit Karte zahlen kann, dafür schon ausreicht.


Grüße,
Rainer


Am 28.03.2018 23:06, schrieb Falk Zscheile:

Am 28. März 2018 um 21:58 schrieb Harald Hartmann
:

Hmm, geht's wohl schon in die nächste Runde?

weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de


Vielen Dank für den Hinweis.

Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
wurden, gibt es auch :-)

Gruß, Falk

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



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

Re: [OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

Note: Cloudflere ne signale aucune anomalie de connectivité sur son noeud
parisien.
De même ping et traceroute depuis mon PC vers opendatacommons.org
fonctionne très bien aussi bien en IPv4 qu'en IPv6.
Donc tout semble lié au serveur web de ce site qui est lié à un proxy
frontal auquel il ne répond plus du tout (serveur Apache planté chez
opendatacommons.org alors que l'hôte répond sur son interface IP?).


Le 28 mars 2018 à 23:31, Philippe Verdy  a écrit :

> L'ODbL est officiellement sur https://opendatacommons.org/ mais
> OpenDataCommons. est inacessible, sans même aucune version en cache sur son
> proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
> problème de connectivité avec une erreur serveur 502)
>
> Qui contacter, Cloudflare ou OpenDataCommons ?
> Pourquoi ces licences normalement stables ne sont pas sur un proxy cache
> stable ?
> Ne devrait-on pas héberger une copie locale de cette licence sur nos sites?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] site officiel de l'ODbL inacessible (erreur du proxy-cache Cloudflare)

[Philippe Verdy]

L'ODbL est officiellement sur https://opendatacommons.org/ mais
OpenDataCommons. est inacessible, sans même aucune version en cache sur son
proxy frontal Cloudflare (au moins celui du noeud de Paris qui signale un
problème de connectivité avec une erreur serveur 502)

Qui contacter, Cloudflare ou OpenDataCommons ?
Pourquoi ces licences normalement stables ne sont pas sur un proxy cache
stable ?
Ne devrait-on pas héberger une copie locale de cette licence sur nos sites?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Tratti brevi e riferimenti

[Simone Saviolo]

Il giorno 28 marzo 2018 22:32, aldoct  ha scritto:

> Tutto OK, grazie per gli interventi. Mi rimane il problema pratico che
> quando
> un ponte di 30 metri in curva è coperto dal nome io non riesco a vedere se
> è
> mappato correttamente ovvero presenta degli angoli troppo accentuati; ma
> tant'è...non si può avere tutto.


Hai provato con un altro rendering? Solo su osm.org ce ne sono quattro.
Magari un altro ti può aiutare.

Ciao,

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

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Am 28. März 2018 um 21:58 schrieb Harald Hartmann
:
> Hmm, geht's wohl schon in die nächste Runde?
>
> weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de
>
Vielen Dank für den Hinweis.

Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
wurden, gibt es auch :-)

Gruß, Falk

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

Re: [Talk-it] Tratti brevi e riferimenti

[aldoct]

Tutto OK, grazie per gli interventi. Mi rimane il problema pratico che quando
un ponte di 30 metri in curva è coperto dal nome io non riesco a vedere se è
mappato correttamente ovvero presenta degli angoli troppo accentuati; ma
tant'è...non si può avere tutto.
Saluti



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-gb-westmidlands] Next meeting

[Rob Nickerson]

Hi all,

According to my calendar the next Mappa Mercia meeting is 5th April. Given
that the clocks have changed we should aim to go out mapping.

Did we pick a location?

Best regards,
*Rob*
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-de] Navads-Tankstellenimport

[Harald Hartmann]

Hmm, geht's wohl schon in die nächste Runde?

> http://audit.osmz.ru/project/navads_fuel
> Validation is closed: this import will be republished shortly as five
distinct imports.

weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de

Und schwups, schon ist meine örtliche Tanke ganz und gar aus dem Import
verschwunden?!

Nachtrag: weiß nicht ob es das vorher schon gab, aber jetzt kann man
gleich einen "fixme" text hinterlassen ...

Crossposting aus
https://forum.openstreetmap.org/viewtopic.php?pid=692056#p692056

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

Re: [Talk-ca] Trans-Canada Highway research

[Martijn van Exel]

Pierre, 

Consistency in the data is the main goal. This benefits all the things
you mention, including map rendering and parsing by navigation software
such as ours but also OSMAnd, maps.me and others.There is a master relation for 
the Trans-Canada Highway / Route
Transcanadienne[0] but it is incomplete and broken. One idea would be to
repair it, and the province-level relations that would be the members of
it. Would you be interested in coordinating that?
[0] https://www.openstreetmap.org/relation/1307243
--
  Martijn van Exel
  m...@rtijn.org



On Wed, Mar 28, 2018, at 13:24, Pierre Béland wrote:
> Bonjour Martin,
> 
> Il me semble que les divers commentaires ont été assez clair. La
> communauté OSM du Canada est assez mature pour gérer cela et n'avons
> pas besoin que Navteq démarre un projet pour modifier ces données.> 
> L'équipe Navteq a déja créé beaucoup de problèmes en ajoutant partout
> des relations complexes pour un simple interdit de faire un virage en
> U.  Quels sont maintenant les objectifs de la tâche> 
> More Overlapping Ways in Canada
> Telenav OSM Integrity Checks's Project
> 
> 
> A mon  avis, vous devez discuter avec la communauté canadienne avant
> de démarrer de tels projets. Svp interrompre cette tâche et venez en
> discuter.> 
> Et quels sont vos objectifs pour les modifications vs la route
> Trancanadienne? Un meilleur rendu sur la carte, des itinéraires dans
> les outils de navigation ? Pourquoi ne pas simplement créer une
> relation de type route pour la route Transcanadienne?> 
> ** 
> Pierre **
> 
> 
> Le mercredi 28 mars 2018 13 h 23 min 37 s HAE, Martijn van Exel
>  a écrit :> 
> 
> Hi all, 
> 
> My colleague Olivia will respond more in depth with some suggestions
> based on your feedback. Thanks for giving our team's ideas some
> thought.> 
> In the meantime, as I was writing a post about the new version of
> MapRoulette, I thought I'd make a Challenge for misspelled Trans-
> Canada Highway names. Please find it here:
> http://maproulette.org/mr3/browse/challenges/2955 . There's only a
> little over 200 tasks, so that should be an easy thing to fix
> together.> 
> The Challenge is based on this Overpass query:
> http://overpass-turbo.eu/s/xoW -- it's pretty easy to make your own
> Challenges based on your own Overpass queries or GeoJSON files.> 
> The diary post explaining MapRoulette is here:
> https://www.openstreetmap.org/user/mvexel/diary/43596> 
> Thanks,
> --
>   Martijn van Exel
>   m...@rtijn.org
> 
> 
> 
> On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:
>> Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient
>> Roumains, Javanais ou Américains soit à considérer. Ils nous ont
>> consultés avant de faire la modification et c’est parfait. Cependant,
>> je suis entièrement en accord avec ta réponse - laissez ça à la
>> communauté canadienne!>>  


>> (I do not believe that the fact these ‘contributors’ are Romanians,
>> Javanese or Americans is to be considered. They consulted us before
>> making the change and it's perfect. However, I fully agree with your
>> answer - leave that to the Canadian community!-)>>  


>> Sent from  Mail[1] for Windows 10


>>  


>> 
>> *From:* Andrew Lester  *Sent:* Monday, March 26,
>> 2018 1:35:56 PM *To:* Olivia Robu - (p) *Cc:* talk-ca *Subject:* Re:
>> [Talk-ca] Trans-Canada Highway research>>  
>> While standardization may be nice, it often won't be possible even
>> within a single country. As has already been discussed, there are
>> differing conventions in different provinces, so please don't try to
>> apply a single plan to all provinces. How the TCH is handled in OSM
>> will vary depending on the province.>> 
>> For example, in BC (and some other western provinces), the TCH
>> carries the 1 ref. In some places where other ref'ed highways
>> coincide with the TCH, the ref is recorded as "ref=1;19", for
>> example. There are places within cities where the TCH runs on city
>> roads with different names (e.g. Douglas Street in Victoria), so
>> those ways are named with the local name and the TCH name is recorded
>> in the alt_name or nat_name tag (a separate argument is which one of
>> these to use). An alternate name should never be added to the primary
>> name in brackets like proposed. That's exactly what the alt_name (and
>> similar) tags are for. There are also many places where Trans-Canada
>> Highway is the official local name of the road, like most of the
>> highway in BC.>> 
>> As for the correct spelling of the TCH, I think it would be fairly
>> uncontroversial to standardize the name to "Trans-Canada Highway" or
>> "Route Transcanadienne" where it's appropriate to use the TCH name,
>> because those are the official spellings. Any variants can be
>> considered errors.>> 
>> As for varying highway classifications, this is correct and to be
>> expected. Unlike the US interstate system, the Trans-Canada Highway
>> network varies in construction and importance all across 

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Bonjour Martin,
Il me semble que les divers commentaires ont été assez clair. La communauté OSM 
du Canada est assez mature pour gérer cela et n'avons pas besoin que Navteq 
démarre un projet pour modifier ces données.
L'équipe Navteq a déja créé beaucoup de problèmes en ajoutant partout des 
relations complexes pour un simple interdit de faire un virage en U.  Quels 
sont maintenant les objectifs de la tâche
 More Overlapping Ways in CanadaTelenav OSM Integrity Checks's Project
A mon  avis, vous devez discuter avec la communauté canadienne avant de 
démarrer de tels projets. Svp interrompre cette tâche et venez en discuter.

Et quels sont vos objectifs pour les modifications vs la route Trancanadienne? 
Un meilleur rendu sur la carte, des itinéraires dans les outils de navigation ? 
Pourquoi ne pas simplement créer une relation de type route pour la route 
Transcanadienne?

 
Pierre 
 

Le mercredi 28 mars 2018 13 h 23 min 37 s HAE, Martijn van Exel 
 a écrit :  
 
 Hi all, 

My colleague Olivia will respond more in depth with some suggestions based on 
your feedback. Thanks for giving our team's ideas some thought.

In the meantime, as I was writing a post about the new version of MapRoulette, 
I thought I'd make a Challenge for misspelled Trans-Canada Highway names. 
Please find it here: http://maproulette.org/mr3/browse/challenges/2955 . 
There's only a little over 200 tasks, so that should be an easy thing to fix 
together. 

The Challenge is based on this Overpass query: http://overpass-turbo.eu/s/xoW 
-- it's pretty easy to make your own Challenges based on your own Overpass 
queries or GeoJSON files.

The diary post explaining MapRoulette is here: 
https://www.openstreetmap.org/user/mvexel/diary/43596

Thanks,--
  Martijn van Exel
  m...@rtijn.org



On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:


Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient Roumains, 
Javanais ou Américains soit à considérer. Ils nous ont consultés avant de faire 
la modification et c’est parfait. Cependant, je suis entièrement en accord avec 
ta réponse - laissez ça à la communauté canadienne!


 


(I do not believe that the fact these ‘contributors’ are Romanians, Javanese or 
Americans is to be considered. They consulted us before making the change and 
it's perfect. However, I fully agree with your answer - leave that to the 
Canadian community!-)


 


Sent from  Mail for Windows 10


 


From: Andrew Lester 
 Sent: Monday, March 26, 2018 1:35:56 PM
 To: Olivia Robu - (p)
 Cc: talk-ca
 Subject: Re: [Talk-ca] Trans-Canada Highway research  
While standardization may be nice, it often won't be possible even within a 
single country. As has already been discussed, there are differing conventions 
in different provinces, so please don't try to apply a single plan to all 
provinces. How the TCH is handled in OSM will vary depending on the province.

For example, in BC (and some other western provinces), the TCH carries the 1 
ref. In some places where other ref'ed highways coincide with the TCH, the ref 
is recorded as "ref=1;19", for example. There are places within cities where 
the TCH runs on city roads with different names (e.g. Douglas Street in 
Victoria), so those ways are named with the local name and the TCH name is 
recorded in the alt_name or nat_name tag (a separate argument is which one of 
these to use). An alternate name should never be added to the primary name in 
brackets like proposed. That's exactly what the alt_name (and similar) tags are 
for. There are also many places where Trans-Canada Highway is the official 
local name of the road, like most of the highway in BC.

As for the correct spelling of the TCH, I think it would be fairly 
uncontroversial to standardize the name to "Trans-Canada Highway" or "Route 
Transcanadienne" where it's appropriate to use the TCH name, because those are 
the official spellings. Any variants can be considered errors.

As for varying highway classifications, this is correct and to be expected. 
Unlike the US interstate system, the Trans-Canada Highway network varies in 
construction and importance all across the country, so the classification can't 
be standardized to just motorway or trunk. There are sections where primary is 
the most appropriate, and possibly even secondary in some places. Just on 
Vancouver Island alone, the roads designated as the TCH vary from a six-lane 
motorway all the way down to a two-lane effectively-tertiary road.

Since there will need to be a lot of local knowledge required for such a 
project, I strongly recommend that this project not be undertaken by Telenav. 
This is the kind of work that Canadians should be doing, being the most 
familiar with the on-the-ground situation which will dictate how the highway is 
handled in each province. The numerous past issues with Telenav's contributions 
is also a factor that can't be ignored. Does it really make sense for a team of 

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Gautier Pelloux-Prayer]

Bonjour Christian et la liste,

A-t-on des nouvelles sur un éventuel service de rendu du relief ? Ça 
serait vraiment une très bonne nouvelle.



On 06/01/2018 19:36, Christian Quest wrote:
J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur 
l'ombrage...


STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre 
certaines dalles de 10° x 10° étaient trop volumineuses et avaient 
dépassé les 2Go d'où un ombrage incomplet.


Je regarde pour corriger ça, sinon 95% du boulot est fait.

Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 
milliards de pixels ;)
Le dossier avec les tuiles finales et leurs overview pèse 133Go... 
tout le dossier du projet fait presque 600Go.


--
Christian Quest - OpenStreetMap France


___
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: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Philip Barnes]

On Mon, 2018-03-26 at 22:24 +0200, Rory McCann wrote:
> Hi guys, gals and non-binary pals,

Some interesting ideas, it is difficult to find a single object that
will exist on a worldwide scale.

Some OSM groups have "quarterly projects" where they improve the
state
> of something in OSM in their area, e.g. the UK OSM community once
> worked
> on schools in the UK for a quarter.

This was a great success, schools are a common feature so everyone had
a chance to contribute. We have access to a government database of
schools and were able to add missing schools and also add additional
information and improve the mapping. A lot of changing from node to
area was done as well as moving tags to the campus. Tagging buildings
doesn't really work as most schools have multiple buildings.

Schools are relatively easy to armchair, the project was done during
the dark evenings, as they are large and surrounded by sports fields
making them distinctive on imagery. 

The database also contains Nurseries so many of those were added as
part of the project.


> 
> How about we do that? Every quarter (3 months) pick some topic,
> something that is traditionally underrepresented in OSM, and we try
> to
> improve the state of that in OSM.
> 
> There's been lots of legit talk lately about what is and isn't mapped
> in
> OSM, so let's try to map it! There's more than just adding data. We
> could also try to improve documentation (written/video), editor
> presets,
> figure out tagging schemes, map rendering, finding data to use, etc.
> But
> we're a geographically spread group, so we can all probably add
> something to the map. There are things that aren't mapped in OSM, so
> let's map them! 
> 
> Any ideas for topics? Off the top of my head: the recently mentioned
> amenity=childcare tag, 

I am not sure that I understand what is missing here, we have mapped
Nursery Schools as amenity=kindergarten which has no English meaning
and is one of the American terms we use in OSM such as sidewalk. I know
it is German for Childrens Garden.

Nursery Schools offer pre school education for 3 and 4 year old and
many offer babycare and after school/school holiday care. All 3 and 4
year olds are entitled to 15 hours free Nursery Education a week, these
are verifiable and are/can be mapped.

Other childcare is provided by Registered Childminders, these are
contactable through adverts/social services, but are in private homes
and are not something we can or should map.

I am not sure what else there is to map in this category but open to
suggestions.


> recently mentioned women's health care facilities, 
Where I live these are provided through the general healthcare, either
through the local doctors surgery or will be departments within the
local hospitals. They are not standalone facilities.

> wheelchair accessibility, 
Something we can do, edge cases will need more specialist knowledge. In
my experience toilets will be the main issue.

> gay bars,
A big city thing I think. The small town I live in is pretty inclusive.

> gendered toilets for trans/gnc/etc people, 
Not something I have ever come across, as far as I am aware in the UK
transgendered people can legally use whichever toilet they feel more
comfortable with.

> gendered toilets
As a European this was something that had never occurred to me. The
norm is that there will be a male/female/unisex disabled. 

Mapping the gender had never occurred to me until I was at an interesting talk 
at SOTM Brussels. 

> minority language? 
Locally there is a big drive to add Welsh language names to OSM,. At the 
weekend I was at a concert that was a bit Welsh and a bit Cornish Synth Pop. 
I'm not sure Cornish is anywhere near the coverage Welsh has. 


HOT/MM is already doing a lot
> in areas where the maps are missing

 . Any more ideas? Nearly all of us
> are privileged in some axis, so someone not in that group must be
> careful not to tell marginalized people how to map their thing, and
> ensure we map it correctly ("The X tag is useless now after all those
> diversity people added all that junk!")

As a community we are mostly from a techie background that generally puts us 
into a middle class background. We do not attract mappers from social housing 
for example. Just off the top of my head shops offering topups for prepayment 
meters, social clubs, bingo halls but that is me, a middle class engineer 
without a clue. 
> 
> What do yous think? Would many be interested in taking part?

I'm certainly interested in mapping those things that are off my radar. 

Phil (trigpoint) 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[Jérôme Seigneuret]

L'antenne extérieur est indispensable dans certains véhicules. Sur nos
flottes de véhicules on le voit clairement. Les véhicules non équipé
d'antenne externe ont des précisions très hétérogènes. Après on peut fixer
des antennes à viser comme pour les cartes wifi (antenne compact)

Le 28 mars 2018 à 17:08, David Marchal  a écrit :

> Quelques dizaines d’euros de différence, c’est le pain pour un mois. Les
> petits budgets, dont je suis, apprécieront cette différence de prix ; les
> pays en voie de développement aussi, d’ailleurs. Les contributeurs
> africains, par exemple, seraient sans doute bien contents d’avoir un truc
> pas cher et tout simple, type allumer-enregistrer, plutôt qu’un
> smartphone avec des dizaines de fonctions mais dont une seule, le GPS, les
> intéresse ; et puis, ça permettrait de laisser les moins dégourdis avec la
> technologie faire des traces, en France ou ailleurs. Je pense aussi aux
> bidouilleurs, qui préféreront reprendre les plans du bidule et l’assembler
> eux-mêmes plutôt que d’acheter un truc tout fait.
>
> Pour la précision, je pense que l’antenne extérieure serait déjà une bonne
> avancée par rapport aux antennes intégrées des smartphones, mais c’est
> totalement subjectif, n’ayant jamais testé réellement la chose.
>
> --
> *De :* Francois Gouget 
> *Envoyé :* mercredi 28 mars 2018 00:35
> *À :* Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger
> GPS ?
>
> On Tue, 27 Mar 2018, David Marchal wrote:
>
> > L’intérêt est, je pense, d’avoir un boîtier discret, simple et pas
> > trop cher, qui ne serve qu’à ça pour ne pas avoir besoin d’un
> > smartphone au prix supérieur et plus complexe.
>
> Et se passer d'OsmAnd~, Street-Complete et Mapillary / OSC ?
> Impensable ;-) !
>
>
> > Ça pourrait viser, [...] ceux qui n’en ont pas les moyens
>
> On peut trouver un bon smartphone à 150€ (Zenfone 2 ZE551ML). Les plus
> basiques commencent à 80€ à tout casser et je n'ai pas l'impression que
> leurs GPS soient tellement pire. Donc pour que l'opération ait du sens
> d'un point de vue strictement économique il faudrait que ce GPS maison
> coûte moins de 60€ (80€ - 20€ pour un dumbphone), ou moins de 95€ si on
> retient un prix moyen.
>
>
> [...]
> > Et puis, il y a bien sûr l’histoire de la précision, qui risque fort
> > d’être meilleure, ce qui est un gros plus quand on modélise sur OSM.
>
> Je suis sceptique sur les chances d'avoir une précision
> significativement meilleure en restant sur les technologies standard et
> pas chères ; c'est à dire qui n'exploitent que le signal L1 et sans
> techniques type GPS différentiel.
>
> L'email de Stéphane Péneau aurait tendance à me renforcer dans ces
> convictions. Mais je ne suis pas un spécialiste des GPS alors peut-être
> que je suis trop pessimiste. Ou alors j'attends trop des GPS. Une
> précision de +/- 1 m en ville et en forêt, là ça changerait la donne.
> Mais déjà à +/- 3 m... bof.
>
>
> --
> Francois Gouget   http://fgouget.free.fr/
> In theory, theory and practice are the same, but in practice they're
> different.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Nelson A. de Oliveira]

2018-03-28 13:57 GMT-03:00 Flavio Bello Fialho :
> Dessa forma, para highway=speed_camera, recomendo usar
> direction=forward ou direction=backward, em casos de via de mão dupla

Isso não serve pra nada :-)
O direction para speed_camera não indica a direção a que se aplica o
radar. É apenas o lado para onde a câmera está apontando.

Um highway=speed_camera em uma via de mão dupla, com qualquer que seja
o direction e sem uma relação de enforcement, significa que se aplica
para os dois lados.

Esse é o problema inicial que o Fidelis levantou.

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

Re: [OSM-Talk-ZA] Wikimania 2018, happening in Cape Town, South Africa

[David Richfield]

Unfortunately only the international Wikimedia Foundation scholarship would
be open to people traveling from India, and that process is already
complete. The scholarships from Wikimedia South Africa are only for people
traveling from South Africa or possibly SADEC countries if there's a good
rationale.

On 28 March 2018 at 15:29, Jinal Foflia  wrote:

> Hello David,
>
> This is great to hear, I'm really excited about the Mapathon happening at
> the conference. It's always awesome to see both these communities working
> together and coming up with something amazing! Thank you for offering the
> scholarship :) I'm based out of India, so it's hard for me making to the
> conference. Would be happy to share ideas and work with folks on OSM
> related sessions.
>
> Cheers,
> Jinal Foflia
>
> On Sat, Mar 24, 2018 at 10:41 PM, David Richfield <
> davidrichfi...@gmail.com> wrote:
>
>> Thank you for sharing this, Jinal!
>>
>> There is of course a significant overlap between OSM volunteers and
>> Wikimedia people, so every year there is something specifically about OSM
>> at Wikimania, and cartography in the service of Wikimedia projects in
>> general. We also usually organise a mapping party for Wikimania. Once the
>> date is confirmed, I'll also post that on this list.
>>
>> I'm on the Wikimania committee, and we have a limited number of
>> scholarships available to fund South African Open Knowledge
>> volunteers/advocates to attend Wikimania, and this can fund your travel,
>> registration fees and accommodation. Check out http://wikimedia.org.za/wi
>> ki/Wikimania_2018_Scholarship_Applications if you're interested and you
>> have something to bring to the conference.
>>
>> Cheers,
>>
>> David Richfield
>>
>> On 20 March 2018 at 08:03, Jinal Foflia  wrote:
>>
>>> Hello everyone,
>>>
>>> Wanted to share about the Wikimania 2018 [1] happening in Cape Town,
>>> South Africa on July 18-22, 2018, it's the annual international conference
>>> that celebrates Wikipedia and its sister free knowledge projects. Find out
>>> more details about the conference and the previous conference here -
>>> https://www.openstreetmap.org/user/jinalfoflia/diary/43529
>>>
>>> It’ll be great if the South Africa/Cape Town OSM communities would want
>>> to participate, conduct BoF sessions or present lightning talks.
>>> OpenStreetMap and Wikipedia communities have a lot in common, let's meet,
>>> collaborate and make the most of this opportunity!
>>>
>>> [1] - https://wikimania2018.wikimedia.org/wiki/Wikimania
>>>
>>>
>>> Cheers,
>>> Jinal Foflia
>>>
>>> ___
>>> Talk-ZA mailing list
>>> Talk-ZA@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-za
>>>
>>>
>>
>>
>>
>> ___
>> Talk-ZA mailing list
>> Talk-ZA@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-za
>>
>>
>
> ___
> Talk-ZA mailing list
> Talk-ZA@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za
>
>


-- 
David Richfield
Nabburgerstraße 19, 81737 München
+49 176 72663368
___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

[OSM-talk] New MapRoulette version

[Martijn van Exel]

Hi all,

MapRoulette v3 is now in public beta. I wrote a diary highlighting the main new 
features. Please give it a try and let me know what you think about it. Thanks!

Diary: https://www.openstreetmap.org/user/mvexel/diary/43596
Link to beta: http://maproulette.org/mr3
Github repo: https://github.com/maproulette/maproulette3 
OSM wiki (still need to update): 
https://wiki.openstreetmap.org/wiki/MapRoulette 

-- 
  Martijn van Exel
  m...@rtijn.org

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

Re: [Talk-ca] Trans-Canada Highway research

[Martijn van Exel]

Hi all, 

My colleague Olivia will respond more in depth with some suggestions
based on your feedback. Thanks for giving our team's ideas some thought.
In the meantime, as I was writing a post about the new version of
MapRoulette, I thought I'd make a Challenge for misspelled Trans-Canada
Highway names. Please find it here:
http://maproulette.org/mr3/browse/challenges/2955 . There's only a
little over 200 tasks, so that should be an easy thing to fix together.
The Challenge is based on this Overpass query:
http://overpass-turbo.eu/s/xoW -- it's pretty easy to make your own
Challenges based on your own Overpass queries or GeoJSON files.
The diary post explaining MapRoulette is here:
https://www.openstreetmap.org/user/mvexel/diary/43596
Thanks,
--
  Martijn van Exel
  m...@rtijn.org



On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:
> Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient
> Roumains, Javanais ou Américains soit à considérer. Ils nous ont
> consultés avant de faire la modification et c’est parfait. Cependant,
> je suis entièrement en accord avec ta réponse - laissez ça à la
> communauté canadienne!>  


> (I do not believe that the fact these ‘contributors’ are Romanians,
> Javanese or Americans is to be considered. They consulted us before
> making the change and it's perfect. However, I fully agree with your
> answer - leave that to the Canadian community!-)>  


> Sent from  Mail[1] for Windows 10


>  


> 
> *From:* Andrew Lester  *Sent:* Monday, March 26,
> 2018 1:35:56 PM *To:* Olivia Robu - (p) *Cc:* talk-ca *Subject:* Re:
> [Talk-ca] Trans-Canada Highway research>  
> While standardization may be nice, it often won't be possible even
> within a single country. As has already been discussed, there are
> differing conventions in different provinces, so please don't try to
> apply a single plan to all provinces. How the TCH is handled in OSM
> will vary depending on the province.> 
> For example, in BC (and some other western provinces), the TCH carries
> the 1 ref. In some places where other ref'ed highways coincide with
> the TCH, the ref is recorded as "ref=1;19", for example. There are
> places within cities where the TCH runs on city roads with different
> names (e.g. Douglas Street in Victoria), so those ways are named with
> the local name and the TCH name is recorded in the alt_name or
> nat_name tag (a separate argument is which one of these to use). An
> alternate name should never be added to the primary name in brackets
> like proposed. That's exactly what the alt_name (and similar) tags are
> for. There are also many places where Trans-Canada Highway is the
> official local name of the road, like most of the highway in BC.> 
> As for the correct spelling of the TCH, I think it would be fairly
> uncontroversial to standardize the name to "Trans-Canada Highway" or
> "Route Transcanadienne" where it's appropriate to use the TCH name,
> because those are the official spellings. Any variants can be
> considered errors.> 
> As for varying highway classifications, this is correct and to be
> expected. Unlike the US interstate system, the Trans-Canada Highway
> network varies in construction and importance all across the country,
> so the classification can't be standardized to just motorway or trunk.
> There are sections where primary is the most appropriate, and possibly
> even secondary in some places. Just on Vancouver Island alone, the
> roads designated as the TCH vary from a six-lane motorway all the way
> down to a two-lane effectively-tertiary road.> 
> Since there will need to be a lot of local knowledge required for such
> a project, I strongly recommend that this project not be undertaken by
> Telenav. This is the kind of work that Canadians should be doing,
> being the most familiar with the on-the-ground situation which will
> dictate how the highway is handled in each province. The numerous past
> issues with Telenav's contributions is also a factor that can't be
> ignored. Does it really make sense for a team of Romanians with a
> history of questionable decisions to be making sweeping changes to the
> Canadian national highway network? At least they've brought a proposal
> to the community this time rather than just push forward with a faulty
> plan like they have in the past. I'm still cleaning up after previous
> Telenav projects in my area that added countless non-existent turn
> restrictions and names and also removed valid data.> 
> Andrew
> Victoria, BC, Canada
> 
> 
> *From: *"Olivia Robu - (p)" 
> *To: *"talk-ca" 
> *Sent: *Monday, March 26, 2018 4:20:16 AM
> *Subject: *[Talk-ca] Trans-Canada Highway research
> 
> Hello,


> The Telenav Map team has done some research on the status of the ways
> and relations of Trans-Canada Highway.> Here are some conclusions from this 
> research:


>  * The highway is formed from 30 routes;
>  * Every route has different names for the 

Re: [OSRM-talk] Limit particular points in a route at runtime

[Daniel Patterson]

Hi François,

  There are basically 3 ways to go about this:

1. If you only have toll-booth nodes, then you can cheat and use the
`result.traffic_lights = true` flag on those nodes, and adjust the traffic
light penalty.  This isn't perfect though, you'll probably want to remove
traffic light tags from elsewhere, and that might mess up some routing,
although I suspect not much.

2. If you have `toll=yes` on the toll roads, you can simply adjust the
speed/rate down for those roads.  This has the downside that the routing
engine will tend to route you *off* those roads as quickly as possible,
which isn't always what you want.

3.  You can use the restricted access tags to add a penalty for
*turning onto a toll road* - this will mostly avoid toll roads, and will
not unnecessarily route you off them.  Take a look at how "access=private"
is implemented currently (and how `turn.source_restricted` and
`turn.target_restricted` are used) in the `process_turn` function.  Again,
you may need to sacrifice other access=private/destination features to get
what you need here.

  Also take a look at Chau's work in
https://github.com/Project-OSRM/osrm-backend/pull/4858 - there may be other
ways you can use the `process_turn` function to add penalties for accessing
tolled roads.

daniel

On Wed, Mar 28, 2018 at 9:13 AM, François Lacombe  wrote:

> Thank you for this input,
>
> Understood the lack of dynamic costing in OSRM. I'll adapat my profile
> Would it be preferable to lower the rate or the speed of specific way I
> want to limit ? Maybe both ?
> I'm not sure to be able to set a rate on a given node isn't it ?
>
> This have to be necessarily relative to rest of my graph
>
> All the best
>
> Francois
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> 2018-03-28 17:59 GMT+02:00 Daniel Patterson :
>
>> Hey François,
>>
>>   The only way to achieve this with OSRM would be to apply large
>> penalties to barriers/tolls.  You'll have to pick a penalty value that's
>> *just right* - enough that 0 or 1 will be acceptable, but 2 would force the
>> engine to find another route.
>>
>>   Because OSRM doesn't have dynamic costing options, you can't do
>> something like "penalize the first toll with 0, penalize the second toll
>> with 1000" - for that, you'd need to be able to run a more customizable
>> routing algorithm.
>>
>>   We have muttered about implementing A* on the edge-based-graph which
>> would make this possible, but so far, nobody has put the time in to
>> implement it.
>>
>> daniel
>>
>> On Wed, Mar 28, 2018 at 8:31 AM, François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Another question I have while I continue to build a routing system
>>> dedicated to industrial networks in parallel of roads we get from osm.
>>>
>>> I'd be interested to get osrm result with a limited amount of particular
>>> ways or nodes in the route.
>>> Something like "Get me from A to B with only 0 or 1 toll barrier on the
>>> route", is this possible ?
>>>
>>> I know the exclude URL parameter to exclude some pre-processed classes
>>> of object, but don't know if we can actually limit them.
>>>
>>> Thanks in advance for any hint, all the best
>>>
>>> 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: [Talk-ca] BC2020 Open Data and Data Mirroring

[Jonathan Brown]

Lessons learned from Finland and Poland in using OSM and Open Data: 
https://blog.core.okfn.org/2018/03/28/open-data-day-2018-getting-the-local-communities-in-porto-and-helsinki-to-talk-about-open-mapping/

Also, the research by Professor Peter Johnson at Waterloo on models of direct 
editing of government spatial data is germane to the BC2020 mapathon events. 
https://www.tandfonline.com/doi/abs/10.1080/15230406.2016.1176536
Two issues related to licensing: 
A) data ownership and license may permit or restrict government usage of 
contributed data, integration with existing government data, and hamper its 
ability to share data with others, particularly under an open license. 
Governments may face issues with accepting data from individuals through their 
own data collection system as users would need to acknowledge that they claim 
no right to the data or the database. Without such a clause, government would 
be at risk of having data contributors potentially remove their edits from a 
database. 
B) A second challenge would come from the integration of part or all of a 
separate database, such as OSM into a government database, which is then 
provided under a separate license than OSM (Saunders, Scassa, and Lauriault 
2012). OSM currently uses a license that has a share-alike clause, where any 
significant portion of the OSM data incorporated into a “derivative” database 
must continue to be licensed under the same Open Database License (ODbL v.1.0), 
including a share-alike clause. This means that any derivative data set must 
then be shared with the same or compatible licensing as the current OSM 
database (for more information, see https://wiki.osmfoundation. 
org/wiki/License). Through a complex and emerging field of database licensing 
law and compatibility, this share-alike clause may restrict the potential for 
blended OSM-government data products to be created as this derivative database 
would need to be contributed back to OSM and be made available under a separate 
license than from the government open data license. For example, the United 
States Geologic Survey (USGS) notes that they cannot integrate OSM data into 
the USGS National Map since OSM data uses a Creative Commons Share-Alike 
license, while their work needs to be under the public domain (Wolf, McNinch, 
and Poore 2011).

For the Durham Region Mapathon even that has been rescheduled for May 3, we 
could use crowdsourcing and data mirroring (below) based on the feedback I got 
from Professor Johnson who has demonstrated the value of open municipal data 
and GIS to local K-12 classroom teachers and students. 

Peter explores the following four models for inputting geospatial data into 
government databases in the above paper: 
1. status quo of open data
2. data curation
3. data mirroring
4. acceptance of external crowdsourced data.

Potential Issues with crowdsourcing: 
• “jurisdictionality of contribution, anonymity, and indeed the authority of 
contributors to make changes are all relevant in the instance that government 
were to adopt OSM. Through using OSM as a source of not only geospatial data, 
but as a conduit for edits, government shifts power over data creation and 
editing outside the walls of city hall.” (see page 7). 

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

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Flavio Bello Fialho]

A direção que a câmera está apontando é irrelevante. O que importa, na
prática é o sentido da via que está sendo monitorado. Dessa forma, para
highway=speed_camera, recomendo usar direction=forward ou
direction=backward, em casos de via de mão dupla, ou não usar o tag, em
caso de vias de mão simples (nesse caso, o sentido é óbvio). Em qualquer
caso, o tag maxspeed deve sempre ser especificado.

Quanto aos sinais de Pare (highway=stop), o pressuposto é que eles sempre
se aplicam ao cruzamento mais próximo, sendo geralmente desnecessário o uso
do tag direction. A exceção é caso de dois cruzamentos muito próximos em
uma via de mão dupla, com o highway=stop no meio, em que o cruzamento alvo
não é óbvio. Nesses casos, recomenda-se usar direction=forward ou
direction=backward, para indicar a direção do cruzamento ao qual se aplica
o highway=stop. Lembro ainda que, no caso de um "all-way stop", em que
todos devem parar, o tag "highway=stop" deve ser colocado no cruzamento, ao
passo que em outros casos deve ser colocado na via, um pouco antes do
cruzamento.

Em 27 de março de 2018 22:09, Fidelis Assis 
escreveu:

>
>
> Em 27 de março de 2018 20:19, Nelson A. de Oliveira 
> escreveu:
>
>> Para este fim não dá para usar direction para highway=speed_camera ou
>> similares.
>>
>> O direction indica apenas o lado que está apontando, mas não a direção
>> a que se aplica.
>> Por exemplo, pode ter câmera apontando para o sentido do fluxo
>> (pegando o carro pela parte de trás) ou apontando contra o sentido do
>> fluxo (pegando o carro pela frente).
>>
>
> Comentei sobre isso, direção da câmera, justamente para enfatizar que não
> se trata da direção da câmera. Esta não ajuda nada nesse caso.
>
> Aproveitando que o nome no iD não é câmera, mas 'sensor de velocidade',
> aliás muito bem escolhido por quem o fez, creio que se pode falar da
> direção dele assim como se fala da direção da respectiva placa de
> sinalização, para onde ela está voltada.
>
> A ideia/sugestão seria uma generalização, imaginar um guarda postado no
> local do alerta (seja sensor de velocidade, lombada, parada obrigatória,
> etc) e assim associarmos a direção do olhar do guarda com um hipotético
> olhar da lombada, do sensor, etc. Dessa forma a direction seria útil na
> extração da direção de atuação do alerta.
>
> Inverter o direction da câmera para gerar um aviso seria incorreto,
>> portanto.
>>
>
> Mas nos dois casos as directions mapeadas não são as das câmeras. São
> direções até opostas às delas, compatíveis com a direção do deslocamento.
> Dá para ver com street view. E não vejo sentido mesmo em mapear a direção
> da câmera num nó da via que representaria o *sensor* (normalmente sob o
> asfalto). Se você conferir, vai ver que a maioria dos sensores com
> direction no Brasil não representam a direção da câmera, mas o sentido do
> fluxo. O problema é que há dúvidas se deveriam representar sentido de fluxo
> ou para onde "olham". Assim, dependendo do mapeador temos um caso ou outro.
>
> Pessoalmente acho que deveriam sempre representar para onde olham quando o
> valor for graus ou pontos cardeais, como vale em geral para direction (*The
> key direction is used in a variety of situations to specify the direction
> of a feature*). No caso de forward/backward já existe uma prática em
> diversos países de que indicam a direção do fluxo afetado, como exemplo o
> mapeamento de parada obrigatória. Interessante é que se você especificar
> forward numa parada obrigatória em via de mão única (desnecessário mas não
> errado conforme a prática) o viewfield do iD olha para trás, indicando para
> onde o alerta "olha" (ou a placa respectiva), o contrário do sentido do
> fluxo.
>
>
>> Sem relação de enforcement não dá para representar a direção a que se
>> aplica.
>>
>
> Concordo que a relação de enforcement é uma solução definitiva mas é mais
> difícil de mapear. Há 600 sensores de velocidade em SP, apenas 19 deles com
> relação de enforcement. No Brasil são cerca de 6772, apenas 311 como
> enforcement. Minha sugestão foi primeiro para interpretar o mapeamento de
> 'sensor de velocidade' em nó de via como representando o sensor
> propriamente dito e não a câmera. Em segundo, aproveitar essa forma mais
> simples de mapear já largamente usada (apenas um nó na via) indicando
> direção apenas quando necessária e com forward/backward conforme as mesmas
> regras usadas para parada obrigatória em vários países.
>
> Abraços,
> -- Fidelis
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


-- 
Flávio Bello Fialho
bello.fla...@gmail.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] dataset MISE distributori

[Francesco Pelullo]

Il mer 28 mar 2018, 18:40 Cascafico Giovanni  ha
scritto:

> Solo l'anagrafica carburanti. Spero che l'ID univoco assegnato dal mise
> possa servire in futuro anche per  collegare altri dati.
>
> Sul nome, in effetti il dataset contiene il campo "nome impianto", ma sono
> decisi da i gestori e mi sembrano troppo eterogenei
>

Immagino.
Però esistono stazioni di servizio che hanno per davvero un nome proprio,
ad esempio "Area di servizio Tevere est" e così via. Valuterei l'opzione di
importarli con un alt_name o cose del genere.

Posso dare un altro suggerimento?
Propongo di verificare, prima dell'import, quali sono i distributori
presenti in OSM (e nel MISE) che distano meno di 80 metri. Sembra assurdo,
ma ce ne dovrebbero essere tanti. Giusto per avere una guida,
successivamente, di quali potrebbero essere i dati importati male, da
revisionare.

Ciao
/niubii/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Solo l'anagrafica carburanti. Spero che l'ID univoco assegnato dal mise
possa servire in futuro anche per  collegare altri dati.

Sul nome, in effetti il dataset contiene il campo "nome impianto", ma sono
decisi da i gestori e mi sembrano troppo eterogenei

Il 28 mar 2018 6:26 PM, "Francesco Pelullo"  ha
scritto:

> Ciao
> ho dato un'occhiata alla pagina sul wiki, il database del MISE contiene
> anche dati sui carburanti forniti, orari di apertura etc?
> O stiamo solo importando l'anagrafica?
>
> Ciao
> /niubii/
>
>
> Il giorno 28 marzo 2018 18:17, Martin Koppenhoefer  > ha scritto:
>
>>
>>
>> sent from a phone
>>
>> > On 28. Mar 2018, at 16:28, Andrea Musuruane  wrote:
>> >
>> > Queste sono regole generali. La domanda di Giovanni era inerente al
>> file CSV messo a disposizione dal MISE.
>>
>>
>> le regole generali si applicano anche al file del MISE, se nome non c’è
>> non si mette, se così non c’è alcun nome (preesistente) si potrebbe
>> ipotizzare di crearne uno, forse
>>
>>
>> Ciao, Martin
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Francesco Pelullo]

Ciao
ho dato un'occhiata alla pagina sul wiki, il database del MISE contiene
anche dati sui carburanti forniti, orari di apertura etc?
O stiamo solo importando l'anagrafica?

Ciao
/niubii/


Il giorno 28 marzo 2018 18:17, Martin Koppenhoefer 
ha scritto:

>
>
> sent from a phone
>
> > On 28. Mar 2018, at 16:28, Andrea Musuruane  wrote:
> >
> > Queste sono regole generali. La domanda di Giovanni era inerente al file
> CSV messo a disposizione dal MISE.
>
>
> le regole generali si applicano anche al file del MISE, se nome non c’è
> non si mette, se così non c’è alcun nome (preesistente) si potrebbe
> ipotizzare di crearne uno, forse
>
>
> Ciao, Martin
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 28. Mar 2018, at 16:28, Andrea Musuruane  wrote:
> 
> Queste sono regole generali. La domanda di Giovanni era inerente al file CSV 
> messo a disposizione dal MISE.


le regole generali si applicano anche al file del MISE, se nome non c’è non si 
mette, se così non c’è alcun nome (preesistente) si potrebbe ipotizzare di 
crearne uno, forse 


Ciao, Martin 



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

Re: [OSRM-talk] Limit particular points in a route at runtime

[François Lacombe]

Thank you for this input,

Understood the lack of dynamic costing in OSRM. I'll adapat my profile
Would it be preferable to lower the rate or the speed of specific way I
want to limit ? Maybe both ?
I'm not sure to be able to set a rate on a given node isn't it ?

This have to be necessarily relative to rest of my graph

All the best

Francois

*François Lacombe*

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

2018-03-28 17:59 GMT+02:00 Daniel Patterson :

> Hey François,
>
>   The only way to achieve this with OSRM would be to apply large penalties
> to barriers/tolls.  You'll have to pick a penalty value that's *just right*
> - enough that 0 or 1 will be acceptable, but 2 would force the engine to
> find another route.
>
>   Because OSRM doesn't have dynamic costing options, you can't do
> something like "penalize the first toll with 0, penalize the second toll
> with 1000" - for that, you'd need to be able to run a more customizable
> routing algorithm.
>
>   We have muttered about implementing A* on the edge-based-graph which
> would make this possible, but so far, nobody has put the time in to
> implement it.
>
> daniel
>
> On Wed, Mar 28, 2018 at 8:31 AM, François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Hi all,
>>
>> Another question I have while I continue to build a routing system
>> dedicated to industrial networks in parallel of roads we get from osm.
>>
>> I'd be interested to get osrm result with a limited amount of particular
>> ways or nodes in the route.
>> Something like "Get me from A to B with only 0 or 1 toll barrier on the
>> route", is this possible ?
>>
>> I know the exclude URL parameter to exclude some pre-processed classes of
>> object, but don't know if we can actually limit them.
>>
>> Thanks in advance for any hint, all the best
>>
>> 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: [OSRM-talk] Limit particular points in a route at runtime

[Daniel Patterson]

Hey François,

  The only way to achieve this with OSRM would be to apply large penalties
to barriers/tolls.  You'll have to pick a penalty value that's *just right*
- enough that 0 or 1 will be acceptable, but 2 would force the engine to
find another route.

  Because OSRM doesn't have dynamic costing options, you can't do something
like "penalize the first toll with 0, penalize the second toll with 1000" -
for that, you'd need to be able to run a more customizable routing
algorithm.

  We have muttered about implementing A* on the edge-based-graph which
would make this possible, but so far, nobody has put the time in to
implement it.

daniel

On Wed, Mar 28, 2018 at 8:31 AM, François Lacombe  wrote:

> Hi all,
>
> Another question I have while I continue to build a routing system
> dedicated to industrial networks in parallel of roads we get from osm.
>
> I'd be interested to get osrm result with a limited amount of particular
> ways or nodes in the route.
> Something like "Get me from A to B with only 0 or 1 toll barrier on the
> route", is this possible ?
>
> I know the exclude URL parameter to exclude some pre-processed classes of
> object, but don't know if we can actually limit them.
>
> Thanks in advance for any hint, all the best
>
> 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] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Quelques dizaines d’euros de différence, c’est le pain pour un mois. Les petits 
budgets, dont je suis, apprécieront cette différence de prix ; les pays en voie 
de développement aussi, d’ailleurs. Les contributeurs africains, par exemple, 
seraient sans doute bien contents d’avoir un truc pas cher et tout simple, type 
allumer-enregistrer, plutôt qu’un smartphone avec des dizaines de fonctions 
mais dont une seule, le GPS, les intéresse ; et puis, ça permettrait de laisser 
les moins dégourdis avec la technologie faire des traces, en France ou 
ailleurs. Je pense aussi aux bidouilleurs, qui préféreront reprendre les plans 
du bidule et l’assembler eux-mêmes plutôt que d’acheter un truc tout fait.

Pour la précision, je pense que l’antenne extérieure serait déjà une bonne 
avancée par rapport aux antennes intégrées des smartphones, mais c’est 
totalement subjectif, n’ayant jamais testé réellement la chose.


De : Francois Gouget 
Envoyé : mercredi 28 mars 2018 00:35
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

On Tue, 27 Mar 2018, David Marchal wrote:

> L’intérêt est, je pense, d’avoir un boîtier discret, simple et pas
> trop cher, qui ne serve qu’à ça pour ne pas avoir besoin d’un
> smartphone au prix supérieur et plus complexe.

Et se passer d'OsmAnd~, Street-Complete et Mapillary / OSC ?
Impensable ;-) !


> Ça pourrait viser, [...] ceux qui n’en ont pas les moyens

On peut trouver un bon smartphone à 150€ (Zenfone 2 ZE551ML). Les plus
basiques commencent à 80€ à tout casser et je n'ai pas l'impression que
leurs GPS soient tellement pire. Donc pour que l'opération ait du sens
d'un point de vue strictement économique il faudrait que ce GPS maison
coûte moins de 60€ (80€ - 20€ pour un dumbphone), ou moins de 95€ si on
retient un prix moyen.


[...]
> Et puis, il y a bien sûr l’histoire de la précision, qui risque fort
> d’être meilleure, ce qui est un gros plus quand on modélise sur OSM.

Je suis sceptique sur les chances d'avoir une précision
significativement meilleure en restant sur les technologies standard et
pas chères ; c'est à dire qui n'exploitent que le signal L1 et sans
techniques type GPS différentiel.

L'email de Stéphane Péneau aurait tendance à me renforcer dans ces
convictions. Mais je ne suis pas un spécialiste des GPS alors peut-être
que je suis trop pessimiste. Ou alors j'attends trop des GPS. Une
précision de +/- 1 m en ville et en forêt, là ça changerait la donne.
Mais déjà à +/- 3 m... bof.


--
Francois Gouget   http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SotM-France, contributeurs de Pessac, Bordeaux, Gironde, Nouvelle-Aquitaine, unissons-nous !

[Vincent Bergeot]

Bonjour,

_*changement de date pour la préparation*_

La réunion de préparation /(initialement prévue le mardi 3 avril)/ est 
décalée au *lundi 9 avril*, à partir de 18h, à l'UMR Passages, c'est ici 
: https://osm.org/go/b~~Fu4Xhj?m=


Bonne journée


Le 23/03/2018 à 09:55, Vincent Bergeot a écrit :


Bonjour,

du 1-3 juin 2018, à Pessac (Bordeaux-Métropole) se déroule le State of 
the Map France, 
https://wiki.openstreetmap.org/wiki/FR:State_of_the_Map_France_2018


*R**éunion le mardi 3 avril à 18h sur le campus de Pessac à l'UMR 
Passages* pour faire le point sur l'organisation et son 
fonctionnement, donner un coup de main, avant, pendant et après le 
State of the Map, et pourquoi pas l'occasion de démarrer un groupe 
local (bon peut-être que je rêve, mais j'aime rêver !).


N'hésitez pas à en discuter ici ou à m'informer de votre 
volonté/possibilité de participer ou pas !


Bonne journée

PS : l'appel à contribution est toujours ouvert, jusqu'au 15 avril ici 
: 
https://framaforms.org/proposition-dintervention-au-sotm-france-2018-1517936730


--
Vincent Bergeot


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



--
Vincent Bergeot

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

Re: [Talk-it] MAPUTNIK E LEAFLET

[Stefano]

Il giorno 28 marzo 2018 16:08, Roberto Brazzelli 
ha scritto:

> Ciao, ho creato un mio stile con l'editor
> on line maputnik e voglio inserire questo
> stile (nomefile.json) come sfondo nella mia mappa creata
> con leaflet o in alternativa in qgis.
> Qualcuno sa darmi indicazioni?
>

Ciao,
per Leaflet ti serve Mapbox GL e mapbox-gl-leaflet.
Trovi il plugin con esempi qui

https://github.com/mapbox/mapbox-gl-leaflet


> grazie
>
>
Ciao,
Stefano


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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao Martin,

2018-03-28 15:55 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 28. Mar 2018, at 10:26, Cascafico Giovanni 
> wrote:
> >
> > A questo proposito cosa mettiamo nel tag name? Duplichiamo il brand,
> mettiamo l'operator? Lasciamo vuoto?
>
>
>
> se abbiamo un nome mettiamo quello, io metto il nome da scontrino quando
> c’è (talvolta ho messo l’operator senza la forma giuridica), spesso rimane
> vuoto, quando c’è già il brand in nome lo lascio normalmente, ma non mi
> metto a duplicare quando non c’è
>
> oppure metto il nome del “tipo” (insegna), per esempio (inventato)
> name=Esso Express
> (brand Esso)
>

Queste sono regole generali. La domanda di Giovanni era inerente al file
CSV messo a disposizione dal MISE.

Ciao,

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

[Talk-it] MAPUTNIK E LEAFLET

[Roberto Brazzelli]

Ciao, ho creato un mio stile con l'editor
on line maputnik e voglio inserire questo
stile (nomefile.json) come sfondo nella mia mappa creata
con leaflet o in alternativa in qgis.
Qualcuno sa darmi indicazioni?
grazie

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[Hartwig Alpers]

Moin!

On 28.03.2018 12:48, dktue wrote:
Kann mich jemand bezüglich des Verlaufs nördlich von Hammelburg und 
südlich von Fulda unterstützen? Ich sehe dort keine Ways, die "ref"="B 
27" tragen und somit in die Relation aufgenommen werden sollten.
Zwischen Hammelburg & Fulda ist die B 27 unterbrochen, wohl wegen ihrer 
Nähe zur A 7. Das ist korrekt so, wie es ist.


Viele Grüße
Hartwig


Am 28.03.2018 um 12:10 schrieb Moritz:



Am 2018-03-28 11:52, schrieb dktue:

Ich habe mich mal daran versucht, könnte vielleicht ein anderer Mapper
mal gegenprüfen [1], ob ich etwas kaputt gemacht habe?

[1] https://www.openstreetmap.org/relation/2064452


Der Relation Analyzer[1] sieht da noch große Lücken.

Moritz

[1]: http://ra.osmsurround.org/analyzeRelation?relationId=2064452

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



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


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

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 28. Mar 2018, at 10:26, Cascafico Giovanni  wrote:
> 
> A questo proposito cosa mettiamo nel tag name? Duplichiamo il brand, mettiamo 
> l'operator? Lasciamo vuoto?



se abbiamo un nome mettiamo quello, io metto il nome da scontrino quando c’è 
(talvolta ho messo l’operator senza la forma giuridica), spesso rimane vuoto, 
quando c’è già il brand in nome lo lascio normalmente, ma non mi metto a 
duplicare quando non c’è 

oppure metto il nome del “tipo” (insegna), per esempio (inventato) name=Esso 
Express
(brand Esso)

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-ja] 高速道路の定義について

[tomoya muramoto]

過去にtalk-jaで`highway=*`の定義に関して議論されたスレッドを見つけましたので展開します。
https://lists.openstreetmap.org/pipermail/talk-ja/2009-October/001664.html

なお私は、Japan taggingに「従って大きな改版をする際はOpenStreetMap Japan メーリングリスト
でお知らせ、意見交換されることを望みます。」と記載されているとおり、今現在、改版を念頭に置いて意見交換を進めているフェーズであると認識しております。
https://wiki.openstreetmap.org/wiki/Japan_tagging

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

Re: [OSM-ja] 高速道路の定義について

[tomoya muramoto]

少しだけオフトピックですが、Japan
tagging内の`highway=track`の定義を修正するのを失念していましたので、のちほど変更いたします。

※2016/10に`highway=track`の日本での解釈について、talk-jaでアナウンスした上で、osm
wikiで議論を進めました。その結果、(主な目的であったunclassifiedとtrackの区分にあいまいなところは残りましたが)`highway=track`はJapan
taggingに記載されている「廃道や未舗装路」ではなく、農業または林業向けに主として利用されている道路であることは確認できたと思います。
https://lists.openstreetmap.org/pipermail/talk-ja/2016-October/009560.html
https://wiki.openstreetmap.org/wiki/JA:Tag:highway%3Dtrack

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[Scholtes, Martin]

Auch ein Beispiel ist wenn 2 Bs Den selbigen Weg nutzen. Dann ist aber nur eine 
B Nummer gültig.

Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)
Von: Harald Hartmann 
An: talk-de@openstreetmap.org
Cc:


> Ich glaube, es gibt durchaus Bundesstraßen, die echte Lücken haben.

Als Beispiel aus meiner Gegend, da wurde die B4 auf Grund der nun
parallel verlaufenden Autobahnen (A73/A71) zur L3004 "degradiert" und
ist somit auch kein Teil der B4 mehr.

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[wambacher]

Am 28.03.2018 um 15:26 schrieb wambac...@posteo.de:

Hi,


Am 28.03.2018 um 12:48 schrieb dktue:
Kann mich jemand bezüglich des Verlaufs nördlich von Hammelburg und 
südlich von Fulda unterstützen? Ich sehe dort keine Ways, die 
"ref"="B 27" tragen und somit in die Relation aufgenommen werden 
sollten.


*Technisch* können dir viele Kollegen helfen, aber die Entscheidung, 
was B27 ist oder nicht, musst du schon selber treffen. Dazu gehören 
halt lokales Wissen und/oder legale Quellen.


Ich glaube, es gibt durchaus Bundesstraßen, die echte Lücken haben.

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


--
My projects:

Admin Boundaries of the World 
Missing Boundaries 


Emergency Map 
Postal Code Map (Germany only) 
Fools (QA for zipcodes in Germany) 
Postcode Boundaries of Germany 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[Harald Hartmann]

> Ich glaube, es gibt durchaus Bundesstraßen, die echte Lücken haben.

Als Beispiel aus meiner Gegend, da wurde die B4 auf Grund der nun
parallel verlaufenden Autobahnen (A73/A71) zur L3004 "degradiert" und
ist somit auch kein Teil der B4 mehr.

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[wambacher]

Hi,


Am 28.03.2018 um 12:48 schrieb dktue:
Kann mich jemand bezüglich des Verlaufs nördlich von Hammelburg und 
südlich von Fulda unterstützen? Ich sehe dort keine Ways, die "ref"="B 
27" tragen und somit in die Relation aufgenommen werden sollten.


*Technisch* können dir viele Kollegen helfen, aber die Entscheidung, was 
B27 ist oder nicht, musst du schon selber treffen. Dazu gehören halt 
lokales Wissen und/oder legale Quellen.


Ich glaube, es gibt durchaus Bundesstraßen, die echte Lücken haben.

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

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Ho fatto una bozza di wiki [1], se qualcuno volesse correggere, integrare
e/o discuterne


[1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/ItalyFuelStations
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-br] (sem assunto)

[Smaran Rneu]

Olá a todos,

Procuro pessoas da região de São José do Rio Preto SP que saibam mapear
para o OSM.

Queremos conversar sobre o levantamento de um antiga estrada (Estrada
Boiadeira) que existia aqui na região e ia até o Mato Grosso.

Agradeço indicações

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

Re: [Talk-it] Campeggio privato

[demon.box]

dieterdreist wrote
> Per me va bene il tuo
> access=private, landuse=camp_site (se permanente).

scusate ma... landuse=camp_site mi suona nuovo ed infatti non è
documentato e in taginfo trovo 1 utilizzo...

mi spiegate per favore?

grazie ;-)

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-ja] 高速道路の定義について

[yuu hayashi]

hayashiです

そもそもこの議論の発端は このスレッドの先頭のあまのさんの発起で

> 「highway=motorway の定義は、入口に自動車専用道路の標識がついている道路です。」というのは的を得ているでしょうか？

というものです。

それに対して幾人の方から
現状の「highway=motorway」の付け方がばらばらで実情を反映したものではない
という意見が出されました。
田口さんTomさんの見立てでもざっくりまとめさせていただくと「高速道路」と「自動車専用道路の標識がついている道路」は違うんじゃないのか？
実は私も「高速道路」と「自動車専用道路」とは別物で個別にタグ付けすべきと考えています。

皆さんが同じ意見を持っているのに、議論が全然咬み合わない理由に、今朝やっと気づきました。
気づくのが遅くて申し訳ありませんでした。

多くの方が「Japan tagging」(https://wiki.openstreetmap.org/wiki/Japan_tagging)
のページを「翻訳ページ」か「チートシート」だと勘違いされているようです。
「highway=motorway」の記述が「JA:Tag:highway=motorway(
https://wiki.openstreetmap.org/wiki/JA:Tag:highway%3Dmotorway)」と違っているので
Japan_tagging が誤訳か更新漏れだと思っていませんか？

「Japan_tagging が誤訳」と仮定してこのスレッドをすべて読み返してみたところ、みなさまの言わんとしている意味が理解できるようになりました。

しかし、「Japan_tagging」は「翻訳ページ」や「チートシート」の類ではありません。
もし、「Japan_tagging
の定義が変だから改定すべき」と考えているようでしたら、今一度「Japan_tagging」がOSMのタグ付け体型の中でどうゆう役割なのかご自身でよく考えて理解してください。

---

ここから先は「Japan_tagging」の役割が理解できた方だけ読み進めてください。

「Japan_tagging」の役割が理解できた方なら、
「Japan_tagging の定義が変だから改定すべき」ではなく、
「Japan_tagging をより充実させる」ことで「高速道路」のモヤモヤ問題も「車種別の通行区分」の問題も解決できることに気づくはずです。

今まで多くのマッパーが「Japan_tagging」を誤訳だと思って無視し放置されたことが原因で、
・「highway=motorway」のタグ付けがばらばらで統一されなくなり、
・「高速道路」のタグ付け方法がわからなくなり、
・「道路標識」をマッピングすることすらできない
という状況がいつまでも続いていることに気づくはずです。

私は、日本のマッピング状況がヨーロッパに比べて発展が遅い原因のひとつに日本人マッパーが「Japan_tagging」を無視するからだ、とも考えています。

それでも「"Japan_tagging"の motorway
はおかしい」と思う方は、私に議論を挑む前にOSMのタグ付け体系とローカライズの考え方とリレーションの規定体系をよく調べたうえ個別でメールしてください。

このTalk-jaではどうすれば現状の問題を解決できるかという前向きな議論の場にしていきたいと考えています。

ひとりひとりがOSMを正しく認識したうえで議論をすすめれば、JapanTaggingに関する問題は
新しいタグを世界に提案するより簡単に解決できるはずだと信じています。

hayashi.



2018年3月28日 13:40 Tomomichi Hayakawa :

> Tomです。
>
> 途中に割り込みすみません。以下、参考資料としていただければ幸いです。
>
> 私は、高速道路には詳しくありませんので、
> 重要な議論と思いつつも、具体的にどの道路のことを指しているのか、分からないところも多く、
> 日本で高速道路と呼ばれる道路についてWikipediaを参考に調べてみました。
> もし、同様の方がいらっしゃれば、以下をご参考にしていただければ幸いです。
>
> 個人的には、wikipediaなどの素人でも分かりやすいところで、線引きするような方向性を望んでおります。
>
>
> 「国道２３号バイパス」は「名四国道（名四バイパス）」と呼ばれる道路ですね。
> その昔、有料道路だった時代もあったと記憶しておりますが、今は無料のはずです。個人的には一般国道のバイパスと理解しています。
>
> 「名阪国道」「京葉道路(R14)」ですと、「（A'路線）高速自動車国道に並行する一般国道自動車専用道路」になっていますね。
>
>
>
> 【高規格幹線道路】
> https://ja.wikipedia.org/wiki/%E9%AB%98%E8%A6%8F%E6%A0%BC%
> E5%B9%B9%E7%B7%9A%E9%81%93%E8%B7%AF
>
> ＊（A路線）高速自動車国道
> https://ja.wikipedia.org/wiki/%E9%AB%98%E9%80%9F%E8%87%AA%
> E5%8B%95%E8%BB%8A%E5%9B%BD%E9%81%93
> ・国土開発幹線自動車道（国幹道）
> ・高速自動車国道として建設すべき道路の予定路線（国土開発幹線自動車道の予定路線を除く）のうちから政令でその路線を指定したもの：
> 成田国際空港線、関西国際空港線、関門自動車道、沖縄自動車道の4路線
>
> ＊（A'路線）高速自動車国道に並行する一般国道自動車専用道路（名阪国道など）
> https://ja.wikipedia.org/wiki/%E9%AB%98%E9%80%9F%E8%87%AA%
> E5%8B%95%E8%BB%8A%E5%9B%BD%E9%81%93%E3%81%AB%E4%B8%A6%E8%A1%
> 8C%E3%81%99%E3%82%8B%E4%B8%80%E8%88%AC%E5%9B%BD%E9%81%93%E8%
> 87%AA%E5%8B%95%E8%BB%8A%E5%B0%82%E7%94%A8%E9%81%93%E8%B7%AF
>
> ＊（B路線）国土交通大臣指定に基づく高規格幹線道路（一般国道の自動車専用道路）
> https://ja.wikipedia.org/wiki/%E5%9B%BD%E5%9C%9F%E4%BA%A4%
> E9%80%9A%E5%A4%A7%E8%87%A3%E6%8C%87%E5%AE%9A%E3%81%AB%E5%9F%
> BA%E3%81%A5%E3%81%8F%E9%AB%98%E8%A6%8F%E6%A0%BC%E5%B9%B9%E7%
> B7%9A%E9%81%93%E8%B7%AF%EF%BC%88%E4%B8%80%E8%88%AC%E5%9B%BD%
> E9%81%93%E3%81%AE%E8%87%AA%E5%8B%95%E8%BB%8A%E5%B0%82%E7%94%
> A8%E9%81%93%E8%B7%AF%EF%BC%89
>
> ＊（B路線に準じる）本州四国連絡道路
> https://ja.wikipedia.org/wiki/%E6%9C%AC%E5%B7%9E%E5%9B%9B%
> E5%9B%BD%E9%80%A3%E7%B5%A1%E9%81%93%E8%B7%AF
>
>
> 【地域高規格道路】
> https://ja.wikipedia.org/wiki/%E5%9C%B0%E5%9F%9F%E9%AB%98%
> E8%A6%8F%E6%A0%BC%E9%81%93%E8%B7%AF%E4%B8%80%E8%A6%A7
> 一覧中で、○は自動車専用道路または自動車専用道路として建設される予定の道路である。
>
> ＊都市圏自動車専用道路（首都高速、名古屋高速など）
> https://ja.wikipedia.org/wiki/%E9%83%BD%E5%B8%82%E9%AB%98%
> E9%80%9F%E9%81%93%E8%B7%AF
>
> ＊一般 （都市圏自動車専用道路以外）
>
>
> 【その他の自動車専用道路】（高規格幹線道路及び地域高規格道路に分類されない自動車専用道路。）
> https://ja.wikipedia.org/wiki/%E3%81%9D%E3%81%AE%E4%BB%96%
> E3%81%AE%E8%87%AA%E5%8B%95%E8%BB%8A%E5%B0%82%E7%94%A8%E9%81%
> 93%E8%B7%AF%E4%B8%80%E8%A6%A7
>
> 2018年3月28日 11:48 Takahisa TAGUCHI :
> > 田口です。
> >
> > 議論の発端になったR23のバイパスに関して、わたしがMapillaryへアップした
> > 写真をみると以下のようになっています
> > https://goo.gl/X5dhrg
> >
> > これを見ると、厳密には「自動車専用道路」ではないが、自動車専用道路の
> > ように自転車や歩行者の通行を制限したいという大人の事情が鑑みえます。
> > 個人的にはこれはTrunkかなと思いますが、例えば名阪国道なんかも
> > 意見が割れそうな気がします。
> >
> > 名阪国道の特徴を挙げると、、、
> > ・一般国道だが高速道路ナンバリングが振られていて、高速道路と直接接続
> > ・本線には（60km/h制限順守を呼びかけるため）高速道路ではないことを
> > 主張する標識が多数あるが、入り口には 『自動車専用道路』の標識がある
> > ・無料で通行できるのと、名物「Ωカーブ」が構造規格ギリギリで作られている
> > せいか、市販の地図では慣例的に国道として扱われることが多い
> >
> > 一方で Ras and Roadさんが例で上げられている京葉道路(R14)や小田原厚木道路
> > (R271)は世間一般的には「高速道路」という認識が強いと思うので、わたしも
> > 最終的には現地の実情や多数の意見に合わせる方向でよいのかなとは思います。
> >
> > # あまりにも酷い都道府県道などもそのような方向でマッピングされていたかと
> > # 思います、、、
> >
> >
> > ___
> > Talk-ja mailing list
> > Talk-ja@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ja
>
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> はやかわ ともみち (Tomomichi Hayakawa)
> tom.hayak...@gmail.com
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>

Re: [OSM-talk-fr] Import station essence

[marc marc]

deuzeffe le propriétaire d'une base peux tjs donner un droit spécifique 
pour l'ajout de ces données dans osm. les données dans osm seront alors 
accessible comme n'importe quel objet osm.

Christian : pourquoi n'utilise-t-on pas la base des prix des carburants 
pour mettre à jour osm si elle contient de meilleurs infos ?

JP : tu veux dire que si une marque est incorrecte,
l'opération ne doit pas la corriger ?
Alors faudrait une xieme catégorie osmose pour qu'un humain le fasse ?

pour la conclusion, je crois qu'il faut nuancer par élément
afin de garder l'utile au lieu de tout jeter :

- heure d'ouverture : à virer vu que ceux-ci semblent souvent 
correspondre au magasin et non à la stations d'essence souvent 24/7
en cas de payement possible par carte.

- code postaux : aucun sens, personne n'écrit à une station d'essence.
cela n'aurait du sens que pour les magasins.
On pourrait pas contre s'en servir pour vérifier si les codes postaux 
définit sur les aires (les communes principalement) sont correct et 
faire une alerte qualité si cela ne correspond pas au lieu d'importer.

- numéro de téléphone : uniquement les numéros uniques qui ont des 
changes d'être ceux de la station elle-même et non du siège social.

- brand : cette info me semble par contre intéressante vu la confusion 
importante dans les stations actuelle entre nom <> operator <> brand

- doublon : l'outil doit rechercher les doublons dans un rayons plus 
large que cela actuellement utilisé vu la géolocalisation imprécise.
Ce n'est qu'alors qu'on pourrait se faire une idée des réels ajouts
de station grâce à cette base par rapport à l'existant dans osm.

- ref : si chaque compagnie de seo met sa propre ref, cela ne
va évidement pas.
d'un autre côté je comprend tout autant qu'une compagnie mondiale
ne va pas utiliser 30 ref différentes selon la situation de chaque pays.
je pense donc que l'outil doit se passer de ref.

- disussed : tant mieux si l'import le gère.
il doit cependant aussi prendre en compte à la prochaine maj les 
stations qui ont été effacée dans osm (analyse des diff) au lieu
de les recréer (c'est pas au contributeur osm de se farcir la doc
de tous les imports ayant un lien avec chaque objet qu'il modifie)

- demander une copie de la base pour traiter les ajouts via osmose,
j'y crois peu vu les 400k éléments en attente d'intervention humaine.
osmose.openstreetmap.fr/fr/errors/graph.png?item=8xxx=france*
Vaut mieux améliorer la qualité de l'import plutôt que de mettre
sur une pile dont pas assez de monde ne s'occupe.
Ce serra très différent si les créations étaient séparée des maj

Stéphane si t'as besoin d'un coup de main pour formuler
tout cela en anglais, dis le moi.
ou mieux un dernier brouillon ici avant envoi histoire que les doués
en anglais corrigent au besoin :)

Le 28. 03. 18 à 11:55, Christian Quest a écrit :
> En gros la conclusion c'est quoi ? Communauté FR opposée à cet import ? 
> ok pour moi ;)
> 
> On a des données plus propre dans la base des prix des carburants.
> 
> Le 27 mars 2018 à 22:01, Stéphane Péneau a écrit :
> 
> Il n'y a plus de remarque ? J'envoie la réponse ?
> 
> Stf
> 
> 
> Le 26/03/2018 à 14:58, Stéphane Péneau a écrit :
> 
> Pour ma part, j'ai trouvé plusieurs stations-service manquantes
> que ce jeu de données pourrait ajouter.
> Donc non, je ne pense pas qu'il faut tout jeter, ni lui tomber
> dessus en hurlant que son truc, "c'est d'la merde".
> 
> J'espère qu'on peut être un peu plus constructif. On a tous à y
> gagner.
> 
> Stf
> 
> Le 26/03/2018 à 14:33, deuzeffe a écrit :
> 
> Le 26/03/2018 à 13:47, marc marc a écrit :
> 
> La source est Navads.
> 
> 
> Et « We have the full permission to add all of these to
> OpenStreetMap: that's the very reason we were contacted. »
> (from https://wiki.openstreetmap.org/wiki/Navads_Imports#Source)
> semble suffisant ? Quid de telles données une fois qu'elles
> font partie d'OSM, avec une telle (absence de) licence
> (clairement pas identifiée) ?
> 
> -- 
> deuzeffe - qui s'instruit
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Navads-Tankstellenimport

[André Riedel]

Im Bereich Chemnitz und Mittelsachsen passen die Zuordnungen und
ergänzten Werte. Vielleicht kann Ilya, die vorgeschlagenen Bewertung
der Änderung integrieren.

Am 28. März 2018 um 11:12 schrieb Christoph Hormann :
> On Tuesday 27 March 2018, Michael Reichert wrote:
>> > POI-Daten sind auch in Deutschland unvollständig und werden
>> > unvollständig bleiben. Wir begrüßen Unterstützung bei der
>> > Verbesserung des POI-Datenbestands in Deutschland. Trotzdem
>> > entspricht die Datenqualität des Imports nicht unseren Erwartungen.
>> > Wir selbst haben auch Gegenden ohne aktive Mapper, die sich um ihre
>> > Gegend kümmern. Daher werden Fehler, die der Import mit sich
>> > bringt, nicht behoben werden. Außerdem ist es nicht die unsere
>> > Aufgabe als *Freiwillige* den Datenbestand eines kommerziellen
>> > Anbieters zu verbessern.
>> >
>> > *Dieser Import ist gegen die Interessen der deutschen
>> > OSM-Community*. Das Anbieten einer Liste oder der Unterschiede
>> > zwischen dem Navads-Datenbestand und OSM ist gern gesehen und hilft
>> > uns, unser Werk zu verbessern, ohne die Aufwand des Importmanagers
>> > in die Verbesserung der Daten oder der Software zu erhöhen.
>
> Ich halte das für eine zu pauschale Darstellung die nicht wirklich das
> Meinungsbild der Äußerungen hier und im Forum komplett wiedergibt.
>
> Es wurden eine ganze Reihe von Problemen herausgearbeitet, die dem
> Import wie geplant im Wege stehen, aber es gibt auch eine Reihe von
> Dingen, die auf Basis der verfügbaren Informationen machbar und
> zumindest von einem erheblichen Teil derjenigen, die sich geäußert
> haben, vermutlich Unterstützung finden könnten - so zum Beispiel das
> Ergänzen von fehlenden Telefonnummern und Öffnungszeiten bei Objekten,
> wo es eine eindeutige Identität zwischen OSM-Objekt und Navads-Objekt
> gibt.
>
> Ein möglicher Vorschlag wäre zum Beispiel, die Daten in verschiedene
> Gruppen aufzuteilen (Tag-Ergänzungen bei eindeutiger Identität,
> Tag-Ersetzungen, Nicht ganz eindeutige Fälle, eindeutig neue Objekte)
> und nur einen Teil davon automatisch zu ergänzen und den Rest für die
> manuelle Bearbeitung aufzubereiten.
>
> Ob Ilya sich auf sowas einlässt steht auf einem ganz anderen Blatt -
> aber ich halte es für deutlich besser, sich da offen zu zeigen (denn
> das sind ja nützliche Daten - zumindest für den Abgleich und das Finden
> von Lücken) als kategorisch das Ganze abzulehnen.
>
> Und für viel entscheidender als ob dieser Import jetzt am Ende
> stattfindet oder nicht halte ich, dass das Primat der lokalen Community
> in solchen Fällen (länderübergreifende Importe) aufrecht erhalten wird.
> Und das tut man wenn man auf Anpassungen an die jeweilige lokale
> Situation besteht mindestens genauso gut wie wenn man alles einfach
> ablehnt.  Und die Außenwirkung einer pauschalen Ablehnung ist halt
> auch, dass die deutsche Community arrogant ist, meint alles besser zu
> wissen und sich gegenüber Mappern von anderswo abgrenzt.  Ich bin mir
> ziemlich sicher, dass ein solches Bild nicht von einer Mehrheit hier
> gewünscht wird.
>
> Auch denke ich, dass hier nicht die Absicht von Navads/Maps.me vorliegt,
> die Daten von Navads für die eigene Verwendung zu verbessern - man
> möchte wohl in erster Linie die Daten für eine bessere Sichtbarkeit in
> OSM hinein bekommen und dabei möglichst keinen Aufwand haben.  Wie viel
> Arbeit sich die OSM-Community darüber hinaus mit den Daten macht dürfte
> ihnen ziemlich egal sein.
>
>> > Michael Reichert aka Nakaner
>> > nach Diskussion und im Namen der deutschen OpenStreetMap-Community
>> > im deutschen OSM-Forum und auf der Mailingliste Talk-de
>
> Auch da solltest Du denke ich ein bisschen vorsichtig sein - Du gibst
> hier maximal die Meinung derer wieder, die sich in diesen Kanälen
> geäußert haben.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[dktue]

Kann mich jemand bezüglich des Verlaufs nördlich von Hammelburg und 
südlich von Fulda unterstützen? Ich sehe dort keine Ways, die "ref"="B 
27" tragen und somit in die Relation aufgenommen werden sollten.


Am 28.03.2018 um 12:10 schrieb Moritz:



Am 2018-03-28 11:52, schrieb dktue:

Ich habe mich mal daran versucht, könnte vielleicht ein anderer Mapper
mal gegenprüfen [1], ob ich etwas kaputt gemacht habe?

[1] https://www.openstreetmap.org/relation/2064452


Der Relation Analyzer[1] sieht da noch große Lücken.

Moritz

[1]: http://ra.osmsurround.org/analyzeRelation?relationId=2064452

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



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

Re: [OSM-talk-fr] Import station essence

[pepilepi...@ovh.fr]

Le 28/03/2018 à 11:55, Christian Quest a écrit :
> En gros la conclusion c'est quoi ? Communauté FR opposée à cet import
> ? ok pour moi ;)

Fortement opposé en l'état.

Ajouter des stations vraiment nouvelles, oui, c'est une bonne idée, mais
il faudrait les vérifier humainement. Il y en a très peu, en réalité
(Les marqueurs verts si j'ai bien vu), ça peut se faire.

Mais surtout il faudrait que cet import ne MODIFIE aucune donnée, qu'il
se contente d'ajouter les infos manquantes : horaires, type de
carburant, marque etc.


JP

>
> On a des données plus propre dans la base des prix des carburants.
>
> Le 27 mars 2018 à 22:01, Stéphane Péneau  > a écrit :
>
> Il n'y a plus de remarque ? J'envoie la réponse ?
>
> Stf
>
>
> Le 26/03/2018 à 14:58, Stéphane Péneau a écrit :
>
> Pour ma part, j'ai trouvé plusieurs stations-service
> manquantes que ce jeu de données pourrait ajouter.
> Donc non, je ne pense pas qu'il faut tout jeter, ni lui tomber
> dessus en hurlant que son truc, "c'est d'la merde".
>
> J'espère qu'on peut être un peu plus constructif. On a tous à
> y gagner.
>
> Stf
>
> Le 26/03/2018 à 14:33, deuzeffe a écrit :
>
> Le 26/03/2018 à 13:47, marc marc a écrit :
>
> La source est Navads.
>
>
> Et « We have the full permission to add all of these to
> OpenStreetMap: that's the very reason we were contacted. »
> (from
> https://wiki.openstreetmap.org/wiki/Navads_Imports#Source
> )
> semble suffisant ? Quid de telles données une fois
> qu'elles font partie d'OSM, avec une telle (absence de)
> licence (clairement pas identifiée) ?
>
> -- 
> deuzeffe - qui s'instruit
>
>
>
> ___
> 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
> 
>
>
>
>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[Moritz]

Am 2018-03-28 11:52, schrieb dktue:

Ich habe mich mal daran versucht, könnte vielleicht ein anderer Mapper
mal gegenprüfen [1], ob ich etwas kaputt gemacht habe?

[1] https://www.openstreetmap.org/relation/2064452


Der Relation Analyzer[1] sieht da noch große Lücken.

Moritz

[1]: http://ra.osmsurround.org/analyzeRelation?relationId=2064452

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

Re: [Talk-it] Tratti brevi e riferimenti

[Simone Saviolo]

Il giorno 27 marzo 2018 22:36, aldoct  ha scritto:

> Sulla ortodossia sono d'accordo; il mio quesito è: a fronte di un rendering
> sgradevole (se si può mappare con un rendering più opportuno, perché non
> farlo?), cosa succede di sbagliato se si cancellano i riferimenti per
> tratti
> di pochi metri?


Mi autocito:

Il giorno 27 marzo 2018 09:26, Simone Saviolo  ha
scritto:

> Il giorno 27 marzo 2018 00:30, aldoct  ha scritto:
>
>> Comporta qualcosa cancellare i riferimenti clonati nei
>> tratti brevi?
>>
>
> Sì, comporta che cancelli dati corretti :)
>

Capisco che la tentazione di vedere una mappa bella è forte: credo che ci
siamo cascati tutti prima o poi. Però tu (mappatore) fai una mappa, qualcun
altro (renderer) la farà bella. Se vuoi farla bella, devi metterti il
cappellino del renderer - e a quel punto sui dati della mappa non
intervieni più. Al limite, il rendering potrebbe farsi una copia
temporanea, di lavoro, in cui toglie il ref dai tratti più brevi di tot
pixel, la usa per disegnare, poi la butta via.

Ciao,

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

Re: [OSM-talk-fr] Import station essence

[Christian Quest]

En gros la conclusion c'est quoi ? Communauté FR opposée à cet import ? ok
pour moi ;)

On a des données plus propre dans la base des prix des carburants.

Le 27 mars 2018 à 22:01, Stéphane Péneau  a
écrit :

> Il n'y a plus de remarque ? J'envoie la réponse ?
>
> Stf
>
>
> Le 26/03/2018 à 14:58, Stéphane Péneau a écrit :
>
>> Pour ma part, j'ai trouvé plusieurs stations-service manquantes que ce
>> jeu de données pourrait ajouter.
>> Donc non, je ne pense pas qu'il faut tout jeter, ni lui tomber dessus en
>> hurlant que son truc, "c'est d'la merde".
>>
>> J'espère qu'on peut être un peu plus constructif. On a tous à y gagner.
>>
>> Stf
>>
>> Le 26/03/2018 à 14:33, deuzeffe a écrit :
>>
>>> Le 26/03/2018 à 13:47, marc marc a écrit :
>>>
 La source est Navads.

>>>
>>> Et « We have the full permission to add all of these to OpenStreetMap:
>>> that's the very reason we were contacted. » (from
>>> https://wiki.openstreetmap.org/wiki/Navads_Imports#Source) semble
>>> suffisant ? Quid de telles données une fois qu'elles font partie d'OSM,
>>> avec une telle (absence de) licence (clairement pas identifiée) ?
>>>
>>> --
>>> deuzeffe - qui s'instruit
>>>
>>>
>>>
>>> ___
>>> 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
>



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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[dktue]

Ich habe mich mal daran versucht, könnte vielleicht ein anderer Mapper 
mal gegenprüfen [1], ob ich etwas kaputt gemacht habe?


Grüße
dktue

[1] https://www.openstreetmap.org/relation/2064452

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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao,

2018-03-28 10:26 GMT+02:00 Cascafico Giovanni :

> Il giorno 27 marzo 2018 19:08, Andrea Musuruane  ha
> scritto:
>
>>
>> Ci sono delle incoerenze tra name e brand. Ad esempio ref:mise=22629:
>> brand=Pompe Bianche + name=Shell; ref:mise=10160: brand=Pompe Bianche +
>> name=Agip.
>>
>> Nel file sorgente questi problemi non ci sono. Faccio fatica a capire da
>> dove viene preso il valore del tag name.
>>
>
> Non ho processato il tag name, per cui laddove non trova dati, il criterio
> del conflator preserva i tag; questi distributori suppongo abbiano cambiato
> marca ed operatore. A questo proposito cosa mettiamo nel tag name?
> Duplichiamo il brand, mettiamo l'operator? Lasciamo vuoto?
>

Il tag name lo toglierei. Non mi sembra porti particolare benefici.


> Nel file description viene messo l'indirizzo. Sarebbe meglio riuscire a
>> metterlo in addr:street e addr:housenumber (per quelli che hanno un numero
>> civico, per gli altri l'informazione mi sembra inutile).
>>
>
> Onestamente non saprei come processare la stringa... l'unica certezza di
> questo campo è il codice postale alla fine. La ho assegnata a description,
> pensando che il mappatore occasionale possa eventualemnte aggiungere il
> civico manualmente. Anche il no rari riferimenti kilometrici (p.es. "Ss
> 356 Km 45+5112") potrebbero essere utili per mettere qualche milestone,
> seppure mi pare siano relegate ad ogetti historic.
>

Si può fare in questo modo.

Estrai tre valori dalla stringa in base alla seguente espressione regolare:
(.*),*\s+(\d+\/*\w*),*\s+(\d{5})

Se l'espressione regolare non è soddisfatta si scarta la stringa.

A questo punto, compili i campi addr:street con il primo valore,
addr:housenumber con il secondo (rimuovendo lo slash se questa è seguito
solo da lettere), addr:postcode con il terzo e addr:city con il valore del
campo COMUNE.

Da notare che bisognerà comunque fare qualche passo di QA perché il valore
del campo addr:street difficilmente sarà uguale a quello della strada
inserita in OSM, siccome i dati sorgente non rispettano le regole OSM
(niente abbreviazioni, ecc).

Mi chiedo però se ha senso importare gli indirizzi nelle aree dove è già
stato fatto un import (o dove sarà fatto).


> Sulla ML di import si sta discutendo di un progetto simile (ma che non
>> riguarda l'Italia):
>> https://wiki.openstreetmap.org/wiki/Navads_Imports
>>
>>
> Si, avevo visto il thread, hanno diversi campi utili (phone, opening
> hours, web ecc) e credo sia ta tenere d'occhio come gestiranno il
> "lifecycle".
>

Quello che mi piaceva di quella proposta è il sito dove si vedono i vari
distributori con i tag prima e dopo la conflation e dove si può validare il
risultato del singolo POI.
http://audit.osmz.ru/project/navads_fuel

Ciao,

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

Re: [Talk-de] Navads-Tankstellenimport

[Christoph Hormann]

On Tuesday 27 March 2018, Michael Reichert wrote:
> > POI-Daten sind auch in Deutschland unvollständig und werden
> > unvollständig bleiben. Wir begrüßen Unterstützung bei der
> > Verbesserung des POI-Datenbestands in Deutschland. Trotzdem
> > entspricht die Datenqualität des Imports nicht unseren Erwartungen.
> > Wir selbst haben auch Gegenden ohne aktive Mapper, die sich um ihre
> > Gegend kümmern. Daher werden Fehler, die der Import mit sich
> > bringt, nicht behoben werden. Außerdem ist es nicht die unsere
> > Aufgabe als *Freiwillige* den Datenbestand eines kommerziellen
> > Anbieters zu verbessern.
> >
> > *Dieser Import ist gegen die Interessen der deutschen
> > OSM-Community*. Das Anbieten einer Liste oder der Unterschiede
> > zwischen dem Navads-Datenbestand und OSM ist gern gesehen und hilft
> > uns, unser Werk zu verbessern, ohne die Aufwand des Importmanagers
> > in die Verbesserung der Daten oder der Software zu erhöhen.

Ich halte das für eine zu pauschale Darstellung die nicht wirklich das 
Meinungsbild der Äußerungen hier und im Forum komplett wiedergibt.

Es wurden eine ganze Reihe von Problemen herausgearbeitet, die dem 
Import wie geplant im Wege stehen, aber es gibt auch eine Reihe von 
Dingen, die auf Basis der verfügbaren Informationen machbar und 
zumindest von einem erheblichen Teil derjenigen, die sich geäußert 
haben, vermutlich Unterstützung finden könnten - so zum Beispiel das 
Ergänzen von fehlenden Telefonnummern und Öffnungszeiten bei Objekten, 
wo es eine eindeutige Identität zwischen OSM-Objekt und Navads-Objekt 
gibt.

Ein möglicher Vorschlag wäre zum Beispiel, die Daten in verschiedene 
Gruppen aufzuteilen (Tag-Ergänzungen bei eindeutiger Identität, 
Tag-Ersetzungen, Nicht ganz eindeutige Fälle, eindeutig neue Objekte) 
und nur einen Teil davon automatisch zu ergänzen und den Rest für die 
manuelle Bearbeitung aufzubereiten.

Ob Ilya sich auf sowas einlässt steht auf einem ganz anderen Blatt - 
aber ich halte es für deutlich besser, sich da offen zu zeigen (denn 
das sind ja nützliche Daten - zumindest für den Abgleich und das Finden 
von Lücken) als kategorisch das Ganze abzulehnen.

Und für viel entscheidender als ob dieser Import jetzt am Ende 
stattfindet oder nicht halte ich, dass das Primat der lokalen Community 
in solchen Fällen (länderübergreifende Importe) aufrecht erhalten wird.  
Und das tut man wenn man auf Anpassungen an die jeweilige lokale 
Situation besteht mindestens genauso gut wie wenn man alles einfach 
ablehnt.  Und die Außenwirkung einer pauschalen Ablehnung ist halt 
auch, dass die deutsche Community arrogant ist, meint alles besser zu 
wissen und sich gegenüber Mappern von anderswo abgrenzt.  Ich bin mir 
ziemlich sicher, dass ein solches Bild nicht von einer Mehrheit hier 
gewünscht wird.

Auch denke ich, dass hier nicht die Absicht von Navads/Maps.me vorliegt, 
die Daten von Navads für die eigene Verwendung zu verbessern - man 
möchte wohl in erster Linie die Daten für eine bessere Sichtbarkeit in 
OSM hinein bekommen und dabei möglichst keinen Aufwand haben.  Wie viel 
Arbeit sich die OSM-Community darüber hinaus mit den Daten macht dürfte 
ihnen ziemlich egal sein.

> > Michael Reichert aka Nakaner
> > nach Diskussion und im Namen der deutschen OpenStreetMap-Community
> > im deutschen OSM-Forum und auf der Mailingliste Talk-de

Auch da solltest Du denke ich ein bisschen vorsichtig sein - Du gibst 
hier maximal die Meinung derer wieder, die sich in diesen Kanälen 
geäußert haben.

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

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

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Il giorno 27 marzo 2018 19:08, Andrea Musuruane  ha
scritto:

>
> Ci sono delle incoerenze tra name e brand. Ad esempio ref:mise=22629:
> brand=Pompe Bianche + name=Shell; ref:mise=10160: brand=Pompe Bianche +
> name=Agip.
>
> Nel file sorgente questi problemi non ci sono. Faccio fatica a capire da
> dove viene preso il valore del tag name.
>

Non ho processato il tag name, per cui laddove non trova dati, il criterio
del conflator preserva i tag; questi distributori suppongo abbiano cambiato
marca ed operatore. A questo proposito cosa mettiamo nel tag name?
Duplichiamo il brand, mettiamo l'operator? Lasciamo vuoto?



> Nel file description viene messo l'indirizzo. Sarebbe meglio riuscire a
> metterlo in addr:street e addr:housenumber (per quelli che hanno un numero
> civico, per gli altri l'informazione mi sembra inutile).
>
>
Onestamente non saprei come processare la stringa... l'unica certezza di
questo campo è il codice postale alla fine. La ho assegnata a description,
pensando che il mappatore occasionale possa eventualemnte aggiungere il
civico manualmente. Anche il no rari riferimenti kilometrici (p.es. "Ss 356
Km 45+5112") potrebbero essere utili per mettere qualche milestone, seppure
mi pare siano relegate ad ogetti historic.




> Sulla ML di import si sta discutendo di un progetto simile (ma che non
> riguarda l'Italia):
> https://wiki.openstreetmap.org/wiki/Navads_Imports
>
>
Si, avevo visto il thread, hanno diversi campi utili (phone, opening hours,
web ecc) e credo sia ta tenere d'occhio come gestiranno il "lifecycle".
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Moin,

wenn es auf eine ja/nein Entscheidung (also ohne
Kompromissmöglichkeiten) hinaus läuft, dann hast
 du für den Text meine Rückendeckung.

Ansonsten ist die Darstellung ja schon so ausgefuchst, dass es für den
Importwilligen möglich sein sollte, an die einzelnen Daten eine
Auswahlmöglichkeit für deutsche Mapper hinzuzufügen: ja, bitte
importieren, nein, dieses Datum nicht importieren (weil irgendetwas
nicht stimmt).

Ein Großteil der Daten passt ja vermutlich, so das eine opt in Lösung
für mich ein guter Kompromiss für Deutschland wäre. Wir sind eine so
große Community, dass der Datensatz sicher in kurzer Zeit geprüft und
dann fit für den Import wäre. Falls er von den Mappern nicht geprüft
wird, also keine Freigabe für die einzelnen Daten erfolgt, dann wäre
das eine Abstimmung mit den Füßen, dass man den Import nicht wünscht.

Gruß Falk

Am 27. März 2018 um 23:10 schrieb Michael Reichert :
> Hallo,
>
> Am 26.03.2018 um 23:50 schrieb Michael Reichert:
>> Falls euch solche oder andere Fehler auffallen, so meldet euch bitte
>> hier oder direkt auf der Imports-Mailingliste.
>
> ich bin euch für eure Kommentare und Fehlermeldungen sehr dankbar. Wenn
> ich die Community vertreten würde, würde ich meine Auflistung der
> gefundenen Fehler mit folgenden Worten abschließen:
>
>> (Zusammenfassung eurer Kommentare und Fehlerberichte)
>>
>> German POI data is not complete and will never be complete. We welcome help 
>> to improve the POI data in Germany. However, the quality of the import does 
>> not meet our expectations. We ourselves have also areas which do not have 
>> active mappers who take care for their area. Therefore, errors introduced by 
>> the import in this area will not be fixed. In addition, it is not the task 
>> of us, the *volunteers*, to fix a commercial dataset.
>>
>> *This import is against the interests of the German OSM community* Providing 
>> a list or a diff between the Navads dataset and OSM is welcomed and will 
>> help us to improve our work without increasing the burden for the manager of 
>> the import to invest more work into fixing all the errors of the data and 
>> the software.
>>
>> Best regards
>>
>> Michael Reichert aka Nakaner
>> after discussion and on behalf of the German OpenStreetMap community on the 
>> German OSM Forum and the Talk-de mailing list
>
> Deutsche Übersetzung:
>> (Zusammenfassung eurer Kommentare und Fehlerberichte)
>>
>> POI-Daten sind auch in Deutschland unvollständig und werden unvollständig 
>> bleiben. Wir begrüßen Unterstützung bei der Verbesserung des 
>> POI-Datenbestands in Deutschland. Trotzdem entspricht die Datenqualität des 
>> Imports nicht unseren Erwartungen. Wir selbst haben auch Gegenden ohne 
>> aktive Mapper, die sich um ihre Gegend kümmern. Daher werden Fehler, die der 
>> Import mit sich bringt, nicht behoben werden. Außerdem ist es nicht die 
>> unsere Aufgabe als *Freiwillige* den Datenbestand eines kommerziellen 
>> Anbieters zu verbessern.
>>
>> *Dieser Import ist gegen die Interessen der deutschen OSM-Community*. Das 
>> Anbieten einer Liste oder der Unterschiede zwischen dem Navads-Datenbestand 
>> und OSM ist gern gesehen und hilft uns, unser Werk zu verbessern, ohne die 
>> Aufwand des Importmanagers in die Verbesserung der Daten oder der Software 
>> zu erhöhen.
>>
>> Viele Grüße
>>
>> Michael Reichert aka Nakaner
>> nach Diskussion und im Namen der deutschen OpenStreetMap-Community im 
>> deutschen OSM-Forum und auf der Mailingliste Talk-de
>
> Fühlt sich jemand von diesen Worten nicht ausreichend repräsentiert?
> Vertritt jemand eine abweichende Meinung und möchte diese kundtun?
> Verbesserungsvorschläge für diese Zusammenfassung sind ausdrücklich
> willkommen.
>
> Viele Grüße
>
> Michael
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[wambacher]

Geht doch (für mich) in JOSM ganz einfach:

1: Relation im Relation-Editor öffnen und sortieren

2: fehlende Ways im linken Fenster aktivieren (rot machen)

3: zur Relation hinzufügen (wenn was doppelt ist, motzt Josm und das 
Stück kann man einfach ignorieren)


4: sortieren

5: noch Lücken da? ---> 2

ok, manche Lücken lassen sich aus topologischen Gründen nicht 
schliessen, aber damit muss man halt klar kommen.


Gruss
walter


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

Re: [Talk-it] Tratti brevi e riferimenti

[Alessandro]

Il 28/03/2018 00:50, Martin Koppenhoefer ha scritto:



sent from a phone


On 27. Mar 2018, at 22:36, aldoct  wrote:

cosa succede di sbagliato se si cancellano i riferimenti per tratti



crei un buco nel dato, praticamente se un renderer cerca di fare una cosa più 
evoluta (unisce i pezzi della strada per la visualizzazione del nome / ref), se 
togli questi informazioni in mezzo diventa impossibile



Questo è l'inconveniente più grave. Eliminando una o più proprietà 
all'oggetto potrebbe cambiare sia l'eventuale render sia la possibilità 
di trovare quella parte eseguendo la ricerca. Mettiamo il caso tu tolga 
SP29, quando qualcuno interrogherebbe il database troverebbe un buco.


Alessandro Ale_Zena_IT

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

[Talk-de] Bearbeiten von Riesen-Relation (Bundesstraße 27)

[dktue]

Hallo,

mir ist gerade aufgefallen, dass die Relation der B 27 [1] nicht alle 
Ways enthält, die eigentlich Teil der Straße sind [2] (Abschnitt südlich 
von Tübingen fehlt).


Mir ist nicht klar, wie ich mit derart großen Relationen sinnvoll 
arbeiten kann -- typischweise nehme ich für (Grenz-)Relationen JOSM, 
aber da kann man sich die meistens höchstens ein Dutzend Ways einfach 
zusammenklicken.


Kann mir vielleicht jemand beim Reparieren dieser Relation helfen?

Gruß
dktue

[1] https://www.openstreetmap.org/relation/2064452
[2] http://overpass-turbo.eu/s/xnJ

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

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

You're quite welcome.
Steve

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

Re: [Talk-us] Amtrak network=Amtrak tagging

[Greg Morgan]

Thank you for the detailed response.

Greg

On Mar 25, 2018 11:57 PM, "OSM Volunteer stevea" 
wrote:

I should have included:

https://wiki.openstreetmap.org/wiki/WikiProject_United_States_railways

as that is a better starting place (for your flavor of question) than our
"at the top" Amtrak wiki.

There's a lot to grok to become a good OSM rail editor (and don't forget
updating wiki), yet, many of us are doing exactly that!

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