小型版

すべての管理単位！すべてが湿っていて複雑です!!! しかし、今のところ!!!

ビッグバージョン

Mapzenは、管理ユニットの地理的ディレクトリを作成します。 すべてではありませんが、ほとんどの種、そしてほとんどの種が望んでいます。地理的ディレクトリは管理単位の大きなリストであり、各管理単位には永続的な識別子と、その場所を説明する多数のプロパティがあります。ハンドブックを行政単位を巡る議論が行われているが解決されていないスペースと考えることは興味深い。ディレクトリを「Who's On First」、または要するに「WOF」と呼びます。

Wikipediaによると、Who's on First：

...これは、アボットとコステロによって有名になったコメディシーンです。このプロットはアボットがコステロ野球選手と呼ぶものに基づいていますが、彼らの名前とニックネームはコステロの質問に対する無意味な答えとして解釈することができます。たとえば、一baseのプレーヤーは「Who」と呼ばれます。したがって、「一firstにいるプレイヤー」は、質問（「一firstにいるプレイヤーは誰ですか？」）と答え（「一baseにいるプレイヤーの名前はだれか」）の2つの方法で認識されます。「Who's On First」は、言葉と名前の戯曲を使用した前世紀初頭のバーレスクスケッチに由来します。たとえば、「The Baker Scene」（店舗はWatt Street（「What street」と一致）にあります）および「Who Dyed」（所有者の名前はWho（Who））です。 1930年のCracked Nuts映画では、コメディアンのBert WheelerとRobert Woolseyが神話の王国の地図を次のような対話で研究しました。「「どちらが？」（どの都市が？） 1930年代初頭の英国の音楽ホール（英国のボードビル劇場）では、コメディアンのウィルヘイが、ウェアから来たが現在はワイに住んでいる学生ハウに先生がインタビューするシーンで演奏しました。

この名前は、地理上の「問題」の1つを完全に強調しています。もちろん、世界を座標セットとしてのみ認識すれば十分です。しかし、私たちはこれを行うことができず、これが意味するすべての「管理ユニット」の負担は、今日まで私たちにかかっています。

私たちのガイドは完全ではありません（データカバレッジと品質の両方の面で）ので、近い将来、使用するときにあまり期待しないでください。

目標と意図を明確にするだけでなく、それらを具体的な結果に変えることが重要であるため、現在データを公開しています 。今日のこのブログ投稿とデータリリースは、最終目標ではなく、私たちの焦点を反映していると考えてください。

私たちのガイドは最初のものではありません（できれば最後ではありません）。私たちの前に多くのものが作成されました。それらの最も顕著なもの：

ゲッティ研究所地名シソーラス
Alexandria Digital Library
YahooのGeoPlanet
ジオネーム
ニューヨーク公共図書館（NYPL）と議会図書館（LoC）の共同による、歴史的な地理的ディレクトリの作成
新しく発表されたNYPL Space / Timeカタログ
ナチュラルアース
クワトロシェイプ

Quattroshapesをデータセットの基礎として使用します。これは、より多くの場所についてより多くの情報をより多く取得できるためです。

ライセンスが許可する限り、このセットをNatural Earth 、 GeoPlanet 、 GeoNamesおよびZetashapesプロジェクトの関連するジオメトリとメタデータで補完します。

この問題に精通している人は、おそらく、特定の種類の行政単位（世界中の多くの地域や農村集落）のカバレッジが不足すると、プロセス全体の開始が遅れることになると考えていますか？ 答えはイエスです。 短期的な目標の1つは、GeoPlanetセット内のどの管理ユニットに、Quattroshapesの対応する対応ユニットがないかを見つけることです。 リストを受け取ったら、これらのユニットの名前と階層をGeoPlanetからインポートできるようになり、データカバレッジがすぐに改善されます。 確かに、多くのユニットはインポート中に座標を失いますが、この問題は時間とともに解決されると確信しています。

私たちは、全世界に関する包括的なオープンデータセットを作成するための最初の探求ではありません。このような各プロジェクトは、この共通の原因に対する独自の貢献であると考えており、これらの貢献を組み合わせることにより、単なる合計以上の何かを生み出し始めたいと考えています。

