Re: [OSM-ja] shop=farm は水産物は対象外?

[Taro Matsuzawa]

松澤です。

http://wiki.openstreetmap.org/wiki/JA:Key:shop

そもそも、
shop=seafood
で良いのではないでしょうか？
> 鮮魚店。鮮魚や水産物を販売する店舗です。
直売所かどうか関係なく「魚屋さん」でよいような気がします。

On 2017/05/06 16:52, Nobusuke Iwasaki wrote:

こんにちは、いわさき＠OSGeoの人です

farmという単語ですが、農業だけで無く、例えば、水産物の養殖にも、farmingが使われますし。
なので、一般的な話としては、水産物直売所でも farmでもいい気がします。
ただ、天然物を扱っている場合はどうなるのかとか、稚貝や稚魚を放流する場合は、養殖になるのかとか、細かい突っ込みがあるかもしれませんが。

誰か漁業が専門の方がいらっしゃったら、教えて下さい（汗


2017年5月6日 14:56 ribbon :

shop=farm は、いわゆる農産物直販所を意図しているのだと思います。
ただ、海岸沿いとかで、「水産物」直販所なんかもあるわけです。

そういった場合、shop=farm は不適切でしょうか?

ribbon



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







--
Georepublic Japan Ltd.
c/o CommunityLink
5-3-1 Kumoidori, Chuo Ward
Kobe 651-0096

Taro Matsuzawa
Senior Developer

eMail: t...@georepublic.co.jp
Web: https://georepublic.info

Tel: +81 (03) 6868 5418
Fax: +81 (03) 3374 0291

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

[Talk-TW] Fwd: [study] Dr. Ottinger 訪台活動第一發，1060515「公民科學實踐方案」工作坊＠高雄！

[洪朝貴]

空污資訊基礎建設...
不知道跟空氣盒子有沒有關係?
或許 list 上的朋友會有興趣去跟他們交流一下。



--
『我的野蠻工讀生』用高昂的『下賊船的代價』
綁架了我的文件! (請分別搜尋)
Chao-Kuei Hung 洪朝貴

PGP Key ID: 4096R/5828A7A7
Fingerprint: 67AF B5AB 5242 3E99 16D7  EAF8 A94D 2C92 5828 A7A7



-- 轉寄的郵件 --
寄件者： Wenling Tu 
日期： 2017年5月8日 上午9:45
主旨： Re: [study] Dr. Ottinger 訪台活動第一發，1060515「公民科學實踐方案」工作坊＠高雄！
收件者： "sci-st...@googlegroups.com" 


大家好，
從FB看到一些朋友想參加但難以配合公開演講行程，其實我們此次除了公開正式演講行程外，有很多是深入社區座談、田野參訪行程，沒有特別對外公佈，是想說透過實地踏查與小型討論，可以進行更多有意義的交流，甚至一起激盪可能的行動藍圖。基本上，我們第一個禮拜的行程會在中南部，第二個禮拜的行程在台北，如果study
list上的朋友有興趣想要跟Gwen有進一步的交流，可以私訊我。
這裡也呼應一下文玲唯一在南台灣的一場公開演講，感謝海科大熱情贊助，搭建了這個媒合平台。
閱讀
Gwen
最近提供來台演講的資料，我覺得對於台灣在空污問題上如何思考以及實踐科技民主化很有啟發，提醒我們在社區空污監測上，或許應該放更多力氣在資訊基礎架構的建立，讓資訊的呈現可以讓某些東西（過去被忽略的）被看到、被知道，並賦予意義。
讓空污資訊的基礎建設更具STS意涵，使系統性改變的需求可以被看見，並支持環境正義運動的實踐。

文苓

Wen-Ling Hong  於 2017年5月6日 下午7:30 寫道：
>
>
>
> 各位ＳＴＳ朋友大家好：
>
> 高雄海洋科技大學STS中心將於5月15日，與台大社會科學院風險治理與政策研究中心 杜文苓教授研究團隊邀請美國卓克索大學政治系/科技與社會中心副教授Gwen 
> Ottinger來校演講，分享她在環境正義與公民科學領域的研究成果，更希望透過與台灣學界、NGOs以及石化區周界社區居民的交流，相互學習。
>
> Gwen Ottinger 
> 主要研究領域為STS與環境正義，聚焦在環境危害的風險分配不正義與決策權力的研究主題。在美國長期關注美國受空氣污染社的環境正義問題，親身與在地社群聯繫交流，協助發展公民科學，並進行社區培力活動，為近年美國公民科學實踐與理論發展的超新星！
>
> 高雄作為一個工業城市，從過去到現在一直面臨著空氣污染及環境正義的問題。今年4月13日行政院長宣布了14項改善空氣汙染的防治策略，但具體政策仍不理想，讓人失望。然而這正是科研與教育單位和公民一起發揮力量的重要時刻。在這次的工作坊中，我們希望借助Gwen
>  
> Ottinger分享在美國的經驗，集合高雄的在地公民對環境科學知識的需求，媒合不同專長領域的學者，期盼能在跨領域的研討、協作、與對話中，推動環境治理的轉型。
>
> Gwen Ottinger訪台行程，詳情與介紹：點此
> 海科大校內場次為：「公民科學實踐方案」工作坊
> 時間：5/15（一）14:00~17:00
> 地點：國立高雄海洋科技大學 楠梓校區 大信樓三樓
> 線上報名，點此
>
>
> 議程：
> 14:00~14:10 開場
> 14:10~15:10 專題演講：Information Infrastructure for Environmental Justice
> 15:10~15:20 茶敘
> 15:20~16:00 依專長與關心議題，分組討論在地議題、科學選擇等等
> 16:00~17:00 論壇：綜合報告與討論－連結科學工具，建置合作網絡
>
>
> 邀請大家！　也感謝協助轉發。
>
> 高雄海洋科技大學　洪文玲
>
>
> ===
> 國立高雄海洋科技大學海洋工程學院科技與社會(STS)研究中心
> 電話：07-3617141轉3425
> 信箱：s...@mail.nkmu.edu.tw
> 地址：81157高雄市楠梓區海專路142號  造船及海洋工程系
>
> --
> STS studylist's long term moderater is 傅大為，questions can be sent to
> d...@mx.nthu.edu.tw
> studylist 成員送上網的 email, 若一定要附加檔，請自我約束，資料量勿超過500K, 謝謝。


--
STS studylist's long term moderater is 傅大為，questions can be sent to
d...@mx.nthu.edu.tw
studylist 成員送上網的 email, 若一定要附加檔，請自我約束，資料量勿超過500K, 謝謝。
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [Talk-GB] Birmingham Tree Import

[Harry Wood]

> On 27/04/2017 20:26, Brian Prangle wrote:

> I've annotated Harry's Import wiki page with some comments and ideas.

This one: 
https://wiki.openstreetmap.org/wiki/Birmingham_City_Council_trees_data 

I don't want you to think of it as *my* wiki page. Like any wiki page we should 
aim to reflect the balance of opinion on there. I tried to distill discussion 
so far. Actually we haven't discussed the tree tags all that much. I was 
summarising a lot from Will Phillips Mar 19th: 
https://lists.openstreetmap.org/pipermail/talk-gb/2017-March/020058.html
...with a bit of my own opinion in stirred in.


