Як правильно вказувати адресу ?

ну, препроцесінг це хороший варіант :slight_smile:

проблема в тому, що тепер постало питання - а чи справді варто на hw ставити всі можливі name:xx чи може їх перенести в відношення? імхо, ця ідея має сенс, в добре відмаплених можна зняти теги name:xx з купи поділених відрізків (яких може бути і 2, і 20) і внести у відношення. Нема дублювання - менше проблем з невірними назвами і необхідністю вносити name:xx на всі можливі відрізки. А в погано відмаплених містах нема таких проблем з кількістю відрізків і іменами на них

Якщо така ідея прийнятна, буде потрібно якийсь пропозал написати, чи що…

Особисто мені така ідея зрозуміла і прийнятна, але все ж таки досить багато конверторів і рендерів використовують саме name:** на лініях
Видалення name:** в лініях буде розцінюватися як вандалізм

Хлопці, є ще такий нюанс стосовно релейшенів.

Я натрапив на ситуацію, коли для однієї вулиці було два релейшена (перший релейшен хтось зробив вручну, другий виник після імпортування даних dima_ua)
Перший релейшен мав тег type=associatedStreet, інший мав тег type=street. При цьому частина будинків та лінія вулиці були в першому релейшені, а інша частина будинків - у другому. А оскільки релейшени були різних типів, то у переліку релейшенів вони розташувалися не поруч. Якби ДЖОСМ при наборі не підкинув автоматом назву вулиці та якби я не тицнув на один з будиночків, я б навіть не дізнався, що є дублікат релейшена.

