JA talk:How to map a

From OpenStreetMap Wiki
Jump to navigation Jump to search

name の付け方を整理したい

JA:Naming_sampleにおいて特にチェーン店の表記揺れを削減するためにname値の実例をあげており、以下不要と感じた部分に取消線を入れておきます。--MaryHiroshige 02:01, 12 February 2012 (UTC)
name=* の定義では通りの名前などで略称は使用禁止となっていますが、日本では自然発生的、かつ非公式な略称が(マツキヨ、マック等)、いつの間にか通り名になってしまうのが通例です。 これらを整理した例を下記に挙げてみますので、ご意見お願いします。

例：マクドナルド大門店

  • amenity=fast_food
  • name=大門店 (Daimon Branch)
  • name:ja=大門店
  • name:en=Daimon Branch
  • operator=McDonald's
  • operator:ja=マクドナルド
  • ref:ja=マック

　--higa4 23:58, 19 October 2009 (JST)

ref というのは基本的にはIDを書くタグであって、略称ではありません。そもそも略称を地図に書く必要があるとは思えません。非正式略称を書きならべるのは、Wikipedia の方が適しています。name に略称を書いてはいけないのは、略称は基本的にそこに住んでる人以外には読めないからです。例えば、マクドナルドは関西では「マクド」と略しているので、「マック」というと「マッキントッシュ」くらいしか思いつかない人がいます。ただ、マツモトキヨシは全ての店舗に「284号店」のように番号をつけていたりするので、それのために "ref:ja=マツキヨ 284" とかくのはありかもしれません。でも、operator を書いてあるので、番号だけの "ref=284" の方が普通かな。 --Nazotoko 17:27, 19 October 2009 (UTC)

この議論の意図のひとつに、おそらく近い将来実現するであろうPOIの日本語検索がしやすい下地作りをしておけたら、との思いがありました。(iPhoneアプリには英語でPOIを検索できるLeisureなどのアプリが既にありますね)シンプルに看板の通りに名称を付けるとすれば、本日ざっと確認したところでは"Mcdonald's","doutor","KFC","mister donut"という感じで、ちょっとそのまま日本語検索に使えそうではありませんでした。operator:ja でも良いセン行くとは思いますが、"マツキヨ"とか"ココイチ"とか、当てはまらないものもあります。地図内での表現が許される範囲で、その店をポイントするのに広く使われていると思われる名称を設定できるタグがあると良いのですが。 --higa4 22:00, 20 October 2009 (JST)

略称検索のためならなおのこと非正式名称をOSM のデータにしてはいけません。それは検索ソフトが「マック」や「マクド」を「マクドナルド」に書き直して検索すればいいだけだろうと思います。データには「マクドナルド」で統一されているれば、検索に手間がかかりませんが、たくさんの略称があったりすると全部検索しなければならないので、大変です。入力する側のソフトも、略称を保管して正式名称を入力するように作ればいいだけでしょう。あと、operator=* はname=* と一緒で、現地語のほうが良さそうなので、operator:en=Macdonald'sのほうがいいと思いますよ。どうでもいいですが、"KFC" は略称の様に見えて正式名称で、"Kentucky Fried Chicken"の方が非正式だったりします。--Nazotoko 21:45, 20 October 2009 (UTC)

もうひとつ、別の話ですが、チェーン店の支店名（上記例では大門店）は、ネットで探すと見つかるのですが実店舗の外から、あるいは中に入って探してもなかなか見つかりません。店舗営業上、お客に支店名をアピールする必要性が薄いからではないかと感じました。チェーン店の店舗を支店名で探す人はごく少ないと思います。ネット以外では探せないような(現地でみつけにくい)支店名をname という基本的なタグに付けるというのはどうにかならないものでしょうか。　--higa4 22:00, 20 October 2009 (JST)

