Geofabrik OSM Inspector

何年か前には、広域森林などがよく壊されていた。 エラーチェックにOSM Inspector をよく使った。 近年は OSM Inspector を使っていない。機能が豊富なので、使いこなすのは簡単ではない。

左上の選択は 「Areas」とする。目下、横浜市泉区をマッピングしているので、そのあたりを 表示してみた。

かなり多くのエラーがある。OSM Inspector でエラーを見つけ、relation とか way などの osm_id を JOSM に入れて、エラーオブジェクトを表示する。

二つのポリゴンで描かれた公園の接合部にエラーがあった。合体させて、一つのポリゴンにした。

boundary=administrativeの一部が欠けていた。このエラーは多くある。 とりあえず、簡単な２件のエラーを修正した。

農地をouter polygonとするマルチポリゴンのエラーも修正した。

OSM Inspector にエラー修正が反映されるのは確か数日後であったと記憶する。

今回、４つのエラーを修正したが、まだ多くのエラーが残っている。 境界線エラーが多いと思われる。

誤って消されたとは限らず、分かる範囲で境界線を描き、不明分が描き残されているのかもしれない。境界線が交差のない閉ループにならなければ、エラーとなる。

道路や河川の県境などは現地確認できるが、詳細な境界線の確認には手がかかる。 残りのエラーのいくつかは後日修正するが、修正できないものもあるだろう。

行政境界線を強調表示する[2024.11.15]

日本地図全体では無数のエラーがある。横浜市泉区では、特に、行政境界線のエラーが多かった。いくつかは修正したが、簡単には修正できないものもある。

エラーが多い場合、国土数値情報を使うことも考えたが、 日本地図全体としては行政境界線エラーは比較的小さい。 OSMデータを使う方が簡単である。

二重境界線の描き方[11月20日]

ポリゴンの境界線の少し内側(長さd)の閉曲線を求める方法として、現在は、 境界線の内側に平行な隣合う線分の交点をつなぎ合わせている。

凸多角形についてはこれでよい。しかし、隣り合う線分の角度が180度を超える と不都合が起きる。360度に近くなると、交点は元の交点とは遠く離れたところにうまれる。 元の交点との距離が長さd を超えるときは、 線分を二つ追加して、この追加線分の交点と元の交点との距離を長さd とすべきであろう。

もう少し簡単に境界線の少し(長さd)内側に、閉曲線を求める方法はないものだろうか。

はじめに

日記機能を使い始めてまもなく３か月、数回書いてみて、使い方がかなり分かってきた。

山歩きでは、しばしば、等高線がほしくなる。 これまではOSM地図を国土地理院地図に切り替えていた。 一度表示した国土地理院のタイル地図画像ファイルはSDカードに保存しているが、 全zoomが保存されているわけではなく、山歩きではスマホの電波も届かないことが多く、 実時間でのダウンロードができず、使い勝手が悪い。

国土地理院の標高タイルについても、事情は同じであるが、 ５ｍメッシュDEMの zoom 15 にあたるため、必要範囲を予めダウンロードしておくこと は容易である。

そこで dem5a を使って、OSM地図に等高線を付け加えることを考えた。

QGISなどを使って、オフラインで等高線を求める記事[3]は他にもあるが、 自分が欲しいのは、自作OSM地図アプリに組み込むプログラムである。 これに関するものは少なかった。

最初に試した簡易プログラム[5]

    void getContour(Bitmap bmp) {
        for (int j = 0; j < 255; j++) {
            for (int i = 0; i < 255; i++) {
                float c = ele[j][i];        // check pixel
                float r = ele[j][i+1];      // right pixel
                float d = ele[j+1][i];      // down
                float g = ele[j+1][i+1];    // diagonal
                int ic = (int)(c/20);
                int ir = (int)(r/20);
                int id = (int)(d/20);
                int ig = (int)(g/20);
                boolean flag = (ic != ir) || (ic != id) || (ic != ig);
                bmp.setPixel(j, i, flag ? 0xffff0000 : 0x00000000);
            }
        }
    }

