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