Для меня, например, не до конца очевидно, должно ли такое отношение включать только два члена, или больше - тоже нормально (при условии, если логика именно такова). Несколько входов на одну станцию или в одно заведение - могут быть. Один вход в несколько заведений или на несколько станций - тоже. Даже несколько входов в несколько заведений или станций - тоже. Но надо ли каждую возможную пару обозначать отдельным отношением или достаточно одного (при условии что тип exit|entrance|both один) - не знаю. Идеи принимаются.
Еще мысль, пришедшая после прочтения того, что написал выше - можно добавить третью роль - route, в том случае, если между объектом, куда ведет вход, и точкой, где находится сам вход, есть некая линия (как в случае того же подземного перехода). Но это может быть избыточно. Хотя как необязательная возможность - может для чего-нибудь пригодиться.
Если “relation типа entrance” то значит 1 вход много объектов. К тому же в большинстве случаев входов меньше, чем объектов.
Если вводить роль “путь”, то еще может быть.
А если нет, то поясните - во-первых, я не вижу связи, почему обязательно должен быть один вход, во-вторых, большинство случаев тут точно не при чем, потому что с обратными случаями что-то надо делать, а логического препятствия сделать отношение “много входов - один объект” я не вижу. Собственно, хочется аргументов, а не просто краткого описания взгляда на проблему.
Объекты обозначаются не только для того чтобы их можно было найти/показать, но и чтобы их можно было учитывать в тех же алгоритмах маршрутизации. А турникеты (или те же эскалаторы) - это объекты, очевидным образом на них влияющие. Ну и маршрутизация бывает не только для использования в навигаторах, но и для других сервисов, типа планирования поездок с учётом метро, расчёта дистанций и т.п.
Ну тогда уж надо вводить highway=indoor_path и объединять все возможные соединения дверей и пои.
pfg21
(Paul)
187
freeExec, может хватить насиловать hw ?? на него и так уж всех собак повесили 
“широкополосной_тракт=проход_внутри_здания” ну как то не логично.
Что в этом плохого ? Или надо придумать ещё десяток namespace’ов но всё так же вешать на них покрытие, проходимость и т.д.
AMDmi3
189
Нет, не логично то что в highway понапиханы всякие street_lamp, bus_stop и crossing, а вот то что там наличествуют все возможные дороги как раз единственно правильно.
Надо бы определиться, рисуем ли мы метро по схеме public_transport или по старинке.
Вносит новые элементы по схеме public_transport - обязательно/нельзя/допустимо/желательно или как?
Вот тут public_transport только в “см. также”:
http://wiki.openstreetmap.org/wiki/User:Zverik/%D0%9C%D0%B5%D1%82%D1%80%D0%BE
Я вот начал понемногу
https://www.openstreetmap.org/relation/3867379
http://www.openstreetmap.org/relation/3831798
Сейчас на почту пришёл вопрос от sim, по обсуждению решили поднять вопрос на форуме
Если внедряем новую схему, надо ещё определиться, в каком масштабе сохраняем старую схему - для рендеров и прочего.
ИМХО:
- Новые элементы рисовать по схеме public_transport - крайне желательно.
- От старой схемы сохраняем только railway=station в центре (на эту же точку вешаем public_transport=station)
- “Откатывать” объекты с новой схемы на старую - запрещено
- Входы в метро - по текущей схеме
- Маршрут поезда на линии - только один, от начальной до конечной, без неполных
- Станции, связанные переходами - связываем в stop_area второго уровня.
Zverik предложил отмечать railway=subway_entrance турникеты, но не сказал ничего о спусках в метро, у которых данный тег «экспроприируется». В public_transport об этом вообще не упоминается.
Как-то всё это странно получается.
Zverik
(Ilya Zverev)
192
Я уже сам склоняюсь к тому, чтобы subway_entrance ставить на входы и спуски, а для турникетов придумать отдельный barrier.
petrovnn
(Петров Николай)
193
может окажется полезным, и вроде в тему топика.
Проект в котором можно выбрать маршрут в метро с учетом конкретного входа.
Отображаются параметры входов, насколько я понял для инвалидов и мам с колясками: лифты, лесницы, ширина колес, угол наклона и тд.
http://metro4all.org/ru/spb/#stat-start=6&stat-end=42&portal-out=1504&portal-in=1072
sim
(Максим Дубинин)
194
собственно именно под этот проект мы и хотим улучшить ситуацию с картированием метро в ОСМе, пока “привязаться” качественно к инфраструктуре не получается, слишком много бардака
Поэтому хочется услышать возможную критику схемы public_transport (не для какого-то проекта), а в принципе.
В первую очередь хочется иметь возможность в ОСМ серией несложных манипуляций получать выборку по всем объектам транспортной инфраструктуры сразу и по её частям отдельно. Например одним максимально коротким правилом (для рендера, конвертора и любого другого случая обработки данных) выбрать все объекты (включая переходы, лестницы, двери, входы, выходы, торговые автоматы на подземных станциях и т.д., относящиеся, например, к метро, не гадая по тегам layer, как сейчас. Что бы иметь возможность без ручного визуального отсеивания объектов, автоматически рисовать ту же карту метро отдельно. Или например в сочетании с тегом layer исключить из рендеринга на веб карте все подземные платформы, переходы и прочее, не исключая при этом совершенно сторонние объекты в других частях карты с отрицательными layer.
Уже есть barrier=turnstile, добавить лишь fee=yes
AMDmi3
197
А в чём проблема применения PT для метро? Отличий от железной дороги нет.
ИМХО, в public_transport надо получать так:
- все (nodes) public_transport=stop_position+subway=yes в нужной зоне
- все relations public_transport=stop_area, в которые входят полученные точки, включая все объекты этих relations
- все relations public_transport=stop_area, в которые входят полученные relations
- все relations route=subway+type=route в нужной зоне (или по всем имеющимся объектам), включая все объекты в этих relations
- все relations type=route_master+route_master=subway, в нужной зоне (или по всем имеющимся объектам)
- все (nodes/ways) public_transport=platform+subway=yes - на всякий случай, это не совсем по схеме
P.S. не проверял
Обычно всё заканчивается на первом пункте, поскольку тег subway=yes в лучшем случае присутствует только у рельс и иногда у чего нибудь ещё. Ни у одного перехода в метро кроме layer=-4 не было замечено ничего и в одном отношении, они как правило не участвуют.
Ну сейчас-то да. Но давайте разделим текущую ситуацию, когда метро никак не нарисовано по схеме public_transport и перспективную, когда метро будет отрисовано.
Я предлагаю обсуждать перспективную, в разрезе переделываем всё на public_transport или нет.
ИМХО, как раз для задачи “загрузить из базы только метро”, public_transport даёт преимущество.
Я вот зеленоградские автобусы стараюсь поддерживать по схеме, только stop_position почти нет, зато есть все public_transport=platform и они с bus=yes
Можно на них опробовать загрузку из базы только объектов транспортной инфраструктуры.
