Ещё раз про maxspeed:practical

andriano · 2012-12-03 17:01:22

dimonster wrote:

Ну, можно сразу "вес ребра графа" вписывать.
Нечто вроде "время, затраченное на перемещение от начала до конца участка". В секундах или минутах. Разное для разных категорий тр. ср.
elapsed_time:car=
elapsed_time:backward:car= ( в обратном направлении)
elapsed_time:hgv= (для грузовиков)
elapsed_time:bicycle=

Этот вопрос уже обсуждался, и я уже писал, почему это невозможно (точнее, почему такой подход принципиально не способен привести к правильной маршрутизации).
Пост №132 в этой теме.

andriano · 2012-12-03 17:03:37

Amigo wrote:

Для тюнинга в ситуациях когда есть более длинная дорога высокого класса и короткая низкого и навику они одинаковы нужен стал именно
liosha wrote:
что "настроечный коэффициент" сам по себе особого смысла не имеет
и для этого вполне подошел maxspeed:practical подкуртив который на +- десяток км/ч на короткой или длинной дороге стало можно добиться правильной маршрутизации.

1. Это противоречит принципам OSM (противоречит, кстати, не потому, что OSM такой плохой, а потому, что подход неверный).
2. Это может работать только для одного конкретного алгоритма (и то неидеально).
Затачивать данные OSM под одну конкретную программу - нонсенс.

andriano · 2012-12-03 17:16:10

dimuzz wrote:

Ну и таки сошлюсь на Институт инженеров транспорта...

1. На мой взгляд, maxspeed может быть только 100%. Все, что ниже 100% - это вариации на тему avgspeed: верхняя средняя, нижняя средняя и т.п. Поэтому данный способ задания противоречит названию.
2. Мне, в конце концов, все равно. Хотите, чтобы название противоречило существу - пусть будет. Но чтобы в конце концов появилось что-то определенное, а не "каждый мапит во что горазд". Но хочу сразу предостеречь: если мы сейчас даже договоримся на определение величины вопреки ее названию, рано или поздно этот же вопрос (о соответствии названия и определения) будет поднят кем-то другим.

Так что, на мой взгляд, нужно сразу делать по уму (в том числе - названия), а не надеяться, что "и так сойдет".
Если что-то требуется корректировать и переделывать, лучше делать это на как можно более раннем этапе.

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

dimuzz · 2012-12-03 17:20:55

andriano wrote:

На мой взгляд, maxspeed может быть только 100%.

Ну заблуждение же, о чем ИИТ говорит прямо-таки с военной прямотой:
Since drivers navigating the roadways neither know nor observe design speeds, they tend to drive at speeds that they consider comfortable and safe based on their perceptions of the roadway geometry regardless of the speed limit. Therefore, the overall speed of roadways may not be in agreement with the roadway’s intended function.

esaulenka · 2012-12-03 17:34:11

andriano wrote:

я, якобы, пытаюсь что-то "переделать".

вот этого не было, да?

andriano wrote:

поправить существующее использование и впредь использовать только по прямому назначению.

andriano wrote:

Ну так изложите свое видение:
- что было раньше?
- и чем это отличается от того, что я предлагаю?

В пятый раз? Или в десятый?

Last edited by esaulenka (2012-12-03 17:34:29)

Sergey Astakhov · 2012-12-03 17:43:22

andriano wrote:

Ну так изложите свое видение:
- что было раньше?
- и чем это отличается от того, что я предлагаю?

Ну, к примеру, ваше предложение о внесении ограничения по maxspeed вполне тянет на переделку. Сосбно, с чего данный топик и начался. Мало того - оно ведёт к потери информации в исходных данных. Это как с буквой "ё" - заменить её на "е", если кому нужно, элементарно, а вот восстановить отсутствующую уже проблематично.

andriano · 2012-12-03 20:09:12

Sergey Astakhov wrote:

Ну, к примеру, ваше предложение о внесении ограничения по maxspeed вполне тянет на переделку. Сосбно, с чего данный топик и начался. Мало того - оно ведёт к потери информации в исходных данных. Это как с буквой "ё" - заменить её на "е", если кому нужно, элементарно, а вот восстановить отсутствующую уже проблематично.

Ну, вообще-то неогравниченных величин в природе не бывает, так что это вряд ли можно рассматривать как ограничение. Скорее - уточнение. Причем, по вполне понятным соображениям (и, учитывая аргументацию тех, кто высказался за отклонение пропозала) - неограниченная величина будет характеризовать автомобиль больше, чем дорогу.
Вы с этим не согласны?
И потом, я все-таки хотел бы услышать Вашу трактовку maxspeed:practical.

