Иерархия административных границ страны

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

  1. Качаю .osm нужной страны
  2. Фильтрую через osmfilter, оставляя границы и точки с admin_level
  3. Фильтрую ненужные теги через QGIS, им же сохраняю в geojson
  4. Скармливаю парсеру, превращая в сущности движка (Drupal 7, термины). У сущности есть название и инфа о координатах, контурах и admin_level
  5. На основе координат и контуров выстраиваю в словаре иерархию Страна - Округ - Область - Город. (Drupal, geophp, geos)

Просидев пару дней над 5 пунктом решил спросить здесь, есть ли что-то подобное в готовом виде?
Искал на gis-lab, drupal.org, форумах, гугле по словам “иерархия городов”, “openstreet административные границы”, “список городов и областей”, лучшее, что нашел:

  1. http://habrahabr.ru/post/21949/ - его использование ломает связь в OSM контурами
  2. ru.wikipedia.org/wiki/Список_городов_России - тоже нет связи с OSM, хотя и ближе

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

Если я использую неправильные ключевики при поиске, подскажите, как назвать данные по иерархии территорий.

Задача решается проще. Гораздо.

  1. Качнуть SHP нужной территории: http://wiki.openstreetmap.org/wiki/Shapefiles, http://beryllium.gis-lab.info/project/osmshp/
  2. Открыть ГИС (QGIS, ArcGIS и т. п.) и привести семантическую таблицу (таблицы) к желаемому виду.
  3. Импортировать полученную таблицу (таблицы) себе в MySQL.

Семантическая таблица - это таблица аттрибутов (QGIS)?
Под “привести к желаемому виду” вы имеете в виду ручное проставление непроставленных областей (родителей) у территорий?
В общем, согласен, так нааамного проще, единственное, что не нравится - ручная правка данных перед импортом.

Да.
Делать такое вручную - это несерьёзно. Есть spatial join для этого.

Тк у меня в под рукой всегда есть postgres + postgis + выгруженная через osm2pgsql часть нужной территории, то я делаю примерно так:

  1. Выбираю корень, например, -59065.
  2. Затем выбираю первый уровень вложенности:
SELECT osm_id, name, ST_AsGeoJSON(way) FROM osm_polygon WHERE tags->'admin_level' = 4 AND ST_Contains((SELECT way FROM osm_polygon WHERE osm_id = -59065), way)
  1. Для полученных регионов выбираю еще один уровень вложенности с тем же запросом но другим admin_level и id родителя, и так пока не дойду самого низа.

Если все полигоны встык, то ничего не потеряется, иначе можно проверять вложенные полигоны через уровень, например вместо admin_level=2 и admin_level=4 взять admin_level=2 и admin_level=6 (у Вас могут быть другие).

Скорее можно проще без postgis, взяв что-либо на основе того же geos что и postgis, например, для питона есть shapely, для php возможно есть биндинг. Или же посмотреть предложенные варианты с GIS системами.

Если можно еще проще был бы рад узнать.

Оказывается, в России не все районы включены в отношения регионов как subarea. В ЦФО добавил, сейчас занимаюсь Южным округом. Буду рад, если кто-то возмётся за другие округа.

subarea — зло.

popstas в данном случае важна информация о координатах? Если нет, легче использовать ФИАС.
Если да, то никакого geophp , зачем? Сейчас такая выборка делается мягко говоря за использованием ST_WIthin в PostGIS для нужного полигона.
Для областей России, что -то вроде SELECT * FROM public.planet_osm_polygon WHERE admin_level=‘4’ AND ST_Within (SELECT way FROM planet_osm_polygon WHERE osm_id=‘айди отношения РФ’), way) - например так, пиши по памяти может и не работать

Фи какой архаизм. Ладно хоть до is_in не взялся.

Zverik и freeExec Слова не подкреплённые объяснением своей точки зрения это просто слова. Чем плох subarea? По моему наоборот очень полезен если нужно проверить сразу все границы по вложенности. В страну в качестве subarea включаются Федеральные округа, в Федеральные округа включаются области, республики и края и т.д.

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

Добавлю свои 5 копеек к неприязни is_in и подобным, помимо повторения геометрии они могут протухать, хотя для административного деления, которое редко меняется, это не столь актуально.

Например, в Беларуси к области помимо районов относятся и города обласного подчинения, которые время от времени упраздняют, так при таком упразнении, если не знать про subarea в области, данные начнут попахивать.

freeExec Как с помощью одной геометрии я могу за 15 минут проверить целостность всех 84 областей (краёв и республик) России? По одному релейшины выискивать? Как с помощью одной геометрии я могу определить релейшены по которым я могу оптимально нарезать страну для дальнейшей конвертации в навигатор?

http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Sergey Astakhov Приводя ссылки - приводите перевод на русский, мы всё таки на русскоязычном форуме.

Раз используется, значит кому-то нужно, но как часть мультиполигона - напрягает.

Разными функциями Postgis и выборками postgres . На удивление всё это дело довольно быстро и шустро работает.

Нет у меня Postgis`а и не нужен он мне, ещё как?

Чем именно напрягает? :slight_smile:

это выглядит примерно так же , как и добавление addr:country и addr:city ко всем poi

Поддержу Kostik’а, на мой взгляд, subarea достаточно полезная штука позволяющая быстро и весьма легко выстраивать иерархию АТД. Если бы все рисующие границы муниципальных образований проставляли бы subarea, то автору данной темы было бы достаточно лишь произвести элементарные рекурсивные запросы, а не подымать целый стек технологий для решения данной элементарной задачи. Касательно же протухания данных и их целостности с полнотой, не для этого ли существуют валидаторы, что бы отслеживать ошибки и поощрять полноту данных?
Вообще, я вроде ранее писал, что, имхо, было бы полезно даже заиметь роль settlment или что-то в этом роде, для явного связывания малых населённых пунктов и муниципальных образований.
Насчёт же “Relations are not Categories”, думаю, оно к этому случаю относится весьма слабо.