Есть такой совершенно замечательный документ «Методические рекомендации по проектированию пешеходных сетей» ЦНИИП градостроительства, опубликованный еще в 1988 году. В нем подробно разбираются вопросы проектирования удобных пешеходных сетей, приводится теоретическая основа и практические рекомендации по прокладыванию удобных дорожек. Определяется само понятие «удобства» и вводятся необходимые определения и методики. Мы постоянно ссылаемся на этот документ как на пример того, что «как делать правильно» известно уже давно, вот только почему-то до сих пор никто так не делает.

image092[1]

Результат проектирования пешеходной сети согласно «Методическим рекомендациям…». Нет прямых углов, столь любимых нашими застройщиками, зато есть удобные пути ко всем основным точкам района.

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

В методических рекомендациях приведено несколько примеров построения пешеходных сетей, сперва в них идут базовые абстрактные примеры с несколькими начальными и конечными точками, а затем — практический пример района возле метро «Водный стадион» в Москве. Под катом мы загоним эти примеры в ARP и сравним полученные результаты со статьей.

Простые примеры

Рекомендации начинаются с определения «контрольного угла» — угла между направлением на цель движения и текущим направлением пешеходной дорожки. Авторы утверждают, что как только контрольный угол превысит определенную величину (по результатам натурных экспериментов они называют величину в 30 градусов для среднего качества газона) пешеход неизбежно сойдет с дорожки и пойдет по газону.

Первый пример к статье утверждает, что на картинке ниже значение контрольного угла превышено на участке K2-K4:

image008

A — начальная точка, S — конечная, маршрут авторы называют «нежизнеспособным», так как нарушено правило контрольного угла и на участке K2-K4 образуется тропа

Загоняем этот простой пример в ARP «для разминки» и получаем предсказуемый результат:

paths_no_ants

Да, на этом месте действительно будет тропа

Второй пример демонстрирует идею «слипания» путей. При нахождении множества целевых точек в небольшом секторе относительно начальной, вполне возможно объединять пути к ним экономя на создании дорожек. При этом в любой точке данной системы соблюдается правило 30 градусов, пешеходы могут прийти в любую конечную точку по дорожкам и контрольный угол нигде не превысит предельное значение, т.е. не будет нужды топтать газон.

image038

Древовидная структура на последнем рисунке — оптимальная по длине и удобству пешеходная сеть

Загоняем в ARP, смотрим результат:

paths_no_ants_reduction_0_025

В целом похоже. Точка №5 оказалась прицеплена к правому поддереву, а не к левому, а в остальном дерево получилось почти таким же. Некоторая избыточная прямизна ветвей вызвана использованием прямоугольной сетки.

После вариантов с одной исходной точкой в рекомендациях рассматриваются варианты когда исходных точек несколько. Вот одна и них:

image052

Несколько целевых и несколько исходных точек. При этом два множества расположены достаточно далеко друг от друга (если сравнивать с размерами самих множеств). В итоге образуются промежуточные точки So и Ao, через которые ведут все остальные маршруты.

Тут ARP выдает два возможных варианта (различия по-видимому достаточно случайны и зависят от порядка появления пешеходов):

paths_no_ants

result_21660_reduction_0_0025

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

heatmap_25270

Основной трафик идет через центр, крайние проходы в общем-то особо и не нужны

Пример реального двора

Для демонстрации работы своего алгоритма на реальном примере авторы рекомендаций выбрали район в Москве возле станции метро «Водный стадион». Стоит отметить что все это происходило почти 30 лет назад и с тех пор там многое изменилось, поэтому результаты могут отличаться от реального положения дел с тропами сейчас.

image092[1]

paths_no_ants

Местами результаты похожи, местами различаются. Часть различий обусловлены неточностями карты в ARP (в статье были показаны не все места притяжения пешеходов), часть различиями в алгоритмах. Ниже приведем сравнение отдельных мест района.

Обе карты для упрощения результата учитывали только каждый второй подъезд в многоквартирных домах.

1

Первый фрагмент, дорожки вокруг пятиэтажек, результаты почти идентичны

2

Дорожки вокруг высотных домов похожи, хотя в варианте ARP горизонтальная тропа идет выше.

3

Сложный пример троп в центре района, лежащих на множестве транзитных направлений. Многие тропы совпадают (помечены желтыми линиями), но есть и отличия.

Некоторые «лишние» тропы показанные ARP на самом деле не лишние. Авторы алгоритма были вынуждены сократить количество используемых исходных и целевых точек для упрощения результата. Если же поглядеть на схему дорожек для «полной» версии района, учитывающей все подъезды домов, то можно увидеть что на ней аналогичные тропы есть:

image086

Вариант с более густой дорожной сетью, учитывающей все подъезды домов, многие «лишние» тропы из результата ARP отсутствуют на упрощенном плане но есть на этом

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

При этом время на обработку карты в ARP составило:

  1. 2 часа на обрисовку карты по картинке из статьи
  2. 8 часов на симуляцию
  3. Еще 2 часа понадобятся на шлифовку результатов и перенос их в ту САПР в которой проектировщики района хранят свои планы

Т.е. 3-4 часа рабочего времени человека и 12 часов от начала и до конца процесса (при этом симуляцию можно оставить работать ночью и получить результаты к началу следующего рабочего дня или использовать более мощный вычислительный компьютер).

При этом авторы методических рекомендаций упоминают что на ручное проектирование дорожек по их алгоритму в крупном квартале уходит около 50 часов, то есть больше одной рабочей недели. В итоге симуляция с помощью ARP при сопоставимых результатах оказывается  в 10 раз выгоднее по рабочему времени сотрудника, или в 4 раза по общему времени.

Так что если хотите сэкономить время и при этом разработать удобную систему пешеходных дорожек — редактор карт ARP  ждет вас!