Czy istnieje wspólny projekt bazy danych adresów ulic dla wszystkich adresów na świecie?

Jestem programistą i szczerze mówiąc nie znam struktury adresów na świecie, tylko jak wygląda struktura w moim kraju :) Więc jaka jest najlepsza i powszechna baza danych do przechowywania adresów? Powinno być tak prosty w obsłudze, szybki i dynamiczny zapytania do przechowywania wszystkich adresów z całego świata, które identyfikuje tylko przez jeden identyfikator
dzięki dużo

Możliwe jest przedstawienie adresów z wielu różnych krajów w standardowym zestawie pól. Podstawowa idea nazwanej drogi dojazdowej (arterii), na której znajdują się nazwane lub ponumerowane budynki, jest dość standardowa, z wyjątkiem czasami Chin. Inne niemal uniwersalne koncepcje obejmują: nazwanie osady (miasto / miasto / wieś), które można ogólnie określić jako miejscowość; nazwanie regionu i przypisanie alfanumerycznego kodu pocztowego. Należy pamiętać, że kody pocztowe, nazywane również kodami pocztowymi, tylko w niektórych krajach są wyłącznie numeryczne. Będziesz potrzebował wielu pól, jeśli naprawdę chcesz być ogólny.

UPU Universal Postal Union dostarcza dane adresowe dla wielu krajów w standardowym formacie . Należy zauważyć, że format UPU przechowuje wszystkie adresy (z dokładnością do dostępnego pola) dla całego kraju, dlatego jest relacyjny. Jeśli przechowujesz adresy klientów, w których będzie przechowywana tylko niewielka część wszystkich możliwych adresów, lepiej jest użyć pojedynczej tabeli (lub płaskiego formatu) zawierającej wszystkie pola i jeden adres na wiersz.

Rozsądny format przechowywania adresów byłby następujący:

• Wiersze adresu 1-4
• Miejscowość
• Region
• Kod pocztowy (lub kod pocztowy)
• Kraj

Wiersze adresów 1-4 mogą zawierać takie komponenty, jak:

• Budynek
• Podbudowa
• Numer lokalu (numer domu)
• Zakres lokalu
• Przejście
• Pod-arteria
• Lokalność podwójnie zależna
• Podrejon

Często używane są tylko 3 linie adresowe, ale często jest to niewystarczające. Oczywiście można wymagać większej liczby wierszy, aby przedstawić wszystkie adresy w oficjalnym formacie, ale przecinki zawsze mogą być używane jako separatory wierszy, co oznacza, że ​​informacje można nadal przechwytywać.

Zazwyczaj analiza danych byłaby przeprowadzana według miejscowości, regionu, kodu pocztowego i kraju, a te elementy są dość łatwe do zrozumienia przez użytkowników podczas wprowadzania danych. Dlatego te elementy powinny być przechowywane jako oddzielne pola. Jednak nie zmuszaj użytkowników do podawania kodu pocztowego ani regionu, nie mogą być one używane lokalnie.

Lokalizacja może być niejasna, w szczególności rozróżnienie między lokalizacją na mapie a lokalizacją pocztową. Za miejscowość pocztową uważa się władze pocztowe, którym czasami może być pobliskie duże miasto. Jednak kod pocztowy zazwyczaj rozwiązuje wszelkie problemy lub rozbieżności, aby umożliwić poprawną dostawę, nawet jeśli nie jest używana oficjalna lokalizacja pocztowa.

Zapoznaj się z odpowiedziami dotyczącymi bazy danych . W szczególności dotyczy to wielu przypadków:

(Wszystkie typy danych o zmiennej długości)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Zadaj sobie pytanie, jaki jest główny cel przechowywania tych danych? Czy faktycznie zamierzasz wysłać pocztę do osoby pod adresem? Śledzić dane demograficzne, populacje? Potrafisz prosić rozmówców o ich prawidłowy adres w ramach podstawowego uwierzytelniania / weryfikacji? Wszystkie powyższe? Żadne z powyższych?

W zależności od rzeczywistych potrzeb określisz albo a) nie ma to znaczenia i możesz wybrać podejście oparte na wolnym tekście lub b) pola strukturalne / specyficzne dla wszystkich krajów lub c) architekturę specyficzną dla danego kraju.

Czasami adres najbliższy ulicy to miasto.

Miałem kiedyś projekt, aby umieścić wszystkie szkoły średnie w Indiach w Mapach Google. Napisałem sprytny program przy użyciu Google API i pomyślałem, że będzie to całkiem proste.

Następnie otrzymałem dane od klienta. Niektóre szkolne adresy brzmiały w stylu „Po drugiej stronie rynku, obok fryzjera” lub „W pobliżu starego przystanku autobusowego”.

To znacznie utrudniło mi zadanie, ponieważ niestety Google API nie obsługuje tego formatu.

W przypadku adresów międzynarodowych niezwykle trudno jest znaleźć sposób na sformatowanie informacji, jeśli są one podzielone na pola. Na przykład włoski adres używa:

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

Jak na przykład

Via Eroi della Repubblica
89861 Tropea VV
Italy

To raczej różni się od kolejności adresów w USA - w drugim wierszu.

Zobacz także pytania SO:

• Ilu pól adresowych użyłbyś w brytyjskiej bazie danych?
• Czy dzielisz adresy na ulicę / miasto / stan / kod pocztowy?
• Jak radzisz sobie ze zduplikowanymi sufiksami ulic?
• Najlepsze praktyki dotyczące przechowywania adresów pocztowych w bazie danych (RDBMS)?

