[OSM-talk-fr] Atelier et conférence Cartographie et données libres - OpenStreetMap - QGIS - opendata - samedi 31 mars à Digne

[Jean-Christophe Becquet]

Bonjour,

Ce samedi 31 mars à Digne, j'animerai un atelier et une conférence sur
le thème Cartographie et données libres. Je propose de travailler sur
les noms des rues de Digne-les-Bains extraits à partir d'OpenStreetMap
pour les catégoriser (par type, par genre...) puis de générer des
représentations graphiques colorées avec le logiciel libre QGIS.

Les données produites au cours de cette journée seront également
partagées sous licence libre.

Cette animation s'inscrit dans le cadre de la journée Libre en fête
organisée par l'association Linux-Alpes de 10h à 17h à la médiathèque de
Digne.

Venez découvrir ou redécouvrir les logiciels libres.

Au programme :

 - Expolibre dès la semaine précédente et pendant toute la journée
 - Accueil du public, démonstration et installation de logiciels libres
de 10h à 16h
 - Atelier cartographie et données de 10h à 15h30
 - Atelier enfant initiation à la programmation de 11h30 à 16h00
 - Conférence sur le logiciel Scratch (programmation), par Arnaud
Champollion, enseignant à 11h00
 - Conférence sur la cartographie et les données, par Jean-Christophe
Becquet à 15h30
 - Table ronde sur les enjeux politiques du logiciel libre à 16h00,
animée par le président de l’April, avec la participation de Delphine
Bagarry, députée de la première circonscription des Alpes de Haute
Provence et Thibaut Le Corre Conseiller municipal de la Ville de
Digne-les-Bains délégué au numérique et à l'innovation

Participation libre et gratuite pour tous, n'hésitez pas à nous rendre
visite.

Expolibre
http://www.expolibre.org

Linux-Alpes
http://www.linux-alpes.org

April
https://www.april.org

L'annonce sur l'Agenda du libre
https://www.agendadulibre.org/events/16595

Propager l'info :
https://twitter.com/Linux_Alpes/status/976718328462041088
https://twitter.com/aprilorg/status/976753080334209024
https://twitter.com/AgendaduLibreFr/status/976433385810866176

https://www.facebook.com/linuxalpes/
https://www.facebook.com/MairieDigne/posts/2196194737087846

Au plaisir de vous retrouver pour cet événement.

Bonne journée

Librement

JCB
-- 
Pourquoi le libre ne concerne pas que les informaticiens
http://www.apitux.org/index.php?2006/07/09/97-pourquoi-le-libre-ne-concerne-pas-que-les-informaticiens

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [Talk-de] Navads-Tankstellenimport

[Ludwig Baumgart]

Hallo,
 in meiner Gegend (westlicher Bodensee Schaffhausen - Singen - 
Stockach) sind die Daten auch an mehreren Stellen fehlerhaft ( zB Ort 
falsch oder bei nebeneinander liegenden Tankstellen nur eine gemappt).


Untenstehendes von Michael ist aus meiner Sicht  +1.

Ludwig

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



___
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-ja] 高速道路の定義について

[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-ja] 高速道路の定義について

