נתוני ההתראות צריכים להיות תואמים למפרט של פרוטוקול OASIS פרוטוקול התראות נפוצות גרסה 1.2, וכן למפרט של התראות ציבוריות של Google מגרסה 1.0 ולדרישות הנוספות המפורטות בהמשך.
מידע על Google CAP
התקן CAP קובע את המבנה הבסיסי ואת רכיבי הנתונים עבור התראה CAP, אבל עדיין יש מקום משמעותי לחוסר עקביות באופן ובזמן שבהם נעשה שימוש ברכיבי הנתונים השונים.
הפלטפורמה שלנו נועדה לפשט את התהליך של מציאת מידע למקרה חירום על ידי שילוב של נתונים רלוונטיים באיכות גבוהה בכלים באינטרנט, שאנשים כבר משתמשים בהם מדי יום. המטרה של הדרישות הנוספות היא למקסם את פוטנציאל החשיפה של ההתראות למוצרי Google, ואת היעילות שלהן.
הבדלים ספציפיים ל-Google עם דרישות XML CAP 1.2 מסוכמים במפרט של Google Public CAP v1.0.
האפשרות "Google Public Alerts CAP" ב-CAP Validator בקוד פתוח מאפשרת לך לאמת את הנתונים שלך בהשוואה למפרט OASIS וגם לדרישות הנוספות של Google.
ההנחיות שבהמשך חלות על כל סוגי ההתראות והסכנות. בנוסף, ריכזנו כמה דרישות והמלצות נוספות עבור סוגי ההתראות הספציפיים האלה בקטע דוגמאות:
ביצוע בדיקות תקופתיות
- כדי לבצע בדיקות מערכת קבועות מקצה לקצה, עליך לוודא שהמערכת שלך יכולה לפרסם התראות באמצעות התכונה
<status>בדיקה</status>.
אזורי יעד לשליחת התראה
- אם קיימים אזורים שאינם רציפים באותה רמת התראה ואותה סוג, יוצרים
הודעות
<alert>נפרדות במקום<alert>נפרדות עם אזורים נפרדים. - אם הרכיב
<area>מכיל רכיבי<polygon>, צריך לוודא שהם פוליגונים חוקיים בלי לחצות קצוות ולהגדיר 6 נקודות עשרוניות לכל היותר. - אם הרכיב
<area>של ההתראות מכיל הגדרות גיאוגרפיות, יש לספק את הנתונים הגיאוגרפיים בפורמט shapefile ולהודיע ל-Google בכתובת google-public-alerts@google.com לפחות 30 יום לפני שהנתונים משתנים. - יש לצייר פוליגונים המבוססים על השפעה המותאמים אישית לתנאים הנוכחיים ולהאופי של האירוע כאשר זה אפשרי, במקום לטרגט התראות לאזורים גיאופוליטיים מוגדרים מראש (למשל מחוזות, מחוזות).
- יש לספק ל-Google תיאור קצר (פחות מ-50 תווים) של האזור המושפע מ
<areaDesc>או ב-<parameter>התראות ייעודיות נפרדות ל-CAP. הטקסט הזה יוצג בכותרת ההתראה.
להוסיף תוכן עשיר
- יש לכלול תוכן עשיר ומעשי שניתן לקריאה על ידי אנשים ברכיבי
<description>ו-<instruction>. - יש לתאר את האירוע הנוכחי, ההתפתחויות הצפויות, ההשפעה הצפויה וההמלצות הרלוונטיות.
- חשוב להקפיד על איות, דקדוק ופיסוק נכונים.
- השתמשו בטקסט פשוט או בסימון כדי לשפר את קריאות התוכן, במקום את תגי ה-HTML.
- ציינו קודי צבע RGB או הקסדצימאלי שתואמים לכל רמת התראה (אפשר לספק אותם ל-Google במצב אופליין).
עדכון התראות
כשהתראה משתנה, צריך ליצור התראה חדשה לגבי ההתראה הקודמת, במקום לשנות או להסיר את ההתראה הקיימת מהפיד. לאחר פרק זמן מוגדר (למשל, 24-48 שעות), יש להסיר מהפיד התראות שבוטלו, עודכנו או שפג תוקפן.
<msgType> העדכון או הביטול חייבים לכלול לפחות רכיב אחד (<references>).
כפי שצוין בתקן CAP, כל התראת התראה שמעדכנת התראה קודמת צריכה להשתמש ב-<msgType>Update</msgType> ולהגדיר את <references>code</references> לכל ההודעות הקשורות הקודמות שלא הגיעו לתאריך <expires> שלהן. העדכון או הביטול חייבים לחול על התראה שפג תוקפה.
יש שלוש דרכים לבטל אירועים, לפי סדר העדיפויות:
- יש להגדיר תאריך ושעה אחד (
<expires>) לכל אירוע, ולהגדיר בתיאור של הציפייה את סיום ההתראה. - יש להנפיק
<alert>חדש עם<msgType>UPDATE,<responseType>"All Clear", ו-<expires>לזמן קצר בעתיד. - יש להנפיק
<alert>חדש עם<msgType>CANCEL.
לקבלת דוגמאות, יש לעיין בהתראות לדוגמה עבור עדכונים וביטולים.
תמיכה בשפות מרובות
יש ליצור <alert> אחת עם <info> בלוקים (<info> חסימה אחת לכל שפה).
לפרטים נוספים ולהתראה לדוגמה רב-לשונית, ניתן לעיין בשפות מרובות.