תת־חלקות לא התאימו לשורת החלקה
לחלקה יכול להיות כל מספר של תת־חלקות. כשהן נשמרו בתוך רשומת החלקה, הסינון והוולידציה הסתבכו.
העברתי את תת־החלקות לטבלה נפרדת עם מפתח ייחודי (חלקה, תת־חלקה). בעדכון מחליפים את כל הסט בבת אחת, כך שאין עריכות חלקיות.
מערכת בק־אופיס לחברת קרקעות ונדל״ן ישראלית, לניהול תיק החלקות שלה לפי גוש וחלקה. תהליך רקע מושך את הכתובת של כל חלקה משירות ה־GIS הלאומי, ובקליק אחד החלקה נפתחת מסומנת על המפה הלאומית. קודם שני הדברים האלה נעשו ידנית.
בישראל קרקע מזוהה לפי מספר גוש ומספר חלקה. החברה מנהלת תיק גדול של חלקות כאלה, ולכל אחת יש סוג בעלות, שיטת רישום, ייעוד, שטח, תת־חלקות ומסמכים נלווים. שתי משימות יומיומיות נעשו ידנית. כדי למצוא כתובת של חלקה היה צריך לחפש בפורטל ה־GIS הלאומי, חלקה אחרי חלקה, ולהעתיק את התוצאה. כדי לראות איפה החלקה נמצאת היה צריך לפתוח שוב את הפורטל ולהקליד את המספרים. ולא הייתה דרך פשוטה לדעת אילו רשומות עדיין חסרות נתונים.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
ה־worker רץ בתוך שרת ה־API, כך שאין עוד רכיב לפרוס. הוא שומר את התשובה הגולמית מה־GIS לצד הכתובת המפוענחת לצורכי בקרה, ונקודת הקצה של הרשימה משמיטה את העמודה הזאת כדי שעמודי הרשימה יישארו קלים.
רשומה נחשבת ”הושלמה” כשיש לה כתובת, שטח וייעוד. ה־SQL Server מחשב ושומר את הדגל, כך שהרשימה מציגה וממיינת לפי סטטוס בלי קוד אפליקטיבי שצריך לשמור מסונכרן. המחיר: שינוי בכלל דורש שינוי סכמה ולא רק שינוי הגדרה.
ה־worker בוחר חלקות שעוד לא עודכנו, בקבוצות קטנות ומסודרות, ומרווח בין הקריאות 100 מילישניות. חלקות חדשות מועשרות אוטומטית, ואחרי הפעלה מחדש הוא ממשיך מאיפה שעצר. המחיר: הכתובות מתמלאות תוך דקות ולא מיד.
אפליקציית הניהול טוענת את מפת ה־JavaScript של ה־GIS הלאומי ומסמנת קודם את הגוש ואז את החלקה. הלקוח מקבל את השכבות הקדסטריות הרשמיות בלי עלות. המחיר: סקריפט צד שלישי עם תלות ב־jQuery ותזמון טעינה משלו, שדרש טיפול זהיר (פירוט בהמשך).
מסננים, מיון ועימוד נכתבים ל־query string ונקראים ממנו בטעינה. תצוגה מסוננת שורדת רענון ואפשר לשלוח אותה לעמית כקישור. המחיר: יותר קוד פענוח, כולל מסננים עם כמה ערכים.
לחלקה יכול להיות כל מספר של תת־חלקות. כשהן נשמרו בתוך רשומת החלקה, הסינון והוולידציה הסתבכו.
העברתי את תת־החלקות לטבלה נפרדת עם מפתח ייחודי (חלקה, תת־חלקה). בעדכון מחליפים את כל הסט בבת אחת, כך שאין עריכות חלקיות.
אפשר היה להזין את אותו גוש וחלקה פעמיים, ואז המדיה וההיסטוריה מתפצלות בין שתי רשומות.
הוספתי אינדקס ייחודי על גוש + חלקה, כך שה־DB דוחה כפילויות לא משנה מאיזה מסלול הנתונים מגיעים.
משתמשים איבדו את המסננים ואת העמוד בכל רענון או מעבר מקישור. בנוסף, ערכי ברירת מחדל דרסו ערכים שהגיעו מה־URL.
העברתי את מצב הטבלה ל־query string עם פענוח מוקלד. ברירות המחדל חלות רק כשערך חסר. גודל העמוד קבוע על 100, ומיון ברירת המחדל הוא לפי גוש ואז חלקה.
סקריפט המפה הלאומית נטען באופן אסינכרוני. סימון חלקה לפני שהמפה אותחלה נכשל בשקט, בלי שום שגיאה.
טוענים את הסקריפט לפי דרישה, בודקים כל 100 מילישניות אם ממשק המפה זמין (עם timeout של 7 שניות), ומסמנים גוש וחלקה רק כשגם המפה וגם נתוני החלקה מוכנים.
חלק מצמדי הגוש/חלקה מחזירים מה־GIS תוצאה ריקה או שגיאה.
כל חלקה מטופלת בנפרד ונרשמת ללוג עם הגוש והחלקה שלה. קבוצה שנכשלה ממתינה לפני המחזור הבא. תוצאה ריקה אף פעם לא דורסת כתובת קיימת.
כל חלקה צריכה מסמכים: קישורים חיצוניים, קבצים שהועלו, או גם וגם.
בניתי טופס מדיה אחד ששולח multipart/form-data ל־API, שמאחסן את הקבצים ב־S3. בעריכה הקובץ הקיים נשמר, אלא אם הועלה קובץ חדש.
זמני השלבים הם הערכות שמרניות להמחשה ולא מדידות. שלב הכתובת ב”אחרי” רץ בלי מעורבות של אף אחד.
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים