SIMA をシェープファイルに変換する Python スクリプトを書いた

測量データ共通フォーマット SIMA の通称 JPGIS 版をシェープファイルに変換できるスクリプトを書きました。

jsima2shp.py

使い方

git で取ってきて python スクリプトを走らせれば変換できますが、シェープファイルを書き込むために別のリポジトリを参照しているので、git submodule init して git submodule update しないとダメかもしれないです。

このフォーマット変換では平面直角座標系を緯度経度に変換しません。

能書き

GeoJSON の RFCで座標参照系を指定する項目が削除され、 座標は緯度経度を使って WGS 84 で表現することになったため、Proj などを利用して緯度経度に変換して GeoJSON 化するスクリプトを書いたりしましたが、平面直角座標系を緯度経度に変換する際に精度の劣化が起こるため、劣化の少ないフォーマット変換を行うために書きました。

とはいえシェープファイルで保存しても少しですが精度の劣化が起こります。

今回は初めて Python で書いてみました。今まで Hallo World くらいしか書いたこと無かったんですけどね。

パースして地物を作って登録する流れは一緒なので QGIS プラグインとかに応用できたらいいなと思っています。

SIMA をシェープファイルに変換する Python スクリプトを書いた

測量データ共通フォーマット SIMA の通称 JPGIS 版をシェープファイルに変換できるスクリプトを書きました。

jsima2shp.py

使い方

git で取ってきて python スクリプトを走らせれば変換できますが、シェープファイルを書き込むために別のリポジトリを参照しているので、git submodule init して git submodule update しないとダメかもしれないです。

このフォーマット変換では平面直角座標系を緯度経度に変換しません。

能書き

GeoJSON の RFCで座標参照系を指定する項目が削除され、 座標は緯度経度を使って WGS 84 で表現することになったため、Proj などを利用して緯度経度に変換して GeoJSON 化するスクリプトを書いたりしましたが、平面直角座標系を緯度経度に変換する際に精度の劣化が起こるため、劣化の少ないフォーマット変換を行うために書きました。

とはいえシェープファイルで保存しても少しですが精度の劣化が起こります。

今回は初めて Python で書いてみました。今まで Hallo World くらいしか書いたこと無かったんですけどね。

パースして地物を作って登録する流れは一緒なので QGIS プラグインとかに応用できたらいいなと思っています。

OQ_Analysis で建物の品質チェックを行うテスト

OQ_AnalysisOSM にある建物データの品質解析を行うスクリプトで、PostGIS を組み込んだ PostgreSQL 上で動作します。

今回はジオメトリエラーの除去を行う作業のための準備としてある建物とその建物以外のオブジェクトが交差している部分を抽出するテスト行いました。なお、実験中に OQ_Analysis のリポジトリが更新され、機能が増えたみたいです。

実行した環境は VirtualBox 上の Ubuntu 19.04 でメモリは 2GB 割り当ててあります。

テストに使うためのデータは Geofabrik 社のダウンロードサービスから四国のデータをダウンロードしました。同サービスにある日本の中では最も小さいデータサイズになっていることが決め手です。

流れとしては - PBF を PostgreSQL にインポート - OQ_Analysis で交差地物の抽出 - PostGIS で交差をポイントまたはラインに変換 - ogr2ogr で結果を GeoJSON 化 みたいな感じです。

とりあえずできたのですが、課題は残っています。

続きを読む

Leaflet で 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 にウェブサービスを集約する

運用していたウェブサービスが別々のサービス上に点在していたのでさくらの VPS に集約することにしました。 とはいえ一番の動機は VPN サーバーをホストさせていた IDCF クラウドが個人向けサービスを終了させるということでした。集約したいサービスは次のようなものです。

新しくドメインを取得してさくらの VPS に紐付けます。今回取得したのは tk ドメインatlasseed.tk というものです。

Tasking Manager も Softether も Docker で動かしてホスト環境はあまりいじらないことを目標にしています。契約した VPS はメモリ1GB、SSD 30GBのもので、1年間で約1万円です。ロリポップと ConoHa と IDCF クラウドで1年あたり1.3万円くらいしてたので若干安くなる計算です。

以下 VPS の設定メモが無限に続きます。

続きを読む

2020年東京オリンピックの会場予定地の OSM 書き込み状況をざっくり調べた Part2

2016年にも会場予定地の書き込み状況を調べましたが開催まで1年半くらいになったのでもう一度それぞの場所を見てみることにしました。

会場予定地の名称と住所は東京都オリンピック・パラリンピック準備局ウェブサイトから引用し、住所を東京大学空間情報科学研究センターが提供するCSVアドレスマッチングサービスによってジオコーディングした結果を OSM の地図で表示させています。以前は Getofabrik の Map CompareGoogle 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 良好

Tasking Manager 3を更新したら動かなくなったので復旧させた話

以前更新してから時間が経っているので更新してみましたが、develop ブランチを取ってきていたせいもあって動かなくなってしまいました。

Release に置いてあるバージョンを遡っていって 3.0.1 だったらすぐに動いたので develop ブランチの HEAD から 3.0.1 に戻しました。

サービスの停止

まずは動いているサービスを停止させます。

$ sudo systemctl stop tm3.service
$ sudo systemctl stop nginx.service

configのパッチ作成

例によってドメインごとに異なる設定の書かれたファイルのパッチを用意しておきます。

$ cd ~/tasking-manager
$ git diff server/config.py > ~/config.patch

動かないですがとりあえず develop ブランチのやつを待避させておきます。

$ cd ~
$ mv tasking-manager tasking-manager.dev

v3.0.1のダウンロード

動いたバージョンを落として同じパスになるように移動させます。

$ 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 

python venv の作成

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

やっぱり Release を追いかけるのがいいのかな…

開発者でもないので GitHub リポジトリから取ってこられる develop ブランチではなく、Release から zip なり tar 玉を取ってきた方が安心かもしれません。
いやウチの環境だと v3.0.5 も動かなかったり、 3.0.1 にしたら npm install脆弱性指摘されたりするわけですが…。

動かない理由探してフィードバックできればいいんですが、なかなかアレです。