gs://alphaearth_foundations קטגוריית GCS מכילה קובצי COG (Cloud Optimized GeoTIFF) שביחד מרכיבים את מערך הנתונים השנתי של Satellite Embedding של AlphaEarth Foundations. הוא מכיל את ההטמעות השנתיות לשנים 2017 עד 2024, כולל.
רישיון
הנתונים האלה מותרים לשימוש במסגרת רישיון CC-BY 4.0, ונדרש להוסיף את טקסט השיוך הבא: "מערך הנתונים של הטמעת נתוני לוויין של AlphaEarth Foundations נוצר על ידי Google ו-Google DeepMind".
הקטגוריה הזו מוגדרת כ'הגורם המבקש משלם', ולכן הורדת נתונים עלולה לגרור חיובים על תעבורת נתונים יוצאת וחיובים אחרים.
מבנה הספרייה
הקבצים מחולקים לספריות לפי שנה. כל ספרייה של שנה מחולקת ל-120 ספריות משנה, אחת לכל אזור UTM, והשמות שלהן משקפים את מספר האזור ואת חצי הכדור (N או S).
בכל ספרייה יש מספר קובצי COG. הקבצים האלה מכילים את כל נתוני הפיקסלים של אזור ה-UTM הזה.
מבנה הקובץ
כל קובץ הוא בגודל 8,192x8,192 פיקסלים, עם 64 ערוצים. הגודל של כל פיקסל, אחרי שמחילים את מיפוי הביטול של הכמות (ראו בהמשך), עבר נורמליזציה כך שאורך אוקלידי יהיה 1.
הקבצים מכילים שכבות סקירה כללית ברזולוציה של 4096x4096 פיקסלים, 2048x2048 פיקסלים וכן הלאה, עד לשכבת סקירה כללית ברמה העליונה ברזולוציה של 1x1. שכבות הסקירה הכללית האלה בנויות כך שכל פיקסל בסקירה הכללית הוא הממוצע של הפיקסלים ברזולוציה הגבוהה ביותר שמתחת לפיקסל הזה בסקירה הכללית, כאשר הגודל של הממוצע עבר נורמליזציה כך שהאורך שלו הוא 1.
הערוצים תואמים, לפי הסדר, לצירים A00 עד A63 של מערך הנתונים Satellite Embedding. גם ב-COGs מופיע השם הזה של הערוצים.
הערך של כל פיקסל בכל ערוץ הוא מספר שלם חתום של 8 ביט. בהמשך מוסבר איך הערכים האלה ממופים לערכים המקוריים (בטווח [-1, 1]) של ההטמעות.
הערך -128 מתאים לפיקסל מוסתר. אם הוא מופיע בערוץ אחד,
הוא יופיע בכל הערוצים. הערך הזה משתקף ב-COGs (כלומר, הערך NoData מוגדר כ--128).
השם של כל קובץ מכיל גם מידע מסוים. לדוגמה, נניח שיש קובץ בשם gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff.
כמו שמתואר למעלה, הקובץ הזה הוא חלק מהטמעת הנתונים השנתית של 2019, והוא נמצא באזור UTM 1S (אזור 1, חצי הכדור הדרומי). שם הקובץ הבסיסי, x8qqwcsisbgygl2ry-0000008192-0000000000, משמש לקישור הקובץ הזה לשם התמונה המקבילה של הטמעת לוויין ב-Earth Engine. בדוגמה הזו, הקובץ הזה תואם לחלק מהתמונה של Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. שני החלקים העשרוניים של שם הקובץ מציינים את המיקום של ערכי ה-COG ביחס לתמונה של Earth Engine, כהיסט ב-Y ואחריו היסט ב-X. במקרה הזה, המקור של הפיקסלים ב-COG נמצא במיקום (0, 8192) ביחס למקור של התמונה ב-Earth Engine.
הסיבה לכך היא שהיה צורך לחלק כל תמונה של Earth Engine (שהן בגודל 16384x16384 פיקסלים) כדי שקבצי ה-COG שיתקבלו לא יהיו גדולים מדי.
הסרת הכימות
כדי להמיר את הערך הגולמי עם סימן של 8 ביט (שיהיה בין -127 ל-127 כולל, כי -128 שמור כערך 'אין נתונים') בכל ערוץ של כל פיקסל לערך נקודה צפה שמוכן לניתוח (שיהיה בין -1 ל-1), המיפוי שצריך לבצע הוא
- לחלק ב-127.5
- ריבוע
- להכפיל בסימן של הערך המקורי
ב-NumPy, הביטוי הזה ייראה כך:
# values is a NumPy array of raw pixel values
de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)
ב-Earth Engine, הפעולה המקבילה תהיה
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
יצירת פירמידות עם דגימה חוזרת
אם אתם מתכוונים ליצור גרסאות משלכם עם דגימה נמוכה יותר או תצוגות כלליות חיצוניות משכבת הרזולוציה הבסיסית של קובצי ה-COG האלה (לדוגמה, אחרי יצירת פסיפס של כמה קבצים), אתם צריכים לפעול לפי ההליך שמופיע בהמשך. שימוש בטכניקות פירמידה רגילות של רסטר (למשל, שימוש ב-gdaladdo עם -r average על ערכי המספרים השלמים הגולמיים) לא יניב תוצאות נכונות.
- ביטול קוונטיזציה: המרת המספרים השלמים הגולמיים בני 8 הביטים למספרים ממשיים באמצעות השיטה שמתוארת למעלה.
- חיבור וקטורים: חיבור של הווקטורים אחרי ביטול הכימות, לפי רכיבים.
- נרמול: מחשבים את הנורמה האוקלידית של וקטור הסכום שמתקבל ומחלקים אותה בנורמה כדי לנרמל מחדש לאורך יחידה.
import numpy as np
# Assuming 'raw_values' is a NumPy array of shape (N, 64)
# containing the raw signed 8-bit integers from N pixels.
# N = 4 for a 2x2 aggregation, for example.
# 1. De-quantize
de_quantized_values = ((raw_values / 127.5) ** 2) * np.sign(raw_values)
# 2. Sum the de-quantized vectors
sum_vec = np.sum(de_quantized_values, axis=0) # Shape (64,)
# 3. Normalize the sum vector
norm = np.linalg.norm(sum_vec)
# Add epsilon to prevent division by zero
pyramided_vec = sum_vec / (norm + 1e-9)
# 'pyramided_vec' is the correctly downsampled 64-dimensional unit vector.
שכבות הסקירה הכללית בקובצי ה-COG נוצרו באמצעות התהליך הזה. אם הן מתאימות לצרכים שלכם, אתם יכולים פשוט להשתמש בהן ולא לבצע חישובים.
מניפסט ואינדקס
רשימת הקבצים במערך הנתונים הזה מופיעה בכתובת
gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.
מכיוון שאי אפשר לדעת משמות הקבצים איזה אזור בעולם הם מכסים, סיפקנו גם אינדקס בשלושה פורמטים (GeoParquet, GeoPackage ו-CSV) בקבצים gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg ו-gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv. האינדקס הזה מכיל רשומה אחת לכל קובץ במערך הנתונים. המידע שמופיע
לגבי כל קובץ הוא
- הגיאומטריה של הקובץ כ-WGS84 (כלומר, פוליגון EPSG:4326). בטופס ה-CSV, הערך הזה מופיע בעמודה
WKT. בהמשך מפורט אופן החישוב של הגיאומטריה הזו. -
crs: מערכת ייחוס הקואורדינטות של אזור ה-UTM שאליו שייך האימג' הזה, כקוד EPSG, כמוEPSG:32610. -
year: השנה שמופיעה בתמונה. -
utm_zone: אזור UTM של התמונה, כמו10N. -
utm_west,utm_south,utm_east,utm_north: הגבולות של מערך הפיקסלים הגולמיים במערכת UTM. הערך הזה לא משקף עיבוד גיאומטרי, והוא כולל את כל הפיקסלים, גם אם הם תקפים וגם אם לא. -
wgs84_west,wgs84_south,wgs84_east,wgs84_north: קווי האורך וקווי הרוחב המינימליים והמקסימליים של גיאומטריית WGS84.
עיבוד גיאומטרי
מערך הפיקסלים נמצא באופן טבעי באזור UTM מסוים, ולכן באזור UTM הזה תיבת התוחמת של מערך הפיקסלים היא מלבן פשוט. תיבת התוחמת הזו מומרת למצולע ב-WGS84. הפוליגון הזה כולל מספר נקודות נוספות כדי שהקצוות שלו יתאימו באופן מדויק לקווים המעוקלים ב-WGS84 שהקווים הישרים ב-UTM מומרים אליהם. הפוליגון הזה לא מתייחס לתוקף או לחוסר התוקף של פיקסלים בתמונה, אלא רק לגבולות של מערך הפיקסלים של התמונה.
לאחר מכן, הפוליגון נחתך לפי קווי האורך המינימליים והמקסימליים של אזור ה-UTM של התמונה. בפועל, יכול להיות שהמערכת לא תכלול כמה פיקסלים תקינים שחורגים מהקצה של אזור ה-UTM. השמטה של הפיקסלים האלה מהאינדקס לא אמורה לגרום לבעיות: חלק מהתמונה מאזור ה-UTM הסמוך אמור לכסות את האזור הזה.
שימו לב: חיתוך לקו האורך המינימלי או המקסימלי של אזור UTM פירושו שאין מצולע שחוצה את קו התאריך הבינלאומי, ולכן העיבוד של הקובץ הזה אמור להיות פשוט יותר.