Не понятно. Обоснуйте.
Действительно знак 6.13 “Километровый знак”. Расстояние (км) до начала или конца дороги. Относится к категории Информационные знаки (см. ПДД).
Но именно в RU:Key:traffic_sign сказано: “Тег вешается на точку, принадлежащую линии highway=*”. В то же время сказано: “Объект Точка. Допускается наносить объект Точка или в составе объекта Линия, или отдельно, сбоку от дороги. Оба метода используются на практике”.
Вы советуете создавать дубли знаков? Одни оставить как highway=milestone на дороге? Дубли как traffic_sign поставить на обочину?
К тому же тега для Километрового столба в RU:Key:traffic_sign я не обнаружил.
непонятно с какой целью highway=milestone оказались на линии дороги
непонятно с какой целью Километровые столбы выведены в отдельную категорию от дорожных знаков
непонятно предложение создавать дубли для Километровых столбов
Можно ли как то наделить уникальными географическими свойства эти НП. Или какую модель тегирования использовать для исключения объединения таких одинаковых объектов?
ОКТМО, ОКАТО и примкнувший к ним ФИАС (в девичестве КЛАДР).
Только я подозреваю, что им новые повыдают, но пока старые проставить.
А что значит “объединения”? Это что за алгоритмы объединяют НП по имени?
З.Ы. Да, тут на праздники поехал в Королев/Юбилейный к родственникам.
Нынче там дома с одинаковыми номерами по улице с одинаковым именем стоят в двух кварталах друг от друга.
Яндекс подсунул разумеется не тот (хотя и писал про названия микрорайона, но кто же читает на ходу!). Но я был на стороже, ибо уже на карте мне показалось что дом не такой.
Самое забавное, что потом все равно пришлось заехать и в этот дом за знакомым этих родственников, так что разведка пригодилась.
Речь о конечном продукте. Конвертер тянет одинаковые: country, region, district. А вот subdistrict - утрачен упразднением поселений (что и было основой самостоятельности НП). После конвертации данных в наличии один НП. Два в одном!
Вот и думаю как теперь их и подобных им разделить. Аналогичный пример Новосёлки… и т.д.
Ну значит плоховат конвертор.
Так как в некоторых областях есть и по три-четыре одноименных деревни внутри одного поселения, да и другие дубли имен далеко не редкость уже давно.
Или пинать конвертер, чтобы он это непонятное “объединение” не затевал, или писать препроцессор для конвертора и ТАМ курочить имя или еще чего на свой вкус, чтобы предотвратить “объединение”.
В том то и вопрос - за что зацепиться конвертеру (по какому территориальному признаку хороший конвертер понимает, что это разные НП). Думаю любой конвертер считает что это один и тот же НП, очагами разбросанный по территории городского округа. Поэкспериментировал с addt:postcode (хотя полигона то нет). Есть эффект, но далеко не на всех НП проставлено, ну и отсутствующий полигон действия… .
Коверкать имя можно было бы в исходной базе = скажем Сотниково (вблизи Жилево), Сотниково (Малино). Понимаю - непременно найдутся бескомпромиссные поборники “правил”. Попытка не пытка - спросил в надежде найти понимание и аналогичную заинтересованность. Что бы писать препроцесс (постпроцесс), надо знать о всех одноимёнцах в России…
В любом случае спасибо. Пора переходить в тему отладки конкретного конвертера.
Если в одном округе два НП с одним названием то делать особо нечего. Это как две улицы с одним названием в одном городе - без путаницы не обойдётся. Всё равно такси или доставка не туда приедет.
Чаще всего используется почтовый индекс, два НП с одним названием с одним почтовым индексом - что-то из разряда совсем фантастического развиия событий. Поэтому в США принято вводить ZIP в дополнение к адресу. Остальные автоматические привязки могут дать сбой.
Я пока так и не понял, ЗАЧЕМ?
Если в OSM разные НП, то они и разные.
Можно привести пример, когда это не так?
Для чего склеивать-то несколько НП в один?
Я знаю только один случай, это way/relation границы и одноименный с тем же значением тега place node, лежащий внутри этой границы. Так такое “объединение” производят по геометрии (попаданию одного в другое).
Эти данные встречаются в базе реже - addr:postcode. Но главное у этого тега так же нет уникального полигона.
Вот обратный пример - Большое Алексеевское и Выселки, территории одного целого на значительном расстоянии. Где Выселки и где Большое Алексеевкое. Изначально Выселки это территория Большого Алексеевского. Так решили в 90-х. Выселки должны определяться как часть Большого Алексеевского.
Это конечно частность. По сути там скорее дачники. По факту и администрация слабо представляет что где и почему так.
А вот одноименных НП в границах отдельно взятого адресного полигона достаточно. Наверное в ГО Ступино (и прочих) со временем появятся микрорайоны?! Тогда появятся subdistrict. Проблема снимется. А пока не здорово.
Повторюсь. Не думаю что будет много “криминала”, если в таких случаях корректировать name НП. Это самое простое решение проблемы. Тем более по стране чудных name НП предостаточно. И никто не торопится наводить порядок. А молчание знак согласия?!
Конечная программа видит два одинаковых названия (и никаких различий), формирует его один раз, объединяя данные. И правильно делает т.к. НП могут иметь две территории (см. выше).
Уже пробую. Но есть но. В адресе появится индекс у всех НП где есть. Оно не надо. А так что бы только у одноименных?! Это только разработчик конвертера. И то есть ли такая возможность?!
Перед тем, как отдать конечной программе данные, надо диагностировать наличие тезок, и им в имя приклеить official_status, если однозначность не убирается, то тогда приклеить или порядковый номер (вещь плавающая) или код типа OKTMO.
Поэтому уж лучше вносить в OSM его (а также official_status), чем портить name.
Еще раз повторюсь, что тезки явление массовое и решать проблему при конвертации надо системно.