これは何？

この記事は、2017年10月に開催された技術書典3にて、サークル「タイル3兄弟」として頒布した同人誌『OpenStreetMap編集ステップアップガイド』を、一部改修した内容です。

いくつかの記述が古い内容になっていたので、気がついたところは修正しています。
もし明らかに異なる内容がまだありましたら、指摘をいただけると嬉しいです。

それでは、よりよいマッピングライフを！ (/･ω･)/

この本の目的

近年、iDエディタやMAPS.MEなど、OpenStreetMapのデータ編集は多くのツールが開発され、編集自体に対するハードルは次第に難易度が下がってきています。

しかし、OpenStreetMapの編集を行ってゆくと、どうしてもよくわからない部分がでてきたり、とてもではないけれども憶えきれないタグの情報に混乱してしまうときが訪れます。

それらの情報は、OpenStreetMapのデータを構成するにあたって非常に重要な概念であり、それらを集めるため、そして解説するために多くのドキュメントが作成されてきました。

しかし「地球上のすべてを表現する」というOpenStreetMapの目的を反映して、それらの情報は非常に数多くなってしまっており、実際にOpenStreetMapのマッピングを行う際に具体的にどのような作業を行えばよいのか、わかりづらいものになっていることも事実です。

この本は、筆者がOpenStreetMapの編集活動を行う上で使っているTIPSをまとめたものです。あなたが直面する「こんなときどうするんだっけ」に対して、OpenStreetMap編集を行う際のリファレンスとして参照いただければ幸いです。

道路の編集

日本の道路編集と、道路の「階層」

OpenStreetMapでは、道路のラインを編集する際、その道路の「階層」をタグとして表現します。

日本では慣習として高速道路や国道・都道府県道などの分類に沿ってOpenStreetMap上の階層構造も作成されています。ただし、その階層を理解する前に、OpenStreetMapにおける道路の階層の基本的な考え方を理解しておくと、その階層の理解にも役立ちます。

highway=*	概要
motorway	高速道路。多くの場合は有料で、2車線以上で構成されます。
trunk	日本国内の交通網を構成する上で最も重要な道路。幹線。日本では、国道が相当します。
primary	trunkの次に重要な道路。日本では、主要地方道（都道府県道）のうち、主に番号が二桁の道路が相当します。主に市レベルの、比較的大きめの居住地同士をつなげるように整備されます。
secondary	primaryの次に重要な道路。日本では、主要地方道（都道府県道）のうち、主に番号が三桁以降の道路が該当します。主に、町や村レベルの、比較的小規模な居住地同士をつなげるように整備されます。
tertiary	secondaryの次に重要な道路。日本では、2車線以上の道路に付けられることが多くあります。市町村のなかで、集落や繁華街同士をつなげるように整備されます。
unclassified	tertiaryよりも重要度が低い一般道に対して付与されます。住宅地同士を繋ぐ道路などに利用されます。
residential	住宅地のなかで、それぞれの家に到達するための道路です。行き止まりになっていたりして、通り抜けができない場合があります。
service	工場や駐車場など私有地のなかを通る道路や、residentialの道路から少しだけ奥まった「路地」の部分に対して付与されます。しばしば、通り抜けができません。
track	農道や林道。農地のなかや、森林のなかにある場合に利用します

unclassifiedとresidentialの違いについて

日本と諸外国を比較した際の特徴のひとつとして、日本は居住区域（residential）という概念が薄いという点があります。

そのため、初心者マッパーが道路を描く際に、描く対象となる道路がunclassifiedなのかresidentialなのか、そしてそれらの区別をどのように行うのか、という点は、しばしば混乱を招くポイントになっています。

しかも、この2つは数が多く、非常に日常的な描画の対象になります。

この問題、熟練者であっても、頭を悩ませることが多いはずです。

一応、都市計画としては用途地域として第一種低層住居専用地域や準住居地域などの区分があるにはあるのですが、日常的に目にする情報ではなく、OSM編集にあたって参照するのは難しいと思われます。

個人的にではありますが、私はOSM wikiで表記されている分類の補足として、以下の基準で区分を行っています。

OSM wikiにおける元々の解説

