לפני שמתחילים

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

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

כשיוצרים מערך נתונים:

• השמות המוצגים חייבים להיות ייחודיים בפרויקט שלכם ב-Google Cloud.
• השמות המוצגים חייבים להיות קטנים מ-64 בייטים (מכיוון שהתווים האלה מיוצגים ב-UTF-8, בשפות מסוימות, כל תו יכול להיות מיוצג על ידי מספר בייטים).
• התיאורים חייבים להיות קטנים מ-1,000 בייטים.

כשמעלים נתונים:

• סוגי הקבצים הנתמכים הם CSV , GeoJSON ו-KML.
• גודל הקובץ המקסימלי הנתמך הוא 500MB.
• השמות של עמודות המאפיינים לא יכולים להתחיל במחרוזת "?_".
• אין תמיכה בגיאומטריה תלת ממדית. כולל האות Z סיומת בפורמט WKT, וקואורדינטת הגובה בפורמט GeoJSON.

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

הערה: משבצות מפה שנוצרו עם נתונים שהועלו באמצעות במפות Google Datasets API עשוי לרדת או לפשט נתונים צפופים או מורכבים ברמות זום נמוכות. לדוגמה, כאשר משתמש מקטין את התצוגה למדינה או למדינה (למשל, רמת זום 5-12), הנתונים במשבצות עשויים להיראות שונה ממרחק התצוגה של עיר או שכונה (לדוגמה, רמת זום 13-18). זה קורה כדי לשמור על אריחים צרים ורמת ביצועים טובה באמצעות המשבצות עם הכלי לעיבוד מפות.

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

שיטות מומלצות להכנת נתונים

אם נתוני המקור מורכבים או גדולים, כמו נקודות צפופות, מחרוזות קווים ארוכים או פוליגונים (בדרך כלל קובצי מקור בגודל של יותר מ-50MB נכללים בקטגוריה הזו), כדאי לפשט את הנתונים. לפני ההעלאה כדי להשיג את הביצועים הטובים ביותר במפה חזותית.

ריכזנו כאן כמה שיטות מומלצות להכנת הנתונים:

1. מזעור המאפיינים של התכונות. שמור רק את מאפייני התכונות הדרושים לסגנון לדוגמה, 'id'. ו-'category'. אפשר לצרף נכסים נוספים לתכונה מסוימת בלקוח באמצעות סגנונות מבוססי-נתונים במפתח מזהה ייחודי. לדוגמה, ראה הצגת הנתונים בזמן אמת בעזרת סגנון מבוסס-נתונים.
2. מומלץ להשתמש בסוגי נתונים פשוטים בשביל אובייקטים של מאפיינים, כמו מספרים שלמים, כדי להקטין את גודל המשבצת ולשפר את ביצועי המפה.
3. לפני העלאת קובץ, הגדירו צורות גיאומטריות מורכבות. אפשר לעשות זאת כלי גיאו-מרחבי לבחירתכם, כמו קוד פתוח. בכלי Mapshaper.org, או ב-BigQuery באמצעות ST_Simplify של פוליגונים מורכבים של פוליגונים.
4. לאסוף נקודות צפופות מאוד לפני העלאת קובץ. אפשר לעשות זאת כלי גיאו-מרחבי לבחירתכם, כמו קוד פתוח. פונקציות של אשכול turf.js או ב-BigQuery באמצעות ST_CLUSTERDBSCAN בפורמט גיאומטרי של נקודות צפופות.

הנחיות נוספות לגבי שיטות מומלצות לגבי מערכי נתונים זמינות המחשה חזותית של נתונים באמצעות מערכי נתונים ו-BigQuery.

דרישות לגבי GeoJSON

Maps Datasets API תומך המפרט של GeoJSON. ב-Maps Datasets API יש גם תמיכה בקובצי GeoJSON שמכילים כל אחד מסוגי האובייקטים הבאים:

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

ממשק ה-API של מפות Google Datasets לא תומך בקובצי GeoJSON שמכילים נתונים במערכת ייחוס קואורדינטות (CRS) מלבד WGS84.

למידע נוסף על GeoJSON, אפשר לעיין במאמר תאימות לתקן RFC 7946.

