[Talk-ca] Building Canada 2020 (BC2020i) Microsoft has released 120, 000, 000 building outlines for the US

2018-07-12 Per discussione john whelan
I'm not sure what the implications are but hopefully they'll do Canada soon.

OSM-weekly.

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


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione yasunori kondoh
近藤(yasu747)です。

私の意見としては、name:ja-Latn に使う変換テーブルが指定されていないので、name:ja-Hira
は同一であるとは見なせない。これに関しては現状ママでよいのでは。

さて現地調査で「大手町  Otemachi」という標識を見つけたら、どうtaggingするかで、japan_tagging の注記を見る限り、
name:en =Otemachi なのですね。私の使い方が間違っていたかも。

2018年7月12日(木) 23:13 Leo Gaspard :

> レオです。
>
> [1]の「ūやōなどのマクロン付きの文字を使用する」によると、「大手町」の正しいタグは「name:ja-Latn=Ōtemachi,
> name:en=Otemachi」だと思いますから、それは問題ありませんと思っております。
>
>
> その上、もし「name:ja-Furi」のようなタグがよかったら、「name:ja-Furi」でも「name:ja-Hira」を計算することが易しくできます。「大手町[おおてまち]」から「おおてまち」まで、それとも「彼[かれ]の
> 脳[のう]」から「かれののう」まで(スペースを使って漢字とかっこを消します)
>
> 「name:ja-Furi」から「name」も計算できますが、「name」のタグにAnki-style
> furiganaを入れるのがちょっと違うかもしれません。
>
> [1] https://wiki.openstreetmap.org/wiki/Japan_tagging#Names
>
>
> On 07/12/2018 09:38 PM, yasunori kondoh wrote:
> > 近藤(yasu747)です。
> >
> > ひらがなとローマ字表記は変換テーブルによっては1対1で変換可能ではないと思います。
> > たとえば、交差点・道路標識でよくみられる「大手町」「Otemachi」。
> > 「おてまち」なのか「おおてまち」なのか知っている地元の人が、ja-Hira を使うのは有用かもしれません。
> >
> > 2018年7月12日(木) 1:15 Leo Gaspard :
> >
> >> 皆様
> >>
> >>
> >>
> ちょっと質問があります。「ja-Latn」と「ja-Hira」は同じ情報を伝えませんか。ですから、ふりがなができるように「ja-Hrkt」(平仮名もカタカナもできるコード)を使おうとしましたが、それも完璧ではありません。例えば、「彼の脳」と「かれののう」で「彼(かれ)の脳(のう)」だけでなく、「彼(かれの)の脳(う)」も作ることができます。
> >>
> >> そのため、ja-AnkiStyleFurigana
> >> (ja-Furi?)のタグは一番いいと思います。そのフォーマットで、前の例はこのように書きます。「ja-Furi=彼[かれ]の
> >> 脳[のう]」(スペースは必要があります。スペースがなければ、Ankiは「の脳」の上に「のう」を書きます)
> >>
> >> そして、そのような「name:ja-Furi」から全て計算できます。ところが、日本語に向いていないUIのため、「name
> >> / name:ja」も記入するのがもっといいと思います。
> >>
> >> (Ankiはhttps://ankisrs.netで、そのプログラムで日本語の言葉を勉強するために、そのように書きます)
> >>
> >>
> >>
> ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。
> >>
> >> それは自分の考えだけです。
> >> レオ
> >>
> >> ___
> >> 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
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione Satoshi IIDA
いいだです。

えっと、ローマ字には2種類あって、現在、OSMのタグづけではどちらを使うか、統一されていないという認識です。

ヘボン式: [東京 / とうきょう / Tokyo], [大阪 / おおさか / Osaka]
訓令式: [東京 / とうきょう / Tokyō], [大阪 / おおさか / Ōsaka]

個人的には、ローマ字の表記は国土地理院の方式に従うとよいのじゃないかな、と思っています。
この場合、ヘボン式になります。(これの別紙1の表)
http://www.gsi.go.jp/common/000138865.pdf

経緯とかはこちらが詳しいです (2005年の文書): http://www.gsi.go.jp/common/24858.pdf

もちろん、OSM上では訓令式を使って値が記載されていることも多く、
訓令式も実際に省庁で使われていますので、どちらが悪いというわけではありません。

また、ローマ字表記が、ひらがな表記と完全に1体1で対応するものではないことも、他のみなさんが指摘されているとおりです。
なので、ja-Latn と ja-Hira は両立(どちらも残す)するほうがよいのかな、と考えています。


ja-Furiは、調べる限りそれなりに記法が成熟していて面白い試みだとは思うのですが、
Hiraを残すと考えると、新しく設定しなくてもいいのかなぁ、という気がします。
いまのところ、消極的反対、というところです。



2018年7月13日 1:47 Takahisa TAGUCHI :

> 田口です。
>
> > [1]の「ūやōなどのマクロン付きの文字を使用する」によると、「大手町」の正しいタグは「name:ja-Latn=Ōtemachi,
> > name:en=Otemachi」だと思いますから、それは問題ありませんと思っております。
>
> わたしも最初はマクロン付き文字でカバーできるかなと思っていたのですが、
> よくよく考えると長音の「おう」と「おお」はどちらも ō となってしまうので
> やはりひらがな表記は必須になってくるかと思います
>
> 例)
>  東京 / とうきょう / Tokyō
>  大阪 / おおさか / Ōsaka
>
> ルビを振ることを想定し、ふりがな用のタグを用意するのはよい意見だとは
> 思うのですが、既存の name:ja-Hira を非推奨にしてまで一つに統合する
> 必要性も感じられず、もし需要があるのであれば name:ja-Furi のような
> タグの新設を議論する方向がよいのかなと個人的には思うのですが、
> いかがでしょうか。
>
>
>
> On 2018/07/12 23:11, Leo Gaspard wrote:
>
>> レオです。
>>
>> [1]の「ūやōなどのマクロン付きの文字を使用する」によると、「大手町」の正しいタグは「name:ja-Latn=Ōtemachi,
>> name:en=Otemachi」だと思いますから、それは問題ありませんと思っております。
>>
>> その上、もし「name:ja-Furi」のようなタグがよかったら、「name:ja-Furi」でも「name:ja-
>> Hira」を計算することが易しくできます。「大手町[おおてまち]」から「おおてまち」まで、それとも「彼[かれ]の
>> 脳[のう]」から「かれののう」まで(スペースを使って漢字とかっこを消します)
>>
>> 「name:ja-Furi」から「name」も計算できますが、「name」のタグにAnki-style
>> furiganaを入れるのがちょっと違うかもしれません。
>>
>> [1] https://wiki.openstreetmap.org/wiki/Japan_tagging#Names
>>
>>
>> On 07/12/2018 09:38 PM, yasunori kondoh wrote:
>>
>>> 近藤(yasu747)です。
>>>
>>> ひらがなとローマ字表記は変換テーブルによっては1対1で変換可能ではないと思います。
>>> たとえば、交差点・道路標識でよくみられる「大手町」「Otemachi」。
>>> 「おてまち」なのか「おおてまち」なのか知っている地元の人が、ja-Hira を使うのは有用かもしれません。
>>>
>>> 2018年7月12日(木) 1:15 Leo Gaspard :
>>>
>>> 皆様


 ちょっと質問があります。「ja-Latn」と「ja-Hira」は同じ情報を伝えませんか。ですから、ふりがなができるように
 「ja-Hrkt」(平仮名もカタカナもできるコード)を使おうとしましたが、それも完璧ではありません。例えば、「
 彼の脳」と「かれののう」で「彼(かれ)の脳(のう)」だけでなく、「彼(かれの)の脳(う)」も作ることができます。

 そのため、ja-AnkiStyleFurigana
 (ja-Furi?)のタグは一番いいと思います。そのフォーマットで、前の例はこのように書きます。「ja-Furi=彼[かれ]の
 脳[のう]」(スペースは必要があります。スペースがなければ、Ankiは「の脳」の上に「のう」を書きます)

 そして、そのような「name:ja-Furi」から全て計算できます。ところが、日本語に向いていないUIのため、「name
 / name:ja」も記入するのがもっといいと思います。

 (Ankiはhttps://ankisrs.netで、そのプログラムで日本語の言葉を勉強するために、そのように書きます)


 ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから
 、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。

 それは自分の考えだけです。
 レオ

 ___
 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

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



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


Re: [OSM-talk-fr] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)

