Итак, по транспортной сети. Продолжаю крутить Криворожский скорик. Сразу скажу - данный пример не по принципу роут-мастера. В каждое направление - отдельные линии маршрута. Так же хочу определить основную идею - минимум дублирующейся информации и её упорядоченность на каждом из уровней материнских и дочерних отношений. В договорной деятельности есть такое понятие, как “границы балансовой принадлежности”, поэтому довольно важно понимать, где кончается ответственность одних и начинается ответственность других. Кроме того, есть элементы, которые одновременно обслуживают несколько компаний. Как пример - линию highway=…, если по ней ходит троллейбус и над проезжей частью находится контактная линия будут обслуживать не только дорожники, но и предприятие, обслуживающее работу троллейбуса. Поэтому, хоть и не напрямую, к линии highway=… необходимо на одном из уровней поместить operator=…

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

1. Маршруты. Тут все не очень сложно. Состоят из самих линий, по которым транспорт движется, точек остановки самого транспорта на проезжей части и платформ для пассажиров (точка или линия, вплетенная в пешеходную навигационную сеть). Вики предлагает именно такую иерархию. Её и будем придерживаться в дальнейшем. Пока придумывал, как это все сделать, сделал в точности до наоборот. Обязательно изменю порядок в дальнейшем. Основные теги этого отношения (type=route) решил выделить откуда и куда (from=… ; to=…) движется маршрут, его colour=…, его номер ref=…, вид маршрута route=… (в моем случае light_rail) и его name=… То есть информация, касающаяся ТОЛЬКО информации о маршруте.

2. Территории. Тут немного сложнее. Как ярко выраженный пример можно выделить территорию депо или станции. Обслуживанием данных территорий также занимается компания-перевозчик. Здесь же мы сталкиваемся с еще одним под-отношением - type=public_transport + public_transport=stop_area. Для дорожного транспорта сюда будут входить точки остановки самого транспорта на проезжей части и платформ для пассажиров (точка или линия, вплетенная в пешеходную навигационную сеть). В моем случае сюда будут еще и входить территории станций. Кроме того я столкнулся с таким, что почти каждая станция Криворожского скоростного имеет свою страницу на Википедии. Было бы очень правильно в данное отношение внести ссылку на статью.

После создания отношений маршрутов и остановок, с добавлением территорий депо и прочих огороженных территорий (скоростной, к примеру, ездит по поверхности за забором, куда доступа кроме как у обслуживающей компании нет) все они связывается в большое материнское отношение type=network. И уже сюда вносится информация о том, кто operator=… данной сети, общее название предприятия, ссылки на офф сайт, телефоны и тд.

Таким образом единственная информация, которая будет дублироваться, это name=… в отношении type=public_transport + public_transport=stop_area и точкой остановки общественного транспорта на проезжей части. По большей части чисто ради рендера. Ибо из отношения name=… не отображается. И то это скорее применимо для дорожного транспорта. В случаях, где есть станции, можно дублировать name=… на точку или полигон станции.