OpenStreetMap

MAPconcierge's Diary

Recent diary entries

私のコンピュータースキルまとめ

※ OpenStreetMapの日記機能で表現できる Markdown記法の動作確認用です。

はじめてPCに触れたのは

  • 小学生の頃

使用したパソコンの種類

  • MSX

  • X68000

  • PC-98

  • Windows

  • Mac

  • Unix/Linux

そこそこ使えるソフト(5個くらい)

  • MS-Office

  • Adobe Photoshop、Illustrator

  • ウェブブラウザー

  • keynote

  • Github Desktop

この記事は OpenStreetMap Advent Calendar 2016 (12/15用) として投稿しました。

はじめに

青山学院大学地球社会共生学部に赴任し、大学教育の中でOpenStreetMap(以下OSM)を活用し、その成果もまたOSMに還元することを目指し、多くの取り組みを行ってきました。せっかくの機会なので、今年1年間と、その前の年である2015年も振り返ってみます。

(現在、目下更新中です…)

ついでに2015年も振り返る

UN WCDRR @ Tohoku Univ.

淵野辺周辺マッピング

ネパール地震

HOT Summit @ UN Redcross HQ

State of the Map US @ UN HQ

相模原キャンパスインドアマッピング

State of the Map Asia

State of the Map Taiwan

相模原キャンパス3Dマッピング

日本のOSM品質向上プロジェクト

相模原キャンパスストリートビュー化

相模原キャンパス放射線量マッピング with Safecast

GeoGeoWEST 友引じゃナイト


そして2016年

淵野辺周辺マッピング

熊本地震

相模原キャンパスストリートビュー化

Missing Maps Project レクチャー@Google

State of the Map Japan

State of the Map Brussels

ICCM - International Conference of Crisis Mappers

State of the Map Asia in Manila

龍野マッピング

鳥取地震

wikidata

相模原キャンパス放射線量マッピング with Safecast

GeoGeoWEST 友引じゃナイト

OSMstatsから読み解くマッパーコミュニティの現状

Posted by MAPconcierge on 14 December 2016 in Japanese (日本語). Last updated on 16 December 2016.

この記事は OpenStreetMap Advent Calendar 2016 (12/15用) として投稿しました。

OSMstatsから読み解くマッパーコミュニティの現状

About OSMstats

OSMstats は世界中の OpenStreetMap ユーザーコミュニティ活動量が毎日どのように行われているのか、定量的な統計情報を整理して、見える化するサービスです。 運営は altogetherlost.com & Pascal Neis (neis-one.org) チームが行っています。

http://osmstats.neis-one.org/

何がわかるの?

様々な情報が可視化されていますが、主に次の情報が便利です。

  • OpenStreetMapユーザーアカウント総数の時間遷移
  • 日別のアクティブマッパー活動量
  • 国別のアクティブマッパー数

これらの情報を、それぞれ見てみましょう。

OpenStreetMapユーザーアカウント総数の時間遷移

### OSMstatsトップページを開く これは簡単です。OSMstatsのトップページを開くだけです。

Number of registered OSM members

左上の Number of registered OSM members の情報を見ます。2016/12/15 の時点では、3,285,076ユーザーアカウント、約330万マッパーによって今のOpenStreetMapはデータ更新されています。但し、この数字は現時点で有効なアカウント数であり、過去に作ったっきり使われていないアカウントや作業の目的によって複数アカウントを使い分けている人も含まれていますので、実際の人間としてマッパー数はこの数字よりも小さくなります。

グラフの時間軸を少縮尺にする

横軸を時間軸に、縦軸をユーザーアカウント数でプロットした二次元グラフを見てみましょう。また、2012年から現在までの遷移を見てみましょう。

ユーザー数の増加傾向に変化

