ניקיון ותקינות במידע: איך להבטיח את איכות הנתונים במערכת ה-GIS הארגונית
מערכת המידע הגיאוגרפי (GIS) הנה בראש ובראשונה מערכת מידע. כמו כל מערכת מידע, האמינות שתיוחס לה בארגון ומעמדה כלפי משתמשיה, יגזרו במידה רבה מאיכותם של הנתונים המנוהלים במערכת. לכולנו יצא בוודאי להיתקל במערכות מידע אשר לאחר שימוש קצר בהן התרשמנו כי "אי אפשר לסמוך" על המידע המוצג ומנוהל מתוכן, ובדר"כ פשוט ויתרנו על המשך השימוש במערכת …
תקינות המידע חשובה לא רק למשתמשי הקצה. גם עבור עורכי המידע עצמם, היא מגבירה את האמינות המקצועית ומונעת מהם להיכנס ל"שגיאה נגררת" שתעצים עצמה עם המשך העריכות.
אז אם אמרנו שבעצם מבחינת הצורך בהבטחת איכות הנתונים אין הבדל בין מערכת GIS לכל מערכת מידע, מה בכל זאת מייחד את הפרמטר הזה במערכת מידע גיאוגרפי ? כמו כל דבר שקשור בממ"ג, התשובה נעוצה במרחב ובייצוג שלו על ידי הגיאומטריה של היישויות (Features) במערכת. במערכת GIS אנחנו פשוט צריכים שבמסגרת בדיקות האיכות תקלח תמיד בחשבון גם הגיאומטריה ומיקומה במרחב. אני בוחר לחלק את המושג הגדול של "איכות" לנתוני ה GIS אל חמש קטגוריות מרכזיות:
- דיוק מרחבי: היישויות הגיאוגרפיות ממוקמות באופן מדוייק במערכת הייחוס כך שמייצגות את מיקומם של הפריטים המתוארים בשטח.
- דיוק בסיווג: המאפיינים הא"נ ובראשם מאפייני הסיווג של הפריטים מאוכלסים באופן אמין.
- שלמות המידע: כל הפריטים שהיו אמורים להכלל אכן נקלטו (ולא "נשכחו" פריטים הקיימים בשטח).
- עקביות לוגית: תאימות מאפייני הפריטים למה שסביר למצוא בשטח, גם אם אין מידע מפורט – למשל שכביש בסיווג "כביש ראשי 4 נתיבים" לא ייקלט עם רוחב 5 מטר.
- עדכניות הנתונים: פריטים שהשתנו / נוספו / נעלמו מהשטח, צריכים להשתקף תוך פרק זמן סביר במערכת הממ"ג.
מאיפה מגיעות הגדרות של "מה נחשב מידע תקין" ?
אולי נתחיל מאיפה לא: לא היינו רוצים שכל עובד קליטת מידע יהיה אחראי בעצמו לקבוע מהם הסטנדרטים לאיכות הנתונים שהוא עצמו קולט …..
במקום זה, היינו רוצים לראות מצב בו הניסיון והידע של עובד קליטת המידע, משתלב עם הגדרות רגולציה המוכתבות על ידי גופי תקינה מקצועיים או לאומיים, ועם ייעוץ שיינתן לארגון על ידי מומחים לתחום המידע הנקלט. יחד, אמורות כל התובנות האלו להשתלב אל תכנית ארגונית להבטחת המידע הגיאוגרפי, שתשמש Reference להגדרה של מה נחשב עבור הארגון למידע מרחבי תקין, וכפועל יוצא מכך, מה נחשב למידע לא-תקין שיש לאתרו ואז לתקנו או למחוק אותו כליל מהמערכת.
ביצוע בדיקות תקינות על המידע – באיזה שלב ?
אנחנו מאמינים שהבטחת האיכות לנתונים הנו תהליך שיש לו שתי "פאזות" המשולבות כל הזמן זו בזו:
- חוקי אימות (Constraints) שימנעו הזנת מידע לא-תקין למערכת וכך ימנעו היווצרותו מלכתחילה במאגרים.
- תהליכי בקרה (Validations) שניתנים להפעלה בדיעבד, על בסיס עיתי או בסיומו של פרק בקליטת המידע, לאיתור שגיאות הקיימות במידע והתייחסות אליהן.
כלים קיימים במערכת ArcGIS להבטחת איכות הנתונים הגיאוגרפיים
מערכת ArcGIS הנה מערכת מידע שלמה לקליטה, ניהול, ניתוח והפצה של כלל המידע המרחבי הארגוני. ככזאת, קיימים בה כלי עזר רבים העשויים לייעל ולהבנות את תהליכי הבטחת איכות הנתונים. נסקור כאן כמה מהם בקצרה (על כל אחד מהם ניתן להעביר "קורס" שלם ובכל מקרה מלוא התיעוד זמין לכם ברשת
חוקי אימות למאפיינים – Attribute Domains
נראה שכמעט כולם מכירים את ה Attribute Domains. הם קלים מאד להגדרה ולמימוש והיו במערכת ArcGIS ממש מראשיתה. בבסיס עומדת היכולת להגדיר חוקי אימות למאפיינים כ Domains המוגדרים ברמת ה Geodatabase כולו, ואז ניתנים ל"הצמדה" אל שדות נתונים בשכבות או ב Subtypes של שכבות. קיימים שני סוגי Domains:
- Coded Value Domain – רשימת ערכים סגורה המאלצת את העורך לבחור נתון מתוך הרשימה המוגדרת.
- Range Domains – טווח ערכים מותר המגדיר אליו ערכים (עבור שדות נומריים) נחשבים תקינים.
ניתן להגדיר Attribute Domains בכל סוגי ה Geodatabase, ולהשתמש בהם הן בעריכות ArcMap והן ב ArcGIS Pro. בשניהם ניתן גם לעקוף את ה Domain באמצעות שימוש ב field Calculator. עורך המאפיינים בכל מקרה יצביע על הערך כחורג מהטווח / רשימה המוגדרת.
חוקי יחס מרחבי בין גיאומטריה בשכבות – Geodatabase Topology
גם טופולוגיית בסיס נתונים היא עניין די ותיק. מדובר ביכולת להגדיר יחסים "אסורים" או "נדרשים" בין שכבות, כגון "אסור שתתקיים חפיפה בין מבנים לבריכות" או "נקודת כתובת חייבת להיות ממקומת בתוך פוליגון מבנה".
לאחר שמגדירים את החוקים השונים, הם אינם מונעים עריכות, אלא "מוצפים" למשתמש לאחר ביצוע מהלך Validation כשגיאות פוטנציאליות עם האפשרות לתקן את השגיאה או לסמנה כ "Exception".
גם טופולוגיית בסיס נתונים יכולה לשמש אותנו בעריכות דרך ArcMap או דרך ArcGIS Pro.
חוקי אימות מתקדמים – Geodatabase Attribute Rules
כאן כבר מדובר על משהו חדש – הוצג לראשונה עם ArcGIS Pro 2.4. החוקים האלו – בניגוד לקודמים –יעבדו רק עבור עריכות עם ArcGIS Pro ולמען האמת שכבה שתגדירו עליה Attribute Rules באמצעות Pro תהפוך ללא נגישה בכלל עבור ArcMap (גם לצפייה …) – אבל כאן מסתיימים החסרונות ומפה – רק יתרונות! מדובר ביכולת חזקה מאד שמאפשרת הגדרת חוקי אימות ובדיקה מתקדמים המאוכסנים יחד עם השכבה בבסיס הנתונים. קיימים שלושה סוגים ל Attribute Rules:
- Calculation Rule – מגדיר חישוב אוטומטי מסויים שמתבצע אל שדות הפריט עם קליטתו כפונקציה של שדות שנקלטו או של הגדרה תהליכית אחרת.
- Constraint Rule – מגדיר חוק מניעה – שמבטל עריכה (הוספה / שינוי / מחיקה) לפריט אם נוגדת את החוקיות המוגדרת.
- Validation Rule – מגדיר בדיקת תקינות שניתנת להפעלה בדיעבד על המידע כדי לחשוף פריטים לא תקינים שמצאו דרכם אל המאגר.
בכל המקרים, הגדרת החוקיות מתבצעת באמצעות שפת Arcade. ניתן לראות בזה סוג של "תכנות" פשוט אבל עבור ביטויים פשוטים יש המון דוגמאות ועם קצת נסיון, גם אלו מכם שאינם מתכנתים יצליחו להגדיר חוקי אימות שכאלו. בכל מקרה, לאחר החלה של חוק אימות, הוא מוגדר בתוך בסיס הנתונים ולא ניתן לעקיפה, לא דרך עורך המאפיינים, לא דרך ה field Calculator, ולא בעריכה דרך web application.
שימוש ב Select ככלי לבקרת איכות
לפעמים אנחנו שוכחים אבל אחד הכלים החזקים ביותר להבטחת איכות הנתונים נמצא ממש "מתחת ליד": אם אנחנו יודעים לתאר אילו מצבים (גיאומטריים, מאפיינים) ייחשבו כ"לא-תקינים", נוכל תמיד למצוא את היישויות האלו באמצעות פעולת בחירה: בחירה לפי מאפיינים, בחירה לפי מיקום, ובעיקר שילוב של שניהם. ניתן לעשות זאת ידנית באמצעות כלי הבחירה האינטראקטיביים של המפה או ….. לשרשר מספר פעולות בחירה דרך Geoprocessing Model מוכן להפעלה שנוכל להשתמש בו בכל פעם שנרצה לאתר את ה Features שייחשבו מבחינתנו לשגויים במערכת.
שימוש בגרסאות עריכה ככלי לבקרת איכות
גרסאות עריכה של Enterprise Geodatabase הן באמת נושא לקורס בפני עצמו ….. אבל נסתפק בהקשר זה באזכור של אחת מהיכולות החזקות של עבודה בגרסאות: בידוד העריכה. כאשר אנחנו מבצעים את העריכות שלנו על המידע במסגרת Edit Version, אנחנו "לא מפריעים" לשאר משתמשי הארגון שאינם חשופים לעריכות שביצענו עד שנבחר למזג אותן אל גרסת ה Default. כך אנחנו יכולים בכל שלב של תהליך העריכה, לבצע את פעולת ה-Version Differences שתאתר עבורנו בשכבות השונות רק את הפריטים שנערכו (נוספו, שונו או נמחקו) בגרסת העבודה הנוכחית – ולבצע בקרת תקינות עליהם באופן ספציפי.
מבוא להרחבת ה ArcGIS Data Reviewer
כפי שנוכחנו עד כה, הבטחת האיכות לנתוני הממ"ג זה עסק רציני: חשוב לארגון, חשוב לנו כעורכים. ראינו גם שיש המון דרכים שונות ומשלימות להבטחת האיכות. מתוך ראיית החשיבות של תהליכי האיכות האלו, פותח ב Esri תוסף (Extension) ייעודי בדיוק למטרה זו – ה ArcGIS Data Reviewer.
תוסף זה מעשיר את הפונקציונליות הקיימת בכלי המדף בכלי עזר שונים המקלים עלינו את תהליכי בדיקות האיכות:
- סטים מוכנים לקונפיגורציה של בדיקות שחוסכות זמן רב בהגדרת אמצעי בקרה אחרים.
- ממשק משתמש ייעודי שמאפשר איגום של השגויים המתקבלים מהבדיקות בטבלאות ושכבות מיוחדות לתיעוד השגויים, ואפשרות לאיטרציה דרך סט השגויים לתיקון / סקירה.
- אפשרות להרצת סט הבדיקות / ולידציות גם מתוך ArcGIS Enterprise Service – הופך את בקרת האיכות למשאב ארגוני הניתן להפעלה מתוך יישומי Web.
תוסף ה ArcGIS Data Reviewer מכיל כאמור סט של בדיקות המוכנות לקונפיגורציה עבור שכבות הנתונים שלכם – בדיקות שיחסכו לכם מאמצים בדרך להגדרת תכנית ולידציה כוללת. תוכלו לראות את התיעוד המלא לבדיקות הקיימות או להתרשם מפוסטר המציג אותן באופן ויזואלי.
קיימות דרכים שונות לשימוש ביכולות ה Data Reviewer אבל בסקירה זו בחרתי להתמקד בשתיים מתוכן:
הגדרת Attribute Rules באמצעות Data Reviewer
על Attribute Rules סיפרנו בשלב מוקדם יותר של הבלוג. שם כתבנו שנקודת "חולשה" יחסית של כלי רב-עוצמה זה הנה הצורך להגדיר את הבדיקה או חוק האימות הספציפי שנרצה, באמצעות כתיבת ביטויי Arcade. כאן בדיוק באה לביטוי העזרה שניתנת לנו באמצעות Data Reviewer. עבור כל שכבה / טבלה שנרצה להגדיר עבורה Attribute Rules, ה Data Reviewer יציע לנו סט של בדיקות מוכנות לפי ההקשר של השכבה. בדיקות מוכנות אלו יהיו תחת קטגוריית ה "Ready to use Rules" במסך הגדרת ה Attribute Rules. כך למשל עבור שכבה פוליגונלית יוצעו לנו בדיקות מאפיינים וכן בדיקות גיאומטריות הרלוונטיות ליישויות פוליגון:
בעוד שעבור שכבה קווית נקבל סט אחר של בדיקות גיאומטריה – ההולמות יישויות קו:
הרצת Reviewer Batch Job
כבר ציינו קודם ש Attribute Rules לא יהיו תקפים לעבודה עם ArcMap. אם בכל זאת נחפש אפשרות להגדרת סט בדיקות שנוכל להפעיל הן עבור תהליכי עריכה ב ArcMap והן מתוך ArcGIS Pro, הרחבת ה Data Reviewer מעמידה לרשותנו יכולת נוספת: Batch Job. מדובר בסט חוקים הנערכים ב ArcMap דרך ממשק משתמש ייעודי (Reviewer Batch Job Manager)
במסגרתו נגדיר קטגוריות ובתוכן בדיקות ספציפיות
לאחר שמירת קובץ ה Batch Job, ניתן להפעיל אותו על כל Extent שנרצה או על כל המרחב, באופן יזום או מתוזמן (באמצעות Geoprocessing Tool)
ולקבל בכל פעם תיעוד מסודר בטבלת תוצאות של כל היישויות שנמצאו כשגויות על ידי הבדיקות המוגדרות ב Batch Job.
סיכום
קשה להפריז בחשיבותה של הבטחת האיכות למידע בכל מערכת מידע – ובמערכת GIS בפרט. מידע תקין ועדכני הוא הבסיס עליו נשענת אמינות המערכת הן בעיני עורכי המידע, הן בעיני מנהלי הארגון והן בעיני צרכני הקצה של המערכת באשר הם.
ArcGIS מציע לכם מגוון גדול של כלי עזר שיסייעו לבם במימוש תכנית הבטחת המידע הארגונית, הן במניעת הזנה של מידע לא-תקין למערכת, והן באיתור מידע שכזה במאגרים הקיימים.
הרחבת ArcGIS Data Reviewer מבנה את תהליכי הבטחת המידע, מוסיפה אפשרויות שונות לאוטומציה שלהם, מקלה על תהליך הגדרת הבדיקות האלו כחלק מסטים מובנים להרצה, ומספקת ממשק משתמש לסקירה ואיטרציה דרך תוצאות בדיקת התקינות.