Маленькая версия

Все административные единицы! Пока всё сыро и сложно!!! Но это пока!!!

Большая версия

Mapzen создаёт географический справочник административных единиц. Не то, чтобы всех, но подавляющего большинства, и, мы надеемся, большинства их видов. Географический справочник — это большой список административных единиц, каждая из которых имеет постоянный идентификатор и некоторое количество свойств, описывающих их местонахождение. Интересно рассматривать справочник как пространство, где дебаты вокруг административных единиц ведутся, но не решаются. Мы называем наш справочник «Who’s On First» (Кто на первой базе), или короче — «WOF».


Согласно Википедии, Who’s on First:

… это комедийная сцена, ставшая знаменитой благодаря Abbott и Costello. Сюжет основан на том, что Abbott называет Costello бейсболистов, однако их имена и прозвища могут быть интерпретированы как ничего не значащие ответы на вопросы Costello. Например, игрока на первой базе зовут «Кто»; по этому на слух «Кто на первой базе» воспринимается двояко как вопрос («Какой игрок на первой базе?»), так и ответ («Имя игрока на первой базе — Кто»). «Who’s On First» исходит из бурлескных скетчей начала прошлого века, в которых использовалась игра слов и имён. К примеру, «The Baker Scene» (магазин находится на Watt Street (созвучно с «Какая улица»)) и «Who Dyed» (владельца зовут Who (Кто)). В фильме Cracked Nuts 1930 года комики Bert Wheeler и Robert Woolsey изучали карту мифического королевства с приблизительно таким диалогом: «- Какой за Которым?» (Какой именно город находится за Которым?) «- Да». В английских мюзик-холлах (британский аналог водевильских театров) начала 1930 годов комик Will Hay играл в сцене, где учитель собеседует ученика Howe, который приехал из Ware, но сейчас живёт в Wye.

Название прекрасно подчеркивает одну из «проблем» в географии. Конечно, было бы проще, если бы нам достаточно было воспринимать мир лишь как набор координат. Но мы так не можем, и бремя «административной единицы» со всем, что под этим подразумевается, лежит на нас по сей день.

Наш справочник весьма далёк от завершённости (и в плане покрытия данными, и в плане их качества) так что в ближайшем будущем не стоит ожидать многого при его использовании.

Мы публикуем данные уже сейчас, потому что нам важно не просто проговаривать свои цели и намерения, но и превращать их в ощутимые результаты. Считайте эту запись в блоге и релиз данных сегодня как отражение направления наших усилий, а не конечную цель.



Наш справочник не первый (и не последний, надеемся). Множество создано до нас. Наиболее заметные из них:

• Тезаурус географических названий института Getty
• Александрийская цифровая библиотека
• GeoPlanet от Yahoo
• Geonames
• Совместный вклад Нью-Йоркской публичной библиотеки (NYPL) и Библиотеки Конгресса (LoC) в создание исторического географического справочника
• Недавно анонсированный NYPL Каталог пространства/времени
• NaturalEarth
• Quattroshapes

Quattroshapes мы используем как основу для своего набора данных, поскольку он имеет больше всего информации о большем количестве мест в течение большего времени.

Этот набор мы дополняем релевантными геометриями и метаданными из проектов Natural Earth, GeoPlanet, GeoNames и Zetashapes, насколько это позволяют их лицензии.

Люди, хорошо знакомые с проблемой, вероятно, думают: Не значит ли это, что скудность покрытия определённых типов административных единиц (множество районов и сельских населённых пунктов по всему миру) будет оттягивать начало всего процесса? Ответ: да. Одна из наших краткосрочных целей — выяснить, каким административным единицам в наборе GeoPlanet не хватает соответствующего аналога в Quattroshapes. Получив их список, мы сможем импортировать наименования и иерархии для этих единиц из GeoPlanet, и покрытие данными сразу улучшится. Правда, многие единицы потеряют координаты во время импорта, но мы уверены, что эта проблема решится со временем.

Мы не первые в своём стремлении создать всеобъемлющий открытый набор данных обо всём мире. Мы рассматриваем каждый подобный проект как уникальный вклад в это общее дело, и, объединяя эти вклады, мы надеемся начать создавать нечто большее, чем просто их сумма.

