Комментарии 23
Не уловил, как можно при описании исследования данных в OSM вообще не упомянуть https://overpass-turbo.eu/? Как по мне, сначала идем туда, изучаем разметку, пишем запросы. И потом уже осмозис (или другая утилита, например паркетизер).
В публикации есть несколько примеров где используются геоданные, понятное дело что osmosis тут и не причём - это могло быть реализовано и с помощью других инструментов, да и явно не одного... но всё же, главное задача, а инструмент это уже дело наживное, поэтому пишите о других примерах где и как геоданные используются.
Думаю много можно найти примеров необычного приложения.
Спасибо за подробный разбор osmosis
это действительно "швейцарский нож" для OSM дампов, только его больше не развивают.
Из примеров задач - поиск лучшего места для жилья, по моему мнению, отличное применение для геоданных из OpenStreetMap
Почему не развивают? Зашёл на GitHub в историю коммитов: https://github.com/openstreetmap/osmosis/commits/main/ , - пациент скорее жив, чем мёртв.
Текущая версия 0.48 появилась в 2020 году, если я не ошибаюсь, - да не самая большая динамика (раньше релизы были чаще), но и не так чтобы древность.
Но если Вы имеете в виду что новые команды вряд ли появятся, то соглашусь, я этого тоже не жду.
Почему не развивают?
К сожалению, только поддержка проекта. В 2020-2022 я провел много времени разбирая исходники этого проекта, чтобы написать запись PBF в PostGIS шустрее и с разбиением данных в таблицы по H3 index.
Надеюсь они приняли Pull Request.
Я не делал PR в osmosis. Не думаю что мой код с учетом статуса проекта приняли бы, там и внешние утилиты вызываются к тому же. Просто выложил openstreetmap_h3 на GitHub.
С жильём согласен, можно много примеров привести где OSM пригодится, вижу у Вас много публикаций на эту тему - тут добавить нечего.
Мне ещё вот эта публикация нравится: 1 000 000 жилых домов России. Но она не совсем про OSM.
Мне ещё вот эта публикация нравится
Данные о годах постройки домов и типовых проектов зданий, как оказалось, есть в OSM. Для спальных районов Москвы данных прилично, а в остальных зданиях start_date и design:ref редкость.
А так в других городах по РФ действительно для аналитики парсят ГИС ЖКХ. Так делали в параллельном проекте на одной из моих предыдущих работ.
Пример бы как выгрузить полигоны райнов города, было бы удобно
osmosis \
--rb file.osm.pbf \
--wkv boundary.administrative \
--tf reject-relation \
--un \
--wx boundary.xmlТак попробуйте: берём файл --rb, делаем фильтр по административным границам boundary.administrative, отбрасываем все отношения reject-relation, оставляем точки из которых состоят линии границ --un.
Для более детальной настройки используйте фильтр по admin_level см. boundary.
Получим что-то в духе:
...
<node id="3467344978" version="1" timestamp="2015-04-20T08:40:51Z" uid="0" user="" lat="57.080591" lon="65.4632397"/>
<node id="3802047459" version="2" timestamp="2019-06-25T10:08:28Z" uid="0" user="" lat="57.0924709" lon="65.5657055"/>
<node id="4324760740" version="2" timestamp="2016-07-29T04:43:09Z" uid="0" user="" lat="57.1731187" lon="65.6030412"/>
<way id="550959671" version="2" timestamp="2022-05-02T16:22:26Z" uid="0" user="">
<nd ref="716821476"/>
<nd ref="716821344"/>
<nd ref="716823830"/>
<nd ref="5321016260"/>
<nd ref="716823006"/>
<nd ref="716822613"/>
<nd ref="716822092"/>
<nd ref="716820906"/>
<nd ref="5321016177"/>
<tag k="admin_level" v="6"/>
<tag k="boundary" v="administrative"/>
</way>
...Но это не полигоны, к сожалению. Полигоны ещё собрать надо из точек, которые придётся найти по ref. Osmosis это не сделает, придётся что-то своё писать.
UPD лучше relation выбрать, ниже другой вариант.
А в чем сложность создать из точек полигоны? Порядок?
У osmosis? Не знаю, он так просто не умеет - авторы видимо не для этого его задумывали.
Порядок не является проблемой, все теги <nd> идут в нужном порядке.
Я в другом комментарии описал другую версию получения границ - эта ошибочная (поспешил). В той версии выбираются не линии, а отношения. Отношения объединяют множество линий в одну границу, а линии состоят из точек.
В целом и порядок линий и порядок точек в выгрузке сохраняется - написать кастомное решение которое возьмёт отношения, для каждого отношения переберёт линии, потом переберёт точки и создаст полигон - выполнимая задача.
Но это уже не osmosis. И придётся что-то писать - уже не из коробки. Умеют ли так аналоги osmosis - я не знаю.
Всё же вопрос стоял про районы города. То что вы решили не выбрасывать отношения, это правильно. Потому что границы это всегда отношения. Но тут другая проблема, выбираются все границы, а не уровня районов городского округа. А во вторых, районы это не всегда административные единицы, могут быть и просто именованные части города. В общем-то задача не такая и простая, как может показаться.
Про admin_level я писал. Про именованные районы города, подскажите что это за тег, если нужно объединять, то тут без merge будет не обойтись.
В коде просто админ-уровень не отразился. А именованные районы, это значения тега place
Это потому что в код я его не включил, описав в тексте что "соль перец по вкусу". Но вот пример с admin_level и place:
osmosis \
--rb file.osm.pbf \
--tf accept-relations boundary=administrative \
--tf accept-relations admin_level=9 \
\
--rb file.osm.pbf \
--tf accept-relations place=suburb,quarter,neighbourhood \
\
--merge
\
--uw \
--un \
--wx boundary.xmlЗдесь два потока: Один по отношениям boundary, у которого admin_level=9, второй по отношениям с place=suburb,quarter,neighbourhood. Потом Мы их объединяем с --merge и выбираем way и node --uw --un.
admin_level=9 и place=suburb,quarter,neighbourhood нужно в зависимостри от потребностей настраивать.
Хм... Данные OSM всеж немного не очень пока структурированы.
Возьмем к примеру Екатеринбург, в нем есть Академический район, но он не является участником города. Похоже единственный путь реально выгребать boundary administrative из квадрата
osmosis \
--rb file.osm.pbf \
--tf accept-relations boundary=administrative \
--uw \
--un \
--wx boundary.xmlПоправка, сейчас подумал что лучше от relation плясать а не от way
Не уловил, как можно при описании исследования данных в OSM вообще не упомянуть https://overpass-turbo.eu/? Как по мне, сначала идем туда, изучаем разметку, пишем запросы. И потом уже осмозис (или другая утилита, например паркетизер).
Мне он не кажется удобным для изучения разметки - потому и не пишу. Уловили? Возможно я не умею его готовить... но пусть об этом пишут те кто умеет.
Ну, мне показалось, что вы все же говорите об исследовании разметки, в том числе. Осмозис - это уже когда вы скорее знаете, что вам нужно.
Возможно я не умею его готовить...
Легко верю. Он сложный. Но ведь и разметка достаточно сложная, и тут интерактивный режим работы решает. Я подумывал про него написать, но ушел с того проекта, где я его активно применял на ежедневной основе. По-моему тут была про него статья, поищу.
https://habr.com/ru/articles/520524/ ну вот скажем статья в том числе и про него.
Я не совсем про сложность, я просто не представляю как его использовать для исследования разметки, в моём представлении он для поиска "белых пятен" на карте.
Например: я хочу что-то закартографировать, в соседней ветке мы уже вспомнили про даты постройки домов, давай в качестве примера и возьмём.
Мне нужно найти те дома у которых дата постройки не указана, например есть квартал, почти везде всё заполнено но может быть пара домов без даты, мне либо тыкаться по каждому в поисках пустоты, либо зайти на turbo и ввести что-то типа:
nw[building][!start_date]({{bbox}});
(._;>;);
out;и он мне подсветит building где отсутствует start_date - profit.
Но мне уже надо знать и про тег building и проstart_date.
Про "не умею готовить" - я имел в виду именно это - не могу представить соответствующий сценарий, в моём представлении это инструмент другого назначения.
Но я плохой осмер - редко картографирую, поэтому и с overpass-turbo не взаимодействую, - не могу его из-за этого полноценно оценить.
На счёт сложности - да, для многих порог входа будет очень велик, жаль что Вы отказались от идеи описать его, думаю многим бы это пригодилось. В целом вот хорошая публикация для начинающих: Overpass API: следующий уровень владения OpenStreetMap.
"Кому на Руси жить хорошо?" - это прям хардкор, для начального уровня наверно слишком.
Ну да, я согласен - это другие кейсы, тут я пожалуй тоже не скажу, что оверпасс был бы удобен. Тэги надо либо знать априори, либо хотя бы понимать, где у нас правильно размеченные объекты на карте - и тогда зайти с их стороны. Если ни то ни другое нам не известно - то наверное инструмент для работы с текстовым представлением (либо xml, либо может быть - база) будет лучше.
Для меня оверпасс - это инструмент для задач типа "открыть карту, найти объект какого-то известного типа (станцию метро), изучить, как она размечена, какими тэгами отмечены выходы, и т.п. А потом уже идем в базу, или запускаем осмозис. И выгружаем все станции и все выходы к себе, и мучаем по всякому.
Потому что на базе, при условии что она правильно построена, можно себе позволить запросы вида "а какие у нас вообще тэги бывают при таких-то условиях".
Геоданные без регистрации и СМС