すべてのデータは、 Creative Commons Zeroライセンスの下で利用可能です。

私たちが使用する多くのオープンソースには帰属が必要です。これらのソースをここにリストしました。

巨大なバージョン

巨大なバージョンは巨大です。自分でコーヒーを飲むのは理にかなっていますが、私たちと同じジャングルに登るならもっと強いものにしよう。

結局のところ、地理的参照とは何ですか？

前述したように、地理ディレクトリは管理単位の大きなリストであり、各管理単位には永続的な識別子と、その場所を説明するいくつかのプロパティがあります。ハンドブックを行政単位を巡る議論が行われているが解決されていないスペースと考えることは興味深い。

このアイデアの最も単純で友好的な表現は、人々が同じ地域にどのように名前を付けることができるかを考えることです。時々、2人がこの場所を同じと呼びますが、異なる方法で書き留めます。ジオコーダーが依然としてクエリの正確さを維持していること、および誤ったクエリが入力された場合にどれだけ面白いかを思い出してください。次に、これに世界のすべての言語の数を掛けます。

ガイドの目的を説明する最も簡単な方法は、スペルミスの問題を解決するということです。すべての地域に単純な（多くの場合、数値であるが最も重要な定数）識別子がある場合、この識別子を使用して、可能なコンテキストで同じ地域を参照できます。また、言語学的な知恵を考えれば、膨大な時間を無駄にしないでください。

たとえば、都市を「モントリオール」（英語）と呼び、「몬트리올」（韓国語）と「モントリオール」（フランス語）または「MTL」（国際）などの名前を付けることができます。削減）など。したがって、ガイドが、1つの行政単位（または、楽しみのために、すべての人が同意した1つの幻覚）のこれらすべての表現が共存できるスペースであったら、素晴らしいでしょう。

ハンドブックは議論のために存在しているというより複雑な考えを伝えるために、「行政単位」は社会的、政治的、そしてしばしば非常に感情的なレベルでしばしば論争の対象になるため、大きな問題であることを思い出すことができます。この問題は新しいものではありません。人々は、自分自身を覚えている限り、所属のビジョンと領土の境界線のために議論し、時には戦います。

単一の本ではなく、単一の段落でも、単一の文でも、長年にわたって異なる心を持っている、しようとしていない、または特定の領域で共通の意見になりたくない。おそらくこれは役に立たないかもしれませんが、キーと値のペアのリストは、そのような領域のすべてのニュアンスを修正するために作成され、どれだけ完全でなくても、長期にわたる紛争の解決に役立つと信じたいと思います。

基本原則

このガイドは、いくつかの基本原則に基づいています。

Mapzenには意見がある

Mapzenが特定の各管理単位についてではなく、そのような単位の性質について意見を持っていることが重要です。この必要なポイントは境界の概要を示し、プロジェクトが何であり、何が重要で、何がそうでないかを理解させてくれます。

プロジェクトの境界内にあるすべての視点を反映

世界は複雑なものであり、地理的ガイドは、この世界についての意見の矛盾、時には矛盾した意見の一種であると考えています。特定のユニットについて、アプリケーションやユーザーに対してできるだけ多くの意見や決定を反映するつもりです。特定の条件でこれがどのように現れるかはまだ不明ですが、私たちは自分自身に目標を設定しています。

可動性

管理ユニットに関する正規の情報ソースは、一意の64ビット数値IDを持つGeoJSONテキストファイルです。すべてのコンピューターは、テキストファイルと数字で動作できます。テキストファイルは、古いテキストエディタで表示または調整できます。テキストファイルはプリンターで印刷できます。番号は、データベースによって迅速かつ簡単に索引付けされます。

テキストファイルを使用するのは、データにとって特に重要であるためです：時間の経過に伴う使いやすさ、信頼性、移植性。古き良きテキスト形式の利点は、他のオプションの利点を上回ります。

