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地図を国土地理院地図に切り替えていた。 一度表示した国土地理院のタイル地図画像ファイルは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画素の比較で塗りつぶしは常に右上にしているのがギザギザの原因であろう。 ４画素中、等高線が一番近くを通る画素を塗りつぶすように変えれば、ギザギザは いくらか目立たなくなるかもしれない。

… Переглянути весь допис

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

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

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

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

2025年4月28日 日本全体

建物 24935321 / 全地物 42683658 ＝ 58.4％

2025年3月6日 日本全体

建物 24505846 / 全地物 42050435 ＝ 58.3％

2025年2月2日 日本全体

建物 24211623 / 全地物 41646203 ＝ 58.1％

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