unclassified: 一般道（２車線未満）。 1.5車線以下でセンターラインも無いが、交通ネットワークを形成する舗装路。舗装林道や圧石路も含む。
residential: 居住区域内道路。住宅街にある道路で、通り抜けを目的としていない道路。

筆者による分類補足

unclassified: 別の道路への通り抜けができる。人が住んでいる地域と地域や、主要な道路の間をつないでいる。しばしば1.5車線。
residential: unclassified同士を繋いでいる。通り抜けができない場合や、環状になっている場合がある。個々の家に到達するための道路。しばしば1車線。

ですが、正直なところ、この2つの区別はさほど重要ではないなぁ、とも感じています。対向する車同士がすれ違えるかどうか、という観点でざっくり決めてしまっても、そこまで大きな影響はない気がします。

国道・県道のリレーション

国道や都道府県道を描く場合、ほとんどの場合は基本に沿ってhighway=primaryやhighway=secondaryを使って区別することができます。ですが、例えば1区間に複数番号の国道・県道が乗り入れている場合など、highwayにどの値を入力すればよいか、混乱することがあります。

そうした場合は、リレーションを使うことで、国道や県道を正確に表現することができます。
type=routeリレーションを作成し、リレーションに対して以下のタグを付与してください。

キー	値	補足説明
type	route	必須
route	road	必須
network	（国道）JP:national （都道府県道）JP:prefectural	必須
ref	国道・都道府県道の番号	半角英数字で入力
name	一般的な呼び名
official_name	正式な名称	兵庫県道81号小野香寺線など

この場合、リレーションに対してhighwayタグは付与しないでください。

リレーションに対してhighwayタグを与えてしまうと、ウェイ側に付与されているhighwayタグと情報の重複が発生してしまい、いわゆる険道や酷道といった状態や、階段国道などの状態を正しく扱うことができなくなります。（osm.orgのレンダリングでも、リレーション側のhighwayタグのほうが優先して適用されてしまいます）

歩道系のタグについて

OpenStreetMapでは、歩道を描くことも可能です。
分類は以下のようになります。

highway=*	概要
footway	歩行者専用道路。舗装されているかどうかは問わない
pedestrian	都市部の歩行者道路。ある程度の広さの場合、エリアとして描くことも可能
path	特に用途が定められていない、歩行者が通行できる場所
cycleway	自転車専用道

footwayとpedestrian、pathの使い分けに、わかりづらい場合があるかもしれません。特に「これ」という取り決めは無いのですが、私の場合、以下のようなイメージで描いています。

highway=*	概要
footway	市街地のなかにある歩行者専用の歩道
pedestrian	車道部分が無く、道路全体が歩行者だけ通行可能な道路。他、ペデストリアンデッキもこのタグ
path	ハイキングコースなど、自然のなかの歩道

ここに、適宜accessタグなどを使って通行可能な種別を指定するなど、アレンジを行ってゆきます。

歩道をエリアとして描く場合の道路ネットワーク

ペデストリアンデッキなどを表現する際に、歩道をエリアとして描く場合があります。
具体的には、対象の場所をエリア（ポリゴン）として描いた後、以下のタグを付与します。

highway=pedestrian
area=yes

すると、下図のような状態でレンダリングが行われます。

例は、秋葉原の駅前広場です。

また、この場合、エリアで描いたペデストリアンデッキに加え、歩道の道路ネットワークとして、ウェイとしても別途データを描くようにするとよいでしょう。

これは歩道データを使った経路探索を行うにあたって、エリアとして描かれるデッキ部分以外に、ウェイとしての道路ネットワークが必要になることが理由です。

エリアとしての広場と、道路中心線としてのウェイ、この2つのオブジェクトを両方追加しておくことで、絵図としての地図とネットワークデータとしての地図の両方に対応することができるようになります。

歩道橋と歩道ネットワーク

街中にはしばしば、幹線道路など大きめの道路をまたいで歩道橋が設置されている場合があります。

そうした場合、歩道橋の部分をbridgeとして描くことがあると思うのですが、その歩道橋の道路ネットワークのウェイをどこに接続したらよいか、困る場合があります。

この場合、地面の部分にある歩道ネットワークも別途描き、そこに歩道橋のネットワークをつなげる必要があります。車道とは別に歩道が設けられれている場合、なるべく歩道を車道とは別のオブジェクトとして描くようにしましょう。