2018-07-12 Per discussione François Lacombe
*Hello Deuzeffe,*

Le 12 juillet 2018 à 20:07, deuzeffe  a écrit :

> Bonjour,
>
> Les jeux de données ouvertes disponibles étant peu bavards, la collecte
>> d'informations de terrain a une valeur importante,
>> démontrant si il le fallait encore la pertinence d'OSM.
>>
>
> Bilan à mi-course de mes crapahutes de transfo. en transfo. :
> - ceux sur poteau ont un nom ;
> - beaucoup de ceux en building ou street_cabinet n'ont qu'un nom (et pas
> de réf) ;
> - j'ai trouvé :
> -- des buildings référencés dans la base Enedis* non cadastrés ;
> -- des buildings cadastrés non référencés dans la base ;
> -- des buildings sans nom ni référence visible sur leur plaque
> d'identification non référencés dans la base;
>

Comme quoi ca ne sert pas qu'à l'inventaire des réseaux elec, le bâti se
prend un petit coup de ménage par endroits.
La ref des postes peut ne pas être affichée sur le terrain, elle existe
dans tous les cas néanmoins. Il faudra qu'Enedis la libère, ou l'affiche.


>
> RdV à la fin du mois pour l'avancement des travaux ;) À ce propos, on
> pourrait avoir une chtite mise à jour de
> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/
> postes_electriques#Statistiques_et_participation
> ?
>
Le suivi est à jour d'hier, pour l'instant 2 700 postes édités depuis début
Juin !

