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

2008年 3月 24日 (月) 02:13:08 GMT

tatata tatata wrote:
> 08/03/23 に Hiroshi Miura<miurahr ＠ acm.org> さんは書きました:
>   
>>  皆さん、では、国土数値情報にある内容については、個別に作業するのは
>>  やめた方がいいようですね。
>>
>>  Tatataさん、国土数値情報のデータについて、登録するのは分散して可能なのでしょうか。
>>  あるいは、共同の専用サーバがあったりすると、作業が容易なのでしょうか？
> うーん、作業の進め方については迷いますね。元々私は別のプロジェクトで使える地図が
> 欲しくてOSMに来たので、データの変換をしたら編集無しで一気にインポートしてしまいたい
> という衝動にも駆られるのですが、それはちょっと難しいような気がします。
>   

了解しました。つまり、提案は、

１）インポート方法を整理したガイドやスクリプトを整備
２）取り込みは、地域を分担して、参加者による手動でWiki的に実施する。

ということですね。わたしは２について意見がありますが、まず１については、
鉄道データ以外について、プログラミングスキルのある方の参加（分析とスクリ
プト作成）を期待
ということですね。どなたか鉄道データ以外にチャレンジしてみませんか？


> データの中身を見たり変換スクリプトを作ったりしたのは、まだ鉄道データだけですが、これに
> 関しては次のような問題点があります。
> * 既にOSMに存在している情報には鉄道データに無いものがある。 [1]
> * 鉄道データでは1つの路線が多くの区間に分割されており、路線名がレンダリングされる
> mapnikでの表示のことを考えると適当な間隔でwayの結合を行った方が良い。（スクリプト
> での結合は断念しました。）
>   
了解しました。鉄道データも道路のデータも同様ですが、適当な区間で結合が必要
ですね。これは、参加者が利用をイメージしつつ、手動で行うのがよいのですね。
（例：東武野田線ならば、岩槻からの乗車が多いから、岩槻駅付近で区切ったほうが
　地図にレンダリングされたときに、表示が具合いい、とか）


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

2-2) 2-1を実現することに興味のある参加者（プログラミングスキルのある方）
の協力を求めます。
> また、現時点でも分かっている鉄道データ以外にも共通する問題点としては、nameタグ [2]
> で使用する英語表記やローマ字表記の値が国土数値情報のデータには無いことです。
>
>   
はい、たしかにデータがないということは、参加者が入れていく必要がある、
ということですね。

> 編集無しで一気にインポートしてから直すという方法もありますが、狭いエリアごとに
>   
そう思ったんです。maplintによってエラー表示を見られますので、
それを頼りにあとからデータを追加できます。

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

提案ですが、
もう一つの方法として、一次加工データを別サーバで保持し、
加工がすんだデータを順次、インポートしていく方法はどうでしょうか。

加工が済んだかどうかは、データのもつ属性で、最低限必要とされる情報がそ
ろったかどうか、
（アルゴリズムとしては、ＮＵＬＬ値か、値が入っているか）によって判断して、
アメリカのTIGERのように自動インポートしていく、というものです。

ただし、これには、Mapserverをもう一つ立てるというハードルがあります。
ソフトウエアは、幸いにも、OSMプロジェクトがOSSライセンスで提供しているので
使えると思いますが、国土数値情報にあわせたアルゴリズムを追加開発を
する必要がありそうです。もちろん、サーバハードウエアの調達や
データセンターへの設置など、超えるべきハードルが高くなります。

> なので現時点では、スクリプト、ガイド、（鉄道路線名・空港名・湖沼名などの）個別のインポート
> 対象の一覧表などのツール類の整備を行って、実際のインポート作業は特定の地域の地図作り
> を行っている各参加者の判断にお任せしたほうが良いのではないかと思います。自分のGPSで
> トレースしてmappingしたい人もいるでしょうし、既にOSMに存在している情報も尊重したいので...
>
> 何か良いアイデアがないか、皆さんのご意見をお待ちしています。
>   
この議論は、Wiki上で展開したほうがいいでしょうか？


>   
>>  後者がよいならば、整備したいなーと思います。どっちにしても、Mapnikで
>>  日本の地図のレンダリングを日本ルールのカラーでやりたいと思っており、
>>  そのためには、早くてメモリーがいっぱい乗っているサーバ機を調達するのが
>>  必要だと思っています。
>>
>>     
>
> 凄いですね。私もosmarenderのスタイルよりmapnikの方が好きなので、期待しています。
> 今のところOSMサイトのmapnikは日本語表示できませんが（osmarenderの方も日本語
> フォントを持っているT ＠ Hのクライアントが処理したタイルでしか表示されませんけど）、
> mapnikの開発に携わっている人には日本語表示 [3] の方法が分かっているようです。
> 実際の方法自体は書かれていませんが、先ほど関連するmailing listへのリンクを
> バグレポートに貼ってきました。 [4]
>   
はい、こういった用途でも問題なく埋め込めるフォントについては、
http://www.da-cha.jp/?q=ipafont
というページを作成し、OSM-talkでの議論について返信して開発者の方に提供して、
表示されることを確認しています。

ただ、フォントに含まれる属性情報について
扱いがうまくいかないのか、欧文についてフォントのカーニングが
崩れる事象が発生していて、その解析が必要そうです。

osmarenderのほうも、i18nの観点から配布されるソフトウエアや
動作環境にて、Unicodeで表現されるすべての文字セットについて
表現できるフォントを提供するとか、必要条件にいれるとか、
必要だとおもいます。


>   
>>  ＃最近、ＨＰのＭＬ１１５がやたらとやすい（キャンペーン中）ので、
>>  ＃マシン室を探して、置きたいと思っているところです。
>>     
>
> 私は古くて遅い死に掛けのノートPCを主に使っているのですが、新しいPCに乗り換える
> 気も起きなかったので最近の値段を全く知らないのですが、「キャンペーン価格 ￥15,750
> （税込）～」って凄いですね。メモリーを一杯積むとそれなりの値段になりそうですが...
> これだったら昔途中までやり掛けて止めてしまったlinux機に使いたいような気が。（面倒くさくて
> 実際にはやらないと思いますけど。）
>   
参考までに。知人に聞いたところ、この機種はECCなしのその辺の部品屋で
うっているメモリもつかえるのだそうです。
なので、個人ユースの場合は、最小構成で購入して、部品屋の安いメモリを
いれて使うという例もあるようです。
ただ、サーバなので音については考慮されていません。なので、冷却ファンを換装
するなどの記事が、ブログ等ででています。


三浦