このグラフをよく見ると、ユーザー数の増加傾向に何度か変化が起きていることが読み取れます。一つは、2012年6月前後からの増加(①)。二つ目は2013年4月前後からの増加(②)、そして最近も 2016年4月からの増加傾向(③)。さあ、ここからその背景を、、、と書きたいところですが、この問いは青山学院大学の古橋ゼミの課題に使うのであえてここでは問題提起のみに留めます。後日学生達の分析を追記公開します。

日別のアクティブマッパー活動量

上記のユーザー増加数の中身を判断するには、実際にマッピングを行っているユーザー数である No. of daily active members overall と比較することが大事です。これは日別のアクティブマッパー数のグラフで、例えば 2016年4月からの増加傾向は、ユーザー数が増えているだけでなく、連動してアクティブマッパー数も同じタイミングで増え始めています。

国別のアクティブマッパー数

最後に、国別のアクティブマッパー数を比較してみましょう。先程までは世界全体の傾向を追っていましたが、OSMstats上に並ぶ Countries タブリンクから表示を切り替えると、各国ごとの集計表が登場します。時差もあるので、2日くらい前に設定したほうが正しく表示されることが多いです。2016/12/14時点では日本は世界でTOP10のポジションにいます。

今度は、Japan をクリックして、日本のアクティビティ(実際には日本エリア内でのマッパーアクティビティであり、日本人だけでなく遠隔からのアームチェアマッピングも加算されています)を見てみましょう。

日本でも 2016年4月から、アクティブマッパー数が増えているように見えますが、これはグローバルなOpenStreetMapのマッパー数の増加傾向と関連性があるのでしょうか?それとも日本独自の現象でしょうか?いずれにしてもこのような定量的な数値を元に、世界と日本のマッパーコミュニティがどのように変化しているのか、マクロな視点でのコミュニティ分析も大事な見方です。

鳥取中部地震の発災後航空写真を用いたマッピング方法について

タスキングマネージャから、自分のタスクを選択してマッピング開始

2016-10-27 10 12 47

国土地理院のタイルURLをコピー

http://maps.gsi.go.jp/development/ichiran.html#20161021tottori_1022dol

2016-10-27 10 14 20

カスタムレイヤとしてURLを貼り付け

2016-10-27 10 15 21

これで、発災後の航空写真に切り替わります。

2016-10-27 10 16 26

フレッシャーズセミナーお題(2016/10/13)

#2232 - Hurricane Matthew: Ile de la Tortue

