המחשה ויזואלית של הנתונים באמצעות BigQuery ו-Datasets API

במסמך הזה מפורטת ארכיטקטורת עזר ודוגמה ליצירת תצוגות חזותיות של נתוני מפות עם נתוני מיקום ב-Google Cloud Platform BigQuery וב-Google Maps Platform Datasets API. למשל, ניתוח נתונים של רשויות מקומיות פתוחות, יצירת מפת כיסוי של מערכות טלקומוניקציה או הצגה חזותית של נתונים על תנועת כלל הרכבים בנייד.

תצוגות חזותיות של נתוני מפות הן כלי יעיל לעורר עניין בקרב המשתמשים ולקבל תובנות מרחביות בנתוני המיקום. נתוני מיקום הם נתונים עם תכונות של נקודות, קו או פוליגונים. לדוגמה, מפות מזג אוויר עוזרות לצרכנים להבין ולתכנן נסיעות ולהתכונן לסופות; מפות של בינה עסקית (BI) עוזרות למשתמשים לקבל תובנות מניתוח הנתונים שלהם, ומפות תקשורת עוזרות למשתמשים להבין את הספקים שלהם הכיסוי והאיכות של כל אזור שירות.

עם זאת, מפתחי אפליקציות מתקשים ליצור תצוגות חזותיות גדולות של נתוני המפה שמניבות ביצועים טובים ומספקות חוויית משתמש מעולה. המערכת צריכה לטעון נתונים גדולים בצד לקוח הזיכרון, ולכן זמני הטעינה הראשונים של המפה איטיים. הרכיבים החזותיים צריכים להיות טובים בכל המכשירים, כולל טלפונים ניידים פשוטים יותר עם מגבלות זיכרון ו-GPU. לבסוף, מפתחים צריכים לבחור ספרייה גדולה לעיבוד נתונים – ניידת, מהימנה ועם ביצועים טובים ועם כמות גדולה של נתונים.

ארכיטקטורת עזר

כדי לפתח אפליקציות עם תצוגות חזותיות גדולות של הנתונים נדרשים שני רכיבים עיקריים.

1. הקצה העורפי של הלקוח - כל נתוני האפליקציות בקצה העורפי כמו עיבוד ואחסון.
2. לקוח לקוח – ממשק המשתמש באפליקציה שלכם עם רכיב להמחשה של מפה.

בהמשך מופיע תרשים מערכת שמראה את האינטראקציה בין שני הרכיבים האלו עם המשתמש באפליקציה, עם Google Cloud והפלטפורמה של מפות Google, במטרה ליצור אפליקציה להמחשת נתונים גדולה.

אני רוצה לנסות:נכנסים למסוף Google Cloud ומפעילים את Maps Datasets API.

שיקולים לגבי התכנון

יש כמה שיקולי עיצוב שצריך להביא בחשבון כדי ליצור המחשת נתונים יעילה באמצעות Google Cloud והפלטפורמה של מפות Google.

1. גודל נתוני המקור ותדירות העדכון.
   1. אם נתוני המקור בפורמט Geojson הוא <5mb או מתעדכן לעתים קרובות מאוד, למשל: תחזית מכ"ם מזג אוויר פעילה, כדאי להציג נתונים כצד הלקוח של אובייקט geojson באפליקציה ולעבד באמצעות שכבת deck.gl.
   2. אם הנתונים שלכם הם בנפח של יותר מ-5MB והעדכונים שלהם לא מתבצעים מהר יותר מפעם בשעה, כדאי להביא בחשבון את ארכיטקטורת ה-Datasets API במסמך הזה.
      1. מערכי נתונים תומכים בקבצים בגודל של עד 350MB.
      2. אם הנתונים גדולים מ-350MB, כדאי לחתוך או לפשט את הנתונים בגיאומטריה בקובץ המקור לפני ההעברה למערכי נתונים (ראו 'הרצת נתונים' בהמשך).
2. סכימה ו- פורמט
   1. מוודאים שלנתונים יש נכס מזהה ייחודי גלובלי לכל תכונה. מזהה ייחודי מאפשר לכם לבחור תכונה ספציפית ולעצב אותה, או לצרף נתונים לתכונה כדי להציג אותה באופן חזותי. למשל, עיצוב של תכונה נבחרת באירוע המשתמש 'קליק'.
   2. פורמט הנתונים צריך להיות CSV או GeoJSON בהתאם למפרט של Datasets API עם שמות עמודות תקינים, סוגי נתונים וסוגי אובייקטים של GeoJSON.
   3. כדי ליצור בקלות מערכי נתונים מ-BigQuery, צריך ליצור עמודה בשם wkt בייצוא של קובץ ה-CSV של SQL. מערכי נתונים תומכים בייבוא גיאומטריה מקובץ CSV בפורמט טקסט ידוע (WKT) מעמודה בשם wkt.
   4. צריך לבדוק שהנתונים גיאומטריה וסוגי נתונים תקינים. לדוגמה, GeoJSON חייב להיות במערכת הקואורדינטות WGS84, סדר ליפוף גיאומטרי וכו'.
   5. משתמשים בכלי כמו geojson-validate כדי לוודא שכל הפרטים הגיאומטריים בקובץ המקור תקינים, או כדי ogr2ogr לבצע טרנספורמציה של קובץ מקור בין פורמטים או מערכות קואורדינטות.
