Собственно на слое экология почти так и произошло =) Подправляю в модели погрешности, но картина уже вырисовывается.
Но если об этом не говорить, лучше не станет никогда. Бездейсвтие точно ничего не исправит. А если об этом говорить, приводить аргументы, тыкать пальцем в красную карту, доносить проблему до людей, которые о ней даже не задумывались — может, это немного сдвинет ситуацию с мертвой точки. А может и нет.
Да, изохроны для разных видов транспорта — важная штука.
Сценарий такой: выбираем интересующий дом, и видим тепловую карту куда и за ккое время можно доехать. Условно зеленым отмечены зоны — куда за 10 минут, оранжевым — 30 минут и так далее.
На самом деле я не думаю, что эти дома способны простоять 100 лет. Советские кирпичные дома легко простоят еще столетия. У этих же — начинаются проблемы в первые же дни заселения. На второй-третий год многие новые ЖК уже не такие чистенькие как на момент сдачи: облицовка осыпается, плитки отваливаются, расползаются трещины, крыша протекает, подвал заливает и так далее.
Да, все так. До «ареста активистов» чаще всего не доходит, потому что этих самых активистов старательно выставляют в негативном свете. В посте я упомянула про европейские практики: выставить недовольных идиотами, вызвать общественное осуждение, а дальше уже неважно, насколько логичны и естественны претензии активистов.
Насколько я вижу, у нас это работает следующим образом:
1. Активисты выступают против человейников. Тема получает хоть какой-то общественный резонанс.
2. По телеку делают сюжет: семья живет в бараках. Туалет на улице, протекающая крыша, холод, вокруг грязь. Семью переселяют в клетушечку в человейнике. Показывают радостные лица: «Да мы теперь в настоящем дворце!»
3. В активистов летят камни: «вы что, против новой застройки? вы против того, чтобы такие семьи получали нормальное жилье?! „
Типичная подмена понятий. Протест против некачественного, недолговечного и не приспособленного для нормального быта жилья заменяется на протест против переселения бедствующих семей в лучшие условия. То есть ситуация переворачивается вверх тормашками)
К сожалению, квартиры в человейниках в основном раскупаются теми, у кого банально нет средств на что-либо другое. Это либо молодые семьи, либо люди, приехавшие из других регионов, либо пенсионеры, котором приобрели квартиры дети.
Но действительно есть некоторый процент населения, не задумыающийся о проблемах человейников и покупающий там квартиру «по ошибке». Те, у кого есть выбор. Можно сказать, это целевая аудитория данного проекта.
В целом вы правы, конечно нельзя обобщать. Я отталкиваюсь от статистики. Поясню, что имею ввиду под «среднестатистическим туристом»: мапсми долго и упорно затачивал свой функционал именно для туризма. Поэтому core-аудитория мапсми — это туристы. В гугл плей у мапсми 50 млн+ инсталлов, у османд — 5 млн+ (вилами по воде, но хотя бы порядковая оценка). В магазине эпл что-то не соображу как посмотреть количество инсталлов, поэтому по количеству оценок: 32к у мапсми, 617 штук — у османд. При этом переделывание стилей для дорог и тропинок не было среди популярных реквестов пользователей мапсми. Отсюда и вывод.
Ничего не имею против османда. И да, некоторому проценту туристов с ним удобнее. Но когда в любой теме про мапсми (обсуждение фичей, планов, или вот похорон) всплывает «а вот османд лучше», не подкрепленное вообще ничем, это коробит.
Новый владелец по понятным причинам официальный ченджлог опубликовать не пожелал =)
Первое, что тут же бросается в глаза при сравнении — выпилены пробки и гиды. Вместо них — неактивный кошелек.
Поэтому если есть необходимость по-настоящему достоверно сравнить отличия, можно собрать свою версию оригинального мапсми под андроид и сопоставить с текущей.
Сложилось впечатление, что ни оригинальный мапсми, ни мапбоксовую версию, ни ее замену вы не видели и не сравнивали все это собственноручно. Очень много фактических и смысловых ошибок.
Грустно видеть подобные попытки хайпануть и по-быстрому склепать статью, не разобравшись в происходящем.
Часть фактических ошибок:
> В апдейте от 30 декабря 2020 года восстановлена вся функциональность.
Это не так. Если бы вы самостоятельно сравнили все три версии фича-к-фиче, вам бы это бросилось в глаза.
> Во-вторых, такое приложение по своей сути будет быстрее.
Откуда такая инфа? Предположим, нужно проложить маршрут через всю густозамапленную Европу. Одно дело запускать поиск пути по дорожному графу на стареньком смартфоне, и другое — отправить запрос на мощный бэкенд. Аналогично с поисковым индексом на телефоне и на бэке.
> По мнению пользователей, с 2014 года приложение не стало хуже, что является заслугой разработчиков Mail.Ru. Они его не испортили. Хотя пытались.
Мысли рассогласованы. Заслуга в том, что не испортили, хотя пытались?..
> в 2019 году сервис запустил платную подписку на каталог путеводителей, которые бесплатно доступны в других местах — это не очень красиво.
Можно пруф?
> Для начала вспомним этот ужас, который появился в декабрьском обновлении.
Вы лично ставили этот апдейт? По тексту приводятся скрины из другой статьи, и мне почему-то кажется, что вы его в глаза не видели.
> Для получения карт внедрили Mapbox SDK.
Некорректо же. Мапбокс сдк — это не только про скачивание тайлов, но и про отрисовку, поиск на карте, роутинг и все остальное. То есть фактически этим сдк были замещены оригинальные фичи.
> Слева — OpenStreetMap (MAPS.ME), справа — Google Maps. Источник
Нет. Справа — Яндекс.
> Его можно использовать частично (например, для добавления отображения офлайн-карт)
Что здесь имеется ввиду? А вы понимаете, как это работает?
> На самом деле MAPS.ME — это просто одна из многих оболочек для рендеринга OpenStreetMap
Правда? Вы забыли про поиск на карте, поиск маршрутов, режим навигации, карту высот, букмарки и вагон других функций.
> Чтобы карты отображались в офлайне, нам нужны векторные тайлы и программа для их рендеринга.
В мапсми не было векторных тайлов. Данные хранились в бинарных файлах, примерно соответствующим административному делению.
> Что касается альтернатив, то одной из лучших считают OsmAnd.
Кто считает? Османд любят разработчики османда и осмеры, потому что там очень много замапленных объектов, которые для среднестатистического туриста только засоряют карту.
> предупреждения о камерах контроля скорости (POI)
А что в вашем понимании POI?)
> Есть мнение, что карты OsmAnd даже полнее и информативнее, чем у MAPS.ME.
Чье мнение? Опять же: в османде очень много информации, для среднестатистического пользователя избыточной.
> Итак, старое приложение MAPS.ME пока остаётся с нами.
Нет, это не так. Версия, выкаченная на замену мапбоксу, уже не является старым приложением.
Это как-то неправильно — не разобравшись в теме, надергать скринов, фактов и отзывов из других статей, фейсбука и с хабра, и скопирайтить из этого крайне недостоверный текст.
Под описание подходит контейнер типа std::bitset из c++. Триты записываются в битсет один за другим. Первый лежит начиная с индекса 0, второй — начиная с 3 и тд. Аллоцировать заранее по количеству тритов, обращение по индексу — за O(1).
А какие требования к структуре? Планируется только доставать триты по индексу, или еще искать по значению, добавлять, удалять? Известна ли верхняя граница количества тритов? Какой желателен компромисс между скоростью и объемом (т.е. есть ли ограничения на объем)?
Ты правильно сказал, что количество 0 в LBS совпадает с количеством узлов дерева + 1. А фейковый корень добавляется для того, чтобы количество 1 точно совпадало с количеством узлов.
Поэтому select0(i + 1) — это не только индекс 0 в фрагменте LBS, относящемся узлу i — 1. Это индекс 0 перед той самой 1, которая по номеру совпадает с номером искомого первого потомка. Иными словами, select0(i + 1) + 1 — индекс единицы в LBS, номер которой — и есть номер первого потомка i.
Этот индекс нужно превратить в номер узла, и для этого используется rank1:
firstChild(i) = rank1( select0(i + 1) )
Получили еще одну формула для firstChild(i). Также известно соотношение между rank и select:
select0(x) = y
rank0(y) = x
rank1(y) = y — x
select0(i + 1) — i выводится из этого соотношения и второй формулы firstChild(i). Заранее извиняюсь, если где напутала с +-1.
P.S. Еще есть формула, определяющая зависимость rank0 и rank1 (для select чего-то похожего нет):
i = rank0(i — 1) + rank1( i — 1)
Следуя логике «2N — это O(N)», у зависимостей
f(N) = 10N,
g(N) = N + lg(N),
h(N) = N + 8
одинаковая асимптотика. Если не вылезать за рамки теоретической математики, то почему бы не огрубить до верхней границы O(N). Это верно.
Но речь идет про девайсы с ограниченной памятью, на них не удастся рассматривать эти функции как предельные с N -> inf. И f(N) = O(N), g(N) = N + o(N) и h(N) = N + O(1) уже нельзя назвать ростом одного порядка. f = O(N) — это оценка сверху, в которой N может быть помножено на любую константу, а f = N — это четкая гарантия N, без потенциального удвоения или утроения памяти.
2N возрастает строго как 2N. На константу не домножается.
O(N) возрастает линейно от N, то есть N может быть домножено на любую константу (да, в том числе на 2, но может и на 10).
У узла i есть сосед i + 1 на том же уровне дерева (иными словами, узел не является крайним справа в ряду), если выполняется условие: x = select1(i + 1) + 1
LBS[x] == 1
Есть ли у узла с i=4 (буква «е») сосед i+1?
x = select1(4 + 1) + 1 = 8
LBS[8] = 1
Да, i + 1 — сосед.
Есть ли сосед у узла с i=5 (буква «о»)?
x = select1(5 + 1) + 1 = 9
LBS[9] = 0
Нет, i + 1 не является соседом, он находится уже на следующем уровне иерархии.
P.S. Спасибо, опечатку в childrenCount(i) исправила.
С предподсчетом все не так страшно, как может показаться.
Во-первых, спасают оптимизации на аппаратном уровне: в большинстве процессоров реализован popcnt, который быстро считает количество установленных битов в слове. Интел довольно давно разработал набор команд SSE4 с POPCNT для регистров 16, 32, 64 бита. AMD — аналогично. А также есть вариации с ускорением посредством SIMD.
Если забыть про аппаратное ускорение, то конечно есть техники для предподсчета rank таким образом, чтобы не раздувать занимаемое пространство. Многие из них основываются на списках с пропусками для блоков битовой строки. Но это очень большая тема, тянет на отдельную статью с красивыми графиками сравнения производительности и занимаемых ресурсов.
Но если об этом не говорить, лучше не станет никогда. Бездейсвтие точно ничего не исправит. А если об этом говорить, приводить аргументы, тыкать пальцем в красную карту, доносить проблему до людей, которые о ней даже не задумывались — может, это немного сдвинет ситуацию с мертвой точки. А может и нет.
Сценарий такой: выбираем интересующий дом, и видим тепловую карту куда и за ккое время можно доехать. Условно зеленым отмечены зоны — куда за 10 минут, оранжевым — 30 минут и так далее.
Я правильно поняла идею?
Циан:
www.cian.ru/novostroyki-ekonom-klassa
Или вот Яндекс-недвижимость:
realty.yandex.ru/moskva/kupit/novostrojka/zhk-econom
Насколько я вижу, у нас это работает следующим образом:
1. Активисты выступают против человейников. Тема получает хоть какой-то общественный резонанс.
2. По телеку делают сюжет: семья живет в бараках. Туалет на улице, протекающая крыша, холод, вокруг грязь. Семью переселяют в клетушечку в человейнике. Показывают радостные лица: «Да мы теперь в настоящем дворце!»
3. В активистов летят камни: «вы что, против новой застройки? вы против того, чтобы такие семьи получали нормальное жилье?! „
Типичная подмена понятий. Протест против некачественного, недолговечного и не приспособленного для нормального быта жилья заменяется на протест против переселения бедствующих семей в лучшие условия. То есть ситуация переворачивается вверх тормашками)
Но действительно есть некоторый процент населения, не задумыающийся о проблемах человейников и покупающий там квартиру «по ошибке». Те, у кого есть выбор. Можно сказать, это целевая аудитория данного проекта.
Нужно подумать, как это реализовать на данных OSM и возможно из дополнительных открытых источников. На первый взгляд задача выполнимая.
Ничего не имею против османда. И да, некоторому проценту туристов с ним удобнее. Но когда в любой теме про мапсми (обсуждение фичей, планов, или вот похорон) всплывает «а вот османд лучше», не подкрепленное вообще ничем, это коробит.
Первое, что тут же бросается в глаза при сравнении — выпилены пробки и гиды. Вместо них — неактивный кошелек.
Поэтому если есть необходимость по-настоящему достоверно сравнить отличия, можно собрать свою версию оригинального мапсми под андроид и сопоставить с текущей.
Грустно видеть подобные попытки хайпануть и по-быстрому склепать статью, не разобравшись в происходящем.
Часть фактических ошибок:
> В апдейте от 30 декабря 2020 года восстановлена вся функциональность.
Это не так. Если бы вы самостоятельно сравнили все три версии фича-к-фиче, вам бы это бросилось в глаза.
> Во-вторых, такое приложение по своей сути будет быстрее.
Откуда такая инфа? Предположим, нужно проложить маршрут через всю густозамапленную Европу. Одно дело запускать поиск пути по дорожному графу на стареньком смартфоне, и другое — отправить запрос на мощный бэкенд. Аналогично с поисковым индексом на телефоне и на бэке.
> По мнению пользователей, с 2014 года приложение не стало хуже, что является заслугой разработчиков Mail.Ru. Они его не испортили. Хотя пытались.
Мысли рассогласованы. Заслуга в том, что не испортили, хотя пытались?..
> в 2019 году сервис запустил платную подписку на каталог путеводителей, которые бесплатно доступны в других местах — это не очень красиво.
Можно пруф?
> Для начала вспомним этот ужас, который появился в декабрьском обновлении.
Вы лично ставили этот апдейт? По тексту приводятся скрины из другой статьи, и мне почему-то кажется, что вы его в глаза не видели.
> Для получения карт внедрили Mapbox SDK.
Некорректо же. Мапбокс сдк — это не только про скачивание тайлов, но и про отрисовку, поиск на карте, роутинг и все остальное. То есть фактически этим сдк были замещены оригинальные фичи.
> Слева — OpenStreetMap (MAPS.ME), справа — Google Maps. Источник
Нет. Справа — Яндекс.
> Его можно использовать частично (например, для добавления отображения офлайн-карт)
Что здесь имеется ввиду? А вы понимаете, как это работает?
> На самом деле MAPS.ME — это просто одна из многих оболочек для рендеринга OpenStreetMap
Правда? Вы забыли про поиск на карте, поиск маршрутов, режим навигации, карту высот, букмарки и вагон других функций.
> Чтобы карты отображались в офлайне, нам нужны векторные тайлы и программа для их рендеринга.
В мапсми не было векторных тайлов. Данные хранились в бинарных файлах, примерно соответствующим административному делению.
> Что касается альтернатив, то одной из лучших считают OsmAnd.
Кто считает? Османд любят разработчики османда и осмеры, потому что там очень много замапленных объектов, которые для среднестатистического туриста только засоряют карту.
> предупреждения о камерах контроля скорости (POI)
А что в вашем понимании POI?)
> Есть мнение, что карты OsmAnd даже полнее и информативнее, чем у MAPS.ME.
Чье мнение? Опять же: в османде очень много информации, для среднестатистического пользователя избыточной.
> Итак, старое приложение MAPS.ME пока остаётся с нами.
Нет, это не так. Версия, выкаченная на замену мапбоксу, уже не является старым приложением.
Это как-то неправильно — не разобравшись в теме, надергать скринов, фактов и отзывов из других статей, фейсбука и с хабра, и скопирайтить из этого крайне недостоверный текст.
Поэтому select0(i + 1) — это не только индекс 0 в фрагменте LBS, относящемся узлу i — 1. Это индекс 0 перед той самой 1, которая по номеру совпадает с номером искомого первого потомка. Иными словами, select0(i + 1) + 1 — индекс единицы в LBS, номер которой — и есть номер первого потомка i.
Этот индекс нужно превратить в номер узла, и для этого используется rank1:
firstChild(i) = rank1( select0(i + 1) )
Получили еще одну формула для firstChild(i). Также известно соотношение между rank и select:
select0(x) = y
rank0(y) = x
rank1(y) = y — x
select0(i + 1) — i выводится из этого соотношения и второй формулы firstChild(i). Заранее извиняюсь, если где напутала с +-1.
P.S. Еще есть формула, определяющая зависимость rank0 и rank1 (для select чего-то похожего нет):
i = rank0(i — 1) + rank1( i — 1)
f(N) = 10N,
g(N) = N + lg(N),
h(N) = N + 8
одинаковая асимптотика. Если не вылезать за рамки теоретической математики, то почему бы не огрубить до верхней границы O(N). Это верно.
Но речь идет про девайсы с ограниченной памятью, на них не удастся рассматривать эти функции как предельные с N -> inf. И f(N) = O(N), g(N) = N + o(N) и h(N) = N + O(1) уже нельзя назвать ростом одного порядка. f = O(N) — это оценка сверху, в которой N может быть помножено на любую константу, а f = N — это четкая гарантия N, без потенциального удвоения или утроения памяти.
O(N) возрастает линейно от N, то есть N может быть домножено на любую константу (да, в том числе на 2, но может и на 10).
x = select1(i + 1) + 1
LBS[x] == 1
Есть ли у узла с i=4 (буква «е») сосед i+1?
x = select1(4 + 1) + 1 = 8
LBS[8] = 1
Да, i + 1 — сосед.
Есть ли сосед у узла с i=5 (буква «о»)?
x = select1(5 + 1) + 1 = 9
LBS[9] = 0
Нет, i + 1 не является соседом, он находится уже на следующем уровне иерархии.
P.S. Спасибо, опечатку в childrenCount(i) исправила.
Во-первых, спасают оптимизации на аппаратном уровне: в большинстве процессоров реализован popcnt, который быстро считает количество установленных битов в слове. Интел довольно давно разработал набор команд SSE4 с POPCNT для регистров 16, 32, 64 бита. AMD — аналогично. А также есть вариации с ускорением посредством SIMD.
Если забыть про аппаратное ускорение, то конечно есть техники для предподсчета rank таким образом, чтобы не раздувать занимаемое пространство. Многие из них основываются на списках с пропусками для блоков битовой строки. Но это очень большая тема, тянет на отдельную статью с красивыми графиками сравнения производительности и занимаемых ресурсов.