Google Earth Engine מאפשר לכם לעבוד עם נתוני רסטר שמאוחסנים במאגרי נתונים Google Cloud Storage (GCS) משלכם. באמצעות Cloud Optimized GeoTIFFs (COGs), אתם יכולים לגשת לנתונים ולנתח אותם ישירות ב-Earth Engine בלי להטמיע את הפיקסלים בחנות הנכסים של Earth Engine.
הגישה הזו, שמתמקדת בענן, מציעה כמה יתרונות, במיוחד כשמנהלים מערכי נתונים גדולים או כשמשלבים את Earth Engine בתהליכי עבודה רחבים יותר ב-Google Cloud או בכלים ובפלטפורמות חיצוניים.
למה כדאי להשתמש ב-Cloud Storage וב-COG?
- גמישות ויכולת פעולה הדדית: הנתונים נשמרים בקטגוריות סטנדרטיות של Cloud Storage, כך שכלים ושירותים אחרים יכולים לגשת אליהם. לא משנה אם אתם מעלים את הנתונים ישירות או מייצאים אותם מ-Earth Engine, Cloud Storage משמש כמקור האמת היחיד (SSOT) גם ל-Earth Engine וגם לתהליכי עבודה חיצוניים.
- שליטה בנתונים ויציאה: אחסון נתונים ב-Cloud Storage מספק יכולות ניהול סטנדרטיות של אחסון אובייקטים. כך תוכלו להוריד, להעביר או לשתף את הנתונים שלכם באמצעות תכונות של Cloud Storage כמו Requester Pays או קטגוריות ציבוריות, ולנהל את הגישה באמצעות Cloud IAM רגיל.
- הרחבה גמישה: הימנעות ממגבלות האחסון של Earth Engine. ב-Cloud Storage יש נפח אחסון כמעט בלתי מוגבל בשירות עצמי, שאפשר להגדיל עד לפטה-בייטים.
- אין המתנה להטמעה: רישום של COG מסתיים במהירות כי Earth Engine קורא רק את המטא-נתונים (כמו היטל ומידות) מכותרת הקובץ לצורך הוספה לאינדקס ואימות. נתוני הפיקסלים עצמם נשארים ב-Cloud Storage ונקראים על פי דרישה במהלך החישוב, כך שאין צורך במשימת הטמעה נפרדת.
תהליכי עבודה של COG ב-Earth Engine
Earth Engine תומך בתהליכי עבודה דו-כיווניים עם קובצי COG ב-Cloud Storage: אפשר לקרוא קובצי COG ישירות מ-GCS ל-Earth Engine, ולכתוב תוצאות חישוב מ-Earth Engine ישירות ל-GCS כקובצי COG.
קריאת קובצי COG מ-Cloud Storage
כדי להוסיף קובצי COG שמתארחים ב-GCS ל-Earth Engine, יש שתי אפשרויות:
טעינה ישירה (
ee.Image.loadGeoTIFF): טעינה של תמונה אחת ישירות באמצעות ה-URI שלה ב-GCS. האפשרות הזו מתאימה במיוחד לבדיקות מהירות, לניתוח אד-הוק או לנתונים זמניים:JavaScript
var image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif');Python
image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif')דוגמאות פתורות מופיעות במאמר תמונות מקובצי GeoTIFF בענן.
נכסים רשומים: אפשר לרשום אחד או יותר קובצי COG כנכס ב-Earth Engine באמצעות מניפסט העלאה (ראו את מדריך הרישום של COG). זהו הנתיב המומלץ לתהליכי עבודה בסביבת הייצור, במיוחד כשיוצרים אוספי תמונות.
| תכונה | טעינה ישירה (loadGeoTIFF) |
נכס רשום (מניפסט) |
|---|---|---|
| הגדרה | ללא (רק URI של GCS) | מניפסט (לקוח Python, CLI או REST) |
| ביצועים | רגיל (הכותרת מוקראת בזמן הקריאה) | אופטימיזציה (נוסף לאינדקס בזמן היצירה) |
| ניהול | לא נוצר נכס | נכלל במכסת הנכסים, לא במכסת האחסון. |
| תרחיש לדוגמה | יצירת אב טיפוס, ניתוח אד-הוק | תהליכי עבודה בסביבת ייצור שדורשים קריאות מהירות. |
כתיבת קובצי COG ל-Cloud Storage
כדי לשמור את תוצאות החישוב של Earth Engine כקובצי COG בקטגוריה של Cloud Storage, משתמשים בפונקציה Export.image.toCloudStorage לייצוא באצווה (ראו ייצוא תמונות) ומגדירים את הפרמטר cloudOptimized כ-true ב-formatOptions. הפקודה הזו אומרת ל-Earth Engine לקמפל את התמונה ולכתוב אותה ישירות לקטגוריית GCS כ-COG שתואם באופן מלא.
מיקומי קטגוריות נתמכים ב-Cloud Storage
כדי ש-Earth Engine יוכל לגשת לקטגוריה של Cloud Storage, הקטגוריה חייבת להיות באחד מהאזורים או מהאזורים המרובים הבאים של מרכזי הנתונים:
- מספר האזורים של
us - כל אזור כפול בארה"ב שכולל את
us-central1 - אזור
us-central1
אם הקטגוריה נמצאת במרכז נתונים אזורי אחר, מערכת Earth Engine תדחה את בקשות הרישום והקריאה. ל-Earth Engine יש גישה לקובצי COG שמאוחסנים רק בקטגוריות של Google Cloud Storage. אין תמיכה בספקי אחסון בענן חיצוניים ובכתובות URL גנריות מסוג HTTP.
שיקולי עלות וסוגי אחסון
כשמנתחים נכסי COG רשומים, קריאות מ-Earth Engine לא גוררות חיובים על פעולות קריאה או על אחזור נתונים מ-Cloud Storage בפרויקט Google Cloud.
החיוב ב-Cloud Storage הוא בעיקר על אחסון נתונים סטנדרטי במנוחה (GB לחודש) ועל כל העברת נתונים של לקוח חיצוני או עמלות על תעבורת נתונים יוצאת (egress) ברשת (בהתאם למיקום הקטגוריה ולהגדרות הרשת של הלקוח).
המלצות לסוגי אחסון (storage classes)
- אחסון רגיל (מומלץ): אחסון רגיל מתאים במיוחד לתהליכי עבודה פעילים ב-Earth Engine. מכיוון שאין כללים לגבי משך האחסון המינימלי, אתם יכולים להחליף, לעדכן או למחוק קובצי COG זמניים בלי לשלם קנסות על מחיקה מוקדמת. בנוסף, אם אתם או שותפי העריכה שלכם ניגשים לקטגוריה באמצעות תוכנת GIS למחשב, סקריפטים של GDAL או מחברות של למידת מכונה מחוץ ל-Earth Engine, באחסון Standard לא תחויבו בעמלות קמעונאיות על אחזור.
- אחסון ב-Nearline, ב-Coldline וב-Archive: כל סוגי האחסון ב-Cloud Storage מספקים את אותם זמני אחזור קצרים וקצב העברת נתונים כמו Standard Storage, כך שאין פגיעה בביצועי הקריאה כשמשתמשים ברמות אחסון קרות יותר ב-Earth Engine. אפשר לקרוא את הנתונים האלה גם באמצעות חישובים של Earth Engine בלי לשלם עמלות על אחזור נתונים, אבל כללי הקמעונאות של Cloud Storage אוכפים משכי אחסון מינימליים מחמירים (30 ימים ל-Nearline, 90 ימים ל-Coldline ו-365 ימים ל-Archive). שינוי או מחיקה של קבצים לפני משך הזמן המינימלי שלהם מפעילים חיובים נוספים על מחיקה מוקדמת. בנוסף, גישה לאובייקטים קרים מכל כלי לקוח חיצוני כרוכה בתשלומים נוספים על אחזור נתונים.
למידע מפורט על מדיניות התמחור הקמעונאי ומשך הזמן המינימלי, קראו את מדריך התמחור של Google Cloud Storage.
תהליך עבודה כללי
תהליכי עבודה אופייניים לשימוש ב-COGs ב-Earth Engine כוללים את השלבים הבאים:
לייבוא נתונים חיצוניים:
- אופטימיזציה: ממירים את קובצי הרסטר לפורמט COG באמצעות כלים חיצוניים (כמו GDAL, סקריפטים של תחנת עבודה מקומית או צינורות עיבוד נתונים בענן).
- העלאה: מעלים את קובצי ה-COG לקטגוריה נתמכת של Cloud Storage שנמצאת ב-
us-central1או במספר אזורים בארה"ב. - הרשאות: ודאו שלכם ולכל שותפי העריכה בפרויקט יש הרשאת קריאה לקבצים ב-Cloud Storage (ראו הרשאות COG).
- רישום: משתמשים בספריית הלקוח של Python, בכלי שורת הפקודה
earthengineאו ב-API בארכיטקטורת REST כדי לרשום את קובצי ה-COG כנכסים של Earth Engine (ראו רישום COG).
כדי לייצא תוצאות:
- ייצוא: מריצים ייצוא באצווה מ-Earth Engine ל-Cloud Storage, כש-
cloudOptimizedמוגדר ל-true(ראו ייצוא תמונות). - רישום (אופציונלי): רישום קובץ ה-COG שיוצא בחזרה ב-Earth Engine כנכס חדש לניתוח נוסף (ראו רישום COG).
מוכנים להתחיל? כדי לרשום את הנכס הראשון, פועלים לפי המדריך המפורט לרישום COG.