*Si comme moi, vous prononcez Énédis, tagguer avec Enedis doit froisser
> votre fibre orthotypo. :(


Il faut partir du principe que c'est un mnémonique, sans accent ni espaces
c'est mieux
Même si les valeurs doivent être lisibles par l'homme, la machine aime bien
quand on lui mâche le travail

Bonne soirée

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


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione tomoya muramoto
(1)ja-Hira, ja-Kana, ja-Latnの統一について
田口さんがご指摘されたとおり、ひらがな(片仮名)とローマ字の互換性は完全ではないので、どちらか一方だけでよいことにはなりません。重複しても問題ないと考えます。
マッパーの視点から言えば、日本人マッパーは「かな」で入力するのが容易でしょう。一方、外国人利用者は、ローマ字で入力されていたほうが利用しやすいでしょう。データ処理ソフト側で適切に処理してほしい案件です。

(2)ja-Furiの新設について
必ずしも反対するものではありませんが、慎重にしたいです。
「彼の脳」は「かれののう」と読むのであって、「かれ-の-のう」であるのか「かれの-の-う」であるのか、地図利用の観点からはどっちでも構いません。OSMは日本語の読み方を学ぶ場ではありません。
もし新設を提案される場合は、公的なフォーマットで提案していただくようお願いします。"Anki"がどのような団体なのかよくわかりませんでした。

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


Re: [OSM-ja] 住所 (was: Re: ローマ字)

2018-07-12 Per discussione tomoya muramoto
レオ様

お返事いただきありがとうございます。

>「name=2」については、JOSMのプリセットのために、必要です。
なるほど。ではJOSMのプリセットが不適切なんでしょうね。ref=2は良い形かもしれません。

>place=city_block, admin_level=11
日本のタグ体系を大きく変更する提案になるので、多くの人のご意見を待ちたいと思います。

>番地の区画の調べ方。
ありがとうございます。足で調べたのですね。お疲れ様です。逆に言うと、番地区画のマッピングはそれだけ大変ということなのですね。

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


Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

2018-07-12 Per discussione OSM Volunteer stevea
On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> Damien's question appears to be about nodes like
> https://www.openstreetmap.org/node/438843513, which has
> name=Berri-UQAM, operator=Société de transport de Montréal.
> short_name=STM seems inappropriate here, we could do
> operator:short_name=STM or something but it seems a bit much.

Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
that operator:short_name=STM is a bit of "overkill" (getting over-specific on 
the key side).

> The nearby station https://www.openstreetmap.org/node/26233453 has
> name=Jean-Drapeau, network=STM, operator=Société de transport de
> Montréal which seems like an attempt as good as we might get. Commuter
> rail station https://www.openstreetmap.org/node/548900549 has
> network=RTM, operator=Réseau de transport métropolitain which fits
> that scheme as well. Similar with a random bus line on North Shore
> https://www.openstreetmap.org/relation/3472432

I find that operator=* is a key which certainly applies to "underlying rail 
infrastructure" objects (railway=rail), especially when the rail is 
freight-oriented, though I have also seen operator=* set to the value of the 
passenger operator when the underlying infrastructure is one of 
[railway=light_rail, railway=subway, railway=tram] on more passenger-oriented 
rail.  Though, I seem to recall more frequently (I'd have to do some Overpass 
Turbo queries to confirm this) network=* is applied to the passenger (not 
freight) elements instead of operator=*, both are used, both seem correct.

Without getting "lost in the weeds," there are/were three "levels" of railway 
route relations:  #1 is/used to be route=tracks (largely if not completely 
deprecated in North America, but maybe still used in Germany), #2 is 
route=railway (a grouping of what we in N.A. call "Subdivisions" or "Branches" 
or "Industrial Lines") and #3 is route=train relations for passenger rail.  We 
can (and do) have passenger rail as route=train relations all over N.A. withOUT 
the "underlying infrastructure" of route=railway relations, but I, others and 
indeed OSM consider this incomplete and rather sloppy.  The Germans use all 
three (or did).  The Bottom Line for what we in N.A. should do is to use BOTH 
of the "middle-" (#2, route=railway) and #3 "higher-" level (route=train) 
relations to describe "track infrastructure" and "passenger rail routes."  OK, 
thanks for reading all that, it makes a better OSM.

> Looking through map very casually I didn't see any operator=STM on the
> subway. I did see it on a bus line
> https://www.openstreetmap.org/relation/270258 but changing it to
> network=STM and operator=Société de transport de Montréal seems like
> it'd be fine there IMO.

Yes, again, I agree.

> To me "operator" looks a bit more little technical than the other
> tags, so to me it would be alright to use the longer more formal name.
> But I wouldn't edit-war anyone about it. I'd say run a query, see
> which is more common currently, ask people here (as you've done), then
> after a week change the minority tags to match.

You saying "more technical" might be agreeing with me that operator=* is at a 
"lower/middle level" (infrastructure on track, not "higher level" as applied to 
the different relation of route=train for passenger rail).  So I think we are 
largely in agreement:  if you (and Canada) want to move into the direction of 
putting operator=* on freight rail (and maybe sometimes passenger rail), yes, 
that seems correct.  If you additionally want to use the network=* key for, in 
this example, STM, yes, that makes perfect sense to me as well.  So does your 
suggestion/approach of "run a (OT) query...change minority tags to match."

Thank you for good discussion,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-12 Per discussione Stéphane Péneau

Le 12/07/2018 à 22:22, osm.sanspourr...@spamgourmet.com a écrit :


Il y a quand même la référence de la voie qui l'indique.

CE= Chemin d'Exploitation, pas Chemin Écolo pour vélos, car comme 
deuzeffe le fait remarquer, sinon il y aurait un accent ;-).


Pour moi, chemin empierré où le passage de véhicules de particuliers 
est exceptionnel. On s'y croise difficilement (en mordant sur les bas 
côtés pour ne pas dire les champs).


Pas du 100 % mais pas loin.


Tiens, c'est pour tes 0.1% :-)

https://www.mapillary.com/map/im/pJ1RNDTgfFCUZXAvfJorqg
https://www.mapillary.com/map/im/0vCMhbMm6JOnTrexHjlQQg

Et il y en a d'autres dans le coin.
J'ai choisi
highway=track
tracktype=grade1
access=agricultural

J'ai hésité pour le surface=asphalt, mais comme il n'y en a plus au 
centre...


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


Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

2018-07-12 Per discussione Jarek Piórkowski
Hi all,

Damien's question appears to be about nodes like
https://www.openstreetmap.org/node/438843513, which has
name=Berri-UQAM, operator=Société de transport de Montréal.
short_name=STM seems inappropriate here, we could do
operator:short_name=STM or something but it seems a bit much.

The nearby station https://www.openstreetmap.org/node/26233453 has
name=Jean-Drapeau, network=STM, operator=Société de transport de
Montréal which seems like an attempt as good as we might get. Commuter
rail station https://www.openstreetmap.org/node/548900549 has
network=RTM, operator=Réseau de transport métropolitain which fits
that scheme as well. Similar with a random bus line on North Shore
https://www.openstreetmap.org/relation/3472432

Looking through map very casually I didn't see any operator=STM on the
subway. I did see it on a bus line
https://www.openstreetmap.org/relation/270258 but changing it to
network=STM and operator=Société de transport de Montréal seems like
it'd be fine there IMO.