たとえば、Googleのプロトコルバッファーは優れていますが、使用するには他の多くのGoogleプログラムが必要です。 ESRIのShapefilesも素晴らしいです。その普及率と長い歴史はフォーマットの利便性を裏付けていますが、少し編集するために特別なプログラムをインストールする必要もあります。

これは、テキストファイルまたは静的ファイルが最良の選択であることを意味するものではありません。すべては特定のタスクに依存し、必要に応じて、すべてのデータをより軽量で便利な形式に変換しますが、単純なテキストファイルに常にアクセスできます。

ジオソン

GeoJSONは、2つの補足的な理由から主要な交換フォーマットとして使用されます。

現時点で最小限のマークアップを持つこのデータ構造。誰かがより簡潔なマークアップ言語を思いついたら、それに切り替えます。
GeoJSONを操作するためのツールは多数ありますが、重要なことは、使用されている他のすべての形式に変換することです。

詳細を教えてください（複雑なこと）

単純なもの（名前、ジオメトリ、およびそれらに関連する必要最小限のプロパティなど）に興味がある場合は、さらにスクロールします。

コンプライアンス

他のディレクトリを処理する場合（および使用可能なすべてのディレクトリとのやり取り：廃止、現在、および計画の両方）、それらの間の対応を探すことから始めるのが良いオプションです。

この場合の対応は、例えば、「彼らのボストン」と「私たちのボストン」が同一であることを主張する根拠です。それらの詳細は、他のタスクやビューによって完全に異なる場合があります。異なる視点を持つことは良いことです。通信により、誰もが他の人の仕事を考慮し、相互作用のメカニズムを提供して、彼が興味を持っているものを扱うことができます。

各WOFレコードには、キーと値のペアの形式でwof:concordances

プロパティがあります。これは、他のデータベース内の同じオブジェクトへのポインターのリストです。例：

 "wof:id": 101736545, "wof:concordances": { "fct:id": "03c06bce-8f76-11e1-848f-cfd5bf3ef515", "gn:id": "6077243", "gp:id": "3534" }

この発行時点で、GeoNames（159,359オブジェクト）、GeoPlanet（135,399）、QuattroShapes（115,550）、Factual（80,973）、さまざまな空港分類子（ICAO、IATA、FAA、OurAirports）、Wikipedia（これまで空港のみ）、およびMapzen Border国でさえ。もっとすぐに来る。

管理単位のタイプ

管理ユニットの階層については、3つの「クラス」を特定しましたが、その1つはどのタイプのユニットにも属することができます。これは、他のクラス（または管理単位のタイプ）が存在できないことを意味するものではありません。このようなセットから始めることにしました。

共通（C）

これらのユニットは、Who's On Firstのすべての階層とすべての管理ユニットに共通です。

重要なポイント：これは、すべてのオブジェクトがこのクラスの1つ以上の共通の上位オブジェクト（たとえば、国、大陸、または単に惑星地球）を持たなければならないことを意味します。これは、既存の共通階層に適合するために、特定の場所の階層への特定の追加を妨げません。

共通オプション（CO）

このクラスのユニットは、一般的な階層の一部として暗示されていますが、適切でないため、またはそのようなデータがないために存在しない場合があります。このタイプの例は郡です。

オプション（O）

階層のこれらの部分は、通常、特定の国または地域に固有です。たとえば、フランスまたはドイツの多くのネストされた部門。唯一のルール：オプション（O）タイプは、一般（C）階層内のどこかになければなりません。

最も一般的な階層の管理単位タイプの最小リストは、次のようになります。

 -大陸（C）
   -国（C）
     -地域（C）
       -「郡」（CO）
         -地域（C）
           -近所（C）

より詳細なバージョンは次のとおりです。

 -大陸（C）
   -帝国（CO）
     -国（C）
       -地域（C）
         -「郡」（CO）
           -「メトロエリア」（CO）
             -地域（C）
               -マクロフッド（O）
                 -近所（C）
                   -マイクロフード（O）
                     -キャンパス（CO）
                       -建物（CO）
                         -アドレス（CO）
                           -会場（C）

サイト！建物!!! 微小地区 !!! 帝国!!!

