[OSM-ja] 国土数値情報の利用に際して

2008年 3月 24日 (月) 10:17:23 GMT

08/03/24 に Hiroshi Miura<miurahr ＠ nttdata.co.jp> さんは書きました:
>
>  ということですね。わたしは２について意見がありますが、まず１については、
>  鉄道データ以外について、プログラミングスキルのある方の参加（分析とスクリ
>  プト作成）を期待
>  ということですね。どなたか鉄道データ以外にチャレンジしてみませんか？
>

鉄道データについてもperlなど他のソフトウェアの導入をせずに単体で実行できる
プログラムがあると使いやすくなるかも知れませんね。国土数値情報のファイルを
xmlからshapeに変換するツールを導入する際にJREの導入もできるようなので、
javaでも良いかも知れません。もしプログラムを作れる方がいらっしゃいましたら、
宜しくお願いします。

>  ２については、
>  2-1) 作業の重複やデータの重複登録をうまく避けつつ、効率的にインポートす
>  る仕掛けがあったほうがいいですね。
>  また、これは
>  2-1-1) インポートの元データ（スクリプトによって一次加工されたもの）を提
>  供するサーバ・サービスがあるとスムーズ。
>  2-1-2) 取り出した元データについて、作業を宣言したり、他の作業者に知らせ
>  るサービスがあるとスムーズ。
>  ではないかとおもいます。

確かにその通りです。ただ、インポート作業自体は個々の対象についてはone-timeなので、
既にあるソフトウェアで利用できるものがあれば一から作成することを避けられるのですが...

>  そう思ったんです。maplintによってエラー表示を見られますので、
>  それを頼りにあとからデータを追加できます。

すみません。何だかよく分からなかったのでmaplintは見ていませんでした。後で見てみます。

>  > サーバーからダウンロード・ローカルで編集・サーバーへアップロードのという作業を何度も
>  > 繰り返すよりも、一つ或いは幾つかの対象ごとに予めローカルで編集を済ませてから
>  > インポートした方が作業自体が楽なような気がしますし、
>
> なるほど、そうかもしれません。作業してくれる人が多数だとまた違うかもしれ
>  ません。
>  > nameタグの情報が揃っていない
>  > ものがOSMのサーバー上に大量にある状態だと日本語表記だけを行うのが標準であるか
>  > のような印象を新規の参加者に与えてしまうことが心配です。
>  >
>  参加者へのミスリードを誘発する可能性があるんですね。了解です。
>  では、一気にインポートするという考えはしないようにします。

そうですね。情報が足りない箇所を簡単に把握できる仕組みがあって、参加者が多ければ
一時的にそのような状態になっても大丈夫かも知れません。
nameタグの使い方自体についても、まだ参加者が少ない時に私が書いてしまったものなので、
そのままで良いのかどうか少し不安があります。これはこれでご意見を伺いたいと思いますが、
そのままで良いことを前提として一次加工のデータを、例えば、

<tag k='name' v='九州新幹線 ()' />
<tag k='name:en' v='' />
<tag k='name:ja' v='九州新幹線' />
<tag k='name:ja_rm' v='' />

として作成した場合に、OSMのapi、データベース、potlatch、JOSMなどでエラーになったり、
タグが消されてしまわなければ、名称の最後が () になっているものをメインの地図から見つけ
られますし、valueが設定されていないname:enやname:ja_rmを見つける仕組みを作れるかも
知れないので、一気にインポートするという考えを捨てなくても良いような気がします。
（まだ、迷っているのです。すみません。）

>
>  提案ですが、
>  もう一つの方法として、一次加工データを別サーバで保持し、
>  加工がすんだデータを順次、インポートしていく方法はどうでしょうか。
>
>  加工が済んだかどうかは、データのもつ属性で、最低限必要とされる情報がそ
>  ろったかどうか、
>  （アルゴリズムとしては、ＮＵＬＬ値か、値が入っているか）によって判断して、
>  アメリカのTIGERのように自動インポートしていく、というものです。
>
>  ただし、これには、Mapserverをもう一つ立てるというハードルがあります。
>  ソフトウエアは、幸いにも、OSMプロジェクトがOSSライセンスで提供しているので
>  使えると思いますが、国土数値情報にあわせたアルゴリズムを追加開発を
>  する必要がありそうです。もちろん、サーバハードウエアの調達や
>  データセンターへの設置など、超えるべきハードルが高くなります。
>

この方が安全そうで作業もやりやすそうですけど、ハードルが高そうですねぇ。
自分自身でデータセンターを利用したことがないので、どの程度の高さのハードルなのか
ちょっと分かりません。

>
> この議論は、Wiki上で展開したほうがいいでしょうか？
>

個人的にはmailing listはあまり使ったことが無いこと（こんなにやりとりしたのは今回が
初めてです）と他のWiki系プロジェクトからここにやって来たことから、Wikiの方がやりやすい
です。Wikiで長い議論が展開されているノートページを開くと、その瞬間にうんざりしてしまい
ますが、ある程度まとまったらサブページにアーカイブするなどの整理ができますし、議論の
過程で出された意見やアイデアを後から来た人が読む場合にもmailing listよりは使い易い
気がします。ただ、Wikiは自分からそのページを直接見に行って更新をチェックするか、
ウォッチリストに入れてウォッチリストをチェックしなければなりませんので、現状では他の
参加者に気づいてもらえなそうですね。提案や意見を求める際にmailing listでお知らせすれば
いいですかね。

>
> はい、こういった用途でも問題なく埋め込めるフォントについては、
>  http://www.da-cha.jp/?q=ipafont
>  というページを作成し、OSM-talkでの議論について返信して開発者の方に提供して、
>  表示されることを確認しています。
>

mapnikでの日本語表示が楽しみです。

>  なので、個人ユースの場合は、最小構成で購入して、部品屋の安いメモリを
>  いれて使うという例もあるようです。

うっ。でも、手を出したらそっちにハマッテしまいそうです。

ところで、今朝のたろかわさんのメールに、

>  自宅周辺の地図を見たところ、ある意味では当たり前なのですが、
>  見事に真っ白ですて、こりゃ容易には手を出せない、、、という
>  感じでした。　ちょっと挑戦はしてみたものの、白紙に地図を
>  書くのはかなり難しく、まず、主要道路の形状やランドマークとなる
>  建物等の座標が確定していないと作業が進められませんな。

とあり、さらに先ほど森さんのブログを拝見して数値地図を使ったほうがいいのかなと思い、
国土地理院の承認申請を読んでいたのですが、国土数値情報と違いハードルが高くて
無理そうでした。道路の情報が取れるかなと思ったのですが...

で、国土数値情報の旧フォーマット（国土数値情報統一フォーマット）には1995年（平成7年）
の道路データや1975年の文化財データなどがあり世界測地系にも変換されているのですが、
データ作成年度が古くても（無いよりはマシということで）データをインポートできた方が良い
でしょうか？

-- Tatata