To me "operator" looks a bit more little technical than the other
tags, so to me it would be alright to use the longer more formal name.
But I wouldn't edit-war anyone about it. I'd say run a query, see
which is more common currently, ask people here (as you've done), then
after a week change the minority tags to match.

--Jarek


On 11 July 2018 at 04:45, OSM Volunteer stevea
 wrote:
> Hello Damien:
>
> I'm "meh, OK" with an operator=STM value, but I freely say I haven't checked 
> in completely with whomever you mean by "the minority."  (I "haven't heard 
> of" any controversy one way or the other, STM or full-name.  But that isn't 
> saying much on my part).  I watch what's up with North American rail and it 
> seems that key-value pair is somewhere around the beginning of correct, at 
> least from my perspective, fwiw.  Being right on it (there) you are way more 
> on it than I am.  I'm sorta like a linguist here.
>
> However, OSM does have a short_name key and I'd be even better with 
> short_name=STM or alt_name=STM and operator=Société de transport de Montréal 
> if you want to get dotting-of-i and crossing-of-t about it.
>
> I mean, there are wiki pages on loc_name, nat_name, official_name, 
> short_name, alt_name and more, it's a slightly rich and deep topic in OSM and 
> in our wiki.  I say STM is somewhere around alt_name or short_name.  That is 
> one person's opinion.  What happens, happens.  I'm a guy typing words right 
> now, so, yeah.
>
> I also I notice when people get my name exactly right, as I appreciate that.  
> And look at that, both of us got "Société de transport de Montréal" exactly 
> right too (twice), making it a good candidate value for the name=* key.
>
> SteveA
> California
>
>> On Jul 10, 2018, at 7:22 PM, Damien Riegel  wrote:
>>
>> Hi everyone,
>>
>>
>> I'm new to this list so please forgive me if this topic has already been 
>> discussed.
>>
>> In Montréal, the public transportation provider is the "Societé de transport 
>> de Montréal", more commonly known as STM. Some (the minority) nodes use the 
>> full name, all the others use the acronym. it would be great to get rid of 
>> that discrepancy.
>>
>> If I had to give my opinion on the matter, I'd say "STM" is more appropriate 
>> as almost everything is branded under the "STM" name (for instance the 
>> website is https://stm.info, their Facebook page is called "STM - Mouvement 
>> collectif"), so that's the name people use. I think that also explains why 
>> "STM" is way more common as operator value than the full name.
>>
>>
>> Regards,
>> Damien
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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


Re: [Talk-it] Should StreetComplete stop adding addresses in Italy?

2018-07-12 Per discussione Martin Koppenhoefer


sent from a phone

> On 12. Jul 2018, at 20:33, Tobias Zwick  wrote:
> 
> Since early 2017 till now, users of my app StreetComplete have been
> adding house numbers to buildings.
> Should I disable this functionality for Italy?


I you could invite people to add addresses to entrances and gates and 
barrier=entrance (where applying), it would be great. 

For buildings I would say it is ok as long as the address applies to the whole 
polygon (usually means buildings with only one access from the public land).

For example I know an office in an apartment building, it is inside a garden. 
The access road to the garage has number 10, the gate which leads  to the 
footway to the building has 8, another gate which leads to the garden has 6. 
The office does not use the main entrance of the building (the access is 
through the garden) but it has the same house number and a postbox together 
with the apartment. For me it would be ok to have the 8 tagged as addr 
housenumber on the building (because it is a property of all tenants), as well 
as at the gate (because it applies to this point).
But I guess this is a situation more unusual than not, at least for commercial 
use.

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


Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-12 Per discussione osm . sanspourriel

Il y a quand même la référence de la voie qui l'indique.

CE= Chemin d'Exploitation, pas Chemin Écolo pour vélos, car comme 
deuzeffe le fait remarquer, sinon il y aurait un accent ;-).


Pour moi, chemin empierré où le passage de véhicules de particuliers est 
exceptionnel. On s'y croise difficilement (en mordant sur les bas côtés 
pour ne pas dire les champs).


Pas du 100 % mais pas loin.

Le 12/07/2018 à 20:09, Charles MILLET - charlesmil...@free.fr a écrit :

Bonsoir,

Une brève parenthèse au sujet du highway=track qui serait destiné à 
décrire les chemins agricoles ; je crois que c'est une traduction un 
peu rapide de la page en anglais mais surtout le wiki précise que 
finalement c'est plus une question de largeur... Pour ma part 
j'utilise track non pas pour son usage agricole mais lorsqu'un chemin 
est peu carrossable et assez large pour une voiture. La vocation 
agricole est quand même super compliquée à établir en plus !


Selon moi certaines voies vertes empruntent clairement un aménagement 
qu'on qualifierait de track si le panneau ne nous faisait pas en 
débattre.


Bonne soirée.

On 21/06/2018 20:08, Axelos wrote:

highway=track ? Non ce n'est pas un chemin agricole mais une route.



___
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] Should StreetComplete stop adding addresses in Italy?

2018-07-12 Per discussione Andrea Albani
Il giorno gio 12 lug 2018 alle ore 20:34 Tobias Zwick 
ha scritto:

> Hey there
>
> Since early 2017 till now, users of my app StreetComplete have been
> adding house numbers to buildings.
> Should I disable this functionality for Italy?
>
>
Hi Tobias and thanks for posting this question.
I think that you are referring to the Italian guideline that specifically
forbids to put "house numbers" on building polygons.
This is because in Italy the "house numbers" are actually access
identifiers unlike in other countries where they identify the building
itself.
Given that I think that the answer to your question should be "yes" .

In any case I would wait further contributions to this thread since the
above approach, even if accepted by the Italian community, was subject to
some criticism.

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


Re: [OSM-talk-fr] Changement de nom d'un réseau de transport

2018-07-12 Per discussione mga_geo
Bonsoir à tous,
J'ai commencé à uniformiser le tag network sur les différentes relations
existantes.
J'ai une page wiki sur ce réseau :
https://wiki.openstreetmap.org/wiki/User:Mga_geo/Transports_publics/juillet_2018

Marc



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


[Talk-it] Should StreetComplete stop adding addresses in Italy?

2018-07-12 Per discussione Tobias Zwick
Hey there

Since early 2017 till now, users of my app StreetComplete have been
adding house numbers to buildings.
Should I disable this functionality for Italy?

For buildings of certain types, such as "apartments" or "house"s etc.
(but not "yes"), which do neither have an address tagged, nor have any
node on or in their outline with an address tagged, nor are in any area
that has an address tagged, the app shows a pin on the map, like this:

https://raw.githubusercontent.com/westnordost/StreetComplete/master/fastlane/metadata/android/en/images/phoneScreenshots/screenshot8.png

This pin is shown to every user of the app, until it is solved. To solve
it, the user taps on the pin and can input the housenumber for the
building in the form that pops up then. The user can also answer that
the building has no housenumber, in which case the app tags noaddress=yes.

Cheers
Tobias

-

Addresses in Italy are described here in the wiki:
https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia

A related discussion on talk-it is archived here:
https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html

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


Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

2018-07-12 Per discussione Kevin Kenny
TL;DR: Cadastre in the US is untidy.



(1) Boundaries through buildings are not at all uncommon. Typically,
the landowner owes some apportionment of property tax to both
jurisdictions. The people I know who live in property that lies in
multiple school districts have the choice of which public school
system to send their children to.

