データ変換でエラー発生。内側境界のある地番

26.9.07(月)

一つ前の記事に、登記所備付地図から抽出した電子筆データの並べ替えを書いたが、並べ替えてもデータの形式は当然ながら GeoJSON のままである。グーグルマイマップで表示するには、これを KML 形式に変換しなければならない。GeoJSON から KML に変換するマクロも数日前に作ったが、その前にいったん GeoJSON 形式のまま、プロパティや経度・緯度1組毎に改行を入れるなど、見やすい形に整形することを前提としている。そうしないと見づらくて、どんな筆データかわからないし、なによりマクロで扱いにくい。その見やすい形に整形するマクロも数日前に作った。

今回も、そのマクロで整形をしたら、途中でエラーが出た。なんでだろう？ ここ数日、正常に動いていたのだが・・ 調べたら、[経度,緯度]],[[経度,緯度],の並びをエラーとしていた。あれまあ、内側の境界線でエラーか。

GeoJSON 形式でも KML 形式でも、ポリゴン（多角形）は外側の境界線だけではなく、内側に境界線がある場合にも対応できるようになっている。作成した整形用のマクロでは GeoJSON 形式ファイルの中の [経度,緯度],[経度,緯度],・・の ],[ 部分に改行を入れ、
[経度,緯度],
[経度,緯度],
　：
と整形しているのだが、マクロがエラーと判定した ]],[[ は境界線と次の境界線との区切りで、1つ目は外側の境界線、2つ目以降は内側の境界線となる。土地の筆データは、ほとんどが外側の境界線だけだが、内側に境界線がある筆があるんだな。ちょうど、サンマリノ共和国を囲むイタリアや、レソト王国を囲む南アフリカ共和国みたいなものだ。
 

"coordinates":[[
    [経度,緯度],
        ：
    [経度,緯度],
]]

と整形してきたが、境界線と境界線の区切り ]],[[ を見つけたら、

"coordinates":[[
    [経度,緯度],/*外側の境界線*/
        ：
    [経度,緯度],
    ],[
    [経度,緯度],/*内側の境界線*/
        ：
    [経度,緯度],
]]

のように整形しなければならないのだな。ここ数日正常に動いていたマクロなのだが、このパターンには対応していなかった。でもまあ、見逃さずにエラーと判定してくれたおかげでこの機能不足に気付いた訳だから、良しとしよう。また、日本国の土地の筆データには、外側の境界線だけではなく、内側にも境界線がある場合があると初めて知った。これも収穫である。
そんな訳で、マクロにこの機能を追加することにした。1つの筆データに内側境界が2つ以上存在する場合もあり得るだろう。見たら、エラーとして検出した筆データにも、内側境界が2つあった。これも意識して機能追加しなければならない。そういえばイタリアの中にもサンマリノ共和国だけでなく、ヴァティカン市国もあるなあ。

機能追加作業をしていたら、Ｇ空間情報センターへの問い合わせにメールで回答が来た。前の記事に書いた、某字の電子データに 89番地の3がなく、88番地の次が90番地の1となっている件である。
> FAQにてご紹介しておりますが、登記所備付地図データは
> すべてのデータが地図に展開可能な公共座標が付与されているとは限りません。
> 公共座標が付与されていない任意座標については、シェープファイルは
> GeoJSONには変換しておりませんので、欠落するような場合もございます。

26.9.08(火)
内側にも境界線がある筆データに対応できるよう、マクロに機能追加する作業を前日から始め、思ったより手こずったが、何とかできた。

ところで、登記所備付地図の GeoJSON 形式電子データでは、筆データのジオメトリ型に上記のような Polygon を使っているが、まさか MultiPolygon はないよね？ つまり、一つの筆に飛び地があって、外側境界線が複数というようなことだが、そんな筆はないだろなあ。市町村や県の境界線なら、飛び地のため複数の外側境界線があるだろうが、筆でそれはないよな。もしあったら、またマクロに機能追加・・ いや、手作業でエディットして、個々の Polygon に分割することで対応しよう。

地図上に筆を表示するためのデータを作るのが目的なので、それを実現できるなら手段は何でも構わない。GeoJSON の構文規則上、内側境界線への対応はマクロに機能追加せざるを得なかったが、万が一 MultiPolygon があっても手作業での分割で十分だろう。こういう作業では、いつの間にか手段が目的化してしまう。しばしばそういう状態に陥るが、それは時間の無駄である。過ぎたるは及ばざるが如し。

筆データの並べ替え

26.9.06(日)
前の記事の最後に書いた、登記所備付地図の電子データに、某字 89番地の3がなく、88番地の次が90番地の1となっている件、某字の80番地～99番地を抽出・並べ替えて調べたのだが、まだ腑に落ちない。そこで、その某字の376筆すべての番地をグーグルマイマップに表示してみることにした。やはり大字名，地番順に並べ替えないと、後でマップで見ても調べにくいだろう。

並べ替え用に作ったテキストエディタ（秀丸）のマクロでは、クリップボードを利用しているため、並べ替え中に他のアプリでコピペをすると、並べ替えが誤動作してしまう。このため、並べ替え中に他のアプリでの閲覧や検索はかまわないが、コピペはできない。とは言ってもうっかりコピーしてしまいそうだから、並べ替え中はトイレに行ったり、フリーセルゲームをしたりしてきた。
80番地～99番地の46筆を並べ替えた時は、先頭データから最終データまでを 31周、入れ替え回数 261回で、8分ほどかかったので、376筆もあると数時間はかかるだろう。その間、他のアプリの利用が制限されるのでは時間の無駄。いま風に言うと、タイパが悪い。

テキストエディタのマクロだから時間がかかるのだろう。MSVC とかでプログラミングしたら並べ替えは速いだろうが、MSVC は試したことがないので、ある程度習得して動かせるようになるまで時間がかかる。動作が遅くても、実績のあるマクロでやるほうが早く終わるだろう。夜中寝ている間にやることにした。

夜 20時頃、ビールを飲み始めた頃に並べ替え開始。22時半頃、歯を磨いた後に見たらまだ並べ替えを続けていて、パソコンの ACアダプタを触ったらけっこう熱くなっていた。やはりこういう繰り返し作業では電力消費が多いんだな。エラーが起きないことを願いながら就寝。

26.9.07(月)
朝 5時半頃に起きたら、エラーはなく、並べ替えは正常終了していた。やれやれ。何時頃終わったかはわからないが、先頭データから最終データまで 323周、入れ替え回数 23,169回との表示。46筆の入れ替え261回に8分かかった時の、約88.8倍の入れ替え回数なので、単純計算で ×8分とすると 約710分=11時間50分となるが、そんなに長くは寝ていない。もっと早く終わっていたに違いない。終了時刻も表示するようにしておけばよかったな。いずれにせよ、こういう処理は起きている時間にはやってられない。やってる間はパソコンの利用に制限が生じる。夜中寝ている間にパソコンにやらせておくしかない。

世に数多とあるアプリのシステム管理者は、はるかに複雑なシステムで、事前のスケジュール調整や事前調査をしてから、メンテナンスやアップデートをしているんだろうな。ご苦労さまです。

母の山林遺産を地図に表示

7年前に父が亡くなった後、母は山林を何筆か相続し、その固定資産税を毎年払ってきた。7月に母が亡くなり、その山林を私の兄弟でどうするか相談しなければならないが、固定資産税の明細書に書かれた地番を見ても、どこにその山林があるかわからない。

26.8.26(水)
茨城の営林署に勤務している弟と LINE で相談したら、法務省が登記所備付地図の電子データを公開していて、Ｇ空間情報センターの検索サイトで検索して、ダウンロードできるという情報を得た。検索したところ、ありました。ありました。山林のある村のデータ、登記所備付地図。
注意書を見たら「XMLデータのダウンロードにはユーザー登録が必要」「シェープファイル、GeoJSONファイルのダウンロードにはユーザー登録は不要」との記載あった。GeoJSONファイルなら、街道歩きに持ち歩く白黒地図作成の際、何度も扱ったことがある。これを利用して、山林の位置を地図に表示できそうだ。ユーザー登録不要で、しかも無料。さっそくダウンロード。

26.8.27(木)
ダウンロードした登記所備付地図データを、テキストエディタで開いた。面積の小さい村なのだが、地番のデータは1万件以上あった。地番1件は1筆と数えるから「1万筆以上」と書くのが正しいかな。
今年、母に送られてきた固定資産税の明細に書かれた山林は30筆。1万筆以上のデータから、大字名と地番でサーチして30筆を手作業でコピー、街道歩き用の白黒地図にペーストして、自宅PCローカルで表示させることに成功した。ネットで公開する必要はないから、上記サイトの白黒地図にはもちろん載せてない。

GeoJSON 形式のまま白黒地図に移植・表示できたので、次にこれをグーグルマイマップ用に移植することにした。今までの街道歩きの際は、まずグーグルマイマップで予定ルートを作成し、それを白黒地図に移植していた。歩いた後のブログ記事に載せる地図はグーグルマイマップだから、グーグルマイマップ用の KML 形式から、マップボックス用の GeoJSON 形式に変換・移植することはあっても、その逆の変換はしたことがなかった。今回はまさに、この逆パターン。

テキストエディタ（秀丸）で簡単なマクロを作り、グーグルマイマップ用に変換・移植し、表示できた。兄弟で情報共有するため、このマイマップは公開する必要がある。誰からでも閲覧できるので、当然、個人データは載せていない。

グーグルマイマップでは閲覧できる範囲を、特定の人物に限定する設定はできるのかな？ できれば兄弟に限定したいが、立木売却でもなければ二束三文どころか、毎年固定資産税を徴収されるだけの山林である。これを狙ってくるような輩はいないだろう。

26.8.28(金)
母の山林遺産はグーグルマイマップに表示できたが、私が父から相続していた分も表示したい。母の分30筆は、登記所備付地図データから手作業で探してコピペしたが、私の分はそれより多い。たくさんあると、手作業では間違える可能性大である。大字名や地番で探すのだが、これを間違えたり、うっかり前後の筆データをコピペするかもしれない。
そんな訳で、登記所備付地図データから自分の筆データを、大字名と地番をキーに自動で抽出する方法を考えた。ブログに載せる地図を作成する際は、テキストエディタ（秀丸）のマクロを使ってきたから、今回も、いままで慣れたこの方法でやることにした。
抽出後は、GeoJSON 形式からグーグルマイマップ用の KML 形式に変換する必要があるので、この変換をするマクロも作成。グーグルマイマップで表示できた。

26.8.29(土)～
表示した地図を見たら、大字名，地番順になっていない。元の電子データ（登記所備付地図データ）が大字名、地番順になっていなかったからだが、やはり大字名，地番順にしたいな。また、固定資産税の明細に書かれた情報も、いくつか表示したい。このため、大字名と地番で抽出するマクロに、この明細情報を付加する機能を追加し、抽出後に大字名と地番で並べ替えるマクロも作成することにした。
この作業にはけっこう時間がかかり、ひととおりできるようになるまで 5日ほどかかった。こういう作業をすると、いつの間にか手段が目的化することにしばしば陥ってしまう。余計な空白行が入ってしまうのが気になって、マクロを修正するとか。目的は地図への表示だから、それができればいいのにね。時間の無駄だが、気になり始めると止められない。

26.9.03(木)
電子データ（登記所備付地図データ）から抽出した私の筆データは、固定資産税の明細より1筆少なかった。某字の89番地3がない。抽出前の電子データを調べたら、88番地の次が90番地の1 となっている。分筆などで89番地3は消滅？ いや、今年固定資産を払ったから、まだ消滅してないだろう。法務省の登記所備付地図の電子データに欠落があるのかな？Ｇ空間情報センターに問い合わせることはできるのかな？ 相手にされないかも。