[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

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

[osm . sanspourriel]

Je dirais bien la 2.
Philippe, le but des de fabriquer un "récepteur/logger GPS", GNSS en fait, pas un couteau suisse de positionnement.

Un bon capteur (bonne puce, bonne antenne) c'est déjà bien.

Est-ce que le RTK doit être géré in situ ou pas je n'en suis même pas certain.

Pour garder un prix bas, faisons simple et utilisons ce qu'on a : un téléphone et un PC ça a plus de patate et un téléphone c'est plus optimisé côté consommation qu'une production maison.

Si on veut un écran, on transfère les données sur le téléphone : une interface BLE consommera moins qu'un écran (ne pas oublier qu'il faut dire quoi afficher sur l'écran : dates et coordonnées ? Quel format ? Un bouton sauvant le point spationtemporel dans un gpx ou équivalent, pourquoi pas).

 

Par contre tout ce qui est complément style réseau Wifi, c'est un plus qui ne doit pas à mon avis être dans ce projet. Libra à toi d'avoir un projet de fusion de sources.

Et si le code est dans un langage assez standard, le portage sera possible entre téléphones.

 

Stéphane, savoir le nombre de satellites captés et le DOP serait un plus.

On voit des sautes qui semblent dues à des pertes de satellites.

Il semble que la trace 2 aient un décalage vers l'est.

Quand tu dis que le GPX a moins d'infos que le NMEA, OK, mais

 

Jean-Yvon


___
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?

[Fidelis Assis]

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

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

[Ras and Road]

Ras and Roadです。

なぜこの議論が発生したのか。zyxzyxさんはForumに定義案のみ記述されていて、問題と感じていることや背景への言及がありません。
昨夜、muramotoさんがForumへ呼びかけてくださっていますので、反応を待ちましょう。
一方、私自身、Japan Taggingのhighway=motorwayの記述にはひっかかるところがあって、意見しています。

highway=motorwayとは「to identify the highest-performance roads within a
territory」です。
これを日本にあてはめたとき、自動車専用道路とすることは一案です。
ただ、策定した当時、「自動車専用道路」とすることにより、highway=motorwayに含めるべきでない道路も含まれてしまうことの議論がなされたのか、疑問です。
具体的に言えば、比叡山ドライブウェイのような自動車道（道路運送法に定められる道路）は to identify the
highest-performance roads なのか。
これをいま一度検討してみませんか？というのが、私の発言主旨です。

前回の投稿でhighway=motorwayの改定案として「高速道路ナンバリングされた道路」を記述しましたが、いま読み返してみると言葉が足りていません。
あらためて、改定案を提示します。

-- Start of draft
「自動車専用道路。青地に白い車の標識のある道。 高速道路、有料道路、国道のバイパスなどにこの標識があったらこれに分類します。」は全削除のうえ、
高速道路または高速道路を補完する道路で、次に掲げる(1)(2)のいずれかに該当する道路。
(1) 高規格幹線道路
　　国土交通省が公表 [http://www.mlit.go.jp/road/sign/numbering/about/index.html#about02]
するとおり、高規格幹線道路は高速道路ナンバリングされます。
(2) 都市高速道路 または 東京高速道路（いわゆるKK線）
-- End of draft

高速道路ナンバリングをOSM上に表現することが目的ではなく、高規格幹線道路を識別するために有効な手段であると言いたかったのです。
もっとも、例外がありまして、京葉道路・西湘バイパス・小田原厚木道路・長崎バイパス等は単なる国道の有料区間であって高規格幹線道路ではないのですが、高速道路ナンバリングされています。
そんな状況なので、highway=motorwayとして高規格幹線道路を定義するよりも高速道路ナンバリングされた道路を定義するほうが誤解が少ないかも知れません。

検証可能性の件ですが、自動車専用道路とすると私が先に投稿したとおり、その検証可能性は限定的になります。
自動車専用道路の一覧が存在せず、官報や都道府県例規を検索するしかありません。
マッピングの基本はサーベイにあるとは言え、標識の有無に依拠すると検証できる人数が格段に減ってしまいます。
これも、いま一度検討しようと考える一因です。

最後に、日本におけるhighway=motorwayの定義を改訂すると、当然のことながら、既にマッピングされた道路に影響があります。
その混乱を懸念して、現状通りとすることも一案です。あるべき姿に目をつむることになるので個人的には賛成し難いですが、それが多数派であれば従いましょう。現在がそのような状態ですし。

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

[Nelson A. de Oliveira]

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).
Inverter o direction da câmera para gerar um aviso seria incorreto, portanto.

Sem relação de enforcement não dá para representar a direção a que se aplica.

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

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

[Philippe Verdy]

Je suis de ce point de vue là aussi: l'intérêt c'est d'abord l'autonomie
des enregistrements et la possibilité d'améliorer la captation avec une
antenne externe dont sont dépourvus les smartphones. Mais ensuite je ne
vois pas en quoi il faut par principe interdire toute amélioration en
permettant d'utiliser aussi d'autres sources (y compris celles via
internet, ou téléchargés  remise à jour régulièrement, mais pas forcément
en continu, sur le smartphone ui a beaucoup de possibilité de calcul et qui
a aussi la possibilité de prémâcher certaines données pour remettre à jour
aussi les tables de correction du GPS portable externe auquel il se
connectera de temps en temps mais qui peut aussi lui fournir en continu,
s'il en a, d'autres données comme celles de l'accéléromètre, le compas
magnétique et tout ce que les smartphones peuvent aussi détecter, y compris
des données topographiques si un algo correcteur peut en tenir compte).

Pour que cela ait de l'intérêt il faut une valeur ajoutée qu'un smartphone
commercial n'apporte pas: en milieu urbain dense je pense que les
constructeurs trouveront et utiliseront des solutions de corrections pour
les intégrer à leurs appareils. On aura des systèmes de radioguidage sur
les routes les plus fréquentées et des capteurs pas cher que les véhicules
et smartphones pourront aussi utiliser, là où justement le GPS par
satellite donne plutôt des mauvais résultats.

Mais en attendant on va manquer ce capteurs et il faudrait s'intéresser à
remplir le vide, et cela doit pouvoir être utilisable dans une fourchette
de temps de 6 ans environs (le temps de mettre au point un nouvel appareil,
puis qu'il soit sur le marché, que le dispositif s'impose et voit ses prix
baisser et qu'enfin passe la barrière des 3 ans environs où les gens
renouvellent leur appareil, bien que ce temps devrait tendre maintenant à
s'allonger en favorisant les réutilisations au lieu de tout jeter). Le GPS
c'est au minimum 10 à 15 ans d'investissement.

Mais les technos de capteurs alternatifs peuvent s'imposer beaucoup plus
vite, et c'est là qu'on peut avoir une action utile: il s'agit juste de
combler ce qui manque en attendant: l'antenne externe est par exemple ce
qui manque à tous les appareils, de même que la capture de constellations
supplémentaires, ou encore la prise en compte de nouvelles sources de
données de correction (qu'on peut intégrer avec du logiciel libre comme
RTKLIB et des bases de données en ligne).
On ne peut pas tout intégrer au début, mais on doit plutôt s'orienter vers
un kit ouvert "multicapteur" et des interfaces standardisées : RTKLIB et
l'USB sont déjà des solutions d'intégration (il y en a d'autres dont
l'intégration avec les interfaces standard des ordinateurs de bord des
véhicules à moteur), mais on peut étendre ça pour en faire une vraie API
complète portable permettant d'intégrer des capteurs, des moteurs de
calcul, des systèmes de mise à jour en ligne, et même du "GPS assisté" sur
un moteur en ligne libre (pas Google nécessairement!) qui respectera aussi
la vie privée. Après libre à chacun de choisir les éléments à intégrer dans
ce kit logiciel et l'interface de base, et ses fournisseurs.

Dans l'immédiat on ne sera utile que si on remplit des fonctions délaissées
par les smartphones, ou des fonctions encore trop propriétaires (dont
l'assistance Google) pour les ouvrir à d'autres possibilités plus libres.
Les composants à développer seront d'autant plus facilement réutilisables
et faciles à utiliser qu'ils s'appuieront sur une interface simple et
standardisée, sans trop de dépendance entre eux. Ce projet n'est pas que
matériel, il y a des services en ligne à développer, des bases de données à
créer et mettre à jour !



Le 28 mars 2018 à 00:35, Francois Gouget  a écrit :

> 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 

Re: [Talk-es] Importaciones Catastro

[Javier Sánchez Portero]

Joaquim, he cambiado la prioridad del proyecto de baja a media, para que
aparezca listado junto al resto (se ordenan por prioridad). Si no, no será
visible para quien quiera colaborar.

Si alguien quiere contribuir el enlace es:

http://tareas.openstreetmap.es/project/50

Javier

El 26 de marzo de 2018, 0:03, Javier Sánchez Portero 
escribió:

> Hola
>
> El disco duro del servidor se ha roto. Alejandro ha conseguido rescatar
> los datos y va a intentar poner el servidor en marcha de nuevo en cuanto
> tenga la posibilidad de hacerlo.
>
> Mientras no funcione, podemos seguir trabajando en las importaciones
> usando los archivos de tareas directamente. Si hay varias personas
> trabajando en el proyecto tendrán que ponerse de acuerdo para no pisarse.
> Cuando el servidor esté en marcha de nuevo hay que marcar las tareas como
> realizadas.
>
> Saludos
>
> El 25 de marzo de 2018, 18:52, Joaquim  escribió:
>
>> Hola Javier
>>
>> Desde hace unos días no consigo entrar en tareas.openstreetmap.es, no se
>> si es un fallo del servidor o de mi sistema. ¿Es un problema si sigo
>> trabajando en las importaciones usando las copias de los ficheros de tareas
>> generadas en mi ordenador y que en su momento subí a GitHub?
>>
>> Un Saludo
>>
>> Joaquim Puxan
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

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

[Fidelis Assis]

Pessoal,

Gostaria de ajuda na interpretação da etiqueta direction para pontos de
alerta. No exemplo abaixo temos duas paradas obrigatórias e dois sensores
de velocidade:

https://www.openstreetmap.org/edit#map=20/-23.49394/-46.59179

No caso das paradas obrigatórias, as direções estão indicadas uma por
forward e outra por backward, representando para cada uma o alinhamento do
sentido de deslocamento fiscalizado com o do traçado da via no OSM.

O campo visual (viewfield) de cada uma mostrado pelo iD indica o lado
fiscalizado. Para facilitar o entendimento, interpreto o desenho do campo
visual como um "olho" vigiando quem se aproxima por este lado.

Já no caso dos dois sensores de velocidade as direções estão indicadas por
valores numéricos (graus) que representam o azimute do "olhar" dos mesmos
independentemente do sentido do traçado da via, conforme interpreto o texto
de ajuda do iD referente a direction (se esta interpretação estiver errada,
por favor me corrijam).

O problema é que o "olho" neste caso está voltado para o lado oposto ao
fiscalizado por cada um, inconsistente com o caso das paradas obrigatórias.
Como os dois sensores de velocidade são opostos e próximos, esse problema
de direções invertidas não prejudica os alertas gerados na prática pois um
faz o papel do outro.

Já no exemplo abaixo, com apenas um sensor de velocidade, a interpretação
faz diferença e pode gerar um alerta no sentido invertido:

https://www.openstreetmap.org/edit#map=20/-23.53710/-46.59314



Como manter a consistência e gerar alertas com direções corretas?
Invertendo os ângulos dos sensores de velocidade (e de outros alertas) no
OSM para que indiquem um "olhar" [1] para o lado fiscalizado, e não o
sentido do deslocamento, ou usar forward/backward [2] com a mesma
interpretação usada nas paradas obrigatórias?



[1]  Esse "olhar" não tem relação com a direção para a qual a câmera está
voltada, pois esta pode fiscalizar um mesmo sentido voltada para um ou
outro lado, ou seja, fotografando a placa dianteira ou a traseira. Esse
"olhar" indicaria o lado fiscalizado por um guarda ali colocado em
substituição ao sensor, ou seja, para onde ele olha.

[2] Usar forward/backward tem a vantagem de ficar imune a alterações no
traçado que implicariam em atualização também do valor da direction em
graus. Mesmo em caso de inversão do traçado o ID e o JOSM ajustam
automaticamente.

Uma observação adicional: nas vias de mão única a direction é dispensável.
Acho até melhor não usar pois evita essas dúvidas. O mesmo acontece nas
vias de mão dupla em que o alerta atua nos dois sentidos.

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

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

[Stéphane Péneau]

Le 28/03/2018 à 00:10, Francois Gouget a écrit :

J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les
autres. Mais peut-être ai-je raté les points importants ?
Normalement, si tu décoches au fur et à mesure les traces qui te semble 
les moins bonnes pour qu'elles ne perturbent plus l'affichage, tu 
devrais trouver assez facilement celle qui vient de l'antenne sur le toit.
J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça aide, 
mais umap semble limité sur ce point.


Je donnerai la réponse dans quelques jours.

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

Re: [Talk-it] Tratti brevi e riferimenti

[Martin Koppenhoefer]

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

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

Re: [Talk-it] Tratti brevi e riferimenti

[Andrea Albani]

Il mar 27 mar 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?
>

Succede che non rappresenti la realtà dei fatti.
Se un'ipotetica via Manzoni ad un certo punto passa su di un ponte
continuerà, nel caso più semplice,  a chiamarsi sempre allo stesso modo.

Se gli togliamo il nome o un ref creaiamo una realtà fittizia che asseconda
solo la nostra personale idea di rappresentazione grafica con un dato
schema di rendering.
___
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 27. Mar 2018, at 20:20, Daniele Forsi  wrote:
> 
> molti molti anni, i distributori fa vennero importati da prezzibenzina.it


questo prima del 2008, mi ricordo che i benzinai di prezzi benzina erano i 
primi dati in una mappa vuota in quei tempi.

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

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

[Francois Gouget]

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] Et si on fabriquait notre récepteur/logger GPS ?

[Francois Gouget]

On Tue, 27 Mar 2018, Stéphane Péneau wrote:

> Je viens de faire un test :
> 5 récepteurs Gps+Glonass :
> - Smartphone Sony Xperia Ray
> - Smartphone HTC One mini
> - Tablette Nexus 9
> - Tablette Nvidia Tablet Shield K1
> - Navspark GL.
> 
> Le Navspark a son antenne sur le toit.
> 
> Le résultat est visible ici :
> http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577

Que peut-on en conclure ?

Je ne suis pas expert du coup tout ce que je voit c'est que la trace 
bleue et la rouge me semblent pire que les autres (voir le parking un 
peu avant la boucle et sorties de route dans la grande ligne droite 
avant).

Les autres sont similaires ce qui semble indiquer qu'avoir une antenne 
sur le toit n'apporte pas grand chose.

La trace orange a perdu le signal pendant un bon moment et en ville, 
dans le coin nord-ouest, elle fait quelques écarts significatifs. Pas 
terrible non plus.

Pas en reste les traces jaune et vertes font elles aussi 
régulièrement des écarts en ville, peut-être un peu moins prononcés que 
la trace orange. Mais dans tous les cas ça ne fait pas terrible sur 
une trace Mapillary par exemple.


J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les 
autres. Mais peut-être ai-je raté les points importants ?


-- 
Francois Gouget   http://fgouget.free.fr/
   RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt
IP over Avian Carriers with Quality of Service___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-de] Navads-Tankstellenimport

[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)





signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[Philippe Verdy]

une remarque: sur ta carte UMap, les libellés 1, 2, 3, 4, 5 ne sont pas
assez explicites, il faudrait que tu décrives réellement à quoi ils
correspondent : quel récepteur, smartphone or GPS externe, avec ou sans
antenne, avec ou sans activation de la correction assistée sur les
smartphones (qui peuvent utiliser d'autres capteurs comme le compas
magnétique, un capteur inertiel, accéléromètre, ou la captation d'autres
réseaux locaux en zone urbaine ; si le récepteur GPS est intégré à un
véhicule, il peut aussi utiliser des données venant du véhicule lui-même
dont le compteur de vitesse, les capteurs de pression de la suspension, les
systèmes embarqués utiliseront bientôt aussi les caméras, la signalisation
lumineuse ou de radioguidage, les guides magnétiques sur la chaussée et le
marquage au sol qui vont évoluer pour la conduite de plus en plus
automatique...)

Le GPS satellitaire n'est donc qu'une des sources possibles et je suis
persuadé qu'à l'avenir on pourra même s'en passer totalement, et que les
actuelles constellations ne seront plus dédiées à ça mais pourront utiliser
n'importe quel autre satellite capable d'émettre un signal, même ceux sur
des orbites pus hautes géostationnaires et les héliosynchrones (pas
observables partout directement). Les capteurs multifréquences seront
légion et aussi courant et peu chers que le sont aujourd'hui les modems DSL
qui ont remplacé les vieux modems monofréquence, et qui pourront utiliser
un spectre très étendu de bandes de fréquences avec une intégration
directement dans le silicium des transformées de Fourier et la possibilité
même de recevoir un même signal modulé sur plusieurs satellites,
indépendamment de la fréquence utilisée sur chacun, et de se prémunir ainsi
de pas mal d'effet gênants sur une bande de fréquence unique trop étroite
traversant une atmosphère trop changeante (et changeant de plus en plus, à
mesure qu'on capte plus en plus bas vers l'horizon, avec des chemins
multiples de plus en plus nombreux dont on ne peut finalement exclure aucun
mais dont on doit pouvoir tenir compte parmi les autres et pas juste
éliminer de façon élective, le premier signal reçu n'était pas non plus
nécessairement le plus stable).

Je crois qu'on se focalise trop sur le "pur" GPS et qu'en voulant éliminer
le "GPS assisté" on passe à côté du sujet et des sources pourtant fiables
de correction. Toutes ces sources sont intéressantes: plus on demande de
précision plus on a besoin de multliplier les sources et non d'en éliminer,
il faut savoir mieux les utiliser conjointement car on n'aura jamais aucune
source isolée "parfaite" utilisable toute seule.


Le 27 mars 2018 à 21:35, Stéphane Péneau  a
écrit :

> Je viens de faire un test :
> 5 récepteurs Gps+Glonass :
> - Smartphone Sony Xperia Ray
> - Smartphone HTC One mini
> - Tablette Nexus 9
> - Tablette Nvidia Tablet Shield K1
> - Navspark GL.
>
> Le Navspark a son antenne sur le toit.
>
> Le résultat est visible ici : http://umap.openstreetmap.fr/
> fr/map/comparaison-recepteurs-gnss_208577
> Ce n'est pas la position absolue qui est le point le plus important, mais
> la façon dont la géoloc bouge en cas d'obstacle (forêt, immeubles).
> http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577
>
> Quelques photos ici :
> https://twitter.com/stfmani/status/978706991983087616
>
> Vous remarquerez qu'il y a 2 antennes sur le toit de la voiture. Je
> voulais calculer une trace en RTK, mais je me suis raté sur la ligne de
> commande pour enregistrer les données RAW. J'étais resté en configuration
> "base" qui envoie les données à un caster NTRIP.
>
> Stéphane
>
>
>
> Le 27/03/2018 à 08:46, David Marchal a écrit :
>
> 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. Ça pourrait viser, par exemple, les
> réfractaires à ces menottes technologiques, ceux qui n’en ont pas les
> moyens ou ceux qui veulent profiter de la nature sans surveiller sans arrêt
> leur smartphone – comme vous l’aurez sans doute compris, je parle en
> connaissance de cause. 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.
>
>
> Cordialement.
>
> --
> *De :* Francois Gouget  
> *Envoyé :* vendredi 23 mars 2018 11:25
> *À :* verd...@wanadoo.fr; Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger
> GPS ?
>
> On Thu, 22 Mar 2018, Philippe Verdy wrote:
>
> > < 1 m en montagne c'est difficile  pour une simple raison: le manque de
> > visibilité d'une part et les réflexions/chemin multiples sur les parois,
> et
> > souvent aussi la végétation en zone forestière. Particulièrement sans
> > correction si c'est l'objectif et encore plus en monofréquence.
> [...]
> > L'absence de ces corrections 

[Talk-es] [Catastro] Fallo tareas.openstreetmap.org

[Javier Sánchez Portero]

-- Mensaje reenviado --
De: Alejandro S. 
Fecha: 27 de marzo de 2018, 21:02
Asunto: Re: Fallo tareas.openstreetmap.org
Para: Javier Sánchez Portero 


Ya vuelve a funcionar tareas.openstreetmap.es, a la vuelta de Semana Santa
seguramente cambiaremos el hardware la máquina por una más potente y estará
caído un rato el servicio, pero no debería fallar.

Saludos,
Alejandro Suárez



Hola

Por favor, marcar en el gestor como realizadas las tareas subidas mientras
estuvo el servidor caído.

Saludos,
Javier.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Tratti brevi e riferimenti

[aldoct]

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?
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

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

[Stéphane Péneau]

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

Re: [Talk-cz] Nadrzovy dvur

[jzvc]

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.





(viděl jsem to někde v chemičce, ne v přírodě)


BTW - když už jsme u těch zábran proti vodě - máme nějaký speciální tag 
na protipovodňové zátarasy?



(Obzvláště myslím na ty části, kde je jen pás v chodníku, kam se zátaras 
umístí až před povodní).



Muzes tam dat ze tam stoji zed a nastavit ze v sezone ;D, ale nedelal 
bych si iluze ze to pripadny navigace pochopej jinak, nez se se tam 
proste neda projit.





--

Severák





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




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

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

[Stéphane Péneau]

Je viens de faire un test :
5 récepteurs Gps+Glonass :
- Smartphone Sony Xperia Ray
- Smartphone HTC One mini
- Tablette Nexus 9
- Tablette Nvidia Tablet Shield K1
- Navspark GL.

Le Navspark a son antenne sur le toit.

Le résultat est visible ici : 
http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577
Ce n'est pas la position absolue qui est le point le plus important, 
mais la façon dont la géoloc bouge en cas d'obstacle (forêt, immeubles).

http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577

Quelques photos ici :
https://twitter.com/stfmani/status/978706991983087616

Vous remarquerez qu'il y a 2 antennes sur le toit de la voiture. Je 
voulais calculer une trace en RTK, mais je me suis raté sur la ligne de 
commande pour enregistrer les données RAW. J'étais resté en 
configuration "base" qui envoie les données à un caster NTRIP.


Stéphane


Le 27/03/2018 à 08:46, David Marchal a écrit :


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. Ça pourrait viser, par 
exemple, les réfractaires à ces menottes technologiques, ceux qui n’en 
ont pas les moyens ou ceux qui veulent profiter de la nature sans 
surveiller sans arrêt leur smartphone – comme vous l’aurez sans doute 
compris, je parle en connaissance de cause. 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.



Cordialement.



*De :* Francois Gouget 
*Envoyé :* vendredi 23 mars 2018 11:25
*À :* verd...@wanadoo.fr; Discussions sur OSM en français
*Objet :* Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger 
GPS ?

On Thu, 22 Mar 2018, Philippe Verdy wrote:

> < 1 m en montagne c'est difficile  pour une simple raison: le manque de
> visibilité d'une part et les réflexions/chemin multiples sur les 
parois, et

> souvent aussi la végétation en zone forestière. Particulièrement sans
> correction si c'est l'objectif et encore plus en monofréquence.
[...]
> L'absence de ces corrections basées sur d'autres observations et mesures
> prises par d'autres satellites ou stations d'observation au sol fait 
qu'on

> ne peut espérer mieux qu'une précision de 30 mètres en montagne. On peut
> toujours rêver mais il faut comprendre un peut comment et sur quelles
> mesures se basent les systèmes GNSS.

Du coup quel serait l'intérêt d'un tel GPS par rapport à un smartphone ?

Il ne reste guère que l'autonomie et le plaisir d'avoir du matériel
libre mais est-ce vraiment suffisant ou cela ne le condamne-t-il pas à
être diffusé à une douzaine d'exemplaires seulement ?

La précision c'est vraiment le principal reproche que je ferait au GPS
de mon smartphone. Paradoxalement en voiture elle est suffisante pour du
Mapillary mais dès que je me promène en ville à pied il divague beaucoup
(je soupçonne qu'il utilise la vitesse pour restreindre le champ des
possibles de la prochaine position). Étant donné les problèmes de
réflexion et de masquage des satellites je ne vois guère de solution
hors passer justement à un système travaillant à partir de la L5.

La fréquence de mise à jour de la position est potentiellement un
deuxième problème mais il est tout aussi probable que ce soit juste un
bug de Mapillary.

Donc, pour moi, un GPS séparé pourrait éventuellement être intéressant
mais uniquement s'il offre une meilleure précision. Or il y a à présent
assez de satellites qui émettent un signal L5 et on nous promet de
nouveaux smartphones avec des puces GPS qui l'utilisent pour 2018. Du
coup j'attendrai peut-être simplement de changer de smartphone.

https://spectrum.ieee.org/tech-talk/semiconductors/design/superaccurate-gps-chips-coming-to-smartphones-in-2018 




Superaccurate GPS Chips Coming to Smartphones in 2018 ... 


spectrum.ieee.org
Broadcom has released the first mass-market GPS chips that use newer 
satellite signals to boost accuracy to 30-centimeters






--
Francois Gouget  http://fgouget.free.fr/ 


   A man can fail many times, but he isn't a failure
    until he begins to blame somebody else.
   -- John Burroughs


___
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-it] dataset MISE distributori