東京の高尾山の山頂を含む zoom 15 のタイルの等高線を描いた結果を下に示す。 その下に、国土地理院の標準地図タイルを載せた。

プログラムは非常に簡単であるが、ギザギザが目立つ。線の太さは１画素であり、 これより細く見える線は簡単に描けない。

4画素の比較で塗りつぶしは常に右上にしているのがギザギザの原因であろう。 ４画素中、等高線が一番近くを通る画素を塗りつぶすように変えれば、ギザギザは いくらか目立たなくなるかもしれない。

しかし、zoom 16以上をどうするか、簡単な方法を思いつかない。

CONREC A Contouring Subroutine[7]

これは、40年近く前に発表された古い技術である。デジタル地図用ではなく、 CAD(ワイヤーフレームモデル)用かもしれない。

元々はC、Basic、Fortran言語プログラムであったが、その後、多くの人が 色んな言語に移植しているので、実用性は高いと推察される。

文献[7]にアルゴリズムが述べられているが、自分はまだ十分には理解していない。

Java言語に移植したプログラムを Android OS上の自作OSM地図アプリに 組み込んだ。Android Javaと本家Javaでは特にUI回りで互換性がないが、 等高線を求めるアルゴリズムの部分については、何も修正する必要はなかった。

zoom 15

５ｍメッシュの標高タイルDEM5aは zoom 15 の256x256画素の中心点(多分)の 標高を表すものである。座標で言えば、0.5 から 255.5 までとなる。 下の図をよくよく見れば、タイル境界で等高線の途切れがある。 これはあるタイルの最終座標 255.5 と次のタイルの 0.5 の間に１画素分の間隙がある ためである。いずれ、両隣の標高タイルの値を使って、このタイル境界での途切れをなくしたい。

タイル境界での途切れをなくした[2024.10.6]

zoom 15で言えば、座標値 0.5 から 255.5 ではなく、前と後ろに１点を加えて、 座標値を -0.5 から 256.5 とした。

標高タイルはキャッシュするように変えた。 スマホの場合、１画面に最大３ｘ４タイルが表示される。周辺の標高タイルを使うために、 画面全体としては、最大で５ｘ６標高タイルの標高値を使って等高線を算出する。

ファイル読み込み時間は増えるが、等高線算出処理は 256x256配列が 258x258配列に変わるだけで、処理時間の増加は僅かである。

zoom 16以上

zoom 16の場合には、zoom 15の DEM5a を縦横２分割して、 128x128地点の標高データを使って等高線を描くことになる。

zoom 17の場合、DEM5aを縦横４分割して、64x64地点の標高データを使う。

zoom が大きくなるほど、使うデータが少なるため、誤差は大きくなるであろう。 下に、zoom 17、zoom 19 の例を載せた。等高線は乱れはない。

二つの図ではタイル境界での等高線のとぎれもない。 実は、zoom 17の場合、64x64個のデータで等高線を描いているのではなく、 66x66個のデータで等高線を描いている。 zoom 15で言えば、座標値 0.5 から 255.5 ではなく、前と後ろに１点を加えて、 座標値を -0.5 から 256.5 としている。 -0.5～0 および 256.0～256.5 の部分はタイルからはみ出すが、描画されないだけであり、 エラーが起きるわけではない。

zoom 17で言えば、 -1～64、63～128、127～192、191～256 とする。 -１は前の標高タイル、256は次の標高タイルとなる。中間のオーバラップは 同じ標高タイルからのデータ取り出しのため、サポートが簡単である。 したがって、ここでは等高線の途切れが起こらないようにしている。

zoom 17

zoom 19

山頂の標高

等高線とは関係ないが、DEM5a とOSMの natural=peak の ele と 比較するのは簡単である。 1ｍ以内の誤差はいいとして、ほんの少し調べただけでも、5ｍ前後の誤差が散見された。何故だろう。 著名な山では誤差が少ないが、無数の無名の山頂には誤差が含まれているのかもしれない。ただ、一般の人にとっては、数ｍの誤差は問題ではない。

