OQ_Analysis は OSM にある建物データの品質解析を行うスクリプトで、PostGIS を組み込んだ PostgreSQL 上で動作します。
今回はジオメトリエラーの除去を行う作業のための準備としてある建物とその建物以外のオブジェクトが交差している部分を抽出するテスト行いました。なお、実験中に OQ_Analysis のリポジトリが更新され、機能が増えたみたいです。
実行した環境は VirtualBox 上の Ubuntu 19.04 でメモリは 2GB 割り当ててあります。
テストに使うためのデータは Geofabrik 社のダウンロードサービスから四国のデータをダウンロードしました。同サービスにある日本の中では最も小さいデータサイズになっていることが決め手です。
流れとしては - PBF を PostgreSQL にインポート - OQ_Analysis で交差地物の抽出 - PostGIS で交差をポイントまたはラインに変換 - ogr2ogr で結果を GeoJSON 化 みたいな感じです。
とりあえずできたのですが、課題は残っています。
続きを読むGitHub Gist の pkorac/leafletGeoJsonTileLayer.js に書かれています。
このまま使おうとしたら自分の環境ではいくつか問題があったのでカスタマイズしました。
Leaflet.js 1.4.0 で試しています。
大きな変更点は2つです。
タイルパスの取得方法を変更
Gist ではイベントのURLをevent.url で取得していますが、今回試した環境ではイベントから URL を直接取得できませんでした。
代わりに event.coords を使うとポイントオブジェクトとして XYZ タイル座標を取得できるため、この情報を使って GeoJSON タイルの URL にしています。
jQuery を使いたくない
JSON をダウンロードするために jQuery を使っていますが jQuery には使わない機能も多く搭載されていて 85kB あるため、13kB 程度にある axios を使っています。
とはいえ axio では Promise が使われているので IE なんかで使おうとすると Polyfill とかが必要になるのでアレ。
どっちにしろ Webpack とか Babel な環境で使う事が多いので Promise ならなんとかなるんですよね。
運用していたウェブサービスが別々のサービス上に点在していたのでさくらの VPS に集約することにしました。 とはいえ一番の動機は VPN サーバーをホストさせていた IDCF クラウドが個人向けサービスを終了させるということでした。集約したいサービスは次のようなものです。
新しくドメインを取得してさくらの VPS に紐付けます。今回取得したのは tk ドメインの atlasseed.tk というものです。
Tasking Manager も Softether も Docker で動かしてホスト環境はあまりいじらないことを目標にしています。契約した VPS はメモリ1GB、SSD 30GBのもので、1年間で約1万円です。ロリポップと ConoHa と IDCF クラウドで1年あたり1.3万円くらいしてたので若干安くなる計算です。
以下 VPS の設定メモが無限に続きます。
続きを読む2016年にも会場予定地の書き込み状況を調べましたが開催まで1年半くらいになったのでもう一度それぞの場所を見てみることにしました。
会場予定地の名称と住所は東京都オリンピック・パラリンピック準備局ウェブサイトから引用し、住所を東京大学空間情報科学研究センターが提供するCSVアドレスマッチングサービスによってジオコーディングした結果を OSM の地図で表示させています。以前は Getofabrik の Map Compare で Google Maps と並べて表示させていましたが、Google Maps のアレで残念なことになってしまっているので…。
引用した情報とOSM状況は2018年12月6日の状況です。状況のコメントは偏見で判定しています。
工事中の場所もありますが建物や土地利用の他に POI を充実させた方が良さそうなところもありました。
余裕のある場所では経路検索対応も考えておいた方がいいかもしれません。
まだ少し時間があるためマッピングパーティーの開催などによってより充実させることができると思います。
| 名称 | OSM状況 | コメント |
|---|---|---|
| 新国立競技場 | OSM | 会場工事で更新が必要、周辺に POI が欲しいかも |
| 東京体育館 | OSM | 周辺に POI が欲しいかも |
| 国立代々木競技場 | OSM | 良好、POIをさらに充実させる余地がある? |
| 日本武道館 | OSM | 良好 |
| 皇居外苑 | OSM | 良好 |
| 東京国際フォーラム | OSM | 良好 |
| 国技館 | OSM | 良好、河川沿いに POI を充実させる余地がある? |
| 有明アリーナ | OSM | 会場工事で更新が必要、POI の追加も |
| 有明体操競技場 | OSM | 会場工事で更新が必要、POI の追加も |
| 有明BMXコース | OSM | 会場工事で更新が必要、POI の追加も |
| 有明テニスの森 | OSM | 良好 |
| お台場海浜公園 | OSM | 良好 |
| 潮風公園 | OSM | 公園内の設備を 充実させる余地があるかも |
| 大井ホッケー競技場 | OSM | 良好 |
| 海の森クロスカントリーコース | OSM | 良好 |
| 海の森水上競技場 | OSM | 良好 |
| カヌー・スラローム会場 | OSM | 良好 |
| アーチェリー会場（夢の島公園） | OSM | 良好、POI を充実させる余地があるかも |
| オリンピックアクアティクスセンター | OSM | 良好、POI を充実させる余地があるかも |
| 東京辰巳国際水泳場 | OSM | 良好、POI を充実させる余地があるかも |
| 馬事公苑 | OSM | 周辺の建物・POI が不足 |
| 武蔵野の森総合スポーツ施設 | OSM | 会場工事で更新が必要、建物・POI が不足 |
| 東京スタジアム | OSM | 建物・POI が不足 |
| さいたまスーパーアリーナ | OSM | 周辺に POI を充実させる余地あり |
| 陸上自衛隊朝霞訓練場 | OSM | 建物・POI が不足 |
| 幕張メッセ | OSM | 良好、POI を充実させる余地があるかも |
| 埼玉スタジアム2002 | OSM | 土地利用や POI が不足 |
| 横浜国際総合競技場 | OSM | 良好、POI を充実させる余地があるかも |
| 東京ビッグサイト | OSM | 良好 |
以前更新してから時間が経っているので更新してみましたが、develop ブランチを取ってきていたせいもあって動かなくなってしまいました。
Release に置いてあるバージョンを遡っていって 3.0.1 だったらすぐに動いたので develop ブランチの HEAD から 3.0.1 に戻しました。
まずは動いているサービスを停止させます。
$ sudo systemctl stop tm3.service $ sudo systemctl stop nginx.service
例によってドメインごとに異なる設定の書かれたファイルのパッチを用意しておきます。
$ cd ~/tasking-manager $ git diff server/config.py > ~/config.patch
動かないですがとりあえず develop ブランチのやつを待避させておきます。
$ cd ~ $ mv tasking-manager tasking-manager.dev
動いたバージョンを落として同じパスになるように移動させます。
$ mkdir ~/src && cd $_ $ wget https://github.com/hotosm/tasking-manager/archive/v3.0.1.tar.gz $ tar xf v3.0.1.tar.gz $ cd ~ $ mv ~/src/tasking-manager-3.0.1 tasking-manager
設定の書き戻しをします。
$ cd ~/tasking-manager $ patch server/config.py ~/config.patch
gunicorn などが入ってくる venv を設定します。 サービスは systemctl で起動させるのですぐに deactive しました。
$ python3.6 -m venv ./venv $ source ./venv/bin/activate $ python3.6 -m pip install -r requirements.txt $ deactive
クライアントをビルドします。
cd client/ npm install gulp build
package.json の内容だと npm から脆弱性を指摘されるので気がかりですが…。
あと2回くらい gulp build を忘れて 404 返されたことがありました(汗
最後にサービスを再開させます。
$ cd ~ $ sudo systemctl start tm3.service $ sudo systemctl start nginx.service
開発者でもないので GitHub リポジトリから取ってこられる develop ブランチではなく、Release から zip なり tar 玉を取ってきた方が安心かもしれません。
いやウチの環境だと v3.0.5 も動かなかったり、 3.0.1 にしたら npm install で脆弱性指摘されたりするわけですが…。
動かない理由探してフィードバックできればいいんですが、なかなかアレです。
この記事は OpenStreetMap Advent Calendar 2018 の1日目の記事です｡
Windows10 + IE 11 で HackMD の内容が表示されなかったのではてなブログに移動しました｡
自分でマッピングしている地域と主なマッピング方法を紹介しようと思います。
3地域ありますが(「主な」とは)どの地域も基本的にアームチェアマッピングです。
実家があり、osm を始めた最初の頃から断続的にマッピングしている地域です。
日本で Yahoo/ALPS データのインポートが始まる頃に最初の集中マッピングをしていて、Yahoo/ALPS データのノードの多さや接続の形状が主観的によくないと判断し、町の外周部から内側に向かって Bing から道路のトレースを行っていました。
次に集中的にマッピングを始めたのが基盤地図情報のトレースが出来るようになった頃で、千葉県に接する東側から建物を書き始めました。
埼玉県さいたま市浦和区や川越市のトレースと平行して現在もボチボチ思い出したように建物を書いています。
その後、2015年頃にアジアにマッパーらによる日本の道路データクリーンナッププロジェクトに連動して道路など地物のクリーンナップを行いました。
当初の道路トレースの後に地震による岩盤のスライドがあり、地物の地球上の位置が相対的にずれていたり、道路の建設などを反映する更新を行いました。
杉戸町では杉戸町・富岡町・川内村地域間共助推進協議会を中心に東日本の震災の教訓を元にした協働型災害訓練という催しを行っていて、避難所の運営などの災害対応シミュレーションを行っています。その中でOSMを使ったアームチェアマッピングのワークショップも行われ、広い地域で建物が追加されています。
建物については西側1/3が割と残っていて、しかもそこは街の中心地と新興住宅地があるため全体として概ね半分程度のカバー率と推測しています。
ソースは道路が Bing と基盤地図情報、建物は基盤地図情報をトレースしています。
現在住んでいる地域です。
この地域には hatochan というベテランマッパーがおり、道路の多くは hatochan が自転車で廻ってマッピングしていて、高いカバー率になっています。
ある日 hatochan が市街地から建物をトレースしている事に気づき、触発されてトレースをするようになりました。もっとも、あまりにマッピング地域に近いからスタートしたので、反対側から始めればよかったかなと思ってるところです。
中心地の建物を概ね書き終えた後、市域の南東側を中心に建物を書き始めました。現在は建物が南東から北西側にかけて多くマッピングされていて、北東や南側が手薄です。今後北西側から時計回りに建物をトレースしていくつもりでいます。
手前 Tasking Manager でタスクを用意して進捗を眺めていますが、まだ先は長そうです。
観光地という側面も持つ川越市なので観光資源の周辺は積極的に POI の追加もしていきたいところです｡
建物をトレースする際のソースは基盤地図情報を背景にしてトレースをしています｡
現在最も注力している地域です。
オープンデータになった航空写真のトレース許可を申請いただき許可されたことで、高精細な画像からマッピングできます。
タイル化された航空写真を元にまずは道路の形状変更と追加を中心地に行っているところです。航空写真が高精細なあまり、油断すると様々なものをトレースしてしまうため、トレースする地物を絞ってマッピングする方針にしています。
こちらも手前 Tasking Manager でタスクを用意して進めています。航空写真の鮮度もあるため早めに終わらせたいのですが、ランチタイムに少しずつ進める程度になっています。
基盤地図情報はインポートしてはいけませんが、トレースすることができます。
データをダウンロードしただけでは JOSM などで読み込めないため、次のような手順でトレース元画像にしています。
何気に 2. の段階で JOSM のオープンデータツールを使って読み込めますが、うっかりアップロードしてしまうのが怖くて WMS にしています。
Let's Encrypt で HTTPS 化した Tasking Manager 3 の証明書更新が成功しませんでした｡
動かなかったらどうしよ(
とか書いてたらその通りですよ…｡
VPS に接続して手動で更新を試みました｡
$ sudo ~/src/certbot/certbot-auto renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/%ドメイン%.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certs are not due for renewal yet: /etc/letsencrypt/live/%ドメイン%/fullchain.pem expires on 2018-XX-XX (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
どうやら証明書自体は cron で更新されたっぽいです｡
良く見ると表示された fullchain.pem のフルパス名と /etc/nginx/sites-available/tm3 に記録した各種 pem のパスが異なっています｡
一覧を見てみます｡
$ sudo ls /etc/letsencrypt/live/%ドメイン%/ -lo total 4 lrwxrwxrwx 1 root 36 Sep 14 03:00 cert.pem -> ../../archive/%ドメイン%/cert2.pem lrwxrwxrwx 1 root 37 Sep 14 03:00 chain.pem -> ../../archive/%ドメイン%/chain2.pem lrwxrwxrwx 1 root 41 Sep 14 03:00 fullchain.pem -> ../../archive/%ドメイン%/fullchain2.pem lrwxrwxrwx 1 root 39 Sep 14 03:00 privkey.pem -> ../../archive/ドメイン/privkey2.pem -rw-r--r-- 1 root 682 Jul 12 14:49 README
どうやら /etc/letsencrypt/archive/%ドメイン%/ にあった各種ファイル名の最後にある数値がインクリメントされていて､ /live/%ドメイン%/ の各種ファイルは archive/%ドメイン%/ の新しいファイルにシンボリックリンクが貼られているようです｡
ということで新しいファイルを nginx に認識してもらうために設定ファイルを書き換えます｡
$ sudo vi /etc/nginx/sites-available/tm3 - ssl_certificate /etc/letsencrypt/archive/%ドメイン%/fullchain1.pem; - ssl_certificate_key /etc/letsencrypt/archive/%ドメイン%/privkey1.pem; - ssl_trusted_certificate /etc/letsencrypt/archive/%ドメイン%/fullchain1.pem; + ssl_certificate /etc/letsencrypt/live/%ドメイン%/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/%ドメイン%/privkey.pem; + ssl_trusted_certificate /etc/letsencrypt/live/%ドメイン%/fullchain.pem;
最後に nginx を呼び出し直してあげます｡
$ sudo systemctl reload nginx.service
これで再び HTTPS 接続できるようになりました｡