信号機の描き方について

海外の道路と違い、日本の信号機には名前がついている場合があります。こうした信号機の名称は、nameタグで表現されます。

これらをどのようにマッピングするかは、長い間の議論になっており、いまだ、いくつかのやり方が混在しているのが現状です。

そしてしばしば、正しい道路ネットワークを描くことと、レンダリングのためにデータ構成を変えることが混同され、混乱を招きます。

基本的に、道路の交差を正確に表現させるため、基本的に道路のウェイは井桁状に描きます。

一部だけすぼませるように描くと、正しく経路探索が実施できなくなります。

正しい描き方

誤った描き方

道路ネットワークを表現するには、現実の道路の接続状態を正確に表現することがまず必要です。また、複雑な表現になればなるほど、より高度な表現として、turn restrictionリレーションを使った右折禁止、左折禁止などの表現が必要になってきます。すぼめて描いてしまうと、これらの条件を満たすことができず、正しい経路探索が実施できなくなってしまいます。

信号機に関する特記事項

日本の信号機にはしばしば名前がつけられており、ナビゲーションの用途に使われています。また、OpenStreetMapでも、名前のつけられた信号機を表現するために、ノードオブジェクトに対してnameタグを付与することが一般的です。

1本同士のウェイが交差する場合

道路オブジェクトの交点が1つである場合、その交差する1つのノードに対してhighway=traffic_signalとnameタグを与える方式で問題ありません。

2本以上のウェイが交差する、あるいは複数の信号機が設置されている場合

1つの交差点に対して複数の信号機が設置されている（道路オブジェクトの交点が複数ある）場合、それらの信号機を囲むようにエリアオブジェクトを描き、そのポリゴンに対して junction=yesとname=****のタグを与えます。

この、エリアによる記述方法については、2つほど注意点があります。

OSM wikiのドキュメント上は上記の記述方法が正しいとされているのですが、まだ日本国内でこの記述方法を使ったやりかたは少数に留まっており、一般的とは言いづらい状況です。中央分離帯つきの道路が含まれるような複雑な記述を行う場合は、Talk-jaなどで相談しながら記述するほうがよいかもしれません。
北海道地域に設置される信号機に対するnameタグの付与方法についてはまだ明確な定めがありません。なかには1つの信号機に対して複数の名称が付与されているパターンも報告されており、これからの整理が必要となっています。その場合は、個々の信号機に対してnameを追加し、さらに、エリアオブジェクトに対して交差点のnameを別途追加する方式が、いまのところ最も、現行の記法に近い形となります。

自然物

河川の描き方

地図を作る上で、河川や湖はしばしば描かれる重要な地物です。
OpenStreetMapでそれらの地物を描く際の描き方を示します。

基本的に、河川の中心線をラインとして描いた上で、河川の流域は別途ポリゴンとして描きます。

詳しくはOSM wikiも参照してください。

基本の河川の描き方

河川の中心線をラインとして描き、川の太さに応じて適切なwaterwayタグを付与します。
中洲などで、短距離の間だけ一時的に2つ以上に分岐している場合、主流となるウェイだけを描きます。

waterwayタグで河川を描く場合、ラインの矢印の向きは、河川の流れる向きを意味します。
大きな河川であれば流れる向きが明確ですが、stream（小型河川）やditch（用水路・堀）など、小さな河川の場合は少し気をつけるようにしてください。

一級河川/二級河川の情報

日本地域で定められる一級河川や二級河川の情報についてはrefタグなどで表現できると思われますが、それらの情報に対して適切なタグは2017年現在、まだ議論されていません。
もしより詳細にタグづけを行いたい場合、talk-jaメーリングリストなどで議論を行うとよいでしょう。

もしリレーションとして河川の情報をまとめたい場合、type=waterwayのリレーションを作成することで、情報をまとめることができます。

河川の流域の描き方

waterwayタグで描くウェイは、道路中心線ならぬ「河川中心線」です。
その川が流れている水域部分は、waterwayウェイで描いた中心線とは別オブジェクトとして、waterway=riverbankタグ（あるいは、natural=waterとwater=riverのセットのどちらか）を付与したエリアで表現します。