非常に多くの新しいタイプがありますが、それだけではありません。これまでのところ、一般的なスケルトンのみが表示されます。 GitHubには、上記の各タイプに関するディスカッション（および正規リンク）を含む、タイプ専用のリポジトリ全体があります。

階層

Who's On Firstの階層はリストとして表示され、その各要素は完全な階層を含むディレクトリです。ここのように：

 "wof:hierarchy": [ { "country_id": "85633147", "region_id": "85683255", "county_id": "102072387", "locality_id": "101750223", "neighbourhood_id": "85794581" } ]

これは、Who's On Firstの地形が複数の異なる階層に属することができるという事実によるものです。たとえば、都市集積（サンフランシスコ内およびその周辺の「サンフランシスコ湾岸地帯」、5つの地区すべて、さらにはニュージャージー州の一部を含む「ニューヨーク」など）のタイプを考えます。同じタイプ。再び紛争地域。この決定に至った理由と方法は、別の記事のトピックですが、要するに：

このソリューションが優れている理由：

それは視覚的です
複数の階層を簡単に比較できます
ユーザーが過度の頭脳を使って階層全体を復元したり、訪問したばかりの次の「洞察」をサポートしたりする必要はありません。
開発プロセスの変更が容易になります（...「公式」の開始前に宣言します）

なぜこの解決策が悪いか、または悪いようです：

都市の集積をサポートする場合、他の多くのユニット（近隣、地区、サイト）が複数の階層を持つことができ、一部の地区はすべての親ユニットを超えて広がることを意味します
ファイルサイズ、ディスク容量、チャネル幅-これらはすべて最初の段落の結果であり、GeoJSONファイルの小数点以下6桁以上のスペースと座標に似ています。

紛争地域

すべての地域と多くの入植地は友好的な冗談のレベルで「論争」されていますが、2つ以上の州が関与しているため、一部の領土をめぐる紛争は非常に深刻な変化をもたらします（そして、いわゆる国際法の非国家主題）。そのような論争は、「友好的な冗談」とはほど遠い、暴力と結果に満ちています。

異議申し立てのステータスの期間中、異議を申し立てられたタイプをそのような地域に割り当てます。紛争地域は、定義により、その階層に2つ以上の親の状態があります。このアプローチは、各紛争の状況のすべての事実を反映していません。一方、上記のように、論争の当事者を強調し、タスクのコンテキストで論争を反映する方法について決定を下すことができます。

親IDと親の権利

テリトリーが異なる階層に属することができたとしても、ほとんどの場合、1人が事実上「制御」されていることを意味します。たとえば、ゴラン高原はシリアとイスラエルによって争われており、これは階層に反映されていますが、依然としてイスラエルの管理下にあります。

 "wof:hierarchy": [ { "continent_id": "102191569", "country_id": "85632315", "disputed_id": "85632221" }, { "continent_id": "102191569", "country_id": "85632413", "disputed_id": "85632221" } ], "wof:id": "85632221", "wof:name": "Golan Heights", "wof:parent_id": "85632315",

場合によっては、紛争が最近始まったので、誰が領土を管理しているか、またはそれについて確信がないと言うことができず、まだデータを確認しています。次に、親レコードを-1に設定します。

割り当てて-2が発生します。これは「：肩をすくめる：世界は難しいものだ」と解釈されるべきです。たとえば、カザフスタンのバイコヌール宇宙基地。

代替/交換可能

地理を扱う際に生じる大きく複雑な哲学的質問の1つ： 単純な調整と根本的な変化を区別する方法は？

この問題は単なる地理的なものではありませんが、地理学では目障りです。たとえば、ポーランド、フランス、ドイツは、1つの領土を割り当てて、降伏させました（何百年もの間）（場合によってはその後の割り当てがあります）。それらの境界、および境界の存在期間は、地図作成のためだけでなく、活動の他の多くの領域にとっても重要なコンテキスト情報です。領土がポーランドに属していたときに準備ができていたが、領土がドイツに属していたときに作成された芸術作品を取ります。変化する地形をどのように着実に特定しますか？