[Daniele Forsi]

Il 27 marzo 2018 19:23, Damjan Gerl ha scritto:

> Ma ricordo male io oppure questi dati sono stati già importati qualche anno
> fa?

molti molti anni, i distributori fa vennero importati da prezzibenzina.it

-- 
Daniele Forsi

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

Re: [Talk-it] Nomi delle strade e numeri civici

[Lorenzo Mastrogiacomi]

Il giorno mar, 27/03/2018 alle 10.05 +0200, Martin Koppenhoefer ha
scritto:
> 
> 
> perché non mettiamo
> place=dispersed_settlement
> e lo documentiamo nel wiki, così lo possono utilizzare anche gli altri?
> Raggiunto un certo numero chiediamo al rendering di visualizzare il nome e da 
> quel punto sarà utilizzato anche da chi mappa soprattutto per il rendering ;-)
> 
> Se non prendiamo una decisione saremmo condannati ad aspettare gli altri, e 
> probabilmente ci ritroveremmo fra qualche tempo di nuovo davanti allo stesso 
> problema...
> 
> 
> Ciao, Martin 
> ___


Vada per dispersed_settlement.

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

Re: [Talk-it] dataset MISE distributori

[Damjan Gerl]

Ma ricordo male io oppure questi dati sono stati già importati qualche 
anno fa?