waterwayを付与したラインオブジェクトとは別に、水が流れている領域をポリゴンで描き、そのポリゴンに対してwaterway=riverbankか、natural=waterとwater=riverタグのセットの「どちらか」を付与します。

流域が広い場合、ポリゴンは適当な大きさにし、複数のポリゴンを使って表現します。

——OSM wiki-Tag:waterway=riverbankより。CC-BY-SA 2.0

この場合、中洲を表現するには、マルチポリゴンのリレーションを作成します。
手順は以下のとおりです。

riverbankのポリゴンを描く
そのポリゴンの中に、中洲となっている陸地部分をポリゴンで描く
外側のriverbankポリゴンと、中洲部分（内側）のポリゴンを選択する
JOSMであれば、キーボードのShiftキーを押しながら、その2つのポリゴンをクリックします。これで、2つのポリゴンを同時に選択したことになります。
その状態で、JOSMの “ツール -> マルチポリゴンの作成”を選択する
riverbankのポリゴンがouterロール、陸地部分がinnerロールになっていることを確認してください

これで、中洲部分を持った河川流域を描くことができます。

ダメな例：
中洲を描く場合に、マルチポリゴンを使わず、一筆描きのようにポリゴンが描かれていることがありますが、これは間違いです。
マルチポリゴンの使い方が普及していなかった過去に作成されたデータでよく見受けられる間違いですので、適宜マルチポリゴンとして作り直す必要があります。

既存の河川に付与されているlayerタグについて

日本地域におけるwaterway=riverのライン・オブジェクトには、しばしば全体にlayer=-1のタグが付与されています。

これは歴史的にいうと、2009年前後に行われた国土数値情報データのインポートの際に付与されたタグであり、当時まだインポートにおけるタグづけ方針などが明確に定まっていなかったために与えられたものです。

layerタグは、橋などで道路と交差している場合に、重なりを表現するために使用されるものであり、なにも重なっていない河川に対してlayer=-1タグを与えるのは不適切です。他のオブジェクトと物理的に重なっていない場合に付与されているlayer=-1タグは、削除してしまって問題ありません。

森林リレーションの取り扱い

日本国内の森林ポリゴンの多くは、2008年前後に国土数値情報のデータを利用してインポートされたデータであり、いくつかの問題を持っています。

ただし、消してしまうにもまた問題が多い状態になっており、継続的な修正が必要になっています。

もし現状にあっていない森林データを見つけた場合、積極的に修正を行ってください。リレーションの補修方法については、Qiitaにドキュメントを記載してあります。

具体的には、以下のような誤りが散見されます。

データ品質に起因するもの

森林の位置や形状が間違っている
河川や湖、海などの水域部分の上に森林ポリゴンが重なっている

国土数値情報で公開されている森林データは、1/25000程度のかなり荒い位置精度品質で作成されています。そのため、海岸線や道路など、他の地物とクロスしてしまっていたりすることがしばしばあります。たいへん面倒ですが、森林を正しい位置に移動させてください。

データの経年変化によるもの

既に森林が消滅し、宅地などになっている

現状に合わせて修正してください。

元データの作成方法によるもの

森林を形成するリレーションが巨大である

マルチポリゴンを分割し、適切な大きさに変更する必要があります。マルチポリゴンオブジェクトをコピーし、2つ以上の塊に分割します。

不要なタグの存在

明らかに不要・意味が不明なタグがある

過去の遺物です。ほとんどの場合、タグを削除しても問題ありません。

人工物

建物の高度な描き方

OpenStreetMapの建物には、建物の階数や高さ、外壁の材質、屋根の形などを入力することができます。

全てを入力することは困難ですが、建物の階数くらいは入力しておくと、例えばMAPS.MEなどの主要なソフトウェアで3D表示されることもあり、日常的なマッピングが楽しくなるでしょう。

建物の3D表現については多くのタグが用意されていますが、まずは建物の階数、あるいは高さを入れておくことをお勧めします。

これらのタグは、建物のポリゴンに付与します。

内容	キー	値	備考
建物の高さ	height	数字（メートル）	建物オブジェクトの高さ。入れなくてもよい
建物の階数	building:levels	数字(階数)	階数。heightタグの代わりにこちらが入っていればとりあえずOKなことが多い