別の例。ニューヨーク市には、BoCoCaと呼ばれる非常に厳しい地区があります。 BoCoCaは、ブルックリンのビジネスセンターの南にある3つの近くの地区であるBoerum Hill、Cobble Hill、およびCarroll Gardensの略です。 BoCoCaは、通常の意味での名前でも、ほとんどの人が考える地区でもありません。一方、多くのマップおよびデータセットでは、これがエリア（および名前）です。考えがどうであれ、BoCoCaは「存在します」。

Who's On Firstでは、BoCoCaを「マクロ地区」にしました。これには、その名前の由来となる3つの地区が含まれます。

管理単位のタイプは非常に重要なプロパティであり、さまざまなアプリケーションで明らかに使用されています。アプリケーションが地形に関連するプロパティを処理する方法や理由を知る必要はありません。そして、このWOF ID 85892915をエリア（Quattroshapesからインポートしたときのエリア）と見なすことにした場合、 おそらく左ヒールの要求に応じて、それほど簡単に変更すべきではありません 。

確かに、BoCoCaを領域とは見なしません。これについては確固たる意見があります。 BoCoCaは地区と見なされますが、私たちの観点からは、もはやそうではありません。このような問題を解決する方法は、新しいタイプ（BoCoCa-マクロ）で新しいレコードを作成し、残りのレコードを調整して、あるレコードが別のレコードに置き換えられることを示すことです。

たとえば、地区としてのBoCoCaのエントリは次のようになります。

 "wof:superseded_by": [102147495], "wof:supersedes": [],

マクロ地区としてのBoCoCaは次のようになります。

 "wof:superseded_by": [], "wof:supersedes": [85892915]

置き換えられたオブジェクトを個別に説明する方法（およびその有無）を決定するのはアプリケーションです。たとえば、検索エンジンは、置換されたオブジェクトを個別にランク付けしたり、処理から完全に除外したりできます。

違反

各エントリにはwof:breaches

リストがwof:breaches

。この記事を読む時点では、これらのリストのほとんどはまだ空である可能性があります。「違反」は、あるユニットのジオメトリが同じタイプの別のユニットのジオメトリと交差するときに発生します。

これらのリストは、データにエラーがあるという事実（原則として、国の国境は隣接する国境を越えない）と、領土の境界（たとえば、地域）に関する意見の相違があるという事実について、Who's On Firstユーザーへのシグナルとして使用されます。

他の多くの信号と同様に、その値、重要性、処理方法はエンドアプリケーションの裁量に任されています。

もっと教えて（簡単なこと）

「単純なもの」の意味を思い出してください...

お名前

すべてのアイテムは、元々QuattroshapesおよびNatural Earthキットから取得されました。ただし、GeoPlanet（GP）は一般に多言語および口語名の点で優れています。

GPには、命名のための2つのプロパティがあります。

言語コードISO 639-3
GPの優秀な人々によって編集された、よく知られた説明のリストからの「タイプ」という名前：

Name_Typeフィールドは、次の値をとる1文字のコードです。

P-英語の優先名
Q-他の言語の優先名
V-一般的な（ただし非公式）名前の変形（たとえば、ニューヨークの場合は「ニューヨークシティ」）
S-同義語または口語名（ニューヨークの場合は「ビッグアップル」）
Aは管理単位の略語またはコード（ニューヨークの場合は「NYC」）

GPはまた、 name

とalias

区別し、それらの世界では以下を見つけることができます：

名前：モントリオール
言語：FRE
エイリアス（ENG_P）：モントリオール
エイリアス（KOR_Q）：몬트리올

GPは、一部の国にいくつかの公用語があることを考慮していません。私たちはこれらすべてについて考え、決定しました：

いくつかの言語の名前と、名前の座標を指定する機能をサポートする必要があります
優先名には、言語に関係なくp

のみを使用します
name

空間を使用する方が便利です。 name

空間を使用する必要があります。

例：

 { "wof:lang": ["eng", "fre"], "name:eng_p": "Montreal", "name:eng_a": "YMQ", "name:fre_p": "Montréal", "name:kor_p": "몬트리올", }