דרישות KML

ממשק ה-API של מפות Google כולל את הדרישות הבאות:

• כל כתובות ה-URL חייבות להיות מקומיות (או יחסיות) לקובץ עצמו.
• תמיכה גיאומטרית של נקודות, קווים ופוליגונים.
• כל מאפייני הנתונים נחשבים למחרוזות.

תכונות ה-KML הבאות לא נתמכות:

• סמלים או <styleUrl> שמוגדרים מחוץ לקובץ.
• קישורי רשת, כמו <NetworkLink>
• שכבות-על של קרקע, כמו <GroundOverlay>
• צורות גיאומטריות תלת-ממדיות או כל תג שקשור לגובה כמו <altitudeMode>
• מפרטי מצלמה כמו <LookAt>
• סגנונות שהוגדרו בתוך קובץ ה-KML.

דרישות לגבי CSV

לקובצי CSV, שמות העמודות הנתמכים מפורטים למטה לפי סדר עדיפות:

• latitude, longitude
• lat, long
• x, y
• wkt (טקסט ידוע)
• address, city, state, zip
• address
• עמודה אחת שמכילה את כל פרטי הכתובת, כמו 1600 Amphitheatre Parkway Mountain View, CA 94043

לדוגמה, הקובץ מכיל עמודות בשם x, y ו-wkt. האפליקציות x ו-y מקבלות עדיפות גבוהה יותר, כפי שנקבע לפי הסדר של שמות העמודות הנתמכים ברשימה שלמעלה, הערכים בעמודות x ו-y נעשה שימוש והמערכת מתעלמת מהעמודה wkt.

כמו כן:

• כל שמות של עמודות צריכים להשתייך לעמודה אחת. כלומר, לא יכולה להיות עמודה בשם xy שמכיל נתונים של קואורדינטות x ו-y. נקודות ה-x ו-y חייבות להיות עמודות נפרדות.
• שמות העמודות הם לא תלויי-רישיות.
• הסדר של שמות העמודות לא משנה. לדוגמה, אם קובץ ה-CSV מכיל העמודות lat ו-long יכולות להופיע בכל סדר שתרצו.

טיפול בשגיאות בהעלאת נתונים

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

שגיאות GeoJSON

דוגמאות לשגיאות נפוצות ב-GeoJSON:

• השדה type חסר, או שהשדה type אינו מחרוזת. הועלו קובץ הנתונים GeoJSON חייב להכיל שדה מחרוזת בשם type כחלק מכל שדה הגדרת אובייקט Feature והגדרת אובייקט גיאומטרי.

שגיאות KML

דוגמאות לכמה שגיאות KML נפוצות:

• קובץ הנתונים לא יכול להכיל אף אחת מתכונות ה-KML הלא נתמכות המפורטות למעלה, אחרת ייבוא הנתונים עלול להיכשל.

שגיאות CSV

דוגמאות לכמה שגיאות CSV נפוצות:

• בחלק מהשורות חסרים ערכים של עמודה בגיאומטריה. כל השורות בקובץ CSV חייבות להכיל שאינם ריקים לעמודות הגיאומטריה. עמודות הגיאומטריה כוללות:
  • latitude, longitude
  • lat, long
  • x, y
  • wkt
  • address, city, state, zip
  • address
  • עמודה אחת שמכילה את כל פרטי הכתובת, כמו 1600 Amphitheatre Parkway Mountain View, CA 94043
  הערה: לרוב מתוארת שגיאה זו על ידי הודעה "לא ניתן להמיר את ' עד כפול" או "לא ניתן לנתח את הקלט למיקום גיאוגרפי.: מיקום גיאוגרפי חסר ערך".
• אם x ו-y הן עמודות גיאומטריות, צריך לוודא שהיחידות קו אורך וקו רוחב. חלק ממערכי הנתונים הציבוריים משתמשים במערכות קואורדינטות שונות מתחת לכותרות x וגם y אם תשתמשו ביחידות הלא נכונות, יכול להיות שמערך הנתונים יייבא בהצלחה, אבל הנתונים שעברו רינדור עשויים להציג את הנקודות במערך הנתונים במיקומים לא צפויים.