There's a section of the wiki page 'Data fields'...
https://wiki.openstreetmap.org/wiki/Birmingham_City_Council_trees_data#Data_fields
which you could fill in with more details. form, age, plot_number, and (as 
already mentioned) usrn, could all do with some explanation.

As for my own opinions on the tags, my main feeling is that they add up to 
quite a heavyweight transfer of database columns. I think I would suggest 
slimming out these ones entirely:
  site_name=LUDGATE HILL
  ward=Ladywood
  constituency=City Centre
Because (like the old is_in tag) these are not technically necessary, and not 
really appropriate for something as fine-grained and numerous as tree nodes.


> Apart from some posts  about the problems with email notifications of
> changeset discussions, there has been nothing to indicate where I take this
> import. I guess that's because the initative is really down to me.

Yes. I guess the question now is whether it's necessary to fix some aspects of 
the tagging via a corrective bulk edit, and whether that should happen before 
or after finishing off the last bit of the import.

You said you've done quadrants of the city: NW,SW & SE completed. So just the 
NE quadrant to finish off. You've added 42,974 so far, so there's what? another 
~15,000 trees to add?  To me it seems reasonable to just finish that off. That 
leaves us with a consistent uniform set of trees tagged the same way (to fix if 
needed).

Harry

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

Re: [Talk-it-lazio] Walk4art II appuntamento: lunedì 8 maggio ore 17.00 a Piazza Niccolò Copernico

[Pelato Marcello]

Presente.


M.P.

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

Re: [Talk-at] Fahrverbot für Kraftfahrzeuge ausgen. Fahrzeuge der Anrainer und ihrer Lieferanten

[Friedrich Volkmann]

On 07.05.2017 22:14, Markus Straub wrote:

Ad private: Ich denke wir könnenn mit den derzeitigen Taggingmöglichkeiten
nicht wirklich zwischen einer Privatstraße und einer öffentlichen Straße mit
Fahrverbot ausgen. Anrainer unterscheiden. Beides wäre imho vehicle=private.


Ich hab seit 2 Jahren vor, ein Proposal für vehicle=residents (bzw. 
allgemein formuliert access=residents) zu erstellen, hab aber noch nicht die 
Nerven dafür gefunden. Es gibt nämlich 2 Probleme: Eines ist, dass man bei 
der Gelegenheit auch gleich ein Proposal für einen Wert für Anrainerverkehr 
machen sollte, aber dafür gibt es keine englische Übersetzung.



Anders siehts bei ausgen. Anlieger aus, das wäre dann vehicle=destination.


Anlieger ist ein Synonym für Anrainer, darum nicht vehicle=destination, 
sondern private oder residents. Und damit kommen wir zum zweiten Problem, 
nämlich dass einige Deutsche das nicht verstanden haben und das Wiki so 
verpfuscht haben, dass dort destination für Anlieger, Anrainer und -verkehr 
empfohlen wird. Ich hab das ein paar mal korrigiert, aber gegen deren 
zahlenmäßige Übermacht war nicht anzukommen. Wenn wir ein Proposal für 
residents oder Anrainerverkehr machen, müssen wir damit rechnen, dass die 
Deutschen das niederstimmen, weil sie sagen, sie haben das immer schon mit 
destination getaggt und deswegen ist das richtig so.



Woher hast du die Info / Interpretation, dass Anrainer ohnehin immer
mitgemeint sind? Ich fänds auch logisch und hab im Wiki nach dieser Aussage
gesucht, sie aber nicht gefunden.


Manche Dinge sind so selbstverständlich, dass man sie nicht extra erwähnen 
muss. So steht z.B. auf der englischen Seite für key:oneway nicht, dass 
Fußgänger gegen die Einbahn gehen dürfen. Diese undokumentierten 
Implikationen sind ein Spiegelbild der Realität, wo ja genauso keiner 
"ausgenommen ich" auf ein Verbotsschild draufschreibt. Da gab es mal einen 
witzigen Fall, wo jemand ein Halteverbotsschild vor sein Haus hängte und 
dann von der Polizei einen Strafzettel kassierte, als er selber dort parkte.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [OSM-ja] OSM Access Mapのご紹介とご協力願い

[yuu hayashi]

hayashiです

ちょっと試しに使ってみました。
とてもおもしろいアプリだと思います。
なんかいろいろ活用できそうな気がします。

いきなり機能改善の要望で心苦しいですが、PNG出力の背景色を「白色」にしてほしいです。「透明色」ならもっと嬉しい。

ではでは

2017年5月8日 0:50 K.Sakanoshita :

> 坂ノ下です。
>
> 最近はマッピングパーティの告知ばかりですみません。
> 少し別のネタを作ったので、ご協力頂けますと幸いです。
>
> OSMをもう少し簡単に扱うためのWebアプリを作りました。
>
> [OSM Access Map]
> https://www.netfort.gr.jp/~saka/accessmap/
>
> [開発意図]
> ・Google Mapは規約上、印刷した紙は自分だけが使える。
>
> ・OpenStreetMapは印刷出来るけど、建物や店名などの
> 不要な情報も印刷されてしまい、使い勝手が良くない。
>
> そんな方向けに、「必要な道だけを画像に書き出しする」
> Webアプリを作りました。（元データはOpenStreetMap）
> ※書き出した後、オフィスソフトで各種加工が出来ます。
>
> 学校に提出する登校ルート、地域の防災マップ以外にも、
> お店やイベント会場への案内マップなどにも使えるはず。
> ※こんなことに使えるアイデアや活用事例を募集します。
>
> 最初のバージョンを作ったばかりなので、機能不足なども
> あると思います。そこはご要望頂けますと幸いです。
>
> それでは。
>
> --
> /*
>  * K.Sakanoshita (http://www.netfort.gr.jp/~saka/)
>  * (Phone) barsa...@gmail.com / (PC) s...@netfort.gr.jp
>  */
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-co] Usuarios de maps.me

[Igor TAmara]

Hola, alguien sabe si un usuario de maps.me tal vez puede ser notificado
cuando se le envía un mensaje vía la interfaz de OSM?

Por ejemplo, este usuario
https://www.openstreetmap.org/user/Jairo%20marin/history#map=12/4.6802/-74.1116

No recuerdo haber visto previamente que hayamos tenido una situación con
alguien usando maps.me.

Es un usuario que podría contribuir porque al parecer está interesado en
institituciones educativas, cómo se tutorea?  Por ahora le envié un mensaje
contándole que podría serle de utilidad umap.

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

[OSM-talk-ie] Speed limits - Dublin

[Colm Moore]

Hi,


Just to let people know that a **lot** of speed limits are changing in Dublin 
and thousands of ways need updating. It may make sense to share the work and 
pick assigned areas.


* Dublin City - Phase 1 city centre - mapped 99%.

