[OSM-ja] 組織的編集の提案: サービスエリア・パーキングエリアと、その駐車場の形状

2022年 11月 2日 (水) 02:56:35 UTC

いいだです。
ご意見ありがとうございます！

> okadaさん
ありがとうございます、それでは、いまのところの傾向としてはこんなかんじですね。
いったん、SA/PA表記でリストとか作成進めようかな、と思います。

SA/PA表記:  4 + Slack1 = 5
サービスエリア/パーキングエリア表記: 1 + Slack1 = 2

> batosmさん
はい、公式の記述はあくまでも目安であって、時宜によって変わってゆくものだと思います。
そこはWikiに申し送りとして記載します。


2022年11月1日(火) 0:52 batosm <beatreg+osm ＠ gmail.com>:

> capacityにどこまで正確性が求められるかわからないのですが、小型/大型兼用の有無に関する統一表記は難しそうです。
>
> NEXCO中日本と東日本のページでしか確認していませんが、中日本は「大型：32/小型：210（大型との兼用を含む）」とあり、兼用しなかった場合の純粋な台数がわかりません。東日本はシンプルに大型と小型の台数が書いてありますが、逆に兼用台数は不明です。
> 私自身はこれの表記方法に対する意見はありませんが、Wikiでの注記は必要かなと思いました。
>
> 2022年10月31日(月) 16:35 OKADA Tsuneo <tsuneo.okada ＠ gmail.com>:
> >
> > 岡田です。
> >
> > > SA・PAの表記について
> > 私はSlackでは「(省略形でない)サービスエリア/パーキングエリア表記が良いのでは？」と書きましたが、
> > SA/PA表記でも問題ないということであれば、それで良いと思います。
> > (IC/JCTもそのままにできますし)
> >
> > ・上り/下りを外しても良いのでは？と書きましたが、その情報が必要な人がいるのであれば、
> > 現状通りnameに入れることで良いと思います。
> >
> > ・大型車はcapacity:longというのも良いと思います。
> >
> >
> >
> > 2022年10月31日(月) 16:08 Satoshi IIDA <nyampire ＠ gmail.com>:
> >>
> >>
> >>
> >> いいだです。
> >>
> >> > メインの客用駐車場が複数のポリゴンに分割されるケース
> >> > 首都高のPAやうみほたるSAは、航空写真をもとに駐車場ポリゴンを描くのが困難
> >> 建物のなかに格納されているケースや、例えば、1階駐車場に90台、2階駐車場に30台、みたいな場合にどうするのか、と理解しました。
> >>
> >> 基本的には、サービスエリアのポリゴンのなかに駐車場のオブジェクトがあってほしい、というのが最低条件ですので、
> >> ケースバイケースで（LocationMindさんとも協議して）判断かと思っています。
> >> どうしても航空写真からは描けない場合は、その旨申し送りすることを想定しています。
> >> （全体数からすれば特殊ケースと思いますが、現状のバラバラぶりを正規化するよりはよほど省力化できます）
> >>
> >> その観点だと、gyotoku810さん提案の、
> >>
> >> parking:capacity:long=98
> >> parking:capacity:standard=528
> >>
> >> を、highway=servicesのポリゴンにくっつけるのが、たしかに合理的なのかな、と考えています。
> >>
> https://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces
> >>
> >>
> >> > 上り、下り、の記載について
> >> 他国ではどうしているのか、ということで、Overpassを使って眺めてみました。
> >>
> >> * UK: ほぼ指定ないが、nameタグの中にカッコ書きなどで記載あるケースあり（Ripley Services
> (Northbound)、のようなかんじ）
> >> * ドイツ: nameタグのなかに、東西南北、の表記あり（Raststätte Dollenberg Ost、みたいなかんじ）
> >> * フランス: nameタグのなかに、東西南北、の表記あり（Aire de Montélimar Est、みたいなかんじ）
> >>
> >> * US:
> >> nameのなかではほとんど表記なし
> >>     "name": "TA",
> >>     "official_name": "TravelCenters of America",
> >> のように、省略形をnameに入れている例もあり、省略しない形式もあり。正規化はされていない様子。
> >>
> >> また、branchタグが利用されている例あり。
> >> 例えば、Pilot Travel Center、の系列で、番号が入っている。どうも、同じ会社の支店番号の様子。
> >>
> >> ひとまず、上り、下り、についてはnameタグのなかに格納、がよさそうに思えます。
> >>
> >>
> >> > SA・PAの表記について
> >> nameのSA/サービスエリア表記についてはかなり拮抗していて、
> >> 決めの問題だなぁ、という印象が強いです。
> >>
> >> SA/PA表記:  3 + Slack1 = 4
> >> サービスエリア/パーキングエリア表記: 1 + Slack2 = 3
> >>
> >> 「現地表記を優先する（SA/PA）」か、
> >> あるいは「現地表記で短縮形の場合は、短縮しない形にする原則（サービスエリア/パーキングエリア）」か、
> >> 今週後半くらいにはどちらか決めたいな、と思っていますので、ご意見いただけると嬉しいです。
> >>
> >> 個人的には、利用者が利便なほう（慣れ親しまれているほう）をnameに表記したほうが良い気がしており、
> >> そうなるとSA/PA表記のほうがいいかも、という心情でいます。
> >>
> >>
> >>
> >>
> >> 2022年10月30日(日) 7:54 gyotoku810 <gyotoku810 ＠ gmail.com>:
> >>>
> >>> gyotoku810です。
> >>>
> >>> ・上り・下りについて
> >>>
> dierctionキーは0～360の数値やN,E,S,W,forward,backward等の機械可読な値が想定されているはずです。「上り」「下り」といった非形式的な値は適切でないと思われます。また"up"/"down"に置き換えてもいけません。「上り」「下り」は地物
> >>> （SA・PA）自体の方向を表しているのではなく、存在する位置を表していると考えたほうが自然です。まだ
> >>> branch=上り
> >>> としたほうがマシだと思いますがそれよりも、通常上下線でSA・PAは別物なので、nameタグに上り・下りの情報を入れたほうが良いと思います。
> >>>
> >>> ・capacity=*関連について
> >>> 日本のOSMにありがちな（自分も当てはまるかもしれない）やり方として、型に当てはまらないデータを既存のタグに無理やり押し込めようとしがちです。
> >>>
> >>>
> 調べたところ、大まかな目安（イメージ）として大型枠が長さ13m、小型枠が長さ5mのようですね。そしてその使い分けは法的な車種区分によるわけではなく、物理的・状況的にちょうどいいところに停めるのがマナー、くらいのものです。
> >>>
> >>> これを既存のcapacity:hgv,
> >>>
> capacity:motorcar等で表そうとするのは流石に無理だと思います。ちゃんと意味にあったキーを使ったほうがよいのではないでしょうか。taginfoで見つけた良さそうなキーは、
> >>> capacity:standard（小型車）
> >>> capacity:long（大型車）
> >>> です。別に提案プロセスが必要なものでもないので、これらのタグを活用されると良いかと思われます。
> >>>
> >>> ・駐車場のポリゴンと台数について
> >>>
> amenity=parkingのエリアにcapacity=*を付けるなら、エリアに含まれる駐車枠の数が台数とちゃんと一致するようにしなければなりません。しかし、台数のソースが公式情報、エリアのソースが航空写真だとすると両者の数は本当に一致するでしょうか？
> 駐車場を複数のエリアに分割する場合も同様で、各エリアに対し名前とエリアごとの駐車台数を入力しますが、合計台数を入力する余地はありません。
> >>>
> 公式情報の台数はSA・PAに紐付いた情報なので、SA・PAの地物に対して入力したいですね。ここでparking:capacity=*が良い選択肢となります。
> >>> P.S. 航空写真から駐車場エリアが描画できないときにも適用できますね。
> >>>
> >>> ・SA・PAの表記について
> >>> まず前提として、案は以下の2パターンに集約されると思います。
> >>>
> >>> (A)
> >>> name=地名SA
> >>> official_name=地名サービスエリア
> >>>
> >>> (B)
> >>> name=地名サービスエリア
> >>> short_name=地名SA
> >>>
> >>>
> 地図のみならず文章や掲示物など多くの場面で用いられるのは略称の「地名SA」の方なのは確かで、(A)が自然だと考えるのはよく分かるのですが、OSMをデータベースとして見たときに私は(B)のほうが自然ではないかと思います。Wikipediaの記事名が(B)のようになっているのと同じ感覚です。あとはもう決めの問題だと思います。
> >>> 念の為、地図上ではもちろん略称で表示されるべきです。標準タイルがshort_nameに対応すれば良いのですが。
> >>> なお(A)の場合、単に長いだけの表記を入れるのはalt_nameでも良いかと思います。
> >>>
> >>> ・例
> >>> highway=services
> >>> name=海老名サービスエリア (下り)
> >>> short_name=海老名SA (下り)
> >>> name:ja-Hira=えびなさーびすえりあ (くだり)    ←・・・？
> >>> parking:capacity:long=98
> >>> parking:capacity:standard=528
> >>> parking:capacity:disabled=8
> >>> parking:capacity:disabled:long=1
> >>> parking:capacity:disabled:standard=7
> >>>
> >>> building=retail
> >>> shop=mall
> >>> name=EXPASA海老名 (下り)
> >>>
> >>> gyotoku810
> >>>
> >>> _______________________________________________
> >>> Talk-ja mailing list
> >>> Talk-ja ＠ openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-ja
> >>
> >>
> >>
> >> --
> >> Satoshi IIDA
> >> mail: nyampire ＠ gmail.com
> >> twitter: @nyampire
> >> _______________________________________________
> >> Talk-ja mailing list
> >> Talk-ja ＠ openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ja
> >
> >
> >
> > --
> > 岡田常雄(OKADA Tsuneo)
> > tsuneo.okada ＠ gmail.com
> > _______________________________________________
> > 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: nyampire ＠ gmail.com
twitter: @nyampire
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://lists.openstreetmap.org/pipermail/talk-ja/attachments/20221102/7895a9db/attachment-0001.htm>