[OSM-ja] 国土数値情報のインポート条件整備

Satoshi IIDA nyampire @ gmail.com
2012年 11月 27日 (火) 04:31:27 GMT


いいだです。

>バス停インポート
いいですねー。
バス停は更新が多いのでそのまま使うのはちょっと気が引けますが、
下書きとして割り切ればかなり使えるデータだと思います。

> 少々精度が悪くてもデータが少ない地域はバルクインポートで降らせたほうがいいのか、
> Knowledge/survey の補完データとしてインポートデータをマッパーに提供したほうがいいのか、

インポート用データを再配布してしまうのは、整形したデータとはいえライセンス的に懸念がある気がしますので、
変換の手段を提示しておいて、各自の変換・投入にまかせる方式がよいかな、と思いますが、どうでしょうか。

重複して投入されてしまう懸念はありますが、
近隣にバス停のNodeが無い場合にのみインポート作業が可能になっているようなので、
大きな問題にはならないと思っています。



2012年11月18日 11:33 yuu hayashi <hayashi.yuu @ gmail.com>:
> hayashiです。
>
> 国土数値情報の「バス停」データについて、
> 試験的にインポートデータを作って見て気がついた点を散文的にWikiに書き込んでみました。
>
> http://wiki.openstreetmap.org/wiki/Talk:Import_Bus_stop_from_%E5%9B%BD%E5%9C%9F%E6%95%B0%E5%80%A4%E6%83%85%E5%A0%B1
>
> http://wiki.openstreetmap.org/wiki/Import_Bus_stop_from_%E5%9B%BD%E5%9C%9F%E6%95%B0%E5%80%A4%E6%83%85%E5%A0%B1
>
> 一応、変換プログラムもダウンロードできるようにしていますので、興味のある方は試して見ることも可能です。
> 既存のバス停タグとダブらないように150m周囲にbus_stopノードが存在しない時のみOSMノードを作成する機能をつけています。
>
> 私の感想ですが、バス停の位置が「上り・下りの中間点に設定」されていることと、基準としている縮尺がOSMに書き込まれているものよりも小縮尺なようで、位置がかなりアバウトです。
> 入り組んだ道を走るコミュニティバスのバス停だと平気で路地1〜2本ずれたりします。
> インポートデータをそのまま投入するのは気が引けます。
>
> そこで、YahooALPSデータのように人力で投入するほうが良いような気がしたので、変換プログラムも路線バスの経路毎にインポートファイルを分けて、マッパーのKnowledgeベースで投入しやすいようにしています。
>
> 少々精度が悪くてもデータが少ない地域はバルクインポートで降らせたほうがいいのか、
> Knowledge/survey の補完データとしてインポートデータをマッパーに提供したほうがいいのか、
> ご意見をおまちしています。
>
> 私個人はバスを利用しないので「バス」のことはよくわかりません。
> しかし、バス停をマッピングすることで住所とは異なる「地名」が浮かび上がってきてバス利用者じゃなくともなかなか興味深い地図が出来上がります。
>
> また、バス停のsurvey自体が意外と楽しい作業です
> ・GPSロガーがなくてもできる
> ・夜間もできる
> ので通勤・通学の帰りに「バス停狩り」がお勧めです。
>
>
> 2012年11月17日 22:16 Satoshi IIDA <nyampire @ gmail.com>:
>> いいだです。
>>
>> ちょっと間が開いてしまいましたが、
>> インポートに関するスタンスの変更をうけ、
>> 国土数値情報のインポートについて、いちど整理したいと思います。
>>
>> こんなかんじかな?というたたき台を作ってみましたので、
>> ご意見いただけると嬉しいです。
>> 国内でOKがとれたら Imports MLで報告をして、
>> みんなが安心してデータ利用できるようにしたいです。
>>
>> ■国土数値情報の元データ
>> 変更なし
>> http://nlftp.mlit.go.jp/ksj/gml/gml_datalist.html
>>
>> ■インポート用データの変換スクリプト
>> 既に開発されているスクリプトがある場合、継続して利用可能。
>> なお、元データがShpであれば、以下のスクリプトも使えます。
>> 変換ルールを pythonで記述する必要がありますが、非常に強力なツールです。
>> https://github.com/pnorman/ogr2osm
>>
>> ■利用するタグ
>> ・タグ基本セット
>>     source = KSJ2/NO3   [注: NO*の部分にはデータごとの識別子を記入]
>>     source_ref =
>> http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import
>> [注: 決め打ち]
>>     note:ja = 国土数値情報(行政区画)平成24年 国土交通省  [注: ( )の中にデータ名称を記入。利用した年度も都度変更]
>> ・データセットごとの追加タグ
>> データセットごとに、MLで議論。
>> 結果をWikiページに書き込んでまとめ。
>>
>> ■従来との変更点
>> ・インポート対象データがWay、あるいはAreaの場合、Nodeへのタグづけは行わない
>> →従来はWey、あるいはAreaを構成する全てのNodeに対して、
>>  sourceタグや緯度経度を含む、全ての情報を記載していました。
>>  今回、データの利用条件として「Wikiページを作成する」などの条件付けが明確になったことを踏まえ、
>>  ウェイ・エリアを構成するノードへのタグ付けは行わないようにしたいです。
>>
>> ・インポート用アカウントの作成
>> →先日Data Working GroupのPaulさんからも投稿がありましたが、データインポートの条件が変更になり、
>>  インポート専用アカウントが必須になりました。
>>  (OSM Wikiでも、従来は「専用アカウントの作成を考慮してください」だった記載が、
>>  「専用アカウントを作成してください」に変更されています)
>>  ついては、インポート作業を実施する際は、通常のアカウントとは別に
>> インポート専用アカウントを作成して、そのアカウント経由でアップロードを行うようにします。
>>  アカウント名はなんでもよいみたいで、例えば僕(nyampire)ならば
>> "nyampire_import"などを別に作成することで条件を満たせるようです。
>>
>> ■インポート対象にするデータ
>> まずはライセンス移行で消滅してしまったデータについて復旧させたいです。
>> 具体的にはこのあたりです。
>>  ・行政区画
>>  ・一部の鉄道
>>  ・一部の湖沼
>> また、バス路線は非常によいデータなので、これもインポートできたらなぁ、と思っています。
>> (既に投入されているデータとの重複チェックが必須になりますね)
>>
>> ■imports MLへの報告
>> 日本国内の方針が固まった時点で、imports MLへ報告をする予定です。
>>
>> ご意見をお待ちしています。
>>
>>
>> --
>> Satoshi IIDA
>> mail: nyampire @ gmail.com
>> twitter: @nyampire
>>
>> _______________________________________________
>> 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



-- 
Satoshi IIDA
mail: nyampire @ gmail.com
twitter: @nyampire



Talk-ja メーリングリストの案内