幾何学

コンセンサスジオメトリ

各管理単位には、1つの「コンセンサス」ジオメトリがあります。「コンセンサス」の概念はまだ定義されていません。とにかく、この言葉の使用には問題がたくさんあります。より正確な用語に置き換えられます。

すべての「その他」のジオメトリ

また、各ユニットには、異なる名前のジオメトリを持つ「代替」ファイルがあります。物議を醸す単純化されたジオメトリを格納するか、特定のタスク（ジオコーディングなど）向けに最適化することを想定しています。

ここでの主なこと：アカウントのすべてのジオメトリを取得する。

ジオメトリソース、コンセンサス（sic）または代替は、各エントリに含まれます。例：

 { "src:geom": "zetashapes", "src:geom_alt": ["quattroshapes", "naturalearth"] }

重心

各レコードは複数の重心を持つことができます。「複数の重心」の組み合わせは、矛盾語のように聞こえます。「重心」という用語は、任意のジオメトリの焦点領域を示します。異なる重心は、使用タイプを示すプレフィックスで示されます。例：

geom:latitude

とgeom:longitude

は、数学的魔法を使用して取得したコンセンサスポリゴンの中心です。
lbl:latitude

とlbl:longitude

は、最適な命名lbl:longitude

座標です。たとえば、サンフランシスコの埋め立て地にはファラロン諸島が含まれています。これは、この埋め立て地の「中心」が太平洋にあることを意味しており、これは名前を付けるのに最適な場所ではありません。
nav:latitude

とnav:longitude

は、ナビゲーターが表示するポイントです。たとえば、同じ場所に到着するトラックの荷台ではなく、救急ステーションの入り口。

最低限必要なプロパティ

Flickr APIは、 「写真に関連するリクエストに対してAPIが返す必要がある最小のデータセットは何ですか？」という原則に従って設計されています。

Flickrの答えの本質は、「写真の標準結果」、つまり「最小データセットでは、Flickrの写真ページを指すURLをロード/構築できる必要があります」に記載されています。

Mapzenの場合、この質問に対する答えは、 「データセットにより、API応答をマップに表示できるようにする必要があります 。」

たとえば、 Pelias （またはその他のAPI）から応答を取得し、それをGeoJSON

レイヤーとしてLeafletに転送して、マップで結果を確認することが可能です。

これらすべてを考慮すると、「プロパティの最小セット」は次のようになります。

 { "wof:id": 85922583, "wof:name": "San Francisco", "wof:fullname": "San Francisco, California US", "wof:placetype": "locality", "wof:parent_id": 85688637, "wof:quality": 9, "wof:score": 100 }

上記の例に関するいくつかの言葉：

「プロパティ」とは、ジオメトリではなく、このエリアに関連付けられたメタデータを意味します。
wof:score

プロパティは、Peliasチームの部隊によって決定される検索ランクと同等と見なされる必要があります。同様に、 wof:quality

は、データチームによって定義された品質/信頼性ランクに相当するものと見なされる必要があります。

未来の魔法（開発中）

次は、現在サポートされていないプロパティのリストです。サポートされていないということは簡単です。これらのプロパティについては、将来サポートする必要があります（今後サポートされる予定です）のでお話します。

ランク（s）

品質

この記録のデータは、私たちの意見ではどの程度完全であるか信頼できるか

カバレッジ

「カバレッジ」とは、地形レコードが持つ属性の数を意味します。レコードには、公式名と代替名の素晴らしいセットがありますが、メタデータ（人口、身長など）はほとんどないためです。

日程

設立日、または場合によっては行政単位の廃止日はいつですか？この情報は、あるレコードが別のレコードを置き換えることができるデータセットで特に重要になります。

一般的に、日付はかなり不均一な空間であり、単純な形式から始めて、歴史的現実と現代の現実を記述する複雑さを徐々に増やしていきます。米国議会図書館は、拡張された日付/時刻形式（EDTF）に取り組んでいます。この問題に関心がある場合は、それを感じることは理にかなっています。

待ってください...どこからこのデータを入手できますか？