私は、operator=*を書いたら、name=*は書かなくてもいいものだと思っていますから、わかったときだけ書いたらいいんじゃないでしょうか。フランチャイズ契約の仕組みをよく知ってる人はわかると思いますが、看板が「マクドナルド」でも、実際に自治体に飲食店として登録されている名前が、「有限会社山田ハンバーガー」とかだったりすことはよくありますよ。さて、そんな理想は置いといて、一番の問題はレンダラーがちゃんとoperator タグを見ているかなのですが、まったく見ていません。よって、いまのところname=大門店 では何屋かわらなくなるので、name=マクドナルド のほうが良さそうです。表を書き直して置きます。、、ん！そうすると、operator:ja=*とか何の意味もないってことか。 --Nazotoko 21:45, 20 October 2009 (UTC)
支店名がref=*というのも違和感があります。鉄道だとoperator=小田急電鉄,name=小田急電鉄小田原線のように書いていますから、operator=マクドナルド,name=マクドナルド大門店というのはどうですかね?　支店名がわかりにくいというのは確かですね。買い物・飲食してレシートを貰えばはっきりするのですが...--Nahainec 12:36, 21 October 2009 (UTC)
支店名がref=* は、意外と整合がとれると思ったのですが。例えば国道3号線はhighway=trunk,ref=3。小田急電鉄小田原線はoperator=小田急電鉄,ref=小田原線。マクドナルド大門店は、operator=マクドナルド,ref=大門店って意外と普通かなとおもうのですが。支店の名が重要なのは、特に国家資格「薬剤師」がないと開けないドラックストアーの場合です。マツモトキヨシの店舗検索とかで、地方の店舗名を見てください。「長峰ファミリー薬局」「調剤薬局　浜松中央店」「薬　ﾍﾞｽﾄ電器久留米本店」など、他の会社が本当の経営主であることを強く主張してある名前が出てきます。ここまで強いとalt_name=*とかもありなのかもしれませんが。--Nazotoko 19:56, 21 October 2009 (UTC)
異質なrailway=*を例に出したのは失敗だったかな。対象によってoperator=*が重要なものとname=*が重要なものがあること。現在のレンダリングに合わせてタグを打ってはいけないという理想と、「マクドナルド」無しで支店名だけが表示されるのはあまりに不便という現実。当面下のように入れておいて、支店名branch_name=*みたいなのができたらname=*から支店名を外すというのもありですか。ところでバッチ処理的にタグの書き換えってできるんですかね。できるのならname=*の「マクドナルド」部分の表記のゆれをなくしておくと将来楽ができるかもしれませんね。

表1Aにて再掲している為、表1は削除しました。必要に応じて過去の版を参照願います。 --MaryHiroshige 02:01, 12 February 2012 (UTC)

表1は削除

上記表に公共施設の例で学校を追記してみました。私は外国人の方も使えるようできるだけ英文表記も入れるようにしているのですが(例:name=松戸市立常盤平第三中学校 (Tokiwadaira-Daisan Junior High School))長くなりすぎてレンダリング上ちょっとうっとおしいです。松戸市はoperatorへ、英文表記はname:enへ切り出すべきでしょうか？

--higa4 1:40, 24 October 2009 (JST)

私はname に英文(ローマ字でも可)を書くのはレンダラーがアルファベットしか表示できない時に白紙になるのを避けるためだったからと思っているので、Mapnicが完全に多言語対応していて、tiles@home でもcjk 統合漢字フォントのインストールを勧めている今は書かなくてもいい気がします。でもまだtiles@homeでも時々空白になっている事があるので、それを恐れるときは必要最低限をかいたらいいと思います。だから、name=松戸市立常盤平第三中学校 (Tokiwadaira-Daisan) でいいんじゃないでしょうか。どうしてもアルファベットしかかけない人は、とりあえずname:enとnameを英文で書いて、fixme=I cannot input Japanese. Please fix it. とか書いてもらいましょう。--Nazotoko 19:05, 26 October 2009 (UTC)

表全体を再掲します。いかがでしょうか。

表1A
対象 operator=* name=* name:en=* ref=* コメント
国道 長崎街道 3
鉄道 小田急電鉄 小田急電鉄小田原線
地下鉄 東京都交通局 都営地下鉄新宿線 10
鉄道駅 東京都交通局 小川町 S 07 共同使用駅とかoperator=*どうしましょう?
ドラッグストア マツモトキヨシ マツモトキヨシ???店 Matsumotokiyoshi ??? Branch (284) JA:Naming_sampleを参考に
ファーストフード マクドナルド マクドナルド大門店 Mcdonald's Daimon Branch JA:Naming_sample参照
送電線 東京電力 高井戸線
鉄塔 東京電力 杉並線13 当初はname=杉並線No.13とか入れてました。
学校 松戸市立常盤平第三中学校 (Tokiwadaira-Daisan) Tokiwadaira-Daisan Junior High School name 欄()内の英文は長い場合は最低限で可
ホテル 東横イン 東横イン 宮崎駅前 Toyoko Inn Miyazaki Ekimae 101 JA:Naming_sampleを参考に
弁当屋 オリジン東秀 東秀 本厚木駅東口店 正式名称にこだわればname=中華東秀～?