* Dublin City - Phase 2 some suburbs changing June 2017 - help welcomed! :) 
http://www.dublincity.ie/sites/default/files/content/RoadsandTraffic/Documents/Adopted%20Special%20Speed%20Limit%20Bye-Laws%202016%20-Signed.pdf
* South Dublin County - 80%+ of county changing on 8 May 2017 - about 10% of 
changes mapped, help welcomed! :) 
http://www.sdublincoco.ie/index.aspx?pageid=939=37154


ITO Map updates every few weeks: 
http://product.itoworld.com/map/124?lon=-6.28499=53.32984=11=true


Colm


---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it-lazio] Walk4art II appuntamento: lunedì 8 maggio ore 17.00 a Piazza Niccolò Copernico

[Martin Koppenhoefer]

sent from a phone

> On 7. May 2017, at 23:43, jprimav  wrote:
> 
> Chi c'è domani?


io conto di esserci 

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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Christoph Hormann]

On Sunday 07 May 2017, Frederik Ramm wrote:
>
> It is a common issue in OSM (and elsewhere) for people to use the
> status quo as a reason. "Admin boundaries are not visible on the
> ground and they are mapped, THEREFORE I can also map everything else
> that is not visible on the ground" - no! And you're doing it the
> other way round, saying "your privacy goes down the drain if you do
> anything online anyway, so why should we at OSM take steps to protect
> it more".

But we also should be careful not to apply the 'analogy sledgehammer' 
the other way round - just because restricting access to data can in 
some case reduce privacy issues it is not necessarily always the best 
way to deal with such a problem.

Specifically that putting a login via OSM account in front of HDYC makes 
sense for this specific tool and some specific concerns regarding it 
(mainly the 'invitation to stalking' matter) should not lead anyone to 
consider this a useful standard measure for all privacy related 
concerns.  

Side note: Mailing lists are a very different matter for a variety of 
technical and social reasons.  I would say that the idea of restricting 
mailing list archive access due to metadata based privacy concerns is 
fairly far fetched (in contrast to content related concerns about 
privacy or confidentiality - which make much more sense) considering 
the archives show almost nothing of the mail metadata except 'From' 
and 'Date' which can be freely chosen by the user.

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

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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Frederik Ramm]

Hi,

On 07.05.2017 22:54, Nicolás Alvarez wrote:
> Yet I don't know of any such platform that has rules on how such
> metadata can be used, and I don't see anyone here arguing that we need
> rules on the use of mailing list archive metadata.

One thing at a time. Pascal's request for identifying yourself as an OSM
user is a tiny first step. Farther down that road there might be
conditions for the release of user-related information (e.g. "you can
get this info but you have to affirm that you won't abuse that"). Making
mailing list archives accessible to mailing list members only is also
something that Mailman offers out of the box and that we could one day
switch on if we like.

It is a common issue in OSM (and elsewhere) for people to use the status
quo as a reason. "Admin boundaries are not visible on the ground and
they are mapped, THEREFORE I can also map everything else that is not
visible on the ground" - no! And you're doing it the other way round,
saying "your privacy goes down the drain if you do anything online
anyway, so why should we at OSM take steps to protect it more".

Perhaps: because we can, and because it's a good thing?

Bye
Frederik

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

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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Nicolás Alvarez]

2017-05-05 6:59 GMT-03:00 Frederik Ramm :
> Today, if you are looking for a job and you're being interviewed by a
> potential employer, the potential employer could say: "I can see from
> OpenStreetMap that you've been editing a lot during the day in your last
> job. Did you not have any work to do?" - and the employer would not even
> be "wrong". Harvesting the full history file for totally OSM unrelated
> information like that is not against any of our rules; it might be
> against the law in some countries but certainly not in others. If you
> publicly complained about what happened to you, it is very likely that
> there will be many people like in this thread who will say "duh, you
> idiot why didn't you use a pseudonym, didn't you read what you signed up
> for, lah lah lah".
>
> I would like to come to a point where, if this happened to you in a job
> interview, you could afterwards point to an OSM policy and say: Clearly
> this company has violated OSM rules, they must have created an account
> under false pretenses to get at this data and they're using it for
> purposes not sanctioned by OSM. That won't make you get the job, but it
> would at least make clear that we stand with our contributors against
> abuse of their data.

This scenario is not specific to OSM map edits at all. They could also
use mailing list archives to see you have been arguing about OSM
tagging conventions during work hours. Or see that you have been
editing Wikipedia. Every web forum, mailing list, social network,
wiki, etc. that has usernames and timestamps would be "vulnerable" to
that.

Yet I don't know of any such platform that has rules on how such
metadata can be used, and I don't see anyone here arguing that we need
rules on the use of mailing list archive metadata.

-- 
Nicolás

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

Re: [OSM-talk-fr] Communes pratiquant l'extinction de l'éclairage public

[Paul Desgranges]

Bonsoir,
 Pour pouvoir mapper dans OSM les communes pratiquant l'extinction 
de l'éclairage public, j'ai documenté une proposition qui prend en 
compte un peu ce qui a été échangé sur cette liste talk-fr, et qui prend 
en compte aussi le format de déclaration que les sentinelles de l'ANPCEN 
 utilisent (si un jour on arrive à accéder à ces 
données !) et j'ai envoyé ça sur la la liste tagg...@openstreetmap.org.
   C'est ici 
https://wiki.openstreetmap.org/wiki/Talk:Key:lit#For_town_for_cities_with_lighting_plans_to_reduce_light_pollution 


C'est à approuver ou désapprouver ou commenter/améliorer etc,
merci
Paul
Le 06/05/2017 à 20:32, osm.sanspourr...@spamgourmet.com a écrit :


Le 05/05/2017 à 10:09, Nicolas Moyroud - nmoyr...@free.fr a écrit :

>>Concernant la collecte et le traitement des données par l'ANPCEN des villes et 
des villages pratiquant l'extinction totale ou partiellede leur 
éclairage public (environ 12 000 communes recensées)  ce travail 
représente pour notre association composée uniquement de bénévoles, 
un travail considérable que nous ne pouvons pas transmettre aux tiers.

C'est quand même hallucinant de lire des âneries pareilles !(...)

Nicolas


Bonnes réponses  Philippe (la première surtout)

> Pour l'ANPCEN, ils ont aussi peur que le "lobby de l'éclairage 
publique" exploite leur liste pour les contrer.