Sprawdź także tag „ kod pocztowy ”.

Edycja : Odwróć kolejność regionów i miast - według UPU

Może jest to przydatne: https://gist.github.com/259744 Dla projektu zebrałem tabelę informacji o wszystkich krajach świata, w tym kody ISO, domena najwyższego poziomu, kod telefonu, znak samochodu, długość i regex zamek błyskawiczny. Nazwy krajów i komentarze niestety tylko w języku niemieckim ...

Zależy od tego, jak swobodny jesteś przygotowany do pracy z polami. Jedno pole adresu o dowolnym formacie oczywiście zawsze się sprawdzi, ale stosunkowo niewiele pomoże w zawężeniu geografii.

Problem polega na tym, że istnieje zbyt duże zróżnicowanie poziomu hierarchii geograficznej w poszczególnych krajach. Do licha, w niektórych krajach nie ma nawet „adresów pocztowych”.

Nie radzę robić tego zbyt sprytnie.

W odróżnieniu od innych odpowiedzi tutaj, uważam, że możliwe jest posiadanie ustrukturyzowanej bazy danych adresów.

Zaraz po wyjęciu z kapelusza przychodzi mi do głowy następująca struktura:

• Kraj
• Region (stan / prowincja)
• Miejscowość (miasto / gmina)
• Podrejon (powiat / inny podrejon miejscowości)
• Ulica

Ale jak szybko zapytać?

Zawsze uważam, że jednym ze sposobów jest poproszenie o kod pocztowy (lub kod pocztowy), który różni się w zależności od kraju, ale jest stały w całym kraju.

W ten sposób możesz uporządkować swoje dane wokół informacji dostarczanych przez urzędy pocztowe na całym świecie.

Len Silverston z Universal Data Model zaleca oddzielną hierarchię GEOGRAPHIC BOUNDARIESi zależnie od tego, ile dowolnych formacji jesteś skłonny zaakceptować albo proste STREET ADDRESS LINEinstrumenty pochodne, albo instrumenty pochodne dla poszczególnych krajów.

Nie, absolutnie nie. Jeśli porównasz sposób działania adresów w USA i Japonii , zobaczysz, że nie jest to możliwe.

AKTUALIZACJA:

Po namyśle wszystko można zrobić, ale istnieje kompromis.

Jednym podejściem jest modelowanie problemu za pomocą tabel adres i atrybut_adresu, z relacją 1: m między nimi, wszystko można modelować. Tablica address_attribute miałaby pk, nazwę, wartość i fk, które wskazują z powrotem na pk swojego nadrzędnego adresu. To prawie tak, jakby używać mapy z parami nazw i wartości.

Kompromisem jest wykonanie JOIN za każdym razem, gdy potrzebujesz adresu. Musisz również przepytać nazwy atrybutów address_attributes, aby dowiedzieć się, z czym masz do czynienia za każdym razem.

Innym podejściem byłoby przeprowadzenie bardziej kompleksowych badań nad modelowaniem adresów na całym świecie. W świecie zorientowanym obiektowo możesz mieć zachodnią klasę adresu (ulica1 / ulica2 / miasto / stan / kod pocztowy) i inne dla Japonii i Chin, tyle, ile potrzeba do ułożenia przestrzeni adresowej. Wtedy miałbyś główną tabelę adresów i tabele podrzędne dla innych typów z relacją 1: 1 między nimi.

Jak to robi Amazon czy eBay? Wysyłają za granicę. Czy mają funkcje interfejsu użytkownika specyficzne dla lokalizacji? Użyłem tylko ustawień regionalnych w USA.

Nie, nie ma standardowego schematu adresowania. Zwykle różni się w zależności od kraju. Nawet Światowy Związek Pocztowy powiedział o adresowaniu świata, adresie dla wszystkich, którego nie ma. Najlepszym rozwiązaniem jest użycie 2/3-literowego standardu kodu kraju znanego jako ISO 3166 i traktowanie wszystkiego innego według norm krajowych.

Jeśli jednak naprawdę desperacko pragniesz użyć łatwo dostępnych narzędzi do swojego projektu, możesz wypróbować Google Place API .

Twój projekt powinien silnie zależeć od celu. Niektóre osoby opublikowały opis struktury danych. Więc jeśli po prostu chcesz wysłać komuś wiadomość e-mail, wystarczy. Sprawy zaczynają się komplikować, jeśli chcesz używać tych danych do nawigacji. Nawigacja samochodowa będzie wymagała dodatkowych struktur zawierających informacje o ruchu (np. Drogi jednokierunkowe), podczas gdy nawigacja piesza będzie wymagała wielu dodatkowych danych. Oto mały przykład: w moim mieście moja okolica znajduje się w pobliżu parku. Obok parku znajduje się dawne lotnisko (właściwie jedno z najstarszych w Europie) zamienione w muzeum lotnictwa. Obok muzeum lotnictwa znajduje się park biznesowy. Numer ulicy dla muzeum to 39, a numery parków biznesowych zaczynają się od 39A. Może się więc wydawać, że 39 i 39A są blisko - ale przejście od jednego do drugiego zajmuje około mili (a nawet dłużej, jeśli jedzie się samochodem).
To tylko mały przykład zaczerpnięty z mojego miasta, myślę, że prawdopodobnie można znaleźć wiele wyjątków (szczególnie w wiejskich lub dzikich częściach każdego kraju).