Pull to refresh

Comments 24

те же данные можно получить через Overpass API:
way(poly:"51.838105 36.035249 51.562810 35.991534 51.563141 36.125976 51.681037 36.317305 51.780274 36.333813 51.837612 36.159021 51.838105 36.035249")[building][~"addr:."~"."];
out;
А ссылку на оверпасс-турбо стесняемся давать или хабраэффекта опасаемся?;-)
там ответ >20мегов, у меня браузер заметно подвисает.
Лучше использовать https://github.com/mvexel/overpass-api-python-wrapper или типа того…
Да, оверпасс мощный инструмент и при простых задачах очень удобный. Но с ним плохо работать когда сложные запросы или объёмные результаты. Особенно со сложными запросами, когда у тебя нет инструмента для оценки производительности и приходится гадать на кофейной гуще почему так медленно. В отличии от локальной базы где можно посмотреть почему затык и в случае чего создать дополнительные индексы. Поэтому я привык по старинке делать локально и не от кого не зависеть.
Тогда лучше сразу загрузить pbf в СУБД и дальше SQL-запросами
Да сама реализация вывода OpenStreet лишает всяких ее возможностей. У меня центр города Россия, Красноярск выводится порядка 8 секунд. Это еще без домов.

Яндекс 3 сек, гугл около 5 сек до дома.
Не совсем понял, вывода чего и каких возможностей нет?
сделай свой сервер
Выводится куда?
Если речь о показе картинок с картой — эта статья вообще не об этом.
это просто картинки

В основе OSM тоже «просто картинки». Это просто набор точек, линий и полигонов. Осмысленность они приобретают только с добавлением тегов. Есть у этой area тег «дом»? Значит это дом.

Что меня смущало в OSM в свое время – так это несогласованность тегов. Если мне надо найти какую-то entity, которая может быть обозначена разными тегами, мне надо выполнять поиск, который бы все вариации учитывал? Или правило по написанию номеров домов. Да, я видел голосование, но все ли здания следуют выбранному варианту, или мне придется еще писать свой универсальный парсер номеров, чтобы потом в UI моего приложения показывать человекочитабельный номер дома. Получается, что я не могу просто взять и использовать данные OSM, надо писать какие-то обертки. Или я не прав и есть какое-то решение?
В основе OSM тоже «просто картинки». Это просто набор точек, линий и полигонов.

Нет, в просто картинках нет ни точек, ни линий, ни тем более тегов, есть только пиксели разных цветов. И в этом проблема.
Что же до несогласованности тегов, то проблема слишком преувеличена. Да, существуют несколько схем обозначения схожих свойств. И тут я не вижу большой проблемы учитывать два варианта для полноты покрытия.
С номерами домов конечно интересно, но почему вы думаете, что дизайн вывода их в вашем UI идеален и никому не захочется видеть их в другом виде? Поэтому визуальная составляющая всё равно потребует каких-то преобразований.
С номерами домов конечно интересно, но почему вы думаете, что дизайн вывода их в вашем UI идеален и никому не захочется видеть их в другом виде?

Она и не должна быть идеальной. Я вот о чем: хочу, например, составить какой-то справочник организаций со списком адресов. Понятно, что я использую какой-то свой формат вывода, например пишу полностью «дом 13 корпус 2 строение 4». И вот из голосования я вижу, что в OSM были предложены такие варианты: «48АК2С1», «48Ак2с1», «48А к2с1», «48А к2 с1» и «48а к2 с1». Выбран был предпоследний. Соответственно, я могу написать код, который такой формат преобразует к моему. Проблема в том, что в реальности я могу встретить и другие форматы, а так же те, которые вообще не перечислены выше. И получается, что для того, чтобы корректно работать с этим значением, мне надо прикладывать больше усилий, чем думалось. И ладно еще справочник, его можно отредактировать после генерации, если что-то не распозналось. Сложнее, если надо реализовать поиск по адресу, например.

Я далеко не OSM гуру и, возможно, преувеличиваю проблему. Но наличие некого стандарта все же было бы большим плюсом.
Хочешь стандартов — используй ФИАС (КЛАДР)
Который сам устарел, неполон и местами противоречив?
У самого была схожая задача, в итоге купили API яндекса.
Тут какое дело — это не то чтобы проблема конкретно ОСМ, ей подвержены все внешние источники по отношению к процессу. Тут как бы на одной чаше весов полнота данных, на другой код коррекции. Или вы думаете в ФИАС, как предлагают ниже, всё идеально. Да там от региона к региону, кто в лес, кто по дрова. Уже не говорю о фейках когда у них идёт сплошная нумерация от 1 до 999.
А представьте какой будет головняк, если надо объединить не только Россию, а весь мир :) Поэтому вариант — данные идеальны я бы рассматривал в живой ситуации.
Добавлю свои три копейки. Только в ОСМ можно играться с форматом вывода так или эдак, у других поставщиков геоданных (а они наверняка существуют, и это не яндекс с гуглом) — только за деньги. Так что просто берёшь и используешь данные ОСМ. И обёртку конечно пишешь, не без этого.
Может кто напишет статью про Overpass
А чего там писать? В OSM wiki всё расписано
В вики чёрт ногу сломит. Документация длинная, а учебник всем лень писать.
мне хватило http://wiki.openstreetmap.org/wiki/RU:Overpass_API/Overpass_QL
А есть ли возможность получить, например, все улицы определенного города или все улицы определенного района города?
Можно, если обрезать по границе этого определенного хххх и фильтровать по highway. Тут другая проблема, что вывести так же в CSV не выйдет. Но ogr2ogr умеет читать форматы OSM и может выдать shape или geojson.
Возможность то есть, но нужно уточнить:

1. какие улицы (нужны ли пешеходные, грунтовки, сервисные и внутредворовые проезды)
2. нужно понимать, что улица может быть разбита на несколько кусков, которые прийдётся склеивать (схемы осм не во всём бывают хорошы)
3. есть всякого рода двойные улицы, бульвары, развязки дорог и нужно ли как-то это обрабатывать

Я как-то пытался связать викиданные данные с осм касательно улиц и сталкивался с этими вопросами, решение получилось страшнованым: https://github.com/opendataby/osm-streets/blob/gh-pages/main.py#L732, а так на скорую руку можно и так http://overpass-turbo.eu/s/lz9.
Sign up to leave a comment.

Articles