クライシスマッピングを経験した上で、依頼者の赤十字がなぜこのデータを必要としているのか各自が考えたことを提出してもらいました。 http://tasks.hotosm.org/project/2232

  • emika [10:19 AM]
    その地域にある建物のデータを取り、ハリケーン通過後のデータと照らし合わせて、ハリケーンの被害がどのようなものなのか、またハリケーンの移動の経緯を知ることができる。建物が密集していて、且つ、損害が激しいようならハリケーンの滞在時間が長く、ハリケーン事態の規模が大きいものだったと考えられる。そこで、それらのハリケーンのデータを詳細に知ることで、事前に対策を考えられる。例えば、ハリケーンの強弱の変化とその地域の状況に何らかの法則があるとすれば、それに対応した状況を避ける対策を考えることができる。

  • ycmj17vernon [10:20 AM]
    台風が通過した大まかな地域と照らし合わせて、そのなかでも住宅が少なく取り残されているとみられる地域へ足を運ぶために用いられるのかな?(ヘリなどを止めるための場所確認にも用いていたりして?)

  • kudo [10:24 AM]
    建物が密集しているかどうか、建物のある環境(森、川、海など)を知ることでどのようなルートで救助に行くべきか、優先順位、救助方法を考えることが可能になると考えられる。また、最新の航空写真と比較することができる

  • zaki [10:24 AM]
    人民救助などで住宅地など、人のいる場所を把握するため。また、避難場所となる建物の確保などに役立つ。土砂災害による建物の破壊?が起こりそうな地域の把握など。

  • shuta [10:24 AM]
    建物の場所を把握することによってその建物のある場所、つまりは人がいる可能性が高い場所に赤十字は迷わずに向かえるなどの行動が起こしやすいと思われる。

  • kents111 [10:25 AM]
    自然災害や人災が発生したときに、どこに人が住んでいるのか、またはその地域に住んでいる人がどこに避難するのかを考えることができるのではないか。そして、地形や周りの環境を見て救済を必要としている人々に対してどのような物資や支援を必要としているのか、また、どこからどのように運搬すればベストなのかを検討することができると思う。

  • akari [10:25 AM]
    赤十字は世界中様々な場所で活動しているため、いつどこで何が起きても現地で先のことを想定して動けるように建物などの情報が必要。今回の台風の場合は特に建物があった場所なのか、もともと何もない場所なのかの判断にも役立つと思われる。

  • shunsuke0107saru [10:25 AM]
    家の位置を大まかに確認し家が密集している地域だけでなく孤立している家にも安全確認などをするために足を運ぶためだと思った。また、家が壊れていたりしてどれくらいそこに家があったか知るためだと思った。

  • kotatamura [10:26 AM]
    建物に関する情報を手に入れることにより、既存の建物に被害が生じているのかが分かるほかに、どの地域にどの程度人が住んでいるのかなどの地域に住んでいる人に関するおおまかな情報が推測できるのではないかと思う。 その情報がわかることにより、実際現地に赴いたときにどのようなところに行きどのように行動をするかの計画が現地に行く前に立てられるようになり、現場でより効率のいい動きができて結果としてたくさんの現地の人の役に立つことになるのではないかと思う。

  • hisada [10:27 AM]
    台風の被害に遭う前の建物の情報を得ることで、その場所にはどれくらいの建物があるのか、またヘリの出動数や、どれぐらいの助けが必要かが把握でき、さらにどのようにしてその場所に向かうかが、分かるのではないかと思う。

  • takahito [10:27 AM]
    奥の集落などにマップがあるとは限らない。そのためこのようなネット上のマップを用いることでより多くの情報を得ることができる。それだけでなく現地にマップがあったとしても目印となる地形は変形してしまっているかもしれない。そのためこのようなデータを用いることで正確な座標データも獲得することができヘリなどでもすぐに行くことができる。

  • hiroki [10:27 AM]
    建物の密集している程度によってどれほどの人が取り残されているかを予測して、その程度によって救助に当たる人数や支援物資の量を適切に配分することができると思う。また、支援・救助に当たる人が安全に移動できるようにするため。

  • kodai [10:27 AM]
    住宅の数から避難すべき人のおおまかな人数を割り出して、避難できていない人がいないか確認するためだと思う。

  • miyu [10:28 AM]
    赤十字が建物データを必要とする理由は、建物の正確な位置をmapとして現場に行く前にデータとして知っておくことで実際に被災者救助にあたる際に、どの方面からのアクセスがより多くの人命救助が出来るかを把握できる。特に家が密集している地帯には被災者が多く取り残されて可能性が高い。またこのmapがあれば物資の運搬経路や避難場所の確認も、何も知らずに現場に直行して探すより事前に知っておくことで簡単になると思う。

  • akarikodama [10:28 AM]
    現在の状況を把握して、現時点での救助において最も安全な移動をするため。また、被害状況をおおまかに把握して救助がどの程度必要か知るため

  • shuta [10:29 AM]
    建物の位置情報がわかれば損壊したときにした後と前とで照らし合わせればすぐに確認できるため赤十字は優先度をつけて動けるのではないかと思われる。

  • misato [10:30 AM]
    Google map などのすでに完成している地図アプリを使わずにOSMに要請する理由として、ハイチの主要都市や発達地域の場所など、ハイチに対する前提知識を知らない一般人が編集することで、公平な地図が出来上がるからではないかと考えます。この地図は、人のいそうなところを推測するために使われると思います。

  • eguri89 [10:30 AM]
    リアルタイムの建設データを得ることで、被害の大きさ、住宅の有無の確認で人がどこにいるのか、森などの自然環境を見ることでどのような二次災害が起こるかなどの情報を知ることができる。また台風のもたらした被害がリアルタイムで把握することができる

