W tym dokumencie opisujemy wymagania wstępne, sprawdzone metody i często popełniane błędy podczas pracy z zbiorami danych.
Wymagania wstępne
Podczas tworzenia zbioru danych:
- Nazwy wyświetlane muszą być unikalne w projekcie Google Cloud.
- Wyświetlane nazwy muszą mieć mniej niż 64 bajty (ponieważ te znaki są reprezentowane w formacie UTF-8, w niektórych językach każdy znak może być reprezentowany przez wiele bajtów).
- Opisy muszą mieć mniej niż 1000 bajtów.
Podczas przesyłania danych:
- Obsługiwane typy plików to CSV, GeoJSON i KML.
- Maksymalny obsługiwany rozmiar pliku to 500 MB.
- Nazwy kolumn atrybutów nie mogą zaczynać się od ciągu znaków „?_”.
- Geometrie trójwymiarowe nie są obsługiwane. Dotyczy to przyrostka „Z” w formacie WKT i współrzędnej wysokości w formacie GeoJSON.
Sprawdzone metody przygotowywania danych
Jeśli dane źródłowe są złożone lub duże, np. zawierają gęste punkty, długie linie lub wielokąty (często pliki źródłowe o rozmiarze powyżej 50 MB należą do tej kategorii), przed przesłaniem ich do wizualnej mapy rozważ uproszczenie danych, aby uzyskać najlepszą wydajność.
Oto kilka sprawdzonych metod przygotowywania danych:
- Minimalizuj właściwości funkcji Zachowaj tylko właściwości funkcji potrzebne do stylizowania mapy, np. „id” i „category”. W aplikacji klienckiej możesz łączyć dodatkowe właściwości z funkcją za pomocą stylów opartych na danych na podstawie klucza unikalnego identyfikatora. Na przykład zobacz Wyświetlanie danych w czasie rzeczywistym za pomocą stylów opartych na danych.
- W przypadku obiektów właściwości używaj prostych typów danych, takich jak liczby całkowite, aby zminimalizować rozmiar kafelka i zwiększyć wydajność mapy.
- Przed przesłaniem pliku uprość złożone geometrie. Możesz to zrobić w wybranym narzędziu geoprzestrzennym, np. w narzędziu open source Mapshaper.org lub w BigQuery za pomocą funkcji ST_Simplify w przypadku złożonych geometrii wielokątów.
- Przed przesłaniem pliku zgrupuj bardzo gęste punkty. Możesz to zrobić w wybranym narzędziu geoprzestrzennym, np. w funkcjach klastrowania open source turf.js lub w BigQuery za pomocą funkcji ST_CLUSTERDBSCAN w przypadku gęstych geometrii punktowych.
Dodatkowe wskazówki dotyczące sprawdzonych metod związanych ze zbiorami danych znajdziesz w artykule Wizualizowanie danych za pomocą zbiorów danych i BigQuery.
Wymagania dotyczące GeoJSON
Interfejs Maps Datasets API obsługuje bieżącą specyfikację GeoJSON. Interfejs Maps Datasets API obsługuje też pliki GeoJSON zawierające dowolny z tych typów obiektów:
- Obiekty geometryczne Obiekt geometryczny to kształt przestrzenny opisany jako suma punktów, linii i wielokątów z opcjonalnymi otworami.
- obiekty funkcji, Obiekt funkcji zawiera geometrię oraz dodatkowe pary nazwa/wartość, których znaczenie zależy od aplikacji.
- Kolekcje funkcji Kolekcja obiektów to zbiór obiektów.
Interfejs Maps Datasets API nie obsługuje plików GeoJSON, które zawierają dane w układzie odniesienia przestrzennego innym niż WGS84.
Więcej informacji o GeoJSON znajdziesz w artykule Zgodność z RFC 7946.
Wymagania dotyczące KML
Interfejs Maps Datasets API ma te wymagania:
- Wszystkie adresy URL muszą być lokalne (lub względne) w stosunku do samego pliku.
- Obsługiwane są geometrie punktowe, liniowe i wielokątne.
- Wszystkie atrybuty danych są traktowane jako ciągi tekstowe.
- Ikony lub
<styleUrl>zdefiniowane poza plikiem. - Linki do sieci, np.
<NetworkLink> - nakładki na powierzchnię, np.
<GroundOverlay>; - geometrie 3D ani żadne tagi związane z wysokością, np.
<altitudeMode>; - Specyfikacje aparatu, np.
<LookAt> - Style zdefiniowane w pliku KML.
Wymagania dotyczące plików CSV
W przypadku plików CSV obsługiwane nazwy kolumn są wymienione poniżej w kolejności priorytetu:
latitude,longitudelat,longx,ywkt(Well-Known Text)address,city,state,zipaddress- Jedna kolumna zawierająca wszystkie informacje o adresie, np.
1600 Amphitheatre Parkway Mountain View, CA 94043
Na przykład plik zawiera kolumny o nazwach x, y i wkt.
Ponieważ kolumny x i y mają wyższy priorytet (określony przez kolejność obsługiwanych nazw kolumn na powyższej liście), używane są wartości w kolumnach x i y, a kolumna wkt jest ignorowana.
Ponadto:
- Każda nazwa kolumny musi należeć do jednej kolumny. Oznacza to, że nie możesz mieć kolumny o nazwie
xy, która zawiera dane współrzędnych x i y. Współrzędne x i y muszą znajdować się w osobnych kolumnach. - W nazwach kolumn wielkość liter nie jest rozróżniana.
- Kolejność nazw kolumn nie ma znaczenia. Jeśli na przykład plik CSV zawiera kolumny
latilong, mogą one występować w dowolnej kolejności.
Obsługa błędów przesyłania danych
Podczas przesyłania danych do zbioru danych może wystąpić jeden z typów błędów opisanych w tej sekcji.
Błędy GeoJSON
Do częstych błędów GeoJSON należą:
- Brak pola
typelub poletypenie jest ciągiem znaków. Przesłany plik danych GeoJSON musi zawierać pole tekstowe o nazwietypew definicji każdego obiektu Feature i obiektu Geometry.
Błędy KML
Do typowych błędów KML należą:
- Plik danych nie może zawierać żadnych z wymienionych powyżej nieobsługiwanych funkcji KML, w przeciwnym razie import danych może się nie powieść.
Błędy w pliku CSV
Do typowych błędów w pliku CSV należą:
- W niektórych wierszach brakuje wartości w kolumnie geometrii. Wszystkie wiersze w pliku CSV muszą zawierać niepuste wartości w kolumnach geometrii. Kolumny geometrii obejmują:
latitude,longitudelat,longx,ywktaddress,city,state,zipaddress- Jedna kolumna zawierająca wszystkie informacje o adresie, np.
1600 Amphitheatre Parkway Mountain View, CA 94043
- Jeśli kolumnami geometrii są
xiy, upewnij się, że jednostkami są długość i szerokość geograficzna. Niektóre publiczne zbiory danych używają różnych systemów współrzędnych w nagłówkachxiy. Jeśli użyjesz nieprawidłowych jednostek, zbiór danych może zostać zaimportowany, ale wyrenderowane dane mogą wyświetlać punkty zbioru danych w nieoczekiwanych lokalizacjach.