JA:Naming_sampleを参考に

交差点（信号） 浜田山駅入口 Hamadayama Sta. Ent. 英文の「Sta.」「Ent.」は略称ですが、現地にはそう表記されている

--higa4 7:30, 27 October 2009 (JST)

ホテル、operator=*とname=*が異なる例として「東秀」、略称か正式名称か疑問に思える例として交差点（信号）を追記してみました。交差点名については現地表記以外に根拠とするものはないので「Sta.」とかは構わないと思います。どこかで英文表記にゆれのある（現地の複数の標識で表記が異なっている）のを見たのですが、そういう場合はどちらかをalt_name=*ですかね。あと北海道の交差点の信号の表記は方向によって異なっていることがありました。チェーン店名のように大量にあるものでは下のような固有名のリストがあった方が良いかもしれません。別件のpub,cafe,restaurant,fast_foodの区別も揃えられそうですし。

表「食事」削除。（必要に応じて過去の版を参照願います。--MaryHiroshige 02:22, 12 February 2012 (UTC) ） --Nahainec 13:38, 27 October 2009 (UTC)

補足 上の「食事」表では支店名は省いています、念のため。
データ形式によっては前に言及のあった検索にも使えますね。

--Nahainec 13:45, 27 October 2009 (UTC)

英語の略称について、"Sta.","Ent." はだめです。欧米にある標識はほとんどの標識は略称を使ってますが、書いちゃいけないと言うのがその「略称はだめ」ルールです。"Sta."は国際表記とかでもなく、日本語が「駅」「入り口」なので、すぐに"Stataion", "Entrance"だと解るので、そこは正しく書きましょう。ひどい場合、日本についてしらないひとには、"Ent."が英語の略じゃなくて、"Entamuma"とかローマ字日本語の略かもしれないと思う人もいるので。--Nazotoko 19:14, 30 October 2009 (UTC)
英語の略称禁止って、「勝手に省略しない」だと思っていたのですが、「省略されていたら伸張する」だったんですね。大量に書いてしまいました。--Nahainec 13:02, 31 October 2009 (UTC)

operator タグ

operator タグだけの話になったので、JA_talk:Key:operator#operator タグの統一表に移動。--Nazotoko 19:43, 12 November 2009 (UTC)
operator タグもチェーン店においてはJA:Naming_sampleにて表記の統一の取り組み中。--MaryHiroshige 02:01, 12 February 2012 (UTC)

fast_food or restaurant

JA_talk:Key:amenity#fast_food or restaurantへ移動--Nazotoko 21:03, 29 December 2009 (UTC)

焼肉はbbq?

これも典型的に BBQ で、知られていると思います。例:Japanese BBQ dining Gyu-Kaku --Nazotoko 20:36, 14 October 2009 (UTC)

牛角サイトの画像で納得です。焼肉屋そのものですね。私は焼肉屋にsteak_houseを使っていたのですが日本にある焼肉屋といわれる所にはbbqを使うようにしたいと思います。 -higa4 23:31, 15 October 2009 (JST)

おまけです。:

--Nazotoko 19:41, 18 October 2009 (UTC)

amenity と shop のカテゴリー

amenityとshop タグは、多様過ぎるので、ざっぱなカテゴリーだけを書くことが推奨されています。これは、そうでもしないといつまでも標準のレンダラーの設定が追いつかないからです。例えば、Talk:Tag:shop=beveragesにあるように、私もshop=beveragesとshop=alcoholを分けようとするなど、ばかばかしいと思います。よって、居酒屋は、amenity=pub でいいでしょう。補足説明にcuisine=japaneseを付けてもいいと思います。 --Nazotoko 20:36, 14 October 2009 (UTC)
amenity=pub/barについての議論が主となっており、amenity=pubの「日本での解釈」で統一可能と考えられる為、該当部分に取消線を入れました--MaryHiroshige 02:47, 12 February 2012 (UTC)