Damjan


27.03.2018 - 14:38 - Cascafico Giovanni:
La precisione delle coordinate, la frequenza di aggiornamento, nonchè 
la licenza rendono il dataset MISE [1] degno di essere integrato in 
OSM. Ho prodotto un osm di test per il Friuli Venezia Giulia [2] 
tramite conflator [3], impostando un raggio di 80 metri.
Dovrebbe essere pronto per il caricamento, in quanto è gestita la 
versione dei nodi. Manca il controllo della comunità la pagina per 
l'import e, suppondo uno username ad-hoc.




[1] 
http://www.sviluppoeconomico.gov.it/images/exportCSV/anagrafica_impianti_attivi.csv

[2] https://drive.google.com/open?id=1HvileMB3TUGqwnLZeeEM723Q23zAX6SW
[3] https://wiki.openstreetmap.org/wiki/OSM_Conflator




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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao Giovanni,
ho guardato il file OSM.

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.

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).

Sulla ML di import si sta discutendo di un progetto simile (ma che non
riguarda l'Italia):
https://wiki.openstreetmap.org/wiki/Navads_Imports

Ciao,

Andrea



2018-03-27 14:38 GMT+02:00 Cascafico Giovanni :

> La precisione delle coordinate, la frequenza di aggiornamento, nonchè la
> licenza rendono il dataset MISE [1] degno di essere integrato in OSM. Ho
> prodotto un osm di test per il Friuli Venezia Giulia [2] tramite conflator
> [3], impostando un raggio di 80 metri.
> Dovrebbe essere pronto per il caricamento, in quanto è gestita la versione
> dei nodi. Manca il controllo della comunità la pagina per l'import e,
> suppondo uno username ad-hoc.
>
>
>
> [1] http://www.sviluppoeconomico.gov.it/images/exportCSV/anagrafica_
> impianti_attivi.csv
> [2] https://drive.google.com/open?id=1HvileMB3TUGqwnLZeeEM723Q23zAX6SW
> [3] https://wiki.openstreetmap.org/wiki/OSM_Conflator
>
>
>
> ___
> 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] Segnaletica "I" con annessa botola.

[liste DOT girarsi AT posteo DOT eu]

Il 27/03/2018 11:52, denis_dand...@inwind.it ha scritto:


Se mi giri le coordinate glielo faccio controllare.



Le coordinate non le ho, comunque è di facile da vedere e trovare, è a 
lato strada, a salire si trova a sinistra, si trova lungo la strada 
forestale Acqua Schiava, pressappoco qui:


http://osm.org/go/0IFKDvdvE-?m=



Prima della vecchia calchera ad ogni modo.


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] Mapping party Padova 7 aprile 2018

[Alessandro Palmas]

Il 27/03/2018 13:35, Matteo Zaffonato ha scritto:


Si pensava anche di affiancare una sessione di mappatura con Mapillary 
per offrire un'alternativa di scelta.


Ciao
Matteo Zaffo80 


Essendo un sister project ormai diamo per scontato che ci possa essere 
anche chi si occupa di Mapillary.
Per i non esperti c'è sempre la carta StreetView o Wheelmap: in questo 
modo contribuirebbero pure loro e nel frattempo girando assieme 
potrebbero vedere come funziona un mapping party e come e quali app 
utilizziamo. Nessuno quindi può avere scuse per non partecipare :-)


Alessandro Ale_Zena_IT


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

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 14:38, Max1234Ita  wrote:
> 
> se invece sono proprio poche, ed isolate, mi atterrei alle raccomandazioni
> della Wiki ed andrei sicuramente con place=isolated_dwelling.



se “poche” è una o massimo due,si, ma non sono case sparse in questo caso. 
Invece se il toponimo è uno, mettere una serie di isolated_dwellings sarebbe 
sbagliato 


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

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

[Begin Daniel]

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 
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 name tag, such as: street names, 
other routes names or Trans-Canada highway name in different forms;
  *   The issue above is repeating for the ref tag;
  *   The name of Trans-Canada highway has more than one form (Trans-Canada 
Highway, TransCanada Highway, Trans Canada Highway, etc);
  *   Another issue is the variety of names in other tags related to it (such 
as: name:en, name:fr, alt_name, alt_name:en, alt_name:fr, nat_name);
  *   There are some routes that don’t have a route name only ref (5 routes);
  *   There are some routes that overlap:
 *   in Manitoba: - PTH 1 (MB Trans-Canada Highway) and Trans-Canada 
Highway (Super);
 - Yellowhead Highway and 
PTH 16 (MB Trans-Canada Highway);

 *   in Alberta: Trans-Canada Highway (AB) and Trans-Canada Highway (Super);
 *   in British Columbia: - 

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 14:38, Max1234Ita  wrote:
> 
> Io vedrei bene anche place=neighbourhood


no, perché neighbourhood è per i neighbourhoods, che sono parti piccoli di una 
città 


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

Re: [Talk-it] Nomi delle strade e numeri civici

[Max1234Ita]

Leggendo la Wiki ho trovato questo:
https://wiki.openstreetmap.org/wiki/Tag:place=neighbourhood

Io vedrei bene anche place=neighbourhood se il toponimo "copre" un'area
piuttosto vasta ma non si riesce ad identificare un vero e proprio "centro";
se invece sono proprio poche, ed isolate, mi atterrei alle raccomandazioni
della Wiki ed andrei sicuramente con place=isolated_dwelling.

Max



--
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: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

La precisione delle coordinate, la frequenza di aggiornamento, nonchè la
licenza rendono il dataset MISE [1] degno di essere integrato in OSM. Ho
prodotto un osm di test per il Friuli Venezia Giulia [2] tramite conflator
[3], impostando un raggio di 80 metri.
Dovrebbe essere pronto per il caricamento, in quanto è gestita la versione
dei nodi. Manca il controllo della comunità la pagina per l'import e,
suppondo uno username ad-hoc.



