Національна класифікація "admin_level"

Если уж делать как пример, то мне несколько “не понятно” наличие тега place=village в отношении type=boundary
http://www.openstreetmap.org/browse/relation/2593548 ИЛИ http://www.openstreetmap.org/browse/relation/2824642
Чем ув. olehz сможет это объяснить? Только чтобы рэндер (mapnik) не прорисовывал названия дважды?
Именно поэтому и заметил этот тег - т.к. не мог понять почему у меня есть название сельрады в центре, а у olehz их нет.

и… думаю это есть не правильно: - тег явно лишний в отношении
что он означает? что внутри есть НП с таким названием? административный центр? так есть admin_centre + label. Костыль? к чему?

ПРАВКИ ОТ 17-03-2013, а 15-03-2013 olehz писал:

и еще по поводу

При чем тут вообще boundary к place? Мухи отдельно, котлеты отдельно. Ну да в некоторых случаях “котлеты” выглядят как “мухи”, но все равно их создают отдельно (отдельно отношение type=boundary и отдельно полигон place)

и предлагать использовать отношение boundary выкинув из него admin_level и boundary=administrative - это … предлагать в целях освещения использовать люстру выкинув из нее все негорящие части и сжигая остальные. Отношение boundary - это общепринятое понятие. Убрав boundary=administrative, его можно рассматривать как boundary=bratva_controled и как много еще каких

Это все следствие незаконченного эксперимента. Сейчас ситуация по Львовской области следующая: Есть недоделаный админ-пазл из сельрад. При чем каждая сельрада еще имеет и тег place=vilage і name = название главного села. Я согласен, что нужно сесть и переименовать все сельрады в формат “Блаблаївска сільська рада” і перенести тег place=village c админграниц на новосозданные мультиполигоны, которые бы содержали в себе все строения. Эту работу можно скормить какому-то скрипту, а вот обрисовывать островки застройки прийдеться вручную и это адская прорва работы. Так что рассматривать Львовску область как пример, пока явно преждевременно.

Суть в том, что в Украине мы имеем по факту 2 типа границ:

  • Административную - границы сельрады (может состоять из нескольких сел)
  • Адресную - границы села, при чем эта граница может состоять из анклавов или скопления “островов” разделенных полями/лесами

Т.е. убрав boundary=administrative мы лишь убираем тег указывающий на административную природу границы. Так что пример с люстрой здесь слегка неуместен :stuck_out_tongue:

Это хорошо)) В том плане, что все таки тег place c админграниц предполагается убрать… а то срашновато стало за будущее наших границ))

За виды границ я в курсе.
с примером да чуть перегнул, но отсутствие boundary=administrative это большое подспорье для возникновения ошибок в будущем когда появятся другие виды границ (например bratva_controled))
В общем я так понимаю переживать не стоит.

К стати я тоже взялся за границы сельских советов. Использую: подложку украинского кадастра, собственно сам кадастр и логическое мышление.
Границы населенных пунктов там в принципе тоже есть - они вроде как и “административные” получаются (т.е. правильные). По ним то и хорошо рисовать place.
Арцизский район и Саратский район

Есть желание планомерно пройтись по всему и сделать так как надо, параллельно подтянуть населенные пункты (иногда даже не было НП сельской рады) с сеткой дорог, и сетку дорог между ними.

Возникли вопросы по поводу названий. Писать в названиях сільська/селищна/міська рада? Если все не против (я не против - так вроде логично) то пробегусь пропишу.

Заодно по ходу выложу несколько вопросов которые нужно будет решить вместе. Например:
Адм-тер единица Новая-Каховка (вот такая она)

  • ясно что ее AL=6 (гор. обл. знач.)
  • все села входят в состав двух сельрад с AL=8 - имеют адрес Херсонская область, г. Н-Каховка, село XXXX
  • НО есть в подчинение (паралельно с сельрадами) у НовоКаховского городского совета еще один город г.Таврийск. И село подчиненное административно Таврийску имеет адрес вида г. Н-Каховка, г.Таврийск, село XXXX

долго думал и тут более ясна такая картина, что сельрады мы выводим с AL8. По факту каждое село адресуется по району, минуя этот AL8. В случае с Таврийском он не являет собой сельраду в чистом виде, стоит несколько выше т.к. влияет на адресацию. Не стоило бы ему назначить AL=7?

м Нова Каховка – admin_level=6 для Новокаховської міськради + place=town для міста
м Таврійськ м Нова Каховка – admin_level=8 для Таврійської міськради + place=town для Таврійська
с-ще Плодове м Нова Каховка, м Таврійськ – place=village
Дніпрянська селищна рада м Нова Каховка – admin_level=8
смт Дніпряни м Нова Каховка, Дніпрянська селищна рада – place=village
с Корсунка м Нова Каховка, Дніпрянська селищна рада – place=village
с Нові Лагері м Нова Каховка, Дніпрянська селищна рада – place=village
с Піщане м Нова Каховка, Дніпрянська селищна рада – place=village
Райська сільська рада м Нова Каховка – admin_level=8
с-ще Райське м Нова Каховка, Райська сільська рада – place=village
с Маслівка м Нова Каховка, Райська сільська рада – place=village
с Обривка м Нова Каховка, Райська сільська рада – place=village
с-ще Тополівка м Нова Каховка, Райська сільська рада – place=village

