update.日本は災害の多い地域であり、災害の対応において、地図の存在は非常に大きなものです。Mappingという形で、災害時における地図作成活動が行われています。日本におけるその活動は、今後も実施方法について検討が必要であるという認識です。先日の鳥取震災においては、遠隔から大量に行われた編集によって多くのデータが誤編集、あるいは破壊され、地元のマッパーが編集意欲を失ってしまうなどの事態を引き起こしています。本家HOTの活動についても、災害発生時のマッピングがひとつの柱としてありつつ、基本は防災・減災の活動となっています。日本においても、その流れでなにかできないかな、と考えていたのですが、とりあえずやってみよう、ということで、始めてみます。detail(神は細部に宿る)"です。Managerで実施しています。日本には2014年時点で、1718の市町村が存在します。そのうち、人口10000人以下の自治体は536ほど存在します。した自治体では、都市計画図の作成(公共測量)による高い位置精度(1/2500)をもった地図を保有できていないことがしばしばあり、また、定期的なデータの更新(本来は5年に1度)についても困難を有しているという課題があります。ここをなんとかするのがよいのではないか、と考えました。boundaryデータを分割しました。village)です。admin_level=8である、区(suburb)が丸められてしまいますが、区である時点で人口が多く、あとまわしになるはずの自治体です。気にしないで続けます。QGIS(2.14)のメニューでゆけば、ベクタ→データマネジメントツール→ベクタレイヤの分割から実施できます。分割されたあとはそれぞれの自治体ごとにshapefile形式のファイルが出力されます。Managerの登録に必要な、geojson形式に変換し直す必要があります。変換作業ではまず、ファイル名に空白があるので、空白を除去します。もって、できあがったファイルを、ogr2ogrを使って変換します。ここが参考になりました。最終的に使ったコマンドは以下のとおりです。done総務省が作成している資料(住民基本台帳に基づく人口、人口動態及び世帯数)をもとに、人口の少ない自治体を割り出しました。Managerに追加します。ほんとうはここで、Mapzenのデータに対して、自治体の人口の属性カラムを追加し、分割や追加をやりやすくするべきなのですが、QGISの操作に慣れておらず、作業をすることができていません。_)m(久々に、OSM側のカラムとして全国地方公共団体コードが追加されているといいのになぁ、と思ってしまいました。そのうちやりたいです。Managerへの追加かーさんがよなべーをしてー。Managerに文章をコピペし、登録をします。Managerに登録してみました。いくつか手がけてみて、改善できる部分は改善してゆきたいと考えています。プロジェクトのコピー機能とかあるといいのかもしれないですが、こういう使い方する人は多くないと思うので、リクエスト出すのも憚れてどうしたものかなー、という印象です。以下のことに気をつける必要があります。詳しくはプロジェクトの「インストラクション」部分にも記載しています。後ほど、この部分は分割して、詳しい描き方のドキュメントを作成する予定です。一緒に整備するとよいでしょう。公民館の近くの駐車場などは、たいていどこの役場でもそれなりに広くスペースが確保されており、描きやすいです。Satelliteを使うと、山間部などであってもカバー率が良好です。Satelliteでも表示がされない場合は、地理院地図(標準タイルを使うのがよいと思います。衛星写真のオフセットが変更できる環境で作業している場合、位置のあわせは、地理院地図(オルソ)にあわせるとよいと思います。wiki等を参照してください。道路(特に一本道道路)の整備を深追いするのはやめましょう。明らかに航空写真とズレていても、今回のターゲットはそこではありません。:))さらにいえば、「正しい位置」へ補正を行うためには、位置の精度が高いGPSトラックが必要となります。したGPSトラックが少ない現状では、精度の高い整備が不可能です。航空写真だけを使って編集する場合、山奥の道路などで道路の位置をそもそも追いづらい、ということもあります。データを実運用する観点からゆけば、山奥などで一本道の道路の場合にはその道路を使っていることが自明であり、分かれ道などで迷う可能性が比較的少ないだろう、ということもあります。将来的に、GPSトラックなどを整備して再度チャレンジしたいと思っています。それから当然ですが、「既にマッピングが精密に行われている地域」を無理に実施する必要はありません。OpenStreetMapのマッピングにおいては、現地の活動が優先されるべきです。明らかな地図のエラーは、この機会に対応しておくとよいかもしれません。JOSMを使って編集しているときには、「妥当性検証」を行っておくとよいでしょう。(海岸線の外側に、森林ポリゴンがはみ出ている状態)があります。このエラーは、個人的に優先したい対象です。これはもともと、Yahoo!Japanから提供された海岸線と、過去に国土数値情報からインポートした森林ポリゴンで位置に相違があることで発生しています。海岸線と森林は修正にやや手間がかかるデータです。このエラーはもう何年も「よくある間違い」として指摘されている項目であり、この機会に少しでも減らすのはよいことだと思います。(今後、MapRouletteなどを使って、別途でTaskにしてもよいかもしれないですね)今回のプロジェクトにおけるメリットこのプロジェクト、地域の防災などで使えたらよいなあ、と思っているとともに、他にこんな効果もあるのかな?と思い始めています。遠隔マッピングのサンプル地域としてアームチェアマッピングを行う際に、対象となる地域の選定はとても難しいです。広すぎず、狭すぎず、多人数で実施しても競合が発生しないエリアというのは、考え始めるときりがありません。した場合に、対象として描画をしてみるとよいのかな、と思っています。実際の作業において、人口の少ない市町村というのは、もともとが人口密集地域が少ない地域ですから、描く対象もそれほど多くなく、1つのタスクが1時間ほどで作業が完了します。実施した作業の確認(バリデーション)を含めても、メリハリをつけた作業時間を確保することができ、2−3時間程度の講習会でも扱いやすいサイズになっています。MapsやYahoo!地図、そしてそのもとになっているゼンリン社の活動が素晴らしく、都市部においては世界でも例を見ないほど高品質の地図が整備されています。離島や山間部などの地域は、商業的にあまり大きなインパクトを有しておらず、地図の更新が滞りがちになってしまっています。OpenStreetMapではこうした地域の地図を優先的に整備することによって、他の地図がカバーすることが難しい地域の手助けをすることができます。商用地図とOSMを同じ土俵の上にのせて「どちらのほうが使える」と比較する不毛な議論ではなく、「お互いがお互いの特色を活かす」ほうが、社会が総体として、前進できると思うのです。Managerに登録する時にとても手間なので、やっぱり属性カラムに市町村の人口を付け足しておきたいと思っています。OSMデータ側には市町村のコードが整備されておらず、QGISのなかでどういう操作をすれば作業ができるのか、いまいちよくわかっていません。したら、人口で分割するのをやめて、最初は「町と村」を対象にしてしまうのがよいのかもしれません。平成26年時点で、町が745、村が183ありますので、合計で約920個。市になるためには人口が5万必要なので、少なくともそれ以下の自治体をカバーできることになります。総数1712の半数も超えることができますので、よく言われる「OSMのカバー率」として、「自治体数で半分は描いてますよ」と返すことができるようになります。(カバー率っていう言葉自体が、相当バイアスのかかった変な聞き方の気がしますけどね)海の部分を作業対象外にしたいOSMの自治体ポリゴンは、海の上までごそっと広がった形状になっています。して登録されてしまっています。これもQGISを使って、陸地部分だけを作業対象のポリゴンにしたいなぁ、と思っています。したら、QGISではなくて、PostGSISを使うほうがよいのかもしれないですが、どうやったら望む結果が出せるのか、ちょっとよくわかっていません。名称が重複している自治体Wikipediaのページ「同一名称の市町村一覧」に詳しいですが、日本には名称が重複している自治体、というものが存在します。現在の分割方法では、名前をもとに分割を行っているため、名前が重複している場合、2つの自治体が1つのファイルとして分割出力されます。格好が良いものではないので、これもなんとかしたいところです。県や郡の名称、人口などを属性カラムにいれて、結合すればよいのですが。Docsなどで、作業完了したかどうかのチェックリストは作りたいなぁ、と思っています。wikiのほうがOSMプロジェクトとしては正しい気がするのですが、作成するのもチェックをつけるのも、ちょっと面倒くさいなぁ、と感じています。(ごめんね)こういうのはうまいこと地図上に表示ができるとよいのですが、そういうのはGithubでページ作ればよいのかなぁ?(適当発言)とまれ、このへんの作業について、「こうやればいいんじゃない?」というアイデアをお持ちの方はコメントいただけると嬉しいです。同地点の地理院地図)におけるマッピング活動でした。みなさんもぜひ一度、みてみてください。下北山村では、現地マッパーによる非常に細かい情報が記載されており、すべての建物が描かれ、そして、amenity=shelterとして、防災拠点もマッピングされています。OpenStreetMapは、三点測量を中心とした位置精度という観点からいえば、測量の基準は全く満たしていません。現地の活動が加わった"生きている"地図は、その地域で"生きている"人たちの役に立つことができるのだ、と感じられます。した地域が増えることが、とても望ましいと思っています。Managerを使ったこのプロジェクトは、いわゆるアームチェアマッピングの作業です。アームチェアマッピングは、その品質や手法について、定期的に批判が起きる手法です。僕も、完璧だとは思っていません。遠隔でできることの限界を見極めた上で、でも、遠隔からできることは遠隔から行い、地元では、本来やりたかったこと、やるべきことがすぐにスタートできるような状態にしておくことも、重要だと思っています。みんなの手で、日本の地図の底力があがる、そんな活動にしてゆきたいな、と思っています。upLoginユーザーは見つかりませんでした。