[1]
http://www.sviluppoeconomico.gov.it/images/exportCSV/anagrafica_impianti_attivi.csv
[2] https://drive.google.com/open?id=1HvileMB3TUGqwnLZeeEM723Q23zAX6SW
[3] https://wiki.openstreetmap.org/wiki/OSM_Conflator
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Segnaletica "I" con annessa botola.

[Andreas Lattmann]

Accidenti, ma ci sono ancora in giro quei cartelli?? I sta per idrante, ma son 
cartelli che avevo anch'io negli anni '80. A vedere così è un idrante 
sottosuolo.


Il March 26, 2018 7:36:34 PM UTC, liste DOT girarsi AT posteo DOT eu 
 ha scritto:
>Questa si trova a lato di una strada forestale poco sopra un paese, non
>
>ne ho viste altre in giro, anche da altre parti, pensate si tratta di 
>condotta acqua?
>
>ne sapete qualcosa?
>
>https://imgur.com/CCeFday
>
>
>
>-- 
>_|_|_|_|_|_|_|_|_|_
>|_|_|_|_|_|_|_|_|_|_|
>Simone Girardelli
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] Mapping party Padova 7 aprile 2018

[Matteo Zaffonato]

Si pensava anche di affiancare una sessione di mappatura con Mapillary 
per offrire un'alternativa di scelta.


Ciao
Matteo Zaffo80

Il 27/03/2018 12:59, Alessandro Palmas ha scritto:

Buongiorno lista,
in occasione dell'assemblea di Wikimedia Italia, sabato 7 aprile dalle 
9,30 alle 13 si terrà un Mapping Party itinerante con OpenStreetMap, 
con ritrovo e conclusione presso il Dipartimento di Scienze Storiche, 
Palazzo Luzzato Dina (1), aula al piano terra (all'ingresso sulla 
sinistra).


Oltre ai vari oggetti da mappare vorremmo porre l'attenzione sulla 
mappatura dell'accessibilità, mappando locali, strutture, marciapiedi, 
attraversameni pedonali, ecc..


A breve verrà creata la pagina wiki i inserito l'appuntamento nel 
diario degli eventi https://wiki.openstreetmap.org/wiki/Current_events



Approfitto per segnalare che la sera prima gli amici di 
Mastergiscience in occasione della notte europea della geografia 
organizzano un mapathon serale/notturno e alcuni eventi collegati, 
info a 
http://www.mastergiscience.it/it_IT/2018/03/19/notte-europea-della-geografia-padova/


Alessandro Ale_Zena_IT



1) https://www.openstreetmap.org/way/131966271

___
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-bf] Mapathon Mensuel/31Mars 2018

[Nathalie SIDIBE]

Bonjour chers Mappeurs,


La Communauté OpenStreetMap Mali, dans son Calendrier 2018, prévoit
d'organiser un Mapathon à chaque dernier samedi du mois à partir de ce mois
de Mars.

Nous vous invitons donc à participer à celui qu'on organise ce samedi 31
Mars à JokkolabsBamako à partir de 14heures sur la tache
https://tasks.hotosm.org/project/1075 ville de Bamako.
 Nous comptons beaucoup sur votre participation à fin de pouvoir compléter
la-dite dans les meilleurs délais.


A retenir
Activité : Mapathon
Lieu : JokkolabsBamako
Jour : 31 Mars 2018
Heures : 14h-20h
Durée : 6heures

Excellente semaine et merci d'avance pour vos contributions !

Nathalie





Garanti
sans virus. www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-bf mailing list
Talk-bf@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bf

Re: [Talk-it] Segnaletica attacco autopompa VVF, idrante forse, che tipo è?

[Dario Zontini]

Non sono un vigile del fuoco ma mi hanno spiegato che c'è un attacco
autopompa per caricare con un idrante una autobotte (come indicato nel
cartello) e un "attacco autopompa di mandata" che serve per mandare acqua
in un edificio e la forma è diversa

Il mar 27 mar 2018, 10:32 Martin Koppenhoefer  ha
scritto:

>
>
> 2018-03-26 21:12 GMT+02:00 liste DOT girarsi AT posteo DOT eu <
> liste.gira...@posteo.eu>:
>
>> Il 26/03/2018 21:05, paolo bubici ha scritto:
>>
>>> Ecco come mapparli:
>>>
>>> emegency=dry_riser_inlet
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Dry_riser_inlet
>>>
>>> https://wiki.openstreetmap.org/wiki/Albisola#Attacchi_di_mandata
>>>
>>> Bubix
>>>
>>>
>>>
>>>
>> Mi pare strano che in case civili ci sia questo tipo di condotta.
>>
>> Capirei in uno stabilimento tipo fabbrica, ma quei parliamo di case
>> abitate, in mezzo ai paesi.
>>
>
>
> non dobbiamo progettare il sistema antiincendio, dobbiamo soltanto
> rilevare quello che c'è. A me dalla descrizione che hai dato mi sembra
> pertinente il tag.
>
> 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] Mapping party Padova 7 aprile 2018

[Alessandro Palmas]

Buongiorno lista,
in occasione dell'assemblea di Wikimedia Italia, sabato 7 aprile dalle 
9,30 alle 13 si terrà un Mapping Party itinerante con OpenStreetMap, con 
ritrovo e conclusione presso il Dipartimento di Scienze Storiche, 
Palazzo Luzzato Dina (1), aula al piano terra (all'ingresso sulla sinistra).


Oltre ai vari oggetti da mappare vorremmo porre l'attenzione sulla 
mappatura dell'accessibilità, mappando locali, strutture, marciapiedi, 
attraversameni pedonali, ecc..


A breve verrà creata la pagina wiki i inserito l'appuntamento nel diario 
degli eventi https://wiki.openstreetmap.org/wiki/Current_events



Approfitto per segnalare che la sera prima gli amici di Mastergiscience 
in occasione della notte europea della geografia organizzano un mapathon 
serale/notturno e alcuni eventi collegati, info a 
http://www.mastergiscience.it/it_IT/2018/03/19/notte-europea-della-geografia-padova/


Alessandro Ale_Zena_IT



1) https://www.openstreetmap.org/way/131966271

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

Re: [Talk-GB] Edits in Wales

[Chris Jones]

On 26 Mar 2018, at 13:04, Gregory  wrote:
> 
> The OpenStreetMap rule for all time has been "what's on the ground is what we 
> use", in the case of names that would be what's on the road signs.
> 
> I was in Wales last week and saw a mix of road names (I didn't focus on place 
> names, but it should still stand):
> 1) Welsh on top line, English below.
> 2) English on top line, Welsh below.
> 3) Welsh only.
> It seemed consistent for areas, maybe relating to how old the streets were or 
> politics - I think this is interesting enough.
> 
> I would tag it the streets always with 2-3 name tags...
> A) name:cy and name:en used whenever they are present on a sign. Do not 
> transliterate. When we have a complete map, this then provides insight into 
> the areas (where and % of roads) actually have Bilingual names.
> B) You should additionally add a "name" value. My preference is for the name 
> on the top line. I can see the argument for putting both/all names in, but I 
> think this gets messy as OpenStreetMap doesn't have the concept of a 
> separator.

Using the top line for name is a good idea historically, however the new(ish) 
Welsh Language Standards legislation is likely to mean that new signage 
throughout Wales have Welsh on top regardless of local usage.

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

Re: [Talk-in] India Coastline Improvement

[Chetan H A]

Hi Paramvir Singh,

Yes, with the help of Apple.

Best,
Chetan

On Tue, Mar 27, 2018 at 11:20 AM, Paramvir Singh 
wrote:

> With the help of Apple?
>
> On Tue, Mar 27, 2018 at 11:05 AM, Chetan H A  wrote:
>
>> Hi all,
>>
>> Wanted to let you know that I plan on improving the coastline data
>> throughout India. With the help of Apple, I have posted a Github page (
>> https://github.com/osmlab/appledata/issues/71) with more details on the
>> project and the procedures I will be following. Let me know if you have any
>> feedback.
>>
>>
>> Thank you,
>>
>> Chetan
>>
>>
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
>>
>
>
> --
> TheUntourists.com
> DesiCreative.com
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Segnaletica "I" con annessa botola.

[denis_dandrea]

Per gli idranti fuori paese da noi purtroppo i vari comuni si sono inventati 
molti fuori standard.

Questo in particolare penso sia un idrante sottosuolo ma messo in una bottola 
non standard ed hanno usato una vecchia tabella ora non più a norma per 
indicarlo altrimenti sarebbe introvabile.

La prossima settimana iniziamo una campagna di raccolta dati degli idranti con 
i Corpi volontari della zona e vorrei spingere perchè i dati siano inseriti 
anche in OSM (tramite inserimento manuale con Osmhydrant).

Se mi giri le coordinate glielo faccio controllare.

PS. Qualcuno sa qualcosa della parte 3 della proposta modifica dei tag [1]? Già 
che facciamo il lavoro sarebbe bene inserire la chiave da usare per manovrarlo.

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_3)

> 
> Message: 4
> Date: Mon, 26 Mar 2018 21:36:34 +0200
> From: liste DOT girarsi AT posteo DOT eu 
> To: openstreetmap list - italiano 
> Subject: [Talk-it] Segnaletica "I" con annessa botola.
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Questa si trova a lato di una strada forestale poco sopra un paese, non
> ne ho viste altre in giro, anche da altre parti, pensate si tratta di
> condotta acqua?
> 
> ne sapete qualcosa?
> 
> https://imgur.com/CCeFday
> 
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
> 
> 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

2018-03-27 11:17 GMT+02:00 Andrea Musuruane :

> Perdonami, lo trovo perfettamente pertinente e frutto di una discussione
> in lista proprio sugli indirizzi portata a suo tempo da mbranco2.
>


di non mappare una cosa "importante" perché ci "manca" il tag non è una
opinione che potrei condividere, e non riccordo che avessimo concordato
questo nelle precedenti discussioni.
Io le vedo come Lorenzo (sopratutto la parte "me lo invento"), e vorrei che
il wiki trasportasse questo spirito, che credevo fosse condiviso anche in
Italia.


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

Re: [Talk-it] Campeggio privato

[Martin Koppenhoefer]

2018-03-27 11:14 GMT+02:00 Volker Schmidt :

> Controllando la presenza di campeggi ho incontrato questo posto [1] nelle
> mie vicinanze che è taggato tourism=camp_site. Come conseguenza appare
> anche su http://unterkunftskarte.de.
> In realtà si tratta di una associazione che lo utilizza come villaggio
> turistico privato permanente. Non accetta esterni.
>
> Si, il posto ha l'aspetto di un campeggio, cioè landuse=camp_site con
> access=private sarebbe corretto, tourism=camp_site non lo è perché loro non
> prevedono nessun servizio o simile per turisti.
>


be, al meno non si consideranno loro turisti. E' possibile iscriversi
all'associazione? In generale sono daccordo che "tourism" nel caso che la
struttura fosse del tutto chiuso, non sarebbe adatto. Per me va bene il tuo
access=private, landuse=camp_site (se permanente).

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

Re: [Talk-it] Nomi delle strade e numeri civici

[Andrea Musuruane]

Ciao,

2018-03-27 11:05 GMT+02:00 Lorenzo Mastrogiacomi :

>
>
> Il 27 marzo 2018 09:39:52 CEST, Andrea Musuruane  ha
> scritto:
>
> >
> >Per togliere quella frase, bisogna trovare un valore di place adatto
> >alle
> >case sparse.
>
> Ma questo è un problema che non ha niente a che fare con la nomenclatura o
> i civici, al massimo andrebbe nella pagina sui place.
>
> Inoltre è la prima volta che vedo su un wiki la richiesta di non mappare
> :) Se non ho un tag che mi soddisfa o mi adatto a quello che c'è o me lo
> invento.


Perdonami, lo trovo perfettamente pertinente e frutto di una discussione in
lista proprio sugli indirizzi portata a suo tempo da mbranco2.

Infatti in quella pagina viene descritto l'uso di addr:place al posto di
addr:street e, almeno in teoria, addr:place vorrebbe il corrispondente tag
place.

Inoltre, se fossimo concordi sull'indicazione di Martin (ovvero di usare un
nuovo tag place=dispersed_settlement), bisognerebbe anche indicare dove
posizionare il nodo corrispondente.

Sul fatto di inventarsi i tag a proprio piacimento, senza alcuna
discussione, la mia personale opinione è che i danni fatti in questi anni
sono peggiori dei benefici.

Ciao,

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

[Talk-it] Campeggio privato

[Volker Schmidt]

Controllando la presenza di campeggi ho incontrato questo posto [1] nelle
mie vicinanze che è taggato tourism=camp_site. Come conseguenza appare
anche su http://unterkunftskarte.de.
In realtà si tratta di una associazione che lo utilizza come villaggio
turistico privato permanente. Non accetta esterni.

Si, il posto ha l'aspetto di un campeggio, cioè landuse=camp_site con
access=private sarebbe corretto, tourism=camp_site non lo è perché loro non
prevedono nessun servizio o simile per turisti.

Sono sicuro che ci sono tanti di questi finti campeggi in giro, ma come
inserirle correttamente nella mappa?

[1]  https://www.openstreetmap.org/way/98291056/history
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nomi delle strade e numeri civici

[Lorenzo Mastrogiacomi]

Il 27 marzo 2018 09:39:52 CEST, Andrea Musuruane  ha 
scritto:

>
>Per togliere quella frase, bisogna trovare un valore di place adatto
>alle
>case sparse.

Ma questo è un problema che non ha niente a che fare con la nomenclatura o i 
civici, al massimo andrebbe nella pagina sui place. 

Inoltre è la prima volta che vedo su un wiki la richiesta di non mappare :) Se 
non ho un tag che mi soddisfa o mi adatto a quello che c'è o me lo invento.

Lorenzo

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Hier liegt ein Fehler vor (keine Tankstelle vorhanden). Etwas weiter
im Nordwesten gibt es eine Tankstelle in meiner Erinnerung ist das
aber nicht Aral:

http://audit.osmz.ru/browse/navads_fuel/NVDS114_27007300DE1

Hier passen name (Jet) und das neu hinzugefügte brand (avia) nicht zueinander:

http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243


Zudem scheint der Import auch Betriebs- oder Firmentankstellen
mitzubringen, aber das lässt sich aus der Ferne nur schwer sagen. Für
mich sehen diese Stellen aus der Ferne nach LKW-Diesel Stationen aus,
die nicht zwingend öffentlich zugänglich sein müssen:

http://audit.osmz.ru/browse/navads_fuel/NVDS126_3043 (Gelände der
"Regionalbus Rostock")
http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243
http://audit.osmz.ru/browse/navads_fuel/NVDS126_3042

Grüße Falk

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

Re: [Talk-it] Segnaletica attacco autopompa VVF, idrante forse, che tipo è?

[Martin Koppenhoefer]

2018-03-26 21:12 GMT+02:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:

> Il 26/03/2018 21:05, paolo bubici ha scritto:
>
>> Ecco come mapparli:
>>
>> emegency=dry_riser_inlet
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Dry_riser_inlet
>>
>> https://wiki.openstreetmap.org/wiki/Albisola#Attacchi_di_mandata
>>
>> Bubix
>>
>>
>>
>>
> Mi pare strano che in case civili ci sia questo tipo di condotta.
>
> Capirei in uno stabilimento tipo fabbrica, ma quei parliamo di case
> abitate, in mezzo ai paesi.
>


non dobbiamo progettare il sistema antiincendio, dobbiamo soltanto rilevare
quello che c'è. A me dalla descrizione che hai dato mi sembra pertinente il
tag.

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

Re: [Talk-de] Navads-Tankstellenimport

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 09:05, "websi...@posteo.de"  wrote:
> 
> Grundsätzlich würde ich den Import als nicht völlig verkehrt bezeichnen,
> allerdings sind doch einige Fehler in den Daten.


Danke für die Analyse, um Deine Beispiele besser einordnen zu können, wäre es 
noch interessant zu wissen, wieviele Tankstellen Du insgesamt angesehen hast 
(wie hoch die Fehlerrate ungefähr war), und wie viele neue Daten dazukämen, 
oder ob die richtigen Punkte aus dem Datensatz mehr oder weniger schon in OSM 
drin sind.

Klingt für mich bisher so, als würde man am besten kleine lokale Päckchen 
machen, die die Community als Hilfe zur QA nutzen kann, die aber nicht blind 
importiert werden sollten, zumindest nicht in Gebieten mit aktiven Mappern.

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

Re: [Talk-it] Tratti brevi e riferimenti

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 09:26, Simone Saviolo  wrote:
> 
> se vuoi risolvere il problema, va affrontato nel rendering. 


+1, quando i dati sono giusti i problemi di visualizzazione sono da risolvere 
nello stile.

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

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 09:39, Andrea Musuruane  wrote:
> 
> Purtroppo mi sembra che, nonostante il problema sia sentito anche in altre 
> nazioni, come la Spagna, non si sia arrivati a una conclusione.


perché non mettiamo
place=dispersed_settlement
e lo documentiamo nel wiki, così lo possono utilizzare anche gli altri?
Raggiunto un certo numero chiediamo al rendering di visualizzare il nome e da 
quel punto sarà utilizzato anche da chi mappa soprattutto per il rendering ;-)

Se non prendiamo una decisione saremmo condannati ad aspettare gli altri, e 
probabilmente ci ritroveremmo fra qualche tempo di nuovo davanti allo stesso 
problema...


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

Re: [Talk-it] Nomi delle strade e numeri civici

[Andrea Musuruane]

Ciao Lorenzo,

2018-03-27 2:22 GMT+02:00 Lorenzo Mastrogiacomi :

> https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_
> specifiche_per_l.27Italia
>
> Questa frase secondo me genera confusione in questo articolo e sarebbe
> meglio toglierla:
>
> "Non si deve inserire la località come nodo quando questa rappresenta
> delle "case sparse" (non c'è attualmente un modo per indicare questa
> tipologia)."
>
>
> Comunque se c'è una località con nome in qualche modo bisogna inserirla
> anche se non c'è un tag place la cui definizione si adatta alla perfezione.
>
> Personalmente credo che place=locality vada bene per le case sparse. Nel
> wiki inglese è nella sezione "Other places" che contiene tutti tag non
> legati alla popolazione, anche se poi la definizione di locality dice che è
> un posto non popolato. Potremmo adattare la definizione italiana come
> località generica non necessariamente legata alla popolazione residente?
> Questo articolo wikipedia cita anche le case sparse. Forse è di aiuto?
> https://it.wikipedia.org/wiki/Localit%C3%A0_abitata
>

Per togliere quella frase, bisogna trovare un valore di place adatto alle
case sparse.

"The place=locality tag is used to name an *unpopulated location*":
https://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality

Quindi place=locality non va assolutamente bene.

Dato che la discussione su come mappare le "case sparse" ritorna
periodicamente in ML da anni, l'ultima volta Martin aveva scritto alla ML
di tagging:
https://lists.openstreetmap.org/pipermail/tagging/2017-June/032610.html

Purtroppo mi sembra che, nonostante il problema sia sentito anche in altre
nazioni, come la Spagna, non si sia arrivati a una conclusione.

Ciao,

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

Re: [Talk-it] Tratti brevi e riferimenti

[Simone Saviolo]

Il giorno 27 marzo 2018 00:30, aldoct  ha scritto:

> Quando mi capita di inserire un ponte non inserito in precedenza su una
> strada già mappata, i riferimenti vengono "clonati" con un risultato
> sgradevole come estetica che per di più maschera la conseguenza della
> correzione eseguita. Comporta qualcosa cancellare i riferimenti clonati nei
> tratti brevi?
>

Sì, comporta che cancelli dati corretti :)

La confusione nel rendering è un errore/problema del rendering. Il dato è
giusto che ci sia - se è corretto. Come mappatore, fregatene di come viene
il rendering: se vuoi risolvere il problema, va affrontato nel rendering.

Ciao,

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

Re: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Srravya C]

Oh, alright. Thanks for explaining. :)

On 27 March 2018 at 12:46, Rory McCann  wrote:

> On 27/03/18 09:00, Srravya C wrote:
>
>> What does minority language mean? I am not sure what you were referring
>> to.
>>
>
> Some country have many official and/or minority languages (as someone
> from India, you should know what I'm talking about ). If you try to
> make a map from OSM with those langauges (using the name:XX tag), you
> can find coverage of that is a bit poor, with not many
> countries/cities/towns/states/etc having such a tag. So we could try to
> ensure that those names are in OSM.
>
> I was just brainstorming for new ideas.
>
___
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: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Rory McCann]

On 27/03/18 09:00, Srravya C wrote:

What does minority language mean? I am not sure what you were referring to.


Some country have many official and/or minority languages (as someone
from India, you should know what I'm talking about ). If you try to
make a map from OSM with those langauges (using the name:XX tag), you
can find coverage of that is a bit poor, with not many
countries/cities/towns/states/etc having such a tag. So we could try to
ensure that those names are in OSM.

I was just brainstorming for new ideas.

___
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: [Talk-de] Navads-Tankstellenimport

[websi...@posteo.de]

Ich habe diverse Tankstellen in und um Bremen überprüft. Folgende
problematische Tankstellen habe ich gefunden:

http://audit.osmz.ru/browse/navads_fuel/NVDS114_13146600DE1 (laut
Website eine Total Tankstelle, auch die bereits vorhandene Telefonnummer
scheint richtig zu sein)

http://audit.osmz.ru/browse/navads_fuel/NVDS114_13127100DE1 (deutlicher
Location Offset)

http://audit.osmz.ru/browse/navads_fuel/NVDS126_1360 (vermutlich Offset
und laut Website sind die vorhandenen Öffnungszeiten korrekt)

http://audit.osmz.ru/browse/navads_fuel/NVDS126_1418 (vermutlich Offset)

http://audit.osmz.ru/browse/navads_fuel/NVDS402_014 (Tankstelle soll
hinzugefügt werden. Die Position ist laut Luftbild völlig falsch
(scheint von Google zu stammen). Die Tankstelle existiert in OSM bereits
weiter nördlich und stimmt optisch auch mit der Website überein
(http://classic-oil.de/tankstellen/unsere-tankstellen/classic-breddorf/)

http://audit.osmz.ru/browse/navads_fuel/NVDS402_048 (Tankstelle soll
hinzugefügt werden. Position ist daneben und Tankstelle existiert laut
Betreiber nicht http://classic-oil.de/tankstellen/unsere-tankstellen/)

Weiter habe ich nicht nachgeforscht.

Grundsätzlich würde ich den Import als nicht völlig verkehrt bezeichnen,
allerdings sind doch einige Fehler in den Daten. Konnte man klären, wie
alt diese sind? Ein großer Zugewinn ist in Deutschland meines Erachtens
nicht zu erwarten. Öffnungszeiten sind nützlich, wenn sie denn stimmen.
Dinge wie addr:postcode=* finde ich unwichtig. Vor allem sollte vor dem
Hinzufügen von nicht in OSM existierenden Tankstellen beim Betreiber
überprüft werden, ob es diese überhaupt noch gibt. Auch scheint die
Position in diesem Fall öfter nicht zu stimmen.

Viele Grüße,

highflyer74

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

Re: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Srravya C]

Hi Rory,

This is an exciting idea!  I'm interested in being a part of such quarterly
projects! The possibilities are wide open. We could begin with mapping some
under-mapped amenities which are of interest to this diversity group/list.

What does minority language mean? I am not sure what you were referring to.

Cheers,
Srr



On 27 March 2018 at 01:54, Rory McCann  wrote:

> Hi guys, gals and non-binary pals,
>
> 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.
>
> 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, recently mentioned women's health care
> facilities, wheelchair accessibility, gay bars, gendered toilets for
> trans/gnc/etc people, minority language? 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!")
>
> What do yous think? Would many be interested in taking part?
>
> --
> Rory
>
> ___
> Diversity-talk mailing list
> Code of Conduct: https://wiki.openstreetmap.org/wiki/Diversity/
> MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
___
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 ?

[David Marchal]

Deux versions serait peut-être trop demander pour un petit projet de ce genre, 
en tout cas pas tant qu’une des deux n’est pas déjà fonctionnelle et 
expérimentée.


De : Philippe Verdy 
Envoyé : dimanche 25 mars 2018 11:35
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

Rien n'empêche d'avoir les deux options. Donc une batterie interne, le port USB 
et une batterie externe qu'on peut brancher pour plus d'autonomie. Cela reste 
un seul boitier à développer (pas besoin de développer un boiteir externe 
supplémentaire, des batteries externe portables USB ça existe déjà un peu 
partout, et on a foison de chargeurs et adaptateurs USB pour véhicules). On est 
dans le même cas que les smartphones en fait.

En revanche on peut imaginer deux versions de ce boitier GPS:
- autonome avec sa prise antenne externe optionnelle et batterie intégrée
- ou toute petite clé USB à brancher sur un PC ou une planche de bord et sans 
batterie (alimenté par le port USB), et là encore avec un mini port antenne 
optionnel: pour des raisons pratiques, le port USB n'est pas fixé à la mini 
carte-mère, mais relié par un mini-câble, ce qui facilite le placement (le 
reproche qu'on peut faire à plein de clés USB c'est que ce sont des "verrues" 
fragiles, le port USB peut facilement casser, c'est souvent mieux et plus 
résistant avec un mini-câble; même pour mon PC fixe je ne relie jamais mes clés 
externes directement au port du PC mais via un câble intermédiaire, ça évite 
plein d'accident; seule exception: si la clé tient presque entièrement dans le 
port comme les mini-clés USB pour clavier/souris sans fil en Bluetooth, pas 
besoin de câble).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[David Marchal]

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. Ça pourrait viser, par exemple, les réfractaires à ces 
menottes technologiques, ceux qui n’en ont pas les moyens ou ceux qui veulent 
profiter de la nature sans surveiller sans arrêt leur smartphone – comme vous 
l’aurez sans doute compris, je parle en connaissance de cause. 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.


Cordialement.


De : Francois Gouget 
Envoyé : vendredi 23 mars 2018 11:25
À : verd...@wanadoo.fr; Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

On Thu, 22 Mar 2018, Philippe Verdy wrote:

> < 1 m en montagne c'est difficile  pour une simple raison: le manque de
> visibilité d'une part et les réflexions/chemin multiples sur les parois, et
> souvent aussi la végétation en zone forestière. Particulièrement sans
> correction si c'est l'objectif et encore plus en monofréquence.
[...]
> L'absence de ces corrections basées sur d'autres observations et mesures
> prises par d'autres satellites ou stations d'observation au sol fait qu'on
> ne peut espérer mieux qu'une précision de 30 mètres en montagne. On peut
> toujours rêver mais il faut comprendre un peut comment et sur quelles
> mesures se basent les systèmes GNSS.

