Package google.type

Indeks

LatLng

Obiekt reprezentujący parę szerokości i długości geograficznej. Jest to para liczb podwójnie po przecinku, która reprezentuje stopnie szerokości i długości geograficznej. O ile nie określono inaczej, obiekt musi być zgodny ze standardem WGS84. Wartości muszą mieścić się w normalizowanych zakresach.

Pola
latitude

double

Szerokość geograficzna w stopniach. Musi mieścić się w zakresie [-90,0, +90,0].
longitude

double

Długość geograficzna w stopniach. Musi mieścić się w zakresie [-180,0, +180,0].

LocalizedText

Lokalizacja tekstu w określonym języku.

Pola
text

string

Zlokalizowany ciąg tekstowy w języku odpowiadającym wartości language_code poniżej.
language_code

string

Kod języka tekstu w formacie BCP-47, np. „pl-PL” lub „sr-Latn”.

Więcej informacji znajdziesz na stronie http://www.unicode.org/reports/tr35/#Unicode_locale_identifier.

PostalAddress

Reprezentuje adres pocztowy (np. adres do dostawy pocztowej lub adres do płatności). Na podstawie adresu pocztowego usługa pocztowa może dostarczyć produkty do budynku, skrytki pocztowej lub podobnego miejsca. Nie służy do modelowania lokalizacji geograficznych (drogi, miast, gór).

W zwykłym przypadku adres jest tworzony przez użytkownika lub importowany z dotychczasowych danych, w zależności od typu procesu.

Porady dotyczące wprowadzania i edytowania adresów: – Użyj widżetu adresu gotowego do użycia w różnych krajach, np. https://github.com/google/libaddressinput. – użytkownicy nie powinni mieć możliwości wprowadzania danych ani edytowania pól poza krajami, w których są one używane;

Więcej informacji o używaniu tego schematu znajdziesz na stronie https://support.google.com/business/answer/6397478.

Pola
revision

int32

Wersja schematu PostalAddress. Musisz ustawić wartość 0, która jest najnowszą wersją.

Wszystkie nowe wersje muszą być zgodne wstecz ze starszymi wersjami.
region_code

string

Wymagane. Kod regionu CLDR kraju/regionu adresu. Nie jest to nigdy wnioskowane, a użytkownik musi sam sprawdzić, czy wartość jest prawidłowa. Więcej informacji znajdziesz na stronach https://cldr.unicode.org/ i https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html. Przykład: „CH” dla Szwajcarii.
language_code

string

Opcjonalnie. Kod języka BCP-47 treści podanych pod tym adresem (jeśli jest znany). Jest to często język interfejsu formularza wprowadzania danych lub ma odpowiadać jednemu z języków używanych w kraju/regionie, w którym znajduje się adres, lub ich transliterowanym odpowiednikom. Może to wpływać na formatowanie w niektórych krajach, ale nie ma to kluczowego znaczenia dla poprawności danych. Nie wpłynie to też na żadną weryfikację ani inne operacje niezwiązane z formatowaniem.

Jeśli ta wartość jest nieznana, należy ją pominąć (zamiast podawać potencjalnie nieprawidłową wartość domyślną).

Przykłady: „zh-Hant”, „ja”, „ja-Latn”, „en”.
postal_code

string

Opcjonalnie. Kod pocztowy w adresie. Nie we wszystkich krajach stosuje się kody pocztowe lub wymaga się ich podawania, ale tam, gdzie są używane, mogą one powodować dodatkową weryfikację innych części adresu (np. weryfikację stanu lub kodu pocztowego w Stanach Zjednoczonych).
sorting_code

string

Opcjonalnie. Dodatkowy kod sortowania w danym kraju. Nie jest on używany w większości regionów. W przypadku, gdy jest używany, wartość to ciąg znaków, np. „CEDEX”, opcjonalnie z dodatkowym numerem (np. „CEDEX 7”), lub tylko liczba, która reprezentuje „kod sektora” (Jamajka), „wskaźnik obszaru dostawy” (Malawi) lub „wskaźnik urzędu pocztowego” (Wybrzeże Kości Słoniowej).
administrative_area

string

Opcjonalnie. Najwyższy podział administracyjny używany w przypadku adresów pocztowych w kraju lub regionie. Może to być na przykład stan, prowincja, obwód lub prefektura. W Hiszpanii jest to prowincja, a nie autonomiczna społeczność (np. „Barcelona”, a nie „Katalonia”). W wielu krajach w adresach pocztowych nie podaje się obszaru administracyjnego. Na przykład w Szwajcarii nie należy wypełniać tego pola.
locality

string

Opcjonalnie. Zwykle odnosi się do części adresu zawierającej nazwę miasta. Przykłady: miasto w USA, miasto w Włoszech, miejscowość w Wielkiej Brytanii. W regionach świata, w których lokalizacja nie jest dobrze zdefiniowana lub nie pasuje do tej struktury, pozostaw pole locality puste i użyj pola address_lines.
sublocality

string

Opcjonalnie. Podjednostka adresu. Może to być na przykład dzielnica, okręg lub region.
address_lines[]

string

Nieustrukturyzowane wiersze adresu opisujące niższe poziomy adresu.

Wartości w elementach address_lines nie zawierają informacji o typie i czasami mogą zawierać kilka wartości w pojedynczym polu (np. „Austin, Teksas”), dlatego ważne jest, aby kolejność wierszy była jasna. Kolejność wierszy adresu powinna być zgodna z „kolejnością na kopercie” w kraju lub regionie, w którym znajduje się adres. W miejscach, gdzie może to się różnić (np. w Japonii), używamy znaku address_language, aby to wyraźnie zaznaczyć (np. „ja” dla kolejności od dużego do małego i „ja-Latn” lub „en” dla kolejności od małego do dużego). Dzięki temu można wybrać najbardziej szczegółowy wiersz adresu na podstawie języka.

Minimalna dopuszczalna reprezentacja strukturalna adresu składa się z region_code, a wszystkie pozostałe informacje są umieszczane w address_lines. Bez geokodowania można by sformatować taki adres bardzo przybliżony, ale nie można było przeprowadzić żadnej analizy semantycznej dotyczącej żadnych elementów adresu, dopóki nie zostały one co najmniej częściowo rozpoznane.

Utworzenie adresu zawierającego tylko region_code i address_lines, a następnie geokodowanie jest zalecanym sposobem postępowania w przypadku całkowicie nieustrukturyzowanych adresów (zamiast zgadywania, które części adresu powinny być miejscowościami lub obszarami administracyjnymi).
recipients[]

string

Opcjonalnie. Odbiorca pod tym adresem. W pewnych okolicznościach to pole może zawierać informacje na kilku wierszach. Może ona na przykład zawierać informacje o adresacie korespondencji.
organization

string

Opcjonalnie. Nazwa organizacji pod tym adresem.