muramotoです。
三浦さんが北区のローカルマッパーであるということを前提として、インポートに賛成します。
理由
・地域のデータをどのようにするかは、地域の方の意見を最優先したいと私は考えます。もちろん三浦さんの他にも北区のローカルマッパーはたくさんいらっしゃると思いますし、インポートによってそれらの方々とコンフリクトが生じる可能性はあります。その場合は、地元の問題は地元で解決していただきたいとは思います。
一括編集に賛成いたします。
編集内容も問題なさそうでした。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
ハッシュタグ付き変更セットの取得は、osmchaのRSS経由でできそうな感じがします。(実際に試したわけではないです。すみません。)
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
間が開いてしまいましたが、import-mlに投稿しました。
https://lists.openstreetmap.org/pipermail/imports/2020-October/006407.html
1週間程度をめどにコメントを受け、その後にインポート作業に入ります。
___
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
インポート計画ページに英語説明を追記しました。
後ほどImport-mlにアナウンスする予定です。
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_GSI_Memorial_of_Natural_Hazard
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
みなさま
国土地理院から 自然災害伝承碑データのインポートを承諾いただきました。
nyampireさん、ありがとうございました。
OSM wikiページに英語説明を追加したのち、import-mlに投稿、インポート作業、の順に実施していきます。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
hayashi様
コメントありがとうございます。
hayashi様にご提示いただきましたが、期間を表す記法があるのを見逃していました。
> start_date=1914..1918 indicates some time during WW1.
とありますので、江戸時代については
start_date=1603..1868
としたいと思います。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
インポート用のgeojsonデータと、descriptionを外部リンクするためのhtmlファイルを作成しました。
https://github.com/tankaru/Japan-GSI-Import
お時間あればデータのチェックをお願いいたします。
muramoto
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
岡田様
ご確認いただきありがとうございます。
建立年はご指摘の通りです。start_dateに変更いたします。
あらためて"建立年"の値を確認したところ、異常値がいくつかありました。下記の扱いにしたいと思います。
・建立年=不明(1934？） → start_date=~1934
・建立年=1940 1994 → start_date=1940 (おそらく1940年に建立され、1994年に改修されたのではないかと推測しました)
・建立年=江戸時代 → start_date=江戸時代 (Approximationsの値にUTF8文字を使っても問題ないと考えました)
皆さま
国土地理院が「自然災害伝承碑データ」の提供を開始しました。
https://www.gsi.go.jp/bousaichiri/denshouhi_datainfo.html
https://twitter.com/gsi_oyochiri/status/1305733239336652801
このデータのインポートを検討しており、下記のようにインポート計画書を調製しました。
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_GSI_Memorial_of_Natural_Hazard
DistrictよりCountyのほうがよいという意見に賛成です。
ただ、Japan taggingのガイドラインでは、
・Metropolis・Prefecture（北海道は除く）・Subprefecture・District・Ward（東京23区は除く）・-chomeを付ける。
・City・Ward（東京23区のみ）・Town・Villageは付けない。
となっており、不統一感を覚えました。
郡・都道府県と市町村でname:enのガイドラインが異なる理由をご存知の方がいましたら教えていただけませんでしょうか。
muramoto
岡田様
申請への対応およびOSM wikiへ記載いただき、ありがとうございました。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
岡田様
OSMデータを拡充いただきありがとうございます。
作成頂いたJapan Censusのページを拝見したのですが、ライセンスがCC BY 4.0と記載されていました。
しかし、CC BYライセンスはODbLと互換性がありません。OSMに利用するためには、別途利用申請が必要であることがOSMFから示されています。
岡田様のほうですでに許諾を受けていらっしゃいますでしょうか？
まだであれば、OSMFJのほうで代理申請を受けているようなので、依頼してはいかがでしょうか？
資料：OSMFJ、CC BY
7月に行われた鎌倉マッピングパーティーでもareaselectorが紹介されました。
https://wiki.openstreetmap.org/wiki/JA:Kamakura_Mapping_Party2019
私もikiyaさんの意見に近い立場です。地理院地図は、手作業でのトレースを想定して利用許諾が下りていると私は考えます。areaselectorは手作業トレースの範疇を超え、機械的にデータを抽出し利用するインポートに近く、危ないのではないかとマッピングパーティーの場では意見を述べました。
編集者が日本におけるhighway=motorway の定義を知りながら編集しているのであれば破壊行為に該当すると考えます。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
muramotoです。
> ref:ISJ_JP
不要だと思います。
quarterとneighbourhoodへの分割はlocal
knowledgeで自由にやって構わないという指針を出すのであれば、ref:ISJ_JPを付けていてもほぼ無意味ですし、local
knowledgeで分割したタグを元に戻してしまうおそれもあります。
> localty (カテゴリ0)の扱いについて
neighbourhoodにすることに賛成です。
京都市の例を見る限りでは、neighbourhoodもしくはquarterのように見えます。
> 京都の町名重複箇所
そのままで良いと思います。
`landuse=forest`タグの定義のひとつとして、"managed
woodlands"があります。公園内の樹木エリアは、まさにこの定義に合致すると思います。
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dforest
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
facebookでコメントした内容と重複する項目もあるかもしれませんが、改めてコメントします。
> refタグ
使用しないことに賛成します。
>丁目、に対するタグの割当について
当面の対応として、大字・小字・丁目を分割せずにplace=neighbourhoodでインポートするのがよいと考えます。
Hi Jeffrey,
I don't know much about nominatim technology, but `place=state` is wrong in
Japan. We don't use it for now.
See the addressing scheme in Japan.
https://wiki.openstreetmap.org/wiki/Japan_tagging
In this case
province=京都府
region=近畿地方
is right.
(Note: region=近畿地方 is not a part of
legal-talkでの議論内容をOSM wikiにまとめました。
認識違いがあれば修正をお願いします。
https://wiki.openstreetmap.org/wiki/Copy_content_from_a_business_website
またAvailable dataの英語版は作りかけですが、こちらにも手を入れて頂ければと思います。
https://wiki.openstreetmap.org/wiki/Available_Data
___
Talk-ja mailing list
I made a OSM wiki page on this topic.
It's sorry to be late.
If I misunderstand your opinion, please modify the page or put your comment.
https://wiki.openstreetmap.org/wiki/Copy_content_from_a_business_website
muramoto
___
legal-talk mailing list
> what’s the difference in reading a printed sign on the street
and a shops website stating the opening hours for our purpose?
For me, "a printed sign on the street" is on-the-ground information,
and "a shops website" is not on-the-ground information.
muramoto
I understand that dominant opinion is the fact data published on the
official website is available to OSM.
It's good for the OSM community to be clear about available data.
I would like to ask again about similar cases that I do not understand
enough.
Assume that TESCO has published the shop
Thanks everyone.
I ask a simple question. May I copy the information of the TESCO Boston
Superstore to OSM?
https://www.tesco.com/store-locator/uk/?bid=2108
This website contains information such as
- addr=*
- phone=*
- opening_hours=*
- branch=*
The OSM data for this store does not yet contain
石野様
legal-talkへ投稿いただきありがとうございます。
私もまだ購読していないので、これから登録します。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
ぞあ様
ご回答ありがとうございます。
>
所有者や運営者による(一次データソース)並べ方に特別な創作性が無い事実情報であって、利用規約等で禁止されていないウェブサイトに掲載されており、データベース権を侵害しえない事項という条件への一致を持って等価と判断しています｡
(1)「事実情報である」
(2)「利用規約等で禁止されていない」
(3)「データベース権を侵害しない」
(4)「一次ソースである」
これらの4点を満たしていればOSMに投入可能である、とのご意見であると理解いたしました。
Potori様
パンフレットに関して利用可否を提案いただきありがとうございます。
私もPotori様のご意見に賛成です。
パンフレットに記載のデータは、別スレで議論中の(公式)ウェブサイトや、レシートの扱いに準じるものと考えます。
・第三者が発行したパンフレット：食べログのような扱いであり、利用不可
・該当施設管理者が発行して、道の駅などにおいてあるパンフレット：公式ウェブサイトと同様の扱いと考えられます。私は不可だと考えています。
あまの様
詳しく説明いただき大変ありがとうございます。
> 地理院地図を座標を求めるツールとしての使用はOSM側の規定にはありません
たしかにその通りですね。日本の「公式ウェブサイト」である地理院地図で「事実情報(住所文字列)」から「事実情報(座標)」に変換することは「公式ウェブサイトの事実情報」の範囲内かと思っていましたが、変換ツールは地理院地図の機能ではないことに気が付きました。理解いたしました。
(ちなみに変換ツールの利用規約はかなりゆるゆるでした。私には測量法に関する知識がないので使って良いのかダメなのか判断できませんでしたが。
石野様
> ウエブサイトのURLそのもの
私は、検索エンジンで調べたURLであってもOKだと考えています。
まずマッパーはその施設について、現地調査やローカルナレッジに基づいて、よく知っているということを前提とします。
ときどき話題に出ますが、「マッピングしたい施設をGoogleマップで検索して場所を確認し、現地に行って、現地調査でマッピングしてよいか？」という構造と同じだと思います。
1. Googleで施設を検索し、
2. URLを知り、
3. ウェブサイトにアクセスして内容を確認し、
4. 自らの知識に基づいてそのURLが該当施設のものであると判断し、
5.
あまの様
お返事ありがとうございます。
> どの段階でも現地調査が入っていない点が問題です
私も同意です。現地調査は必要であると考えています。
であるからこそ、「公式ウェブサイトの事実情報であればOSMマッピングに使っても良い」ということを前提にした場合、現地調査は必要なくなってしまうことが導かれてしまったので、どこかが間違っていると考えました。
「公式ウェブサイトの事実情報であればOSMマッピングに使っても良い」という前提が間違っているのでしょうか？「ローソンリモートマッピング」のどのステップが間違っているのでしょうか？
ローソンリモートマッピングの例は、「公式ウェブサイトの事実情報であればOSMマッピングに使っても良い」という指針を立てた場合はこういうことが可能になると示したものです。この事例に問題があるのならば、「公式ウェブサイトの事実情報であればOSMマッピングに使っても良い」という指針に問題があったということになるかと思います。
(なお、この事例では事実情報しか使っていないので、著作権的には「違法」ではないはずです。ローソンのデータを大量に使ったら「データベース権」の観点で問題になる可能性はありますが)
> 公式ウェブサイトについては電子的な「現地」で、地理的な現地に掲示されている情報と等価と考えているためです。
全く同じ情報であっても、現地調査に基づいて投入するケースと、公式ウェブサイトのデータを転記するのは違うと考えます。
旭川市のローソンに出向き入口自動ドアに書かれてある文字を見て`branch=旭川東４条店`とデータを入力するのと、公式ページを見てリモートで同じデータを入力するのがOSM的に「等価」であるとは私には思えません。
> 「そっちの方がマッピングが楽しそうじゃん?」
公式サイトの「事実情報」が利用できるとしたら、私もぜひ使いたいです。リモートマッピングが非常にはかどります。
たとえばローソン 旭川東４条店は、まだOSMマッピングされていません。
https://www.e-map.ne.jp/p/lawson/dtl/216237/?=al1,al2,al3,nm
https://www.openstreetmap.org/#map=19/43.78323/142.37762
ですが、公式サイトの「事実情報」を使えば、
住所が「北海道旭川市東４条７‐２‐１」であることがわかるので、
地理院地図経由でおよその位置が判明します。
みなさま
公式サイトの情報であればOSMに投入してもよい、と判断されている(海外の)事例・議論があったら教えていただけませんでしょうか。
私が把握している範囲では、ODbL非互換データは有無を言わさずアウト、という判断が支配的であると思います。
いいださんに紹介していただいた議論もそうですが、
https://lists.openstreetmap.org/pipermail/talk/2018-May/080662.html
最近タグ付けメーリングリストに流れてきた事例では、ODbL非互換データを入れ続けて(警告も無視したために)、10年間のアカウント停止処分が下されています。
> ただし、この改定案は法律における不遡及の原則と同様、過去にマッピングされたデータには適用しないことを明記してもらいたいです。
同意します。ただ過去のデータは全部OKとするのもまずいだろうと思いますので、協議のうえケースバイケースで対処することにしてはいかがでしょうか。
以下備考記載案です。
みなさま
北海道廃線マッピングの議論において、Available
Dataでは「ウェブサイト上の店名、住所、電話番号など」が利用OKとなっているが、これを字義通りに解釈すると問題が大きい(食べログなどの情報転記も可能と解釈されうる)ことが指摘されました。
https://lists.openstreetmap.org/pipermail/talk-ja/2019-May/010565.html
https://wiki.openstreetmap.org/wiki/JA:Available_Data
そこで、下記のように改訂したいと考えております。皆さんのご意見をお伺いしたいです。
こんにちは。
残念ながらマッピングパーティーには参加できないのですが、先日に百舌鳥古墳群オフラインマッピングをやった際の経験から、いくつかお願いしたいことがあります。
・現地では「古墳」として認識されているのか、「陵」として認識されているのか確認して欲しいです。現時点では、OSMやWikipediaでは「古墳」、地理院地図や自治体ページでは「陵」となっているようで、どちらが適切なのかよくわかりませんでした。また、例えば大仙古墳にはたくさんのalt_name_N
みなさま
中国地方において廃止された自治体をマッピングしている事例が確認されました。
MLまたはfacebookで合意を取ってほしい旨を変更セットで伝えましたが、拒絶されました。
私は以下の点に問題があると考えました。
(1)廃止自治体リレーションのセンターノードにplace=hamletが用いられているが、現在の日本のタグ体系では
place=hamletは定義されていない。
(2)廃止された自治体に対してadmin_levelタグを付与するのは問題が生じる可能性がある。
(3)廃止された自治体の形状のデータソースが不明。
いいださんがOSM-talkの関連議論をTwitterで紹介していたので、要約してみました。いろんな人の意見が入っているので、一貫した説明にはなっていません。
https://lists.openstreetmap.org/pipermail/talk/2018-May/080662.html
* WikipediaはODbLと非互換なので使わない。
* WikidataはCC0なので使える。
* 事実情報は著作権で保護されない。WikipediaでもWikidataでも事実情報なら使える。
*
＞現地にもほぼ記載がない、あるいは調べることができないけれども事実である、というものがあると思っていて。
＞例えばpower関連のviltageタグや、railwayで使われるgauge, frequency, voltageタグあたりは
＞現地の記載ではなく、かなりの確率で、なにかしらの情報源を参照しているであろう、と思っていたりします。
私は、インフラ系は特に業務に携わるなどにより詳しい人が多いので、目の前で何らかの資料を参照しなくても自分の知識のみでマッピングできる人もいるであろうと解釈しています。source=knowledgeかと。
muramoto
＞JA:Available
Dataのページにある「ウェブサイト上の店名、住所、電話番号など」が「事実情報」としてマッピング可能であるという記述からは、どのようなウェブサイトならば利用してよいのかということが読み取れないからです。
なるほど。たしかにこの記述から判断すると、『「Wikipediaに記載された名称」は「事実情報」としてマッピング可能である』と読み取れますね。気が付きませんでした。
いいださま
お返事ありがとうございます。
いいださまのコメントで気づかされましたが、確かに「法(著作権)」「規約」「規範」をひっくるめてしまっていたようです。
改めて私の意見を述べます。私が反対するポイントは「規範」です。
私の理解では、OSMはこれまでデータソースにはかなりの厳格さを求めてきました。"Whiter than
white"という言葉も聞きます。まさに「李下に冠を正さず」「法的にOKであろうと、OpenStreetMapの内部規範としてNG」がOSMのスタンスかと思います。
こちらでも議論が進んでいるようなので少しだけ。
>地物の属性をWikipediaから（文章をそのまま使っているわけではないので"問題ない"と思う）
Wikipediaの属性情報(名称など)をOSMに投入しても問題ないとのご意見でしょうか？
私はこれには反対です。
これを許容した場合、Googleマップに登録された店舗名称などをOSMにコピーするのがダメな理由がなくなってしまうと思います。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
地理院地図をソースとしてOSMに追加しました。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
あ、私の案だと、犀川の支流をどのリレーションに入れるのか難しいですね。
鍋太郎さんの案のほうがよさそうです。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
●湖の扱い
現時点での定義では、エリア要素(riverbank, waterbody)は承認されていないようです。
ですので湖も不可ということになろうかと思います。
とはいえ、湖(natural=water + water=lake)を`waterbody`要素として入れてしまって良いのではと思います。
"Not approved"は使っちゃダメということではないので…
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
「スーパーリレーション」と表現してしまいましたが、
単に「リレーションを主要メンバーとして持つリレーション」くらいの意味です。ですのでリレーションのタグは以下を想定しました。
name=信濃川水系
type=waterway
waterway=river
、、、type=waterwayのメンバー種類として、リレーションは含まれていないんですね。まぁ、私も使っちゃっても良いと思いますが。
https://wiki.openstreetmap.org/wiki/Relation:waterway
nameにするのかofficial_nameにするのかは難しいところかなぁと感じます。
●nameの使い分けについて
基本的なnameの使い分け(個々のウェイには現地の名称をつけ、alt_nameは不要)に賛成します。
ただ、リレーションの名称を`name=千曲川のリレーション`と提案されていますが、グッドプラクティスの「name
タグを説明に使わない」に反すると考えます。
https://wiki.openstreetmap.org/wiki/JA:グッドプラクティス
そのため、千曲川リレーションの名称は`name=千曲川`でよいと考えます。
●支流の扱い
現状のリレーションでも、`side_stream`ロールをつければ支流を追加することができます。
送電線は、type=route + route=power が広く使われています。ですので"In Use"と考えて指摘しませんでした。
なお、送電線を type=power + power=circuit にする提案もあります。
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal
個人的には、送電線をrouteとするのは違和感があるので、後者のほうが好みではあります。
muramoto
___
みなさま
さきほどTriglav2018氏から変更セットに回答がありました。
https://www.openstreetmap.org/changeset/65710253
取り急ぎ連絡まで。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
みなさま
コメントありがとうございます。
私なりに今回の件をまとめてみました。
【確認できたこと】
(1)河川リレーションにtype=routeをつけるのは間違いである
(2)Triglav氏の解説ページ[*]に記載されたリレーション作成事例のうち、河川、トンネル、駅の通路をtype=routeでリレーション化するのは間違いである。そのほかにも間違ったリレーションが作成されているのか、個別事例で確認が必要。
(3)wikidata=*タグがつけられているからといって、wikipedia=*タグを削除してはいけない。
[*]
みなさま
【要約】
wikipediaに表示するために河川リレーションの「破壊」編集が進められています。どなたか対処いただけませんでしょうか？
【背景】
信濃川の河川リレーションが、type=waterwayからtype=routeに変更されていました。
そのため、データを修正したうえで、type=waterwayが正しいことを変更セットで指摘しました。
https://www.openstreetmap.org/changeset/65407373
すると、上記変更セットに回答がないままに、再度type=routeに戻されてしまいました。
えっと、物事には順序というものがありまして、
一連の物事を進める「前」に、どういった順序で物事を進めるのかを示すステップが必要だと思うのですよ。
今回はtalk-jaで「順序」が提示されなかったので残念だなぁと。
--
おそらくですが、OSMタグと日本法規との対応付け、`transportation_mode`新設だけでなく、`highway=motorway`のImplies定義変更なども今後のステップにあるのだろうと推測しています。提案者のhayashi様であれば、今回の提案にともなう影響度合いやJapan
当初の提案内容は、新規タグ`transportation_mode`(例：`transportation_mode=motorcar @
大型`)の提案でした。
本投票ではではその内容がなくなっています。
いつの時点で`transportation_mode`が提案から外れたのか分かりませんが、`access`タグと国内法の対応関係については私には主たる検討範囲の外だったので、「中立(abstrain)」として投票しました。(投票済みです)
muramoto
___
Talk-ja mailing
OSM
Wikiに記載していた「日本における銘板情報のマッピング」を、Hayashi様が削除(取り消し線の追加)され、議論ページに「不適切な書き込みに対する対応」としてtalk-jaでの議論を記載されたようです。
https://wiki.openstreetmap.org/wiki/JA:Key:tunnel
https://wiki.openstreetmap.org/wiki/JA_talk:Key:tunnel
To hayashi様、Ras and Road様
ご教示ありがとうございます。
highwayオブジェクトのstart_dateについては、供用開始日とみなすのが良い・現実的である、ということで了解いたしました。
では、今回の提案においては、
竣工日 tunnel:start_date
供用開始日 start_date (highwayオブジェクトの属性として付与する)
という使い分けになりますね。
To hayashi様
hayashi様
ご提案のとおり、
highway:start_date ←供用開始日
tunnel:start_date ←竣工日
とするのもひとつのアイディアであると思います。
私が懸念したのは、道路そのものに供用開始日と竣工日が別に存在するのではないか、ということです。もしそうであれば、highway:start_dateが道路の供用開始日を指すのか竣工日を指すのか不明となってしまいます。
詳しい方のコメントをいただきたいです。
muramoto
___
Talk-ja mailing
石野様
ご意見ありがとうございます。
`end_date`が誤解を招きやすいというのは理解できます。
例えば、
`highway=construction`+`construction=trunk`+`end_date=*`
とあった場合、工事終了日なのか道路供用終了日なのか分かりにくい、ということであると思います。
さらに、工事が完了した際に`end_date=`を削除するのを忘れた場合、
`highway=trunk`+`end_date=*`
となってしまい問題が大きくなってしまう、ということもあるかと思います。
みなさま
トンネルの竣工日のタグを`opening_date`と提示しておりました。
しかし、`opening_date`は「予定日」だったようで、「竣工日」には適していないようです。
https://wiki.openstreetmap.org/wiki/JA:Key:opening_date
Ras and Roadさん、ikiyaさんからは、竣工日と供用開始日は区別したほうがよいとのご意見をいただいています。
`start_date`の定義を読むと、「竣工日」と「供用開始日」のどちらにも使えるように記載されており、単純な区別が難しいです。
hayashi様
コメントありがとうございます。
OSM_Wikiの「JA:Key:tunnel」に「日本における銘板情報のマッピング」を追記したようですが、そこは「翻訳ページ」ですので、どこか他の適したページへ移動させてはいかがですか。
>
JAページに日本語話者向けの情報を記載しているページはそれなりにありますので、特に問題ないと考えております。
> 「日本における」とあるので 日本特有の事なら JappanTagging の「議論」に記入するのが妥当でしょうか。
>
tunnel:*は細かいことなので、Japan Taggingの「本ページ」に記載するのは躊躇します。
Ras and Roadさん
ありがとうございます。
「トンネルの銘板」に記載されている幅員が「通行部分の幅」を示しているということであれば、
これはトンネルの属性(tunnel:width)なのか、道路の属性(highway:width)なのか、悩ましいです。
厳密に考えれば道路の属性(highway:width)のように思うのですが、ドンネルの銘板に記載された情報を道路の属性に書き込むのも違和感があります。
なお`width`の定義では「実際の幅」とされています。トンネルの場合は「内空幅」が該当するように思います。
追記：
銘板には「幅員 4.5m」とあり、
(a)の長さを計測すると約5.5m
(b)の長さは写真から推定すると約4.5mでした。
私は(a)の長さが「トンネルの幅員」だと思っていたのですが…
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
みなさま
先日にレーザー計測計を購入し、トンネルの幅を測ってみました。
すると、銘板に記載されている「幅員」と一致しませんでした。
トンネルの「幅員」とは、どこの長さを指すのか、ご存知の方はいらっしゃいませんでしょうか。
https://pbs.twimg.com/media/Dql7EDdU0AAKHpP.jpg:large
よろしくお願いします。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
基本的な方向性に賛同します。
(1)`transportation_mode:motorcar=大型` よりも、`motorcar:transportation_mode=大型`
のほうが良いのではないでしょうか？
(例えば、tunnel=yesに詳細情報をつける際は、tunnel:nameの順序となります)
(2)シンプルに、`motorcar:type=大型`または`motorcar:type:jp=大型`ではいかがでしょうか。もっとシンプルに、`vehicle:type:jp=大型`はいかがでしょうか。
深谷市櫛挽地区の防風林をトレースしてみました。
樹木の様態が細かく見えるので、詳しい人なら樹種までタグ付けできるかもしれません。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
いいだ様
各自治体からトレース許諾をとっていただきありがとうございます。
wiki記載内容についての提案ですが、別途トレース許諾を得たことをどこかに記載したほうがよいのではないでしょうか。
現時点での記載内容だと、CC BYライセンスなのでトレース利用できる、と誤解を生むのではないかと思いました。
ご検討ください。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
hayashi様
ありがとうございます。
あまり使い方を理解できていないかもしれませんが、とりあえず作ってみました。
編集用リンク：
https://github.com/tankaru/JOSM_Presets/blob/master/EasyPresetsTunnel.xml
ダウンロード用リンク：
https://github.com/tankaru/JOSM_Presets/raw/master/EasyPresetsTunnel.xml
("Restrict editing to collaborators only"のチェックを外したので、誰でも編集できるはず…？)
みなさま
トンネルの銘板マッピング向けにJOSMプリセットを作成したので共有しました。
https://1drv.ms/u/s!AvZ5JdN9PK_-j0-tsVo-BuIQdTsJ
(プリセットの作成にはEasyPresetsを使用させていただきました。作成者のMaripo GODA様、ありがとうございます。)
質問なのですが、
JOSMプリセットファイル(XMLファイル)の公開・共有に適したサービスはございませんでしょうか。
個人的には、以下のようなことができるサービスが良いのかなぁと考えています。(なんとなくの優先度順)
(0)まずはXMLファイルが共有できる。
(1)osm
JOSM用プリセットをOneDriveに上げました。よろしければお使いください。誰でも編集可能にしてあります。
https://1drv.ms/u/s!AvZ5JdN9PK_-j0-tsVo-BuIQdTsJ
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
Ras and Roadさん
ご意見いただきありがとうございます。
では、
tunnel:construction:owner=*
を第一案とさせていただきたく。
(tunnel:inscription:ownerを採用する場合、前述したように他のタグもtunnel:inscription:lengthといったタグにしないと整合性が取れないように思いますので、できれば避けたいです)
1週間ほどみて他のご意見が出ないようでしたら、wikiへの記載等をすすめます。
muramoto
___
いいだ様
糸魚川市様から許諾をとっていただき、ありがとうございます。
糸魚川市様に対してもこの場を借りて感謝申し上げます。
で、ちょっとだけですが早速トレースしてみました。
解像度はBing<<地理院ort<<糸魚川市ort
と圧倒的ですね。
鉄道レールもはっきり見えるので、レール分岐マイクロマッピングもできそうな雰囲気です。
ありがとうございました。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
>block_numberが日本だけで使われているのであればよいのですが、
>実際には、フィリピンの一部（まだストリートが無い振興開拓地で、まだ開発中のところ）でも使われている、と聞いています。
>なので、JPは、あったほうがよいかな、と思っています。
日本のplace=neighbourhoodと海外のplace=neighbourhoodは定義が異なるように、
日本のref:block_numberと海外のref:block_numberの定義が異なっていても問題がないように私は思います。
muramoto
＞なので、(a)(b)両方ということになるでしょうか。
なるほど。ありがとうございます。
(a+b)「神奈川県」は発注者（施主）である。建設時は「発注者（施主）=owner」であったが、ownerは変更されている可能性が高い。そのためownerには入力しない。なお現時点では『発注者（施主）』に該当するタグが見つかっていない。適切なタグが見つかるまでは「神奈川県」をタグに入力するのは待つ。
って感じですね。
ということで(?)、『発注者（施主）』タグの案をいただければと思います。
自分で書いておきながらなんですが、
みなさまのご意見を確認させていただきたいのですが、
(a)銘板に記載されている「神奈川県」はタグに入力しない。現時点ではownerが変更されている可能性が高いため。
(b)「神奈川県」はownerではなく施主である。施主に該当するタグが適切に選定されるまでは、「神奈川県」をタグに入力するのは待つべきである。
のいずれのご意見になりますでしょうか？(または他のご意見でも)
wikiに記載するにあたって、書きぶりを調整したいので。
muramoto
___
Talk-ja mailing list
＞案(4) ref:block_numberを新設
＞・boundary=administrative
＞・ref:block_number=*
なるほど。これはアリですね。
＞ref:JP:block_number
boundary=administrativeをつけるのであれば、日本の行政体系の一部であることは明らかなので、JPは不要と考えます。
admin_level=11の策定については慎重であるべきと私も考えます。
ですので現時点での議論では、積極的に策定する理由に乏しいと思いますので、これ以上議論が発展しない場合はペンディングでしょうか。
矢岳第一トンネルの例に限って言えば、
北側の「天險若夷」と南側の「引重致遠」は、どちらもトンネル名ではない、ということではないでしょうか。
(では「天險若夷」「引重致遠」は何かというと…historic=memorialとかでしょうか？)
もし実際に両入口で扁額名に差異がある場合は、銘板優先でしょうか。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
ちょっと先走って、先行的に入力したデータでトンネル情報表示マップのサンプルを作ってみました。
https://umap.openstreetmap.fr/ja/map/map_254999
あと、タグ案が固まったら、wikiへの記載と合わせて、(EasyPresetsで作った)JOSM用プリセットを共有する予定です。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
みなさま、ご意見ありがとうございます。
竣工日であれば tunnel:opening_date ですね。
もちろんtunnel:opening_date=1984-02も推奨で。(計算が面倒でさぼってました)
ownerについては、必ずしも現況を表しているわけではないので、私も微妙だなとは思います。
ただ、トンネル銘板に限らず町中にある看板等が、必ずしも現況を表しているわけではないので、現況がわかったらその時点で書き換えればよいのかなと思っていました。
他の案としては、
tunnel:construction:operator=神奈川県
とか
■place=city_blockについて
私は、
「addrはPOIに対して付与するものであり、
エリア(boundaryオブジェクト)に対しては付与しない。
エリア(boundaryオブジェクト)にはplaceを付与する。」
と認識していました。
番、街区をエリアで描いた場合に、付与するタグは何が良いでしょうか？
案(1)city_blockを使う
・boundary=administrative
・place=city_block
・ref=*
・(街区符号の場合はnameはなくてもよい。番地の場合はname=1番)
・(admin_level=11については後述)
みなさま
トンネルの銘板に記載されている情報をマッピングしたいと考えています。
例えば次の住吉隧道の場合、
https://www.dropbox.com/s/t6soyhvknf85q2p/IMG_0422.jpg?dl=0
highway=*
tunnel=yes
tunnel:name=住吉隧道
tunnel:start_date:ja=昭和59年2月
tunnel:length=95.0
tunnel:width=21.2-25.2
tunnel:height=4.7
tunnel:type=RC2連箱型函渠
tunnel:owner=神奈川県
みなさま
Leo Gaspardさんからplace=city_blockの採用について意見が上がっております。
これを採用した場合、addrとplaceの対応は次のようになるかと思います。
住所 | POIにつける住所 | エリアにつける地名
--
大字、町 | addr:quarter=* | place=quarter
小字、丁目 | addr:neighbourhood=* | place=neighbourhood
街区符号、番地 | addr:block_number=* | place=city_block(Leo Gaspardさんの案)
住居番号 |
非常に微妙なラインです。
ダメな理由
・Available Data(
https://wiki.openstreetmap.org/wiki/JA:Available_Data)に記載されていない。
・トレースしてよいと明示的な許可がない。
良い理由
・行政境界は物理的実体がない。現地の看板は、物理的実体がないオブジェクトの"準Ground truth"であると考えられる。
私は、公園内の池の名前をタグ付けする際に公園に設置された看板を見ることがあります。
看板に記載された池の名前も"準Ground Truth"だと思いますので、今回の例がダメとは言いにくいです。
lawyer:ja=司法書士
はいかがでしょうか？
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
アクションカメラを複数使う事例はこちら
https://blog.mapillary.com/community/2017/01/31/mapping-with-action-cameras-mapillary-and-openstreetmap.html
360度カメラを使う事例はこちら
https://help.mapillary.com/hc/en-us/articles/115001464709-Mounting-a-360-camera
ご参考まで
___
Talk-ja mailing
＞ただ高原という要素は見当たりません。
自然物を意味するnatural=*タグは、確かにあまり整備されていないのが現状ですね。
「高原」も現状では適切なタグがないので、暫定的にplace=localityをつけても良いのではないかと思います。
＞住民の有無でhamletとlocalityを使い分けるという理解で合っていますか？
はい。原則はその通りと考えます。
…細かく言えば、住民が住んでいる場所を意味する名前なのかそうでないのか、という区分になる気もしますが、ほんと細かいところなので…
＞あと観光地に関連することで、複合リゾート施設についてですが
一般的なルールはないと思いますので、私の個人方針を述べます。
(およそのところはいいだ様と同意見かと思います)
(1)自然物であれば、natural=*をつける。場合によってはplace=localityつけることもある。
(2)自然物でないエリアの名前であれば、place=localityをつける
(2-1)旧大字や「～集落」「～地区」は、place=localityは不適であると思う。place=hamletを導入するのが良いのではないかと考えている。
(2-2)「温泉街」のように、明らかに観光向けであればtourism=attractionをつける。place=*は不要と考える。
batosm様
ご意見ありがとうございます。
batosm様の感覚のとおり、日本ではplace=city/town/villageは市/町/村と定義されています。詳しくは日本向けの定義をまとめたページをご確認ください。
https://wiki.openstreetmap.org/wiki/Japan_tagging
上記ページを参照すると、千代田区をtownとしたタグ付けは間違いであることが確認できます。
ただ、place=city/town/villageの各ページに日本向けの解説がなかったことも確かなので、この機会に追記いたしました。
かなり間が開いてしまいましたが、特にコメントありませんでしたので前記提案のように JA:Available Dataを変更いたします。
muramoto
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
muramotoです。
2018年7月22日(日) 10:47 石野貴之 :
> (1) 道路を編集中、国道/都道府県道/市町村道等の区間や、境界となる交差点の位置について疑義が生じた場合、
> ・Wikipedia記事
> ・各自治体が公表しているWebGIS
> を根拠にして編集を行うことは禁止という認識でよろしいでしょうか。
>
これらのデータ利用は禁止です。
もし自治体が OSMと互換ライセンスでデータを公表しているのであれば使えるのでしょうが、判断が難しいので使わないのが無難でしょうね。
使えるデータはこちらに記載されているものに限定するのが安全かと思います。
(1)ja-Hira, ja-Kana, ja-Latnの統一について
田口さんがご指摘されたとおり、ひらがな(片仮名)とローマ字の互換性は完全ではないので、どちらか一方だけでよいことにはなりません。重複しても問題ないと考えます。
マッパーの視点から言えば、日本人マッパーは「かな」で入力するのが容易でしょう。一方、外国人利用者は、ローマ字で入力されていたほうが利用しやすいでしょう。データ処理ソフト側で適切に処理してほしい案件です。
(2)ja-Furiの新設について
必ずしも反対するものではありませんが、慎重にしたいです。
レオ様
お返事いただきありがとうございます。
＞「name=2」については、JOSMのプリセットのために、必要です。
なるほど。ではJOSMのプリセットが不適切なんでしょうね。ref=2は良い形かもしれません。
＞place=city_block, admin_level=11
日本のタグ体系を大きく変更する提案になるので、多くの人のご意見を待ちたいと思います。
＞番地の区画の調べ方。
ありがとうございます。足で調べたのですね。お疲れ様です。逆に言うと、番地区画のマッピングはそれだけ大変ということなのですね。
muramoto
1. toll=noへの変更
問題ないと思います。
無料の自動車専用道路はよくありますので、ネットワーク性を壊すことはありません。
noteやfixmeに一時的な無料措置であることを記載しておくのがよいかと思います。
2. HOTOSMのクライシスマッピングについて
おそらくですが、国土地理院が被災地の航空写真撮影を進めているものと思います。
例えば、今年4/11に発生した中津市土砂災害ですが、被災当日にヘリで撮影したようです。
https://maps.gsi.go.jp/development/ichiran.html#t20180411_ooita_dosha
レオ様
name:ja-Hrkt → name:ja-Hira
name=2 → name=二丁目 が望ましいと思います。
name:ja-Hira=1ちょうめ → いっちょうめ
place=city_block, admin_level=11 →
日本では定義されておりませんが、番地を表現するには確かに必要になりそうですね。有識者の方々のご意見をお聞きしたいところですが、いかがでしょうか。
ちなみに、番地の区画はどのように調べられたのでしょうか？ちょっとやり方が思いつかなくて…
muramoto
>> もし、家に「ふじみ野市清見２−４−１５」のサインが貼ってあったら、その家に「addr:housenumber=15」をタグするのができますか。
>はい、これは大丈夫という認識です。
>個人の名前（佐藤さんとか鈴木さんとか）が入っていなければ大丈夫。
では、JA:Available Dataを次のように変更して良いでしょうか？
https://wiki.openstreetmap.org/wiki/JA:Available_Data
●現状
判定：×
用例：個人住宅の表札
判定の理由：個人情報と考えられるため
補足：使用(マッピング)しない
●変更案
判定：△
＞Can I just add addr:province, addr:city, addr:quarter, addr:neighbourhood
and addr:block_number tags to polygons that map the appropriate area?
まず原則としては、エリアに対してはこれらのタグは使わず、`place=*`を使います。
ふじみ野市の例についても、`place=city`は付いていますが、`addr:city=*`は付いていません。
`addr:*`はPOIに付けます。
＞住所はどう翻訳できますか。「addr:quarter:ja-Latn=Kiyomi」ですか。taginfoにそのようなタグがないから｡｡｡
addr:quarter:ja-Latn=KiyomiでOKです。確かに使っている人はいないようですが、使って大丈夫です。
＞何か道具を使って「addr」のタグを入れますか。
JOSMのEasyPresetsプラグインを使うのはいかがでしょうか。自分でaddr:quarter:ja-
Latnなどのプリセットを作ることができます。
https://github.com/maripo/JOSM_easypresets
＞「name:ja-Hira」と「name:ja-Latn」は同じ情報を伝えませんか。
その通りです。基本的にはどちらかだけで問題ないと思います。
＞そして、nameの漢字を知らなければ、どうしますか。たとえば、「Kaisei」はビルに大きく貼ってありますが、その言葉の漢字は知りません。もしかしたら漢字がないかな。その場合、「name=Kaisei」もいいですか。それとも、「name:ja-Latn=Kaisei」（「name」なし）の方がいいですか。
nameタグについて、厳密なルールはありません。
(1)私個人の考え
osm wikiには、"Note that OSM
レオ様
ちょうど解決されたようでなりよりですが、実は少しnameタグの定義があいまいです。
日本のタグ定義はJapan taggingに基本的な取り決めが記載されています。
https://wiki.openstreetmap.org/wiki/Japan_tagging
昨年、歴史的に使用されている`name:ja_rm`を`name:ja-Latn`に変更しようという議論がありました。しかし明確な合意には至らず、Japan
taggingは`name:ja_rm`のままです。
三浦様
iDは360画像に対応しているのにJOSMはなぜ対応していないんだろうと悶々としていたので、さっそくインストールしてみました。
下記環境でばっちり動きました。
最初はドラッグしても視点が動かないなぁと戸惑いましたが、視点移動はシングルクリックなんですね。
ドラッグ操作できるようにするか、操作方法インストラクション表示がほしいなぁと感じました。
それ以外はもう正式版にしてしまっても良いくらいかと。
大変ありがとうございました。
動作環境
・JOSMバージョン13878(ローカルにインストール)
・OS:Windows10
1 - 100 of 231 matches
Mail list logo