Tout comme la citation trouvée par Eric "??? Et on la trouve ou ??? Il 
me semblait que l'Anpcen ne communiquait pas ce genre de renseignement 
(ni son nombre d'adhérents) pour d'obscures raisons qui échappent à 
toute logique." en disant "C'est quand même hallucinant de lire des 
âneries pareilles !(...)" tu risques de les braquer. Pas exactement 
l'objectif.


C'est à nous de les convaincre de l'intérêt de la mutualisation.
Il existe déjà des carto mettant en évidence le lit=, à nous de leur 
demander un extrait de leurs données et d'en faire une umap.


> /OSM ne les aidera pas beaucoup dans leur travail militant, l'ANPCEN 
a certainement une expertise dans son domaine, elle traite des 
dossiers sur le sujet depuis longtemps et a un argumentaire et des 
contacts efficaces faire faire avancer leur plan d'action avant tout 
auprès des collectivités ou des exploitants de réseaux de transport, 
ou des assos de commerçants et des industriels./
Un peu quand même : on a des personnes qui, aux vues d'un extrait des 
données qu'ils vont nous passer ;-), vont leur proposer 
PublicLightningContrib ou une cartexyz pour contribuer à OSM et hop 
leur faire automatiquement via une umap une exploitation sympa des 
données.
C'est en affichant la cartes des communes non/peu polluées et en les 
valorisant qu'on arrivera à limiter la pollution lumineuse.
Si on pense qu'en rendant publique la liste des communes "propres" on 
va inciter les industriels à fourguer leur matériel, autant ne pas 
collecter l'info car un membre du lobby de l'éclairage peut devenir 
membre et récupérer la liste (ou elle est vraiment sectorisée pour que 
les adhérents ne connaissent que la carte autour de chez eux, par 
exemple au niveau du département, mais 100 adhésions à 10 € pour une 
boîte, ça se fait).
Au contraire s'il y a une appli permettant de renseigner facilement, 
potentiellement les contributeurs ne seront pas limités aux seuls 
membres de l'association.
Et si les gens choisissent une commune grâce à la carte, ils auront 
tendance à soutenir la politique d'éclairage du maire.


Peut-être leur signaler que des associations assez similaires 
(collectes de données sur le terrain) ont fait un choix différent 
comme les sites référençant les paratonnerres radioactifs ou non.
http://www.paratonnerres-radioactifs.fr/ (effet démo : erreur de 
connexion à la base de données, mais j'en avais fait une umap).


Hors OSM/carto mais sur l'éclairage public :
Dans un bulletin d'une petite commune du Finistère dont seul le bourg 
(la partie agglomérée) était éclairé, certains réclamaient l'éclairage 
public dans les hameaux, alors une personne a répondu dans le bulletin 
municipal qu'elle sortait comme d'autres avec une torche et qu'elle 
l'allumait seulement pour se faire voir des voitures ou s'il n'y avait 
pas de lune et que les autres marcheurs faisaient de même et donc 
aucune personne dans la rue à la nuit tombée ne réclamait d'éclairage 
public.
Elle en a déduit que l'éclairage public dans les hameaux serait fait 
pour que les gens qui ne sortent pas se regardent dormir.


Depuis je n'ai plus entendu parler de demande d'éclairage public.

Dans une commune du Morbihan, réunion d'accueil : le maire précise à 
une question que les hameaux ne sont pas éclairés. Plusieurs personnes 
approuvent ce choix.
Depuis les abris pour les car scolaires sont éclairés par des panneaux 
solaires (je n'ai pas regardé si c'était par détecteur de luminosité 
ou par horloge lit=yes me suffit ;-)).
Ce qui permet de ne pas écraser les enfants et ne nuit pas aux nuits 
étoilées.


Jean-Yvon

[Talk-cz] Zajímavé letecké mapy - Open flight Maps

[Michal Poupa]

Je geografický podklad z OSM? zdá se že ne

https://openflightmaps.org/live/ed-germany/?airac=1705=local
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-GB] Mapping Attenuation Ponds / Sustainable Drainage schemes

[Jez Nicholson]

The Council owned ponds/basins might be mapped in Environment Agency's
Flood Storage Areas, but Steve is more after private Sustainable Urban
Drainage Systems (SUDS). These may be difficult to spot, as they are often
landscaped ponds. AFAIK there isn't any register, but could possibly be
gleaned from planning permissions. I would welcome other info/thoughts.
This is part of what i do for my day job.

Regards,
   Jez

On Sun, 7 May 2017 17:35 Chris Hill,  wrote:

> [not cross posted]
>
> I have mapped some largish attenuation ponds as landuse=basin,
> basin=detention here http://www.openstreetmap.org/#map=16/53.7810/-0.4483
>
> These are specifically described by the council, who commissioned them, as
> flood alleviation. These are supposed to work by quickly filling during
> heavy rainfall and slowly emptying into the conventional drainage through a
> restricted outfall thus spreading out the rainfall and preventing flooding.
>
> --
> cheers
> Chris Hill (chillly)
>
>
> On 07/05/2017 17:22, Steve Brook wrote:
>
> Many new UK housing estates are required to be built with Attenuation
> Ponds / Sustainable Drainage schemes as part of their development. These
> are to control rain water runoff during storms and consist of a pond
> surrounded by an embankment with a controlled release structure to slow
> down drainage of the water to the river system.
>
>
>
> The relevant features might be
>
> · Low or normal water level of pond
>
> · High water level or top of embankment
>
> · Land use/vegetation between low/high water marks is water
> tolerant/marsh plants
>
> · Structures for water input and output – often brickwork and
> filter screens round a pipe.
>
>
>
> Has anyone any experience of mapping and tagging such a structure?
>
> Are there any examples of where this has been done?
>
>
>
> Steve
>
>
>
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Birmingham Tree Import

[Dan S]

Hi

Well, as a humble community member, IMHO most of the "tag problems"
listed at 

are indeed problems. (I have no comment on species/genus tagging
though.) Easy fixes:
- change "usrn" to "ref:usrn" as requested, and document its meaning
on the wiki;
- format "height" values in the common format as requested, or perhaps
"est_height" if only a range and not an exact value is known.
Both of those easy fixes will make it easier for people who weren't
involved in this import to make sense of the data.

A question: if "site_name" is indeed always a street, would it make
sense perhaps to import it as "addr:street"? I realise some people
might find this weird. I suggest it since it might make the semantics
a bit more obvious to people in future years trying to make sense of
the data, perhaps this as well as other imports from other datasets.

Best
Dan


