[OSM-ja] 百舌鳥古墳群マッピングパーティのお知らせ（６月３０日）
とし＠ご無沙汰です． 大阪府堺市にある百舌鳥古墳群のマッピングパーティを6月30日にしようと思います． https://countries-romantic.connpass.com/event/135021/ もし興味あり＆ご都合が合えば，是非ご参加頂けたらと思います． 当日は，大仙陵古墳（仁徳天皇陵）＊以外＊の古墳を主に作図しようと思いますが， 百舌鳥古墳群のOSM地図は，2008年4月に大仙陵古墳のノードを入れてから， 多くのOSMerの方々の編集を経て，今日に至ります． 私は最近は子育てもあって，あまりアクティブに動けていないのですが，皆さんの 成果を見ながら，ここまで来たんやなぁと感慨深いものがあります． マッピングパーティイベント当日では色々不手際があるかも知れませんが， どうかよろしくおねがいします！ ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] Merchandise(OpenStreetMap 帽子)再び
としです． 2014年の話題になるのですが， https://lists.openstreetmap.org/pipermail/talk-ja/2014-July/008447.html [OSM-ja] Merchandise (OSM 関連グッズ)(ステッカー，帽子，風呂敷) と言う内容で，OpenStreetMap 帽子を作ったことがあります． この OpenStreetMap 帽子ですが，再度作ろうかなと思っています． 経緯ですが，先日の関西のイベント(K-OF)で，この帽子の話が少しありまして， また作ると希望される方がいるかも？という話になったのが経緯です． 2014年作成時の帽子は，↓に写真があります． https://wiki.openstreetmap.org/wiki/User:Tosihisa/Merchandise 前回と同じでも良いのですが，せっかく作るのだったら(?!)，前回とは違う ものを作りたいなぁと思っていますが，前回のと同じ方が良いかもしれません． ＃こういうのを考えるのが楽しいのです... で，もし OpenStreetMap 帽子を希望される方がいましたら，その方の希望も ふまえて考えてみようと思いますので，お知らせ頂けたらと思います． 最近，私はあまりお役に立っていませんので，こういう形でもと思っています． ＃本音を言うと作りたいだけです...すみません！ ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] osmjp_都道府県 運営のご相談
山下さん： としです． > もしくは「XX県はロックされたら私がSMS認証してあげるよ」というかたはいらっしゃいませんでしょうか？ > （ご自身のtwitterアカウント用とは別の電話番号が必要です） 大阪は既に坂ノ下さんにて対応予定としまして，近畿4県いずれかの1県限定ですがロックされれば応対します． (4県＝兵庫県，滋賀県，奈良県，和歌山県．twitter で見ると，今のところ，大丈夫っぽいですね...) ただ，SIMは少々考えますので，ご期待に添えないやもしれません．そのときはすみません... > その他、回避策、例えばマストドンに逃げるとか（笑 > 終わっていいよとか（藁 マストドンへの移行のキッカケにはなるかもですね． 終わるかどうかは，山下さんの気張らない範疇でと願っています． ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 長距離のGPXデータを手軽に作図する方法を教えて下さい．
としです． ikiyaです。 JOSMでのGPX>OSM変換と大して変わらない気はしますが、 "困った時のGPSBabel"で、変換フリーソフトGPSBabelを勧めています。 ほとんどのものをよいしょとOSMフォーマットにしてくれます。 あ，今でも GPSBabel での OSM データ作成は使われるのですね． もう一点、100m間隔の作図ですが、GPXから変換したOSMデータを使う前提でお話しすると、JOSMのSimplifyAreaプラグインお勧めします。 SimplifyAreaプラグインは知りませんでした．ありがとうございます． JOSM は不慣れなのですが，どうも「ツール」ー「ウェイの単純化」と 言うのがあり，これで間引きが出来るようでした． ２つともとしさんの質問外していそうですが、ご参考まで。 いえいえ，ありがとうございます． 先ほどの muramoto さんから頂いたフォローもふまえて，先ほど 新日本海フェリー航路（敦賀〜新潟〜秋田まで）を作図できました． ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 長距離のGPXデータを手軽に作図する方法を教えて下さい．
とし＠かなりご無沙汰です． つい先日，秋田〜山形〜仙台を周り，秋田へは敦賀港から日本海フェリーで 秋田港へ行きました． この経路はGPSロガーで記録しており，GPXログをアップしています． https://www.openstreetmap.org/user/tosihisa/traces/2503987 で，ここからが質問なのですが，「日本海フェリー 敦賀港〜新潟港」 「日本海フェリー 新潟港〜秋田港」と，二つの route=ferry をOSM作図 したいのですが，二つで 500km 近くありそうで，手作業でコツコツと OSM作図するのは少々時間を要すると考えていまして，楽に作図できないか 考えています． 手頃な方法で思いつくのは，JOSM で GPX を開いて OSM データに変換する事 なのですが，アップロードしようとすると，この方法は強く推奨しない旨の ダイアログが出るので，少し躊躇っています． （とは言え，昔は割とそのままアップしていたようには思いますが...） 要は，手軽にGPX->OSMに変換し，不要なデータは手動削除してアップしたい のですが，何か良い方法があれば教えて頂けると助かります． 蛇足ですが，帰りは仙台港から名古屋港に太平洋フェリーで移動したのですが， 窓際の部屋が確保できずにGPSログが取れませんでした． ＃無理してでもイイ部屋を取るべきだったかもしれません（汗 ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] Code for Sakai 多治速比売神社(たじはやひめじんじゃ)マッピングパーティ
としです． すみません，すっかり告知が遅くなってしまったのですが， Code for Sakaiでは，明日8月30日に，大阪府堺市で 多治速比売神社(たじはやひめじんじゃ)マッピングパーティをします． https://openstreetmap.doorkeeper.jp/events/29945 あまり肩肘張らずに，気軽にマッピング出来ればと思っています． 前日の告知になってしまってすみません．もし興味があれば， どうぞふるってご参加下さいませ〜 ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] インポートデータに関する削除について
としです． On 2015/02/22 18:42, Satoshi IIDA wrote: いいだです。 ご協力いただきありがとうございます。。。 と言いたいところですが、すみません、建物に関する作業をそこで止めて頂けますか？ また、削除作業が完了するまでの間、建物に関する編集をやめていただけますか？ よくわからないのですが，いいださんがこれを言える理由は何でしょうか？ 既に削除作業が始まっているのであれば，後は時間次第で， これはいいださんでもどなたでも変わらないと考えています． 仮に，私が削除作業に参画しても，編集をやめよと聞こえます． 私は，これ（編集操作に対する言及）に反対です． 理由は一時的でも編集独占権を持つ（持たせる）ためです． せっかくの申し出のなか申し訳ありませんが、どうぞご理解ください。 理解しうるに説明が無いのが私の感覚です． 既に削除作業が始まっているのであれば，被るのはいたし方ありません． もし私が，事前了解なしで先行して削除活動を行っていれば同じことです． それでもなお，いいださんが独占的に作業をするための理由があるのならば， その理由（独占作業の根拠）を教えて下さい． 私の主張を以下に記します． ＊編集作業の強制，またはそれに近いことは，誰も述べることは出来ない． ＊これは OSM が Wiki の特性を持っていることによる． ＊よって，いかなる編集でも競合は常に起こりえる． ＊この競合は，不可避であるので OSMer は受け入れるより他はない ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 基盤地図情報のインポートについて
としです． 私が意見を言って良いのかどうか（そう言う趣旨で いいださんが投稿されたの か）分かりませんが空気を読まずに :-) ■原則 まず、最も厳格な適用の場合を述べます。 ... ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 厳格も何も，入れるべきではないデータが入ったのなら削除するより他は無い と思います． 後は削除範囲をどうするかかなと思っています． ではこれにて． On 2015/02/19 23:50, Satoshi IIDA wrote: いいだです。 解説いただきありがとうございます。 ■原則 まず、最も厳格な適用の場合を述べます。 データの改変を実施していても、入力したデータを削除すべき、という適用です。 何故ならば、今回は基本測量成果である基盤地図情報を元データとしており、 測量法の適用範疇内である点が課題である以上、 提供元 (この場合、国土地理院) としても法律運用に基づく利用可否の判断はできず、 可否判断が可能な組織は司法である、という認識を持っています。 つまり、単に提供元に後追いで許諾を貰えばOK、という性質のものではないという認識です。 また、OSMとして、法律に抵触し、なおかつそもそも、 以前に地理院との話し合いの内容に反する状況を維持することは あまりよい事態ではないと考えています。 ■海南町について 現在削除が行われているようです。 作業者とみられるかたからコンタクトあり、削除する方向で進めています。 ■徳島について インポートを実施した範囲が不明確ですので、確認させてください。 徳島県ほぼ全域を作業されているようですが、それで認識はあっていますか？ インポート作業に利用されたアカウントは以下の2つでよいですか？ * 徳島県オープンデータ * mitsurukikkawa ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 ___ 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] 基盤地図情報のインポートについて
としです。 On 2015年02月20日 02:44, 徳島県オープンデータ wrote: ... 「承認を得ず利用できる範囲 ... ・一時的な資料として利用する場合 ・イラスト的に利用する場合」 となっていることからOSMへアップロードする前に， 後に編集すれば，当該地図の「複製」とはならない。 （→一時的な資料として利用） http://www.gsi.go.jp/LAW/2930-qa.html#01 からの引用ですが、 === 3.「一時的な資料として利用する」とは？ 打ち合わせ等で一時的に利用し、利用後は保管することなく処分する場合 === 上記のように記されているので、処分している（削除している）なら良いと 思いますが、処分していないならば一時的な資料とはならないように思います。 実際，県南部海陽町 １．OSM： http://www.openstreetmap.org/#map=16/33.6097/134.3526 ２．電子国土基本図（国土地理院） http://portal.cyberjapan.jp/help/development/update_std/#zoom=16lat=33.60661lon=134.35707layers=BTT 見比べていただければ、かなり異なることが分かると思います。 この「異なる」点、本題とはそれますが、気になっています。 これは、地物(事実)としてはどちらがより正確なのでしょう？ 話の流れを見るに、基盤地図情報を元に、Bing 画像で修正（トレース） してコミットされているようですが、すべてのオブジェクトで修正が必要 ならば、そもそも基盤地図を使うメリットがあまり無いように感じます。 初めからトレースのみで良いように思うのですが、トレースのみの場合と、 基盤地図情報を元に修正するのでは、後者の方がどれくらい効率が良いの か気になっています。 もし、トレース不要なくらいに一致してて、そのままコミットすると、 結果は同じでも元ソースが違うので、基盤地図情報をそのままインポート したともなってしまいます。 これは本題とは少し違うのですが、どっちがより正確なんだろう？と ふと疑問に思ったもので記しました。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] インターナショナルオープンデータディ2015イベントのお知らせ（大阪府堺市）
としです． 2月21日のインターナショナルオープンデータディにあわせ， 大阪府堺市で，オープンデータに関するイベントを行います． 堺の魅力再発見！まちあるきワークショップ 〜 オープンデータを使ったオリジナル観光ガイドを作ろう〜 （略してサミケン） http://peatix.com/event/72435 有料イベント(￥1,000)なのですが，当日のお弁当代と会場費用にあてます． 当日の会場は大仙公園内の日本庭園(和室)で，マッピングは 日本庭園をマッピングする予定です． ところで，これは昨日知ったのですが，位置情報付きのデジカメ写真を Wikimedia commons へアップロードすると，OSM (wmflabs.org経由) で 場所と風景（デジカメ写真）が分かるのですね．勉強不足でした... 例えば，堺市にある旧堺燈台は，以下のURLで，OSM地図と Wikimedia commons へのリンクが得られます． https://tools.wmflabs.org/wiwosm/osm-on-ol/commons-on-osm.php?zoom=16lat=34.583486279313lon=135.45916963279 これは GARMIN 62SCJ で撮影したもので，画質としては今ひとつなのですが， マッピングの記録で位置情報付きのデジカメ写真があると有用ですし， Wikimedia commons にアップロードすることで，誰でもが位置と写真を合わせて 見られるのは良いと思っています． 2月21日当日は，Wikimedia commons へのアップロードもしようと思っていま す． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] planet.osm 日本エリア配信(実験中)
としです． 2015年は日本のOSMの統計を取りたい(fact sheetを作りたい)と思って， まずは手元で planet.osm の日本エリアを自動的に更新できるようになったの で，planet.osm 日本エリアの最新から過去1周間分をダウンロード出来るように しました． http://www.netfort.gr.jp/~tosihisa/notebook/doku.php/planet-japan-osm 日本のOSMの統計が得られるようになるには，子育てと仕事の合間合間ですの で，今年いっぱいまでに統計が取れるところまで行けるかは分かりませんが， ボチボチと進めていきます． まずは基本データである planet.osm の日本エリアを毎日更新できるように なったと言うことで… ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] source=google* のタグが付いたデータの扱い方(削除手順)の確認
としです． source=Google maps と source=2014 Google,ZENRIN については，OSM には 入れられないデータ元ですので，消そうかなと思ったのですが，このあたり，削除手順って何かありましたでしょうか？ この二つのオブジェクトを削除しました． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 2014.08 兵庫県丹波地域豪雨災害クライシスマッピングの準備ができました
としです． (2014/08/21 7:34), Jun NOGATA wrote: オープンデータ・ラボの榊原さんが現地入りされたそうで、その情報によると、 現地入りはボランティアとして入る以外は、かなり制限されているようです。 今、情報収集活動用の許可証が発行できるか打診しているそうなので、現地サー ベイについては、しばらく様子を見ていたほうがいいかもしれません。 土曜日は午後から天候が崩れそうで，ボランティアとして行くとしても日曜日が 良さそうですね． この週末の天候は，丹波，広島共に気がかりです． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 2014.08 兵庫県丹波地域豪雨災害クライシスマッピングの準備ができました
としです． 野方です。 各地で豪雨災害がおこっていますが、兵庫県丹波地域でのクライシスマッピングの 準備ができました。 現在の丹波OSM地図はガチで現地サーベイした方が良さそうなので， まだ確定出来ていませんが，土日どちらか（仕事が入らなければ＆＆カミさんに事情を説明できたら） 現地サーベイしようと思います． 今現在，丹波地域の実地サーベイマッピングを予定または検討されている方はいますでしょうか？ 私は，出来れば土曜日は普通にボランティアして日曜日に現地サーベイ出来たらと思っていますが， 両日行けるかどうかも現時点では何ともではあります． 私の予定はまだ流動的ですが，固まればまたこのMLに投稿します． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] OSC京都でのOSM認知率
としです． 昨日8月2日のOSC京都はお疲れ様でした． OSC京都での OSM 展示では，どれくらい OSM の認知が進んでいるか気になった ので，簡単にですがアンケートを取りました． （いいださん，田口さん，アンケート協力ありがとうございました m(_ _)m） ●OpenStreetMap 認知率 知っている人：26人 知らなかった人：9人 認知率：26/(26+9)=74.28% ●OpenStreetMap アカウント取得率 アカウントを持っている人：12人 アカウントを持っていない人：21人 アカウント取得率：12/(12+21)=36.36% このようなアンケートは関西では初めてと思います． 私見ですが，概ねこのような感じだろうと思っていました． 最近は，知らない人よりも知っている人のほうが多くなったと感じます． この結果を見て，改めて感じたことは，OSM自身の紹介は，OSCではもうそろそろ 飽和（サチる）と思います． しかしアカウント取得が低いので，今後のOSC等での展示では，OSM自身の紹介よ り作図に繋げるような紹介にした方が良さそうです． ここ最近は，OSC京都ではOSMセミナーを出来ていませんが，勉強会などでアカウ ント取得が増えたら...と考えています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] OSC京都での OpenStreetMap 展示について（8月2日土曜日のみとさせて下さい）
としです． Subject の事ですが，本当にすみません，OSMの出展は，1日と2日両日を予定し ていたのですが，8月1日（金）は所用が入り，OSC京都への参加が難し く，OpenStreetMap の展示は8月2日（土）のみとさせてください． # 8月1日の所用もOSS関係ではあるのですが... もし，8月1日（金）のOSC京都で OSM のところに来られる予定の方には，本当に すみませんです... ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] Merchandise (OSM 関連グッズ)(ステッカー，帽子，風呂敷)
としです． OSM 帽子は，合計10個希望がありました． （一応，予備で＋2個ほど余計に製作発注しようと思います） 個人的には、刺繍ワッペンとか、バンドエイドなんかもあると面白いかもなぁ、と思いつつ、 思いつきからはや一年が経過しようとしているところです。 刺繍ワッペンは，スキルバッジとしてヨサゲなので一瞬考えたのですけれ ど，OSMロゴって割と難しいかも？と思ってて躊躇しています． 以下のOSMロゴは，シンプルなので刺繍できるかなとは思ったりしています．．． http://wiki.openstreetmap.org/wiki/File:Logo_simple_colors.svg http://wiki.openstreetmap.org/wiki/File:Logo_mono.svg ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] OSM帽子の製作を進めます(Re: Merchandise (OSM 関連グッズ)(ステッカー，帽子，風呂敷))
としです． OSM帽子の製作の件です． twitter 経由で，一つ希望が来ていますので，ikiyaさん取りまとめ分と合わせ まして，合計5個になったので，OSM帽子製作を発注しようと思います． で，うっかりしていました．すみません．帽子は色が選べます． 以下のURLから，ご希望の色をお知らせいただけませんでしょうか． http://www.wappenya.com/goods/cap/cap2001/otto-mesh.htm 特に指定がなければ， ケリー*ホワイトで製作依頼しようと思います． 発注する帽子の個数は，明日7月28日の22時頃の希望数で確定しようと思います． （OSC京都に間に合えば良いのですが...） OSM帽子製作希望の方は，希望個数と，上記URLから希望の色をお知らせください． このMLあるいは twitter，facebook 経由でも構いません．明日7月28日の22時で 発注数を固めます． ではこれにて． (2014/07/27 19:16), ikiya wrote: ikiyaです。 OSM帽子、会津のマッパーmeguroさんも１ケ希望されるということで ikiyaとりまとめて合計４ケ（ikiya３ケ＋meguro１ケ）希望となりました。 よろしくお願いします。 - Original Message - From: ikiya insidekiwi...@yahoo.co.jp To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2014/7/27, Sun 15:17 Subject: Re: [OSM-ja] Merchandise (OSM 関連グッズ)(ステッカー，帽子，風呂敷) ikiyaです。 素晴らしい。 OSMグッズ、OSM帽子よいですね！ お手数かけますが、OSM帽子３ケ希望します。 もし発注がかないましたら支払等遠慮なくお知らせください。 - Original Message - From: Toshihisa Tanaka tosih...@netfort.gr.jp To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2014/7/27, Sun 12:48 Subject: [OSM-ja] Merchandise (OSM 関連グッズ)(ステッカー，帽子，風呂敷) としです． OSM 関連グッズをいくつか制作してみました． 以下の Wiki にまとめています． https://wiki.openstreetmap.org/wiki/User:Tosihisa/Merchandise OSMステッカーはよくある話で，OSM帽子もままある話ですが，OSM風呂敷は多分 に今のところ世界でこれだけかも？と思ったりしていますが， 真偽は分かりま せん :-) OSM 帽子は，これから夏本番のフィールドマッピングで実用になるだろうと思っ ています． この帽子ですが，もし希望者が5名以上いらっしゃいましたら，追加で製作発注 しようと思っています． もし，OSM帽子の製作を希望する方は，このMLまでお知らせいただけたらと思い ます．費用は Wiki に記載しています． 希望者が5名以上(発注数が5以上)になったら，製作会社に追加発注しようと思い ます． OSM風呂敷ですが，もし SOTM にどなたか行かれるときに，風呂敷に興味があれ ばお貸しします． 海外で，ちょっとした日本文化の話題のネタにでもなればと思います． 8月のOSC京都に帽子と風呂敷は持参しますので，帽子は希望したいけれど現物見 てから考えたい人は，OSC京都で現物を見て頂けたらと思いま す． 風呂敷は，デザインが安易すぎ（OSMロゴをそのまんまデカデカと風呂敷にした だけ）なので，もうちょい何か出来ないかなぁ〜と思ったりしていま す． ではこれにて． ___ 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] OSM京都の申し込みについて
としです． 田口です。 こんばんは． 8/2（土）開催予定のオープンソースカンファレンス京都の申込みですが、 締切が今週いっぱいとなっております。 私は京都へ参加できるかどうかは微妙なので、確実に参加可能な方が いらっしゃいましたら、申込みを行っていただけませんでしょうか。 お知らせが遅くなってすみません．私から申し込みしました． 申し込み自身は前月にしていたのですが，申し込みの様式ファイル (表計算シートのファイル)に記載するのをうっかりしておりまして， たった今 様式ファイルに記載して送りました． 関西の OSMer な皆さま，もしお時間が許せば，OSC 京都へ足を運んで 頂けると嬉しいです！． ＃それまでの自作GPSロガーの完成度も上げないと... ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] ジオコーディング(Re: ローソンさんのデータのインポート)
としです． ローソンさんのOSMデータを眺めてて，今更ながらに気づいたのですが，ローソンさんの OSMデータって，店舗の住所があります． この住所の数は， $ grep addr:full tenpomaster-20130823.osm | wc -l 11396 $ と言う感じで，数にして約1万1千箇所あります． それに加えて，一つの店舗に緯度経度も当然あるのですが，これ，OSM単独(ODbLの元)で，ジオコーディング出来るんじゃないかな？と思いました． いわゆる住所から緯度経度を求めるものです． なお，総務省統計局の情報によると，平成20年時点での住宅総数は57,586で，加えてこれに事業所を加えたりすると， 11396と言う数は，ジオコーディングの量としては足りないかも知れません． しかしながら，ジオコーディングが OSM の DB 単独で1万1千箇所で行える可能性を持っているとすると， これって結構すごいことで，災害時やOSMを用いた地図サービスで有用な情報なのではないかと思っています． もしかすると，既に議論があったのかも知れません． 私はこれまで位置の精度と動的更新の動向に注目していましたが，私の視野が狭かったと言わざるを得ず， このデータは日本のOSMにとってすごい意義のあるものだと改めて考えています． う〜ん．この状態でも，細々と小さい地域に分けてインポートしても良いのではないかと思います． やっぱこのデータは純粋にすごい意義のあるものだと改めて考えています． 何とかいい形でインポート出来ないかと考えています． ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンさんのデータのインポート
としです． すみません，この部分，読んでませんでした． またまたとしさんは、既存データがあっても差し替え派だったかと思いますが、 いかがでしょうか？ // 陵墓データがオープンデータとなったとして、 // 既存の仁徳天皇陵のデータを全て捨ててインポートしたら、、、 // いくら差し替え派のとしさんでも // 俺の頑張りはなんやったんやと // モチベーションがダダ下がりなのではないかと思います。 コメントへの返信で恐縮ではありますが，仮に仁徳天皇陵が，ある日別のものに差し替えられても，「そっちが正確ならば仕方がない」です． これを言い出すと，私は関西において，御堂筋をはじめに描きました．が，今はもう私の引いた御堂筋では無くなっている様です． 別のどなたかが張り替えられたようです． とは言え，OSM は wiki の考え方をしているわけですから，私が作図したものを，別のどなたかが張り替えられても，そういうものだと思っています． 私は2008年あたりから，関西全般を細々と作図してきました． 上記で述べたとおり，御堂筋はもう私の引いたものでもないようですし，堺のいくつかは，ODbL に移行した時に削除対象となり，実際にいくつかのデータは削除されました． 私は Public Domain 宣言をしていますので，昔ながら？に実測を第一にと今でも続けていますが，インポートの物量を前に，自分の手の狭さを思い知るのみです． そのたびに凹んだりすることもありましたが，それでも今でもやっています．やっぱり単純に楽しいからです :-) ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンさんのデータのインポート
としです． （2014/02/10 現在、仕様の再検討案を提示して、テストインポートエリアである、宮城県、京都府、東京都のエリアをテストインポート中です。ディスカッションは talk-ja ML 上で行われています。） １）再検討案 2/10 時点では再検討案を提示して頂いていませんでしたよね？ この仕様の再検討案は，私は2013年9月12日にいいださんが投稿されたマージ手順書の事と考えていました． https://docs.google.com/document/d/1hsk4oBwnbtXSoQdqbwWkCsD5m4IYNgAEGr6J7HvMwCA/edit# 上記の文面では10日時点での事を記しているように見えますが，実際は単純に2月10日時点でのステータスを記しているのみかと． テストインポートしたなら、その評価が必要かと思いますが、 事前も事後も何らアナウンスも依頼もありませんでしたよね。 恐らく，インポート(2月10日か11日かそのあたり)の後に雪害(2月17日)があって，そちらを進めた事によると推測します． （私の時系列の認識が間違っていたらすみません） ローソンさんからは非常に有用なデータを提供いただいているのに、 このような進め方をされることを非常に残念に思います。 できましたら，今しばらく時間的猶予を頂けませんでしょうか... ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンさんのデータのインポート
としです． 第一、店名を気にする人がどれほどいるのでしょうか？ そこにローソンがあることがわかればいい人がほぼ全てで（山下基準） 店名が必要になるのは 4sq でのチェックインの時ぐらいではないかと（笑 私は店名を気にするほうかなと思っています． 特にローソン近くで待ち合わせる場合に，店舗名は必要と考えています． 個人的には，name = ローソン ほげほげ二丁目店 で異論ありません． 私なりの理由を以下に記します． 1) 近所に複数の同一チェーン店がある場合に特定が難しいのは同意． 2) ローソン近くで待ち合わせる時は店舗名が必要． 3) 私は，レンダリングよりも検索性を重視しています． name = ローソン ほげほげ二丁目店 の方がDBとして検索しやすいと 考えています． 2) 既存OSMデータとの店舗位置競合について 既存データが有った場合OSMマッパーの位置を採用してマージします。 貴重な時間をマッピングに費やしていただいた マッパーの功績を残していただけるということで、大歓迎です。 area や building で描かれていた場合も考慮をお願いします。 またまたとしさんは、既存データがあっても差し替え派だったかと思いますが、 いかがでしょうか？ 私の基本的な考えは，既存データの有無よりも，より正確な位置を指している方を 採用するべきだと考えています． よって，私は既存のデータでも位置がズレている？と思しき場合は修正します． 場合によっては差し替えを考えるかもしれません． これはローソンさんの件であろうと無かろうと同じです． しかし，災害などで一刻を争う事態の場合は，インポートデータを優先するのも 判断すべきと考えています． 4) ひらがな表記について 今までの議論： branch:ja_kana などのひらがなタグとして、変換データ内で ちようめ という表記が見られた。修正すべきか？ → OSMマッパー側で修正して良い。将来的にローソン側にフィードバックしていきたい。 山下さんと同じく，メールの文面によるものと思いますが，このあたりの議論を 見ていて，今ひとつわからないのは，どの様なデータであれ，ODbL として OSM データに投入された時点で，みんなの共有データとなるので，フィードバックも 何もなくて，フィードバックを得たい人は自分で得るしか無いと思っています． 私は自分・他人問わずにOSM地図を修正する時は修正しますし， 修正したからとて当人(って誰？)に連絡することも無いです． というか逐一連絡するのは現実的でも無いです． 繰り返し述べますが，ローソンさんのデータを ODbL としてOSMデータに入った 時点で，それはみんなの共有リソースになります． よってローソンさんにフィードバックされるかも分かりませんし，OSMデータに 入ったものについて修正の独占権を持つことも出来ません． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンさんのデータのインポート
としです． 保留になっている？ローソンのデータを 災害救助法適用４県対象にインポートできませんでしょうか？ 参考までに，四県の店舗数は以下のとおりです． 以下の情報は，日付から2013年8月時点で，最新のものは異なると 思いますが，そう極端な変化も無いだろうと見ます． $ grep 山梨県 tenpomaster-20130823.osm | grep addr:full | wc -l 99 $ grep 埼玉県 tenpomaster-20130823.osm | grep addr:full | wc -l 472 $ grep 長野県 tenpomaster-20130823.osm | grep addr:full | wc -l 149 $ grep 群馬県 tenpomaster-20130823.osm | grep addr:full | wc -l 84 $ echo '99+472+149+84' | bc 804 多分に人海戦術で何とか出来そうな数と感じています． 保留？の要因： マッピング済みの店舗との重複をどうするか →チェックはみんなでやればいいかと。協力をお願いします 重複についてですが，重複をチェックするとして，重複している場合， どのようにすべきか．と言う判断が必要と考えています． a) 重複しないようにインポートする？ →それでは時間を要するかも知れません． b) 一気にインポートしてしまって，重複チェックする． みんなでチェックするとして，重複を見つけた場合， 先のデータを優先するか，インポートデータを優先するか， 「最も正しい位置と考えられるもの」を優先するか． 私見ですが，事災害における事で，一刻を争う事を鑑みると， インポートデータを優先すべきと考えています． しかしそれは，私達はローソン店舗についてはイン ポートデータを（全国的に）優先することを示唆する のかしないのかは，意識合わせしておきたい点です． また，インポートデータを優先するのは，2013/9/14 に 山下さんが投稿された内容と反することを私は述べている 事になります． なお，ローソンさんのデータのインポートにおける進捗は， 私が把握している限りでは保留ではなく，動的更新をどう するかにて検討中であると私は認識しています． ローソンさんのデータは日次で更新されるので，その更新を どうするか検討中であるはずです． 動的更新については，2013/08/24 のメールにて，古橋さんが そのため、ローソンさん側からは毎日更新される情報が提供されていますが、 今後は、まずは被災地（とくに石巻）を中心に、毎日更新の技術を試験運用し、その技術ノウハウの共有が最終的な目標になります。 上記の通りお知らせされていることに由来します． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSM地図に手書きメモがかけるiPhoneアプリOSM sketch
としです． ao_zealと言う名で参加させてもらってます。 こんばんは． https://itunes.apple.com/jp/app/osm-sketch/id777144672?mt=8 OSM sketchと言う名で先週からapp storeに公開されてます。 を！．作者さんですか！． 地図の間違いに気づいたら直ぐにメモがとれる様にと思って作ってます。 使った感想を聞かせてもらえるとうれしいです。 一昨日19日に AppStore で OpenStreetMap で検索してまして，OSM sketch を見つけましたのでインストールしていました． 何分まだ使いこなしには至っていませんが，実際にGPXメモをアップロードしてみたり，感想を以下につぶやいたりしていました． https://twitter.com/tosihisa/status/41001359986688 私は OSM sketch はアイデア勝利だと思っています． メルカトル等のOSMエディタで編集する時に，メモレイヤみたいなのがあると便利な時があるのですが，OSM sketch はそれをうまく補完してくれそうに思っています． 面白いツールをありがとうございます． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] Compiling osmfilter on MacOS
としです． いいだです。 ... この時に処理の前段階として .osmファイルから対象のオブジェクトを抽出するために osmfilterというプログラムを使うのですが、そのコンパイルに失敗します。 どなたか、手がかりがわかるかたいらっしゃいますでしょうか？ 環境は、MacOS X 10.8.5です。 http://wiki.openstreetmap.org/wiki/Osmfilter ■Wikiの手順でやると、引数が多いっていわれて停止 nyampire$ wget -O - http://m.m.i24.cc/osmfilter.c |cc -x c - -O3 -o osmfilter stdin:5166:27: warning: too many arguments in call to 'read_close' read_close(oo__ifp-ri); ~~^ ■wgetでいったんローカルにダウンロードして試したけどNG。-vオプションの結果。 nyampire$ cc -x c - -O3 -o osmfilter -v osmfilter.c テキストエディタで，osmfilter.c を開いて，5166 行目が， read_close(oo__ifp-ri); となっているのを， read_close(/* oo__ifp-ri */); として下さい． ソースをざっとですが見ましたがこれで行けるはずで，Mac OS X 10.9 でコンパイルできることを確認して， 適当に map.osm をエクスポートして， $ ./osmfilter map.osm --keep=highway=secondary とかすると highway=secondary に関するもののみが残る（フィルタされる）ところまで確認しました． この osmfilter は便利そうですね．私は今まで grep と awk を駆使？してフィルタしていましたが， これだともっと簡単にフィルタ出来そうです． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] マップコンテスト2013開催、募集
としです． それに合わせて、「マップコンテスト２０１３」を開催したいと思います。 ... ２. 普段、OpenStreetMapの地図表示や、編集を見ている中で、素晴らしいマッピングがされている地域を推薦してください。 ... ＊ talk-ja メーリングリストに投稿します。 自画自賛ながら，大阪府堺市 大仙陵古墳（仁徳天皇陵）をノミネートさせて頂きました． https://wiki.openstreetmap.org/wiki/JA:MapContest2013#.E6.8E.A8.E8.96.A6.E3.81.95.E3.82.8C.E3.81.9F.E3.83.9E.E3.83.83.E3.83.97 大仙陵古墳は，世界の三大陵墓に数えられます． この古墳が本当に陵墓かどうかは OSMer の判断を超えますが，OSM地図として level 11 からでも確認できる歴史的人工建造物で，OSM地図として世界を見ても 他にはあまり例がないでしょう． また，大仙陵古墳は，これまでの日本のOSM作図で主流だったGPSログ以外に オルソ化画像により内部を作図したもので，この作図方法の承諾を得たことで， 日本でのチェアマッピングを加速することが出来たと自負しています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] i-gotu GT-900Pro でGPSログ取ってみました．
としです． ご無沙汰しております。清野です。 ご無沙汰しています． ログを拝見させていただきましたが、かなりキレイでびっくりいたしました。 こんなにキレイに取れるんですね。 はい． 試す前までは，正直なところ，半信半疑と言うか，まぁGPS位置は暴れるかも... と思っていましたが，こうもキレイにログが取れるとは思いもよりませんでし た． 腕に付けた状態ですよね？すごいですね！ はい． 普通に腕時計と同じようにつけて，普通に歩いてログを取りました． ログを拡大して見てみるとGT-900の方はちょっとカクカクしているのが気になるところですね。 これはかつてForeAthlete101 (海外ブランドはForerunner) で見たようなカクカクさですね。 これってなんでこうなるんでしょうね…? 私も分からないですが，恐らくはGPSモジュールのフィルタ処理によるものかも 知れません． あと、データをロガーからダウンロードするためのツールですが、 http://wiki.openstreetmap.org/wiki/BT747 http://www.bt747.com/ こちらのツールも見てみてください。 お知らせありがとうございます． BT747 はまだ試していないのですが，igotu2gpx-0.3.0.tar.gz をダウンロード すると，HACKING と言うファイルがあって，プロトコル仕様が(恐らくは分かる 範囲で)書いてあるので，これをベースにプログラムを書いてみると良いかなと 思っています． ＃問題は私が時間があまり取れない事ですが(汗 電池のもちもこのタイプのGPSロガーでは重要になってくると思うのですが、 値段と関係して安かろう悪かろうみたいな状態みたいですね。 できれば丸一日つけっぱなしにしていても充電しなくて良くて、 精度も高いものがあるといいですね。 この GT-900Pro で，ちょっとよく分からないのが電池の持ちなのです． (箱とかマニュアルを読んでも，どれくらい動くのか書いてなさそうなのです) どれくらいの時間動くのかは，ちょっと試してみたいと考えています． ＃が，これまた時間が取れるかどうか...(汗 ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] osm.jp のレンダリング好評でした(KOF)
としです． KOF で osm.jp のレンダリングが話に登りまして，好評でした． 殆どは広島から来られた丸市さんに教えていただいたのですが， 交差点の名前が出てくる（これはかなりありがたい）のと， 建物が立体的(※)に描かていているのが良いです． ※：これは後で知りましたが，タグのLEVELに関わらず立体的に描いているようですね． 私自身，日本のOSM地図においては，osm.jp のレンダリングを推したいです！． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] i-gotu GT-900Pro でGPSログ取ってみました．
としです． KOFで腕時計型のGPSロガー i-gotu GT-900Pro が販売されていたので， 購入して自作GPSロガーと測り比べをしてみました． 結論としては，i-gotu GT-900Pro のGPXログには精度が記録されないものの， 位置精度はLCD画面を見ると2mまで良い時があるので，マッピングする時の メインGPSロガーとして使えると思いました． ＃私個人は，あくまで自作GPSロガーがメインですが（汗 このあたりの事を，Wikiページに書きつつあります． https://wiki.openstreetmap.org/wiki/User:Tosihisa/GPS_comparison ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 本日のOSCでの話題その2
としです． ９月のState of the Map 2013, Birminghamでも、基調講演で、女性比率が低い、 ダイバシティが生かせていない、という話題が提起されていました。 みなさんは、どう思いますか？ 関西では女性のOSMerが頑張っていると言う印象です． それは今でもそうですし，かつて関西のOSM地図の緑化の先駆けにもなったと思います． 私は基本性別における区別はしないのですが，sinsai.info のデータ班での経験では， 女性のコミットメント力の強さを感じました．この強さは，理屈的な強さではなく， 本質的な強さを感じました． これは男性には見られず，女性の本当の力を男性である私が，忌憚なく言えば思い知らされた感を持っています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンデータのインポート時タグ定義
としです． # 他のタグについてはそんなに意見なさそう？ # atmやお手洗いのタグは、インポートデータとしては含まない、ということで一致しているかと思います # https://lists.openstreetmap.org/pipermail/talk-ja/2013-August/007570.html これは，「タグのみなし設定はしない」と言うことかと思います． lawson2osm.awk が OSM データの生成スクリプトとして，以下は既定値が設定されています． tag k='shop' v='convenience' / tag k='toilet' v='yes' / tag k='atm' v='yes' / tag k='internet_access' v='wlan' / shop は既定値で良いかと思いますが，もし toilet や ATM がインポート元に含んでいるのならば， 含めても構わないかと思いますが，今は含んでいなさそうなので，タグのみなし設定はしないので 入れないと言う流れだったかと． name について，色々案があって，私も私なりに考えているのですが，１点，忘れてはならないのは， $ grep k='name' tenpomaster-20130823.osm | wc -l 11396 $ と言う事で，ローソンさんの店舗数は，８月時点で１万１千店舗あるので，冗長な情報が入ると， それだけOSM DB の容量を更に取るであろうと言う予想です． 今すぐには全件を入れないにしても，最終的には１万１千店舗が入っていくことにはなるでしょうから， なるべく冗長な情報は含めないほうが良いだろうと考えています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] ローソンデータのインポート時タグ定義
としです． 些細な事ですが，少し前から気になっているもので． ■nameタグにおける基本方針 念のため、nameタグとは「現地で確認でき、現地の人が呼称する一般的な名称」をさします。 では、その「一般的な名称」とは何を指すだろう、というところで意見に相違があるのだと思っています。 僕の感覚からゆくと、それは「ローソン」です。 「現地で確認でき、現地の人が呼称する一般的な名称」について異論はないです． ただ，それで行くと，name は LAWSON になると考えています． 理由は，LAWSON の看板にはローソンと書いていないからです． 海外の方は，LAWSON は現地で確認できると思いますが，「ローソン」は確認できないかも知れません． 看板にカタカナで「ローソン」と書いていないからです． 店舗の入口には「ローソン ＊＊＊店」とカタカナ表記していますが，看板は LAWSON で，これはどこでも同じかと思います． これは，もしかすると極論を書いているように思えるかも知れませんが，私がこれまでに出会った海外の方で， 概ね共通しているのは「外来語をカタカナで書いているのは海外の方にしてみると読みにくい」とお話頂いた経験があるためです． なお，これは蛇足ですが，先日から name について色々調べているのですが，名前には「ゆらぎ」があります． コンビニエンスストアの場合，名前のゆらぎが一番顕著なのは セブン-イレブンで，japan-latest.osm.bz2 から見ると， セブン-イレブン セブンイレブン セブン・イレブン 上記３パターンがあります．ローソンは恐らくはゆらぎはないと見ますが... ローソンの話に戻すと，現地で確認できることを第一に置くならば，name はローソンではなく LAWSON が適切だと考えています． ただ，それは，私見ですが，恐らく日本人はそれを受け入れないだろう．とも考えています． まとまっていませんが，これが現状私の頭のなかにあるものです． ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 住所
としです． ■書き換え、あるいは追記が必要なページ nameについて、としさんも直されるようなのでちょっと様子見ちゅうです。 たぶん、ここにまとめるのがいちばん正しいのだろうな、という印象を持っています。 http://wiki.openstreetmap.org/wiki/Japan_tagging#Examples_of_names すみません，基本的には異論はないので修正をと思いつつ，自作GPSロガーのデバッグで謎な現象にハマった＆休日出勤でした． 修正頂く分には，問題無いと思います．もしお時間が許せば，name も併せて修正頂けたら助かります． 取り急ぎ，ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 住所
としです． nameについて、としさんも直されるようなのでちょっと様子見ちゅうです。 たぶん、ここにまとめるのがいちばん正しいのだろうな、という印象を持っています。 http://wiki.openstreetmap.org/wiki/Japan_tagging#Examples_of_names すみません，基本的には異論はないので修正をと思いつつ，自作GPSロガーのデバッグで謎な現象にハマった＆休日出勤でした． 修正頂く分には，問題無いと思います．もしお時間が許せば，name も併せて修正頂けたら助かります． 自作GPSロガーのデバッグでハマった点が解消したので name を変更しました． 後ほどスレッド改めてお知らせします． 取り急ぎ，ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] Japan tagging の name を更新しました
としです． 9月から議論のあった name の括弧併記の今後について，基本的に今後は 括弧併記をしない方向で議論がまとまりましたので，Japan tagging の name 及び，Examples of names から括弧併記を削除しました． https://wiki.openstreetmap.org/wiki/Japan_tagging#Summary_of_names https://wiki.openstreetmap.org/wiki/Japan_tagging#Examples_of_names 修正内容に何かありましたらお知らせ頂けたらと思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． 英語の正式名称は日本の地物では基本的に無いものの方が多数だと思います。 例えば日本の主要道の一つ，国道は，Route と書いているものと Kokudo と 書いているものがあると思います． 数で考えると，確かに東さんの感覚通り，日本の地物では英語の表記ができる ものは少ないと私も思いますが，主要道は英語とローマ字が入り交じっている 感覚を私は持っています． カッコ内に記述されたものが正式な英語なのか、よみがな的なローマ字なのか という区別自体難しいのではないでしょうか。 はい．難しいと私も考えています． それ故に，読む側にとっては混乱されるのではないか．と言う懸念を私は持っています． 例えば，ある国道は，【国道xx号 (Route xx)】，別の国道は【国道yy号 (Kokudo yy)】と 書いてあるとして，日本人は，「Route」と「Kokudo」の読み分けが恐らくは出来ると 考えているのですが，海外の方は，この読み分けが出来るのかどうか，私は気になって います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． 扱いづらいという視点は誰にとっての視点なのでしょうか。 複数の表記が存在することは，意味を混乱させる事に繋がると考えます． 先のメールで述べましたが，「Route」は英語ですが，「Kokudo」は ローマ字で書かれた【日本語】です． 海外の方がローマ字を理解され，英語綴りとローマ字綴りを読み分けられる スキルをお持ちであれば，特段の心配はないのですが，海外の方が 「Kokudo」と言うキーワードを見た時に，このキーワードは，国道と言う 日本語なのか，それとも自身が知らない英語の何かなのか，は混乱されるかも 知れないと私は感じています． それは，扱いづらいデータだ．と見られるかも知れません． 少なくとも利用者の視点ではないように思います。 私は，OSM地図の作図は，まず私自身が利用者なので自分自身の観点で行っています． 東さんの考えていらっしゃる利用者の視点と言うのは，恐らくは海外の方の利用者視点の 事を述べていると思いますが，もしそうであるならば， 「少なくとも利用者の視点ではない」というのは，海外の方の視点ではないと 申し添えるべきかと考えています． 利用者としての私の視点は，単純ですが， 「長い name は Navdroyd で見ると途中で切れて読みにくい」と言うのがあります． カッコ書きにもいろいろありますが、 私の意見としては地名と駅名はいちばん残したいものです。 一番残したい理由はどの様な理由でしょうか． 私見ですが，恐らくは，地名と駅名は，ランドマークとして最も（国内外を問わずに） 使われるキーワードであるからだと思うのですが，もし他に理由があれば教えて 頂けたらと思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． ただし、カッコ付きで書かれた既存データの書き換えについては ビューアーの充実をもう少し待ってからの方が良いのではないかと思います。 たぶんこれを待っていては、永遠に切り替えはできないので、 書き換え方法の検討は始めてしまってもよいのではないか、と思います。 私も，ビューワーの充実を待っていると永遠に切り替えは進まないと考えています． そういう点をカバーするために、日本独自レンダリングを進めないといけないな、と思っています。 日本人以外に、カナなどを気にしてレンダリングなどするひとは少ないのでは、と考えると、 ここは日本人ががんばる以外にない部分なのかな、と思っています。 私は，ローマ字やふりがなは，レンダリングにも貢献できると考えていますが， それ以上に検索性能を向上させうると考えています． どちらにしろ、nameからローマ字表記を大規模に取り除こうとした場合、 Mass Editになりますので、Imports MLでの打診なども含めて、 手順の確定や手続きをふんだほうがよいかな、と思っています。 私は，日本の OSMer が手元で編集できる所からチビチビと編集しても良さそうに 考えています． 私は，カッコ書きを削除することには同意ですが，Mass Edit 的にするのは消極的です． 消極的な理由ですが，実際のところ，既に日本の OSM DB の name のほとんどは， カッコ併記が無いはずと言うのがあります． 2013年9月5日時点の japan-latest.osm.bz2 から，name の括弧表記状況を調べましたが， カッコ併記があると見られる name の数：74,556 個 カッコの無い name の数：1,024,870 個 上記の結果があり，現時点で，日本の OSM DB の name の内，93％はカッコ併記が 無いと私は考えています． とは言え，カッコ表記があると見られる name が7万以上あるので，数としては Mass Edit に当たるとは思いますが，それは日本の OSM DB の7％とも言えるので， チビチビやっていっても良さそうに思いますし，現地の事情を勘案しながら 修正するならば，Mass Edit は避けたほうが良いのではないか．と考えています． いいださんが Mass Edit になると言うのはどの様な理由によるものでしょうか？ ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． name の括弧表記ですが，東さんから提示されている以下の点を調べてみました． その意味で下記2点をクリアにする、あるいはクリアにする方向付けをしたり 従来の記述を修正する手順を考えた方が良さそうに思いますがいかがでしょうか。 1.name:en に書いた名称は言語切替でうまく表示されるようになったんでしたっけ。 PCとスマホで。少なくともこのアプリなら大丈夫というのが示せると良いですね。 2.以前、外国の方からnameは英語よりローマ字が分かりやすい、と聞いたことがあります。 （やろうと思えば）name:ja_rm で設定した名前はうまく表示されるようになったんでしたっけ。 1. については，PCでは交通マップを見ることで name:en が参照できます． スマートフォンでは，mapswithme を使うと，スマートフォンの言語設定を切り替えることで変わります． なお，私は Android 携帯で見てみたのですが，node の表示がが切り替わらないものの，これは切り替わるはずで，いいださん経由で開発者にお話頂いたようです． 2. は，現時点ではまだ表示されるレンダラを知りません． と言う事で，1. は切り替え表示が出来つつある．2. はまだです． クリアにする方向付けですが，1. はレンダラの開発者の尽力にお願いできればと思います． 我々日本の OSMer は，レンダラがより良くなるその日に向かって，タグを修正していけば良いかと思います． その中で特に，Hans さんの， name:ja_kanaを必ず入れるほうがいいと思います。僕はもういつも入れるけれど も、他のユーザはあんまり書かなさそうですね。でも ふりがながものすごく便 利と思っています。検索するときにもふりがなのあるほうがいいと思います。 上記の発言は，国内外を問わずに重要だと思います． 今はまだ出来ないとしても，name:ja_kana でふりがな検索できれば，ナビとしてもものすごく使えるデータになりますし， 海外の方にも，簡単な日本語（ひらがな）を覚えて頂けたらふりがなで検索頂ける可能性があります． 重要な事は，海外の方に読んでもらうためには，英語で記載するのではなく，基本的な日本語が分かれば検索できることだと思います． ここ一連の議論を見るに，基本的に括弧書きの廃止に肯定的な意見なので，日本のOSMer の皆さん，もう括弧書きは止めませんか． http://wiki.openstreetmap.org/wiki/Japan_tagging の変更点としては，name 部分だけです． これが進まないと，別途議論が進んでいるローソン店舗のインポートにも影響があるので，出来ればそろそろ本件は確定に向かいたいです． 個人的には，１周間程様子を見て，9月23日までに特に異論がなければ，http://wiki.openstreetmap.org/wiki/Japan_tagging の name 表記ルールを変更しようと思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] ローソンデータインポート、マージ手順案(was Re: 全国ローソンデータのテストインポートについて)
とし@秋田県です。
いまのOSMの大部分(特に道路と建物)の大部分が相対位置の正確さに依拠している以上、
絶対位置の正確さが正しいものを投入してもあまり意味はない気はします。
この部分の意味をはかりかねているのですが、私はこれまでの作図で相対位置の正確さに依存させた事は無いのですが、上記のお話の根拠はなんでしょうか？
私は、精度がよければその方が良いと考えていますし、それに最善を尽くしています。
正確な位置のデータが投入されるのは良いことかと考えています。
ローソンさんのデータについては、精度が分からないので尋ねた次第で、精度が客観的に良ければそれは良いと思います。
ではこれにて。
2013年9月14日土曜日 Satoshi IIDA nyamp...@gmail.com javascript:_e({}, 'cvml',
'nyamp...@gmail.com');:
いいだです。
完全に個人の意見です :3
としさん
このインポートデータの位置精度は、GPSのDOP(HDOP)ではどれくらいでしょうか?
すみません、具体的な数字はすぐにはわからないので、問合せをしています。
また、絶対精度が良い場合、HDOPがさらに良ければその方を採用するという事ですね。
つまり、インポートデータより私の自作ロガーの方が精度が良いならそれを採用するという事で良いでしょうか。
はい、そうです。
ローソン側も、このデータの位置精度は Survey で作っています。
なので、絶対位置としての情報は、僕達の位置とそんなにずれていない(はず)です。
また、インポートした後のデータを「やっぱ位置ちげーよ」と、Nodeを移動させるのはアリなのではないか、と思います。
ikiyaさん
ということはOSMデータ内に一般マッパーによる変更をよしとしないデータができてしまうと思います。
OSM内のローソン データに触れる人は偏り、提供元にコントロールされるデータにならないでしょうか。
Nodeに対するデータの量は増えますが、一般マッパーによる変更が制限されるとまでは思えません。
たとえば、店舗のひらがな名称は、ローソン側データのほうで撥音表記に誤りがある場合が見つけられており、
OSM上でそこに対して行った修正をまたインポートデータで無理やり上書きすることはよくないと感じます。
ローソンという提供元を1つのコントリビュータとみると、
OSM上でのタグや位置の変更をよしとせずにオリジナル側のデータをまた上書きするのではなく、
むしろ、間違っている可能性がある箇所をOSMで変更し、
変更したデータの差分を還元して元データのブラッシュアップに役立ててもらうほうが健全かな、と感じます。
インポートによる自動更新を行うとした時に、どこまで自動的な上書きを行うかは、まだ未定です。
個人的な印象ですが、強制自動更新ではなく、自動的なチェックが中心にしたほうがよいのでは、と考えています。
(基本的に自動的な上書きをせずに、差分発生アラートだけをあげる。
lawson:idなどのタグを作っても、理論上では重複の可能性あるので、
Node Object IDしか一意のものは生成できないなぁ、とも思っています)
【その２.】：精度の基準を知らせてください。
詳細な値はまだ確認中ですが、データはSurvey品質で作成されており、
ほとんどのデータは既存のOSMノードから数メートル程度の誤差になっている印象です。
(向日市の例があるので、全部が超精密な精度、とはとても言えませんが)
【その３.】：いったん絶対精度にあわせませんか？は唐突では？
そうですよねぇ。
いまのOSMの大部分(特に道路と建物)の大部分が相対位置の正確さに依拠している以上、
絶対位置の正確さが正しいものを投入してもあまり意味はない気はします。
どれだけあるかはわかりませんが、ローソン側の位置を採用することで
・道路の反対側に店舗が移動しちゃう
・Nodeが建物の外に飛び出しちゃう
などの事象は容易に考えられます。
それは、たとい絶対位置やタグ内容の鮮度が正しかろうが、
地図としての全体的な品質の低下を意味します。
これが、例えば基盤地図2500レベルの建物と道路がインポートされた後、など
絶対位置の正確さがそれなりに向上した状態でのインポートなら、
マージ時にローソン側データにあわせるほうが全体的な精度が向上すると思います。
ので、位置データは既存にあわせる、で＋1です。
あと、いままでOSMが幾多の失敗を重ねて作り上げてきた方針である、
インポートのガイドライン、「既存のデータを壊さないで」にも反します。
http://wiki.openstreetmap.org/wiki/JA:Import/Guidelines
確かにインポートデータの提供者もコントリビュータの1つではあります。
逆に言えば、彼らの権限と同じだけの権限も、既存コミュニティの1人1人が持つものと考えます。
あと、逆の発想ですが、もしローソン側データの店舗位置が
OSM既存データとあきらかに離れた場所にある場合、
その場所の近辺は Bing のオフセットが大きくずれている可能性が高い、とも言えます。
マージ作業中にそういう場所を見つけた場合、
なにかしらの手段で、別途注意喚起をしたほうがよいかな、とは思いました。
2013年9月12日 17:07 ikiya insidekiwi...@yahoo.co.jp:
ikiyaです。
３点ほど。
【その１.】：既存データとのマージはほぼインポートデータの上書きで、今後は自動更新では
ローソンデータに触れる人は偏るのではないでしょうか？
ローソンデータ・マージ手順書
既存のデータとインポート用のデータのマージ作業を行う際の手順について解説します。
・
・
■基本方針
・既存データの編集履歴は可能な限り残す
・ローソンデータと競合しない既存データのタグは、残す
・ローソンデータと競合する既存データのタグは、ローソンデータを採用する
・Nodeの位置 (緯度経度) は、ローソン側を採用する
・タグづけの競合が発生する場合、”ローソン側”を採用する
sourceタグは併記を行う
・以下の場合には、OSMの”ノート”機能を使い、コメントを残すようにする
(なお、JOSMのNoteプラグインを使うと、ノートの管理が楽です)
Nodeの位置が大幅に変わった場合
既存データがAreaで、リレーション化した場合
このマージ方法だと、
既存タグの内容とノードの位置座標ともにインポートデータ優先で上書きされます。
さらにこのローソンデータは日々、インポート更新を計画されるとのこと、
ということはOSMデータ内に一般マッパーによる変更をよしとしないデータができてしまうと思います。
OSM内のローソン データに触れる人は偏り、提供元にコントロールされるデータにならないでしょうか。
【その２.】：精度の基準を知らせてください。
田中さんも触れられている精度の問題で
ただ、ローソンさんのデータですが、実はかなり私達の調査方法に近い手法で、
さらに細かい精度をだせるやり方でノードを置いています。
(詳しく話せなくてごめんなさい。もどかしいです)
これは、緯度経度による絶対精度のお話です。
もちろんOSM側はみなさん(特に都市部では)とても気を使って
周辺の建物の位置などと調整されていると思います。
OSMの建物は、常にずれている可能性があることを想起ください。
これは、周辺の地物との調和、つまり、相対的な精度のお話で す。
どちらを優先しましょう？というお話で、
いったん絶対精度に合わせませんか？という提案です。
ちなみにそもそもマージ用に検索を行う場合、
「重複している可能性あり」と判定するのは15mくらいの半径でヒットさせようと思っています。
つまり、最大で30mくらいのNode移動になる可能性があります。
# 基盤地図25000を使っているくらいの感覚でしょうか。
と言われますが、
さらに細かい精度をだせるやり方でノードを置いています。
のコメントだけでは、精度の論点がぼやけています。
精度については透明化してください。1/2500、1/25000なり。
最後に言われている
# 基盤地図25000を使っているくらいの感覚でしょうか。
が精度の例えだとしたら、
私のハンディGPSのほうが精度が良い場合は考えられます。
【その３.】：いったん絶対精度にあわせませんか？は唐突では？
もちろんOSM側はみなさん(特に都市部では)とても気を使って
周辺の建物の位置などと調整されていると思います。
OSMの建物は、常にずれている可能性があることを想起ください。
これは、周辺の地物との調和、つまり、相対的な精度のお話です。
どちらを優先しましょう？というお話で、
いったん絶対精度に合わせませんか？という提案です。
先にも触れましたが、元データの絶対精度はどの程度なのでしょうか。
また今まで、多くのユーザーがいろ んなソースをもとに
相対的な精度を考慮しながらマッピング書いてきた経過があるのに
唐突に絶対精度をかざされても、地図自体も、ユーザーも調和はとれないと思います。
--- On *Thu, 2013/9/12, Toshihisa Tanaka tosih...@netfort.gr.jp* wrote:
としです
このインポートデータの位置精度は、GPSのDOP(HDOP)ではどれくらいでしょうか?
また、絶対精度が良い場合、HDOPがさらに良ければその方を採用するという事ですね。
つまり、インポートデータより私の自作ロガーの方が精度が良いならそれを採用するという事で良いでしょうか。
2013年9月12日木曜日 Satoshi IIDA
nyamp...@gmail.comhttp://mc/compose?to=nyamp...@gmail.com
:
いいだです。
ローソンのインポートデータですが、マージの手順書を作ってみました。
特に方針部分、違和感を感じる方が多いと思いますので、ぜひぜひご意見をください。
https://docs.google.com/document/d/1hsk4oBwnbtXSoQdqbwWkCsD5m4IYNgAEGr6J7HvMwCA/edit#
■問題になるところ
■1. 既存データがNodeで、ローソンデータがNodeの場合の位置情報
位置情報はローソン側のデータを採用したいと思っています。
「おいおい、調査で置いた情報が優先だろ？」というかた、たくさんいらっしゃると思います。
ただ、ローソンさんのデータですが、実はかなり私達の調査方法に近い手法で、
さらに細かい精度をだせるやり方でノードを置いています。
(詳しく話せなくてごめんなさい。もどかしいです)
これは、緯度経度による絶対精度のお話です。
もちろんOSM側はみなさん(特に都市部では)とても気を使って
周辺の建物の位置などと調整されていると思います。
OSMの建物は、常にずれている可能性があることを想起ください。
これは、周辺の地物との調和、つまり、相対的な精度のお話です。
どちらを優先しましょう？というお話で、
いったん絶対精度に合わせませんか？という提案です。
ちなみにそもそもマージ用に検索を行う場合、
「重複している可能性あり」と判定するのは15mくらいの半径で
Re: [OSM-ja] ローソンデータインポート、マージ手順案(was Re: 全国ローソンデータのテストインポートについて)
としです
このインポートデータの位置精度は、GPSのDOP(HDOP)ではどれくらいでしょうか?
また、絶対精度が良い場合、HDOPがさらに良ければその方を採用するという事ですね。
つまり、インポートデータより私の自作ロガーの方が精度が良いならそれを採用するという事で良いでしょうか。
2013年9月12日木曜日 Satoshi IIDA nyamp...@gmail.com:
いいだです。
ローソンのインポートデータですが、マージの手順書を作ってみました。
特に方針部分、違和感を感じる方が多いと思いますので、ぜひぜひご意見をください。
https://docs.google.com/document/d/1hsk4oBwnbtXSoQdqbwWkCsD5m4IYNgAEGr6J7HvMwCA/edit#
■問題になるところ
■1. 既存データがNodeで、ローソンデータがNodeの場合の位置情報
位置情報はローソン側のデータを採用したいと思っています。
「おいおい、調査で置いた情報が優先だろ？」というかた、たくさんいらっしゃると思います。
ただ、ローソンさんのデータですが、実はかなり私達の調査方法に近い手法で、
さらに細かい精度をだせるやり方でノードを置いています。
(詳しく話せなくてごめんなさい。もどかしいです)
これは、緯度経度による絶対精度のお話です。
もちろんOSM側はみなさん(特に都市部では)とても気を使って
周辺の建物の位置などと調整されていると思います。
OSMの建物は、常にずれている可能性があることを想起ください。
これは、周辺の地物との調和、つまり、相対的な精度のお話です。
どちらを優先しましょう？というお話で、
いったん絶対精度に合わせませんか？という提案です。
ちなみにそもそもマージ用に検索を行う場合、
「重複している可能性あり」と判定するのは15mくらいの半径でヒットさせようと思っています。
つまり、最大で30mくらいのNode移動になる可能性があります。
# 基盤地図25000を使っているくらいの感覚でしょうか。
なお、既存のノードの編集履歴は保存するようにマージします。
■2. 既存データでAreaとして書いてあるコンビニ
コンビニの情報をローソンデータのNodeに集約した上で、
リレーションにまとめたいと思っています。
「OSM Wikiによれば、Areaとして描くことも許されているのでは？」というかた、たくさんいらっしゃると思います。
はい、そのとおりです :)
ただ、この方法で描く方法の利点は2つあります。
2-1. コンビニの廃業を考える
コンビニが撤退することなどを考えると、
コンビニの敷地をlanduse=retailとして表現し、別途コンビニのNodeを置くほうが
表現としてスッキリすると思っています。
あくまでコンビニは、かなり一時的な店舗施設であり、その土地を持ち続けるわけではありません。
(では同様の描き方を学校などにも行うの？という意見、あると思います。それは別の議論として、ここでは開店閉店のサイクルが早いコンビニに焦点を絞らせてください)
2-2. データとして扱う際の取り回しやすさ
コンビニの店舗情報をNode側に持たせるか、
それともRelation側に持たせるか、悩ましいところです。
ただし、Node側に持たせることで、データを使う側として考えた時に扱いがしやすい、というメリットが有ります。
主にデータ利用者からして、「リレーションのことを考えなくて済む」「中心点を算出しやすい」というメリットが生まれます。
また、type=siteリレーションは、広く利用されているとはいえ
情報の定義に不確定さを持っており、利用するにはちょっとはばかられます。
(role定義がまともに決まっていない)
当然、テストをする段階で、悩む場面はさらに出てくるとは思います。
ひとまずのたたき台として、どうでしょう？
--
Satoshi IIDA
mail: nyamp...@gmail.com javascript:_e({}, 'cvml',
'nyamp...@gmail.com');
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです。 http://lists.openstreetmap.org/pipermail/talk-ja/2008-July/000571.html のスレッドを見る限りでは、当時 osm.org の地図描画に使用するフォントが日 本語に対応していなかったためという理由から name に英語を併記していたと読 めます。 私も同じ認識(と言うか記憶)です。 当時は日本語がちゃんと出なかったところでもあり、括弧書きで英文字を併記する方式で作図したと思います。 その上、もはや osm.org ですらとっくの昔に Unifont によって日本語名の表示 に対応しているのですから、name は現地表記のみに改めるべきです。 異論ありません。 加えて、最近は投入されるデータも増え、長い name が重なると、地図として 見難くなるので、 現地表記で良い(もう過去のしがらみに引きずられる事も無い)と考えています。 ではこれにて ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． 今後は多言語対応のレンダリングサイトもよりメジャーになってくると思います。 多言語対応のOSMレンダリングサイトがosm.orgのmapnikなみに利用できる環境になってから 現状のローマ字併記を消す、止めるのがよいかと思います。 私自身の感覚では，もう上記の様な環境になっていると思っています． 具体的に述べると，私はこれまで，NavDroyd,MapsWithMe,navit と，それぞれのレンダリングソフトで実際にナビしました． navit においては，大阪〜新潟(OSC新潟)間をナビしました．navit は日本語表示させるにはフォントの設定が必要ですが， フォントさえ設定してしまえば，日本語表示で特段困った事はありません． NavDroyd と MapsWithMe に関しても，インストールすれば普通に日本語で表示されるので困った経験がありません． また，OSMレンダリング（ソフト or サイト）が mapnik なみに利用できる環境を待つとすると，私達はいつまでも今のままであることを意味すると思います． OSMレンダリング（ソフトorサイト）は，今後も新しく作られていくでしょうし，それを期待したいところです． しかしそれらが mapnik なみに利用できるのを待つとすると，レンダリングソフトが枯れきるまでは切り替えが出来ないのではないかと考えています． 多国語対応のレンダリングを考えるとき，「多国語で表示できる」のと，「多国語の切り替えができる」の２点が挙げられると思いますが， http://wiki.openstreetmap.org/wiki/JA:Mapnik を読む限りでは，mapnik で多国語の切り替えをするには，データの前処理などが必要なようです． これらの事を考えると，私自身は，既に他のレンダリングソフトも多国語表示に普通に対応しており， ローマ字併記がレンダリングソフトのために必要という時期は過ぎたのではないか．．．と考えています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
としです． これまでレンダラーやビューアの言語切替機能が整うのを待っていた訳ですが 今回、その準備が整ったといえる状況になったということでしょうか。 最近あまりアプリを見ていないので状況がよくわかっていません。 私の認識では，多言語表示（表示するだけ）ならば整っていると考えています． しかし切り替えて表示できるのは，まだ整ってはいないと考えていますし， mapnik でもそれは現時点でもできていないと思います． 日本人には邪魔と感じる人が多いカッコ書きですが このスレッドを始められたFabienさんのように日本語があまり得意でない 海外から日本に来た人にとっては何はともあれOSMを実際の移動に 使う際に地名や駅名を判読する手がかりになっていたはずです。 http://osm.org/go/7QEmZP75t--?m= を例にすると，ここには阪堺電気軌道の御陵前という駅があるのですが， レイヤを交通マップにすると，name と name:en がレンダリングされていることが確認できます． mapnik を標準？？にすえると言うことでないならば，name と name:en 両方でレンダリングしてくれるものはあるので， そういう方々に対しては具体的に代替手段を提示する あるいは現時点で完全にできないとすればその方向性を考えることと併せて ルールを切り替えて行った方が良いように思います。 具体的に代替案を提示するならば，osm.org で交通マップを見る事で，name と name:en 両方が見られるはずと考えています． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 高精度データソースの利用についてマッパーの気持ち (Re: 鯖江市の都市計画図が CC BY で公開されました。)
としです． 私は今でも旧来ながら？のGPSログによるマッピングです． しかし、努力した地図データが精度や詳細さで劣るとき 速いスピードで置き換わることはありうるのかという気持ちです。 私は割りきって考えていまして，「正確なデータがインポートされるなら良いなぁ」と思ってたりします． GPSロガーを持ってマッピングするのは楽しいのですが，何しろ時間がかかります（汗 もしインポートなしで，GPSロガーだけしかマッピングするしか手段がないとすると，日本のOSM地図が完成するのは，後，数世代後の様にも思います． そうしてみると，この数年でここまでデータが投入されたのはすごいなぁと思っています． じゃぁもうGPSロガー持ってウロチョロとする時代ではないのか．．．と言うと，そうでもなくて， 例えば Pushpin に代表されるようなPOIの入力は，やっぱ現地に行って入れるかな．と思います． それに，一次ソースは正確．．．本当に正確でしょうか． 私は，もし「正確と言われるデータ」がインポートされたら，本当に正確なのか，自作のGPSロガーと測り比べをしたいと思っています :-) データがオープンになるのと並行して，GPSの測位性能も向上しています． 御存知の通り，私はGPSロガーを自作していますが，GPSモジュールの測位性能の向上もすごいなと感じています． 今は，みちびきに対応したGPSモジュールも個人で入手できるようになりました． 先日2月の妙見山マッピングパーティでは，実際にこのGPSモジュールでログを取りましたが， 従来GPSの受信が不利だった山あいでも，割と良い測位結果が得られるようになっています． 私が制作している自作GPSロガーは，インポートが主流？な今でも止めることは考えてなくて， むしろもっと積極的にGPSロガー（と言うかOSMロガー）を作りたいと思っています． 私は最近，高度や傾斜をマッピングしたいと思っています．これがマッピングできると，3次元地図が出来るはずだからです． 加速度センサーで傾斜を測り，気圧・温度センサーで海抜を測ることが出来るはずです． またGPSと加速度センサー(傾斜)の組み合わせで，建物の高さも計算で得られるはず．と考えています． 地磁気センサーがあれば，離れた場所のPOIの位置が計算で分かるはずです． 自作GPSロガーは，もう後1回か2回ほど試作して目処付けしてから，専用の基板を少数ですが制作しようと考えています． それが出来たら，OSMコミュニティの中で希望者を募り，希望者の方にそのロガーをモニター頂こうと考えています． 何とか年内を目指しています．希望者が０でも．．．まぁ，私一人で使います（汗 はたしてOSMのフォースは何でしょうか？ 物量ではインポートの方が有利ですが，「まだマッピングされていない分野」ってのは，きっと，まだまだまあって， 私はそう言ったまだマッピングされていない分野を開拓できればなぁ〜と思っています． 高度や傾斜も，もしかすると，既に正確なデータがインポートされているのかもですが，Bing で上から描かれたものは， これらはわからない．．．はずです． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] maps with me LITE
としです． 個人的に、いまのところオフラインで使えるケータイ用OSMとしては、 osmand と2強のアプリじゃないかな、って思ってます。 (機能としてはosmandのほうが多機能で、閲覧するだけなら MapsWithMe、みたいな) バイク（オートバイ）でOSMナビをした事があるのですが，個人的には， NavDroyd がナビソフトとしては一番良かったです． https://play.google.com/store/apps/details?id=com.osa.android.navdroydhl=ja NavDroyd が良いのは，今一番近い（つまり走ってるであろう）道の名前を 画面の下に１行ハイライトで出してくれるので，今 国道ｘ号線を走っていると言うのが見やすかったのです． （ただ，最近の NavDroyd は使っていないので，もしかすると仕様が変わっているかもですが） もしかすると，MapsWithMe や osmand(osmand+) でも同様な事ができるのかも知れないのですが， 先日 MapsWithMe でバイクナビをした時は，NavDroyd の様な画面の下１行に道の名前が出ませんでした． 今は MapsWithMe をメインに使っていますが，使わなくなった Android 携帯を蘇生させて， これは NavDroyd でOSM専用ナビにしようかなと思っています． osmand+ は，確か速度制限の標識が出たと思うので，これも便利かなと．．． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 8月31日チャリンコマッピングパーティin堺開催
としです． 31日当日の OpenStreetMap チャリンコマッピングパーティ in 堺 ですが，台風が接近していることもあり，自転車での移動は断念します． 歩きと阪堺電軌などで移動できる範囲か，または屋根のある商店街をメインにマッピングしたいと思います． 当日は天候が変わりやすいので，集合したら，まずは近くのマクドナルドで天候をふまえてマッピングの作戦会議をします． 当日の集合場所等については，http://atnd.org/events/42421 にコメントで書いています． 何分天候がどうなるか難しいですので，無理の無い範囲で参加をお願いします． ではこれにて． みなさま 奈良の西村です 8月31日（土）午後より，OpenStreetMap チャリンコマッピングパーティ in 堺が開催されます 下記で参加者募集を開始しましたので，参加希望の方は登録をお願いいたします． http://atnd.org/events/42421 今回は「自転車のまち堺」をテーマに，レンタサイクルもしくは個人の持ち込み自転車で移動しながら，OpenStreetMapの自転車関連情報（自転車道や駐輪場，自転車関連の工場・商店，博物館など）の収集を中心としたフィールドワークを行います（古墳マッピングもできるかも）．この暑いさなかに自転車マッピングというマッパーの耐久テストかと思われるような企画ですが，奮ってご参加頂ければ幸いです ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 全国ローソンデータのテストインポートについて
としです． 古橋です。 ... 都道府県ごとにインポートしましたので、 もし、大きな問題がありましたら Revert 処理いたしますので ご連絡ください。 またインポートデータの refキーは、今後の更新用に使用する予定ですので消去しないようお願い致します。 ref は，http://wiki.openstreetmap.org/wiki/Lawson_hackathon_2013 によると， 6桁の一意な整数値のようですが，この整数値の仕様は自由なもの， ありていに述べれば ref キーの6桁の一意な整数値は，仕様が公開されていますでしょうか？ この ref キーの仕様が公開されておらず，自由に出来るものではないとすると， 今現在，OSMには，自由ではないデータが入っていると考えるのですが， 問題はないでしょうか？ refキーはその更新のために重要なので、 どうぞよろしくお願い致します。 よくわかっていないのですが，そもそも ref キーをこの様に使うと言うのは，OSMとしては既に オーソライズされているのでしょうか？ また，重要であるとしても，このMLを購読していない OSMer もいると思いますし，もし ref キーを (意図せずに)変更した場合，技術的にどの様な不整合が出るかは教えて頂けたらと思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 全国ローソンデータのテストインポートについて
としです． データの重複は、今後のマージ作業を放置することはまったく考えておりません。 責任をもって対応いたします。 その結果、むしろデータ品質は向上していくと考えています。 古橋さんが責任を持ってするのではなく，OSMer のみんなが出来る方法に することが，大切な事の様に考えています． もしこれが古橋さんの責任とすれば，表現を変えると，ある特定のデータは， ある特定のユーザに編集が委ねられる事になります． それは，データの質が向上するとしても，誰でもが参加できる地図とは 言えなくなる．と私は考えます． 誰でもが自由に参加できる地図作りのためには，今回インポートされたデータは， 基本的には元データが得られなければならないはず．と考えていますが，いかがでしょうか． 引用が前後しますが， 良いアイディアについては、マージ後にも発生しうるであろう、POIデータの重複の検出など、 定常的な技術についてむしろ議論をすすめていきたいと考えております。 元データの仕様や技術的情報が不明なままで，OSMer のみんなが良い方法を考えるのは， 中々に難しいように思うのです． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 全国ローソンデータのテストインポートについて
としです． 確かに、ローソン側との協議(NDAの関連で)と、実際の試験投入まで時間が足りず、 talk-ja へのご報告が遅れてしまったことは、完全にこちらのミスです。 一応，念の為に，ここで NDA の表現がありますが，今回のインポートは NDA 外ですよね？ http://wiki.openstreetmap.org/wiki/Lawson_hackathon_2013 に，License: (c) Lawson, ODbL とありますから，元データも ODbL 競合しないはずと思いますが，NDAの表現が出たので， 一応念のための確認です． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] Talk-ja で受け取れるメールサイズに関して
OSM Talk-ja の皆さん： とし＠ML管理者の一人です． （少し前からML管理のお手伝いをしています） OSM Talk-ja ですが，数としてはごくごく少ないのですが，メールサイズリミットに 引っかかってメールが承認待ちになる場合があります． 現在のメールサイズリミットは 40KB です．これを超えるとメールが承認待ちになります． リミットのサイズに関しては何とも即判断は難しいのですけれど，添付ファイルでリミットを 超えたり，長めのスレッドで全文引用が続くとリミットに達しますのでご注意頂けたらと 思います． 判断は難しいですけれど，今のところは数としては少ないこともありますので，しばらく 様子を見て，増えてきた場合は，その時にどうするか皆さんとコンセンサスを得られたらと 思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] nameタグWikiページの更新
としです．
山下と申します。こんにちわ。
...
株式会社の略称として「（株）」「㈱」
有限会社の略称として「（有）」「㈲」
を「使わないでください」の対象外と考えたいのですが、
いかがでしょうか？
これは，3点の検討事項がありますね．
1) 法人格名を name に含むかどうか．
法人格名：「株式会社」「有限会社」「社団法人」「医療法人」等．
2) 法人格名は省略形にしても良いかどうか．
3) 法人格に略称を用いた場合のエンコーディング
法人格を name に含むかどうかは，その法人の正式名称には法人格名が
含まれますので，含んだほうが良いかなと思っています．
法人格に省略名を用いるかどうかですが，これはコンセンサスが必要かも
しれません．私個人は，法人格名に限っては略称も良いかなと考えています．
法人格に略称を用いた場合のエンコーディングですが，'(株)'や'(有)'は１文字と
して扱えるとは思いますが，医療法人('(医)')や宗教法人('(宗)') あたりは，
１文字として扱えましたっけ？
山下さん，医療法人（病院は概ね医療法人かと）や宗教法人（お寺など）の
法人格は，向日市の場合はどの様に入力されていますでしょうか？
私（堺市）の場合，実は法人格名まではきっちり入れていないので，改めて
法人格名を入れるかどうか，自分なりに考えてみたいと思っています．
ではこれにて．
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] nameタグWikiページの更新
としです． 法人格名（株式会社，有限会社）の略称に関してです． 山下です。こんにちわ。 ... 本来なら、こういうのも日本全体で統一したルールに 則るべきなのでしょうが、、 あまり良い方法とは言えないのですが，国土地理院も含めた，他の地図サイトを 眺めてみたのですが，法人格名の表記（表示）は統一性が無さそうですね． 私見ですが，他の地図サイトを眺めると，下記の様な印象があります． a) 法人格名までは書いていない(固有の名前だけを表示する) b) 法人格名を表示していても，株式会社は「(株)」と略字が使われている． このあたりは，元々の山下さんの見解にある， POIが混んでくると「株式会社」と４文字も幅を取られると 隣のPOIと重なってレンダリングされない という事象が多々発生します。 と言う事情があるのからかも知れません． これは，おささんのメールにあるレンダラーの能力かも知れません． レンダラーが「株式会社」を「(株)」と描きさえすれば，このあたりで悩む 必要は無くなると思います． ... 私自身，本件 Web で調べてみたり，色々と考えてみましたが，法人格名までは， あまり厳密にしなくても良さそうに感じて来ました． 正式名称が「株式会社」として，「(株)」と記しても， もし略称を使うべきでないとなっても，(株)が１文字でも３文字でも， 山下さんの初めのメール通り，機械的に置き換えできると考えています． 後の東さんからのメールにありますが，法人格名が別のタグで表現する（できる） ならば別のタグで表現し，それが難しい場合は，法人格名に限り略称記載可能 （これは機械的な置き換えが出来る範疇と考えられるから）で良いような感が あります．ただ，略称名は統一が必要ではあります． 残るは(株)を１文字で表現するかどうかですが，う〜ん．．．他の法人格名が １文字で表せないのに，(株)と(有)だけを１文字で表すと言うのは，私個人は 少し消極的です． とは言え，１文字の(株)も３文字の(株)も，割と見つけやすいと思いますので， どっちでも良いかなぁと感じます． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSM Track は iOS Map を参照している?
としです． みのうらです 先日電車に乗っていて気づいたのですが、iPhone のGPS は移動中、 なるだけ道路に追従しようとしているのではないでしょうか? ... http://farm9.staticflickr.com/8411/8708922810_40a935b8d0_o.png http://farm9.staticflickr.com/8539/8708922902_4bc8453d24_o.png 画像を拝見しました． http://farm9.staticflickr.com/8411/8708922810_40a935b8d0_o.png を見ると，これが電車からのログであれば，マップマッチングの挙動に似ていると思います． 紫色のトラックの南北に着目すると，ログが急なズレを見せますが，基本的に道路に沿って おり，これはGPS単独測位では出ない挙動と思います． もしもこれが本当なら、iOS Map を参照している GPS ログは、マッピングには 使えないのではないでしょうか? 詳しい方がいらっしゃったら教えてください。 私は詳しくありませんが，この画像を見る限りでは， * iOS の location API では何かしらアシスト情報が使われている． →まぁ，location API は，GPS以外の情報も使われていますが(※) * アシスト情報を使う過程で，マップマッチングされても不思議ではない． とは思います． ※：http://support.apple.com/kb/HT5467?viewlocale=ja_JP 何にしましても，iOS もそうですが，Android も位置情報を得るために多少なりとも アシスト情報を使うと思いますので，iOS と Android の位置情報ログは，アシスト情報を 含んだ位置情報ログで，GPS単独のログではないと考えた方が良いように思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 複数の道路名併記について
としです． この議論を見ると，道路の通名（通称も含めて）は，実は関西ローカルなのかな？と思ったりもします． 山下と申します。こんにちわ。 ... 複数のnameタグへの道路名併記を廃止する方向でよろしいでしょうか。 廃止されて、みなさんは困らないのでしょうか？ 私はメチャメチャ困ります． とは言え，後に続く Show-ichi さんのお話にある， highway の名前については、それが何であろうと、現地に掲示してあるものを記述する、で良いと思います。 であれば，そう困るものでもないように思います． 「現地に掲示してあるものを記述」ですから，OSMを用いたナビをする場合も， 現地に掲示してある看板とOSMの name が合っていれば，ナビとして使う際にも 実用と思います． 同じ議論は，道路のみならず，建物や遺跡などでも言えるかと思います． このあたりは，基本的には「名前は現地に提示しているものを記述する」としておけば， 道路以外の場合にも適用出来るでしょうし，ルールとしても覚えやすいと思います． 現地に複数記述があれば，そこをどうするかが論点かと考えています． ここも，Show-ichi さんの見解にある通り，ケースバイケースなのかなと思います． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