В принципе логично и изначально так и предполагалось и так бы и было. Но смутила именно адресация.
У себя я использовал для адресации несколько иной подход, перелопатил КОАТУУ вдоль и поперек (там еще много сюрпризов), всем НП присвоил определенный “класс” исходя из кода КОАТУУ и все адреса выдает правильно по определенному алгоритму.
Так что согласен AL=7 тут не уместен, а все остальное это проблемы индейцев (конверторов, алгоритмов и т.п.)

Таврійськ ніби не впливає на адресацію в селищі Плодове…
74992, Херсонська обл., м. Нова Каховка, с-ще Плодове, вул. Соснова, 11
74992, Херсонська обл., м. Нова Каховка, с-ще Плодове, вул. Червонопрапорна, 102а

Ключевое слово “вроде”.
http://w1.c1.rada.gov.ua/pls/z7503/A005?rdat1=09.08.2013&rf7571=35297
И таки да - когда-то так и было. Я 20 лет прожил в тех местах (Новая-Каховка + Каховка). В Плодовом живут знакомые-родственники. Но с каких-то пор все поменялось - сам был удивлен.
До этого плодовое отчитывалось Новой Каховке непосредственно.

А в паспорте знакомых-родственников адрес какой?

Ну в паспорт я им не заглядывал))
А вот на счет “в паспорте” могу сказать, что 10 лет родители прожили в доме с номером 10 (в селе), а когда я туда прописался (после института) то у меня в паспорте поставили №12. После выяснений оказалось, что всем на улице сместили номера… Как говорится: “на заборе тоже пишут”))

Надо будет узнать у тех кто помоложе (с помощью социалок уже так делал - что-то уточнял у местных жителей).

Вообще-то может быть несколько одноимённых сёл в одном районе одной области, но в разных сельсоветах.

Кто знает?
Если граница населенного пункта проходит по дороге/улице данная улица попадает в поиск с адресацией? Или все же стоит рисовать границу “за дорогой”.
И если “за дорогой”, то как быть если по данной улице адресуются дома из разных административных территорий/населенных пунктов?

Рисуй границу place за дорогой. Иначе улица не привяжется к своему населённому пункту. Линия улицы должна целиком лежать в пределах полигона населённого пункта.
Кроме того, городские власти ведь обслуживают улицу по всей ширине, а не до осевой линии?

Насчёт разных административных территорий - надо разбираться на месте. Покажи конкретное место на карте.

http://www.openstreetmap.org/browse/way/82552298
http://www.openstreetmap.org/browse/relation/2101543
http://www.openstreetmap.org/browse/relation/2127735

Есть еще веселее, когда одна и та же дорога имеет разные названия для разных сёл: http://www.openstreetmap.org/browse/way/148112944

Мне кажется, что кроме как переделать такие улицы в двухвейные с границей между веями, никак иначе толком такие улицы к населённым пунктам не привязать :frowning:

Интересно, а если такую улицу надо будет заасфальтировать, то кто будет её асфальтровать? Власти из одного населнного пункта или власти другого населённого пункта? Или по осевой линии разделят: половину ширины заасфальтируют, половину оставят :slight_smile:

Може в такому разі використовувати relation Collection, точніше два. Ліня дороги без теґу name, а для вулиці кожного з сел створити Collection з відповідною назвою.

Поясніть докладніше. Як це?
Проблема у тому, що одна й та сама лінія highway має повністю належати одночасно двом різним полігонам place. А як розкидати ці “коллекшн” по полігонах place?
До того ж, пропозал щодо collection ще не затверджено.

Я вважаю, що без розділення вею вулиці не обійтися. Подумайте: ми розрізаємо вилиці у всіх випадках, коли на одній і тій самій вулиці на різних ділянках щось відрізняється. Наприклад, тип покриття. Отже, на мою думку, тут так само слід розрізати вулицю. Тільки не впоперек, а вздовж. Зробити два вея (мабуть з одностороннім рухом), а між ними границю полігонів place.

Для вулиці Щорса з с. Вигода на зв’язок Collection вішаємо теґи

name[:<lg>]=Щорса вулиця
addr:city=Вигода

для вулиці Степової з Дослідної станції

name[:<lg>]=Степова вулиця
addr:city=Дослідна станція

Щоб розкидати Collection по полігонах place, потрібно до відповідно зв’язку додати свій addr:city=*

Потім відповідний зв’язок Collection включати до assocoatedStreet з роллю street

Можна ще спробувати замість Collection використати простір імен. Для цієї лінії http://www.openstreetmap.org/browse/way/148112944 потрібно буде зробити так

name[:<lg>]:left=Степова вулиця
name[:<lg>]:right=Щорса вулиця
addr:city:left=Вигода
addr:city:right=Дослідна станція

Як на мою думку, основна проблема саме в графічному представленні однієї вулиці (ліні) різними назвами на головній ОСМ.орг. Якщо не брати це до уваги то достатньо тільки відповідних зв’язків assocoatedStreet

як в цьому прикладі

andygol, насправді, може так і було б краще…
Хто з конверторів, валідаторів, рендерів це підтримує, або, хоч збирається… Чи кожен, як завжди, буде чекати “критичної маси вживань”!? )
взагалі то, для мене виявилося несподіваним така кількість питань у рендеро-конверторів щодо необхідності для адресації будинків наявності саме веїв із співпадаючим “назві вулиці” ім’ям.

Є така мантра в ОСМ: «ми не мапимо під рендер/конвертер» :smiley:
То ж напевне я не можу відповісти на це питання. Намагаюсь мапити згідно прийнятим в ОСМ (де факто/де юре) схемам теґування об’єктів.