2017-05-07 14:31 GMT+01:00 Andy Townsend :
> Anyone got any more comments about this import and the points raised below?
>
> We (the DWG) got a complaint about it at the time (and there were a lot of
> "not in my name" comments on this list and on IRC), but there don't seem to
> have been any further comments since 27th April.
>
> Best Regards,
>
> Andy
>
>
>
> On 27/04/2017 20:26, Brian Prangle wrote:
>
> Apart from some posts  about the problems with email notifications of
> changeset discussions, there has been nothing to indicate where I take this
> import. I guess that's because the initative is really down to me.
>
> I've annotated Harry's Import wiki page with some comments and ideas. I've
> copied below what I think are the relevant bits from the wiki page and I
> look forward to resolving the issues as I'm keen to complete the import.
>
> Extract from wiki page:
>
> So update approach is to be planned. This is not a requirement currently
> listed in the wiki imports guidelines. However it is good practice and the
> issue was raised with Amey and Birmingham City Council as soon as the data
> was released. Don't expect quick results!
>
> Import user problems: The import so far has been entirely uploaded by the
> brianboru user account. The size of the import was such that it should have
> been carried out by specially created OpenStreetMap user account. This
> guideline is in order to create another mechanism of
> separating/disentangling these edits from normal mapping
>
> Solution: dedicated import account created: brianboruimport
>
> Tag problems :
>
> Example imported tree
>
> http://www.openstreetmap.org/node/4721553869
>
> natural=tree source=bcc_dec_2016 form=Natural age=New Planting height=2 to
> 2.99m species=Liquidambar styraciflua 'Worpl usrn=2701986 plot_number=110007
> site_name=LUDGATE HILL ward=Ladywood constituency=City Centre
>
> Areas: ward, and constituency tags describe the area a tree is in. That is
> not a normal thing to do with tags on many nodes. A lot of data which
> ordinarily should be determined by a data user (if they require it) by
> geo-querying boundaries information. These tags will have a data update
> problems when the political boundaries change The local community decided
> some years ago not to add political boundaries, so there is currenty no
> other way of querying the tree data by this attribute. This will need
> revisiting once the boundary changes are in effect
> 'site_name' key which contains the street name written in all capitals. Did
> this need importing, and if so, did it have to be in capitals? Enables the
> average joe/jane to query data by street name. Is the use of capitals a
> problem apart from being ugly? Maybe searches are case-sensitive? The
> downoaded dateset used for import has been edited so that this field is
> "Properly Cased" so any new imports won't be affected. Can also bulk edit
> existing imported data
> 'usrn' appears to be an identifier (Unique Street Reference Number). The
> purpose for this should be documented. Perhaps local_ref or ref:usrn should
> have been used. usrn is indeed Unique Street Reference No. Its purpose is
> documented in the link and is a national standard for referencing streets.
> 'height' values are formatted in a non-standard way (See Key:height) Is this
> a problem? Not everything is recorded to a standard. If there is insistence
> on a standard then it can be fixed e.g by tagging the existing data as
> height:range and tagging with height =x where x= the nearest whole number at
> the upper end of the range
> species but no genus ? See example above which uses normal binomial name
> of genus and species (and includes in this case a cultivar)
>
> Regards
>
>
> Brian
>
>
> On 14 April 2017 at 17:24, ajt1...@gmail.com  wrote:
>>
>> On 13/04/2017 20:26, ael wrote:
>>>
>>> And none of the 3 suggested causes applies in my case.
>>
>>
>> What was the problem in your case?
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> 

Re: [Talk-GB] Mapping Attenuation Ponds / Sustainable Drainage schemes

[Ed Loach]

That seems to be what I settled on too, e.g. 
http://www.openstreetmap.org/way/189511931

 

Ed

 

From: Chris Hill [mailto:o...@raggedred.net] 
Sent: 07 May 2017 17:35
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Mapping Attenuation Ponds / Sustainable Drainage schemes

 

[not cross posted]

I have mapped some largish attenuation ponds as landuse=basin, basin=detention 
here http://www.openstreetmap.org/#map=16/53.7810/-0.4483

These are specifically described by the council, who commissioned them, as 
flood alleviation. These are supposed to work by quickly filling during heavy 
rainfall and slowly emptying into the conventional drainage through a 
restricted outfall thus spreading out the rainfall and preventing flooding.

-- 
cheers
Chris Hill (chillly)

 

On 07/05/2017 17:22, Steve Brook wrote:

Many new UK housing estates are required to be built with Attenuation Ponds / 
Sustainable Drainage schemes as part of their development. These are to control 
rain water runoff during storms and consist of a pond surrounded by an 
embankment with a controlled release structure to slow down drainage of the 
water to the river system.  

 

The relevant features might be

*   Low or normal water level of pond
*   High water level or top of embankment
*   Land use/vegetation between low/high water marks is water 
tolerant/marsh plants
*   Structures for water input and output – often brickwork and filter 
screens round a pipe.

 

Has anyone any experience of mapping and tagging such a structure? 

Are there any examples of where this has been done?

 

Steve

 






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





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

Re: [OSM-talk-fr] Label HQE

[Philippe Verdy]

Ce nest pas que déclaratif. Pour obtenir la reduction fiscale maximale il
faut faire certifier l'installation par un expert qui fait les mesures et
cela engage l'installateur aupres de son client á qui il a promis cette
installation conforme et qui devra corriger a ses frais si le test ne passe
pas. Ce nest pas linstallateur qui fait le test mais un expert independant


Le 6 mai 2017 17:24,  a écrit :

> Le label HQE c'est quelques points sur un ensemble (7 sur 14 actuellement
> en France), donc tu ne sauras pas s'il est bon sur tel ou tel critère.
>
> Donc ça ne montre pas bien les spécificités d'un bâtiment.
> De plus en France c'est du déclaratif, personne ne vérifie si les critères
> sont remplis effectivement (expertise post réalisation), idem pour la
> RT2012.
>
> Tu en déduiras ma réponse à l'intérêt de le marquer sur une carte.
>
> Jean-Yvon
>
> Le 06/05/2017 à 15:50, François Magimel - magimel.franc...@gmail.com a
> écrit :
>
> Bonjour,
>
> Je suis en train de cartographier une zone et je me demandais s'il y avait un 
> tag pour les bâtiments avec le label HQE [0] (je n'en trouve pas sur le 
> wiki). En effet, je trouve que ça montre bien les spécificités d'un bâtiment 
> (mais cela vaut-il le coup sur une carte ?).
>
> [0] https://fr.wikipedia.org/wiki/Haute_qualit%C3%A9_environnementale
>
>
> Merci beaucoup,
> François
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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-GB] Birmingham Tree Import

[Andy Mabbett]

On 7 May 2017 at 14:31, Andy Townsend  wrote:

> Anyone got any more comments about this import

JFDI.

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

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

[Talk-GB] Mapping Attenuation Ponds / Sustainable Drainage schemes

[Steve Brook]

Many new UK housing estates are required to be built with Attenuation Ponds
/ Sustainable Drainage schemes as part of their development. These are to
control rain water runoff during storms and consist of a pond surrounded by
an embankment with a controlled release structure to slow down drainage of
the water to the river system.  

 

The relevant features might be

. Low or normal water level of pond

. High water level or top of embankment

. Land use/vegetation between low/high water marks is water
tolerant/marsh plants

. Structures for water input and output - often brickwork and filter
screens round a pipe.

 

Has anyone any experience of mapping and tagging such a structure? 

Are there any examples of where this has been done?

 

Steve

 

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

hebdoOSM Nº 354 25/04/2017-01/05/2017

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 354 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver à:

http://www.weeklyosm.eu/fr/archives/9034/

Bonne lecture!

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

hebdoOSM Nº 354 25/04/2017-01/05/2017

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 354 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver à:

http://www.weeklyosm.eu/fr/archives/9034/

Bonne lecture!

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

hebdoOSM Nº 354 25/04/2017-01/05/2017

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 354 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver à:

http://www.weeklyosm.eu/fr/archives/9034/

Bonne lecture!

hebdoOSM? 
Qui?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[OSM-ja] OSM Access Mapのご紹介とご協力願い

[K.Sakanoshita]

坂ノ下です。

最近はマッピングパーティの告知ばかりですみません。
少し別のネタを作ったので、ご協力頂けますと幸いです。

OSMをもう少し簡単に扱うためのWebアプリを作りました。

[OSM Access Map]
https://www.netfort.gr.jp/~saka/accessmap/

[開発意図]
・Google Mapは規約上、印刷した紙は自分だけが使える。

・OpenStreetMapは印刷出来るけど、建物や店名などの
　不要な情報も印刷されてしまい、使い勝手が良くない。

そんな方向けに、「必要な道だけを画像に書き出しする」
Webアプリを作りました。（元データはOpenStreetMap）
※書き出した後、オフィスソフトで各種加工が出来ます。

学校に提出する登校ルート、地域の防災マップ以外にも、
お店やイベント会場への案内マップなどにも使えるはず。
※こんなことに使えるアイデアや活用事例を募集します。

最初のバージョンを作ったばかりなので、機能不足なども
あると思います。そこはご要望頂けますと幸いです。

それでは。

--
/*
 * K.Sakanoshita (http://www.netfort.gr.jp/~saka/)
 * (Phone) barsa...@gmail.com / (PC) s...@netfort.gr.jp
 */


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

Re: [OSM-talk-be] YES, we can trace the PICC (was: Using SPW PICC layer in josm)

[André Pirard]

Très long message...  Read throughout, up to the end absolutely! Highly
important!

Despite the explanation on SPW's site that PICC browsing & tracing is
public domain and the report from Julien Fastré, recalled by myself, of
what the PICC told him, the SPW would certainly not sue OSM for using
the PICC that way, vigilantes repeatedly say that the SPW could and they
threaten their mates with OSM exclusion and total contribution removal,
whatever the source.

This letter explains all that in greater detail.