Ведь Вы не будете спорить, что внятой документации, как ее использовать, пока нет, и каждый мапит кто во что горазд? И что было бы гораздо лучше, если бы эту величину все понимали и использовали одинаково?

andriano · 2012-12-03 20:13:44

dimuzz wrote:

andriano wrote:
На мой взгляд, maxspeed может быть только 100%.
Ну заблуждение же, о чем ИИТ говорит прямо-таки с военной прямотой:
Since drivers navigating the roadways neither know nor observe design speeds, they tend to drive at speeds that they consider comfortable and safe based on their perceptions of the roadway geometry regardless of the speed limit. Therefore, the overall speed of roadways may not be in agreement with the roadway’s intended function.

И какое это имеет отношение к обсуждаемому вопросу?

andriano · 2012-12-03 20:14:33

esaulenka wrote:

В пятый раз? Или в десятый?

Ну хоть в первый.
Можно ссылкой.

esaulenka · 2012-12-03 21:35:02

Ссылаюсь на посты на первой же странице этого же топика.
Да, ответ мне можно не писать.

kisaa · 2012-12-04 00:00:22

dimuzz wrote:

their perceptions of the roadway geometry regardless of the speed limit

Скажите, действительно - что из "roadway geometry" не может учесть алгоритм прокладки маршрута? Количество перекрестков со светофорами? Количество левых поворотов? Качество покрытия? Количество полос движения в каждом (!) направлении? Для всего этого существуют достаточно однозначные теги, которыми и может определяться приоритет дороги.

andriano · 2012-12-04 06:37:29

esaulenka wrote:

Ссылаюсь на посты на первой же странице этого же топика.

Хорошо, специально посмотрел, что есть на первой странице:

Sergey Astakhov wrote:

maxspeed:practical - это типичная скорость основного потока, которая на практике вполне может превышать maxspeed в некоторых местах. 150 - это наверное многовато, но 130 - вполне допускаю, до +20 гайцы обычно не реагируют, все этим и пользуются.

Amigo wrote:

Офф. А дефолтный явно указанный maxspeed или ограниченный maxspeed в НП кусками еще то зло для маршрутизации, некий знак 40, отмеченный на транзитной дороге приводит к таким веселым маршрутам по типа 60-90 км/ч дефолтным дорожкам.

VikDD wrote:

maxspeed:practical=* - это практическая максимальная скорость потока, на неё нельзя ориентироваться в плане "+20 - нет штрафов" и т.д. для этого есть maxspeed=*, на pracical должны ориентироваться программы прокладки маршрутов для учёта "быстро/долго".

fserges wrote:

А я вот не понимаю, почему народ ссылается как на истину в последней инстанции (как на Библию) на коряво написанный текст 2009 года который был по разумным причинам отвергнут сообществом.
Понятно что в идее есть рациональное зерно ну дык довести нужно до ума сначала ...

Delin wrote:

Не вижу логики в том чтобы записывать среднюю скорость потока в тег maxspeed:practical. Хотя бы потому что скорость средняя, а тег - max. на что-то типа averagetrafficspeed я бы еще согласился. Средняя скорость потока, пусть даже она выше ограничения (этот момент непринципиален), нафиг на практике никому не нужна - как правило на разных дорогах все равно все ездят с одинаковой скоростью. По мне гораздо важнее информация о качестве полотна, а уж по ней я гораздо точнее смогу прикинуть как быстро я доеду. А учитывая то, как криво у нас зачастую проложены дороги (с кучей поворотов, чтоб враг не проехал) и интенсивность трафика, можно легко попасть в пробку за тошнотом и уже не важно какой на данной дороге maxspeed:practical - все прогнозы летят к чертям.
Вообщем, не вижу я смысла в maxspeed:practical.

Эцелоп wrote:

Удобно использовать для правильной маршрутизации. Если маршрут кладётся не так, как надо - достаточно понизить и (или) повысить maxspeed:practical на соответствующих участках. Ни для чего другого тег не нужен, это технический "костыль" для алгоритмов построения маршрута.

ikz wrote:

Delin, это не средняя скорость потока. Это достижимая скорость потока. Т.е., если при ограничении 60 поток все равно идет 80 плюс-минус, то это тренд вставить эту скорость в maxspeed:practical.

Вы не находите, что здесь присутствует несколько взаимоисключающих утверждений?
Так какое из них мне выбрать?
Лично я разделяю (по крайней мере, частично) мнение fserges:

Понятно что в идее есть рациональное зерно ну дык довести нужно до ума сначала ...

Именно для этого, собственно, и поднят вопрос.

Да, ответ мне можно не писать.

Можно, конечно.
Но я все-таки хочу получить на свой вопрос ответ, а не отписку.

GaM · 2012-12-04 14:33:17

Я за то, чтобы practical был всегда ниже или равен maxspeed, ибо это бред, нарушальщиков ПДД сжечь просто, причем тут наша карта? оО
Есть люди которые ездят по встречке, так что oneway=no ?

Last edited by GaM (2012-12-04 14:33:42)

Amigo · 2012-12-04 14:47:42

Каким образом значение тега maxspeed:practical может привести к нарушению ПДД?

И еще раз:

Amigo wrote:

Для статистики есть ли здесь кто проставлял этот тег для чего либо иного кроме как для тюнинга маршрутизации?

dkiselev · 2012-12-04 15:47:15

Не то что бы может привести, оно констатирует что вот тут на практике нарушают.

andriano · 2012-12-04 15:56:32

Amigo wrote:

И еще раз:
Amigo wrote:
Для статистики есть ли здесь кто проставлял этот тег для чего либо иного кроме как для тюнинга маршрутизации?

Встречный вопрос: преуспел ли кто в этом нелегком деле?

Т.е. сумел ли добиться, чтобы навигатор строил маршрут "как ездят местные"?
Притом, не для одной фиксированнгой пары "старт-финиш", а для всех маршрутов данного города или хотя бы района?

Т.е. вопрос не в том, кто как этот тег использует, а в том, есть ли от такого использования реальная польза?

Или это своего рода плацебо?

Да, на прямой вопрос - прямой ответ: лично я этот тег ни разу не проставлял. Причина проста - я не понимаю его физического смысла. А дискуссию потому и затеял, что хочу разобраться. Разобраться - для того, чтобы иметь возможность его использовать: как самостоятельно проставлять, так и пользоваться им в своей программе маршрутизации.

Last edited by andriano (2012-12-04 16:09:49)

Ilis · 2012-12-04 16:09:42

GaM wrote:

Есть люди которые ездят по встречке, так что oneway=no ?

oneway:practical=no

Amigo · 2012-12-04 17:18:40

dkiselev wrote:

Не то что бы может привести, оно констатирует что вот тут на практике нарушают.

Ни что он не констатирует, в нынешнем виде это настроечный коэффициент, именно скоростной, отталкивающийся от maxspeed или дефолтной скорости, какова в разных навигационных системах может и не быть 60, 90, 110

andriano wrote:

Т.е. сумел ли добиться, чтобы навигатор строил маршрут "как ездят местные" ?
Притом, не для одной фиксированнгой пары "старт-финиш", а для всех маршрутов данного города или хотя бы района?
Т.е. вопрос не в том, кто как этот тег использует, а в том, есть ли от такого использования реальная польза?

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

Last edited by Amigo (2012-12-04 17:23:38)

Ivan Komarov · 2012-12-04 17:37:24

Я согласен с andriano в том плане, что сущестующий maxspeed:practical - весьма неуклюжий костыль. Но не согласен с тем, что с ним надо бороться. Если он кому-то помогает настраивать существующие алгоритмы навигации - ну и славно. Мне представляется, что гораздо более существенная проблема как раз в существующих алгоритмах маршрутизации, которые не используют (или плоховато используют) объективные характеристики дорог. Я также сомневаюсь, что удастся переубедить общественность отказаться от работающего костыля и придать ему формально корректный, но "неработающий" смысл.

andriano · 2012-12-05 06:03:25

Amigo wrote:

Ни что он не констатирует, в нынешнем виде это настроечный коэффициент, именно скоростной, отталкивающийся от maxspeed или дефолтной скорости, какова в разных навигационных системах может и не быть 60, 90, 110

Ладно, давайте на минутку предположим, что maxspeed:practical может быть настроечным коэффициентом.
Тогда для какой конкретно программы это настроечный коэффициент?

Так как это скоростной коэффициент задача не только добиться "как ездят местные", а скорее "в режиме максимальной скорости" вести по транзитным маршрутам, а не через станицы и поселки.

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

В этом плане мною полностью была отрихтована трасса М4 и множество транзитных маршрутов в Краснодарском крае.

"Вести по трассе" - это задача, вообще недостойная упоминания.
"Рихтовка" может понадобиться лишь в случае построения сложного маршрута, в который входят дороги разной категории.
После "рихтовки" такие маршруты строятся оптимально?

Last edited by andriano (2012-12-05 06:04:16)

andriano · 2012-12-05 06:27:38

Ivan Komarov wrote:

Я согласен с andriano в том плане, что сущестующий maxspeed:practical - весьма неуклюжий костыль. Но не согласен с тем, что с ним надо бороться.

Вот только не нужно приписывать мне точки зрения явно противоположно той, которой я придерживаюсь.
С моей точки зрения "бороться" с какими-либо тегами вообще не нужно - any tag you like.
А вот с неправильным использованием нужных тегов бороться можно и нужно.

Если он кому-то помогает настраивать существующие алгоритмы навигации - ну и славно.

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

Мне представляется, что гораздо более существенная проблема как раз в существующих алгоритмах маршрутизации, которые не используют (или плоховато используют) объективные характеристики дорог.

Полностью согласен.
Именно эта причина и заставила меня задуматься о написании собственного маршрутизатора.

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

Переубеждать "общественность" совсем не обязательно, достаточно убедить DWG.
Другое дело, что мне интересно не полное выпиливание этого тега (как, вероятнее всего, отреагирует DWG), а, наоборот, приведение его к виду пригодному для использованию.
Совершенно очевидно, что в случае, когда общего понимания, что означает этот тег, нет, и каждый использует его кто во что горазд, реальный эффект от его применения может быть лишь чисто психологический (типа: "мне кажется, что он помогает настроить маршрутизацию"). Если один человек в одном месте настраивает его под один алгоритм, а в другом - другой человек под другой алгоритм, то совершенно очевидно, что стоит поменять либо место, либо алгоритм - и все развалится. Но отдельные положительные результаты от конкретной пары место-алгоритм создают у каждого конкретного маппера иллюзию полезности этого тега именно в таком "неопределенном" виде. А на другой паре место-алгоритм он даже не пытался сравнивать, поэтому с отрицательными последствиями существующего положения вещей не знаком.

PS. Думаю, если простой двух шаговый алгоритм:
1. Договориться о единых правилах использования тега.
2. Поправить тег в соответствии с выработанными правилами.
не будет одобрен общественностью, придется воспользоваться более сложным и трудоемким:
1. Жалоба в DWG.
2. Полное выпиливание тега.
3. Новых пропозал на тег (возможно, он будет называться по-другому).
4. Заполнение значений нового тега с нуля.

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

Amigo · 2012-12-05 07:02:51

andriano wrote:

Ну вот - опять каждый маппер понимает этот коэффициент по-своему

Как его можно понимать иначе как здесь можно проехать быстрее, а здесь медленне относительно относительных дефолтных скоростей. Еще раз кто его ставил в здравом уме понимал его как-то иначе?

andriano wrote:

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

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

andriano wrote:

Совершенно очевидно, что в случае, когда общего понимания, что означает этот тег, нет, и каждый использует его кто во что горазд, реальный эффект от его применения может быть лишь чисто психологический (типа: "мне кажется, что он помогает настроить маршрутизацию"). Если один человек в одном месте настраивает его под один алгоритм, а в другом - другой человек под другой алгоритм, то совершенно очевидно, что стоит поменять либо место, либо алгоритм - и все развалится.

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

Last edited by Amigo (2012-12-05 07:23:34)

Ivan Komarov · 2012-12-05 08:17:59

Бороться не нужно, поэтому выпилим под корень. Это явно за пределами моего понимания.

andriano · 2012-12-05 08:32:23

Amigo wrote:

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

Отчего же не нужен? Очень даже нужен!
Мне нужен настроечный коэффициент, отражающий скоростную характеристику фрагмента дороги, и лежащий в диапазоне от -1.0 до 1.0.

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

Алгоритмы маршрутизации чтобы они работали в реалтайме в коробочках простейшие

Здесь необходимо учитывать, минимум, два эффекта:
1. Алгоритмы, хоть и "простейшие" по Вашему мнению, но различающиеся даже в пределах одной навигационной программы - из-за различных режимов работы.
2. Вы несколько недооцениваете вычислительную мощь этих "коробочек". Их тактовая частота в 10 раз, а объем памяти - в несколько десятков раз превосходят аналогичные показатели суперкомпьютера Сray-1. Не следует путать современные "коробчки" с первыми Гарминами.

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

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

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

И тут только два варианта:
1. Либо мы договариваемся и плавно преобразуем одно в другое.
2. Либо мы не договариваемся и вместо плавного перехода - выпиливание с последующим занесением в базу уже другого параметра.

На сегодня ситуация примерно следующая (проценты относительны, но их соотношение примерно верное)
Пусть нам нужна программа, которая минимум в 90% случаях строит правильный маршрут.
Примитивный алгоритм строит приавильный маршрут в среднем в 40% случаев.
Но если снабдить его дополнительным настроечным параметром - можно повысить этот процент в идеале до 80%.
На практике удается достичь величины 70%.
Пусть мы придумали алгоритм, который строит правильный маршрут в 70% случаев.
При наличии подгоночного параметра этот процент можно довести до 95%.
Но на неверных данных процент снижается до 50%.
А данные уже покорежены под первых алгоритм.
Поэтому заведомо более хороший алгоритм на существующих (деформированных) данных ведет себя хуже, чем примитивный.
К чему это приводит?
А к тому, что подгонка данных под алгоритм, который принципиально не способен обеспечить высокий процент правильно построенных маршрутов тормозит прогресс в области разработки алгоритмов маршрутизации.

Описан - простейший вариант. На практике - все гораздо хуже:
Пользователь А, используя навигационную программу Б в районе В рихтует данные так, чтобы повысить процент попаданий с 40% до 60%.
Пользователь Г, используя навигационную программу Д в районе Е рихтует данные так, чтобы повысить процент попаданий с 40% до 60%.
В результате процент попаданий навигационной программы Б в районе Е, а также процент попаданий Д в районе В снижаются до 20%.
Но пользователи А и Г об этом не знают и искренне полагают, что их действия способствуют улучшению качества маршрутизации.
Но беда в том, что программ маршрутизации существенно более двух, и почти в каждой предусмотрен выбор из двух или нескольких алгоритмов маршрутизации, поэтому, улучшая характеристики маршрутизации в одном районе при помощи одной программы, одновременно ухудшаются характеристики во всех остальных районах для всех остальных программ.
Только каждый маппер видит только свой район и только свою программу и об этом даже не догадывается.
А когда он приезжает в чужой район, и даже понимает, что маршрут проложен далеко не оптимально (а понять это в чужом районе далеко не всегда просто), он искренне полагает, что дело не в том, что порочен сам подход, а лишь в том, что местные мапперы оказались недостаточно тщательными.

Ivan Komarov · 2012-12-05 08:43:24

Судьба этого тега мне достаточно безразлична, но можно поинтересоваться, откуда уверенность в том, что DWG его выпил ит по запросу?

Announcement

#251 2012-12-03 17:01:22

Re: Ещё раз про maxspeed:practical

#252 2012-12-03 17:03:37

Re: Ещё раз про maxspeed:practical

#253 2012-12-03 17:16:10

Re: Ещё раз про maxspeed:practical

#254 2012-12-03 17:20:55

Re: Ещё раз про maxspeed:practical

#255 2012-12-03 17:34:11

Re: Ещё раз про maxspeed:practical

#256 2012-12-03 17:43:22

Re: Ещё раз про maxspeed:practical

#257 2012-12-03 20:09:12

Re: Ещё раз про maxspeed:practical

#258 2012-12-03 20:13:44

Re: Ещё раз про maxspeed:practical

#259 2012-12-03 20:14:33

Re: Ещё раз про maxspeed:practical

#260 2012-12-03 21:35:02

Re: Ещё раз про maxspeed:practical

#261 2012-12-04 00:00:22

Re: Ещё раз про maxspeed:practical

#262 2012-12-04 06:37:29

Re: Ещё раз про maxspeed:practical

#263 2012-12-04 14:33:17

Re: Ещё раз про maxspeed:practical

#264 2012-12-04 14:47:42

Re: Ещё раз про maxspeed:practical

#265 2012-12-04 15:47:15

Re: Ещё раз про maxspeed:practical

#266 2012-12-04 15:56:32

Re: Ещё раз про maxspeed:practical

#267 2012-12-04 16:09:42

Re: Ещё раз про maxspeed:practical

#268 2012-12-04 17:18:40

Re: Ещё раз про maxspeed:practical

#269 2012-12-04 17:37:24

Re: Ещё раз про maxspeed:practical

#270 2012-12-05 06:03:25

Re: Ещё раз про maxspeed:practical

#271 2012-12-05 06:27:38

Re: Ещё раз про maxspeed:practical

#272 2012-12-05 07:02:51

Re: Ещё раз про maxspeed:practical

#273 2012-12-05 08:17:59

Re: Ещё раз про maxspeed:practical

#274 2012-12-05 08:32:23

Re: Ещё раз про maxspeed:practical

#275 2012-12-05 08:43:24

Re: Ещё раз про maxspeed:practical

Board footer