Подготовка базы для ж/д роутинга

http://ru.wikipedia.org/wiki/Серебряный_Бор_%28станция%29

В Ховрино черт ногу сломит. Там ведь остановок поездов-то не одна. Платформа Моссельмаш находится на территории станции, как я понимаю.
А где там диспетчер — кто его знает.

Станция “Подмосковная” http://osm.org/go/0t2cq9JxR-

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

В том и проблема что там вообще нет и не должно быть точек остановки которые public_transport=stop_position.

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

station это station. А точка отсчёта это точка отсчёта. Нужна последняя, на путях, и не public_transport=stop_position

Тут я имел ввиду станцию не в виде строения, а именно как носителя названия. Например как разные места с названиями 800 км. в чистом поле. Тут же не надо ставить точку где-то рядом, логично что она будет стоять именно на пути.

Я тоже.

Да, но путей несколько, а станция может быть только одна.

Да, но роутинг пойдет по одному пути, а не по всем.

И если маршрут возможен только через другой путь, ничего не будет работать.

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

“Пучок” - это несколько несоединённых физически путей. Даже если они идут параллельно, на одном из них может физически не быть остановки на соседней станции, а они могут и вообще расходиться в противоположные стороны. И односторонние пути очень даже присутствуют.

Ну вот самый отстойный вариант:

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

К чему этот глупый спор? Не будет роутинга, точка.

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

Не зависит, ибо речь идёт о исправлении ошибок в данных, а не о костыляции.

К слову, хочу обратить внимание что в relation:route включаются именно станиции, а не stop_position. Так, убирать из маршрутов станции, добавляя stop_position - это ошибка. Чтобы с этим не было путаницы - ещё один из аргументов для разделения станций и stop_position.

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

Смысл моего начинания - найти ошибки, а не получить абы как работающий роутинг.