On 2016-02-26 17:52, Glenn Plas wrote:
> On 26-02-16 14:23, Thib wrote:
>> Hi,
>>
>> SPW PICC tiles layer is available in JOSM for mapping Belgian Southern
>> area but I can't find enough information about the license terms.
>>
>> Is it allowed to :
>> - copy (doing"calc") buildings and other objects boundaries (as we do
>> with bing tiles)
>> - get address house numbers
>>
>> I've found some old threads talking about that interesting source but no
>> real answer...
>>
>> If someone has any information about it, It would be very useful.
>>
>> Thanks in advance.
>> Regards,
>>
>> Thib
> Reading their license, this is not open data as they restrict the reuse
> and retain the right to change the license later.  This data should not
> be used at all imho.  Now my french isn't that great on the legal
> vocabulary notes, and correct me if I'm wrong, but it doesn't look good
> to me:
>
> http://geoportail.wallonie.be/files/documents/ConditionsSPW/DataSPW-CGU.pdf
>
> http://geoportail.wallonie.be/files/CopieDataSPW-CGA.pdf
>
> http://geoportail.wallonie.be/files/documents/ConditionsSPW/DataSPW-CGU.pdf
>
> For data to be OSM-fit, you need a compatible license like GRB and AGIV
> have.
You simply looked at the wrong files.
> So, unless someone claims i'm wrong, we should not use this at all, if
> you do... and a claim is made, that data will be removed from OSM by
> analysing the user names involved and their changesets.
It's amazing how many OSM contributors threaten their mates based on
superficial facts or © analysis (1).
Think twice.  The danger is that the SPW could complain about OSM ("a
claim"), isn't it?
What could be the problem if they say they will not?
You simply misunderstood their "access rights" and I "claim that you're
wrong" indeed !!!
> I'll be ignoring Lionel's follow-up and act like I didn't read it at all ...
>
> Glenn
On 2016-03-02 09:39, Glenn Plas wrote:
> Hi,
>
> Apparently it's not clear enough
Obviously, and I'm going to try to make it clear.
> You can't use it.  It's not a matter of opinion nor I care what certain
> persons from PICC said to someone else I don't really know.  I should
> not care either, because that's what licences are for.  They show me in
> clear language what can and cannot.
Is it important that you knew Julien Fastré as well as everybody does,
and the person he talked to and who explained on behalf of SPW Carto
that only copying the PICC is licensed and that OSM does not copy it. 
The license regarding what we do is "public domain" (explained below).
What could be the problem?
> It's really simple, you check the license.  I'm not having the
> discussion on what exactly copying data is (or isn't).  
Obviously, if you refuse to understand what the word "copy" means, you
will not understand the word "copyright".
> I was quite
> clear on it:  you can only copy data over with compatible licenses. We
> all know what making a copy is in 2016.
No, nobody knows before having understood or asked the copyright owner
what he means with "copy" (1).
And many self-appointed vigilantes do not even do that.
> I'm almost pulling out my hair btw, because you're not making the
> correct conclusions.
>
> You can NOT copy from data sources with incompatible licenses, having a
> high five from someone at PICC does not count as a license.
>
> Glenn

What "copying" means and what can be done by "tracing" is rather clearly
defined in the Conditions on their site
.
With PICC, one can do two things (see the titles of the Web page):

  *


  Obtenir une copie de la donnée (= get a copy of the data)

that is *copying* (downloading files) and the conditions are:
  o Conditions générales d’accès à l’obtention d’une copie numérique
des données géographiques numériques du Service public de
Wallonie


  o Conditions particulières d’accès  à l’obtention d’une copie
numérique d’une donnée géographique numérique du Service public
de Wallonie –Type B1


  o Conditions générales d’utilisation des données géographiques
numériques du Service public de Wallonie


  o *that is a pay license 

[OSRM-talk] Problem solved

[Wojciech Tomczak]

Hi,
The problem for me was solved. Apparently the source of the problem was the 
server itself.

Thank You, Best regards
Wojciech Tomczak








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

Re: [Talk-GB] Birmingham Tree Import

[Andy Townsend]

Anyone got any more comments about this import and the points raised below?

We (the DWG) got a complaint about it at the time (and there were a lot 
of "not in my name" comments on this list and on IRC), but there don't 
seem to have been any further comments since 27th April.


Best Regards,

Andy


On 27/04/2017 20:26, Brian Prangle wrote:
Apart from some posts  about the problems with email notifications of 
changeset discussions, there has been nothing to indicate where I take 
this import. I guess that's because the initative is really down to me.


I've annotated Harry's Import wiki page 
 
with some comments and ideas. I've copied below what I think are the 
relevant bits from the wiki page and I look forward to resolving the 
issues as I'm keen to complete the import.


Extract from wiki page:

So update approach is to be planned. /*This is not a requirement 
currently listed in the wiki imports guidelines. However it is good 
practice and the issue was raised with Amey and Birmingham City 
Council as soon as the data was released. Don't expect quick results!*/


*Import user problems*: The import so far has been entirely uploaded 
by the brianboru  user 
account. The size of the import was such that it should have been 
carried out by specially created OpenStreetMap user account. This 
guideline is in order to create another mechanism of 
separating/disentangling these edits from normal mapping


/*Solution: dedicated import account created: brianboruimport 
*/


*Tag problems* :


  Example imported tree

http://www.openstreetmap.org/node/4721553869

natural =tree

source =bcc_dec_2016
form

=Natural
age

=New
Planting
height =2 to 2.99m
species
=Liquidambar
styraciflua 'Worpl
usrn

=2701986
plot_number

=110007
site_name

=LUDGATE
HILL
ward

=Ladywood
constituency

=City
Centre

  * Areas: ward, and constituency tags describe the /area/ a tree is
in. That is not a normal thing to do with tags on many nodes. A
lot of data which ordinarily should be determined by a data user
(if they require it) by geo-querying boundaries information. These
tags will have a data update problems when the political
boundaries change /*The local community decided some years ago not
to add political boundaries, so there is currenty no other way of
querying the tree data by this attribute. This will need
revisiting once the boundary changes are in effect*/
  * 'site_name' key which contains the street name written in all
capitals. Did this need importing, and if so, did it have to be in
capitals? /*Enables the average joe/jane to query data by street
name. Is the use of capitals a problem apart from being ugly?
Maybe searches are case-sensitive? The downoaded dateset used for
import has been edited so that this field is "Properly Cased" so
any new imports won't be affected. Can also bulk edit existing
imported data*/
  * 'usrn' appears to be an identifier (Unique Street Reference Number
). The
purpose for this should be documented. Perhaps local_ref or
ref:usrn should have been used. /*usrn is indeed Unique Street
Reference No. Its purpose is documented in the link and is a
national standard for referencing streets.*/
  * 'height' values are formatted in a non-standard way (See
Key:height ) /*Is
this a problem? Not everything is recorded to a standard. If there
is insistence on a standard then it can be fixed e.g by tagging
the existing data as height:range and tagging with height =x where
x= the nearest whole number at the upper end of the range*/
  * species but no genus /*? See example above which uses normal
binomial name of genus and species (and includes in this case a
cultivar)*/

Regards


Brian


On 14 April 2017 at 17:24, ajt1...@gmail.com 
 > 

Re: [Talk-pt] Talk-pt Digest, Vol 90, Issue 2 - Como mapear as florestas do sul?

[Rui Reino Baptista]

Como mapear as florestas do sul?

Caro Carlos Oliveira,

P.f. dá uma vista de olhos a
https://wiki.openstreetmap.org/wiki/Proposed_features/meadow%3Dwooded_meadow

RB

On Sun, May 7, 2017 at 1:00 PM  wrote:

> Send Talk-pt mailing list submissions to
> talk-pt@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-pt
> or, via email, send a message with subject or body 'help' to
> talk-pt-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-pt-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-pt digest..."
>
>
> Today's Topics:
>
>1. Como mapear as florestas do sul? (Marcos Oliveira)
>
>
> --
>
> Message: 1
> Date: Sat, 6 May 2017 14:35:39 +0100
> From: Marcos Oliveira 
> To: "Lista de discuss,o para Portugal"
> 
> Subject: [Talk-pt] Como mapear as florestas do sul?
> Message-ID:
> 

[OSRM-talk] Question Service Route

[Ing. Luis Alberto Rodriguez]

Hello everyone,

I try to use the services and it looks like they are down. Or am I doing 
something wrong myself? I try to see some examples and there is no answer.

Can anyone help me by indicating what I can do? Thanks greetings.



Ing. Luis Alberto Rodriguez

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

Re: [Talk-it] problemi da niubbi

[girarsi_liste]

Il 07/05/2017 12:15, frali...@alice.it ha scritto:
> Buongiorno,
> 
> sono un ..anta avanzato, e per via dei miei trascorsi conosco i problemi 
> della navigazione, quindi leggere delle carte ho pochi problemi, ma OSM  e 
> sopratutto leggere questa mail- list mi ha posto il problema da un'altra 
> visuale: costruire le carte, prospettandomi un mondo, che anche se ne ho 
> sentito parlare,  in realtà disconosco, ovvero i GIS ed i software gis.
> andiamo al dunque, avete qualche suggerimento,un qualcosa da leggere per chi 
> a livello hobbistico vorrebbe saperne di più sui gis e sui suoi  software?
> 
> ringrazio in  anticipo
> 
> 

Se ti interessa il lato "libero" direi di partire da qui:

http://www.gfoss.it/index.php/software-gis


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



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

[Talk-it] problemi da niubbi

[frali...@alice.it]

Buongiorno,

sono un ..anta avanzato, e per via dei miei trascorsi conosco i problemi della 
navigazione, quindi leggere delle carte ho pochi problemi, ma OSM  e sopratutto 
leggere questa mail- list mi ha posto il problema da un'altra visuale: 
costruire le carte, prospettandomi un mondo, che anche se ne ho sentito 
parlare,  in realtà disconosco, ovvero i GIS ed i software gis.
andiamo al dunque, avete qualche suggerimento,un qualcosa da leggere per chi a 
livello hobbistico vorrebbe saperne di più sui gis e sui suoi  software?

ringrazio in  anticipo


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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[moltonel]

On 4 May 2017 22:33:47 IST, Frederik Ramm  wrote:
>It doesn't matter that anyone can sign up and then view that data; we
>can at least make people promise to only use the data for project
>internal use when they sign up.


While I'm not looking forward to having to login to use various tools, I 
understand that it might be a step in the right direction for privacy-sensitive 
contributors.

But seeing how low this new barrier is, I don't think that we should advertise 
it as a privacy-preserving feature, because it'll give a false sense of 
security to the very users we are trying to help.

It's also annoying that it migh increase "contribution-less account bloat", but 
that's something we have to live with anyway.

I'd be more interested in annonymising features like a "randomize changeset and 
gpx timestamps a bit" account setting and providing a best-effort "delete my 
account and as much data as you can" button. These are more invasive and 
complicated than "login to see usernames" but they would be much more useful.

-- 
Vdp
Sent from a phone.

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

Re: [talk-au] Mobile phone towers

[Marc Gemis]

You could add the operator tag to indicate the owner.

regards

m

On Sun, May 7, 2017 at 7:24 AM, Graeme Fitzpatrick
 wrote:
> Hi
>
> Just putting a nearby newish mobile tower on the map.
>
> Due we worry about naming who's tower it is?
>
> Couldn't see anything in the wiki about it.
>
> Thanks
>
> Graeme
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

[OSRM-talk] Problem with route road

[Wojciech Tomczak]

I'm sorry I did not mean it - "works on another thread than the UI" but that is 
used on a another thread than the UI



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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Jo]

2017-05-07 9:30 GMT+02:00 Paul Johnson :

> On Sun, May 7, 2017 at 2:25 AM, Jo  wrote:
>
>> What about a type=traffic_sign relation?
>>
>> Where traffic_sign could be stop, give_way, parking
>>
>
> I was thinking the typical highway=* tags for highway=stop,
> highway=traffic_signals and highway=give_way.
>
>
>> In case of a stop sign, we could include the sign on a node, role 'sign'.
>> The node of the intersection, maybe role 'to'. The way the vehicle is
>> approaching from, maybe role 'from'.
>>
>
> Yes, that's what I'm suggesting.
>
>
>> In case of parking it would make very clear on which ways there is
>> parking and we would have central place to keep track of the conditions
>> like "opening_hours" and tariffs, or specific requirements like permits.
>>
>
> Parking already has a very clear case of way tagging for this.
>

To map the effect on the road network, I agree. To relate the traffic signs
to those ways, we don't. I don't know if we'll be able to map all traffic
signs and include all these relations (and keep them up-to-date), but then
I also wasn't sure we´d be able to put entire countries on the map like we
did, only ust a few years ago. It would be good to have a well thought out
plan, so we can start doing it consistently.

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

[OSRM-talk] Problem with route road

[Wojciech Tomczak]

Dnia Niedziela, 7 Maja 2017 09:24 Wojciech Tomczak  
napisał(a) 
Sorry, I'm in haste with explanations. I thought maybe this is a problem with 
the server because finding a route is not even via the portal. I am using the 
API on android after implementing the osmbonuspack_v6.3 library. When trying to 
use code:
___

Log.e("ROAD!","START");
RoadManager roadManager = new OSRMRoadManager(CApplication.getContext());
Road hRoad = roadManager.getRoad(aGeoList);
Log.e("ROAD!","END");

CWayRouteRoad.CGeoList hGeoList = new 
CWayRouteRoad.CGeoList(RoadManager.buildRoadOverlay(hRoad).getPoints());
CWay hWay = new CWayRouteRoad(Color.RED, 2, 700, hGeoList, iCurrentZoom, 
hScreenBBox, "Route Road");
hOverlay.AddWay(hWay, "Route Road");

 
___
 mStatus == 2, which corresponds Road.STATUS_TECHNICAL_ISSUE.
 I gets in logs:


 05-07 09:04:46.118 9835-10357/com.studiosoftek.wt.OSMMap D/BONUSPACK: 
OSRMRoadManager.getRoads:http://router.project-osrm.org/route/v1/driving/14.573750495910645,53.53826712239718;14.551048278808594,53.54313810202354?alternatives=false=full=true.
__

Of course it works on another thread than the UI. After copying the URL to the 
browser gets Error 504. 
So the problem is that it does not return points beyond the ones I gave myself.
Thank you for the reply. I first ask the question publicly and I am happy to be 
able to communicate.

 

Wojciech Tomczak




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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Paul Johnson]

