אופטימיזציה של השימוש במכסה בעת קידוד גיאוגרפי

קידוד גיאוגרפי הוא התהליך של המרת כתובות ("1600 Amphitheatre Parkway, Mountain View, CA") לקואורדינטות גיאוגרפיות (37.423021, -122.083739), שבו אפשר להשתמש כדי למקם סמנים או ממקמים את המפה. ממשקי ה-API של הפלטפורמה של מפות Google מספקים גישות לקידוד גיאוגרפי:

  • קידוד גיאוגרפי בצד הלקוח, שמופעלת בדפדפן, בדרך כלל תגובה לפעולת משתמש. ממשק JavaScript API של מפות Google מספק המחלקות ששולחות את הבקשות בשבילכם. הגישה הזאת מתוארת API של מפות Google ל-JavaScript תיעוד.
  • קידוד גיאוגרפי בצד שרת HTTP, שמאפשר לשרת לשלוח שאילתות ישירות השרתים של Google לקואורדינטות. Geocoding API הוא האינטרנט שמספק את הפונקציונליות הזו. בדרך כלל, משלבים את הקוד הזה עם קוד אחר שפועל בצד השרת. קידוד גיאוגרפי בצד השרת מתואר Geocoding API תיעוד.

דוגמאות לקידוד גיאוגרפי בצד הלקוח ובצד השרת

לפניכם דוגמה של קידוד גיאוגרפי בצד הלקוח שדורש הכתובת, מקודדת את המיקום הגיאוגרפי, מעבירה את מרכז המפה למיקום הזה ומוסיפה סמן מפה:

geocoder = new google.maps.Geocoder();
geocoder.geocode({ 'address': address }, function(results, status) {
  if (status == google.maps.GeocoderStatus.OK) {
    map.setCenter(results[0].geometry.location);
    var marker = new google.maps.Marker({
      map: map,
      position: results[0].geometry.location
    });
  }
});

דוגמאות נוספות זמינות API JavaScript של מפות Google תיעוד.

הנה דוגמה באמצעות Python לביצוע פעולות בצד השרת בקשת קידוד גיאוגרפי:

import urllib2

address="1600+Amphitheatre+Parkway,+Mountain+View,+CA"
key="my-key-here"
url="https://maps.googleapis.com/maps/api/geocode/json?address=%s&key=%s" % (address, key)

response = urllib2.urlopen(url)

jsongeocode = response.read()

הפעולה הזו יוצרת אובייקט JSON עם התוכן הבא:

{
  "status": "OK",
  "results": [ {
    "types": street_address,
    "formatted_address": "1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA",
    "address_components": [ {
      "long_name": "1600",
      "short_name": "1600",
      "types": street_number
    }, {
      "long_name": "Amphitheatre Pkwy",
      "short_name": "Amphitheatre Pkwy",
      "types": route
    }, {
      "long_name": "Mountain View",
      "short_name": "Mountain View",
      "types": [ "locality", "political" ]
    }, {
      "long_name": "San Jose",
      "short_name": "San Jose",
      "types": [ "administrative_area_level_3", "political" ]
    }, {
      "long_name": "Santa Clara",
      "short_name": "Santa Clara",
      "types": [ "administrative_area_level_2", "political" ]
    }, {
      "long_name": "California",
      "short_name": "CA",
      "types": [ "administrative_area_level_1", "political" ]
    }, {
      "long_name": "United States",
      "short_name": "US",
      "types": [ "country", "political" ]
    }, {
      "long_name": "94043",
      "short_name": "94043",
      "types": postal_code
    } ],
    "geometry": {
      "location": {
        "lat": 37.4220323,
        "lng": -122.0845109
      },
      "location_type": "ROOFTOP",
      "viewport": {
        "southwest": {
          "lat": 37.4188847,
          "lng": -122.0876585
        },
        "northeast": {
          "lat": 37.4251799,
          "lng": -122.0813633
        }
      }
    }
  } ]
}

הקואורדינטות בצד השרת גם מספקות פורמט XML כחלופה JSON. דוגמאות נוספות זמינות Geocoding API התיעוד וגם ספריות לקוח ל-Python ובשפות אחרות.

שיקולי מכסות ועלות

