Просто надо показывать не name, а свойство pk. Или зачем-то придумали новое недоделанное distance.
Только имейте ввиду, обратный километраж хранится в другом теге:
check_date=2013-05-14
highway=milestone
pk=133 km
pk:backward=76 km
source=survey
Иногда в другом, иногда в том же, но через слэш, иногда отсутствует, а иногда прямой и обратный перепутаны местами 
а где это сделать? и можно как-то в запросе это реализовать?
Кстати кроме pk, есть псевдоним kp специально для англофилов или плохопонимающих французский.
“зачем-то” - так почитайте же зачем придумали, там описано, а вот обоснование вашей позиции в вашем сообщении отсутствует, в чем недоделанность не раскрыто.
Тег мутен с самого названия milestone, а расстояние по умолчанию в километрах 
С запросом всё в порядке. Он вытаскивает все объкты с искомыми тегами, в данном случае точки highway=milestone, находящиеся внутри заданной области. Экспортируя результаты запроса, вы сохраняете их в файл, выбрав удобный вам формат.
Большинство настольных ГИС позволяют редактировать атрибутику. Вам нужно взять колонки pk и pk:backward и слить их значения (разделив косой чертой) в колонку name. Или просто переименовать колонку pk.
Наконец, все эти форматы - текстовые. То есть редактируются в любом текстовом редакторе, лично мне нравится notepad++. Воспользовавшись функцией “поиск и замена”, можно поменять все “pk”(вместе с кавычками, если речь о формате geojson) на “name”(тоже с кавычками).
И да, 142 объекта в запросе gryphon’а вместо pk имеют тег distance.
Поскольку речь пошла о теге distance, как его правильно применять?
Допустим, было pk=133 km + pk:backward=76 km, по замыслу должно стать distance=133/76 ?
По замыслу “distance=133”, про backward замысел умалчивает, как и в случае pk. Я бы ставил “distance:backward=76”.
Ура! Все получилось, спасибо всем огромное!
Экспортировала сначала из KML, программа все атрибуты не отображала, а сейчас попробовала через доп. модуль из geojson - все есть. Очень крутая штука overpass))
про backward замысел умалчивает
Именно про это я и говорил, переименовать переименовали, а до ума не довели.
Да я не уверен, что обозначать на столбах backward — это не чисто советская традиция. Подозреваю, что авторы просто о таком не слышали.
Не помню, как в Англии. В США - точно нумерация однонаправленная. На одном шоссе двух milepost-ов с одинаковыми числами в разных местах быть не может.
Эта линия не рендерится как часть маршрута троллейбуса:
http://openstreetmap.ru/#map=18/48.72628/37.54214&layer=ST
Ошибка в данных или в рендерере?
А вот вопрос: как работает поиск на странице http://www.openstreetmap.org ?
Попробовал в первый раз им воспользоваться, и обнаружил, что найти можно только то, что является значением тега name. Более того, это содержимое должно быть запрошено в точности — если например я пытаюсь найти “улица Выставочная”, то и запрашивать надо именно так, по запросу просто “Выставочная” ничего не найдется. И получается, если объект не имеет имени - то его поиском и найти нельзя. А если он еще и не отображается (swing_gate например)…
Это так и задумано, или я совсем ничего не понимаю?
edward17, возможно что-то с порядком линий. У вас ни одной остановки в маршруте (stop_position и platform), что не очень хорошо. Также неплохо бы указать from и to (даже если они совпадают).
Renord, вам сюда http://wiki.openstreetmap.org/wiki/RU:Nominatim.
А улицы не обязательно полностью вбивать. По крайней мере через населенный пункт это работает. Запрос вида “Москва твардовского 1” выдаст дом, если номер убрать выдаст улицу.
Не знаю, но соседние линии являются соседними участниками отношеня. То есть, в том месте с порядком линий всё хорошо.
Спасибо, но тот маршрут делал не я. Как руки дойдут, отпишусь автору с просьбой исправить или поправлю сам.
Да и здесь тоже:
http://www.openstreetmap.org/#map=18/48.72610/37.54229&layers=T
Спасибо, значит проблема действительно в программе.
У меня есть предположение, что эта линия не рендерится из-за highway=tertiary_link.