Давайте вже якось дійдемо згоди щодо використання street або associatedStreet
“Плюси” street

  1. коротше писати (однак це не досить вагомий аргумент, оскільки при набиранні ass… автоматично підкидається associatedStreet

“Плюси” associatedStreet

  1. цей тип є рекомендованим у пропозалі схеми Карлсруе (а про street написано лише “дозволяється використання”)
  2. JOSM (з relation toolbox) більше любить associatedStreet. Навіть вміє (однією кнопкою) розтавляти ролі street, house. А також автоматично прописує в тег релейшена name з відрізків вулиці.

Очевидно що плюсів в associatedStreet більше і вони вагоміші.
Використовую саме його, тому що так само прочитав в документації.
І будуть ще люди, які спочатку читають документацію, а потім вже діють. Не всі одразу занурюються в Potlatch з думкою “о, зараз я все перероблю, тут і так все зрозуміло, нащо ті інструкції” :slight_smile:

Ну, тоді може треба буде пройтися роботом по релейшенах та замінити street на assosiatedStreet. Тільки спочатку імпорт по Харкову закінчемо.:slight_smile:

А я не бачу зовсім переваг assosiatedStreet перед street. В першому випадку теги відношення обмежуються лише type і name, а в другому можна використовувати всі доступні теги. Потім, assosiatedStreet допускає лише street і house, а street дозволяє прив’язати будь-який об’єкт до вулиці. Так що ні в якому випадку не варто

А більше й не треба. А якщо й буде треба (як зараз у Харкові тимчасово додаємо street_id з номером), то можна додати й власні теги. Нема там тих обмежень.

А більше й не треба. А якщо треба прив’язати якійсь об’єкт, що не є будинком, то просто пропишіть йому у релейшені роль house.

Ще й як варто! Інакше й надалі будуть виникати дублі релейшенів.

Хлопці, де ви то взяли? На сьгоднішній день street та associatedStreet є повними сінонімамі.

Я сам починав мапити як associatedStreet, але потім, після виходу втулка relationtoolbox переключився на street через те, що підтримка associatedStreet в ньмоу певний час була відсутня.

Якщо ви бачите два зв’язки, їх треба об’єднати, один видалити, я видалаю більш нові. Об’єднання я роблю так:

  1. Вибрати відношення, яке буде видалено у reltoolbox (вулиця → два кліка на відношенні)

  2. Скопіювати відношення у буфер обміну (ctrl + c)

  3. Праву кнопку на назві відношення → Виділіти всі члени відношення

  4. Переключитися знову на відношення, видалити його

  5. Вибрати, яке залишиться (вулиця → два кліка на відношенні у reltoolbox)

  6. Скопіювати теґи (ctrl+shift+v)

  7. У історії виділень знайти виділення всіх членів старого відношення (зазвичай воно перед пунктом “неможливо вибрати”, тим, де було старе, вже видалене відношення)

  8. Перейти на редагування відношення (олівець у reltoolbox), відкриється стандартний діалог

  9. Зі списка справа перенести члени у відношення. Буде питання, чи дублювати члени у нове, сказати “ні”, і можливо “більше не питати”

Трохи воно задовге, може якось написати плагін, але думаю, що то не часта операція.

Ну, так або так як в вікі написано, або так як хочеться. Тут треба вже вирішитися. Не можливо в одному місці казати, що треба слідкувати вікі, а в іншомо казати, що обмежень немає. В ОСМ взагалі немає ніяких обмежень на теги.

Навіть якщо це віртуальний об’єкт? Тим самим підмінити одну суть іншою і втратити інформацію? Ні, дякую.

Від дублів варто позбавлятися, але не варто змінювати масово одне відношення на інше без очевидних переваг, лише томущо одне відношення зручніше прописувати в одному редакторі.

Якщо об’єкт має роль house, то мається на увазі, що об’єкт “виконує роль” будинка при адресації. Це не значить, що об’єкт сам стає будинком.

Якщо актор у театрі виконує роль Юлія Цезаря - це не значить, що актор насправді стає Юлієм Цезарем :slight_smile:

Ну так у вікі й написано: type=associatedStreet
І не написано, що неможна додавати власні теги до релейшену. Але це будуть лише ваші власні теги. Ніхто не зобов’язаний їх потім обробляти (у конвертерах, у рендерах). А яких тегів у релейшені не вистачає? note? description?

І як ви пропонуєте це “мається на увазі” програмно розпізнавати?

Покажіть мені, де тут написано, що допускаються інші теги. Якщо “власні” теги ніким не будуть оброблятися, то для чого вони тоді потрібні?
Не вистачає, наприклад: highway, name:*, surface, …

Ви пишете в тегах об’єкта addr:housenumber=17 та включаєте його до релейшена вулиці “Такаято вулиця” у ролі house.
osm2pm розпізнає та призначить тому об’єкту адресу “Такаято вулиця, 17”

Вони потрібні лише тому, хто їх пише. Наприклад, як тимчасові відмітки при імпортуванні даних.

Ці теги потрібні не в релейшені!
Ці теги мають бути на веях (відрізках) проїжджої частини вулиці, а також, якщо є потреба, на тротуарах.
Бо то є властивості лише відрізків, а не всієї вулиці як комплексу будинків, проходів та проїздів. До речі, часто буває таке, що одна й та сама вулиця має різні highway та surface на різних ділянках.

А релейшен потрібен для вказування адреси. Щоби показати, що оця пачка відрізків та оця купка будинків та земельних ділянок разом утворюють єдиний об’єкт - вулицю.

ОСМ не обмежується навігацією і osm2mp.

І хто буде потім видаляти ці тимчасові теги? Як розпізнати, що тег тимчасовий?

Ці теги не потрібні Вам і зараз, але це не ознаяає, що вони не потрібні або не корисні взагалі. Треба дивитися ширше і в майбутнє.

А часто буває, що одна вулиця має однакову назву, покриття, статус, стан освітлення, напрямок, ширину проїзжої частини, обмеження швидкості, заборону/дозвіл на проїзд для всіх/окремих видів транспорту… Не знаю на скільки близька Вам тема програмування, але почитайте про об’єкти та генералізацію, в ідеалі в UML.

Ось лише цим і обмежується associatedStreet! Відношення street дає набагато ширші можливості. Таким чином associatedStreet лише часний випадок street, а це означає, що при зміні всіх street на associatedStreet є вірогідність втрати інформації.

Так, але практично це одне з найпоширенішиз застосувань.

Пан знає інший конвертор у “польський формат”?

той, хто їх ставив

можна вважати такими теги, які не описані у вікі та не сприйняті й не ухвалені товариством.

Це просто “самодіяльність”.

Це властивості лише проїжджої частини вулиці, але не всієї вулиці. Хіба будинки на вулиці мають всі ті " покриття, статус, стан освітлення, напрямок, ширину проїзжої частини"? Звісно, що ні.

Це один і той самий тип відношення! Тільки слово “associatedStreet” рекомендоване до вживання, а про “street” написано, що його конвертор теж сприймає.

Для Вас очевидно навігація є приорітетним способом використання ОСМ даних, але ще раз - ОСМ не обмежується навігацією. А те що якийсь конвертор не знає як обробляти якісь дані, то це його проблема. В ОСМ панує принцип “якщо комусь щось треба, то він це робить”. Тобто, якщо вам потрібно щоб osm2mp вмів щось обробляти, то ви його правите відповідно. Я розумію, що не всі програмісти, але на сьогодні це принцип на якому працює ОСМ.
На рахунок тегів. В ОСМ формально немає ніяких обмежень, є лише домовленості. Кожен або притримується цих домовленостей, або ні. У всякому випадку, видалення тегів, які не задокументовані в вікі, або не відомі Вам може прирівнюватися до вандалізму.

В оприділенні відношення street не має чіткості. Там навіть написано, що можливо варто використовувати associatedStreet для прив’язування будинків до вулиці і включати це відношення у свою чергу до street. Те оприділення можна трактувати і так: об’єкт street має властивості (теги) і складається з відрізків у ролі street, а address/house/associated/others є посилання на об’єкти які зв’язані з street.

Проблема не в якомусь конкретному конверторі.

Мають бути єдині встановлені правила та способи маплення. І під ці правила також роблять і конвертор. А коли кожен маппер встановлює свої правила, а автор конвертера з ними не погоджується або навіть не знає про них, то й отримуємо неправильні мапи.

Тоді переконуйте людей, робіть кращі пропозиції. Мене Ви не переконали, що associatedStreet має переваги над street, а я очевидно не зміг переконати Вас, що street краще за associatedStreet. В такій ситуації масові зміни одного відношення на інше не допустиме.

Якщо застосування релейшенів типу street надає ті ж самі можливості, що й застосування релейшенів типу associatedStreet плюс додаткові можливості, то тоді навіщо існує associatedStreet ?

Як на мене, застосування двох типів релейшенів задля майже однакових цілей - це зайва плутанина у даних та зайва можливість виникнення помилок.

Історично, сумісність залишили власне щоб запобігти масових перейменувань.

тут більше йдеться про різницю між street (який скорочення від associatedStreet) і іншим пропозалом, який також використовує type=street і має додаткові ролі address, associated, etc.

синонім ролі address=house можна зрозуміти, а от що таке associated - неясно.