複雑な形状の建物の描き方

リレーションを使うことで、複雑な形状の建物を描くことができます。

中庭がある建物の描き方

マルチポリゴン・リレーションを利用して、中庭部分を「くり抜き」ます。
前述した、河川の中洲と同じ描き方を行います。

buildingのポリゴンを描く

そのポリゴンの中の、空洞部分となっている部分をポリゴンで描く

外側のbuildingポリゴンと、空洞部分（内側）のポリゴンを選択する
JOSMであれば、キーボードのShiftキーを押しながら、その2つのポリゴンをクリックします。これで、2つのポリゴンを同時に選択したことになります。
その状態で、JOSMの “ツール -> マルチポリゴンの作成”を選択する
buildingのポリゴンがouterロール、空洞部分がinnerロールになっていることを確認してください

部分部分で階数の異なる部分の描き分け方法

例えばマンションなどで屋上に一部分だけ高さの違う場所があることはしばしばあります。

そうした建物を描く際には、建物の外周部分を描くためにbuilding=***タグを作成し、建物のなかで一部だけ高さが違っている場所を表すために、別のポリゴンを作成してbuilding:part=yesタグを付与します。

まずは、建物の外郭部分を、通常のbuildingポリゴンと同じように描きます。
その建物外郭オブジェクトとは別に、建物の中身を埋めるようにしてbuilding:partオブジェクトを作成し、そこにbuilding:levelsなどのタグを付与します。
building:partタグと同時にbuilding:min_levelsというタグを組み合わせることで、渡り廊下状の形を作成することもできます。

住所・論理的な境界

住所の描き方

日本の住所は諸外国の住所と異なり、街区方式を採用しています。

そのため、階層構造に対する検索ソフトウェアが対応しきれておらず、日本地域における住所検索・ジオコーディングはあまり品質がよくありません。これは日本地域のOpenStreetMapの大きな課題のひとつといえます。

住所の階層構造

住所に関する構造は、以下のように定められています。

1つ1つのPOIに対して、これら全てを入力するかどうかは今後も議論の余地があります。個人的には、ノードに入力しておくのは市町村や区以下のタグだけでよい気がしていますが、当然様々な観点から異論があるかと思います。これからの議論が必要です。

キー	値	補足
addr:country	JP	JPで固定
addr:province	都道府県
addr:county	郡
addr:city	市町村
addr:suburb	区(政令指定都市の区以外の区も含む)
addr:quarter	大字 / (市町村配下の)町
addr:neighbourhood	小字 / 字 / 丁 / 丁目 / 島嶼部
addr:block_number	街区符号 / 番 / 番地 / 地番	無番地の場合はこの部分に"無番地"と記載
addr:housenumber	住居番号 / 号 / 支号 / 枝番号
addr:flats	複合住宅 / 施設の名称
addr:room	複合住宅 / 施設の部屋番号
addr:floor	複合住宅 / 施設の階層

住所（addr:*）タグを入力する際の手法

OpenStreetMapで住所を書く場合、以下のどれかの描き方を行います。

建物ポリゴンにタグを付与する場合

建物を表すポリゴンに対して、addr:*タグを追加します。

ポリゴンの中に複数の住所が存在する場合（例えば長屋状の建物など）は、建物ポリゴンに対してaddr:housenumberタグを付与しません。

そのかわり、次項のように、建物ポリゴンの「中」に、addr:housenumberタグを持ったノードを別途配置します。

ノードにタグを付与する場合（店舗ノード・エントランス）

建物の中に店舗がある場合や、建物のエントランス（特にメインエントランス）の場所が判明している場合、そのノードに対してaddr:*タグを付与することができます。

個人的にはこの方法が最も正確にデータ構造が表現できると考えていますが、入力に手間がかかるのが課題です。

インターポレーション・ウェイとして作成する場合

住所を意味するデータを1つ1つノードとして登録するのではなく、まとめてウェイとして配置することもできます。インターポレーション（補完）と呼ばれます。

日本では、それぞれの街区（番）のブロックのなかに、住居番号（号）が時計回りに割り振られますので、例えば以下のように描くことができます。
タグの付与方法は以下のとおりです。