飲食ができる場所のタグのうち、酒や食事の内容を問わないタグとしてrestaurant,pub,barの３つがあるかと思いますが、これにどう当てはめるか、ということになろうかと思います。restaurantは上述のとおりで、pubは「店内で静かに飲食ができる店」barは「お酒は飲めるが、食事は必ずしもあるとは限らず、騒がしい店」という英文の定義をベースに考えると、日本で数の多い居酒屋チェーン店はとても騒がしいので、どちらかといえばbar に相当するのではないでしょうか。 --higa4 00:45, 16 October 2009 (JST)
higa4 さんの書くpub と bar の定義は何度読み返しても逆のような気がするのですが。pub はどっちかというと、酒と一緒に夕食を食べるとか、ビールとかの種類が100を越えていることが自慢(English pub の典型)だから飲みに行くとか、テレビでアメフトとかバスケットボールとか流していて客全体が騒いでるようなとことか、クリスマスにはパーティーをしているとか、ジャズバンドが演奏してるとかそんな感じの騒ぐタイプの飲み屋です。騒ぐ方がメインになると、nightclub になるんでしょう。bar というと、特に騒ぐものがなく、食べるために入ることはないような店です。
海外滞在経験が無いものですから、私のはどこかで読んだ内容でしかないのですが、私が書いたpub と bar の違いはTag:amenity=pub の記述からの受け売りです。確かに日本でのpub とbar を比べるとNazotoko さんご指摘の通り逆といった方が実態と合っていますね。やはり居酒屋はpub でしょうか。 --higa4 00:20, 20 October 2009 (JST)

私は、Tag:amenity=pubの記述が間違っているは思ってないのですが、Tag:amenity=barが何か変に見えます。例えばpub の

  • You can usually sit down: 椅子(場合によってはソファー)とテーブルは当然あります。
  • usually no loud music to disturb conversation: ジャズバンドが演奏してたとしても、離れたところでは結構みんな会話してます。少なくてもアメリカ人にはジャズやブルースは演歌みたいなものですから、うるさいと思わないようです。
  • A pub would be good location to meet after a days mapping
今のところmapping party の待ち合わせ場所は pub だけです。未成年を締め出しているようで、良くない気がしますが。

となにもおかしいと感じない。一方で、おかしい気がするbar は、どうも2つ解釈があるらしいがどっちも変だ。

  • (in northern countries)
    • a noisy and vibrant atmosphere similar to a party: まったく解らない。なんせ "sushi bar"なんて店があるくらいの場所に住んでるから。
    • They do not sell food to be eaten as a meal.: これは解る
    • The music is usually loud and you often have to stand.: 椅子がないのは解るが、loud はどんな音楽をさしてるか解らない。
    • Sometimes it has a dancefloor, but it's not the main attraction.: ダンスフロアー？何だそれって感じですが、少なくとも日本の居酒屋ではなさそう。
  • (in southern countries like the mediterranean) 地中海側と言ってるので、ラテンヨーロッパですね。
    • You go there in the morning to have breakfast, at lunch they serve simple meals, all day long: それって cafe じゃないの。
    • Some are open in the evening and night though mostly they close in the evening: 多くは夕方に閉まる？完全に大衆食堂っぽい。

とまったくよく解りません。アメリカ人とヨーロッパ人はまた一段文化が違うので、私には彼らが何をさして bar と言ってるのかさっぱり解りません。アメリカ人は、「カウンター」越しの飲食店を指して bar と呼びます。たぶん amenity=bar はまだ定義不足で、使うのを避けた方がいい気がします。--Nazotoko 20:22, 20 October 2009 (UTC)


英語版Wikipediaでbarをみると イギリスのpub = アメリカのbar、イギリスの（一部の）bar は Nightclub と似てる、となっています。

OSMタグ的には

  • pub : 飲むところ
  • bar : 飲みながら音楽やダンスを楽しむところ
  • nightclub : 踊るところ（お酒も飲める）

こんな感じでしょうか？

飲みながら（大音量の）音楽とダンスを楽しむ場所。日本だとライブハウスがこれに近いですかね。イギリスの"bar"は基本的に入場料不要なようですが。

「pubとbar」より「barとnightclub」のほうがあいまいな感じがします。

