Comments 16
очень долго выполняются запросы.. минуты 3 на запрос про
distance <= 1500 and shop='mall'
И правильность вызывает большие сомнения. Смотрите вокруг Авиапарка большая часть как раз жилых отмечена как неподходящая, сервис выделил зеленым только какие то дома на юго-востоке , бред в общем.
2) и еще такой вопрос, есть запрос для выбора здания где работают IT компани? Тоесть выбрать места где больше всего скоплений IT компаний , ну или бизнес центров на крайняк
3) не нашел даже в ваших предыдущих статьях что такое фильтр "опасность" ?
Потому что "Авиапарк" в данных потерялся
D SELECT building_id, shop, name FROM read_parquet('igor-suhorukov.github.io-main/data/data_*.parquet', union_by_name=True) WHERE name = 'Авиапарк';
┌─────────────┬─────────┬─────────┐
│ building_id │ shop │ name │
│ int64 │ varchar │ varchar │
├─────────────────────────────────┤
│ 0 rows │
└─────────────────────────────────┘
3) ищите по строке "опасность" в статье указаной здесь первой. Это действительно быстро
2) не знаю, поищу как с данными мультиполигонов закончу
бред в общем.
У меня встречный вопрос, почему вы неуважительно относитесь к моему труду? Потому что он бесплатный и не покупали подписку на этот сервис и данные достались бесплатно? Спасибо, уважаемый читатель. После этой фразы мне сразу же "захотелось" отвечать на все ваши вопросы.
Данные для мультиполигонов догрузил и карту обновил.
и еще такой вопрос, есть запрос для выбора здания где работают IT компани? Тоесть выбрать места где больше всего скоплений IT компаний , ну или бизнес центров на крайняк
Не интересовался этой темой, так как фокус был на то что нужно для жизни, а не работы в офисе. Сейчас работа в офисе скорее исключение из правил для программистов. Соответственно, в расчитанных POI таких объектов пока не было. Формально при наличии данных должен сработать следующий предикат:
office in ('it','company','telecommunication')очень долго выполняются запросы.. минуты 3 на запрос про
Посмотрю как в будущем изменить модель данных, чтобы запросы работали быстрее, возможно сохраню предрасчитанные агрегаты по типовым запросам.
Спасибо что нашли проблему в данных!
Не стоит завязываться исключительно на brand, он появляется если данные вносят с помощью шаблонов, а это не всегда так. Руками не кто бренд не добавляет и уже тем более всякие викидаты и инстаграммы.
Я готов выслушать вариант как правильно сделать эту часть запроса, чтобы работала всегда на 100%.
хорошо бы если вы ответили на 2 и 3й пункт (вроде это быстро) )))
Мой варианта, в первую очередь ориентироваться на name.
Вот сейчас с Магнитом так:
name - 11599 шт
brand - 7514 шт
Спасибо! У меня к вам вопрос, всегда ли количество обозначает качество? Есть ли уверенность что мгазины крупных сетей, где указан name но не указан brand - актуальны и существуют на данный момент времени?
Я бы сказал, что вероятность актуальности, что для бренда, что для нейма плюс минус одинакова, но я больше доверяю нейму, потому что бренд по большей части импортированные данные, а неймы заполняют люди с полей.
бренд по большей части импортированные данные
И поле "operator" тоже часто импортированное. Для сетевых магазинов в этом есть и преимущество. Например есть Rocketdata. Они актуализируют OSM данные на основе данных своих клиентов. Не думаю что сеть супермаркетов шлет им не существующие локации. Уж клиенты и обозначение в Maps.Me и навигаторах им нужнее. И это всего лишь один из поставщиков.
неймы заполняют люди с полей
Кто нибудь регулярно следит за ними, нормализует и меняет е на ё итп?
сетевых магазинов в этом есть и преимущество. Например есть Rocketdata.
Это преимущество, так же и существенный минус. Вот не импортирует рокетдата какую-то сетевую марку и бренд там будет стремится к нулю.
нормализует и меняет е на ё итп?
Нет, нормализацию и причёсывание приходится делать потребителям данных, а найденные косяки по возможности исправлять.
Похоже нет правильного решения. Есть работающие решения, зависящие от субъективных предпочтений исследователя. Вы предпочитаете решать через name, я через brand, а у кого-то свой магический рецепт из комбинации тегов.
Нет, нормализацию и причёсывание приходится делать потребителям данных, а найденные косяки по возможности исправлять.
За последние 12 лет в Москве почти на каждом здании появились адреса - это существенный прогресс (видимо независимые таксопарки и софт для тарификации помогли, а так же логистика и доставка сделали это).
За прошедшие три года я не увидел значительных улучшений, например, по тегам метрополитена в Москве. По обозначению подъездов, по актуализации POI.
И что я вижу происходит в реальности - ретейл и конторы геоаналитики делают свой локальный производный OSM с уточнениями и не делятся этими данными, а мэпперы реагируют на сигналы интересующих их валидаторов и у каждого свое хобби.
Инфраструктура у жилья в столице