3. קיצוץ נתונים
   1. צמצום מספר המאפיינים של תכונות. אפשר לצרף נכסים נוספים לתכונה בזמן ריצה באמצעות מפתח מזהה ייחודי (דוגמה).
   2. אם אפשר, כדאי להשתמש בסוגי נתונים של מספרים שלמים לאובייקטים של מאפיינים כדי לצמצם את נפח האחסון של כרטיסי מידע, וכך לשמור על רמת ביצועים טובה של טעינה ב-HTTPS באפליקציית לקוח.
   3. לפשט ו/או לצבור גיאומטריה של תכונות מורכבות מאוד. כדי להקטין את גודל קובץ המקור ולשפר את ביצועי המפה, כדאי להשתמש בפונקציות של BigQuery כמו ST_Simplify עם צורות גיאומטריות מורכבות של פוליגונים.
4. משבצות
   1. ממשק ה-API של קבוצות הנתונים של מפות Google יוצר קטעי מפה מקובץ נתוני המקור לשימוש ב-SDK של מפות Google לנייד או לאינטרנט.
   2. משבצות מפה הן מערכת הוספה לאינדקס המבוססת על זום, שמספקת דרכים יעילות יותר לטעינת נתונים לאפליקציה ויזואלית.
   3. משבצות מפה עשויות להתבטל בחלקים צפופים או מורכבים ברמות זום נמוכות יותר. כאשר משתמש מקטין את התצוגה למדינה או למדינה (למשל z5-z12) עשוי להיראות שונה מאשר כשמתקרבים לעיר או לשכונה (לדוגמה, z13-z18).

דוגמה - רכבות בלונדון

בדוגמה הזו נחיל את ארכיטקטורת העזר כדי ליצור אפליקציית אינטרנט עם GCP ומפות Google, הממחישה את כל מסילות הרכבת בלונדון על סמך נתוני Open Street Map (OSM).

דרישות מוקדמות

1. גישה ל-BigQuery Sandbox ולמסוף Cloud
2. חשוב לוודא שיש לכם פרויקט GCP וחשבון לחיוב.

שלב 1 – שליחת שאילתות על הנתונים ב-BigQuery

עוברים אל BigQuery Public Datasets (מערכי נתונים ציבוריים של BigQuery). מערך הנתונים 'bigquery-public-data' והטבלה geo_openstreetmap.planet_features מכילות את כל הנתונים של Open Street Map (OSM) מרחבי העולם, כולל כל התכונות האפשריות. מידע על כל התכונות הזמינות לשאילתות בוויקי של OSM, כולל amenity, road ו-landuse.

משתמשים ב-Cloud Shell או ב-BigQuery Cloud Console(https://console.cloud.google.com) כדי לשלוח שאילתות על הטבלה באמצעות SQL. קטע הקוד שבהמשך משתמש בפקודה bq query כדי לשלוח שאילתה על כל המסילות המסוננות ללונדון בלבד, באמצעות תיבה תוחמת (bounding box) והפונקציה ST_Intersects().

כדי לבצע את השאילתה הזו מ-Cloud Shell, מריצים את קטע הקוד הבא ומעדכנים את מזהה הפרויקט, מערך הנתונים ושם הטבלה של הסביבה.

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)]
    ))
   )' 

השאילתה מחזירה:

1. מזהה ייחודי לכל תכונה osm_id
2. feature_type, למשל נקודות, קווים וכו'
3. name של התכונה, למשל: Paddington Station
4. הסוג railway, למשל עיקרי, תיירות, צבא וכו'
5. ה-wkt של הישות – גיאומטריה של נקודות, קו או פוליגונים בפורמט WKT. WKT הוא פורמט הנתונים הסטנדרטי של BigQuery Geography עמודות שמוחזרות בשאילתה.

הערה: כדי לאמת את תוצאות השאילתה באופן חזותי לפני שיוצרים מערך נתונים, אפשר להציג במהירות את הנתונים במרכז בקרה של BigQuery באמצעות Looker Studio.