今後の予定

前後の標高タイルに含まれる標高値も使い、タイル境界での等高線とぎれをなくする。 (10月7日に完了)

100ｍ、200ｍといった太い等高線には数値を書き込む(10月8日に完了)。

数値(label)は下図のような書き方は簡単、これでいいであろう。タイル毎、数値毎に、 １回だけ書き込んでいる。

リファレンス

[1] 基盤地図情報1m・5mメッシュDEM　標高データ（数値PNGタイル）
[2] 標高タイルの詳細仕様
[3] 【実習編】非専門家のためのQGIS ～DEMから等高線を描く～
[4] 等高線表示機能（試験公開）
[5] Leaflet で地理院標高タイルから等高線を描いてみる
[6] 地図情報の新たな整備・更新技術の開発－5m メッシュ DEM から地図情報レベル 25000 の等高線を作成する手法の検討（第 1 年次）－
[7] CONREC A Contouring Subroutine
[8] Conrec.java

・この日記機能を使ってみて２か月半。公開の価値はともかく、自分の記録としては便利である。特に、後から編集できるのがありがたい。

・ゆかりの地(地方)を２か所チェックした。 登録時に正しかったが、今は変わっている情報が目に付く。 OSMの利用サイトでは、登録日を表示しているものがあった。 OSMを使うにはそういう配慮がいるかもしれない。 ポイント情報でいいので、もっと多くの人がこまめに登録、修正してくれる日が来ることを 期待している。

・地方でも、交通量が比較的多い幹線道路脇については、コンビニやガソリンスタンド、 人気の飲食店などはそこそこにマッピングされている。 しかし、今も正しい情報かどうかはチェックしていない。 また、Google Mapに比べれば桁違いに登録が少ない。

・医院などは都会でもGoogle Mapに登録されていないことは珍しくない。 自宅近くでは、歯医者はすぐにGoogle Mapに現れる。 これは歯医者は競争が激しく、自らが登録しているのであろう。 一般の医院はホームページを持つていることは多く、検索では現れるが、 当事者がGoogle Mapに登録することは少ないようである。 Google Mapには、悪い口コミも載るので、登録のメリットがないのであろうか。

2025年1月19日 日本全体

建物 24106328 / 全地物 41482342 ＝ 58.1％

2024年11月30日 日本全体

建物 23819544 / 全地物 41026345 ＝ 58.1％

2024年11月28日

関東

建物 5081819 / 全地物 9092712 ＝ 55.9％

建物 5096929 / 全地物 9116307 ＝ 55.9％[12/07]

2024年11月13日

日本全体

・japan.osm の全40,746,043レコード中、建物レコードは 23,696,293 (58.2%)であった。 ・2か月半前ではjapan.osm の全39,982,313レコード中、建物レコードは 23.230,411 であったので、全体では1.9%、建物は2.0%の増加となる。

建物 23696293 / 全地物 40746043 ＝ 58.2％
procRelation high 160991relations
Relation 出力レコード数＝123635 最大Outer数=2211

関東

・kanto.osmでは全 9,030,910レコード中、建物レコードは 5,054,325(56%)であった。 ２か月半前では、全8,871,868レコード中、建物レコードは 4,966,970(56%)であったので、 全体では1.79%、建物は1.76%の増加となる。

建物 5054325 / 全地物 9030910 ＝ 56.0％
procRelation high 47016relations
Relation 出力レコード数＝27980 最大Outer数=173

2024年9月25日

関西

昨晩までのOSMデータ kansai.osm について

レコード数=6410779, 建物数=3960770(62％), 最大レコード長=77900, 平均レコード長=123.3, 平均タグ長=11.6B, 最大タグ長=650B