Все данные доступны по лицензии Creative Commons Zero.

Некоторое количество используемых нами открытых источников требуют указания авторства. Мы перечислили эти источники здесь.

Огромная версия

Огромная версия огромна. Есть смысл приготовить себе чашечку кофе, а может и чего покрепче, если вы полезете в те же дебри, что и мы.

В конце концов, что есть географический справочник?

Как мы говорили ранее, географический справочник — это большой список административных единиц, каждая из которых имеет постоянный идентификатор и некоторое количество свойств, описывающих их местонахождение. Интересно рассматривать справочник как пространство, где дебаты вокруг административных единиц ведутся, но не решаются.

Самое простое и дружелюбное выражение этой идеи — рассмотрение того, насколько по-разному люди могут называть одну и ту же местность. Порой два человека называют это место одинаково, но записывают его по-разному. Вспомните, как педантичен до сих пор геокодер к правильности запросов, и как забавно бывает, если введён некорректный запрос. А теперь умножьте это на количество всех языков в мире.

Проще всего объяснить цель справочника, сказав, что он решает проблему неверного написания. Если всякая местность имеет простой (часто числовой, но главное, чтобы постоянный) идентификатор, то вы и я можем сослаться на одну и ту же местность в любом возможном контексте, пользуясь этим идентификатором. И не терять кучу времени, учитывая лингвистические премудрости.

Например, я могу назвать город «Montreal» (по-английски), а вы его назовёте, скажем, «????» (по-корейски) а кто-то ещё — «Montreal» (по-французски) или «MTL» (международное сокращение) и так далее. Так вот, было бы здорово, если бы справочник был тем пространством, в котором все эти представления одной административной единицы (или, шутки ради, одной всеми согласованной галлюцинации) могли сосуществовать.

Чтобы передать более сложную идею о том, что справочник существует для проведения дебатов, можно вспомнить, что «административная единица» — это большая проблема, поскольку нередко она становится предметом спора на социальном, политическом и часто очень эмоциональном уровне. Эта проблема не нова. Люди спорят и, порой, воюют за своё видение принадлежности и границ территории столько времени, сколько они себя помнят.



Ни в одной книге, ни в одном абзаце, ни в одном предложении различные умы на протяжении стольких лет всё ещё не могут, или не пытаются, или не хотят прийти к общему мнению по определённой территории. Возможно это… бесполезно, но хочется верить, что какой-то список пар «ключ — значение», не важно, насколько полный, созданный в попытке зафиксировать все нюансы такой территории, поможет в разрешении долготекущего спора.

Основные принципы

Справочник основан на ряде основных принципов:

Mapzen имеет мнение

Важно, что Mapzen имеет своё мнение не по каждой конкретной административной единице, но о природе единицы как таковой. Этот необходимый момент очерчивает нам границы и даёт понимание, чем наш проект является и, что критично, чем он не является.

Отразить все точки зрения, которые входят в границы проекта

Мир — сложная штука, и мы бы хотели, чтобы географический справочник был своего рода подмостками для, иногда противоречивых, мнений об этом мире. Мы намерены отразить столько мнений или решений по конкретной единице, сколько сможем, для приложений и пользователей. Как это будет проявляться в конкретных условиях еще предстоит увидеть, но цель мы себе поставили.

Перемещаемость

Канонический источник информации об административной единице — текстовый файл GeoJSON с уникальным 64-битным числовым ID. Все компьютеры могут оперировать текстовыми файлами и числами. Текстовые файлы можно просмотреть или скорректировать в любом старом текстовом редакторе. Текстовые файлы можно напечатать на принтере. Числа быстро и просто индексируются базами данных.

Мы используем текстовые файлы, потому что для наших данных особенно важны: простота использования, надёжность и перемещаемость в течение долгого времени. Преимущества старого доброго текстового формата перевешивают преимущества других вариантов.

Например, Protocol Buffers от Google прекрасны, но для использования они требуют установить много других программ Google. Shapefiles от ESRI так же замечательны, их распространённость и большая история подтверждают удобство формата, однако и для них нужно ставить специальные программы даже ради маленькой правки.

