Вообще-то с моей точки зрения 50, 50а и 50м – это не самостоятельные маршруты, а варианты одного маршрута № 50. Отсюда и нежелание обозначать их по всей длине маршрута.
Ну а как быть с роутингом? И вообще, садиться на этот маршрут или нет, если я хочу доехать до определенной остановки?
Ну я уже написал об этом выше. Роутинг предложит сесть на 50-й и ближе к концу пересесть на 50а. Я подойду к остановке 50-го и увижу, что там же ходит 50а, и дождусь его…
Надо продумать вложенность маршрутов. В отношение, описывающее маршрут, могут входить линии (сегменты пути), точки (остановочные пункты); почему бы не позволить входить туда и третьему типу объектов, отношению?
В данном примере будет так. Есть отношение, которое содержит общую часть маршрутов 50, 50а, 50м. Тэг “ref” ему присваивать не надо, ведь оно не соответствует конкретному маршруту. Второе отношение, у которого тэг ref=50, а члены: линия 47502198 (Амундсена), остановки вдоль этой линии и вышеупомянутое общее отношение. Третье отношение для маршрута 50а, тэг ref=50а, члены: точка 599905966, линия 35193648 (ул. Краснолесья), общее отношение. То же самое для четвертого отношения, которое описывает маршрут 50м.
Тогда будет легко видно, что у маршрутов есть общая часть, и править придется только одно отношение, а не все три — если правки касаются общей части.
Прошу прощения за усаживание не в свои сани - маршруты 
Но уж очень странно читать о подобных проблемах в столь продвинутой системе по отрисовке маршрутов…
Вот у нас, в ГИС, никому и в голову не придёт рисовать ложащиеся друг на друга “маршруты”.
- Будут отрисованы сегменты “от остановки до остановки”, возможно, раздробленные ещё и на “от остановки до перекрёстка”, возможно ещё и на “от перекрёстка до перекрёстка”.
- В БД для каждого сегмента будет указан перечень следующих по нему № маршрутов.
- Будет сделан сервис запроса “№ маршрута” и подсвечиваться все сегменты имеющие к этому маршруту отношение.
- Будет сделан сервис запроса “Все маршруты в этом сегменте” и будет выводится список маршрутов, следующих по этому сегменту.
Вот как-то так в ГИС-ах реализуются такие задачи…
В ОСМ всё точно так же 
Проблема в том, чтобы сегментам дороги не присваивать три вариации одного маршрута, потому что на этом сегменте будет нарисовано “23,50,50а,50м,76”…
Как говорят лица “цыганской национальности” 
Я ТОЛЬКО СПРОСИТЬ!
А на хрена? ПИСАТЬ номера маршрутов на сегментах трасс?
По-моему, гораздо правильнее писать их где-то на остановках?
Ведь, как пишет в другой теме уважаемый (чесс слово!) Zkir именно на остановках “висят АНШЛАГИ с номерами маршрутов”. Так что - полное реалити
PS. А на дорогах я никаких номеров маршрутов не видел Там всё какие-то полосочки беленькие намалёваны: тоненькие и ширенькие…
Provincial, вы просто осознайте пользу от знания не только остановочных пунктов, но и маршрута следования общественного транспорта. :3
Прежде всего, роутинг, как у гугла и прочих.
“Пройдите 122 метра до остановки Синий кот, садитесь на автобус №32, 33 или 51, выйдите на конечной…”
Или автогенерация схемы наземного транспорта города.
Тогда давайте нарисуем ездящие по карте маленькие автобусики с номерами маршрутов на спине, будет еще больше похоже на реальность. А степень пробок отображать скоростью и количеством машин на сегменте дороги. Будет еще более полное реалити.
Не нужно доводить до абсурда. Номера маршрутов нужны, чтобы понять, какой куда едет. Гораздо проще проследить за подписаной линией, чем за чередой точек.
Постойте, если я правильно понял, это вопрос отрисовки (рендеринга) маршрута, к этой теме он не имеет отношения. Мапник вообще их не отрисовывает
А реализовать можно как угодно, с предложениями сюда: http://forum.openstreetmap.org/viewtopic.php?id=5830
Сейчас в теме imho обсуждается именно как проставлять данные маршрутов на карте, стоит ли их объединять и комбинировать через использование relations внутри relations типа route. Если вы о том, стоит ли в БД указывать у маршрутов их сегменты (дороги), то это эквивалентно указанию на сегментах (дорогах) номеров проходящих маршрутов, как это реализовано “у вас”:
Не рисуем для рендерера. Если сейчас вам не нравится, как будут отрисовываться маршруты - высказываем пожелания в соответствующей теме. Будем потихоньку делать красивее.
Я осознаю пользу от знания “не только остановочных пунктов, но и маршрута следования общественного транспорта”
Но, не очень осознаю пользу от “подписывания” номеров маршрутов на трассах 
Особенно, для “роутинга”
“маленькие автобусики с номерами маршрутов на спине” - эту идею Вы зря забесплатно отдаёте. Так вот как будет выглядеть информационный сайт о движении общественного транспорта в Рыбинске!
“Номера маршрутов нужны, чтобы понять, какой куда едет.”
А знать, “какой где останавливается?” - не интересно?
Ну, будете в Рыбинске - попробуйте сесть на “16э”, ориентируясь по Вашим “нумеркам” на трассах. Он Вас на половине остановок прокинет, может быть поумнеете…
Provincial,
никто не подписывает маршруты на дорогах.
Наоборот, есть некая сущность “маршрут”, в которую включаются остановки этого маршрута и дороги, по которым он проходит
Это я “догоняю”.
Моя речь о том, что “визуализация” номера маршрута на трассе менее важна, чем “визуализация” номера маршрута на ОСТАНОВКЕ.
Во всяком случае, для “читающего карту ГЛАЗАМИ” пассажира.
А для программ все эти “отрендеренные” цифири нах не нужны…
Предлагаю подумать над созданием голосовалок: 1) для тега network добавить значение city (городские маршруты)
-
тег route использовать преимущественно для обозначения размеров ТС: до классических пазиков включительно share_taxi, больше - bus
(т.к. пазики в большинстве своем используются как маршрутки, а не на регулярных маршрутах) либо критерии разделения оставить на совесть местных рисовальщиков, ведь в разных регионах по-разному. -
ввести тег для разграничения частных/муниципальных маршрутов – если сообществу не нравится определять это через название оператора.
например, social = yes/no или commercial = yes/no (какой перевод лучше отражает суть?)
Есть такая штука: бритва Оккама. Вот наплодите вы релейшенов содержащих релейшены и как с ними работать? Да, рисовать, может быть, удобнее, но обрабатывать в программах ужасно. Это приведет к багам. Да и вы сами замучаетесь этакие многоуровнеые отношения строить. С точки зрения хранения информации только по отдельному релейшену на маршрут.
А вот при отображении можно пытаться что-то оптимизировать, например написать 50[ аб] вместо 50, 50а, 50б.
Во фрагмент программы, который собирает сегменты маршрута в единую структуру, всего лишь добавится рекурсия по вложенным отношениям.
Но я согласен, что может быть, оно того не стоит; тогда будем считать, что это разные маршруты, просто у них в названиях различие небольшое.
Согласен с Alexey Guseynov, по 1 релейшену на маршрут. Ради наших частных случаев не стоит доделывать всю систему :]
Для решения проблемы, которую предлагали решать через вложенные релейшены есть и другое, более простое решение, которое должно работать даже без доработок текущего ПО.
Идея вот какая: вместо релейшна с общим куском маршрута рисуется вей (можно даже без тегов) по тем же узлам что и highway=*. Естественно этот вей может включать несколько разных улиц.
Этот вей и включаем в маршрутные релейшены. Итого профит вот какой:
- поддержка в софте уже есть - вряд-ли кто-то смотрит по какому хайвэю идет маршрут
- нет необходимости рвать главную дорогу на каждом выезде автобуса с hw=service
- проще редактировать релейшны маршрутов
И как основной плюс, такой подход позволит отразить тем моменты, которые при той схеме что описана в вики отобразить практически невозможно без повсеместного использования двух вэев для одной дороги.
Абсолютно против.
Если рисовать по общим узлам хайвеев,
- задача “какие маршруты проходят по этой улице” начинает решаться на порядок сложнее
- задача “проходят ли два этих маршрута по одному участку” - аналогично
- толковых инструментов для работы с такими веями нет. со временем улицу уточнят, а вей по всем канонам осм - “я не понимаю что это, не буду трогать”