А это нормально, что практически на каждом перекрёстке будет этот рестрикшон?
Он должен быть везде, где есть знаки. Да, это абсолютно нормально.
Ну вот примерно так: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
Ну вот опять: “It obsoletes highway=give_way”.
И понеслось выпиливание…
Точки give_way - это простая и удобная для маппинга схема, которая работает в большинстве случаев. Если для сложных нужен relation - прекрасно, ставьте, но только точки не трогайте.
Это убогая и неработающая схема, поскольку кроме как палку с картинкой она ничего отметить не способна (на самом деле она и на это неспособна, ибо не показывает направление знака). Если прочитаете дальше первой строчки, будет список причин этому. Далее, во-первых, устаревание не означает выпиливание, во-вторых, в схеме есть member location_hint, который полностью покрывает функциональность highway=give_way.
Пусть знаки остаются, хотя бы как ориентир. Мапим же отдельные деревья. Да и кто знает, когда, что и зачем понадобиться.
Ещё раз: в предложенном отношении знаки маппятся через точку с role=location_hint, так что мало того что они никуда не исчезают, они ещё и становятся привязаны к перекрёстку и отношению.
На страничке с описанием схемы явно прописано правило, что действие распространяется на ближайшее пересечение. Этого вполне достаточно для многих применений, как для показа знака в навигаторе, так и для использования в маршрутизаторе. Хотите описывать сложным способом - пожалуйста, но он не является заменой простому и вполне работающему.
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
А можно помедленнее? Э-э-э, по-русски. В двух словах.
Есть ли устоявшийся тег для Дома Культуры/Клуба?
Сейчаc многие обозначены нерекомендуемым amenity=public_building
А amenity=community_centre не ближе?
Или пора вводить что-то вроде amenity=house_culture?
То же не могу принять участие, пока не будет перевода, для меня что китайский, что марсианский, что английский… Так что посмотрел картинки, в связи с чем на всякий случай, бывает и так:
практический пример я приводил выше.
Переведу на досуге.
В двух словах - почти полный аналог отношений restriction. Отношение с type=give_way, в членах с ролью from - второстепенные дороги, в членах с ролью to - главные, в via точка перекрёстка. Отличие от restriction - from и to может быть сколько угодно, и они не обязаны заканчиваться на перекрёстке.
Элементарно.
<relation>
<tag k="type" v="give_way">
<member type="way" id="1" role="to">
<member type="way" id="2" role="from">
<member type="way" id="3" role="from">
</relation>
либо, если 2 и 3 это один way:
<relation>
<tag k="type" v="give_way">
<member type="way" id="1" role="to">
<member type="way" id="23" role="from">
</relation>
А можно в этом пропозале обойтись без дробления веев, по примеру road_sign (в его версии с нодами, а не с веями) ? Уже живого места в ОСМ нет, всё порубили на мелкие кусочки, включая roundabout-ы. Спасибо.
Прочитай пропозал или хотя бы последний пост.
Читал. Перечитал ещё раз. Вижу
member type="way" role="from"
member type="way" role="to"
не вижу ни одного примера с
member type="node" role="from"
member type="node" role="to"
give_way - отношение сегментов дорог, а не точек на них. Лишнего дробления не будет, потому что
Дробление будет в примере с поворачивающей главной. Не может 1/2 вея выступать в роли from, а другая 1/2 в роли to. И круги есть сложные (например в Егорьевске).
Я не против новых фич, просто давайте хоть раз попробуем сделать новый рилейшен без необходимости разрезания дорог. У нас уже есть запреты поворотов, маршруты и пр., под которые дробится геометрия. Всего делов-то - указать точку via и ближайшие к ней точки from и to.
Я понимаю программистскую логику (запрет поворотов - это отношение сегментов). Теперь Вы попробуйте понять людей, приходящих в проект, когда вместо одной цельной междугородной трассы они видят сотню сегментов, и у каждого налеплены одинаковые ref, name и прочая дублирующаяся информация (а со временем она начинает отличаться - в одном месте исправили название, в другом забыли). Даже не новичкам это надоедает.
Зачем делать сложно, если можно сделать просто.
(added)
К слову, две соседние точки вея однозначно адресуют сегмент. Если в этом месте есть неоднозначность (оверлапы) то сегмент адресуется по двум точкам и way_id.
Думаю все согласятся с логикой - в turn_restriction/give_way/destination_sign/route участвуют сегменты, а сегменты можно описать указанным мной способом (2node_id | 2node_id+way_id) без разрезания дорог.
Заодно бы разобраться с запретами грузового движения (и подобными). Тут сложность в том, что неясно как лучше - ставить запрет на точку или на веи. С одной стороны логично на точку, ведь знак запрещает проезд и не имеет зоны действия, в запретный район часто вполне “законно” можно въехать другой дорогой, где знак поставить забыли. С другой стороны объяснить это ГАИшнику будет не просто и легче заплатить, чем судиться. Более того, если педантично следовать ПДД, можно найти в Питер или Москву лесную дорогу, где нет знаков, и потом гонять по городу 90 км\ч :).
Зы Я далеко не программёр и “чайник” в тегах и их логике, но в своё время профессионально занимался организацией дорожного движения и хорошо представляю, о чём пишу.
Знак (3.2-3.9),имеет зону действия. Поэтому логично ставить на вей.
Найдите, но так, что бы не въезжать при этом через другой НП, ибо ограничение будет 60.
Если найдёте - напишите об этом в ГИБДД. То же, кстати, касается отсутствующих знаков 3.2-3.9 “с другой стороны вея”.
- Чем ситуация будет отличаться в случае добавления нодов отходящим веям? Т.е. добавляется новый нод посередине между описанными в отношении, и от него отходит вей. В этом случае нод участвующий в отношении даже не найдёшь.
- Хотя с другой стороны - цена ошибки в отношении запрета меньше чем цена ошибки в изменении самой дороги.
- Реализация любых отношений не нужна сама по себе. Только в конкретном софте - в отображении, или навигации. Соответственно, в случае навигации, чем сложнее с точки программы/алгоритма реализация отношения, тем мощнее нужно железо для работы программы → дороже навигатор.
Имхо, в данном случае нужна следующая концепция: - Делать алгоритм разбора osm файла максимально простым.
- Делать полную поддержку в инструментарии создания.
- Не учитывать полную читаемость человеком.
Ест-но всё должно быть в разумных рамках.
Здравствуйте.
В окрестностях моего города есть огромные территории, где раньше добывали торф:
http://www.openstreetmap.org/?lat=56.4597&lon=43.4633&zoom=13&layers=M
Сейчас на карте они отмечены как landuse = quarry, resource = peat.
Но уже много лет как все эти карьеры заброшены, превратились в тропинки между болот, заросшие березняком. Как это отобразить? Может быть, поменять “карьер” на “болото”, а в названии или примечании указать, что это бывшие торфяные карьеры?
Кстати, какой тег лучше использовать для создания примечания коллегам-мапперам?