Чи існує спільна розробка баз даних вуличних адрес для всіх адрес світу?

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

Можна представити адреси з безлічі різних країн у стандартному наборі полів. Основна ідея названого маршруту доступу (магістраль), на якому розташовані названі або пронумеровані будівлі, є досить стандартною, за винятком випадків у Китаї. Інші близькі до універсальних понять включають: називання населеного пункту (міста / селища / села), яке загалом можна назвати місцевістю; називання регіону та присвоєння буквено-цифрового поштового індексу. Зауважте, що поштові індекси, також відомі як поштові індекси, чисто числові лише в деяких країнах. Вам знадобиться багато полів, якщо ви дійсно хочете бути загальними.

Універсальний поштовий союз UPU надає адресні дані для багатьох країн у стандартному форматі . Зауважте, що формат UPU містить усі адреси (аж до доступної точності поля) для цілої країни, тому він є реляційним. Якщо зберігати адреси клієнтів, де буде зберігатися лише невелика частка всіх можливих адрес, краще використовувати єдину таблицю (або плоский формат), що містить усі поля та одну адресу в рядку.

Доцільним форматом для зберігання адрес буде такий:

• Рядки адрес 1-4
• Місцевість
• Область
• Поштовий індекс (або поштовий індекс)
• Країна

Рядки адреси 1-4 можуть містити такі компоненти, як:

• Будівництво
• Підбудова
• Номер приміщення (номер будинку)
• Діапазон приміщень
• Грунтовний ремонт
• Підпорядкованість
• Місцевість подвійної залежності
• Підміст

Часто використовуються лише 3 рядки адреси, але цього часто недостатньо. Звичайно, можна зажадати більше рядків для представлення всіх адрес в офіційному форматі, але комами завжди можна використовувати як роздільники рядків, тобто інформація все ще може бути захоплена.

Зазвичай аналіз даних проводиться за місцевістю, регіоном, поштовим індексом та країною, і ці елементи для користувачів досить легко зрозуміти під час введення даних. Ось чому ці елементи слід зберігати як окремі поля. Однак не змушуйте користувачів вводити поштовий індекс або регіон, вони можуть не використовуватися локально.

Місцевість може бути неясною, особливо різниця між місцевістю карт та поштовим місцевістю. Місце поштового зв’язку - це той, який вважається поштовим органом, який іноді може бути поблизу великого міста. Однак поштовий індекс, як правило, вирішує будь-які проблеми або розбіжності там, щоб дозволити правильну доставку, навіть якщо офіційна поштова адреса не використовується.

Подивіться відповіді на бази даних . Зокрема, це стосується багатьох випадків:

(Усі типи символів змінної довжини)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Запитайте себе, яка головна мета зберігання цих даних? Ви маєте намір фактично надіслати пошту людині за адресою? Відстежуйте демографічні показники, кількість населення? Уміти запитувати абонентів про їх правильну адресу як частину базової автентифікації / підтвердження? Все вищеперераховане? Жоден з вищевказаних?

Залежно від вашої реальної потреби, ви визначите або: а) це насправді не має значення, і ви можете скористатися підходом до вільного тексту, або б) структурованими / специфічними полями для всіх країн, або c) архітектурою, характерною для кожної країни.

Іноді найближчим адресою вулиці може стати місто.

Я колись мав проект розмістити всі середні школи Індії на Google Maps. Я написав пікантну програму за допомогою API Google і подумав, що це буде досить просто.

Потім я отримав дані від клієнта. Деякі шкільні адреси були такими, як "Через ринок, поруч із перукарем" або "Біля старої стоянки автобуса".

Це значно ускладнило моє завдання, оскільки, на жаль, API Google не підтримує цей формат.

Для міжнародних адрес надзвичайно важко знайти спосіб відформатувати інформацію, якщо вона розбита на поля. Наприклад, італійська адреса використовує:

<street address>
<zip> <town> <region>
<country>

Як от

Via Eroi della Repubblica
89861 Tropea VV
Italy

Це значно відрізняється від замовлення на американські адреси - у другому рядку.

Дивіться також питання щодо ПЗ:

• Скільки адресних полів ви б використали для бази даних у Великобританії?
• Ви розбиваєте адреси на вулицю / місто / штат / zip?
• Як ви маєте справу з дублікатами вуличних суфіксів?
• Найкращі практики зберігання поштових адрес у базі даних (RDBMS)?

Також перевірте тег " Поштовий індекс ".

Редагувати : Зворотний порядок регіону та міста - за UPU