という結果を得た。 １か月弱で、総レコード数は 48,467(＋0.76％)、建物レコード数は 37,939(＋0.97％)増えた。 自分の寄与度が大きいが、その数値は求めていない。 人口１万数千人の田舎町をマッピングしたが、田舎では建物数は人口よりも大きい。 農地、住宅内道路なども多く追加した。

2024年8月29日

日本全体

・2024.8.29 時点では、japan.osm の全39,982,313レコード中、建物レコードは 23.230,411 (58%)であった。

関西

・kansai.osmでは全6,362,312レコード中、建物レコードは 3,922,831(62%)であった。

関東

・kanto.osmでは全8,871,868レコード中、建物レコードは 4,966,970(56%)であった。

・関東地方の建物マッピングが若干遅れているというわけではなく、 首都圏はマンションの比率が高いことが影響しているのであろう。 また、農村では住居以外の建物が多く、人口の割には建物の数が多いことも関係しているであろう。

・全レコード数は自作OSM地図でレンダリング対象とするものに限定した値である。

３年前には横浜市北部の青葉区、緑区、瀬谷区の建物を中心としたマッピングを行った。 今回は都筑区、旭区、港北区について行った。

・港北区は既に８、９割終わっており、 東急日吉駅近辺およびその北部など、取り残されていた地域について行った。

・都筑区は地下鉄駅周辺は終わっており、残りの７割程度を行った。

・旭区は駅周辺や相鉄本線以南はほぼ終わっており、残りの８割程度を行った。

・横浜市北部の前に、こどもの国の真北の三輪緑山の建物のマッピングを行った。 確か３年ほど前に誰か(ひょっとすると、自分自身？)が２、３割の建物のマッピングを行ったので、 先に進むことを期待していたが、その後、その気配がないため、残りのマッピングを行った。

2024.9.10

・ゆかりの地(富山県、兵庫県)を見た。５～８年前とあまり変わっていない。 正直なところ少しがっかりした。 日本全体では、OSMデータファイルのサイズは２倍以上に増えているだろう。 大都会のマッピングが進んだのだろう。

・人口１万数千人のゆかりの田舎町をマッピングしてみた。 時間がかかるのは、建物であるが、農地などのマッピングも行った。 住宅内道路はマッピングされていないものが多かった。 建物については近接して農業用小屋や駐車用小屋などがあると、 国土地理院地図では全体がひとつの大きな建物となっており、 オルト地図や Bingの航空地図でも精度が悪く、 ひと繋がりの建物か、分離した複数の建物か判然としないケースがよくある。 全体として都市部に比べると、人口１万人当たりのマッピング時間は、 ３～５倍かかるようだ。

長らく使っていないため、slackにログインできなかった。（その後、ログインできた。） 記録用としては、日記の方がいいかも知れないので、少し、使ってみよう。 自分が初めてOSMに触れたのは、2015年２，３月である。 ほんの少し、非常勤講師などをやっていたが、余裕がたっぷりできた頃である。 ハイキングには地図がいる。オフライン地図を探し、OSMに出会った。 Google Mapなどに比べると、はるかに内容が乏しいが、オフラインで使えること、 自由にカスタマイズできることが魅力でOSMを使うことにした。 1、2か月で自作OSM地図が完成して、散歩やハイキングの友となった。 １年間10インチWindowsタブレットに自作OSM地図を載せた。 10インチは大きすぎ、１年で８インチWindowsタブレットに変えた。 ３年ほど前から Androidスマホに変えた。 デバッグや自宅利用は ８インチAndroidタブレットを使っている。

この９年間でOSMの情報量は増え、精度も向上している。 旅行、ハイキング、散歩では OSMでさほど不自由は感じない。 観光地に限れば、Google Mapよりも詳細なことがよくある。

ただ、全国均質ではなく、地方にはマッパーがいないため、内容に極端なかたよりがある。

HTMLタグは使えるか？

HTMLタグも使えるようだ。カスタマイズしたOSM地図に国土地理院の標高タイルから 得た標高データを使って等高線を重ねてみた。

参考資料
CONREC A Contouring Subroutine