Таким образом вы придерживаетесь мнения, что если некто начнет импорт “валидных данных”
addr:city, addr:region, addr:country и addr:galaxy для всех адресуемых объектов,
то это в порядке вещей ?
И как будет учитываться административная иерархия отличная от city,addr,country ,
ее тоже можно добавлять ко всем объектам?
необсужденный и неодобренный (а он не будет одобрен) сообществом импорт будет очень быстро откачен
Обсуждение именно об этом. Чтобы признать дополнительные теги на зданиях невалидными и поступать с ними так же, как с транслитом в name:en, например. При рисовании новых объектов можешь вносить (и даже никто не заругает), потом другие могут удалить в рамках приведения к рекомендуемому виду. Но обратно вернуть удалённое, потому что “мне пофиг на договорённости, мне так нужно” - харам.
Я в шапке, кстати, привёл ссылку на один из чейнжсетов с удалением таких “валидных” данных.
Ну то есть всё равно есть откуда их взять (и берут), а не ожидают же, чтобы непременно всё на конкретном доме было.
Есть такой валидный в прошлом популярный тег is_in:country. Ничего, постепенно выпиливается
https://taghistory.raifer.tech/#***/is_in:country/
Имеются ли причины, по которой верное указание местоположения приводит к ошибкам, ломает что либо?
Имеются ли причины, по которым одна схема несовместима с другой?
Если ответ на оба вопроса негативный - тред не имеет смысла. Подписывать город на каждом здании - бесполезная работа, но с трудом понимаю как это может мешать.
Имеются - если на каждом здании, то можно указать теги addr:place/region/country, не совпадающие с такими на соответствующих полигонах, в которых это здание находится. Это влечёт неоднозначность в данных и непредсказуемую работу с ними.
Опять же, в случае переименования населённого пункта придется массово менять теги на всех домах в нём. Сделать ошибку при этом намного проще, чем если бы поменять надо было в одном месте - на самом населённом пункте.
Я за сокращенный.
- Нужно беречь базу. Избыточная информация чревата появлению проблем. Простота и полнота - разные вещи.
- Если какой-то населенный пункт станет частью другого (крупным городам свойственно поглощать города-спутники), то из-за этого придется делать огромный объем **бессмысленной **работы! Тогда как сокращенная схема позволяет легко поправить границы и здания легко унаследуют нужные теги.
- Современные системы позволяют легко наследовать данные объектов покрывающих их область. Вместо того чтоб тотально забивать гвоздями информацию, следует потратить это же время на освоение современных систем и баз данных.
Чушь какая-то. Мне пришлось лишь С++ установить.
Кстати, еще адреса на каждом ПОИ надо прописать, а то, как мне попалось в украинском чате, у отдельных пользователей проблемы написать оверпас для РФ
У нас уже муниципальные районы в городские округа, а потом далее в муниципальные округа, переделывают по всем регионом. что еще ведет к сносу addr:subdistrict
Ну и самим регионам любят где приписать слово республика, а где убрать.
Но в ограниченном масштабе использование addr:* тегов полезна.
Когда какие-то границы не скачаны в выгрузку или объекты залезают в выгрузку соседних регионов и т.п.
Есть имена на другом языке (татарском и т.п.), почтовые коды попадаются в мелких нп.
Сокращенная форма была придумана для ленивых мапперов, чтобы им не приходилось вносить все addr:*, а карта в навигаторе у них бы была с поиском, благодаря известному конвертору.
Теперь у нас теперь просто есть не ленивые, которые хотя вносить все теги, и у них свои способы конвертации в свои системы.
Но, поскольку, многие другие полную схему не поддерживают, то полнота и целостность полной схему абсолютно не гарантирована. Ошибки замечают не сразу, неполноту никого не волнует, кроме наших не ленивые мапперов, но вот насколько лично они готовы внесенные данные поддерживать? Им же, в конце концов, будет больнее.
Валидаторы есть, но ошибки такого рода мало кого заботят, так как раз конвертор работает, то и ладно.
Я бы сейчас не цеплялся к полной схеме.
За долгую историю, насколько я помню, серьёзных проблем она пока не вызывала.
Проблемы в OSM возникают однозначно, когда пытаются разные варианты обязательно подогнать под что-то одно, а остальное пристрелить.
Ну если вместо исправления ошибок вносить данные по второму разу в другом варианте, то ошибки и не будут никогда исправлены. В итоге вместо того, чтобы сосредоточиться на доведении до ума одной схемы, мы на 15-м году существования проекта имеем две и обе неполные.
помню еще в навителе постоянно выскакивали вторые города
адресный формат гармина был сломан еще до эпохи возникновения ОСМ,
и уши city/region/country растут именно оттуда, а не из Карлсруэ.
И где, собственно, причины? Это предполагает что допущена и не исправлена ошибка. Получается, если кто-то безошибочно будет дублировать адресную информацию на объекты - ничего не сломается. Раз обсуждение о том, стоит ли отказаться от одной из схем - нет, не стоит. Это ритуальные пляски из лишних правил.
Делать так все равно незачем. Уже иронизировал: если где-то упала сосиска, значит нужно отметить все места куда не упала - иначе всех завалит. Но если кому-то очень хочется заниматься бесполезным дублированием - пусть делает.
обсуждение о том, стоит ли отказаться от одной из схем - нет, не стоит.
Но если кому-то очень хочется заниматься бесполезным дублированием - пусть делает.
Потом кому-то захочется убрать бесполезное дублирование из данных. Тоже имеет право, раз схемы совершенно равнозначны, плюс весомый аргумент в виде уменьшения размера базы. А первому не понравится, и он сделает обратно. И так до бесконечности. Причём на любой из сторон возможно подкрепление: одному надоело бодаться, так другие сторонники этого варианта подхватят знамя.
Это слабое место всех ситуаций в OSM, когда приняты две равнозначных схемы тегирования - война правок по субъективным предпочтениям “а мне больше нравится вот так” становится лишь вопросом времени. Потому что невозможно сказать, кто из двоих прав - оба правы в равной степени. Вот с Совой именно так и вышло.
Чтобы такой ситуации не было, необходимо сообща признать одну из схем более желательной. Тогда внесение новых данных (тут в любом виде) в OSM - хорошо, переделка существующих из нежелательного вида в желательный - ещё лучше. А вот целенаправленное движение в обратную сторону - из более желательной схемы в менее желательную - однозначно плохо. И тот, кто это делает, даже после комментариев и ссылок на итог обсуждения - уже не сторонник одного из альтернативных подходов, а сознательный вандал, не желающий принять факт того, что здесь совместный проект, в котором нельзя взять и единолично установить свои порядки без обсуждения и согласия большинства.
Вот тогда вместо выпускания пара в виде войны правок, создания вторых-третьих аккаунтов и прочего будет движение по общему вектору в сторону улучшения данных. Без этого имеем то, что имеем.
Лучше бы болота и ручьи маппили
Сокращенная же карэсруэ доступна только программистам серьезно вложившимся в установку PostgreSQL+PostGIS
Ну не всё так печально.
Во первых её уже много лет как поддерживают большинство конвертеров в карты навигаторов, начиная с популярного osm2pl.
Во вторых уже больше 3 лет как существует мой плагин к osmosis, который позволяет заполнить эти теги при необходимости в любой момент на любой файловой выгрузке.
Так что было бы желание…
Но в ограниченном масштабе использование addr:* тегов полезна.
За пределами областей НП конечно.
потом другие могут удалить в рамках приведения к рекомендуемому виду
Я за удаление тегов выше addr:city. addr:city удалять, если есть полигон НП. Страну и регион удалить автоматом, остальное руками. С ПОИ также удалять номер дома и улицу, если они совпадают с тегами на здании, в котором эти ПОИ находятся.
На нытьё вида “я вносил, тратил время, а вы всё одним движением удаляете” не обращать внимание.
Я лично вручную добавил на каждую точку place в своём регионе теги addr:country, addr:district, addr:region, addr:subdistrict и official_status. На все 1695 точек, руками, без скриптов. Потратил много времени, жалко, но сову включать не буду, удалять, так удалять.