ウェイの始点と終点のノードへのタグ:

addr:housenumber = *
addr:block_number = *

ウェイへのタグ:

addr:interpolation=all
addr:block_number = *

日本では、国土地理院が配布している「電子国土基本図（地名情報）「住居表示住所」」に、住居表示住所の採番基準となるフロンテージ情報が存在し、非常に有力なデータソースとなっています。

ただし2017年現在、このフロンテージ情報は測量法で保護されており、OpenStreetMapへのインポートデータとして利用することはできません。

背景画像オフセット

OSMを描く際にはBingやMapbox Satellite、地理院地図など、トレースの許諾がとれている背景図を利用することができます。
ただし、それらの航空写真は撮影・加工処理の都合上、少し実際の位置からずれてしまいます。

そうした位置の「ずれ」を補正し、背景画像を正しい位置に移動させる手段が「オフセット」です。JOSMでは、画像レイヤの上で右クリック（MacではCtrl+クリック）を行うことで、その画像レイヤのオフセットを修正することができます。

ではそのオフセットを行う際に、どの位置に画像をあわせるのがよいでしょうか。

伝統的にはGPSの軌跡にあわせるべきであるとされており、ほとんどの場合においてそれが最も正しい選択肢となります。

ただ、GPSの軌跡はすべての地域で利用できるわけではなく、また、数年以上前に取得された軌跡は、当時のGPS機器の精度がさほどよくなかったこともあって、複数の軌跡が取得されていない場合に信頼するのは頼りない面もあります。

そうした場合は、地理院地図の画像レイヤ（できれば地理院地図の航空写真レイヤ）に位置を合わせるのが、よりベターな選択肢として行われています。Mapbox Data Teamによって2016年に行われた幹線の位置補正作業も、地理院地図の航空写真レイヤとStravaのGPS軌跡を中心とした作業が行われています。

なお、地理院地図を利用する際には、出所明示のひとつとして、変更セットのタグやオブジェクトへのタグを追加する必要があります。

詳しくは、OSM wikiを参照してください。

地理院地図の標準地図タイルを利用する際の設定と必要なタグは以下のとおりです。

地理院地図：標準地図タイルを利用する際の設定

TMS設定URL	変更セットへのタグ
https://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png	source = GSImaps/std

地理院地図：航空写真レイヤを利用する際の設定

TMS設定URL	変更セットへのタグ
https://cyberjapandata.gsi.go.jp/xyz/seamlessphoto/{z}/{x}/{y}.jpg	source = GSImaps/seamlessphoto

コミュニケーション

他ユーザのサポート

OSMのデータ作成には多くのひとびとが関わっており、その習熟度はさまざまです。マッパーによっては、どのように編集したらよいかわからないまま編集を続けてしまっていたり、時折、意図しないままにデータを壊してしまったりする場合もあります。

もしそうした編集を見つけたら、ユーザに対して非難や指摘のメッセージを送るのではなく、積極的にサポートするように心がけましょう。

OpenStreetMapの編集監視はいくつかの方法があります。

Twitterのハッシュタグを使って、県毎にまとめられた変更セットのコメント情報をチェックする方法や、変更セットコメントの議論を確認する方法、あるいはOSMChaなどの編集内容一覧化プラットフォームを活用する方法が代表的です。

特にOSMChaでは、iDやJOSMを使って編集する初心者からの「レビュー依頼」が検索可能になりました。これらのレビューを行い、相手に適切なフィードバックを送ることで、新しいマッパーをヘルプすることができます。

OSMChaを表示させ、フィルタ設定にて、Flag -> Reasons for Flaggingから”Review Requested”を設定することで、レビュー依頼がの変更セットの一覧を取得することができます。

なお、OSMCha上でレビューを行った後、当該のマッパーに対して、変更セットのコメントか、直接メッセージかのどちらかの方法で連絡をとってみてください。（注：OSMCha上で行ったレビュー結果は対象のユーザに送信されません）

他の変更セット検知方法については、Qiitaの記事: OSMの破壊行為検知メモも参照してみてください。

Vandalismへの対応について

