国土数値情報の行政界データをロードしてみる
気をとりなおして緯度経度のデータを入れてみます。国土数値情報（国交省）のデータはXML(JPGIS)形式による提供です。このXMLをShape形式に変換ツールもダウンロード可能になっているので、XML -> Shape -> SQL Server という流れでデータロードしてみます。
たとえば北海道だと6843/6846件はロードできますが、3/6846件は上記のようなエラーメッセージが表示されてロードできません。ポリゴンが左巻きになってないというエラーです。
とりあえずデータが間違ってるのかコンバータがバグってるのか調べるのが面倒なので元のXMLファイルを直接いじります。エラーになるポリゴンを逆順にする方法は、対象ポリゴンの全ポイントの定義を並び替える...とかだと死ねますが、さすがJPGIS、もうちょっと簡単にできます。エラーが起こってるGM_Surfaceの定義を探し出して、GM_Ringを構成するラインの並びをちょちょいと書き換えればおｋ*1。
たとえば、
↓こんな感じの定義があるので、 <jps:GM_CompositeCurve.generator idref="oc6942ec"/> <jps:GM_CompositeCurve.generator idref="oc6862ec"/> <jps:GM_CompositeCurve.generator idref="cv6860ec"/> <jps:GM_CompositeCurve.generator idref="cv6761ec"/> ↓ 要素の並びを逆順にしてプレフィクスを oc ⇔ cv に入れ替える。 <jps:GM_CompositeCurve.generator idref="oc6761ec"/> <jps:GM_CompositeCurve.generator idref="oc6860ec"/> <jps:GM_CompositeCurve.generator idref="cv6862ec"/> <jps:GM_CompositeCurve.generator idref="cv6942ec"/>
で、念のため投入されたデータを確認します。
これはひどい。
なんでこんなに化けてるかというと、国土交通省の変換ツールで生成されるDBFファイルはLDIDが設定されないのです(´･ω･`)。
LDIDに値がセットされていないDBF自体は非常にありふれていて、実際MapInfoなどの一般的なGISツールやオープンソースのツール類の多くもLDIDを設定しません*2。また、残念ながらShapeファイルローダーの作者はLDIDを信じるポリシーで*3、読み込み時にロケールの手動設定をできないという仕様と相まってこんなことになってしまいます。
Shapeファイルに付随するDBFファイルの29バイト目をバイナリエディタなどで0x13に書き換えてから読ませましょう。とりあえずこれでロードはできます。MortenさんのVisualizerで確認するとこんな感じ。
北方領土*4がないとかいう突っ込み禁止。
... 続く
*1:さすがにこれがまっとうな解決とは思ってない。むしろ、JPGISのスキーマうぜえという意見を否定する気はないがたまには便利なこともあるという例を示してみたかっただけともいう。
*2:国土交通省のXML->Shape変換ツールがｘｘとは単純には言い切れないところです
*3:Shapeに規格準拠を云々しても仕方ないのかもしれないが、ESRIがLDIDつかえと言ってる以上Shape作るときはLDID入れるべきだし、現実問題としてLDIDを正しく入れたShapeを作る実装がESRI以外ほとんどない以上、Shapeを読むときはLDIDだけに頼った判断をすべきでない、と思う。そういう意味で今回の問題は書くほうも読むほうもアレだ(はるか昔にMortenさんに説明したことはあるけど...)。
