Вообще говоря нет. То есть когда нам заранее известно что дом “приписан” к деревне Гадюкино - то достаточно.
А если мы просто смотрим на теги и геометрию, то мы не можем сказать достаточно или нет. Потому что в приведенном примере без дополнительных правил “что разрешено брать из геометрии, а что нет” данные теги могут обозначать:
деревня Гадюкино, дом 2
деревня Гадюкино, снт Дачное, дом 2 (нам никто не запрещает брать низлежащие плейсы)
деревня Гадюкино, снт Дачное, Садовая улица, дом 2 (брать улицу предполагается вполне допустимым схемой Карлсруэ)
На какой из этих адресов слать письмо?
Потому что вы тыкаете на форуме. Все кто на форумы не ходят - ничего о ваших проблема с плейсом не знают.
is_in: и addr: - это две разные схемы, которые говорят о разном. is_in - где находится, addr - какой адрес имеет.
В вики все правильно написано в том плане, что в писать квартал Зеленограда, по которому нет адресации, в addr нельзя. Ни в какой. Только в is_in.
Кстати если заполнять Зеленоград без addr:place, но с полигонами place = neighbourhood, то программа может взять квартал в адрес. Потому что нигде не указано, что его не надо брать в адрес (равно не указано что приведенный список плейсов откуда следует брать адрес для геометрии явлеются исчерпывающим).
Не нагнетайте.
Я ясно выразился, что надо брать из геометрии (addr:city), не пытайтесь брать лишнее. СНТ придется писать ручками.
Ну а почему же аналогичные вещи вне Зеленограда начинают писать в addr:place?
Может, но только отравится, но будет получать неверный адрес!
Я понял. Давайте повернем вашу логику в обратную сторону:
не всё, что есть в полигоне place надо записхнуть в адрес,
а взять из полигона place ровно то, чего не хватает в place:city.
Остальное надо вносить в addr:suburb и т.п. ручками
Вы это написали на форуме.Вы лично. НА форуме. Ни в вики ни в каком-либо другом формальном описании ограничения на то, что деревню брать нужно, а снт нельзя нет.
Если вы считаете, что сформулировали удобное правило, которое можно использовать - пишите пропозал.
За написание в addr:place элементов по которым адресация не ведется - надо бить по пальцам стальной линейкой и разъяснять чем отличается addr: от is_in:
Но прошу заметить, что в плане кварталов по которым не ведется адресация - Зеленоград выделяется. Обычно по кварталам адресация таки ведется.
Во-первых это правило не говорит о том, как узнать сознательно не внесен suburb если он есть в геометрии или просто пропущен.
Это не делает ваше правило неприменимым, но делает его менее удобным чем явное указание на последний уровень/объект.
Во-вторых опять проблема вложенных НП, если каждый из них может быть “кандидатом” на addr:city. e.g. /Московская (область) /Балашиха (город) /Дятловка (деревня)
Кстати почтовые адреса у нас идут по административному или по муниципальному делению? Если по муниципальному, то еще можно выкручиваться, а административно Балашиха - весь городской округ.
что Зеленоград ничем не отличается от деревни. Такая же адресация домов по населенному пункту,
что это далеко не единственный случай с микрорайонами вне адреса.
Парвильно, не делает неприменимым, osm2mp его ведь применят.
Узнать просто: если не внесет, то сделано это специально.
Опять приехали к путанице - построение адреса и контроль правильности заполнения. Это две разные задачи.
Чем меньше всяких неявных предположений откуда что брать, тем лучше.
Не нагнетайте и не выдумывайте сложности типа addr:city=Московская (область)
Про вложенные НП это другой холивар, спросите у авторов конверторов.
Не называйте всё, что имеет тег place как НП, от этого путаница. suburb,quarter - не НП.
В конце концов, если НП вложенные, это или ошибка (два города), или пишите всё явно.
Разные. Только перед тем как строить адрес надо понять а можно ли его построить. Это первое.
И второе: если из двух схем сопоставимых по удобству одна позволяет проверять правильность, а вторая нет, то лучше проверять.
область не city, а деревня - не квартал. Там нет вложенных place, там есть place вложенный в boundary=administrative. По чему у нас идут адреса?
Знаете в чем между нами разница? Вы полагаете что люди и программы умные. Что если немного присмотреться то все будет понятно. Мне понятно. Вам понятно.
Я же считаю людей (а особенно программы) абсолютно тупыми. На уровне трехлетнего ребенка, только с фактологической базой побольше. Поэтому полагаю, что любое правило, любая схема требует максимально однозначной и желательно простой инструкции.
Пример.
Порядок записи (адрес с конверта - осм):
*Проверить правильность заполнения описанных полигонов
Заполнить номер дома.
Если перед домом в адресе стоит улица - вписать ее в addr:street
Если перед домом в адресе не улица - вписать это в addr:place
*Указать почтовый индекс в addr:postcode
*Если дом известен как находящийся на территории, а на конверте этой территории не написано внести территорию в is_in:
необязательные пункты
Порядок прочтения(осм - на конверт):
Если указано addr:street - использовать в адресации одноименный highway, ближайший к этому дому, и набор полигонов place и boundary=administrative в которые вписана данная улица (при одноименных полигонах boundary=administrative имеет приоритет).
Если указано addr:place - использовать в адресации одноименный place, в который вписан данный дом и набор полигонов ==//== в которые вписан данный полигон.
Использовать явно указанные теги addr:* в порядке их важности (для большинства случаев хватит порядка из нынешней вики, можно дополнить кварталами и т.д.), кроме одноименных взятым из геометрии.
Если addr:postcode не указан - воспользоваться внешним справочником (например russianpost.ru)
ок, вот моя станица звучит как “станица Новотитаровская”, а по полному “Новотитаровское сельское поселение”
ну никто ж не будет искать по полному названию
А шож их усюду понатыкали в НП и выше?
Не иначе, как нежелание ставить все теги на домики, а определять НП из геомертии, ведет логически к тому, что опущенные теги возникают на НП и т.д.
Как правило люди не знают как можно определить адрес, имея полную карту. И не знают про роль subarea. И не знают чем отличается одрес от взаимоотношения территорий. Но им хочется внести свою лепту, на всякий случай. Вот и вносят.
Адреса - для адресов, отношения - для отношений. Поселок адреса не имеет (за отдельными исключениями, которые как раз лучше описывать addr:full).
Не надо мешать все в одну кучу. А то так получим полигоны государств с addr:planet=Earth.
Возможно, но все дома в нем имеют общую часть адреса, которую на поселке и пишут, что бы не размазывать по домикам.
Я это так трактую. Как следствие применения упрощенной схемы тегирования адресов, опирающейся на геометрию НП.
А is_in это в чистом виде еще одна некая иерархия, в общем случае не адресная.
На поселке есть название поселка, поселок принадлежит району, район - области.
Можно конечно проставить область и район на всех поселках, но это не только бессмысленно, но и вредно, поскольку в случае, например, переименования района, придется править все поселки. И это все равно не адрес, это описание вложенности/подчиненности, которая формирует (или не формирует, как ФО) адрес.
Это вообще говоря замена той самой вложенности полигонов для случая когда полигонов нет. Может использоваться для дублирования вложенности полигонов при желании.
Но самое главное что есть определенные цепочки вложенности/подчинени идущие от России до дома. Не всегда такая цепочка от-и-до единственная (могут быть пропущены или переименованы самые неочевидные звенья), но все они описываются геометрической вложенностью или ее заменой - is_in.
Выборка определенных звеньев в порядке их вложенности даст нам адрес.
Дальше можно применить системный подход и определить правила выборки таких звеньев, а также порядок обозначения исключений. После чего следуя заданной схеме легко актуализировать базу.
Можно, конечно, и просто копировать все элементы адреса, включая очевидные (у кого-то есть сомнения, что Тверская область в России?) и получить громоздкую, плохо обновляемую базу. В которой к тому же, совершенно непонятно можно ли отправить письмо в деревню Запрудье или надо еще и дом указывать.
is_in - задумка неплохая, но в реальности - неформализуемая отсебятина. Чем плоха идея “проставить область и район на всех поселках”? Абсолютно четкая и однозначная иерархия addr:country, addr:region (область, край), addr:district (район), addr:subdistrict (поселение). Переименования районов случаются далеко не каждый день, и массовая правка, если возникнет такая необходимость, будет не сложнее, чем поменять адреса домиков addr:streetname в случае переименования улицы.
Это не только огромная избыточность данных, это ещё и постоянные ошибки похлеще тех, для которых пришлось придумать streetmangler.
Если ты думаешь, что всё так просто, попробуй просто ради интереса изучить, сколько населённых пунктов имеют несогласованные значения place, name и других тэгов на точке и границе.
Избыточность и ошибки - не более, чем в схеме “связь улица-дом через addr:streetname”: через отношение тоже было бы проще, надежнее и с минимумом избыточности, но почему-то не прижилось.
Насколько я понимаю, для связи “полигон place” <-> “точка place” необходимо и достаточно совпадения их полей name, place и размещения точки внутри полигона. Я не спец в построении валидаторов, но на мой взгляд, это проверяется не очень сложно. Зачем поля population, wikipedia и проч. на границе - я не понимаю, кто в курсе, расскажите? Почему бы случаи несогласованности тэгов не отловить и не исправить - ну не 99% же с ошибками?
P.S. Тот же ситигидовский валидатор проверяет city и town’ы на наличие точечного центра и границы. Можно же добавить в него более мелкие НП - хотя бы для отлова несоответствия пар place и name? Да, сначала будет куча ошибок. Ну так и Москва не сразу строилась
