From OpenStreetMap Wiki
Jump to: navigation, search
利用できる言語 — Vandalism
· Afrikaans · Alemannisch · aragonés · asturianu · Aymar aru · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · bamanankan · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · Latina · latviešu · Lëtzebuergesch · lietuvių · Limburgs · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · авар · Аҧсшәа · беларуская · български · қазақша · Кыргызча · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · भोजपुरी · मराठी · संस्कृतम् · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް

破壊行為(Vandalism)は OpenStreetMap コミュニティで合意された規範を意図的に無視することです。単純ミスと編集間違いは破壊行為ではありませんが、破壊行為の修正に使われるものと同じツールを使ってリバートする(訳注:編集を元に戻すこと)必要がある場合があります。


GPS 軌跡への落書き(3つの地名)。

もっとも素朴な感覚の破壊行為は、地図上に「落書き」をすることで、子供じみた悪戯の動機から行われること、意図的に OpenStreetMap に損害を与えるものもあります。純粋な破壊行為が行われることは比較的まれです。 OpenStreetMap は非営利のよい理想であり、地図データはコミュニティが「所有して」います。ほとんどの人がこれを尊重しています。


  • 著作権侵害
  • OpenStreetMap データベース内の紛争(編集合戦)
  • ウィキ上の紛争
  • ボットの不適切な使用
  • データの大掛かりな編集(タグの追加や変更など)
  • 繰り返される破壊的な行為
  • スパム
  • 正しいと考えられているデータの意図的な削除や退化
  • 議論されていないインポート



多くの国ではサイバー犯罪に対する法律があり、「コンピュータシステムのデータの改竄とそれによる損害の発生」などに対応しています。 OSM での破壊行為で裁判沙汰になったり有罪になったりした事件は認知されていませんが、 OSM に「落書き」をしつこく追加する人にも、それが OSM に損害を与える行為だと通告すれば、理論的には適用できます。


Detecting vandalism within OSM is a tricky situation as the types of vandalism above are wide ranging in type, extent, and effect. One of the easiest ways to detect vandalism is using the history tab on the main page and inspecting edits in a location--accomplished easier when looking at a limited area like a town or small municipality.

There are multiple approaches to automated vandalism detection that generally fall within two categories: changeset focused and user focused. But, as in the case of any detection system, either focus will often have false positives or miss "smart" vandals.


Changeset focused detection relies on scanning changesets for nefarious behavior by examining the metadata of the changeset and perhaps the actual objects or nature of tags used. One common method employs limits on the amount of objects edited, added, or deleted. An example program in pseudocode:
for changeset in diff file:
    if more than 1000 objects are added:
        flag as a potential import
    if more than 1000 objects are modified:
        flag as a potential mechanical edit
    if more than 1000 objects are deleted:
        flag as a potential vandal
This type of scanning lends itself to the idea that users generally do not edit a large amount of objects in every day mapping. But, in the above example, all events are flagged "potential" as there are often very reasonable explanations for performing so many actions (e.g. authorized imports, reversions of bad edits, etc.).

In the changeset approach, tags can also reveal potentially bad behavior. Listing copyrighted data as a source is usually a red flag, though some users unfamiliar with the source of default imagery like Bing may list a generic trademark (e.g. Google, Garmin) creating a false positive. Using very outdated or uncommon editors, adding very long tag values, including many extraneous changeset tags, and other behaviors are other examples of leveraging tags in detecting bad edits.

Another component of the changeset approach is examining the spatial characteristics of the objects in a changeset. Added or edited objects could be compared to samples of smiley faces, drawn out words, anatomical features, and doodles to test how similar they are to this list of graffiti.


