Комментарии 16
> когда на дворе уже 9 вечера, и пиво в магазинах уже не продают
Странный лайфхак, в моём подмосковье уже давно до 23 продают. Наверное, у вас какое-то другое =)
Странный лайфхак, в моём подмосковье уже давно до 23 продают. Наверное, у вас какое-то другое =)
Я только сейчас понял, что давно не видел таблички про ограничение продажи. При этом в биршопе после 21 на вынос не дают. Возможно это как-то связано с деталями лицензирования работы.
Чтож, прийдется придумать другое романтическое обоснование обратного геокодера. Например нынче в Москве нельзя сверлить стены(и вообще шуметь) с 19, в то время как мой сосед без проблем может это делать(и делает) до 23.
Чтож, прийдется придумать другое романтическое обоснование обратного геокодера. Например нынче в Москве нельзя сверлить стены(и вообще шуметь) с 19, в то время как мой сосед без проблем может это делать(и делает) до 23.
Забавно. Я сейчас тихо-мирно тоже потихоньку пилю свой обратный геокодер (как библиотеку), который умеет возвращать то же, что и ваш (в смысле ID). Он переваривает все данные OSM примерно за полчаса и генерит бинарную базу примерно на 5Гб (могу еще сжать до 4Гб, но придется всякие битовые оптимизации мутить). После чего используя эту бинарную базу умеет порядка 100 000 локальных вызовов в библиотеку с временами ответов почти всех запросов в районе 1 микросекунды, если подтянуть все данные в память перед запросами. Честного тестирования производительности не делал, поэтому цифры примерные, но правильного порядка. Планирую в течении ближайших пары месяцев допилить и написать статью о библиотеке, алгоритмах и структурах данных в ней.
Я использую Osmosis для импорта planet файла — он только его переваривает в SQL 3-4 часа. Потом еще с неделю в полуручном режиме идет обработка и сборка данных.
Насчет скорости — у меня есть код который держит все данные в подготовленном виде в памяти и работает очень быстро. Но у него есть две проблемы:
1. У js вообще проблемы с обьемами памяти и бинарными структурами. Ну и с сам js для математики тоже не особо подходит :P.
2. По правилам игры «ручка» АПИ на продакшен сервере не должна жрать ни память, ни проц.
Буду ждать статью с нетерпением, успехов в теориях и практиках.
Насчет скорости — у меня есть код который держит все данные в подготовленном виде в памяти и работает очень быстро. Но у него есть две проблемы:
1. У js вообще проблемы с обьемами памяти и бинарными структурами. Ну и с сам js для математики тоже не особо подходит :P.
2. По правилам игры «ручка» АПИ на продакшен сервере не должна жрать ни память, ни проц.
Буду ждать статью с нетерпением, успехов в теориях и практиках.
Полчаса — это если в 12 потоков) И код по хардкору на C++. Руками ничего не обрабатываю, потому что лень( Из-за этого всякие несуразности все-равно остаются.
2. Это как-то неправильно. Задача обратного геокодинга сложная сама по себе, а если еще и память нельзя кушать, то совсем печально получается.
2. Это как-то неправильно. Задача обратного геокодинга сложная сама по себе, а если еще и память нельзя кушать, то совсем печально получается.
2. решается удлинением конвеера. В начале ищем конечную область, потом получаем данные, потом распаковываем первый кусок данных… Благодаря «асинхронности» интерфейсов nodejs можно держать одновременно сотню запросов на разных стадиях обработки. Каждый запрос обрабатывается медленно (10-20мсек), но обеспечивается очень высокое значение одновременно обрабатываемых запросов.
В стрес тестах — на всех 12 ядрах — без проблем держалось ~500 одновременных запросов, которые выдавали 12к RPS на сервер. Потом http начинал валиться. Зажав скорость на уровне 5 RPS на клиента, я просто гарантирую работоспособность и бесплатность системы как для пользователей, так и для себя.
В стрес тестах — на всех 12 ядрах — без проблем держалось ~500 одновременных запросов, которые выдавали 12к RPS на сервер. Потом http начинал валиться. Зажав скорость на уровне 5 RPS на клиента, я просто гарантирую работоспособность и бесплатность системы как для пользователей, так и для себя.
которую отдает ручка регионов
Зашел в профиль, работает в Яндексе. Кто там у вас это первым придумал?
очень много геометрии в текущей базе просто нет, в частности многих городов, для которых кто-то почему-то (до сих пор) не создал relation.
Екатеринбурга, например, так нет — только городской округ.
Ваши две серьёзные ошибки:
1) Геометрия может быть задано не только через отношение(relation), но и обычной замкнутой линией (way). Хотя для административных границ это скорее будет приятным исключением.
2) Город (в плане населённого пункта) к административному делению не имеет никакого отношения, поэтому и искать его там не надо.
А Екатеринбург, как населённый пункт вот.
К сожалению это моя боль. Где-то в дебрях OSM вроде даже есть рекомендация так не делать.
Причина очень проста — в нормальной (и нормализованной) «топологической» базе данных город сложная система, и состоит из многих «way». Это должен быть «face», или relation. Вообще конечным обьектов должен быть relation.
В 96% случаях это так и есть. Специально посчитал процент «потеряшек» без relation.
Не смотря на то, что административное деление, острова разные и города существуют параллельно — их можно подружить. Просто забить на admin_level, флаги и смотреть на размеры. Да и есть в административке место городам. В разных странах по разному.
Плюс я одинаковые объекты (Коломна, Малоярославец, Подольск, Париж) просто склеиваю в один. Хотя если Коломна и Малоярославец просто имеют ГО совпадающие с городом — чем отличаются два Подольска(1, 2) — мне не понять.
Причина очень проста — в нормальной (и нормализованной) «топологической» базе данных город сложная система, и состоит из многих «way». Это должен быть «face», или relation. Вообще конечным обьектов должен быть relation.
В 96% случаях это так и есть. Специально посчитал процент «потеряшек» без relation.
Не смотря на то, что административное деление, острова разные и города существуют параллельно — их можно подружить. Просто забить на admin_level, флаги и смотреть на размеры. Да и есть в административке место городам. В разных странах по разному.
Плюс я одинаковые объекты (Коломна, Малоярославец, Подольск, Париж) просто склеиваю в один. Хотя если Коломна и Малоярославец просто имеют ГО совпадающие с городом — чем отличаются два Подольска(1, 2) — мне не понять.
А чтобы не путаться, хотя бы в родной стране, полезно почитать основополагающие НПА, в частности
Поэтому выдав городской округ (ГО) за сам город, вы вводите пользователей в заблуждение, потому что в ГО кроме самого города могут находится другие населённые пункты. Понятно, что ~90% населения так же как и вы не заметят разницы, но выдавать это в сервисе как то не хорошо.
131 ФЗ "Об общих принципах организации местного самоуправления в Российской Федерации"
Поэтому выдав городской округ (ГО) за сам город, вы вводите пользователей в заблуждение, потому что в ГО кроме самого города могут находится другие населённые пункты. Понятно, что ~90% населения так же как и вы не заметят разницы, но выдавать это в сервисе как то не хорошо.
Эээ нет. Я говорил о _точном_ полигональном соотвествии границ города и ГО. Такое наблюдается, например, в Коломне — она единственный населенный пункт своего муниципального образования.
Иногда ГО «чуть чуть» больше города, буквально на пару арков, но туда влезает пара деревень — это, конечно, уже другое. В норме сельские или городские округа(они же иногда районы) в сотни раз больше города(поселка, села) их образующего.
Иногда ГО «чуть чуть» больше города, буквально на пару арков, но туда влезает пара деревень — это, конечно, уже другое. В норме сельские или городские округа(они же иногда районы) в сотни раз больше города(поселка, села) их образующего.
Поэтому я бы вам предложил дополнить схему данных внутригородскими района (admin_level=9) и самими населёнными пунктами place=city/town/village/hamlet + возможно части города suburb
Сейчас средствами Osmosis выгружается:
административка — accept-relations boundary=administrative
острова и города — accept-relations place=island,town,city,village,borough,suburb --tf reject-relations boundary=administrative
«потеряшки» — reject-relations --tf accept-ways place=town,city,village
Suburb в потеряшках нет, так как нормальные районы нормальных городов идут через relation. Хотя… в тот же самом Подольске (или Екатеринбурге) их просто не нарисовали…
административка — accept-relations boundary=administrative
острова и города — accept-relations place=island,town,city,village,borough,suburb --tf reject-relations boundary=administrative
«потеряшки» — reject-relations --tf accept-ways place=town,city,village
Suburb в потеряшках нет, так как нормальные районы нормальных городов идут через relation. Хотя… в тот же самом Подольске (или Екатеринбурге) их просто не нарисовали…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скажи мне, где ты, и я скажу тебе, где ты