Comments 27
@sshikov смотри что получается если перевернуть агрегацию данных наоборот.
Вот с этим я могу поспорить - большая часть людей в России покупает продукты и товары в магазинах.
Ну я бы сказал, что это зависит от многого. Скажем, в ковид я как раз почти не ходил по магазинам, в основном доставка. А потом наоборот, стал предпочитать посетить живьем, ибо так надоело дома сидеть. Ну да, стоимость доставки для кого-то может быть существенна - но зато ты можешь заказать килограмм 20, и тебе их принесут к двери. И у меня доставка из Ашана Сбермаркетом стоит 59 рублей - о чем тут вообще говорить при такой-то стоимости услуги? На даче в области мы вообще по магазинам не ходим, только доставка.
У каждого своя история. Я в карантин выбирался в Атак поблизости раз в неделю, доставкой не пользовался. А после этого тем более. Ну и из того что вокруг вижу, много людей ходит в магазины и ТЦ, и много пенсионеров и молодежи вижу в магазинах.
Ну так я и говорю, что скорее всего тут разные есть истории. По-хорошему, надо исследовать.
Ты прав! Кажется, что проще всего это исследовать банкам и ФНС - все платежи картой и оплата через POS терминалы доступны для аналитики, а кеш флоу из магазинов есть в налоговой. Но обычному человеку это не перепроверить.
Ну мы кстати пытались. Вот представь, что у тебя есть под рукой биллинг (по картам твоего банка). И в этом биллинге написано, что человек заплатил какому-то ООО Вася Пупкин (название латиницей, транслитерация) столько-то денег непонятно за что. Биллинг этот присылает тебе Visa, ну или в общем, некая карточная система, и составлен он по ее стандартам. И адрес там тоже написан так, что геокодировать его удается скажем в 80% случаев. Да, еще биллинг это терабайты в день, скажем, и работать с ним не так и просто чисто технически.
Короче говоря, если это POS терминал не принадлежит своему банку, то исследовать платежи даже в такой ситуации далеко не тривиально. Вплоть до того, что мы начали применять всякие эвристики типа того, что если платежи А и Б были произведены в течение 5 минут - значит POS Б (это например банк конкурент) находится где-то близко от POS А (который нашего банка, и мы даже знаем координаты), и мы можем примерно прикинуть, где этот POS стоит, даже не имея правильного адреса, ну или уточнить результат геокодирования. С кучей допущений, что человек скажем шел пешком, и за 5 минут удалился не более чем на ... (а если он на самокате?).
Даже будучи банком, это не так просто, не все удается определить, что может быть интересно. Удобнее всего когда у человека в кармане смартфон, и там стоит твое платежное приложение, и каждый платеж сопровождается координатами, помимо всего остального. Да и то остаются вопросы при платежах скажем за билет в трамвае ;) Ну или нужно сочетать данные банка, и скажем сотового провайдера - а это уже сложная задача, причем не технически.
А уж про обычного человека я и не говорю.
Счастливчик, нетривиальная задача попадалась!
Я про такой мэтчинг только слышал. В том числе от компании когда получал оффер, которая не банк, а просто продает банкам систему для оповещения по операциям. Там вроде ElasticSearch для фаззи матчинга пытались использовать - дорого на таком траффике.
даже не имея правильного адреса, ну или уточнить результат
геокодирования. С кучей допущений, что человек скажем шел пешком, и за 5 минут удалился не более чем на ... (а если он на самокате?).
Поэтому банкам выгодно "впаривать" клиентам свою виртуальную сим карту.
А в пользовательском соглашении у вас написано, что вы к чеку координаты приклеиваете?
А где я говорил что приклеиваем? Я говорю, что даже чисто технически это сложно реализовать, если ты только банк, и у тебя нет координат с мобильника. И варианты типа покупки этих данных у сотового оператора - тоже не такое простое решение, во-первых, потому что операторов больше одного, а во-вторых, это же не единоразовая акция, это же желательно канал постоянной поставки таких данных иметь.
Причем довольно очевидно, что если сотовый оператор не дурак, он со своей стороны такой аналитикой тоже интересуется, и пытается эти же данные у себя достроить, чтобы продать тем же банкам, но подороже, и обезличенные, чтобы не иметь проблем с регулятором.
Всякие правовые аспекты - это совершенно другая, и наверное не менее сложная история.
Да вроде прямым текстом написано и сложностей не вижу.
Но вообще вы вот всё говорит, что это сложно и не под силу даже банку. А я вот думаю, что если бы эти данные держали не под матрасом, а публиковались, то сообщество и инструменты разработало и данные дополнились.
Похоже что @freeExecвыбрал стратегию писать в спортлото и обознался с контактом.
Кстати, приблизительно туда же меня и пытался отправить ( точнее в некстгис ) когда я спрашивал в канале ORM RU вполне конкретный вопрос где достать открытые данные ГИС ЖКХ для Москвы бесплатно...
И получил конкретный ответ. Он тебе конечно не понравился, и спортлото не любишь. На этом мои полномочия всё.
Илья, твой совет мне был фактически устроить сутяжничество с одним из ведущих игроков на рынке. И скорее всего ты знаешь что это бесполезно так как компания Bronze Corporate Members в OpenStreetMap и ты знаешь основателя Максима Дубинина.
Перефразируя известную поговорку "Бойся Данайцев советы приносящих". Следуя твоим советам я бы потратил много времени, попортил себе карму в сообществе и не получил бы результат.
О, я в твоем резюме интересную строчку нашел
И получил конкретный ответ. Он тебе конечно не понравился
Похоже на попытку подставить. Кажется что есть конфликт интересов между представлением открытого сообщества и рабочими интересами, судя по поведению в официальном телеграм канале.
сколько человек сможет дойти до конкретного магазина
В качестве идеи для продолжения:
Сколько человек сможет дойти до конкретного магазина, если каждого человека учитывать с весом, обратным количеству магазинов в пешей доступности для этого человека.
Если в районе один магазин, он явно будет более посещаем, чем если в этом же районе будет еще 10 таких же магазинов.
И следующий шаг:
То же, но еще поделить на торговую площадь магазина. (Возможно, еще торговую площадь имеет смысл внести в весовой коэффициент).
Тогда можно будет оценить перспективность магазинов. При высоком соотношении взвешенных покупателей к площади магазин выглядит более перспективным.
Расположение на пути людей к аттракторам крайне важно для успеха торговли - будут чаще заходить чем ближе торговый объект расположен к ежедневному маршруту человека.
Как-то в одном инвестбанке рассказали отличный контрпример - ТРЦ Метрополис. Отличное расположение на маршруте, между Балтийской и Войковской, каждый день огромные толпы народа перемещаются прямо через ТРЦ. Казалось бы, все условия созданы, что здесь может пойти не так?
И полный пролет - вся эта толпа чуть менее чем полностью игнорирует магазины ТРЦ на своем пути.
Видимо, близость к дому важнее расположения на маршруте.
Отличный пример! Сам много раз через него пробегал ничего не покупая внутри. Возможно это ошибка зонирования ТЦ стоимости аренды а следовательно и магазинов на пути потока и уровня цен. Есть другой пример ТЦ Праздник - постоянно людей внутри полно и торговля там успешная - как раз если бы не поток людей в метро и из метро в этом торговом центре не было бы такого ажиотажа, как и в супермаркете напротив.
1 километр это просто радиус или реальный путь с учетом всех промзон, рельс и заборов во дворах?
Правильнее и точнее - это обойти дома где не указано число квартир и по почтовым ящикам( табличкам с номером подъезда)
Или достать все подъезды дома и посмотреть на максимальный addr:flats
Спасибо!
Дельный совет, но это не так просто. Требуется очистка данных и тестировать парсер...
osmworld=# select tags->'addr:flats',count(*) from geometry_global_view where tags?'addr:flats' and tags?'entrance' group by 1 order by length(tags->'addr:flats') desc limit 20;
?column? | count
------------------------------------------------------------------------------------------------+-------
61-69, 90-109, 130-149, 170-189, 210-229, 250-269, 290-309, 330-349, 370-389, 410-429, 450-460 | 1
70-89, 110-129, 150-169, 190-209, 230-249, 270-289, 310-329, 350-369, 390-409, 430-449 | 1
1-9; 10-19; 20-29; 30-39; 40-49; 50-59; 119-120; 131-140; 151-160; 171-178 | 1
3-29;31-32;3А-4А;6А-8А;10А-12А;14А-16А;18А-20А;22А-24А;26А-28А | 1
34-59;34А;36А-38А;40А-42А;44А-46А;48А-50А;52А-54А;56А-57А;59А | 1
60-60А;69-72;81-88;97-104;113-120;130-136;146;188-195 | 1
8-20;21а-23а;22а;26а-28а;30а;31а;34а-36а;37;39;40 | 1
112-124;286;286а;287-288;294;294а;295;295а | 1
95-108;289;289а;290;290а;296;296а;297;297а | 1
1-59, 119-120, 131-140, 151-160, 171-178 | 1
60-68; 69-118; 121-130; 141-150; 161-170 | 1
80А;82А;84А;86А;161-163;91А;158-160 | 1
61,62,64,65,67,68,70,71,73,74,76,77 | 1
11-14; 24-29; 39-44; 54-59; 69-70 | 1
60-118, 121-130, 141-150, 161-170 | 1
52-58;64;40а;42а;44а;46а;48а;50а | 1
517-526;518А;520А;522А;524А;526А | 1
41-45; 46а; 48a; 50a; 52a; 54а | 1
1-10;1А;2А;3А;4А;5А;6А;7А;8А | 1
7-11;20-23;33;34;36;37;46-50 | 1
(20 rows)
C другой стороны:
osmworld=# select tags->'addr:flats',count(*) from geometry_global_view where tags?'addr:flats' and tags?'entrance' group by 1 order by length(tags->'addr:flats') limit 50;
?column? | count
----------+-------
8 | 34
2 | 102
3 | 101
9 | 18
1 | 104
7 | 33
5 | 76
6 | 79
4 | 98
16 | 3
1А | 1
19 | 3
17 | 2
11 | 8
58 | 1
12 | 7
21 | 2
13 | 3
6А | 1
15 | 4
20 | 1
2- | 1
31 | 1
38 | 1
14 | 4
37 | 1
10 | 17
18 | 2
85- | 1
6-9 | 2
280 | 1
1-3 | 3
251 | 1
37- | 1
46- | 1
3-5 | 1
2-7 | 2
3-4 | 1
6-? | 1
301 | 1
4-7 | 1
3-9 | 1
1-5 | 11
4-8 | 2
1-2 | 2
160 | 1
1-9 | 66
2-8 | 3
1-8 | 90
5-6 | 1
(50 rows)
Решил быстро проверить как много домов в Москве можно заполнить максимальным номером квартиры с подъездов дома( при этом отбросив все addr:flats которые не соответствуют шаблону ^\d+-\d+?$) - вышло 1186 шт. Жаль этот подход покрывает малую часть домов:
with entrances as (
select id,(regexp_split_to_array(tags->'addr:flats','-'))[2] max_flat,geom from nodes where tags?'addr:flats' and tags?'entrance' and tags- >'addr:flats' ~ '^\d+\-\d+?$')
select g.id,type,max(max_flat) max_flat from geometry_global_view g inner join entrances e on st_contains(CASE WHEN type='ways' and ST_IsClosed(g.geom) THEN ST_MakePolygon(g.geom) ELSE g.geom END,e.geom) where type<>'nodes' and ((case when g.tags->'building:levels' ~ '^\d+(\.\d+)?$' then g.tags->'building:levels' else NULL end)::real>2) and not(g.tags?'building:flats') --проверка по OSM тегам что дом жилой
group by 1,2;IMHO не особо лучше среднего - нужно валидировать, есть результаты где более 1000 квартир в доме. Ну и в OSM разметке видел что иногда отмечают не все подъезды. Идея-то логичная и отличная!
Потыкался в данные Москвы и внезапно там много building:flats и мало addr:flats. Например, в Питере обратная ситуация (но ещё и свои приколы в виде пропущенных квартир и склеенных зданий в центре)
Навскидку, в Москве не более чем у 25% многоэтажек по addr:flats получится узнать число квартир (поделил 8464 addr:flats начинающиеся с 1- на 31925 building=apartments)
https://overpass-turbo.eu/s/1ExL
есть результаты где более 1000 квартир в доме.
А в чём проблема? Вполне реальные дома
Потыкался в данные Москвы и внезапно там много
building:flatsи малоaddr:flats. Например, в Питере обратная ситуация
О, да! Каждый город - свои особенности в разметке и свой фокус на тегах!
Навскидку, в Москве не более чем у 25% многоэтажек по
addr:flats
Я скорее всего плохо описал свой прошлый запрос для проверки. 1186 это число домов в котором по addr:flats удалось добавить значение по максимальной квартире на подъезде. Это число в добавок к домам где указан building:flats. К сожалению, building=apartments не всегда расставлено на многоэтажных жилых домах. Поэтому там в прошлых публикаций тянется портянка тегов в where запроса.
Спасибо тебе за совет!!! Я обновил запрос в статье и это заменило около 1% в данных
count: 445 (1 row) значений квартир в домах из count:43612 (1 row)
Дороги из дома ведут в магазин: вычисляем суммы квартир в районах Москвы