私たちが理解することを要求する最初の（そして非常に非常に重要な）-Who's On Firstはまだ開発中です。

データの一部（おそらく多く）が正しくありません。
いくつかのことが欠けています。不足しているものもありますが、それらについては知らないことがわかっているため、すぐに対処します。不足しているものがいくつかありますが、それらについて知らないので、エラーを検出したときに対処します。
パラグラフ1の理由により、データの一部（おそらく大きな）が何らかの形で変更されます。
単一のレコードを調整するには、それに関連付けられているレコードを更新する必要があります。関連するレコードを更新するためのツールはまだ正式化も最終化もされていません。これは、短期的には、関連するレコードとの矛盾が発生する可能性があることを意味します。それを理解します。

現在のリリースの目的は、すばらしいデータの新しい夜明けを発表して発表することではなく、私たちが話したことをすべての人に記入し、仮説を確認または反論できるデータセットを用意し、これらのデータを扱う実践についての教育プログラムを提供することでした。

あなたが私たちと同じわずかに暴力的な熱意で困難を乗り越えるのに十分な時間または気質（個人的または集団的）がない場合、おそらくあなたが私たちのデータに入るのは早すぎます。引き続き情報を提供し、プロジェクトに関するオープンな議論に参加していく予定ですので、ブログにご期待ください。改善すべき点をお知らせください。

GeoJSON形式の生データは、AWS S3パブリックアクセスポイントと小さなファイルがたくさんあるGitHubリポジトリの2つの場所にあります。それぞれのURL：

注：上記のS3へのリンクはアクセスポイントであるため、ブラウザーで開く必要はありません。S3を使用できるのはS3で作業できる人だけです。 これらの単語が鳥の言葉である場合、S3へのリンクをクリックする必要はありません。 GitHubへのリンクをすぐにたどってください。

データを表示するための公開ツールはまだありません。 Who's On Firstデータを操作するためのライブラリと共に）コードを開く予定の内部 "caver"がありますが、現時点ではまだ発生していません。

GitHubリポジトリには、 meta

という名前のスマートなディレクトリに「メタ」ファイルもあります。これらのほとんどは、特定のタイプの管理単位に関する最小限のデータを含むCSVファイルです。他のすべてと同様に、 meta

ファイルは開発中ですが、セット全体をデータベースにロードせずにデータを表示する最小限の機能を提供します。

あなたは言った...「サイト」？

はいこのリリースにはサイトは含まれていませんが、現在作業中です。会場は、Who's On Firstの非常に大きな部分を占めていますが、それらは複雑または多数であり、多くの場合一度にすべてを占めます。したがって、単純なものから複雑なものに移行します。

Git（およびGitHub）について一言

GitHubのWho's On Firstデータ（およびGit全体）に縛られることを強くお勧めします。現時点では、データを共有し、同時にコミュニティからの修正や提案を受け入れる最良の方法についてはほとんど考えていません。

GitHubの良き人々が優れた仕事を続け、Gitを使いやすくしているという事実にもかかわらず、現実はGitが多くの人々にとって障壁のままであることを示しています。代替案に関するより正式な決定がない場合、少なくともGitHubを使用すると、主な希望を概説できます。

人々がダウンロードして使用できる、オープンで簡単に配布されるデータセット。
誰でも地形データを調整し、より深刻な変更を加えることができます。
データの変更を制御する機能。
変更ログを保存する場所。

繰り返しになりますが、Who's On Firstのデータを操作しているときにGitに完全にアタッチしないでください。彼はプロジェクトのアイデアを示すために必要です。

次は？

多くの作業が残っています。

詳細：Who's On Firstデータを操作するためのツールとライブラリのリリース、データを掘り下げて検証し、データに基づいてプロトタイプサービスを作成するために使用する内部洞窟学者Webアプリケーションのリリース、完了（および場所によっては、開始）上記のすべてを文書化し、すべてのバグを修正します。

退屈しないでください！

アーロン・コープによる画像。

「誰がベースにいるのか」-Mapzenの新しい地理ディレクトリ

小型版