Zanim zaczniesz

W tym dokumencie opisujemy wymagania wstępne, sprawdzone metody i typowe błędy związane z pracą ze zbiorami danych.

Wymagania wstępne

Podczas tworzenia zbioru danych:

  • Wyświetlane nazwy muszą być unikalne w projekcie Google Cloud.
  • Wyświetlane nazwy muszą mieć mniej niż 64 bajty (ponieważ te znaki są reprezentowane w 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. Obejmuje to sufiks "Z" w formacie WKT, i współrzędną 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 większym niż 50 MB należą do tej kategorii), przed przesłaniem rozważ uproszczenie danych, aby uzyskać najlepszą wydajność na mapie wizualnej.

Oto kilka sprawdzonych metod przygotowywania danych:

  1. Zminimalizuj właściwości obiektów. Zachowaj tylko te właściwości obiektów, które są potrzebne do stylizacji mapy, np. „id” i „category”. Możesz połączyć dodatkowe właściwości z obiektem w aplikacji klienckiej za pomocą stylów opartych na danych na podstawie unikalnego klucza identyfikatora. Więcej informacji znajdziesz np. w artykule Wyświetlanie danych w czasie rzeczywistym za pomocą stylizacji opartej na danych.
  2. W miarę możliwościużywaj prostych typów danych dla obiektów właściwości, np. liczb całkowitych, aby zminimalizować rozmiar kafelka i poprawić wydajność mapy.
  3. 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.
  4. 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 punktów.

Dodatkowe wskazówki dotyczące sprawdzonych metod związanych ze zbiorami danych znajdziesz w artykule Wizualizacja danych za pomocą zbiorów danych i BigQuery.

Wymagania dotyczące GeoJSON

Interfejs Maps Datasets API obsługuje aktualną specyfikację GeoJSON. Interfejs Maps Datasets API obsługuje też pliki GeoJSON, które zawierają dowolny z tych typów obiektów:

  • Obiekty geometrii. Obiekt geometrii to kształt przestrzenny opisany jako suma punktów, linii i wielokątów z opcjonalnymi otworami.
  • Obiekty obiektów. Obiekt obiektu zawiera geometrię oraz dodatkowe pary nazwa/wartość, których znaczenie jest specyficzne dla aplikacji.
  • Kolekcje obiektów. Kolekcja obiektów to zbiór obiektów.

Interfejs Maps Datasets API nie obsługuje plików GeoJSON, które zawierają dane w innym układzie współrzędnych (CRS) niż WGS84.

Więcej informacji o GeoJSON znajdziesz w dokumencie 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 punktów, linii i wielokątów.
  • Wszystkie atrybuty danych są traktowane jako ciągi znaków.
Te funkcje KML nie są obsługiwane:
  • Ikony lub <styleUrl> zdefiniowane poza plikiem.
  • Linki sieciowe, np. <NetworkLink>
  • Obrazy nad powierzchnią, np. <GroundOverlay>.
  • Geometrie 3D lub tagi związane z wysokością, np. <altitudeMode>.
  • Specyfikacje aparatu, np. <LookAt>.
  • Style zdefiniowane w pliku KML.

Wymagania dotyczące CSV

W przypadku plików CSV obsługiwane nazwy kolumn są wymienione poniżej w kolejności priorytetu:

  • latitude, longitude
  • lat, long
  • x, y
  • wkt (Well-Known Text)
  • address, city, state, zip
  • address
  • Pojedyncza kolumna zawierająca wszystkie informacje o adresie, np. 1600 Amphitheatre Parkway Mountain View, CA 94043

Załóżmy, że 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 liście powyżej, 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. Nie możesz więc 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 np. plik CSV zawiera lat i long kolumny, mogą one występować w dowolnej kolejności.

Rozwiązywanie problemów z przesyłaniem danych

Podczas przesyłania danych do zbioru danych może wystąpić jeden z typowych błędów opisanych w tej sekcji.

Błędy GeoJSON

Typowe błędy GeoJSON to:

  • Brak pola type lub pole type nie jest ciągiem znaków. Przesłany plik danych GeoJSON musi zawierać pole ciągu znaków o nazwie type jako część definicji każdego obiektu obiektu i obiektu geometrii.

Błędy KML

Typowe błędy KML to:

  • Plik danych nie może zawierać żadnych nieobsługiwanych funkcji KML wymienionych powyżej. W przeciwnym razie import danych może się nie udać.

Błędy CSV

Typowe błędy CSV to:

  • 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 to:
    • latitude, longitude
    • lat, long
    • x, y
    • wkt
    • address, city, state, zip
    • address
    • Pojedyncza kolumna zawierająca wszystkie informacje o adresie, np. 1600 Amphitheatre Parkway Mountain View, CA 94043
  • Jeśli x i y są kolumnami geometrii, upewnij się, że jednostki to długość i szerokość geograficzna. Niektóre publiczne zbiory danych używają różnych układów współrzędnych w nagłówkach x i y. Jeśli używane są nieprawidłowe jednostki, import zbioru danych może się udać, ale renderowane dane mogą wyświetlać punkty zbioru danych w nieoczekiwanych lokalizacjach.