In Mediterranean countries...以下の文章は、南欧のbarはこれこれこういうものだと延々と説明して、{{tag|amenity|bar}とはぜんぜん違うんだよと言ってるだけで、二通りの解釈をしているわけではありません。翻訳に少し手を加えておきました。 --torimomo 14:38, 14 Nov 2011(UTC)

proposing amenity=public_bath

公衆浴場(温泉地の風呂から日常的に使う銭湯まで含む)にあたるものは、tagwatch とかも見たけどないようです。ヨーロッパとかにもないわけではないので、申請してみようかと思います。だれか人がいない銭湯の写真を撮れる人とかいますか。 --Nazotoko 19:41, 18 October 2009 (UTC)

少しだけですが使用例もでてきてますね --MaryHiroshige 11:20, 19 December 2012 (UTC)

歩道橋

禁断の果実に手を出している気もしますが、目標物としても良いと思うのであえて書きます。 さまざまな書き方が考えられますが、皆さんのご意見はどうでしょうか?

  1. 一つのノードとして （highway=crossingのように）
    • 簡単
    • 交差点でどちらの道を渡るのか、L字になっていて渡れない方角がある、といった情報が不明になってしまう
  2. 上の水平部分のみウェイとして （階段は省略する）
    • 形ははっきりする
    • ルーティングには使えない
  3. 階段も描くが、下は道路のウェイに結合しない
    • 形はより正確になる
    • やはりルーティングには使えない
  4. 階段の下を道路のウェイに結合する
    • 形は変になる （三角形になる）
    • 道路のどちら側という情報は無いので、やはりルーティングには使えない
  5. 道路の歩道を分離して描き、階段はそこに結合する
    • ある意味で理想形
    • ルーティングに使える
    • 歩道を分離するのは非現実的 （少なくとも現時点では他に優先するべきことがある）

跨線歩道橋の場合は、跨ぐ線路ではなく近くの道路へ結合するので「階段の下を道路に結合する」で違和感が無いのでそうしています。 個人的には「階段も描くが、下は道路のウェイに結合しない」で形状を正確に入れておいて、あとはいつの日か歩道を描く人に委ねる、のが現実的かなと思っています。--Nahainec 03:38, 7 November 2009 (UTC)

歩道橋答えは一番理想的な5. で、階段と橋を使って表現するのが普通です。歩道橋によっては自転車や車椅子での利用を想定しているものも当然あるので、それと区別するのが重要だと思います。登る場所を階段にするか、ただの歩道で描くかで視覚的にも表現できます。crossing は自動車側からするとバリアのイメージがあるので、立体交差であることを表現しておいたほうがいいです。歩道を全部分離するのは、労力を多く費やすのは当然ですけど、やるなとか誰も言いません。実際やってる人はいます。でも楽したいというひとも当然いるので、Talk:Proposed features/FootwayとかProposed features/SidewalkとかProposed features/Advanced footway and cyclewayとかあります。ただ、右とか左では表現が曖昧で、今のところhighway=footwayを分離して描くのが一番はっきりした表現になります。何十キロも分離した歩道を描く必要はないですよ。近所の横断歩道で道と交わっていればいいです。歩道橋の下に、横断歩道があったりするなら、4. の描き方もありです。歩道描き方の議論はよくあるFAQですね。

--Nazotoko 22:30, 8 November 2009 (UTC)

Nazotokoさんの想定する4.?
Nahainecの想定していた4.
3.

基本は

階段等の下の処理は、理想形が5.というのは異論無いです。 ただ、楽をしたい場合、あるいは目標物としてとりあえずここに歩道橋があるということを入れておきたい場合にどうするのがよいだろうかということです。Nazotokoさんの「歩道橋の下に横断歩道があったりするなら...」がよくわからなかったのですが、右図の上を想定していたのでしょうか? 横断歩道の無いところで下の道路の結合したらマズいですか?

この3つの書き方の違いというのは

  • 形状を正しく表す
  • トポロジーを正しく表す

という異なる価値観の優先度の違いなんでしょうね。

当初は上の発想は無かったので中と下を比較し、

  • 形状を取るなら下
  • トポロジーを取るなら中、ただし
    • トポロジーを優先する主な目的は将来のルーティング
    • この中の形ではルーティングに使えない （無駄なループにしか見えない）
  • 本質ではないが中はあとで歩道を分離して書くときに面倒

と考えて当面は下（3.）でもよいのかなと思っていました。上は両者を満たす（ルーティングには×ですが）ので良さそうです。

歩道についてはご提示いただいたProposal等読んでみましたが、どちら側に歩道等があるかは表現できても、歩道橋などがどちらに接続しているのかを表現できないように思います。 --Nahainec 12:44, 12 November 2009 (UTC)

まさか図示してくれるとは思ってなかったです。ありがとうございます。図nazotokoの4はどちらかといえば手抜き5. のイメージで、Nahainecさんの4.でもいいと思います。形状よりトポロジーとかの相対的な位置関係を優先したほうがいい理由は簡単で、GPS や Yahoo 航空写真程度の精度では、5 m 以下の精度で図を描くのはほぼ不可能だからです。また利用側の立場から見ると位置の精度よりトポロジーの方がはるかに重要です。例えば、鉄道の案内図は絶対にありえない形の線路(真円でかかれている環状線など)が描かれてますけど、利用者に取ってはトポロジーが正しいので問題ないですよね。歩道橋などがどちらに接続しているかは、実はその中図の4. でもわかると思います。この自転車道は本当に三角形の形をしているのでちょっと違うのかも知れませんが、片方は橋の下を素通り、片方はそれぞれの側から橋の上に接続していてそこに横断歩道がない、ということが地図からも想像がつくでしょう。(この地域はPotlatch でYahoo! aerial が見れますので、参考にしてください。) 最後に下図の3. は、描くなとまで言いませんが、歩道橋が常にその交差している道路につながっているとは、限らないのでお勧めしません。大抵の場合それは高速道路を横断する歩道橋なのでそんなことはわかってるかも知れませんが、念のため。私は時々歩道橋を見つけても、その橋がどこに繋がっているか知らないときは、橋桁だけ描くことがあります。 --Nazotoko 21:59, 12 November 2009 (UTC)

parkingの対象範囲

ML(OSM-ja)での議論からの抜粋転記です。 駐車場はパブリックまたは制限付きパブリックなものを対象とすべきという意見があるが、具体的にはどこまでを対象とすべきかとの問いに対して、以下のような意見があった。

  • タグはAND 条件でどんどん範囲を絞る使い方をするので、個々のタグの示す情報は適応範囲が広い方がいいと考えられている。
  • 絶対に使えっこない消防車専用の駐車場とかでなく、料金をはらえばとか使えるとか、アパートの住人なら使えるとか条件次第で使えるものは parking をつけていいはず。
  • 何らかの制御をするとしても、要は適切にタグを追加すれば良いと考えるべき。
  • 駐車場を使える条件を定義できるタグは例えば fee, access, opening_hours, maxstay
  • Osmarender タイルは駐車場を使える条件を事細かに表示できる。
  • コンビニ専用駐車場であることを強く示したければ、コンビニの敷地を全部エリアにしてshop=convenience、その中に駐車場amenity=parking と building=yesを書いたらいいのでは。

--higa4 00:20, 11 November 2009 (JST)

Preset

このJa:Howto Map AからJOSM用50音順プレセットを生成したいと思います。プレセットの書き方を探していて、見つけました。 そこで、Ja:Howto Map A を機械読みするために細かいルールを設定しようとおもいます。

  1. 一番上の階層は「ア行」「カ行」... のみ。
  2. 次の階層の表題名はPOI (日本語)になる。
  3. 実例,類語 は無視します。
  4. タグ付け (基本) は
    • 歩道橋のようになってるときは、さらに下のサブメニューをつくって選択する。
    • 基本は全部そのまま付ける、name, operator, refはテキストボックスに入力を求める。religion, internet_access は選択肢が少ないので、コンボボックスにする。
  5. タグ付け (拡張）は、チェックボックスとかを付けて、付けない事も選択できるようにする。
  6. コメントは、余力があったら文字だけ表示。

来週末くらいには、第一版ができると思います。 --Nazotoko 02:13, 15 November 2009 (UTC)

待望の機能です。Wikiの記述とスムーズに連携できるといいですね。 --higa4 03:55, 15 November 2009 (UTC)

「タグ付け (基本)」の変換ルール

wiki プリセットの挙動
<pre>

</pre>

不問でamenity=parking と fee=yes が付けられる。
<pre>

</pre>

名前のテキストボックスに、「駐車場 (parking)」が入っている。詳細はJa:Tag:amenity=parking へのリンク
<pre>
  1. 敷地
  2. 通路

</pre>

サブグループとして「敷地」と「通路」ができる。
<pre>
  • amenity=fast_food/cafe/restaurant 実状に合わせて選ぶ

</pre>

「実状に合わせて選ぶ amenity:」とかかれた3つを選ぶコンボボックス。詳細はJa:Key:amenity へのリンク

タグ付け (拡張）に書くと必ずテキストボックスかコンボボックスになります。わかりやすいwiki を書くことの方が優先です。あまりこのルールにとらわれすぎないように。 --Nazotoko 20:22, 20 November 2009 (UTC)

その変換プログラムをここに公開しました。だれか気が向いたら、JOSMのプリセットも書き換えてください。presets タグにdescription とかを前のファイルからコピーして、Attach new File で同名で添付したら置き換わります。--Nazotoko 00:52, 11 December 2009 (UTC) 1.の階層について。項目が増えすぎて選べない選択肢が増えすぎたので多層化しました。変換プログラムはうまく使えなかったのであきらめました。すいません。--MaryHiroshige 02:01, 12 February 2012 (UTC)

牛丼チェーン店

丼物は、確かに牛丼が一番多いのですが、それ以外にも、カツ丼とか海鮮丼のチェーン店などもあります。牛丼チェーン店といっても、実際には牛丼以外もあります。牛丼だけだと対象が狭まるので、cuisine:ja=丼物 というのはだめでしょうか。 Ribbon 13:40, 18 November 2009 (UTC)

はい。いろんな丼物をあつかっている店がありますね。英語だとcuisine=bowl になります。OSMDocによると、まだbeef_bowl も bowl もマッピングされていませんね。牛丼も丼物屋にまとめますか？ --Nazotoko 05:30, 19 November 2009 (UTC)
その方がいいと思います。今、いわゆる牛丼チェーン店でも、牛丼以外を出すことが多いですし。 Ribbon 13:29, 19 November 2009 (UTC)

valueはまったく同じものを指すのであれば統一すべきですが、粒度が異なるものはそれぞれに別の値があって構わないと思います。私はbowl,beef_bowl,牛丼,丼物 いずれもあって良いと思います。一般に分かりやすいグルメマップがいつかできると想定すれば、丼物だけでは牛丼屋の探しようがなくなってしまいます。タギングをどちらかに絞るとしたらむしろ粒度の小さいものが後々のためには有用かと思います。食事のメニューは地図データから逸脱してしまうのでwebsiteタグなどでお店のサイトにリンクしておけば良いと思います。cuisine=*でも値の粒度はさまざまなものが例示されています。 --higa4 03:30, 20 November 2009 (UTC)

amenity=*, shop=*, operator=*,religion=* ようなのは、レンダリングやグループ化のために統一化する必要があるのですが、その他のタグは統一する価値がないまたは無理なので、何が書いてあってもいいです。ただ、cuisine タグはイギリス英語でかかれていることを期待されているので、できればそのように。　--Nazotoko 19:12, 20 November 2009 (UTC)

廃止後の扱い

施設が廃止された場合はどうするのが良いのでしょう?

  1. disused=yesを追加する
  2. 削除する

とりあえずコンビニなど閉店後は特徴の少ないものは 2、 学校など廃止後も外見でそれとわかるものは 1 としています。 特に学校は廃校になっても避難場所として指定されていたりするので削除はマズいかなと。 --Nahainec 13:48, 6 January 2010 (UTC)

建物や施設がなくなって更地になったなら、削除だと思いますけど、そうじゃないなら、disused=yesでいいんじゃないでしょうか。一応 implies されていますが、立ち入り禁止地区にはaccess=noです。完全に管理されなくなったら、historic=ruins,ruins=yes もありかもしれません。--Nazotoko 07:36, 7 January 2010 (UTC)

病院と医院の区別について(削除)

医療機関を表すタグとして、医院（amenity=doctors）と病院（amenity=hospital ）の２つがありますが、この２つの違いはなんでしょうか？
入院の可否の区別かとも思ったのですが、病院のタグを参照すると、入院治療が可能な場合も不可能な場合も含みます。 と書いてあり、わからなくなりました。
もし、明確でないのであれば、医療法上の「病院」と「診療所」で区別をするか、「病院」＋「診療所」と「施術所」（接骨院など）で区別をするというのはどうでしょうか？--MaryHiroshige
amenity=doctors と amenity=hospitalのそれぞれに「日本での解釈」という形で追記されたため、削除します。--MaryHiroshige 07:02, 29 January 2012 (UTC)

米屋

(昨日ちょっとSlackで話題になったのですが) 日本各地で見られる「米屋」(参考: Wikipedia「米穀店」)、のタグ付けに迷うことが多いようで、shop=convenience, greengrocer, deli, rice, food, raw_rice, foodなど様々なパターンが見られます。riceはOSM全体ではあまり一般的なタグではありませんが最も「米屋」のニュアンスに近く、米を中心にさまざまな物を取り扱っている小規模商店という点ではconvenience、未加工に近い農作物という意味ではgreengrocerも有りな気がします。日本では一般的な業態ですので何かタグ付の指針があればいいと思うのですが、どんなタグがふさわしいでしょうか。--Maripogoda (talk) 12:41, 4 May 2020 (UTC)

私は`shop=rice`がよいのではないかと思います。 --Tankaru (talk) 02:50, 5 May 2020 (UTC)
* 日本では米を主に販売する「米穀店」は独自の存在感をもった店舗であり、特有のタグを持ったほうがよいと思います。convenienceやgreengrocerでフィルタリングして店舗を検索し、米穀店を提示されたら違和感が大きいです。
* ただし、店舗の名称が「米穀店」であったとしても、米以外の品ぞろえが充実している場合は、`shop=convenience`など実態にあったタグを選択すればよいかと思います。
私は`shop=greengrocer`を使っていますが、使っていて違和感が有ります。米の店ですので`shop=rice`が良いと考えます。--Tadanet3 (talk) 12:47, 5 May 2020 (UTC)
* 私も米穀店については shop=rice が良いと考えています。米以外も扱う店舗は主要な品目を元に個別検討すれば良いと考えています。 --K Sakanoshita (talk) 15:16, 5 May 2020 (UTC)
* ご意見拝見しました。shop=*に並んでいる食料品系の値を見てみると、業態として定着していたり、食文化的に重要なジャンルの食材を扱っていたりするお店は専用のvalueが定義されているので、これだけ米と米屋が一般的な日本 (他の米食文化の国々も?) ではshop=riceに統一するのが良いかと思います。他の商材を扱っている米屋も、メインとなる商材がお米ならshop=riceで良いかと思います。--Maripogoda (talk) 02:22, 6 May 2020 (UTC)
* かなり昔に話題になった記憶があります。その時は、お米屋さんは他の国にもあるので、 shop=rice でよいのではないか、だったと思います。Ribbon (talk) 00:41, 7 May 2020 (UTC)
* shop=rice がよいと思います。よろず屋的なお店の場合は、shop=convenience でもよいと思います。今まで自然素材（JOSMのプリセット表現）で扱うとしたら、organic=yesなのかな？(shopタグは何？)とタグ付けしたこともありましたが、違和感があったので。--Taki3hira (talk) 01:20, 7 May 2020 (UTC)
* shop=rice を使っています。見かけることが少なくなりましたけどね。 higa4 (talk) 06:48, 7 May 2020 (UTC)

分割の提案

【提案】 このJA:How to map aページは肥大化していて、多数のテンプレートを読み込んでいる関係でエラーが出ており、有効に活用できない状態が続いています。モジュールを使用するテンプレートを約500以下に抑えればエラーは回避できると思われ、いくつかの解決方法が考えられます。例えば、記述の削減は有益ではないでしょうし、このページをあ～わまでの五十音1字ごとに分割するのは細かすぎるでしょう。サイズと分かりやすさの観点から、以下のように五十音の行ごとに10分割することが適当と考えます。

  • 類例として、ドイツ語DE:How to map aは2024年8月にA-Zまでの26音に分割されています。
  • なお、現時点で五十音インデックスはカタカナ表記になっていますが、ひらがな表記が適当と考えられるので分割に併せてひらがなに変更します。
  • 各分割ページ上部には五十音表インデックスを付け、相互に参照できるようにします。JA:How to map a#五十音順POIタグ一覧にある説明文も複製して掲載します。
  • A-Zは、非日本語ユーザー向け案内としての意味もあるようですが、これだけページに残ると違和感があるため、わ行に入れ込むのが穏当と考えます。

以上の通り提案します。--Pekachu (talk) 15:28, 19 November 2024 (UTC)

【賛成】ドイツ語ではすでに分割されていたんですね。エラーが起きないように、「highway=pedestrian」など、直書きに変えてしまおうかとか思ってました。現状のままを望む人はいないので、ぜひ、進めていきましょう。--MaryHiroshige (talk) 10:29, 20 November 2024 (UTC)

エラーが出るのは好ましくないので、分割案に賛成です。Tokada (talk) 11:42, 20 November 2024 (UTC)
分割案に賛成です --Nyampire (talk) 03:54, 23 November 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=JA_talk:How_to_map_a&oldid=2780207"