OpenStreetMapは誰でも参加できるという特性上、いたずら目的のユーザが時折発生します。
例えば、明らかに存在していない地物を書き込んでいたり、大量の情報を削除していたり、nameタグを面白おかしい名前に変えていたりすることがあります。

こうした行為はVandalism（破壊行為）と呼ばれ、適宜対応が必要となります。

そうしたユーザを見つけた場合、以下の順番で対応を行ってください。

当該のユーザに対して、OSM経由のメッセージ、あるいは変更セットコメントを使って注意喚起を行ってください。
明らかに間違いである編集を取り除くか、あるいはリバートプラグインを使って復旧させてください。削除を行う場合、単純に削除してもよいですし、対象のデータが大量である場合はJOSMのリバートプラグインを使うことも可能です。
相手からの応答を待ってください。一週間程度が目安です。いたずらのように見える編集は、しばしば、初心者による悪意のない破壊行為です。
相手からの応答があり、なおかつ相手が初心者であった場合、相手に「直してください」と連絡するのではなく、できればあなたが、原状復帰の編集を行ってあげてください。たいていの初心者は、原状復帰のためにどういったことをすればよいのか、その方法を知りません。
もし攻撃的なメッセージが送られてきた場合、私（nyampire@gmail.com）まで連絡ください。対応を引き継ぎます。
相手からの応答が無いまま、いたずら行為が続行されている場合も、私（nyampire@gmail.com）まで連絡ください。対応を引き継ぎます。

1と2は同時に行うことがしばしばあります。

つまり、相手の対応を待たず、リバートなどを先行して実施する、ということです。明らかに誤ったデータを残しておくほうが問題です。

ただし、タグ付け方針の違いなどによる意見の相違を相手に押し付けることは絶対にしないでください。これらの対応はあくまでも、「明確にいたずら行為である」と認識できる場合のみの処置であることに注意してください。

なお、5や6で私が対応を引き継いだ後は、以下のことを行います。

再度、対象のユーザに対して連絡を行います
攻撃的なメッセージによる応答や、こちらからの連絡を無視したいたずら行為の継続が見受けられた場合、OpenStreetMap Foundation Data Working Group (DWG, データ作業部会) に連絡を取ります。DWGはユーザの一時凍結やアカウント削除などの権限を有しており、それらのユーザに対応を行います。
この際、いたずら行為による影響範囲やこれまでの経緯概要を、英語で報告する必要があります。具体的にどのような連絡を行っているか、興味のある方は筆者まで連絡ください。

ポケモンGOユーザへの対応

2017年現在、ポケモンGOにおけるポケモンのポップアップ判定の元データとしてOpenStreetMapが使われています。そのため、ポケモンの出現率をコントロールしたいユーザがOpenStreetMapの編集を開始し、現実とは異なる地物を登録するということが多発しました。

幸いなことに、日本でそうした動きはあまり活発ではなく、2chなどのスレッドをみても、「OSMに迷惑をかけるな」という紳士的な活動が行われているように見えます。筆者は、現実に即した編集が行われる限り、新しいマッパーは常に歓迎されるべきかと考えています。（実際、筆者もポケモンGOをプレイしています）

ただし極稀に、著作権保護された地図から情報を転記していたりするなど、OSMで禁止された情報源を使った編集を行ってしまうユーザが存在することも事実です。

OpenStreetMap Foundationは、ブログでそうしたユーザに対する公式なメッセージを発信しています。

変更セットコメントや直接メッセージなどで、ブログのURLを伝え、問題のある編集を実施しないようお願いをしてみてください。
メッセージが完全に無視され、問題のある編集が繰り返される場合、データの破壊行為とみなし、適切な対応が行われることになります。
上記、Vandalismへの対応、の項目に沿って対応を実施します。

オブジェクトが削除されてしまった際の変更セット番号確認

OSM上からオブジェクトが削除されてしまった場合、削除されてしまったオブジェクトのIDを特定することが難しいケースがあります。

その場合、Whodiditを使うことで、その地域で行われた過去の変更セットを一覧化することができます。サイトを表示させ、該当の地域まで表示を移動させてください。少し待つとグリッドが表示されます。そのグリッドをクリックすると、その地域の編集が一覧化されます。

そこから、必要に応じてリバート作業などを行ってください。

教材となるリソース