(2) The municipal boundaries in my part of the world are also at least
moderately messed up in OSM. Alas, I don't have any data source that
offers the magical combination of (a) authoritative, (b) reasonably
accurate, (c) compatibly licensed. Unfortunately, I live in the Second
Circuit, the sole juristiction jurisdiction where Experian vs Suffolk
County is good law. The legal situation for government data here,
given that decision, is murky, owing to the fact that on remand, TRW
(Experian's successor-in-interest) settled the case. A Web search for
the case title will turn up reams of stuff. Government records cannot
be presumed to belong to the People.

A lot of patchwork has been done (by Richard Welty and others) in the
last few years, and it's not nearly the mess it once was - and kudos
to whoever made the lines follow the Thalweg of major rivers! There's
a lot more topological consistency than there once was, but I can
certainly see places where the lines aren't quite right, even if
they're more consistent than they once were.

I might do spot fixes to the lines if I happen to find indicia in the
field, but I'm not about to go out trying to recover all the survey
pins, which is really what it would take to do a proper job.



More or less off topic:

Don't get me started on the indefinite boundaries up north of here.
There are county and township lines that have never been field
surveyed accurately. The indefinite ones run mostly through
undeveloped forest, and nobody much cares about getting them even
third-order accurate, to say nothing of the first order. Gore Mountain
https://www.openstreetmap.org/node/357562059#map=14/43.6708/-74.0457
got its name from having been in the gore between two townships - a
legacy that can be seen in the not-quite-perpendicular-and-parallel
borders of the wilderness area and the ski resort. There, too, nobody
much cared - until Barton found garnets in the gore. The ensuing tax
disputes eventually led to the creation of a new township. The odd
corner at https://www.openstreetmap.org/node/357562059#map=13/44.1364/-74.0841
is an error of closure - yes, a 1.5 km error - in an 18th-century land
grant. Surveying that area by traditional methods was ... challenging.
https://localwiki.org/hsl/verplanck%20colvin/_files/Division%20of%20Levels.jpg
On Mon, Jul 9, 2018 at 7:12 AM Frederik Ramm  wrote:
>
> Hi,
>
> I've recently traced a little bit of stuff in Annetta, TX. The area I
> looked at had a lot of potential for someone interested in mapping from
> aerial imagery (houses, tracks, driveways, parking missing; some
> driveways tagged as highway=residential etc.) and I did what I could in
> the small area I worked on, but there was one thing I didn't dare touch
> and that's admin boundaries. The ones I encountered often cut straight
> through residential buildings and I thought that can't be right, but I
> know too little about boundaries in the US to fix any of it. I am
> specifically talking of
>
> https://www.openstreetmap.org/relation/114418
>
> and
>
> https://www.openstreetmap.org/way/33245202
>
> - maybe someone local wants to give them a closer look. Maybe it's ok
> the way it is. The Annetta North boundary is relatively straight but has
> one wobbly bit, is there maybe a waterway missing in OSM?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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


Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-12 Per discussione Charles MILLET

Bonsoir,

Une brève parenthèse au sujet du highway=track qui serait destiné à 
décrire les chemins agricoles ; je crois que c'est une traduction un peu 
rapide de la page en anglais mais surtout le wiki précise que finalement 
c'est plus une question de largeur... Pour ma part j'utilise track non 
pas pour son usage agricole mais lorsqu'un chemin est peu carrossable et 
assez large pour une voiture. La vocation agricole est quand même super 
compliquée à établir en plus !


Selon moi certaines voies vertes empruntent clairement un aménagement 
qu'on qualifierait de track si le panneau ne nous faisait pas en débattre.


Bonne soirée.

On 21/06/2018 20:08, Axelos wrote:

highway=track ? Non ce n'est pas un chemin agricole mais une route.



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


Re: [OSM-talk-fr] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)

2018-07-12 Per discussione deuzeffe

Bonjour,

Les jeux de données ouvertes disponibles étant peu bavards, la 
collecte d'informations de terrain a une valeur importante,

démontrant si il le fallait encore la pertinence d'OSM.


Bilan à mi-course de mes crapahutes de transfo. en transfo. :
- ceux sur poteau ont un nom ;
- beaucoup de ceux en building ou street_cabinet n'ont qu'un nom (et pas
de réf) ;
- j'ai trouvé :
-- des buildings référencés dans la base Enedis* non cadastrés ;
-- des buildings cadastrés non référencés dans la base ;
-- des buildings sans nom ni référence visible sur leur plaque 
d'identification non référencés dans la base;


RdV à la fin du mois pour l'avancement des travaux ;) À ce propos, on
pourrait avoir une chtite mise à jour de
https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques#Statistiques_et_participation
?

*Si comme moi, vous prononcez Énédis, tagguer avec Enedis doit froisser 
votre fibre orthotypo. :(


--
deuzeffe

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


Re: [OSM-talk-fr] Cartographier les voies vertes

2018-07-12 Per discussione Charles MILLET

Bonjour à tous,

Une précision par rapport au message original : un des objectifs de 
cette réflexion sur les voies vertes vient du fait que les collectivités 
et autres acteurs sont très demandeurs pour arriver à distinguer ces 
aménagements en se basant sur leur vocabulaire, c'est à dire les 
classiques pistes cyclables, bandes cyclables, aires piétonnes... et 
voies vertes. Le choix retenu pour décrire les voies vertes ne permet 
pas bien aujourd'hui de le distinguer d'autres aménagements qui 
présenteraient les mêmes combinaisons de tags. C'est pour cela le 
recours au traffic_sign serait une solution assez efficace... et cette 
solution résisterait même aux remarques tels que "on ne mappe pas 
pour..." puisqu'il n'apporterait pas une information fausse ;)


La suite de la réflexion était de se dire que puisqu'on a ce tag qui 
nous permet d'identifier une voie verte, pourquoi ne pas essayer de 
décrire l'aménagement de manière classique (path, track, unclassified, 
etc.) et d'utiliser les tags d'accès pour préciser l'accès justement. 
Comme ces panneaux ont fleuri un peu partout, cela pourrait éviter de 
dégrader une information qui n'est pas fausse. Cette approche semblait 
trouver un consensus lors des échanges physiques.


Bonne soirée.

Charles

On 21/06/2018 17:48, Antoine Riche wrote:


Bonjour,