Это не значит, что текстовые или статические файлы — самый оптимальный выбор. Всё зависит от конкретных задач, и, если потребуется, мы переведём все данные в более легковесный и удобный формат, но доступ к простым текстовым файлам у вас будет всегда.

GeoJSON

Мы используем GeoJSON как первичный формат обмена по двум взаимодополняющим причинам:

• Эта структура данных с минимумом разметки на данный момент. Если кто-то придумает более лаконичный язык разметки, мы перейдём на него.
• Есть множество инструментов для работы с 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 countries. Скоро будет ещё больше.

Типы административных единиц

Для любой иерархии административных единиц мы определили три «класса», одному из которых может принадлежать какой-либо тип единиц. Это не значит, что не может быть других классов (или типов административных единиц). Мы просто решили начать с такого набора.

Common ( C )

Эти единицы общие для всех иерархий и всех административных единиц в Who’s On First.

Важный момент: это значит, что любой объект должен иметь один или более общий вышестоящий объект такого класса (например страну, или континент, или порой просто планету Земля). Это не препятствует специфическим дополнениям в иерархию для определённого места, чтобы вписать его в уже имеющуюся общую иерархию.

Common-optional ( CO )

Единицы такого класса подразумеваются как часть общей иерархии, но могут отсутствовать, потому что не уместны, или у нас нет таких данных. Пример такого типа — округ.

Optional ( O )

Эти части иерархии специфичны, как правило, для определённой страны или региона. Например, множество вложенных департаментов во Франции или Германии. Единственное правило: опциональные ( O ) типы должны быть где-то внутри общей ( C ) иерархии.

Минимальный список типов административных единиц для самой общей иерархии выглядит примерно так:

- continent (C)
  - country (C)
    - region (C)
      - "county" (CO)
        - locality (C)
          - neighbourhood (C)

Более подробная версия может быть такой:

- continent (C)
  - empire (CO)
    - country (C)
      - region (C)
        - "county" (CO)
          - "metro area" (CO)
            - locality (C)
              - macrohood (O)
                - neighbourhood (C)
                  - microhood (O)
                    - campus  (CO)
                      - building (CO)
                        - address (CO)
                          - venue (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 может входить в несколько разных иерархий. Взять к примеру такой тип как городская агломерация («Область залива Сан-Франциско» внутри и вокруг Сан-Франциско, «Нью Йорк», включающий в себя все пять районов и даже части Нью Джерси и так далее), в который часто входят единицы такого же типа. Спорные территории, опять же. То, почему и как мы пришли к такому решению — тема для отдельной статьи, но если коротко:

Почему это решение хорошее:

• оно наглядное
• легко сравнивать несколько иерархий
• оно не требует от пользователя излишне напрягать мозги, чтобы восстановить полную иерархию или обеспечить поддержку очередного «озарения» которое нас только что посетило
• проще вносить изменения в процессе развития (… заявляем мы до «официального» запуска)

Почему это решение плохое, или кажется плохим:

• если мы поддерживаем городские агломерации, значит и множество других единиц (окрестности, районы, площадки) могут иметь несколько иерархий, где какой-нибудь округ простирается за пределы всех родительских единиц
• размер файла, дисковое пространство, ширина канала — всё это последствия первого пункта и сродни пробелам и координатам с > 6 десятичными знаками в файлах GeoJSON, которые могут быстро потяжелеть

Спорные территории

Хотя все районы и множество населённых пунктов «оспариваются» на уровне дружеского стёба, споры о некоторых территориях принимают весьма нешуточный оборот, поскольку в них вовлечены два и более государств (и иногда, так называемые, негосударственные субъекты международного права). Подобные споры чреваты насилием и последствиями, далёкими от «дружеского стёба».

На время действия спорного статуса мы присваиваем таким территориям тип disputed. Спорные территории по определению имеют в своей иерархии два и более родительских государств. Данный подход не отражает все факты сложившейся ситуации по каждому спору. С другой стороны, он позволяет выделить участников спора и, как мы говорили выше, принять решение, как отразить спорность в условиях поставленной задачи.

Родительские ID и «родительские права»

Даже если территория может входить в разные иерархии, мы подразумеваем, что в большинстве случаев де-факто она «контролируется» кем-то одним. Например, Голанские высоты оспариваются Сирией и Израилем, что отражено в иерархии, однако они до сих пор под контролем Израиля.

"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. Это следует интерпретировать как «: пожимание плечами: Мир — сложная штука». Например космодром Байконур в Казахстане.

Замещающий/замещаемый

Один из больших и сложных философских вопросов, возникающий при работе с географией: Как отличить простую корректировку от фундаментального изменения?

Эта проблема не является сугубо географической, однако в географии она чаще всего мозолит глаза. Например Польша, Франция и Германия добрую сотню лет присваивали и отдавали (иногда с последующим присвоением обратно) одну территорию. Их границы, и периоды существования границ — важная контекстная информация не только для картографии, но и для многих других сфер деятельности. Возьмём произведения искусства, которые были готовы, когда территория принадлежала Польше, но создавались, когда территория принадлежала Германии. Как бы вы стабильно идентифицировали изменяющуюся местность?

Другой пример. В Нью-Йорк Сити есть этакий не-совсем-район под названием «BoCoCa». BoCoCa — это сокращение от Boerum Hill, Cobble Hill и Carroll Gardens, трёх рядом стоящих районов к югу от делового центра Бруклина. BoCoCa — это и не название в привычном понимании, и не район, как считает большинство людей. С другой стороны, во множестве карт и наборах данных это — район (и название). Что бы мы там ни думали, BoCoCa «существует».

В Who’s On First мы сделали BoCoCa «макрорайоном», который включает в себя три района, от которых произведено его название.
Тип административной единицы — очень важное свойство, и оно, очевидно, используется различными приложениями. Нам не нужно знать, как или почему приложения обрабатывает свойства, ассоциированные с местностью. И если мы вздумаем считать этот WOF ID 85892915 районом (чем он и являлся при импорте из Quattroshapes), мы, вероятно, не должны его так просто менять, по желанию своей левой пятки.

Мы, правда, не считаем BoCoCa районом. Мы имеем твёрдое мнение по этому поводу. В то время, как BoCoCa считают районом, с нашей точки зрения это уже не так. Наш способ уладить проблему подобную этой — создать новую запись с новым типом (BoCoCa — макрорайон) и скорректировать остальные записи, указав, что одно замещается другим.

Например, запись для BoCoCa как района выглядит так:

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

В то время как BoCoCa как макрорайон выглядит так:

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

Приложениям остаётся решить, как (и надо ли) отдельно учитывать замещённые объекты. Поисковый движок, например, может отдельно ранжировать замещённые объекты или полностью исключать из обработки.

Нарушения

Каждая запись имеет список wof:breaches. На момент прочтения этой статьи большинство таких списков всё ещё могут быть пустыми. «Нарушения» случаются, когда геометрия одной единицы пересекается геометрией другой единицы такого же типа.

Эти списки используются как сигнал пользователям Who’s On First как о том, что в данных есть ошибки (как правило, границы стран не пересекают соседних границ), так и о том, что имеет место различие мнений о границах территории (например района).

Подобно многим другим сигналам, его значение, важность и способ обработки отдаются на усмотрение конечным приложениям.

Расскажите мне больше (простые вещи)

Вспомните, что подразумевается под «простыми вещами»...

Наименования

Все наименования изначально взяты из наборов Quattroshapes и Natural Earth. Однако GeoPlanet (GP) в целом лучше по части многоязычных и разговорных наименований.

GP имеет два свойства для наименования:

1. Код языка ISO 639-3
2. Имя «типа» из хорошо известного перечня описаний, составленного отличными людьми из GP:

Поле Name_Type является однобуквенным кодом, принимающим следующие значения:

• P — предпочитаемое наименование на английском языке
• Q — предпочитаемое наименование на других языках
• V — распространённый (но неофициальный) вариант наименования (например «Нью-Йорк Сити» для Нью-Йорка)
• S — синоним или разговорное наименование («Большое яблоко» для Нью-Йорка)
• A — аббревиатура или код для административной единицы («NYC» для Нью-Йорка)

GP также различает name и alias, и в их мире можно встретить следующее:

Name:  Montreal
Language: FRE
Alias (ENG_P): Montreal
Alias (KOR_Q): ????

GP не учитывает, что некоторые страны имеют несколько государственных языков. Мы подумали над всем этим, и решили:

• Мы должны поддерживать наименования на нескольких языках, и возможность задать координаты для наименования
• Для предпочтительного наименования мы используем только p, независимо от языка
• Мы должны использовать пространство name, потому что так удобнее.

Например:

{
    "wof:lang": ["eng", "fre"],
    "name:eng_p": "Montreal",
    "name:eng_a": "YMQ",
    "name:fre_p": "Montreal",
    "name:kor_p": "????",
}

Геометрии

«Консенсусная» геометрия

Каждая административная единица будет иметь по одной «консенсусной» геометрии. Понятие «консенсусности» пока не определено. Да и вообще использование этого слова чревато проблемами. Оно будет заменено более аккуратным термином.

Все «остальные» геометрии

Также, каждая единица будет иметь «альтернативный» файл с разными именованными геометриями. Предполагается хранить в них спорные, упрощённые геометрии, или оптимизированные под специфические задачи (например геокодирование).

Главное здесь: УЧЕСТЬ ВСЕ ГЕОМЕТРИИ.

Источник геометрии, консенсусной (sic) или альтернативной, включается в каждую запись. Например:

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

Центроиды

Каждая запись может иметь несколько центроидов. Сочетание «несколько центроидов» и правда звучит как оксюморон. Термином «центроид» мы обозначаем область фокуса какой-либо геометрии. Различные центроиды обозначаются префиксами, указывающими на тип использования. Например:

• geom:latitude и geom:longitude — центр консенсусного полигона, полученный с помощью математической магии.
• lbl:latitude и lbl:longitude — координаты оптимального размещения наименования. Например полигон Сан-Франциско включает Фараллоновы острова, откуда следует, что «центр» этого полигона расположен в Тихом океане, а это не самое удачное место для наименования.
• nav:latitude и nav:longitude — точка, до которой вас должен довести навигатор. Например вход на станцию скорой помощи, а не погрузочная платформа для грузовиков, прибывающих в то же место.

Необходимый минимум свойств

Flickr API спроектирован по принципу: «Какой минимальный набор данных должен вернуть API на любой запрос, связанный с фотографиями?»

Суть ответа Flickr даёт в «стандартном результате по фотографиям», а именно: «Минимальный набор данных должен позволять загрузить/построить URL, который указывает на страницу фотографии на Flickr»

В случае Mapzen ответом на подобный вопрос будет: «Набор данных должен позволять отобразить ответ API на карте».

Например, должна быть возможность получить ответ от Pelias (или любого другого API), просто передать его в Leaflet как слой GeoJSON и увидеть результат на карте.

Учитывая всё это, «минимальный набор свойств» может выглядеть так:

{
    "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 team. Так же и wof:quality следует рассматривать как эквивалент ранга качества/достоверности, определяемый Data team.

Будущая магия (в процессе разработки)

Дальше идёт список свойств, которые на данный момент не поддерживаются, либо их поддержка пока настолько сырая, что проще заявить, что её нет. Мы рассказываем об этих свойствах, поскольку они обязательно должны (и будут) поддерживаться в будущем.

Ранг(и)

Качество

Насколько полны или достоверны на наш взгляд данные в этой записи

Покрытие

Под «покрытием» мы имеем в виду количество атрибутов, которые имеет запись о местности. Потому как запись может иметь прекрасный набор официальных и альтернативных наименований, но совсем немного метаданных (население, высота и так далее).

Даты

Какова дата образования или, в некоторых случаях, упразднения административной единицы? Эта информация становится особенно важной в наборе данных, где одна запись может замещать другую.

Вообще, даты — довольно разнородное пространство, и мы намерены начать с простых форм, постепенно увеличивая сложность для описания исторических и современных реалий. Библиотека Конгресса работает над расширенным форматом даты/времени (EDTF), есть смысл его пощупать, если вы интересуетесь этим делом.

Погодите… А где взять эти ваши данные?

Первое (и очень очень очень важное), что мы просим понять — Who’s On First пока ещё в разработке, а это значит, что:

• Некоторые (возможно многие) данные будут неверными.
• Некоторые вещи отсутствуют. Некоторые вещи отсутствуют, и мы знаем, что не знаем о них, поэтому разберёмся с ними в скором времени. Некоторые вещи отсутствуют, и мы не знаем, что не знаем о них, поэтому будем разбираться с ними по мере выявления ошибок.
• Некоторая (возможно большая) часть данных будет изменяться тем или иным образом по причине из пункта 1.
• Корректировка одной записи может потребовать обновления связанных с ней записей. Мы пока не формализовали или не доделали инструменты для обновления связанных записей. Это значит, что в ближайшей перспективе возможна несогласованность со связанными записями. Мы с этим разберёмся.

Целью нынешнего релиза было не трубить и возвещать о новом рассвете прекрасных данных, а наполнить для всех содержанием то, о чём мы говорили, иметь набор данных, которым можно подтвердить или опровергнуть наши гипотезы, и дать ликбез о практике работы с этими данными.

Если вам не хватает времени или темперамента (персонального или коллективного), чтобы с таким же немного буйным рвением как у нас продираться через трудности, то лезть в наши данные вам, наверное, пока ещё рано. Мы планируем и далее держать вас в курсе и участвовать в открытых дискуссиях по нашему проекту, так что следите за блогом и сообщайте нам о том, что нужно улучшить.

Сырые данные в формате GeoJSON лежат в двух местах: публичная точка доступа AWS S3 и репозиторий GitHub с кучей мелких файлов. Их URL, соответственно:

• s3.amazonaws.com/whosonfirst.mapzen.com/data
• github.com/whosonfirst/whosonfirst-data

Замечание: ссылку на S3 выше не нужно открывать в браузере, поскольку это точка доступа, и только люди, которые умеют работать с S3, смогут что-то с ней делать. Если эти слова для вас — птичий язык, вам не нужно щёлкать по ссылке на S3. Сразу переходите по ссылке на GitHub.

Пока ещё нет общедоступного инструмента для просмотра данных. У нас есть внутренний «спелеолог», код которого мы планируем открыть (вместе с библиотеками для работы с данными Who’s On First), но на данный момент этого не произошло.

В репозитории на GitHub также есть «мета» файлы, сложенные в каталог, по-умному названный meta. Это в большинстве своём CSV файлы с минимумом данных об административных единицах определённого типа. Как и всё остальное, meta файлы в разработке, но они дают минимальную возможность просматривать данные без загрузки всего набора в базу данных.

Вы сказали… «площадки»?

Да. Мы не включили площадки в этот релиз, но мы работаем над ними. Площадки занимают очень большую часть Who’s On First, однако они либо сложны, либо многочисленны, а часто и всё сразу. Так что, будем двигаться от простого к сложному.

Пару слов про Git (и GitHub)

Не советуем особо привязываться к данным Who’s On First на GitHub (и Git вцелом). Сейчас мы слабо представляем, какой наилучший способ одновременно раздавать данные и принимать поправки и предложения от сообщества.

Не смотря на то, что добрые люди из GitHub продолжают отличную работу, делая Git проще для использования, реальность показывает, что Git остаётся барьером для многих людей. За неимением более формального решения об альтернативе, GitHub, по крайней мере, позволяет наметить основные пожелания:

• Открытый и легко распространяемый набор данных, который люди могут скачать и использовать.
• Любой человек может вносить корректировки и более серьёзные изменения в данные о местности.
• Возможность контроля над изменением данных.
• Место для хранения журнала изменений.

И ещё раз: не привязывайтесь полностью к Git, работая с данными Who’s On First. Он нужен, чтобы показать идею проекта.

Что дальше?

Дальше предстоит много работы.

Подробнее: релизы инструментов и библиотек для работы с данными Who’s On First, релиз внутреннего веб-приложения «спелеолог», которое мы используем для копания в данных и проверки достоверности, создание прототипных сервисов на основе наших данных, завершение (а кое-где и начало) документирования всего, что выше и исправление всех багов.

Не скучайте!

Автор изображений — Aaron Cope.