Запреты поворотов хотя бы соответствуют тому, что на местности есть.
А некоторые ставят запреты разворотов почти на каждом перекрестке (даже там, где нет знаков, просто нелогично раворачиваться или нельзя из за других ограничений, которые уже есть). Такие запреты я бы повыпиливал.
Как у вас тут весело, кот-спода.
Пару копеек вставлю: во-первых ваши конвертеры они по чему работают? прямо по апи? Разрешите не поверить.
Ergo если завести конвертер (или даже прослойку над апи, если кто и вправту от апи работает) чтобы *в выгрузках * заменять “старые” теги на “новые”. Можно даже для глухих ретрогардов сделать обратный конвертер.
Это даст возможность на самом деле игнорировать кашу между двумя способами в базе вплоть до момента когда один из них будет окончательно доминировать. При соотношении более 1:10 можно использовать и второй способ.
То есть давайте попробуем решит не вопрос “что нам делать с живой базой”, а “как нам жить несмотря на кашу в базе”. Потому что каша в базе - она от каши в головах, а кашу в головах ботами не победить.
Я по делу уже всё сказал, теперь жду новых аргументов. Но все защитники как-то лишь повторяют старые, местами перефразируя, а на них я уже ответил. Как тут не троллить?
блин но это долбаная партизанщина. Да и опять, те кто против, будут говорить: “Пусть мапперы ручками сами поменяют”, ну не понимаю я этого. В мир компьютеров делать руками, когда можно автоматизировать. Ведь все josm юзают, т.к. удобно, а вы отсылайте правки напрямую через апи, правя в блокноте.
Ну так и делайте автоматизированно - добавляете в конвертер поддержку всех нужных схем (как старых, так и новых) и сразу получаете результат. В большинстве случаев это занимает не более пары строк. Без каких-либо правок базы руками или ботами. Пусть данные живут своей жизнью - если новая схема будет лучше, чем старая, то старая сама собой отомрёт со временем. А там уже можно будет уже и в редакторы добавить автоудаление, как сделано для created_by.
Не нужно пытаться сделать “идеальную” базу - в community проекте без централизованной разработки тегирования такого никогда не будет, такова плата за гибкость. Во всяких мапмейкерах и няк-ах за вас решает дядя, поэтому там всё более упорядочено, но гибкость и скорость реакции никакая.
Я ратую за то, чтобы был специальный “технический” рендерер (неважно, отдельный или как стиль для Мапника) для маперов. Обычно таковым называют стандартный Mapnik, но это немного не то. Постоянные споры в стиле “Почему не отображается XXXXX? – Потому что если отображать всё, то будет невозможно пользоватся” – намекают, что Мапник ориентируется для обычных пользователей в первую очередь.
Так вот, я за то, чтобы был специальный рендерер, который бы:
рисовал всё, что обозначается общепринятыми и давно известными тэгами;
рисовал всё, что принято утверждёнными пропозалами;
принятие любого пропозала как approved безусловно влекло за собой реализацию отображения на этом рендерере, причём как можно скорее;
отсебятина, необщепринятые обозначения, пропозалы в стадии иной, чем approved – не отображались на этом рендерере;
переставал отображать всё, что признано deprecated.
Что касается автоматических изменений тэгирования – я за то, чтобы автоматический переход на новые одобренные схемы производился, но существовал бы grace-период, в течение которого бы старая и новая схема сосуществовали. По окончании grace-периода старую схему – вон из базы. Иной порядок просто замедляет внедрение полезных нововведений – срабатывает принцип “зачем трогать, ведь и так всё хорошо”. Так и будет ползучее вялотекущее сохранение старья, мы вынуждены будем усложнять софт для поддержки разных схем обозначения одного и того же. Длительность grace-периода обсуждаема, на мой взгляд, достаточно квартала или двух. Программные средства, не успевшие за этот обновить правила работы с тэгами, признать устаревшими, неподдерживаемыми, и в деятельности OSM на них больше не ориентироваться.
Уточню. Это атрибутивная информация, об её отрисовке речь не идет. Я имел в виду отрисовку объектов. Вот приняли пропозал, что подъезды, станции скорой помощи, горные перевалы обозначать вот так. Немедленно начинается работа по отрисовке на карте обозначений подъездов, станций скорой помощи, горных перевалов. Приняли пропозал, что входы обозначать entrance=* вместо buiding=entrance – немедленно реализуем стиль подъезда для точек, обозначенных тэгом entrance=* и убираем его с точек, имеющих только buiding=entrance. Надеюсь, мысль понятна.
Для просмотра атрибутивной информации есть режим “Просмотр данных карты”, но чтобы им воспользоваться, сначала нужно увидеть наличие самого объекта – для этого и служит технический рендерер.
а смысл смотреть этот рендер? когда в JOSM или другом редакторе можно загрузить кусок карты и посмотреть локально, для josm можно вроде свои локальные стили даже писать
В этом плане как раз впилить в жосм такой рендер (вместе со списком актуальных/устаревших тегов) лучше чем отдельный поднимать: видно будет тут же.
Да и вообще нынешнее состояние у жосмового рендера печально, так что одним махом по двум зайцам.
Список устаревших, кстати, при таком раскладе можно сбоку держать и сразу подтягивать и как отрубание отображение и как ворнинг при коммите.
Это да, но видно будет тем кто откроет JOSM и скачает данные. А вот если сделать отдельный рендер - видно будет без этих усилий.
Другое дело, что пропажу мелких объектов в плотно отрисованных районах не факт что сразу заметят.
А в целом я согласен, что валидатор - технически более правильное решение, чем рендерер.
так вы же сами хотели его открывать действительно в josm проще стиль накидать, у меня там есть кнопка с тем же стилем мапника, например. и перед сложной выгрузкой проверяю… иногда ошибки по дорогам отлавливаю, наглядно
Нет, так больше действий приходится исполнять. Предположим, у нас нет такого рендерера, а есть только Мапник. Я – зная, что в вот это месте есть некие интересные мне объекты – смотрю в Мапник, не вижу объектов, запускаю Josm, качаю данные, включаю стиль, и вижу, что объекты есть, просто Мапник их не отрисовывает, и понимаю, что с запуском Josm возился зря. В то время как при наличии рендерера я бы сразу увидел, что объекты в базу уже добавлены, и ничего править не нужно.
То же самое и при пропадании объектов – рендерер гораздо быстрее покажет, что пора запускать Josm и что-то делать.