כדי לייצא את הטבלה לקובץ CSV בקטגוריה של Google Cloud Storage, משתמשים בפקודה חילוץ bq ב-Cloud Shell:

bq extract \
--destination_format "CSV" \
--field_delimiter "," \
--print_header=true \
PROJECTID:DATASET.TABLENAME \
gs://BUCKET/FILENAME.csv

הערה: אפשר להפוך כל שלב לאוטומטי באמצעות Cloud Scheduler כדי לעדכן את הנתונים באופן קבוע.

שלב 2 – יוצרים מערך נתונים מקובץ ה-CSV

בשלב הבא יוצרים מערך נתונים בפלטפורמה של מפות Google מפלט השאילתה ב-Google Cloud Storage (GCS). באמצעות Datasets API אפשר ליצור מערך נתונים ואז להעלות נתונים למערך הנתונים מקובץ שמתארח ב-GCS.

כדי להתחיל בעבודה, עליך להפעיל את Maps Datasets API בפרויקט GCP ולעיין במסמכי ה-API. קיימות ספריות לקוח של Python ו-Node.js כדי לשלוח קריאה ל-Datasets API מהלוגיקה בקצה העורפי של האפליקציה. בנוסף, יש ממשק משתמש גרפי (GUI) של מערכי נתונים ליצירה ידנית של מערכי נתונים במסוף Cloud.

אחרי שההעלאה של מערך הנתונים תסתיים, תוכלו לראות תצוגה מקדימה של מערך הנתונים בממשק ה-GUI של מערכי הנתונים.

שלב 4 – שיוך מערך הנתונים למזהה מפה

אחרי שיוצרים את מערך הנתונים, אפשר ליצור מזהה מפה עם סגנון מפה משויך. בעורך סגנון המפה אפשר לשייך מזהה וסגנון למערך הנתונים. כאן אפשר גם להחיל עיצוב מפה מבוסס-ענן כדי להתאים אישית את המראה והסגנון של המפה.

שלב 5 – יוצרים תצוגה חזותית של מפת אפליקציית הלקוח

לבסוף, אפשר להוסיף את מערך הנתונים לאפליקציה להמחשת נתונים בצד הלקוח באמצעות Maps JS API. מאתחלים את אובייקט המפה באמצעות ה-mapID שמשויך למערך הנתונים מהשלב הקודם. לאחר מכן מגדירים את הסגנון והאינטראקטיביות של שכבת מערך הנתונים. לפרטים נוספים, אפשר לעיין במדריך המלא לסגנון מבוסס-נתונים באמצעות מערכי נתונים.

אפשר להתאים אישית את הסגנון, להוסיף גורמים מטפלים באירועים כדי לשנות את הסגנון באופן דינמי ועוד באמצעות Maps JS API. במסמכים האלה תוכלו לראות דוגמאות. בהמשך נגדיר את הפונקציה setStyle כדי ליצור את סגנון התכונות של הנקודה והקו עבור הדוגמה הזו, על סמך המאפיין "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,
           }
     }
}

הערה: הקפידו להוסיף תמיד את פרטי הייחוס של מערך הנתונים לאפליקציית המפות. כדי להוסיף פרטי ייחוס של OSM, פועלים לפי הדוגמה של קוד השיוך שבמסמכים בהתאם להנחיות של מערכת ההפעלה OSM.

הקוד הזה שלמעלה כשמופעל באפליקציית אינטרנט בדף יחיד מניב את הרכיבים החזותיים הבאים של נתוני המפה:

מכאן תוכלו להרחיב את הצגת המפה בפונקציה setStyle() על ידי הוספת לוגיקה לתכונות סינון, הוספת עיצוב על סמך האינטראקציה של המשתמש, ויצירת אינטראקציה עם שאר האפליקציה.

סיכום

במאמר הזה עסקנו בארכיטקטורת עזר ובהטמעה לדוגמה של אפליקציה גדולה להמחשה חזותית של נתונים, באמצעות Google Cloud והפלטפורמה של מפות Google. באמצעות ארכיטקטורת העזר, ניתן ליצור אפליקציות להדמיה של נתוני מיקום מכל הנתונים ב-BigQuery שמניבים ביצועים טובים בכל מכשיר באמצעות ממשק ה-API של מערכי הנתונים של מפות Google.

הפעולות הבאות

קריאה נוספת:

• מאמרי העזרה של Google Maps Platform Datasets API
• הצגת נתונים בזמן אמת באמצעות סגנונות של אחסון נתונים
• מבוא לניתוח גיאו-מרחבי ב-BigQuery
• שימוש ב-GeoJSON ב-BigQuery לניתוח גיאו-מרחבי

תורמים

מחברים ראשיים:

• ריאן באומן, מנהל הנדסת פתרונות של הפלטפורמה של מפות Google