On Sun, May 7, 2017 at 2:25 AM, Jo  wrote:

> What about a type=traffic_sign relation?
>
> Where traffic_sign could be stop, give_way, parking
>

I was thinking the typical highway=* tags for highway=stop,
highway=traffic_signals and highway=give_way.


> In case of a stop sign, we could include the sign on a node, role 'sign'.
> The node of the intersection, maybe role 'to'. The way the vehicle is
> approaching from, maybe role 'from'.
>

Yes, that's what I'm suggesting.


> In case of parking it would make very clear on which ways there is parking
> and we would have central place to keep track of the conditions like
> "opening_hours" and tariffs, or specific requirements like permits.
>

Parking already has a very clear case of way tagging for this.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cz] Co fotit a kam s fotkama? - Re: Mapovaci prace pro studenty - kde by mohli pomoci?

[Miroslav Suchý]

Dne 7.5.2017 v 07:24 Pavel Zbytovský napsal(a):
> Včera jsem nasadil novou verzi - stačí nyní na osmap.cz
>  zapnout vrstvu "Foto rozcestníků" a vpravo nahoře se
> ukáže ikonka pro nahrávání fotek.
> 

Super!
Muzes prosim tu ikonu zobrazit i kdyz zapnu pouze vrstvu "Chybne
rozcestniky"?


Mirek

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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Jo]

What about a type=traffic_sign relation?

Where traffic_sign could be stop, give_way, parking.

We can put a traffic_sign tag on nodes, where they get the
country_code:specific_national_code like BE:C1. Several traffic signs can
have an effect on several ways and nodes of the road network, so we could
group them in such relations.

In case of a stop sign, we could include the sign on a node, role 'sign'.
The node of the intersection, maybe role 'to'. The way the vehicle is
approaching from, maybe role 'from'.

In case of parking it would make very clear on which ways there is parking
and we would have central place to keep track of the conditions like
"opening_hours" and tariffs, or specific requirements like permits.

Polyglot


2017-05-07 8:57 GMT+02:00 Paul Johnson :

> I think it's time that we seriously reconsider how stop signs, yield signs
> and traffic calming devices are handled in all but the most simple (all
> approaches to the affected node apply) cases.  This largely after having a
> protracted discussion with one person about nodes lacking direction and
> this being a big factor in turn restrictions and enforcement being handled
> by relations already (and really, the entire reason relations were
> introduced in the first place).
>
> I'm thinking it's time to start mapping this similar to how we handle
> enforcement and turn restrictions, ie, with relations, for all but the
> simplest of cases, especially since the whole forward/backward direction=*
> thing is nonapplicable to nodes by design.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Paul Johnson]

On Sun, May 7, 2017 at 2:12 AM, Nicolás Alvarez 
wrote:
>
> Do you know of a case where you would have a traffic calming device
> only affecting one direction, but not already have a reason to map
> each road direction as a separate way?
>

Somewhat commonly.  Oklahoma and Texas have a strong tendency to set down
at least three sets of rumble strips on approach to a traffic light, stop,
give_way or the side way of a T intersection when the speed limit is 55 or
faster.  Oklahoma Turnpike Authority also uses rumble strips to warn of the
toll plaza on the state's only undivided turnpike.


> I agree about the signs though. Relations add complexity, but I don't
> see how else to handle that kind of directional signs...
>

This is a problem that can be solved via editors.  id and JOSM both have
excellent editors for turn restrictions that could likely be readily
extended to handle enforcement, traffic calming, stop, yield and
nonstandard traffic signal cases (and clean up traffic signal situations on
SPUI interchanges, dual carriageways and other "messy" traffic light
situations that get mapped as multiple ways intersecting but are handled by
a single assembly of traffic lights or an interlocking pair of traffic
lights as functionally a single intersection).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Nicolás Alvarez]

2017-05-07 3:57 GMT-03:00 Paul Johnson :
> I think it's time that we seriously reconsider how stop signs, yield signs
> and traffic calming devices are handled in all but the most simple (all
> approaches to the affected node apply) cases.  This largely after having a
> protracted discussion with one person about nodes lacking direction and this
> being a big factor in turn restrictions and enforcement being handled by
> relations already (and really, the entire reason relations were introduced
> in the first place).
>
> I'm thinking it's time to start mapping this similar to how we handle
> enforcement and turn restrictions, ie, with relations, for all but the
> simplest of cases, especially since the whole forward/backward direction=*
> thing is nonapplicable to nodes by design.

Do you know of a case where you would have a traffic calming device
only affecting one direction, but not already have a reason to map
each road direction as a separate way?

I agree about the signs though. Relations add complexity, but I don't
see how else to handle that kind of directional signs...

-- 
Nicolás

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

[OSM-talk] Revisiting traffic control and traffic calming

[Paul Johnson]

I think it's time that we seriously reconsider how stop signs, yield signs
and traffic calming devices are handled in all but the most simple (all
approaches to the affected node apply) cases.  This largely after having a
protracted discussion with one person about nodes lacking direction and
this being a big factor in turn restrictions and enforcement being handled
by relations already (and really, the entire reason relations were
introduced in the first place).

I'm thinking it's time to start mapping this similar to how we handle
enforcement and turn restrictions, ie, with relations, for all but the
simplest of cases, especially since the whole forward/backward direction=*
thing is nonapplicable to nodes by design.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk