Многофункциональный комплекс - как оформлять и обозначать

[Mic]

Если я правильно понял участка контроля средней скорости не будет. А если появиться то это в далеком будущем? Тогда придется ставить по две точки на одну пару камер... Даже наверное тремя точками.

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

[MVV23RUS]

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

Вот именно.
и не только для дроида, но и для остальных осей.
а то зациклились на наращивании функционала только на нём. а на остальных он отстаёт на полгода - год.

[NickF]

Уже есть тип точки

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

[valur111]

А разве к управлению АТС допущены лица с нарушением цветовосприятия?

[12alexd21]

А разве к управлению АТС допущены лица с нарушением цветовосприятия?

Да.

[action_64]

Не думаю что такая проблема получить справку. Год назад менял права, проверяли только на сколько хорошо видишь.

[12alexd21]

Проблема насущная - факт.
Сам уже попадался на "комплексы".
Есть толковые предложения, от mitraleks например или от stroy82, осталось только реализовать
В первую очередь, ИМХО, нужно отобразить направление камер полосы (лоб/тыл) и комплексные камеры, пока  хотя бы общим словом (значком), ну а в дальнейшем уже "расписывать", какие именно нарушения фиксирует   комплекс.

[valur111]

А разве к управлению АТС допущены лица с нарушением цветовосприятия?

Да.

В соответствии с "Приложением N 2 к ПриказуМинздравсоцразвития России от 12.04.2011 N 302н (ред. от 05.12.2014)...", нарушение цветоощущения является медицинским противопоказанием для управления тр.ср-вами (п.27.1, графа "Дополнительные медицинские противопоказания", подпункт 13).

[stroy82]

Текст версии и таблицы поправлен, подправлен. Страшный п.2 для шанса приемственности перенесён в конец текста.  http://mapcam.info/forum/index.php?topic=3387.msg50003#msg50003

1. Необходимо отказаться от типа камер "Камера, измеряющая скорость (в спину)". Принять понятие "Направление контроля": Встречное, Попутное, Встречное и Попутное(оба). Т.к. "Направление контроля"  является лишь признаком вектора направленности основной функции учёта и контроля. При оформлении объекта должна быть возможность выбора "Направления контроля".       

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

Раздельную настройку для каждого направления никто не отменял, если это очень критично. Но и сейчас MCD голосом оповещает один раз, остальное в графике на экране. Неужели водитель забудет за 5 секунд о том, что его предупредили и о встречном и о попутном контроле? В чём суть вопроса о мотоциклисте?

Если убрать разделение в спину тип точки - получиться что данные камеры попадут в стандартную базу что отрицательно скажется сервиса. Извините меня stroy82 но мобильные засады и некоторые вещи не в тему, хотя с некоторыми вещами я с вами согласен а с какими то нет.

При представленной или любой другой концепции развития учёт направления становится гибким настолько, что ввести попутный контроль в спину можно и для любой Полосы и для Средней скорости. И видение (ударение на первую "и") "мобильных Засад и некоторых вещей"(из цитаты action_64) к Вам придёт, не расстраивайтесь, Вы перспективный молодой человек.
 В данном варианте представлен не алгоритм, а концепция. Концепцию рассматривают, рабочая или нет, а нравиться всем она и не должна. Это как концпт-кар - новый, необычный, непривычный, заумный...
 Чтобы Mic "торкнуло" нужны ещё версии. Предлагайте.

[NickF]

Хотелось бы, чтоб МФК как-то отличался не только по цвету...
Тут как-то меняли камЕРЫ СРЕДНЕЙ СКОРОСТИ... Мы все привыкли, что они желтые и значок парой.... А когда осталась пара и стало синим, как обычные камеры - это не есть камильфо... Вернули оперативно...
Это я к тому, что цвет конечно важно, но если разработчики учтут и этот вариант - хуже не будет точно

[NightWatcher]

В чём суть вопроса о мотоциклисте?

Суть вопроса в том, что мотоциклистов не интересуют камеры, контролирующие нарушения "в лоб", им нужны только предупреждения о камерах в спину, способные распознать их ГРЗ. Если объект будет один, но иметь разные свойства направлений контроля, то как, например, отключить оповещение о камерах, контролирующих скорость в лоб и отдельно настроить оповещения о камерах в спину, если оповещение настраивается для конкретного типа объектов. Разделение способов оповещения по свойствам внутри одного объекта повлечет за собой серьезную переработку программного кода, что может оттянуть реализацию на значительное время. Плюс непонятна работа проекта во время переходного периода, ведь многие по разным причинам останутся на старой версии и как обеспечить совместную работу таких кардинально отличающихся алгоритмов? При введении отдельных типов "в спину" такого масштабного изменения работы не потребуется.

[stroy82]

 Всесторонний учёт и оповещение из него - разные вещи. От целого твёрдого куска трудно или невозможно отделить часть нужного размера, но если целый твёрдый кусок будет состоять из множества небольших размеренных кусочков, то выделить, и учесть каждый не составит труда. Это всего лишь работа настроек оповещения. Хотите только попутный контроль в спину? Настраивайте оповещение с учётом направления и пользуйтесь. Хотите только муляжи мобильных Засад? Настраивайте и пользуйтесь, Стационарные муляжи - пожалуйста.
 А так, например, по заявкам придётся делать типы объектов: участок средней скорости попутно (в спину), полосы ОТ попутно (в спину), Обочины попутно (в спину), нарушения на ПП попутно (в спину), светофора попутно (в спину)... Плюс "удвоение" Базы при раздельном учёте, её содержание и обслуживание... 
 
 

[12alexd21]

Всесторонний учёт и оповещение из него - разные вещи. От целого твёрдого куска трудно или невозможно отделить часть нужного размера, но если целый твёрдый кусок будет состоять из множества небольших размеренных кусочков, то выделить, и учесть каждый не составит труда. Это всего лишь работа настроек оповещения. Хотите только попутный контроль в спину? Настраивайте оповещение с учётом направления и пользуйтесь. Хотите только муляжи мобильных Засад? Настраивайте и пользуйтесь, Стационарные муляжи - пожалуйста.
 А так, например, по заявкам придётся делать типы объектов: участок средней скорости попутно (в спину), полосы ОТ попутно (в спину), Обочины попутно (в спину), нарушения на ПП попутно (в спину), светофора попутно (в спину)... Плюс "удвоение" Базы при раздельном учёте, её содержание и обслуживание...

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

[NightWatcher]

А так, например, по заявкам придётся делать типы объектов: участок средней скорости попутно (в спину), полосы ОТ попутно (в спину), Обочины попутно (в спину), нарушения на ПП попутно (в спину), светофора попутно (в спину)... Плюс "удвоение" Базы при раздельном учёте, её содержание и обслуживание...

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

[MVV23RUS]

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

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