User focused detection looks at the editing character of the individual. Did a user make 300 edits within 10 minutes of joining? Are all edits of a new user deletions? This detection aims to catch the behavior of the individual instead of the characteristics of the objects.




  • 全ての投稿者はいつでも良い、正確でよく調査された変更を試みようとしているはずだ、ということを念頭におくべきです
  • 我々はあらゆる投稿者はデータセットをより良くしようという(より悪くではない)バランスの上にいるということを確認する必要があります。もし投稿が疑わしいものであれば、相手の投稿者に調査と返信を依頼すべきです。
  • 我々は、人は誤りを犯すものであり、学習には時間が掛り、新しい参加者はしばしば手助けに反応するものだとということに目を向けるべきです。
  • 我々は投稿者に対して、変更セットにコメントを追加したり、その興味と知識についての詳細を個人ページに役に立つからと言って掲載してもらうようにお願いすることはできますが、強制することはできません。とはいえこれをやっていると、リバートをする必要が無く、必要な時にその個人が手助けされる傾向にあります。
  • 誰かが奇妙な編集をしているように思えた際には、最初に「良心(訳注:good faith)」を信じながらも、注意深く見守り、必要であれば他の人と議論すべきです。
  • もし、ウェイに対する編集の多くが悪意があったり、不快なものであったり、中傷であったりであることが明確に証明された場合や、これらがプロジェクトの信用を失墜させる可能性があれば、関連する変更セットは議論や変更セットを100%チェックすることなしに、直ちにリバートすることができます。
  • その編集が、疑わしいが正しくないと証明できない場合、その人に連絡をとり、詳しい話を聞くべきです。筋道だてた説明が無かったり(あるいは返事がなかったり)、疑わしい編集が引き続き行われ、あまり有益な投稿であると思えない場合には、少なくともひとつ、正しくない編集を証明し、他の人とその疑念のある、及び当人が作成した可能性のある全ての変更セットをリバートすることが適切であるかどうかを議論した上で決定すべきです。
  • いったん誰かが問題のある投稿者として識別されたら、それから先の変更セットをリバートする前に、まずは一連の編集を手短に検査すべきです。
  • もし問題が続くようであれば、「バーチャル・バン(訳注:仮アカウント削除)」します。この状態になると、当人がシステム管理者に連絡して、心を入れ換えたのでもういちどチャンスを欲しい、と言わない限り、変更のメリットを検査することなしにその編集がリバートされます。
  • もし誰かが世界のどこかで悪い編集を行ったら、世界中からの反応を期待できるでしょう。というのも、誰かがアイスランドにちょっかいを出す一方でアイルランドで良い編集を行い、現地の人たちの頭の中で何が起こるか私にはあまりよく分からない、ということは考えにくいからです。 —私は他人の良い作業を、何らかの良い編集もまた無意味なものと化してしまうめったにない機会に巻き込まれてしまう損傷から保護することを選ぶでしょう。
  • 他の人々の作業をリバートする人は、それがその問題に対して十分な理由に基づき、バランスの取れたものであることを示す用意がなければなりません。
  • 「null」編集 — 要素を「変更する」以外に目的がない編集 — は、誤りやエディタの都合で行われたり、エリアを更新するために有益であったりします。しかし、「null」編集を多用することは、混乱を招く行為だとみなされるでしょう。



リバートのログをセットアップするのは適切です。Within England/Wales/Scotland please put requests on the GB revert request log.


もし、ウェイに対する大多数の編集が完全に悪意があったり、不快なものであったり、中傷であったりということが証明されるか、プロジェクトの信用を失墜させると考えられる場合には、即座に反応することが重要であり、最初にリバートするのと並行してその投稿者に問いかけてください。同時にデータ・ワーキング・グループに連絡することも適切です。 Objects that have been touched since the initially bad edit may require using a complex reversion method, so if you are unfamiliar with these tools then seek assistance from the community or Data Working Group.


If, after contact has been made with the mapper via changeset discussions and/or messages, the mapper refuses to respond and does not alter their behavior, the Data Working Group may place a temporary block on the user in question. This is neither a presumption of guilt nor a banishment from the project. Rather, it is a measure to get the attention of the mapper as they must log in to the OSM site and read the block message before they can continue uploading edits through the API.

Blocks come in varied time lengths to expiration from 0 to 96 hours. They also have the capability to require a user to log in and read the block message before it is removed, regardless of expiration time. DWG members will often place a 0 hour block on an account with the block message read condition as an initial measure to unresponsive conflicting mappers. A history of blocks is available here.


See the OSM Foundation ban policy for more information.






主な記事:Data working group




  • White lists
  • Data rollback — Let the community run this task using tools that have been tested
  • Data deletion — Let the community run this task using tools that have been tested
  • Change rollback
  • History removal — Requires high level privileges
  • Rollbacks
  • Data with later history