Du coup quel serait l'intérêt d'un tel GPS par rapport à un smartphone ?

Il ne reste guère que l'autonomie et le plaisir d'avoir du matériel
libre mais est-ce vraiment suffisant ou cela ne le condamne-t-il pas à
être diffusé à une douzaine d'exemplaires seulement ?

La précision c'est vraiment le principal reproche que je ferait au GPS
de mon smartphone. Paradoxalement en voiture elle est suffisante pour du
Mapillary mais dès que je me promène en ville à pied il divague beaucoup
(je soupçonne qu'il utilise la vitesse pour restreindre le champ des
possibles de la prochaine position). Étant donné les problèmes de
réflexion et de masquage des satellites je ne vois guère de solution
hors passer justement à un système travaillant à partir de la L5.

La fréquence de mise à jour de la position est potentiellement un
deuxième problème mais il est tout aussi probable que ce soit juste un
bug de Mapillary.

Donc, pour moi, un GPS séparé pourrait éventuellement être intéressant
mais uniquement s'il offre une meilleure précision. Or il y a à présent
assez de satellites qui émettent un signal L5 et on nous promet de
nouveaux smartphones avec des puces GPS qui l'utilisent pour 2018. Du
coup j'attendrai peut-être simplement de changer de smartphone.

https://spectrum.ieee.org/tech-talk/semiconductors/design/superaccurate-gps-chips-coming-to-smartphones-in-2018
[https://spectrum.ieee.org/image/Mjk1NDM3OQ.jpg]

Superaccurate GPS Chips Coming to Smartphones in 2018 
...
spectrum.ieee.org
Broadcom has released the first mass-market GPS chips that use newer satellite 
signals to boost accuracy to 30-centimeters





--
Francois Gouget   http://fgouget.free.fr/
   A man can fail many times, but he isn't a failure
until he begins to blame somebody else.
   -- John Burroughs
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[David Marchal]

Bonjour.


Pour l’écran, en tant que randonneur, ça ne me serait guère utile : la 
navigation en suivant son itinéraire sur la carte papier est plus pratique que 
d’y reporter sans arrêt la position GPS, mais je fais ces choses-là à 
l’ancienne, donc tout le monde ne sera peut-être pas de cet avis.


Le Bluetooth, s’il est présent, devrait être optionnel, et le boîtier devrait 
être capable d’enregistrer sans, car tout le monde n’en aura pas l’utilité, ni 
l’envie de gérer ça pendant une rando : typiquement, on randonne pour se 
désencombrer la tête, donc gérer le boîtier au delà de l’allumer et s’assurer 
que la réception fonctionne, bof… La carte microSD, en revanche, très bonne 
idée ! On insère, on allume, on attend une position stable pour démarrer, et on 
oublie le boîtier jusqu’à l’arrivée.


Pour une batterie interne, pas de souci tant qu’on peut jouer du fer à souder 
pour la changer en cas de besoin, et qu’elle tient la journée ; arrivé au soir, 
on peut la brancher sur une batterie externe pour la recharger, c’est 
suffisamment minime pour ne pas encombrer une soirée à la belle étoile avec un 
surplus de technologie.


Pour l’antenne, bonne idée de l’avoir magnétique pour les voitures, tant qu’on 
peut la fixer sur soi en rando ; j’avais dans l’idée de la mettre sur la 
lanière du sac à dos, sur l’épaule, en hauteur et avec une vue assez dégagée. 
Sur la casquette, ça ne serait guère discret.

Cordialement.

De : Stéphane Péneau 
Envoyé : vendredi 23 mars 2018 16:12
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

Je vais essayer de répondre aux différentes questions :

Licence :

Pas d'inquiétude, notre concepteur (que je prénommerai Hooligan0) est 
parfaitement au courant des différentes licences et de la manière dont elles 
s'appliquent. Le CC-by-SA faisait référence au design technique, pas au code 
nécessaire. Celui-ci sera sous une licence "quivabien".
A ce propos, il n'est pas prévu de remplacer complètement le logiciel U-center 
de Ublox, qui donne accès à des centaines de paramètres de la puce, et qui lui 
n'est pas FOSS. Mais on n'empêchera personne de reprendre la doc du protocole 
Ublox pour en refaire un, libre, et multi plateformes.


Présence ou non d'un écran sur le récepteur :

Ce n'était pas prévu, et cela risque d'augmenter le coût. Synchroniser des 
photos depuis la trace reste possible en photographiant l'écran d'un 
smartphone, qui lui, afficherait en gros l'heure GPS. Je ne sais pas si ça 
existe. A creuser.
S'il y a beaucoup de demandes pour un écran, on regardera.


Protocole de communication avec un smartphone :

C'est le profil SPP du bluetooth, une banale liaison série. C'est compatible 
avec à peu près tout.
Le Bluetooth low energy, rien de certain pour le moment.


Enregistrement des points :

Je ne pense pas que filtrer les points soit pertinent. Il vaut mieux garder les 
infos brutes, et éventuellement filtrer par la suite.
Si le stockage se fait sur une carte microSD, la nbr de points importe peu. Si 
c'est sur de la mémoire flash, passer de 32 à 64Mo, c'est de l'ordre de 5€.

Utilisation sur piles :

Le souci des piles, c'est leurs capacités plus faibles que les batteries Li-ion.
Est-ce qu'une batterie Usb externe pour recharger le récepteur serait 
problématique en situation de trek ?

Boutons pour enregistrer des POI :

J'aimerais beaucoup que ça soit possible. Ça va dépendre en partie du 
microcontrôleur qui sera utilisé. J'imagine aussi assez bien un connecteur pour 
pouvoir déporter ces boutons.

Le projet Centipède :
Centipède c'est avant tout le réseau de bases pour faire du RTK. Là on parle 
plutôt de la partie mobile.
Donc non, ce projet n'a pas de lien particulier avec celui de Julien Ancelin, 
mais pourrait tout à fait s'y insérer pour la partie "rover" si la puce est une 
M8T ou une M8P. De toute façon, je lui en toucherai certainement 2 mots.


La précision :

Alors là, ça va être un peu plus long.
Partons du postulat qu'on utilise un récepteur monofréquence, et je vais 
ignorer tout ce qui est SBAS, RTK, que Galileo promet une meilleure géoloc, 
etc..

Les variations de précision qu'on va obtenir dépendent principalement du nombre 
de satellites en vue directe par l'antenne, et des caractéristiques 
(sensibilité, etc..) de cette dernière.

Si je prends mon smartphone, que je le place dans une zone complètement 
dégagée, ça va très bien fonctionner, sans doute aussi bien qu'un système plus 
performant.

Si je pose mon smartphone sur le tableau de bord de la voiture, alors j'ai déjà 
environ la moitié des satellites qui sont invisibles à cause du toit (ceux qui 
sont derrière le véhicule). Si je passe le long d'une forêt, j'en perd encore, 
ce qui va forcément dégrader le positionnement.
En revanche, si j'ai mon antenne magnétique posée sur le toit de la voiture, 
tous les satellites sont disponibles, et ils resteront bien plus 

Re: [Talk-de] Karte mit Campingplätzen?

[Marc Gemis]

Hallo,

es gibt auch http://unterkunftskarte.de/

m.

2018-03-27 8:07 GMT+02:00 lars lingner :
> Hallo,
>
> Ergänzend möchte ich auf die Overpass-API hinweisen. Ein Query für
> tourism=camp_site in Deutschland könnte so aussehen:
>
> https://overpass-turbo.eu/s/xlQ
>
> Wobei ich gerne zurückfragen möchte: Was meinst du mit "Karte"? :)
> Onlinekarte mit Filtermöglichkeit, Karte mit bestimmten Kriterien eines
> Campingplatzes, gedruckte Karte fürs Fahrrad, offline Karte für
> abgelegene Regionen ohne Netz oder Strom...
>
>
> Viele Grüße,
>
> Lars
>
> ___
> 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] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

sent from a phone

> On 27. Mar 2018, at 02:22, Lorenzo Mastrogiacomi  wrote:
> 
> Comunque se c'è una località con nome in qualche modo bisogna inserirla anche 
> se non c'è un tag place la cui definizione si adatta alla perfezione.



+0.6 (si all’inserimento, e si per togliere la frase dal wiki, ma non 
all’applicazione di un tag non adatto


> 
> Personalmente credo che place=locality vada bene per le case sparse.


no, perché locality è per toponimi senza abitanti.

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

Re: [Talk-de] Karte mit Campingplätzen?

[lars lingner]

Hallo,

Ergänzend möchte ich auf die Overpass-API hinweisen. Ein Query für
tourism=camp_site in Deutschland könnte so aussehen:

https://overpass-turbo.eu/s/xlQ

Wobei ich gerne zurückfragen möchte: Was meinst du mit "Karte"? :)
Onlinekarte mit Filtermöglichkeit, Karte mit bestimmten Kriterien eines
Campingplatzes, gedruckte Karte fürs Fahrrad, offline Karte für
abgelegene Regionen ohne Netz oder Strom...


Viele Grüße,

Lars

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