Lors de l'atelier "vélo-tags" qui s'est déroulé lors de SOTM FR le 
samedi 2 juin, le sujet des voies vertes a été discuté. Le constat 
partagé lors des échanges est qu'une voie verte est identifiée par le 
panneau C115 (cf. 
https://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France), et que 
son aménagement peut être très différent : sentier, piste, voie de 
service, etc.


Le consensus des participant.e.s à cet atelier est de ne pas 
restreindre la valeur de la clef highway à path, et de préciser la 
présence du panneau par la clef traffic_sign. Je propose donc de 
modifier la section 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes pour 
indiquer qu'une voie verte est mappée par :


highway=*
foot=designated
bicycle=designated
traffic_sign=FR:C115

Ainsi nous affinons la description du terrain (on peut par exemple 
ajouter un tracktype si highway=track) et pouvons répondre aux 
attentes des collectivités qui souhaitent pouvoir identifier les voies 
vertes qu'elles ont balisées.


Des objections ou clarifications ?

Antoine.



 
	Garanti sans virus. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


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


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


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione Takahisa TAGUCHI

田口です。

> 
[1]の「ūやōなどのマクロン付きの文字を使用する」によると、「大手町」の正しいタグは「name:ja-Latn=Ōtemachi,
> 
name:en=Otemachi」だと思いますから、それは問題ありませんと思っております。


わたしも最初はマクロン付き文字でカバーできるかなと思っていたのですが、
よくよく考えると長音の「おう」と「おお」はどちらも ō となってしまうので
やはりひらがな表記は必須になってくるかと思います

例)
 東京 / とうきょう / Tokyō
 大阪 / おおさか / Ōsaka

ルビを振ることを想定し、ふりがな用のタグを用意するのはよい意見だとは
思うのですが、既存の name:ja-Hira を非推奨にしてまで一つに統合する
必要性も感じられず、もし需要があるのであれば name:ja-Furi のような
タグの新設を議論する方向がよいのかなと個人的には思うのですが、
いかがでしょうか。


On 2018/07/12 23:11, Leo Gaspard wrote:

レオです。

[1]の「ūやōなどのマクロン付きの文字を使用する」によると、「大手町」の正しいタグは「name:ja-Latn=Ōtemachi,
name:en=Otemachi」だと思いますから、それは問題ありませんと思っております。

その上、もし「name:ja-Furi」のようなタグがよかったら、「name:ja-Furi」でも「name:ja-Hira」を計算することが易しくできます。「大手町[おおてまち]」から「おおてまち」まで、それとも「彼[かれ]の
脳[のう]」から「かれののう」まで(スペースを使って漢字とかっこを消します)

「name:ja-Furi」から「name」も計算できますが、「name」のタグにAnki-style
furiganaを入れるのがちょっと違うかもしれません。

[1] https://wiki.openstreetmap.org/wiki/Japan_tagging#Names


On 07/12/2018 09:38 PM, yasunori kondoh wrote:

近藤(yasu747)です。

ひらがなとローマ字表記は変換テーブルによっては1対1で変換可能ではないと思います。
たとえば、交差点・道路標識でよくみられる「大手町」「Otemachi」。
「おてまち」なのか「おおてまち」なのか知っている地元の人が、ja-Hira を使うのは有用かもしれません。

2018年7月12日(木) 1:15 Leo Gaspard :


皆様


ちょっと質問があります。「ja-Latn」と「ja-Hira」は同じ情報を伝えませんか。ですから、ふりがなができるように「ja-Hrkt」(平仮名もカタカナもできるコード)を使おうとしましたが、それも完璧ではありません。例えば、「彼の脳」と「かれののう」で「彼(かれ)の脳(のう)」だけでなく、「彼(かれの)の脳(う)」も作ることができます。

そのため、ja-AnkiStyleFurigana
(ja-Furi?)のタグは一番いいと思います。そのフォーマットで、前の例はこのように書きます。「ja-Furi=彼[かれ]の
脳[のう]」(スペースは必要があります。スペースがなければ、Ankiは「の脳」の上に「のう」を書きます)

そして、そのような「name:ja-Furi」から全て計算できます。ところが、日本語に向いていないUIのため、「name
/ name:ja」も記入するのがもっといいと思います。