Можливо, це корисно: https://gist.github.com/259744 Для проекту я зібрав таблицю інформації про всі країни світу, включаючи коди ISO, домен верхнього рівня, телефонний код, автомобільний знак, довжину та регулярний вираз блискавка. Назви країн та коментарі, на жаль, лише німецькою мовою ...

Залежить від того, наскільки вільна форма ви готові йти з полями. Одне поле у ​​вільній формі, очевидно, завжди буде, але порівняно мало допоможе звузити географію.

Проблема у вас полягає в тому, що рівень географічної ієрархії в різних країнах є занадто великим. Чорт, деякі країни навіть не мають "адрес вулиць" скрізь.

Я рекомендую вам не намагатися зробити це занадто розумним.

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

Щойно з капелюха я можу придумати таку структуру:

• Країна
• Регіон (штат / провінція)
• Місцевість (місто / муніципалітет)
• Підміст (округ / інший підрозділ місцевості)
• Вулиця

Але як запитувати його досить швидко?

Один із способів, я завжди думаю, що це може бути досягнуто, - це попросити поштовий індекс (або поштовий індекс), який варіюється від країни до країни, але є надійним у межах країни.

Таким чином ви можете структурувати свої дані навколо інформації, що надається поштовими відділеннями по всьому світу.

Лен Сільверстон із слави універсальної моделі даних рекомендує окрему ієрархію GEOGRAPHIC BOUNDARIESта залежно від того, наскільки вільно формується, ви готові прийняти як прості STREET ADDRESS LINEпохідні, так і похідні країни.

Ні, абсолютно ні. Якщо порівняти спосіб роботи американських та японських адрес , ви побачите, що це неможливо.

ОНОВЛЕННЯ:

По-друге, можна зробити що завгодно, але є компроміс.

Один із підходів полягає у моделюванні проблеми з адресами та таблицями address_attribute із співвідношенням 1: m між ними, і все можна моделювати. Таблиця address_attribute матиме pk, ім'я, значення та fk, які вказують на pk батьківського адреси адреси. Це майже як використання карт з іменем, значеннями пар.

Компроміс повинен робити ПРИЄДНАЙТЕСЬ щоразу, коли ви хочете адресу. Вам також доведеться допитувати імена адреси_attributes, щоб зрозуміти, з чим ви маєте справу щоразу.

Іншим підходом було б зробити більш всебічне дослідження того, як моделюються адреси в усьому світі. У об'єктно-орієнтованому світі у вас може бути західний клас адреси (street1 / street2 / city / state / zip) та інші для Японії, Китаю стільки, скільки потрібно для встановлення плитки адресного простору. Тоді ви матимете головну таблицю адрес та дочірні таблиці до інших типів із співвідношенням 1: 1 між ними.

Як це роблять Amazon чи eBay? Вони постачаються на міжнародному рівні. Чи є у них особливості інтерфейсу, характерні для локальної мережі? Я використовував лише місцевість США.

Ні, немає стандартної схеми адресації. Зазвичай вона варіюється в залежності від країни. Навіть Універсальний поштовий союз заявив про адресу "Світ у світі" - адресу для всіх, що його немає. Найкращим рішенням для цього є використання 2/3-літерних стандартів коду країни, відомих як ISO 3166, та обробляти все інше за стандартами країни.

Однак якщо ви справді відчайдушно використовуєте легко доступні інструменти для свого проекту, можете спробувати API Google Place .

Ваш дизайн повинен сильно залежати від вашого призначення. Деякі люди розмістили інформацію про структурування даних. Тож якщо ви просто хочете надіслати електронний лист комусь, це станеться. Речі починають ускладнюватися, якщо ви хочете використовувати ці дані для навігації. Для автомобільної навігації знадобляться додаткові структури, щоб містити інформацію про дорожній рух (наприклад, дороги в одну сторону), тоді як навігація пішки потребує багато додаткових даних. Ось невеликий приклад: у моєму місті мій район поблизу парку. Поруч з парком знаходиться колишній аеродром (фактично один із найстаріших в Європі), перетворений на музей авіації. Поруч з музеєм авіації знаходиться бізнес-парк. Номер вулиці для музею - 39, а номер бізнес-парку починається з 39А. Тож може здатися, що 39 і 39А близькі - але пішки від одного до іншого потрібно (і навіть довше, якщо їхати на машині).
Це лише невеликий приклад, взятий з мого міста, я думаю, що ви, мабуть, можете знайти багато винятків (особливо в сільській чи дикій частині кожної країни).