W tym dokumencie znajdziesz architekturę odniesienia i przykład tworzenia wizualizacji danych mapowych z danymi o lokalizacji w BigQuery w Google Cloud Platform i w interfejsie API Zbiorów danych Google Maps Platform, np. analizowanie otwartych danych gminnych, tworzenie mapy zasięgu telekomunikacji czy wizualizacja śladów ruchu floty pojazdów.
Wizualizacje danych mapowych to potężne narzędzie do zwiększania zaangażowania użytkowników i uzyskiwania statystyk przestrzennych na podstawie danych o lokalizacji. Dane o lokalizacji to dane, które zawierają obiekty punktowe, liniowe lub wielokątne. Na przykład mapy pogodowe pomagają konsumentom planować podróże i przygotowywać się na burze. Mapy analityki biznesowej pomagają użytkownikom uzyskać statystyki na podstawie analizy danych. Mapy telekomunikacyjne pomagają użytkownikom poznać zasięg i jakość usług dostawców w danym obszarze.
Deweloperom aplikacji trudno jednak tworzyć wizualizacje dużych zbiorów danych mapowych, które są wydajne i zapewniają użytkownikom świetne wrażenia. Duże dane muszą być wczytywane do pamięci po stronie klienta, co powoduje długi czas wczytywania mapy. Elementy wizualne muszą działać prawidłowo na wszystkich urządzeniach, w tym na tańszych telefonach komórkowych, które mają ograniczenia pamięci i procesora graficznego. Na koniec deweloperzy muszą wybrać bibliotekę do renderowania dużych danych, która jest przenośna, niezawodna i wydajna w przypadku dużych danych.
Architektura referencyjna
Tworzenie aplikacji z wizualizacjami dużych zbiorów danych wymaga 2 głównych komponentów.
- Backend klienta – wszystkie dane i usługi aplikacji backendowej, takie jak przetwarzanie i przechowywanie.
- Klient klienta – interfejs aplikacji z elementem wizualizacji mapy.
Poniżej znajduje się diagram systemu pokazujący, jak te 2 elementy współdziałają z użytkownikiem aplikacji, Google Cloud i Google Maps Platform, aby utworzyć aplikację do wizualizacji dużych zbiorów danych.
Uwagi dotyczące projektu
Aby utworzyć wydajną wizualizację danych za pomocą Google Cloud i Google Maps Platform, należy wziąć pod uwagę kilka kwestii projektowych.
- Rozmiar danych źródłowych i częstotliwość ich aktualizacji.
- Jeśli dane źródłowe w formacie geojson mają mniej niż 5 MB lub są aktualizowane bardzo często (np. prognoza pogody na żywo), rozważ udostępnianie danych jako obiektu geojson po stronie klienta w aplikacji i renderowanie za pomocą warstwy deck.gl.
- Jeśli Twoje dane mają rozmiar większy niż 5 MB i są aktualizowane nie częściej niż raz na godzinę, rozważ użycie architektury interfejsu Datasets API opisanej w tym dokumencie.
- Zbiór danych obsługuje pliki o rozmiarze do 350 MB.
- Jeśli dane są większe niż 350 MB, przed przekazaniem ich do zbiorów danych zastanów się nad odcięciem lub uproszczeniem danych geometrycznych w pliku źródłowym (patrz Odcinanie danych poniżej).
- Schemat i format
- Upewnij się, że dane mają niepowtarzalny identyfikator dla każdej funkcji. Unikalny identyfikator umożliwia wybranie konkretnej cechy i nadanie jej stylu lub złączenie danych z cechą w celu wizualizacji, np. nadanie stylu wybranej funkcji w zdarzeniu „kliknięcie” użytkownika.
- Sformatuj dane jako CSV lub GeoJSON zgodnie ze specyfikacją interfejsu Datasets API, używając prawidłowych nazw kolumn, typów danych i typów obiektów GeoJSON.
- Aby ułatwić tworzenie zbiorów danych z BigQuery, utwórz w eksporcie CSV do SQL kolumnę o nazwie
wkt
. Zbiory danych obsługują importowanie geometrii z pliku CSV w formacie Well-Known Text (WKT) z kolumny o nazwiewkt
. - Sprawdź, czy dane mają prawidłową geometrię i typy danych. Na przykład dane GeoJSON muszą być w układzie współrzędnych WGS84, kolejności nawiasów geometrycznych itp.
- Użyj narzędzia takiego jak geojson-validate, aby sprawdzić, czy wszystkie geometrie w pliku źródłowym są poprawne, lub narzędzia ogr2ogr, aby przekształcić plik źródłowy między formatami lub systemami współrzędnych.
- Oczyszczanie danych
- Zminimalizuj liczbę właściwości cech. W czasie wykonywania możesz złączać z funkcją dodatkowe właściwości na podstawie unikalnego klucza identyfikatora (przykład).
- W miarę możliwości używaj typów danych liczb całkowitych w przypadku obiektów właściwości, aby zminimalizować ilość miejsca na dane w płytkach i utrzymać ich wydajność podczas wczytywania przez aplikację klienta przez HTTPS.
- Uprość lub zgrupowań bardzo złożonych geometrii obiektów. Zastanów się nad użyciem funkcji BigQuery, takich jak ST_Simplify, w przypadku złożonych geometrii wielokątów, aby zmniejszyć rozmiar pliku źródłowego i poprawić wydajność mapy.
- Płytka
- Interfejs Maps Datasets API tworzy kafelki mapy na podstawie pliku danych źródłowych, aby można było go używać z pakietem SDK Map Google na potrzeby witryny lub aplikacji mobilnej.
- Płytki mapy to system indeksowania oparty na powiększaniu, który zapewnia bardziej wydajne sposoby wczytywania danych do aplikacji wizualnej.
- Fragmenty mapy mogą pomijać gęste lub złożone elementy na niższych poziomach powiększenia. Gdy użytkownik oddali widok do stanu lub kraju (np. z5-z12), może on wyglądać inaczej niż w przypadku zbliżenia widoku do miasta lub dzielnicy (np. z13-z18).
Przykład: koleje w Londynie
W tym przykładzie zastosujemy architekturę referencyjną, aby utworzyć aplikację internetową z GCP i Mapami Google, która wizualizuje wszystkie linie kolejowe w Londynie na podstawie danych z Open Street Map (OSM).
Wymagania wstępne
- dostęp do piaskownicy BigQuery i konsoli Cloud;
- Upewnij się, że masz skonfigurowany projekt i konto rozliczeniowe GCP.
Krok 1. Wysyłanie zapytań dotyczących danych w BigQuery
Otwórz publiczne zbiory danych BigQuery. Zbiór danych „bigquery-public-data” i tabela geo_openstreetmap.planet_features
zawierają dane Open Street Map (OSM) obejmujące cały świat, w tym wszystkie możliwe funkcje. Poznaj wszystkie funkcje dostępne do wyszukiwania w Wiki OSM, w tym amenity
, road
i landuse
.
Użyj Cloud Shell lub konsoli Cloud BigQuery(https://console.cloud.google.com), aby wysłać zapytanie do tabeli za pomocą języka SQL. Fragment kodu poniżej używa polecenia bq query do wysłania zapytania do wszystkich linii kolejowych, które zostały odfiltrowane do tylko Londynu za pomocą prostokąta ograniczającego i funkcji ST_Intersects().
Aby wykonać to zapytanie w Cloud Shell, uruchom ten fragment kodu, aktualizując identyfikator projektu, zbiór danych i nazwę tabeli w swoim środowisku.
bq query --use_legacy_sql=false \
--destination_table PROJECTID:DATASET.TABLENAME \
--replace \
'SELECT
osm_id,
feature_type,
(SELECT value
FROM unnest(all_tags)
WHERE KEY = "name") AS name,
(SELECT value
FROM unnest(all_tags)
WHERE KEY = "railway") AS railway,
geometry as wkt
FROM bigquery-public-data.geo_openstreetmap.planet_features
WHERE ("railway") IN (SELECT key FROM unnest(all_tags))
AND ST_Intersects(
geometry,
ST_MakePolygon(ST_MakeLine(
[ST_GeogPoint(-0.549370, 51.725346),
ST_GeogPoint(-0.549370, 51.2529407),
ST_GeogPoint(0.3110581, 51.25294),
ST_GeogPoint(0.3110581, 51.725346),
ST_GeogPoint(-0.549370, 51.725346)]
))
)'
Zapytanie zwraca:
- niepowtarzalny identyfikator każdej funkcji.
osm_id
feature_type
np.punkty, linie itp.name
funkcji, np.Paddington Station
- Typ
railway
, np.główny, turystyka, wojsko itp. wkt
obiektu – geometria punktowa, liniowa lub wielokątna w formacie WKT. WKT to standardowy format danych zwracany przez kolumny Geografia w BigQuery w zapytaniu.
Uwaga: aby przed utworzeniem zbioru danych wizualnie sprawdzić wyniki zapytania, możesz szybko zwizualizować dane w panelu BigQuery za pomocą Looker Studio.
Aby wyeksportować tabelę do pliku CSV w zasośniku Google Cloud Storage, użyj w Cloud Shell polecenia bq extract:
bq extract \
--destination_format "CSV" \
--field_delimiter "," \
--print_header=true \
PROJECTID:DATASET.TABLENAME \
gs://BUCKET/FILENAME.csv
Uwaga: aby regularnie aktualizować dane, możesz zautomatyzować każdy krok za pomocą usługi Cloud Scheduler.
Krok 2. Utwórz zbiór danych na podstawie pliku CSV
Następnie utwórz zbiór danych Google Maps Platform na podstawie danych wyjściowych zapytania w Google Cloud Storage (GCS). Za pomocą interfejsu Datasets API możesz utworzyć zbiór danych, a potem przesłać do niego dane z pliku hostowanego w Cloud Storage.
Aby rozpocząć, włącz interfejs Maps Datasets API w projekcie GCP i zapoznaj się z dokumentacją API. Do wywoływania interfejsu Datasets API z logiki w backendzie aplikacji służą biblioteki klienta Python i Node.js. Dodatkowo w konsoli Cloud można ręcznie tworzyć zbiory danych za pomocą interfejsu graficznego Zbiory danych.
Po przesłaniu zbioru danych możesz wyświetlić jego podgląd w interfejsie zbiorów danych.
Krok 4. Połącz zbiór danych z identyfikatorem mapy
Po utworzeniu zbioru danych możesz utworzyć identyfikator mapy z powiązanym stylem mapy. W edytorze stylu mapy możesz powiązać identyfikator mapy i styl ze zbiorem danych. Tutaj możesz też zastosować definiowanie stylów map w Google Cloud, aby dostosować wygląd i działanie mapy.
Krok 5. Utwórz wizualizację mapy aplikacji klienta
Na koniec możesz dodać zbiór danych do aplikacji do wizualizacji danych po stronie klienta za pomocą Map JS API. Inicjuj obiekt mapy, używając identyfikatora mapy powiązanego ze zbiorem danych z poprzedniego kroku. Następnie ustaw styl i interaktywność warstwy zbioru danych. Więcej informacji znajdziesz w pełnym przewodniku po stylizacji opartej na danych za pomocą zbiorów danych.
Za pomocą interfejsu Maps JS API możesz dostosowywać styl, dodawać moduły obsługi zdarzeń, aby zmieniać styl dynamicznie, i wykonywać inne czynności. Przykłady znajdziesz w dokumentacji. Poniżej zdefiniujemy funkcję setStyle, która w tym przykładzie utworzy styl punktów i linii na podstawie atrybutu „feature_type”.
function setStyle(params) {
const map.getDatasetFeatureLayer("your-dataset-id");
const datasetFeature = params.feature;
const type = datasetFeature.datasetAttributes["feature_type"];
if (type == "lines") {
return {
fillColor: "blue",
strokeColor: "blue",
fillOpacity: 0.5,
strokeWeight: 1,
}
} else if (type == "points") {
return {
fillColor: "black",
strokeColor: "black",
strokeOpacity: 0.5,
pointRadius: 2,
fillOpacity: 0.5,
strokeWeight: 1,
}
}
}
Uwaga: zawsze dodawaj do aplikacji mapowej informacje o źródle danych. Aby dodać informacje o źródle OSM, postępuj zgodnie z przykładem kodu informacji o źródle w dokumentacji, przestrzegając wytycznych OSM.
Po zainicjowaniu w ramach aplikacji internetowej na jednej stronie ten kod powoduje wyświetlenie tych danych mapy:
Teraz możesz rozszerzyć wizualizację mapy w funkcji setStyle(), dodając logikę do funkcji filtrowania, dodając stylizację na podstawie interakcji użytkownika i interagując się z resztą aplikacji.
Podsumowanie
W tym artykule omawiamy architekturę referencyjną i przykładową implementację dużej aplikacji do wizualizacji danych z użyciem Google Cloud i Google Maps Platform. Dzięki tej architekturze referencyjnej możesz tworzyć aplikacje do wizualizacji danych o lokalizacji na podstawie dowolnych danych w BigQuery w Google Cloud Platform, które działają sprawnie na dowolnym urządzeniu i korzystają z interfejsu API Zbiorów danych Google Maps.
Dalsze działania
Więcej informacji:
- Dokumentacja interfejsu API Mapy Google Platform Datasets
- Wyświetlanie danych w czasie rzeczywistym za pomocą stylów napędzanych danymi
- Wprowadzenie do analizy geoprzestrzennej w BigQuery
- Korzystanie z formatu GeoJSON w BigQuery do analizy geoprzestrzennej
Współtwórcy
Główni autorzy:
- Ryan Baumann, menedżer ds. inżynierii rozwiązań Google Maps Platform