(Ankiはhttps://ankisrs.netで、そのプログラムで日本語の言葉を勉強するために、そのように書きます)


ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。

それは自分の考えだけです。
レオ

___
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


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



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


Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

2018-07-12 Per discussione Martijn van Exel
When it comes to strange boundaries, I always like to refer to this situation: 
https://www.openstreetmap.org/relation/53137#map=15/51.4390/4.9341

Baarle-Hertog is a Belgian enclave (actually some 20 enclaves) in the 
Netherlands. The main town inside the county is functionally one town together 
with (Dutch) Baarle-Hertog. Before the Schengen treaty, this led to weird 
situations with lots of checkpoints and people paying property taxes in two 
countries.
Some more info here: https://brilliantmaps.com/baarle-hertogbaarle-nassau/
-- 
  Martijn van Exel
  m...@rtijn.org

On Thu, Jul 12, 2018, at 08:41, Kerry Irons wrote:
> There are some "famous" court cases where it needed to be determined 
> where someone lived.  First the courts decided that the bedroom would 
> determine which jurisdiction applied, and then it came down to where the 
> bed was in the bedroom, and then finally where the person's head was 
> when they slept.  Indeed, boundaries do go through buildings.
> 
> 
> Kerry Irons
> 
> -Original Message-
> From: Greg Troxel  
> Sent: Thursday, July 12, 2018 10:02 AM
> To: Frederik Ramm 
> Cc: talk-us@openstreetmap.org Openstreetmap 
> Subject: Re: [Talk-us] admin_level=8 boundaries in Parker County, TX
> 
> 
> Frederik Ramm  writes:
> 
> > I've recently traced a little bit of stuff in Annetta, TX. The area I 
> > looked at had a lot of potential for someone interested in mapping 
> > from aerial imagery (houses, tracks, driveways, parking missing; some 
> > driveways tagged as highway=residential etc.) and I did what I could 
> > in the small area I worked on, but there was one thing I didn't dare 
> > touch and that's admin boundaries. The ones I encountered often cut 
> > straight through residential buildings and I thought that can't be 
> > right, but I know too little about boundaries in the US to fix any of 
> > it. I am specifically talking of
> 
> Not commenting on that boundary (which others say needs help), but the logic
> 
>   admin-8 bounadry goes through houses
> -->
>   boundary must be wrong
> 
> is incorrect in the US.  Around me, there are multiple houses where the 
> boundary line indeed goes through them (where I've seen the boundary 
> markers, seen the houses, and talked to the occupants who pay taxes to 
> two towns).
> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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


Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

2018-07-12 Per discussione Kerry Irons
There are some "famous" court cases where it needed to be determined where 
someone lived.  First the courts decided that the bedroom would determine which 
jurisdiction applied, and then it came down to where the bed was in the 
bedroom, and then finally where the person's head was when they slept.  Indeed, 
boundaries do go through buildings.


Kerry Irons

-Original Message-
From: Greg Troxel  
Sent: Thursday, July 12, 2018 10:02 AM
To: Frederik Ramm 
Cc: talk-us@openstreetmap.org Openstreetmap 
Subject: Re: [Talk-us] admin_level=8 boundaries in Parker County, TX


Frederik Ramm  writes:

> I've recently traced a little bit of stuff in Annetta, TX. The area I 
> looked at had a lot of potential for someone interested in mapping 
> from aerial imagery (houses, tracks, driveways, parking missing; some 
> driveways tagged as highway=residential etc.) and I did what I could 
> in the small area I worked on, but there was one thing I didn't dare 
> touch and that's admin boundaries. The ones I encountered often cut 
> straight through residential buildings and I thought that can't be 
> right, but I know too little about boundaries in the US to fix any of 
> it. I am specifically talking of

Not commenting on that boundary (which others say needs help), but the logic

  admin-8 bounadry goes through houses
-->
  boundary must be wrong

is incorrect in the US.  Around me, there are multiple houses where the 
boundary line indeed goes through them (where I've seen the boundary markers, 
seen the houses, and talked to the occupants who pay taxes to two towns).


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


[Talk-pe] Invitación a SOTM LATAM

2018-07-12 Per discussione info

¡Hola!
Nos alegra poder invitarlos a que nos acompañen en la 4ta edición del 
State Of The Map (SOTM) LATAM a realizarse este año en la Ciudad de 
Buenos Aires, Argentina el 24 y 25 de septiembre 2018 en el Centro 
Metropolitano de Diseño.
Este año, se busca contar con alrededor de 200 asistentes locales, 
nacionales, regionales e internacionales, otras comunidades tecnológicas 
relacionadas a la información geográfica, y presencia de parte de las 
instituciones estatales, académicas y organizaciones sociales.
La misma se realizará en la misma semana que el Abrelatam (26/9) y el 
IODC (27 y 28/9) así que es una buena oportunidad para asistir a varios 
eventos internacionales referidos a los datos abiertos.
Visita nuestra página para más información, anotarse (sin costo) y 
presentar propuestas de charlas en https://state.osmlatam.org/ o escribí 
a i...@osmlatam.org


Comisión Organizadora SOTM Latam 2018

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


Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

2018-07-12 Per discussione Greg Troxel

Frederik Ramm  writes:

> I've recently traced a little bit of stuff in Annetta, TX. The area I
> looked at had a lot of potential for someone interested in mapping from
> aerial imagery (houses, tracks, driveways, parking missing; some
> driveways tagged as highway=residential etc.) and I did what I could in
> the small area I worked on, but there was one thing I didn't dare touch
> and that's admin boundaries. The ones I encountered often cut straight
> through residential buildings and I thought that can't be right, but I
> know too little about boundaries in the US to fix any of it. I am
> specifically talking of

Not commenting on that boundary (which others say needs help), but the
logic

  admin-8 bounadry goes through houses
-->
  boundary must be wrong

is incorrect in the US.  Around me, there are multiple houses where the
boundary line indeed goes through them (where I've seen the boundary
markers, seen the houses, and talked to the occupants who pay taxes to
two towns).


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


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione yasunori kondoh
近藤(yasu747)です。

ひらがなとローマ字表記は変換テーブルによっては1対1で変換可能ではないと思います。
たとえば、交差点・道路標識でよくみられる「大手町」「Otemachi」。
「おてまち」なのか「おおてまち」なのか知っている地元の人が、ja-Hira を使うのは有用かもしれません。

2018年7月12日(木) 1:15 Leo Gaspard :

> 皆様
>
>
> ちょっと質問があります。「ja-Latn」と「ja-Hira」は同じ情報を伝えませんか。ですから、ふりがなができるように「ja-Hrkt」(平仮名もカタカナもできるコード)を使おうとしましたが、それも完璧ではありません。例えば、「彼の脳」と「かれののう」で「彼(かれ)の脳(のう)」だけでなく、「彼(かれの)の脳(う)」も作ることができます。
>
> そのため、ja-AnkiStyleFurigana
> (ja-Furi?)のタグは一番いいと思います。そのフォーマットで、前の例はこのように書きます。「ja-Furi=彼[かれ]の
> 脳[のう]」(スペースは必要があります。スペースがなければ、Ankiは「の脳」の上に「のう」を書きます)
>
> そして、そのような「name:ja-Furi」から全て計算できます。ところが、日本語に向いていないUIのため、「name
> / name:ja」も記入するのがもっといいと思います。
>
> (Ankiはhttps://ankisrs.netで、そのプログラムで日本語の言葉を勉強するために、そのように書きます)
>
>
> ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。
>
> それは自分の考えだけです。
> レオ
>
> ___
> 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] Invitación a SOTM LATAM

2018-07-12 Per discussione info

¡Hola!
Nos alegra poder invitarlos a que nos acompañen en la 4ta edición del 
State Of The Map (SOTM) LATAM a realizarse este año en la Ciudad de 
Buenos Aires, Argentina el 24 y 25 de septiembre 2018 en el Centro 
Metropolitano de Diseño.
Este año, se busca contar con alrededor de 200 asistentes locales, 
nacionales, regionales e internacionales, otras comunidades tecnológicas 
relacionadas a la información geográfica, y presencia de parte de las 
instituciones estatales, académicas y organizaciones sociales.
La misma se realizará en la misma semana que el Abrelatam (26/9) y el 
IODC (27 y 28/9) así que es una buena oportunidad para asistir a varios 
eventos internacionales referidos a los datos abiertos.
Visita nuestra página para más información, anotarse (sin costo) y 
presentar propuestas de charlas en https://state.osmlatam.org/ o escribí 
a i...@osmlatam.org


Comisión Organizadora SOTM Latam 2018

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


[Talk-cl] Invitación a SOTM LATAM

2018-07-12 Per discussione info


¡Hola!
Nos alegra poder invitarlos a que nos acompañen en la 4ta edición del 
State Of The Map (SOTM) LATAM a realizarse este año en la Ciudad de 
Buenos Aires, Argentina el 24 y 25 de septiembre 2018 en el Centro 
Metropolitano de Diseño.
Este año, se busca contar con alrededor de 200 asistentes locales, 
nacionales, regionales e internacionales, otras comunidades tecnológicas 
relacionadas a la información geográfica, y presencia de parte de las 
instituciones estatales, académicas y organizaciones sociales.
La misma se realizará en la misma semana que el Abrelatam (26/9) y el 
IODC (27 y 28/9) así que es una buena oportunidad para asistir a varios 
eventos internacionales referidos a los datos abiertos.
Visita nuestra página para más información, anotarse (sin costo) y 
presentar propuestas de charlas en https://state.osmlatam.org/ o escribí 
a i...@osmlatam.org


Comisión Organizadora SOTM Latam 2018

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


[Diversity-talk] 2018Q3 Mapping Project - Women's health facilities - and help needed

2018-07-12 Per discussione Rory McCann

Hello all,

I'm a little late again, but we're in July, so I'll close the poll for
this Quarterly Mapping Project, and the most votes went to Women's
Health Facilities. So that'll be the 2018Q3 Mapping Project.

*But* it's a topic I don't know anything about, so someone else needs to
explain! Please, please chime in! What should we map, how should we map
it. What's missing from OSM? What's useful to map?

There is this ( 
https://wiki.openstreetmap.org/wiki/Tagging_in_Support_of_Women_and_Girls#Health_Services 
).


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

Re: [OSM-talk-fr] Route500 et le passage à 80 km/h du 1er juillet...

2018-07-12 Per discussione Rpnpif
Le 12 juillet 2018, Jérôme Amagat a écrit :

> Le mer. 11 juil. 2018 à 23:47, marc marc  a
> écrit :
> 
> > oups, 2 typos dans mon message, je recommence
> >
> > Le 11. 07. 18 à 14:52, Jérôme Amagat a écrit :  
> > > j'ai fait les modification autour de chez moi (en gros sur un quart de
> > > département autour de Bourg en Bresse dans l'Ain), retour sur expérience  
> > :  
> > > j'ai modifié là où il y avait déjà un maxspeed=90  
> >
> > tu veux dire que t'as modifié toutes les routes simplement
> > en te basant sur maxspeed=90 ?
> > donc en gros une route qui a un panneau 90km/h est maintenant à 80km/h
> > dans osm alors qu'on peux y rouler à 90km/h ?
> > car sauf erreur de ma part, la valeur par défaut de la loi
> > s'applique en l'absence de panneau.
> > En présence de panneau, c'est celui-ci qui a le dernier mot.
> >  
> 
> Normalement tout les panneaux 90 là où maintenant c'est 80 ont du
> disparaitre! Supprimé ou remplacer par 80.
> (Sauf peut être dans les quelques départements qui font de la resistance)
> 
> Sinon Pour le suivi des changement je n'avais pas pensé à la carte sur
> taginfo ! Bien vu !

Comme le dit Marc Marc, ce sont les panneaux qui ont le dernier mot
donc il faut être sûr que quand la route a un profil particulier, c'est
bien 80.

-- 
Alain Rpnpif

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


Re: [OSM-ja] name:ja-Hira、name:ja-Hrkt、ja-AnkiStyleFurigana?

2018-07-12 Per discussione Takahisa TAGUCHI

田口です。

> 
ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。


ja-Latn と ja-Hira が両方存在する背景は、おそらくですが「駅名標」の
表現方法が、日本人の共通認識としてかなり昔から根付いているから
じゃないかな、、、と個人的には思っています。
https://ja.wikipedia.org/wiki/%E9%A7%85%E5%90%8D%E6%A8%99

# 違っていたらごめんなさい、、、

個人的には、こうした歴史的背景があるので両方あってもよいかなと思ったり
しますが、一方でご指摘の通り ja-Latn から自動生成することも可能では
あるので、データとしてみると確かに重複しているのかもしれません。

他の人のご意見も聞きたいところです。


On 2018/07/12 1:13, Leo Gaspard wrote:

皆様

ちょっと質問があります。「ja-Latn」と「ja-Hira」は同じ情報を伝えませんか。ですから、ふりがなができるように「ja-Hrkt」(平仮名もカタカナもできるコード)を使おうとしましたが、それも完璧ではありません。例えば、「彼の脳」と「かれののう」で「彼(かれ)の脳(のう)」だけでなく、「彼(かれの)の脳(う)」も作ることができます。

そのため、ja-AnkiStyleFurigana
(ja-Furi?)のタグは一番いいと思います。そのフォーマットで、前の例はこのように書きます。「ja-Furi=彼[かれ]の
脳[のう]」(スペースは必要があります。スペースがなければ、Ankiは「の脳」の上に「のう」を書きます)

そして、そのような「name:ja-Furi」から全て計算できます。ところが、日本語に向いていないUIのため、「name
/ name:ja」も記入するのがもっといいと思います。

(Ankiはhttps://ankisrs.netで、そのプログラムで日本語の言葉を勉強するために、そのように書きます)

ちなみに、「ja-Hira」は全部「ja-Latn」から計算できて、「ja-Hira」の理由がよく分かりません。ですから、「ja-Furi」はよかったら、「ja-Hira」もdeprecateしませんか。

それは自分の考えだけです。
レオ

___
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


[Talk-cz] WeeklyOSM CZ 415

2018-07-12 Per discussione Tom Ka
Ahoj, je dostupné vydání 415 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/10481

* Organizace OSM CZ.
* Říční síť Turca.
* Problematický obsah v OSM.
* FIXME a fixme.
* Hlasování pro Ceny OSM 2018.
* Zemětřesení v Osace.
* Kvalita mapování HOT.
* Offline OSM od Amazonu.
* Nabíjení elektromobilů.

Pěkné počtení ...

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