Комментарии 18
НЛО прилетело и опубликовало эту надпись здесь
Если бы вы прочитали всего на один абзац ниже, вы бы увидели, что в моей задаче ни Гугль, ни Яндекс не применимы вовсе — интранет, однако. Так что мне глубоко безразличны оба эти продукта.
Более того, я бы не рекомендовал использовать ни один из них, если у вас свои карты на основе OSM, вы вносите свои данные, генерируете свои тайлы и т.п. Причина достаточно очевидна — Гугль и Яндекс не будут вам возвращать osm id, а без него вы замучаетесь связывать ответ геокодера с объектами карты.
Более того, я бы не рекомендовал использовать ни один из них, если у вас свои карты на основе OSM, вы вносите свои данные, генерируете свои тайлы и т.п. Причина достаточно очевидна — Гугль и Яндекс не будут вам возвращать osm id, а без него вы замучаетесь связывать ответ геокодера с объектами карты.
БЛЯСТЯЩЕ!
Мы делали адресный поиск для Guru Maps и могу сказать, что работа эта не из легких. Адреса точек вы получили. Но они же просто номер дома, плюс имя улицы. Бывает, что у одного объекта несколько адресов на нескольких улицах. Еще надо определять попадание точки в административные границы, чтобы отличить деревни с одинаковым названием в разных районах. Выбирать нужные из административных границ, чтобы не перегружать результат данными. Магазины многие стоят без адресов, но у полигона здания, в котором они находятся адрес есть. Дальше больницы и учебные заведения название ставят на территорию, а адрес на здания. И получается что надо не только административные границы из полигонов получать, но и название заведения. И много еще чего.
imposm умеет быстро разбирать pbf на nodes,ways,relations и понимает модель данных, которую ему подсунули. Благодаря модели он выбросить все ненужные данные и оставит только нужные. Так получится развернуть только то что надо в postgis. Потом обработать и выгрузить уже поисковый индекс во что угодно. Хотя и posgresql достаточно быстр.
imposm умеет быстро разбирать pbf на nodes,ways,relations и понимает модель данных, которую ему подсунули. Благодаря модели он выбросить все ненужные данные и оставит только нужные. Так получится развернуть только то что надо в postgis. Потом обработать и выгрузить уже поисковый индекс во что угодно. Хотя и posgresql достаточно быстр.
Я не говорил, что работа на этом закончена. Она только начинается.
Магазины многие стоят без адресов, но у полигона здания, в котором они находятся адрес есть. Дальше больницы и учебные заведения название ставят на территорию, а адрес на здания. И получается что надо не только административные границы из полигонов получать, но и название заведения.
Премного благодарен за подсказки. В проекте также пришлось сделать самодельный адресный поиск, а некоторые моменты упустил. С вашими подсказками смогу существенно доработать свой поиск. Если вы подскажете еще несколько лайфхаков был бы просто безмерно благодарен. Пишу здесь, а не в личку так как думаю, что не я один буду вам благодарен в будущем.
Это не мне спасибо (вы видимо не туда комментарий написали).
К сожалению могу добавить от себя, что лайфхаки к OSM нужны постоянно, потому что разметка к сожалению хромает. Но я боюсь, что это не баг, а фича, что называется. Ну вот прикиньте:
>Дальше больницы и учебные заведения название ставят на территорию, а адрес на здания.
Есть у вас забор. Внутри много зданий (типичная больница). Адреса у зданий. А название у больницы. На чем висят тэги с названием? На заборе! На чем висят тэги с адресами? На зданиях, потому что адреса эти разные (корпуса, строения и т.п. разные).
К сожалению могу добавить от себя, что лайфхаки к OSM нужны постоянно, потому что разметка к сожалению хромает. Но я боюсь, что это не баг, а фича, что называется. Ну вот прикиньте:
>Дальше больницы и учебные заведения название ставят на территорию, а адрес на здания.
Есть у вас забор. Внутри много зданий (типичная больница). Адреса у зданий. А название у больницы. На чем висят тэги с названием? На заборе! На чем висят тэги с адресами? На зданиях, потому что адреса эти разные (корпуса, строения и т.п. разные).
Запросто могу представить и повеселее — «забор» собран в релейшен и в него же входит точка с ролью label, и у них, внезапно, name разные (у точки, территории и релейшена).
И вот тут интересно было бы узнать у автора, как можно проверить хотя бы частично, что ваш велосипед (по-)едет в нужную сторону? Кроссвалидация? Ручной просмотр ошибок? Игнорирование? ИИ? Блокчейн? =)
И вот тут интересно было бы узнать у автора, как можно проверить хотя бы частично, что ваш велосипед (по-)едет в нужную сторону? Кроссвалидация? Ручной просмотр ошибок? Игнорирование? ИИ? Блокчейн? =)
Вообще проблемы невалидности для OSM имеют место. И валидаторы соответственно существуют.
Что до моего проекта — то он не предполагает никакой навигации по адресам, доставки посылок и поездок курьеров, так что мы у себя вполне можем игнорировать те объекты, которые не удалось идентифицировать или скажем геокодировать (при условии, что их количество укладывается в разумные рамки).
Вообще мы много думали над тем, как проверять результат геокодирования. Это как раз очень актуально, потому что большинство геокодеров рассчитаны на интерактивное применение, они показывают человеку несколько найденных кандидатов, а тот уже отбирает нужный.
Но если у вас приложение (робот) — такой вариант не годится, потому что признака «этот лучше» кандидаты не содержат. И вот прикиньте — вы даете API на вход адрес, а он вам возвращает десять адресов и координат. Какой из них правильный, и есть ли он?
Если для обратного геокодирования задача проверки сводится к тому, насколько близки координаты на входе и на выходе, то в этом случае вам нужно понять, насколько близки два адреса. И тут уже даже на самом верхнем уровне начинается ужас «Ханты-Мансийский АО», «ХМАО» и «Ханты-Мансийский Автономный округ — Югра» — это три разных адреса, два, или один и тот же?
>ИИ? Блокчейн? =)
Ну кстати, шутки шутками, а вот применить к этому делу некоторые технологии ML и NLP очень давно чешутся руки. Только пока ресурсов на это не хватает.
Что до моего проекта — то он не предполагает никакой навигации по адресам, доставки посылок и поездок курьеров, так что мы у себя вполне можем игнорировать те объекты, которые не удалось идентифицировать или скажем геокодировать (при условии, что их количество укладывается в разумные рамки).
Вообще мы много думали над тем, как проверять результат геокодирования. Это как раз очень актуально, потому что большинство геокодеров рассчитаны на интерактивное применение, они показывают человеку несколько найденных кандидатов, а тот уже отбирает нужный.
Но если у вас приложение (робот) — такой вариант не годится, потому что признака «этот лучше» кандидаты не содержат. И вот прикиньте — вы даете API на вход адрес, а он вам возвращает десять адресов и координат. Какой из них правильный, и есть ли он?
Если для обратного геокодирования задача проверки сводится к тому, насколько близки координаты на входе и на выходе, то в этом случае вам нужно понять, насколько близки два адреса. И тут уже даже на самом верхнем уровне начинается ужас «Ханты-Мансийский АО», «ХМАО» и «Ханты-Мансийский Автономный округ — Югра» — это три разных адреса, два, или один и тот же?
>ИИ? Блокчейн? =)
Ну кстати, шутки шутками, а вот применить к этому делу некоторые технологии ML и NLP очень давно чешутся руки. Только пока ресурсов на это не хватает.
Благодаря модели он выбросить все ненужные данные и оставит только нужные.
А кто так не может?
Так вот же автор статьи использовал данные от parquetizer-а, которые полные и большие. А imposm уже на этапе чтения выбросит весь мусор.
Ну, на самом деле я просто не знаю, что мне еще понадобится, поэтому ничего выбрасывать не стал принципиально. С местом проблем нет, для приличного кластера весь OSM вообще не размер, у меня проблема скорее в том, чтобы его из интернета выкачать, и до кластера в интранете доставить. Поэтому когда я начал импортировать — мне уже нет смысла ничего экономить.
Можно повторить подобную операцию на уровне relations, если хочется, но вряд ли стоит.
Но тогда вы потеряете часть домов выполненных в виде мультиполигонов.
Хм. Почему вдруг потеряю? Hive умеет хранить сложные типы данных, так что я вполне могу построить тип для relation, который будет хранить не ссылки на входящие в него другие элементы, а их самих (включая построенную для ways геометрию, тэги и прочее).
Ну то есть, ценой дублирования информации в этой денормализованной таблице я не буду строить дорогой для меня join. А поскольку я обновлять в этой базе ничего не собираюсь, она write once фактически, то проблем с обновлением в двух местах одного и того же у меня не будет.
Ну то есть, ценой дублирования информации в этой денормализованной таблице я не буду строить дорогой для меня join. А поскольку я обновлять в этой базе ничего не собираюсь, она write once фактически, то проблем с обновлением в двух местах одного и того же у меня не будет.
Как почему, вы же сами пишете, что можно было это сделать, но вы не стали. А я вам говорю о последствиях вашего выбора.
То что я не стал — не значит, что я это не попробовал. Я строил такую таблицу, и в ней ничего не теряется.
А не стал я по другим причинам, потому что join nodes и ways для меня дорогой, а вот relations как раз дешевый — потому что она сама копеечного размера, в ней 740 тыс записей, и она вся влезает в память — поэтому map join работает на ура.
А не стал я по другим причинам, потому что join nodes и ways для меня дорогой, а вот relations как раз дешевый — потому что она сама копеечного размера, в ней 740 тыс записей, и она вся влезает в память — поэтому map join работает на ура.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как загрузить OpenStreetMap в Hive?