האסטרטגיות המתוארות כאן הן עלויות קידוד גיאוגרפי, מכסות ומגבלות קצב של יצירת בקשות מהמסמך.

עלות

מגבלות המכסה ליום (QPD) כבר לא בשימוש בבקשות לקידוד גיאוגרפי. במקום זאת, כל בקשת קידוד גיאוגרפי, בין אם בצד הלקוח דרך הדפדפן או בצד השרת דרך שירות האינטרנט של Geocoding API החיוב מתבצע לפי מחיר לכל מחיר. כדי לנהל את עלות השימוש, כדאי לשקול הגבלת המכסה היומית שלכם.

מגבלות קצב של יצירת בקשות

שירות הקידוד הגיאוגרפי מוגבל ל- 3,000 QPM (שאילתות לדקה). מחושב כסכום השאילתות בצד הלקוח ובצד השרת.

כשמריצים בקשות לקידוד גיאוגרפי בצד הלקוח במרווחי זמן תקופתיים, כמו באפליקציה לנייד, הבקשות שלכם עשויות להחזיר שגיאות אם כל המשתמשים ביצוע בקשות בו-זמנית (לדוגמה, כל הזמן באותה שנייה של כל דקה). כדי למנוע מצב כזה, אפשר לנסות את אחת מהאפשרויות הבאות:

שמירה במטמון

צפייה כללי מדיניות Geocoding API לגבי שמירה במטמון.

מתי כדאי להשתמש בקידוד גיאוגרפי בצד הלקוח

התשובה הקצרה היא 'כמעט תמיד'. הסיבות לכך הן:

  • בקשה ותגובה מצד הלקוח מספקים מענה מהיר יותר חוויה אינטראקטיבית למשתמשים.
  • בקשה בצד הלקוח יכולה לכלול מידע שמשפר את הקידוד הגיאוגרפי איכות: שפת המשתמש, האזור ואזור התצוגה.

באופן ספציפי, קידוד גיאוגרפי בצד הלקוח הוא האפשרות הטובה ביותר בקידוד גיאוגרפי של כתובות על סמך קלט מהמשתמש.

יש שתי ארכיטקטורות בסיסיות לקידוד גיאוגרפי בצד הלקוח:

  • מבצעים את הקידוד הגיאוגרפי ואת התצוגה ישירות בדפדפן. לדוגמה, המשתמש מזין כתובת בדף. האפליקציה יוצרת קידוד גיאוגרפי. לאחר מכן הדף משתמש בקואורדינטות כדי ליצור סמן במפה. לחלופין, האפליקציה שלך ניתוח פשוט באמצעות קואורדינטות. לא נשלחים נתונים לשרת שלכם. הפעולה הזו תפחית את העומס על השרת.
  • מבצעים את הקידוד הגיאוגרפי בדפדפן ושולחים אותו לשרת. למשל, המשתמש מזין כתובת בדף שלכם. האפליקציה שלך את הקואורדינטות בדפדפן. לאחר מכן האפליקציה שולחת את הנתונים לשרת שלכם. השרת מגיב עם נתונים מסוימים, כמו נקודות עניין קרובות. הזה מאפשר לכם להתאים אישית תשובה על סמך הנתונים שלכם.

מתי כדאי להשתמש בקידוד גיאוגרפי בצד השרת

קידוד גיאוגרפי בצד השרת מומלץ במיוחד לאפליקציות לדרוש מכם לקודד כתובות שהומרו לקואורדינטות ללא קלט מהלקוח. דוגמה נפוצה הוא כשמקבלים מערך נתונים שנפרד מקלט של משתמשים, למשל אם יש קבוצה קבועה, סופית וידועה של כתובות שדורשות קידוד גיאוגרפי. ניתן לבצע קידוד גיאוגרפי בצד השרת שימושי גם כגיבוי למקרים שבהם הקידוד הגיאוגרפי בצד הלקוח נכשל.

חלק מהחששות האפשריים הם הגדלה מיותרת של זמן האחזור עבור המשתמש, ותוצאות קידוד גיאוגרפי באיכות נמוכה יותר מאשר בצד הלקוח, כי פחות המידע הזה זמין בבקשה.