OpenStreetMapのドキュメントは基本的にOSM wikiにまとまっていますが、OSM wikiはしばしば情報量が膨大で、チュートリアルなどの情報が埋もれてしまうことがあります。

以下に、よく使われるリソースをあげておきます。

どちらかというと、LearnOSMが初心者向け、Mapbox Mapping Guideが中級者以上のレベルを対象としています。ところどころ英語のままになっている部分がありますので、翻訳の協力をいただけると嬉しいです。

翻訳は、LearnOSMがTransifex経由、Mapbox Mapping GuideがGithubリポジトリから実施します。

ただし、LearnOSMの翻訳は文節の区切り精度ががあまりよくなく、リポジトリ管理者に都度訂正依頼を行いながら翻訳作業をする必要があります。
もし興味のあるかたがいらっしゃいましたら、ぜひお声がけください。

OpenStreetMapのコミュニケーションチャンネル

OpenStreetMapは地域によって、利用しているツールにかなりの違いがあります。
国際的なコミュニケーションをとる際には、いまだにメーリングリストがよく使われます。
メーリングリストとその履歴一覧はOSM wikiで公開されています。

日本地域では以下のコミュニケーションチャンネルが用意されています。
用途に応じて使い分けてください。

Talk-jaメーリングリスト: 最も「公式」に近いチャンネルです。どんな内容でも投稿することができますが、古くからのユーザも多く登録していることもあり、タグについての議論や広域編集に関する議論などはこのチャンネルがよいでしょう。
Twitterハッシュタグ #osmjp: 気軽な告知や質問、募集を行うのに便利なチャンネルです。
Facebook Group: こちらも気軽な告知や質問、募集を行うのに便利なチャンネルです。OSMのライトユーザ層も多く登録しているように感じられます。
OpenStreetMap Forum: 使われる頻度はあまり高くありませんが、OSM公式のフォーラムも用意されています。

他、OpenStreetMap Foundationの総会やHOTの会議などではMumbleというボイスチャットシステムが利用されているなど、IRCやSlack channelも含めて、普段のコミュニケーションツールは状況・チームに応じて使い分けられています。

各地のコミュニティで使われているツールは、こちらのリポジトリによくまとまっています。最近だと、Telegramなどもよく使われているようです。

OSM Community Index

コミュニティ用ページ：イベント告知など

OSM Foundation Japanは、OSM日本コミュニティのウェブページを運営しています。

・OSM日本コミュニティページ

このページはOpenStreetMapユーザ以外も参照する可能性が高いことが特徴です。

あなたがマッピングパーティの開催告知などを行う際、より広い対象への告知を行うため、osm.jpのページに告知を掲載することも可能です。
PeatixやConnpass、Facebookのイベントページなどを使って自身で別途イベントページを作成したうえで、OpenStreetMap Foundation Japan（info@osmf.jp）までご連絡ください。掲載を行います。

また、イベントに関しては、OSM wikiのイベントカレンダーに登録することで、WeeklyOSMなどの媒体に掲載されるようになります。

おわりに

OpenStreetMapは2004年にスタートし、既に14年間の歴史を持っています。

日本地域も2008年から活動をスタートしており、10年近い歴史があります。

その長い歴史のなかで、多くの議論が行われ、膨大な量のタグが使われてきました。しかしながら、使うことのできる情報源がGPSユニットと目視調査から航空写真の利用が可能になり、さらにインポートなどで利用できるデータソースが増えるに従って、地物をどのように描くことが最善なのかは時代に依って変化してきています。

また、タグの利用状況もそれにつれて変化してきていると感じています。

OpenStreetMapは生きており、そのなかで方向性を定め、お互いの規範を定めるのは、他でもなく、私達マッパー自身です。

そして実は、既に決まっていると思われているやり方も、いつでも見直しの可能性があり、新しい方法がありえると考えています。

メーリングリストでは毎日のように、新しい意見や質問が飛び交っています。

ここに書かれていることはあくまでも筆者個人の経験に基づいた参考情報でしかなく、常にブラッシュアップが必要です。

文章の内容や表現、より詳しい説明方法など、ご意見をいただければ幸いです。

初出: 技術書典3 
地図画像: © OpenStreetMap contributors, CC BY SA 2.0