Pull to refresh

Comments 43

А из кадастровой карты что-то можно извлечь? Уже и не помню.

Вроде можно. Но когда я пытался это сделать, кадастровая карта Росреестра работала ужасно медленно. И потом, очень желателен доступ к API (там вроде был ArcGIS), но его не факт что дадут.

Вот если бы спарсить гугл/яндекс-панорамы, "прогулять" по ним нейросеть, обучив на тех данных, которые уже размечены на OSM, и на основании полученной модели разметить всё остальное... Дата-сайентисты, ау! :)

А не проще пойти от года строительства, фактически большинство домов района построены одновременно, и относятся к примерно одной серии.

Кстати, да! Плюс можно попробовать автоматическую кластеризацию по форме линий, как подсказку для человека что дома скорее всего относятся к одному проекту.

Впрочем, я подумал, наверное все-таки без изображений и их распознавания не обойтись. Ну вот представим, что я хочу помочь разметке. И что я знаю даже про свой дом? Примерно год постройки (+- пару лет), примерно число этажей (кроме шуток, потому что зачем мне точно знать, 9 их или 10), ничего про серию дома я не знаю вообще. Но если его сфоткать в нужном ракурсе, вполне вероятно распознавание.

Ну т.е. человеку чтобы размечать даже вручную, не помешал бы помощник.

Есть Яндекс Народная карта)

В ней Яндекс как раз таким и занимается.

Только за нейронками люди потом проверяют.

Все что люди размечают в "Яндекс Народная карта" пренадлежит Яндексу, а не тем кто создавал эти данные. Так что толку что там эти данные есть, если эти данные закрытые.

Отличная идея! И для Yandex/Google/Bing и Mapillary это уже реальность для распознавания с панорам. Для OpenStreetMap все компьютерное зрение пока относится к распознаванию дорог и домов по спутниковым снимкам в rapideditor.org

С юридической точки зрения нельзя использовать гугл/яндекс-панорамы для OSM, но панорамы с Mapilio вроде можно.

Для Москвы тут не хватает МЦК, которая по сути тоже метро. Ну т.е. по сути, какие-то еще виды транспорта не учтены (скорее всего МЦК и ее станции на карте OSM есть).

@sshikovзамечание в точку! Они уже автомагически включены:

osmworld=# select tags->'network',count(*) from subway_entrance group by 1;
        ?column?         | count 
-------------------------+-------
                         |   273
 МЦК                     |    56
 МЦК(14)                 |     1
 Московский метрополитен |   853
(4 rows)

Если какие станции пропустил, надо загребаться в разметку

Ну я случайно ткнул в район станции Зорге, и мне кажется, там куча домов близко к ней. При этом остальные станции далеко - и дома эти не помечены.

Красные точки - входы в МЦК Зорге, синие - центры зданий считающимися жилыми, расположенные на расстоянии до 1250м от входов

Вроде не облажался здесь с SQL. Спасибо за проверку!

Неплохое упражнение в аналитике small data :)

Для больших данных ST_DWithin (и вообще георасширения любой СУБД) не подошло бы, да и вообще, слишком уж это медленно и неэффективно — сравнивать в лоб все сочетания пар POI из двух наборов. Но для ~300 станций и ~100к домов (≅ 30М сочетаний) потянет.

@PastorGLперечитал все твои статьи на Хабре и OneRing/datacooker-etl в моих закладках. Смотрю как ты героически допиливаешь spark инструментарий чтобы решать проблемы которые в олдскульных решениях для работы с данными из коробки. Твой проект с SQL ETL для геоданных вызывает мое уважение, как технаря! С другой стороны глядя на как архитектор и менеджер хочется в моих проектах взять готовые вещи и не разрабатывать что-то новое и потом не поддерживать это.

Неплохое упражнение в аналитике small data :)

Мерси! Считаю если что-то можно решить без hadoop/spark это и нужно решать подходящими простыми инструментами, не пытаясь сразу заложиться на петабайты данных. Моя задача пока не тянет на бигдату и divide and conquer позволяет решать задачи с помощью UberH3. Когда от геофункции ST_DWithin перехожу к работе с геохешами h3_grid_disk.

Проблема PostgreSQL в этих задачах - отсутствие SIMD для геофункций и заточеность его query executor и планировщика на row based структурах, так как эта база из 90х годов и до сих пор основной сценарий её использования OLTP. Поэтому не спасает

Для больших данных ST_DWithin (и вообще георасширения любой СУБД) не
подошло бы, да и вообще, слишком уж это медленно и неэффективно —
сравнивать в лоб все сочетания пар POI из двух наборов. Но для ~300
станций и ~100к домов (≅ 30М сочетаний) потянет.

В прошлых статьях я создавал GIST геоиндексы, поэтому

план запроса использует GIST индекс для ST_DWithin
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      QUERY PLAN                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=4181841.45..4184368.59 rows=1183 width=56)
   Group Key: m.id, (st_x(m.centre)), (st_y(m.centre))
   ->  Sort  (cost=4181841.45..4182199.51 rows=143225 width=68)
         Sort Key: m.id, (st_x(m.centre)), (st_y(m.centre))
         ->  Nested Loop  (cost=0.54..4166133.76 rows=143225 width=68)
               ->  Seq Scan on subway_entrance m  (cost=0.00..52.83 rows=1183 width=40)
               ->  Append  (cost=0.54..3520.85 rows=17 width=191)
                     ->  Index Scan using nodes_000_geom_idx1 on nodes_000 nodes  (cost=0.54..25.78 rows=1 width=76)
                           Index Cond: ((geom)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                           Filter: ((tags ? 'building'::text) AND (NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((geom)::geography, (m.centre)::geography, '1250'::double precision, true))
                     ->  Bitmap Heap Scan on nodes_001 nodes_1  (cost=183.03..757.78 rows=1 width=76)
                           Recheck Cond: (tags ? 'building'::text)
                           Filter: ((NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((geom)::geography, (m.centre)::geography, '1250'::double precision, true))
                           ->  Bitmap Index Scan on nodes_001_tags_idx  (cost=0.00..182.76 rows=22 width=0)
                                 Index Cond: (tags ? 'building'::text)
                     ->  Index Scan using ways_000_linestring_idx1 on ways_000 ways  (cost=0.67..155.15 rows=1 width=197)
                           Index Cond: ((linestring)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                           Filter: ((tags ? 'building'::text) AND (NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((linestring)::geography, (m.centre)::geography, '1250'::double precision, true))
                     ->  Index Scan using ways_001_linestring_idx1 on ways_001 ways_1  (cost=0.68..2385.05 rows=10 width=177)
                           Index Cond: ((linestring)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                           Filter: ((tags ? 'building'::text) AND (NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((linestring)::geography, (m.centre)::geography, '1250'::double precision, true))
                     ->  Index Scan using ways_32767_linestring_idx1 on ways_32767 ways_2  (cost=0.53..25.65 rows=1 width=843)
                           Index Cond: ((linestring)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                           Filter: ((tags ? 'building'::text) AND (NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((linestring)::geography, (m.centre)::geography, '1250'::double precision, true))
                     ->  Index Scan using multipolygon_000_polygon_idx2 on multipolygon_000 multipolygon  (cost=0.53..25.67 rows=1 width=807)
                           Index Cond: ((polygon)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                           Filter: ((tags ? 'building'::text) AND (NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((polygon)::geography, (m.centre)::geography, '1250'::double precision, true))
                     ->  Bitmap Heap Scan on multipolygon_001 multipolygon_1  (cost=90.96..117.09 rows=1 width=471)
                           Recheck Cond: (tags ? 'building'::text)
                           Filter: ((NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((polygon)::geography, (m.centre)::geography, '1250'::double precision, true))
                           ->  BitmapAnd  (cost=90.70..90.70 rows=1 width=0)
                                 ->  Bitmap Index Scan on multipolygon_001_polygon_idx2  (cost=0.00..1.00 rows=5 width=0)
                                       Index Cond: ((polygon)::geography && _st_expand((m.centre)::geography, '1250'::double precision))
                                 ->  Bitmap Index Scan on multipolygon_001_tags_idx  (cost=0.00..88.32 rows=10749 width=0)
                                       Index Cond: (tags ? 'building'::text)
                     ->  Bitmap Heap Scan on multipolygon_32767 multipolygon_2  (cost=2.46..28.59 rows=1 width=5966)
                           Recheck Cond: (tags ? 'building'::text)
                           Filter: ((NOT (tags ? 'amenity'::text)) AND (NOT (tags ? 'shop'::text)) AND ((tags -> 'building'::text) <> ALL ('{service,garages,industrial,retail,office,roof,commercial,garage,kiosk,warehouse,church,parking,public,shed,hangar,train_station,guardhouse,transportation,terrace,greenhouse,bridge,government,chapel,gazebo,civic,ruins,supermarket,sports_centre,semidetached_house,toilets,sports_hall,clinic,farm_auxiliary,stable,grandstand,bunker,gatehouse,store,temple,ventilation_kiosk,carport,cowshed,barracks,shop,cabin,barn,cathedral,wall,townhouse,manufacture,shelter,fire_station,stadium,stands,sport_hall,theatre,storage_tank,checkpoint,houseboat,abandoned,dovecote,mosque,museum,military,container,observatory,lift,tent,factory,sport,mall,riding_hall,depot,prison,gate,triumphal_arch,water_works,public_building,pavilion,bank,institute,works,collapsed,car_repair,crossing_box,fuel,tree_house,presbytery,yesq,farm,outbuilding,police,porch,sauna,monastery,cinema,tower,boathouse,library,transformer_tower,heat_exchange_station,ice_rink,entrance,construction,transformer}'::text[])) AND st_dwithin((polygon)::geography, (m.centre)::geography, '1250'::double precision, true))
                           ->  Bitmap Index Scan on multipolygon_32767_tags_idx  (cost=0.00..2.20 rows=1 width=0)
                                 Index Cond: (tags ? 'building'::text)
 JIT:
   Functions: 55
   Options: Inlining true, Optimization true, Expressions true, Deforming true
(43 rows)

Ну, GIST эт такое себе индексирование, для геометрий его натянули примерно как сову понятно на что. Плавали, знаем как оно внутри устроено.

BTW, мы тоже ведь начинали 6 лет назад именно с PostGIS, и для считанных сотен тыщ точек использовать тамошние ST_ функции было ещё нормально. Проблемы начались, когда точек стали миллионы, и постгря перестала справляться с такими запросами. Вот тогда и мигрировали на Spark, поначалу с разбиениями по полигонам и/или по Вороному. А к решениям, позволяющим работать с миллиардами точек, и требующим нормальное геометрическое индексирование типа того же H3, мы пришли за несколько лет.

Ну, GIST эт такое себе индексирование, для геометрий его натянули примерно как сову понятно на что.

Неэффективно по сравнению с чем? Расскажи пожалуйста какие самые частые операции в ваших запросах, какие геофункции используете, какие индексы, библиотеки для Spark?

да и вообще, слишком уж это медленно и неэффективно — сравнивать в лоб
все сочетания пар POI из двух наборов. Но для ~300 станций и ~100к домов
(≅ 30М сочетаний) потянет.

Вот я показываю выше план запроса, в котором видно что используется Index Scan, Index Cond: ((geom)::geography && _st_expand((m.centre)::geography, '1250'::double precision))а не перебор "в лоб".

Вот тогда и мигрировали на Spark, поначалу с разбиениями по полигонам
и/или по Вороному. А к решениям, позволяющим работать с миллиардами
точек, и требующим нормальное геометрическое индексирование типа того же
H3, мы пришли за несколько лет.

Сам по себе Spark удобный фреймворк для распределенных вычислений над данными, но в плане эффективности использования аппаратного обеспечения ему еще далеко до многих колоночных/MPP баз, многое пытаются вынести из jvm байткода в нативный чтобы повысить его производительность/уменьшить накладные расходы связанные с GC. Мне интересно какие у вас расчеты в запросах, почему не проще было взять тот же omniscidb(heavydb) на GPGPU?

Увы, я не могу рассказать больше, чем уже рассказал, потому что это уже под NDA. Могу только с некоторой грустью добавить, что кроме нас в мире никто из коммерсов за похожие задачи в таких масштабах не берётся, и в общем-то правильно делает. (Рисёрчеры и научники — делают, но у них иная экономика.)

Касательно эффективности: спарк не про утилизацию железа на 100%, и даже не про скорость, а про саму возможность посчитать сумасшедшие объёмы даты на относительно слабом и дешёвом виртуализованном железе в облаке. «Проще» не означает «экономически эфффективно», и наоборот.

Бабло решает, короче.

Касательно эффективности: спарк не про утилизацию железа на 100%, и даже не про скорость, а про саму возможность посчитать сумасшедшие объёмы даты на относительно слабом и дешёвом виртуализованном железе в облаке. «Проще» не означает «экономически эфффективно», и наоборот.

Бабло решает, короче.

Как я понял в облаках вам удобно, потому что это проще масштабироваться под внешних клиентов и выставлять им счета? И капитальные затраты (CAPEX) с покупки своего железа переводить в большие операционные затраты (OPEX) но с возможностью легко масштабировать ресурсы как в большую так и в меньшую сторону?

Увы, я не могу рассказать больше, чем уже рассказал, потому что это уже
под NDA. Могу только с некоторой грустью добавить, что кроме нас в мире
никто из коммерсов за похожие задачи в таких масштабах не берётся, и в
общем-то правильно делает. (Рисёрчеры и научники — делают, но у них иная экономика.)

Мы в разных лагерях тогда) Тут все открыто и прозрачно.

Ну хоть в процентном отношении расскажите, не думаю что ST_DWithin 85% и ST_Intersects 15% нарушит ваши NDA)

У вас как я понял есть проекты для продажи аналитики по комерческой недвижимости и задача рекламной площадки в real time?

Каких только проектов нет у наших заказчиков... И про недвигу, и про аутдор адвертайземент, я даже понятия не имею какие именно, потому что данными не занимаюсь. Я инструменты для аналитиков делаю, чтобы они могли «относительно быстро» и дёшево это всё безобразие считать.

И поэтому могу сказать, что индексы в постгресе — шляпа. И вообще, постгрес с деривативами (гринплам, редшифт, и т.п.) для бигдаты сам по себе чудовищно медленная и гораздо более дорогая шляпа, чем спарк.

И поэтому могу сказать, что индексы в постгресе — шляпа. И вообще,
постгрес с деривативами (гринплам, редшифт, и т.п.) для бигдаты сам по себе чудовищно медленная и гораздо более дорогая шляпа, чем спарк.

У меня позитивный опыт с Redshift со стороны моих пользователей и не очень позитивный в плане удобства разработки и ограничений. Там хранились метрики с 3D геометрии об ортодонтическом лечении и обогащение информации из других систем компании. Для пользователей, бизнеса и отдела эксплуатации удобно, для разработки не очень.

Самое главное не надо писать поверх свои фреймворки для пользователей, self service цветет ярким цветом, документации в интернет по PostgreSQL синтаксису полно и оно уже "матерое".

Для геоданных есть компании кто на BigQuery сидит и довольны. Просто платят за запросы дорого! И готовят данные пайплайнах на duckdb, чтобы не в PostGIS.

Увы, я не могу рассказать больше, чем уже рассказал, потому что это уже под NDA.

Не обижайся, но получается как в анекдоте

истинные джентльмены верят друг другу на слово

Поехал однажды Василий Иванович в Англию и вернулся через неделю. Встречавший комдива Петька застыл от удивления: Чапаев был в дорогом костюме и с кучей мешков, из которых торчали крупные купюры.

Выйдя из роскошного лимузина, Чапаев блаженно прищурился и закурил трубку. Ничего не понимающий Петька подошёл к командиру и спросил:
— Василий Иванович, а всё это у вас откуда взялось? Мы ж десять лет всей дивизией деньги копили, чтобы вы смогли в Англии побывать!
— Да ерунда, Петька, я всего-то выиграл в карты! — небрежно ответил Чапаев.
— Ого! Но как?
— Ну, приехал я в Англию, и меня пригласили в клуб. Там все мужики сидели, выпивали и играли в карты. Я пригляделся — оказалось, они в «двадцать одно» играют! Я к одной компании присоединился и стал играть, на карты глянул, оказалось, что у меня — 17. А сидящий напротив произнёс: «Господа, у меня — 21!» Я ему и сказал: «А покажи-ка!» А он ответил: «Сэр, мы — в Англии, здесь все джентльмены, а истинные джентльмены верят друг другу на слово!» Вот тут-то, Петька, мне так попёрло, так попёрло!

не приводишь фактов, use case, деталей и сразу делишься выводами. Предлагая просто верить. Возможно у нас вообще разные задачи и контекст у приложений, потому заключения из твоего опыта не применимы здесь.

Я б тоже с удовольствием посмотрел на чужие юзкейсы. Особенно, кейсы из промышленной эксплуатации en masse, а не всякие разовые исследования гениальных консалтеров, из которых делаются далеко идущие выводы с интерполяцией на всю индустрию.

Угу, выбираешь так квартиру недалеко от входа на станцию МЦД, потом от этого "входа" кандехаешь 250 метров по крытым надземным кишкам и павильонам с шаурмячными до самих поездов.

А кто-то стоит под дождем и снегом на автобусной остановке и не помещается в маршрутку к метро и ждет следующую в Москву через 40мин. Опыт из моей жизни в феврале этого года, когда гостил в подмосковье.

А это тут ни при чем. Я говорю о том, что выбранная автором метрика сомнительна, вход входу рознь в плане удобства посадки и дальнейшего маршрута.

Я бы вообще жил подальше (в разумных пределах) от входов в метро, это тот еще рассадник всякого быдла.

Я говорю о том, что выбранная автором метрика сомнительна

Я и есть автор) Жизненный опыт показывает что когда в моем присутствии говорят обо мне в третьем лице, то мотивация человека не добрая и не направлена на конструктивную критику.

Расскажите как вы предлагаете изменить учет расстояния? Погрешность указанных вами 250м на максимальном расстоянии 1250м - это 20%. Есть документированнный алгоритм как расчитывают метрику расстояния до метро другие сервисы?

Я бы вообще жил подальше

На каком расстоянии?

от входов в метро, это тот еще рассадник всякого быдла

Вы ставите себя выше других людей, пользующихся метрополитеном?

Я и есть автор) Жизненный опыт показывает что когда в моем присутствии говорят обо мне в третьем лице, то мотивация человека не добрая и не направлена на конструктивную критику.

Я не всегда смотрю на цвет плашек в ответах (иногда сам Хабр их не подсвечивает зеленым).

Расскажите как вы предлагаете изменить учет расстояния? Погрешность указанных вами 250м на максимальном расстоянии 1250м - это 20%. Есть документированнный алгоритм как расчитывают метрику расстояния до метро другие сервисы?

Я не могу точно ответить на это и тем более дать алгоритм, могу только указать юзеркейс. Я бы вообще не рассматривал МЦД, они говно как транспорт и связан чисто условными "переходами" с метро, на которые нужно потратить 10-15 минут по улице. Входы в метро – более честное понятие, даже если идти от лестницы в подземный переход и по эскалаторам на платформу, то это не будет дольше 5 минут ни на одной станции.

Вы ставите себя выше других людей, пользующихся метрополитеном?

Это вы, похоже, ставите, раз приравниваете к быдлу всех пассажиров метро.

https://ru.wiktionary.org/wiki/быдло#быдло_II

  1. перен.разг.презр. тупой, грубый, неотёсанный, бескультурный человек 

На каком расстоянии?

Повторюсь: на достаточно близком, чтобы ходить до дома пешком (<700 м); на достаточно далеком, чтобы быдло (всякие обитающие у входов рыгающие панки и стреляющие мелочь бомжи) были не у меня под окнами (>50-100 м).

Я бы вообще не рассматривал МЦД, они говно как транспорт и связан чисто
условными "переходами" с метро, на которые нужно потратить 10-15 минут
по улице.

А где в статье указано что я его рассматриваю? Все что я учитываю в этой аналитики - railway=>subway_entrance

Это вы, похоже, ставите, раз приравниваете к быдлу всех пассажиров метро.

Вы только что сами придумали и приписали мне неуважительное высказывание по отношению к пассажирам Московского метрополитена. Чистой воды демагогия! Еще и выбрали из викисловаря определение удобное вам

всякие обитающие у входов рыгающие панки и стреляющие мелочь бомжи)

У меня в целом положительные впечатления от пользования метрополитеном. Не знаю где вы находите маргинальные элементы.

были не у меня под окнами (>50-100 м

Достаточно ли этой дистанции? В прошлых статьях некоторые коментаторы возмущались что 150м от негативных факторов им мало.

Ну тут напрашивается привязка к циану и тд. И аналитика на подбор кв в доступности от метро и по ₽

Только на практике 5 км/ч это максимальная скорость. Так ходят единицы и то не всегда. Средная скорость пешеходов, скорее, 3 км/ч.

Не просто бегают, а на электросамокате :). Кстати, я бы попробовал учесть и его, потому что на сегодня прокат самокатов и великов сильно меняет ландшафт. В том числе даже зимой. В тоже время, маршруты, доступные самокату, велосипеду и пешеходу, далеко не всегда совпадают.

Ну т.е. когда я ездил на работу самокатом, мне было удобно доехать 20 минут до МЦК, 20 минут на нем, и 20 минут до офиса. При этом метро от меня в 5 минутах, а МЦК где-то 3.5-4 км. Но - тут уже вступают в игру погодные условия. Сегодня вот снег выпал - какие нафиг самокаты (хотя прокатчики их еще не убирали)?

Похоже на новую фичу для Graphhopper. Он до сих пор не поддерживает "из коробки" комбинированные маршруты (велосипед+пешком+транспорт итп) При этом поддержка для общественного транспорта по протоколу gtfs в коде есть, но кто же в РФ будет публиковать такие данные для общественного транспорта, хотя эти данные есть у Яндекса и Мосгортранса? Так что я бы пока так не усложнял задачу на старте.

Ну, такая комбинированная навигация - она сложная логически. Я бы сказал что Яндекс, который выкатил навигацию для самокатов, до сих пор строит такие маршруты, что только ой. Скажем, у меня поблизости два пешеходных перехода через магистраль, оба с лифтами, но меня с самокатом почему-то гонят за пару км, чтобы переехать магистраль поверху. Считается, что я на самокате не могу войти в лифт, или закатить его по лестнице с пандусом?

Ко-фаундер Graphhopper мне честно отвечал почему они удалили нужный код для сложной навигации:

Считается, что я на самокате не могу войти в лифт, или закатить его по лестнице с пандусом?

Надо разработчиков маршрутизации в Яндексе спрашивать. Отправь к ним на митап или конференцию своих коллег этим с вопросом)

Ну вот откуда им знать, что оно не используется? Потому и не используется, что нет такой функции. А по сути, чем самокат плюс метро отличается от метро плюс общественный транспорт? Та же фигня на первый взгляд.

15 минут др метро много. Это 1.5 км, ничего себе. 5 нормально. У меня 3, засекал, от двери до двери

Sign up to leave a comment.

Articles