Это ответ не по существу — хотя кто-то из читателей может посмеяться, адресат может и нет.
Я думаю, что ввиду огромного фронта работ у DWG они не делают различий, что из пакетов правок удалять, а что оставить. Те же самые домики кто-нибудь нарисует в другой раз. Ничей вклад в OSM не бесценен, поэтому иногда участники DWG могут расстроить, откатив больше, чем нужно. Кто знает, как именно человек переносил адреса из третьего источника — вместе с геометрией или без?
Вывод тот же, что у literan: нарушение правил относится к пакетам правок целиком, а то и ко всему вкладу человека целиком. Расковыривать пакеты никто не будет, это слишком много работы. Поэтому лучше заранее убедиться, что не делаешь ничего, нарушающего подписанные при регистрации условия участия.
Просматривать адреса в ПКК можно, законодательством не установлено для каких целей разрешено\запрещено использовать эту информацию.
Так же как можно просматривать информацию об адресе на самом здании. Законодательством не регулируется право использования этой информации.
Если явно разрешить использовать информацию об адресе, то ты автоматически её для чего-то запрещаешь. Для этого нужно переписывать закон. Поэтому получаются такие размытые ответы.
Одно дело размещать данные и предоставлять неограниченный доступ к ним.
Другое дело предоставление сведений из ЕГРН.
И совершенно иное - размещение сведений на других информационных порталах.
Совпадение адресов в ПКК и на ином источнике данных не есть размещение сведений ЕГРН на ином информационном ресурсе. Идёт подмена понятий и грубое обобщение. Адрес не сведение из ЕГРН. Сделайте запрос по своему объекту недвижимости и вы увидите что такое сведения из ЕГРН.
Вот и получается что претензии по копированию не обоснованные. Совпадение адресов не есть копирование, а есть объективная данность.
Другое дело если есть пример полного копирования данных, то с этим никто не спор т надо разбираться жёстко.
Все остальное из области зайди лайкли. Не подсудно…
Нельзя по каждому чиху посыпать себе голову пеплом!
тег amenity=register_office устарел. Определение то же, что у office = government + government = register_office
По сути дела, ЗАГСы, отмеченные amenity=register_office являются “мертвым грузом” в базе, а после перетегирования они появятся на рендерах и в поиске.
Было бы глупо настроится на “вымирающий” тег времен раннего OSM, когда все POI были в amenity=*, и не настроится на современный и широко распространенный тег…
А мы живём хитрее. Используем все возможные варианты тегов - и отмирающие, но не вымершие, и современные, ещё не прижившиеся! Особенно это актуально когда в России что то массово меняется, а у соседей на постсоветском пространстве остается неизменным.
Лично я уже готов “вчера” к такого рода правкам. Изменения останутся не замеченными.
Кто то памятники ваяет, кто то сносит. Кто то снова ваяет, а кто то снова сносит. Диалектика! ??
В Вашем случае Вы ничего не теряете, напротив, в будущем сможете отказаться от amenity=register_office и сосредоточиться на government=register_office. Вам жизнь упрощают, один тег вместо двух
Я планирую также заменить building=entrance на entrance=yes (только ноды без entrance = *; например, building = entrance + entrance = main не будет изменено). Есть возражения или пожелания?