Markdown記法 講座はじめました。

Posted by MAPconcierge on 19 May 2016 in Japanese (日本語). Last updated on 7 December 2017.

2016年度の古橋ゼミでMarkdown講座はじめました

## 基本ルール * Internet Explorer を使ったらアウト * マイクロソフトの Wordファイル(doc/docx)で提出したらアウト * 基本的な文書の提出は Markdown 記法でテキストファイルで提出する * Dropbox paper や Qiita、GitHub は特にMarkdown 対応がすばらしい * 特別な理由がない限り MSゴシック/MS P ゴシックのフォント使用はアウト * マイクロソフトは大好きですが、特に好きなのは PowerPoint と Bing maps です。

初級編

### 見出しの書き方 * #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。 * 例: # 見出し * source: # 見出し

箇条書きの書き方

  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切り箇条書き文字列を書く。
  • 例: * 項目1
  • source: * 項目1

中級編

### 太字(BOLD)の表現 * **(アスタリスク)2つで文字列を囲む。 * 例: 太字 * source: **太字**

斜体(イタリック)の表現

  • *(アスタリスク)1つで文字列を囲む。
  • 例: 斜体
  • source: *斜体*

リンク

  • [テキスト](URL) と半角で表記します。
  • 例: 古橋のGeoBadge実績
  • source: [古橋のGeoBadge実績](http://geobadges.org/#!/members/2217068)

画像の貼り方

  • ![代替テキスト](URL) と半角で表記します。
  • 例: CrisisMappers 1.0 バッジ
  • source: ![CrisisMappers 1.0 バッジ](https://credlyapp.s3.amazonaws.com/badges/e1a9e174d368e32b451c3f84387bde95_17.png)

上級編

### ソースコードの埋め込み方 * バッククォートを3つ前後に挟む。 例: ** ソースコード ** * チェックボックスを箇条書きの先頭につける。 例:- [x] 箇条書き ※但し、GitHub など一部のツールに限定される。

(この記事は FOSS4G Advent Calendar 2015 の投稿記事のバックアップです。原本は Qiita に投稿しました。)

遅ベントカレンダーということで、年が明けて三が日にこれを書いていますが、せっかくなので今年の豊富とTIPSをメモしたいと思います。

2016年は、SHPファイルからGeoJSONへの世代交代の年!

というわけで、今から10年前に世の中に登場したKMLデータ形式が地理空間情報の世界を塗り替えても、すべてをKMLに置き換えられない理由がいくつかありました。その一番の理由がそれまでのデファクトスタンダードだったSHP(シェープファイル)形式の存在です。

Googleトレンドで、全世界の検索ボリュームの中でのKML、SHPデータの相対ボリュームを比較すると、2007年にはKMLがSHPとの立ち位置を逆転していますが、その差は大きく離れるわけではないこともまた読み取れます。 スクリーンショット 2016-01-04 7.03.53.png

一方で、じわじわとその足元から存在感を示してきているのが GeoJSON形式です。 ひとことで言うと、KMLで実現できなかったSHPファイルの世代交代は、このGeoJSONが近い将来成し遂げると思います。

その理由を述べます。

  • データ構造がシンプル、理解しやすい。
  • データと表現が分離されている(HTMLとCSSのような関係)
  • SHPが扱える点・線・面のベクタ型フィーチャのみにデータ型が限定されている。
  • 文字化けトラブルが起きにくい。文字コードが UTF-8 に限定されている。
  • 属性データの格納の自由度が高い。SHPのようにフィールド名制限とかほぼない。
  • デフォルトの座標系/測地系が EPSG:4326(緯度経度座標系/WGS84測地系)。
  • ヘッダーにcrsプロパティを記述することで任意の座標系/測地系に指定可能。
  • トポロジ構造化した TopoJSON 形式も用意されている。
  • JSON構造がベースなのでJavaScriptなどウェブマップサービスで扱いやすい。
  • QGISを始め多くのFOSS4Gツールでは既に読み込み/書き込みに対応している。
  • なによりGitHubで簡単に可視化できる。

というわけで、

ここでは、どれだけGeoJSONが扱いやすくなったのか、OSMGitHubを使って実演してみます。

新年なので、神社のPOIデータをOSMから引っ張り出す

神社タグは religion=shinto

OpenStreetMap(以下OSM)には神社仏閣の位置データが多数格納されていますが、日本の神道の教会でもある神社はOSM上ではお祈りする場所として amenity=place_of_worship ( 稲荷神社のような道端の小さな神社はhistoric=wayside shrineとして定義) 、宗教として神道を意味する religion=shinto とタグを記述します。

2016年1月3日現在、世界で神社として登録されているPOIデータは約5,000箇所以上になるようです。

スクリーンショット 2016-01-04 7.44.49.png

http://taginfo.openstreetmap.org/tags/religion=shinto#map

神社タグからOverpass-Turbo APIで検索

この神社タグ religion=shinto を使って、 overpass-turbo API で検索してみます。検索用のスクリプトは以下の内容ですが、TagInfoスクリーンショット 2016-01-04 8.16.23.png ボタンをクリックすると簡単にスクリプトが生成されます。

/* This has been generated by the overpass-turbo wizard. The original search was: “"religion"="shinto" global” */ [out:json][timeout:2500]; // gather results ( // query part for: “religion=shinto” node["religion"="shinto"]; ); // print results out body; >; out skel qt;

ここでは横着して、既に用意したスクリプト をお使いください。 http://overpass-turbo.eu/s/dx2

https://cloud.githubusercontent.com/assets/416977/12081465/33fa2802-b2bd-11e5-9c2b-33ca9e349b95.png

スクリプトが読み込まれたら、実行ボタン ![スクリーンショット 2016-01-04 8.25.00.png] (https://qiita-image-store.s3.amazonaws.com/0/18691/da46b2ce-5461-05f0-3cad-7834ac08f41e.png)をクリックすると、検索処理が開始されます。

https://cloud.githubusercontent.com/assets/416977/12081459/faf73bee-b2bc-11e5-9b52-b8f6d4f4696f.png

右下のノード数が5,000ポイントを超えていたら正解!

https://cloud.githubusercontent.com/assets/416977/12081393/98ed8e78-b2ba-11e5-9cd3-3df098823ac8.png

迷わずGistへ直接エクスポート

あとは、ためらいなくエクスポートボタン スクリーンショット 2016-01-04 8.31.46.png をクリックして、 “GeoJSONをgistとして保存” を選択。

https://cloud.githubusercontent.com/assets/416977/12081487/d4a10474-b2bd-11e5-893a-b21f7575e48b.png

しばらくすると

スクリーンショット 2016-01-04 7.49.55.png

と表示されます。

GeoJSONファイルを自動的にマッピングしてくれるGitHub

同じタイミングで、ウェブブラウザにこのように GitHub の Gistページが表示されます。GistにはGitHubのアカウントがなくても、anonymous という、アカウント無しの状態でファイルの投稿ができます。

https://gist.github.com/anonymous/0c06bc837a25bc931f41

スクリーンショット 2016-01-04 7.50.40.png

ちゃんと、ウェブマップとして、表示範囲を変えたり、ズームレベルも変更できます。 また、属性情報は対象の地物をクリックすることでポップアップ表示されます。

スクリーンショット 2016-01-04 7.53.48.png

まとめ

  • 今後、SHPファイルはGeoJSONに置き換わっていく
  • OSMも含めて、データの受け渡しはGeoJSONになっていく(既になっている)
  • GeoJSONファイルの受け渡しには GitHub が便利(とくに Gist )
  • GitHub に投稿した GeoJSON ファイルは自動的にマッピングされる(背景はOSM)
  • OSM → Overpass-Turbo API → Gist on GitHub の流れが最強!

Happy Mapping!! :-)

このブログは、OpenStreetMap Advent Calendar 2015 の記事として書きました。 (締め切りは見事に過ぎました…orz)

というわけで小ネタをひとつ。

2015年の秋は、mapbox インドチームを中心に、アジアのOSMマッパーと青山学院大学の学生他、日本のOSMマッパーのみなさんと、日本のOSMデータ品質向上プロジェクトを実施しました。

https://github.com/mapbox/mapping/issues/120

その中で得られた成果の一つに「国土地理院のオルソ空中写真レイヤの精度がすごすぎる!」ということです。

StravaのGPSログと国土地理院オルソとOSMデータ重ねあわせ

(写真. StravaのGPSログ[ヒートマップ]と国土地理院オルソ[背景写真]とOSMデータ[道路など]重ねあわせ精度比較)

様々なデータを比較した結果、OSMマッパーにとって一般的なBing航空写真よりも、地図調整を行っている国土地理院の標準地図よりも、GPSロガーよりも、国土地理院のオルソ空中写真が最強であるということがわかりました。

もちろん、国土地理院のオルソ空中写真も弱点はあります。

  • 日本全国をカバーしているわけではない。
  • 写真撮影日は比較的古い(2007年以降)

それでも、その位置精度は日本のOSMの品質向上にとって重要なリファレンスとなります。

というわけで、この成果から iDエディタで日本国内を編集する際には、背景画像設定機能から “Japan GSI ortho imagely” として簡単に選べるようになりました。

トレースした際は、できるだけ source = GSImaps/ort と記述もお願いします!

地理院地図オルソレイヤ追加のマージ作業のメモ

マージ作業中メモ

Thanks for all OSM mappers, Happy Mapping!!

Origin: https://www.openstreetmap.org/user/pratikyadav/diary/36182 ( @pratikyadav posted on 2015 Oct 8)

ID: PlaneMad と ID: MAPconcierge による「日本の主要道に関する改良タスク」の記事を踏まえて、今、日本のOSMコミュニティは、東京および周辺地域の道路データ修正について集中して取り組んでいます。

TeachOSM Tasking Manager for Tokyo.

TeachOSM Tasking Manager for Tokyo. http://tasks.teachosm.org/project/91

目的は、以下のとおりです。

  • 主要な道路の道路中心線の修正とマージ (自動車専用道路、国道、主要地方道および一般都道府県道)

  • 合流や一方通行のタグを考慮して、主要な道路の上下線を分離

一国の首都であり、多くの日本人マッパーの中心地ということもあり、全体的に見てOSMデータの品質は非常に良いです。しかし、別の方法からの見直しは確実にデータの質をを向上させることができます。

このタスクに貢献することで、日本のOSMコミュニティに参加してください。 説明は英語、日本語、ロシア語でご利用いただけます。

自国語に翻訳したい場合は pratikyadavあるいは MAPconcierge にご連絡ください。

マッピング方法の詳細については http://tasks.teachosm.org/project/91 を参照してください。

Happy Mapping!!

Location: 二番町, 千代田区, 東京都, 102-0084, 日本

Origin: http://www.openstreetmap.org/user/PlaneMad/diary/36058 ( @PlaneMad posted on 2015 Oct 8)

(訳者注:急ぎ翻訳したため正確でない部分があります。ver0.86 )

この数週間、Mapboxのデータのチームは、一見すべてが網羅的にマッピングされたように見える日本のOSMデータの膨大な未接続の道路を調査してきました。

![screenshot 2015-10-08 17 25 25] ( https://cloud.githubusercontent.com/assets/126868/10365528/b98eeec4-6de1-11e5-935a-51d7238ece57.png ) 日本全域の壊れた highway 分布図。より大きな円は高位分類クラスの Highway を示します。

かなりの数の興味深い知見がデータから見えてきました:

  • 日本のほとんどの道路データは、2011年から実施された Yahoo! JAPANデータインポートの結果で、 500万本以上の道路セグメント が含まれています。

  • 既存の道路データは、GPSデータと比較すると位置誤差(5〜30メートル)を持ち、衛星画像と一致していない位相構造の誤りが含まれています。

screenshot 2015-09-14 16 08 10

  • 首都圏の道路は、正しい位置に修正されていますが、それ以外の大部分は、まだ2011年以降修正されていません。 ![screenshot 2015-09-14 16 27 36] (https://cloud.githubusercontent.com/assets/126868/9848298/8ec5afa8-5afd-11e5-9c7f-39b230ea85a1.png)

  • 車が走行可能な多くの道路が path としてタグ付けされており、多くの path は、道路としてタグ付けされています。 ![screenshot 2015-10-08 18 34 54] (https://cloud.githubusercontent.com/assets/126868/10366982/620fb278-6deb-11e5-844a-04254df36d7d.png)

  • 道路は、すべての接合部との間の小さなセグメントに分割されています。 untitled

  • マイナーな道路の分類は、YH:width タグ に基づいているように見えますが、衛星画像と比較して、一貫性のない道路幅の値が見受けられます。分類結果は、任意のセグメントに対してtertiary、unclassified、residential の三分類がされています。 untitled

  • 日本のBing画像カバレッジは全域をカバーしていますが、OSMデータやStrava GPSデータと一致していません。日本においてはオフセットとオルソ補正の誤差の両方があるので、新人マッパーは、iDエディタを使用して、誤差を持ったBingのイメージを背景にデータトレースすることで多くの矛盾を引き起こす原因になります。 untitled

  • 国土地理院から提供される非常に詳細な 地理院地図 標準マップ(std)は、OSMでトレース可能です。ズームしてよく見てみると、主要道路は正確ですが、マイナーな道路は正確ではありません。 untitled

  • 利用可能な最良の画像ソースである国土地理院の地理院地図・高解像度オルソ画像(ort)はStravaのGPSデータと完全に一致します。 ![screenshot 2015-10-08 18 00 41] (https://cloud.githubusercontent.com/assets/126868/9682282/dccb1d38-5322-11e5-97c4-ab57ba45cf5e.png)

ただ、この高解像度オルソ画像のカバーエリアは日本の主要な都市部に限られています。 ![screenshot 2015-10-08 18 00 41] (https://cloud.githubusercontent.com/assets/126868/10366209/87645ace-6de6-11e5-9804-4a08a966451a.png)

マップの修正

日本の複雑なデータ問題を修正するのは、やりがいのある仕事です。インポート以降の4年間、データの大部分はそのまま残されました。日本のOSMコミュニティのメンバーは、どのようにこれらの大規模なデータの不整合を作成するのか、市民参加型マッピングとしてハードな作業であると表明しています。

我々の現在のOSMツールは、この規模のデータクリーンアップのために準備ができていません。そして、それをスマートなツールとマップに修正するには、ローカルマッピングコミュニティに権限を与え、データのクリーンアップ戦略の進化が必要です。

データチームはこの問題へチャレンジのアプローチ方法について望んでいた日本人コミュニティからのインプットを得ました。

みなさんは私たちの マッピング・リポジトリ に再マッピングトライアルと我々の調査結果をフォローすることができます。

今後の記事で、私はこれより包括的な取り組みに役立つ可能性があり、既存のツールや教訓を使用してクリーンアップ戦略を文書化したいと思います。

Location: 六車, 南牧村, 甘楽郡, 群馬県, 370-2806, 日本