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

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

  • קידוד גיאוגרפי בצד הלקוח, שמופעל בדפדפן, בדרך כלל בתגובה לפעולה של משתמש. ה-API של JavaScript של מפות Google כולל מחלקות ששולחים עבורכם את הבקשות. הגישה הזו מתוארת במסמכי התיעוד של Maps JavaScript API.
  • קידוד גיאוגרפי בצד שרת 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
    });
  }
});

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

זוהי דוגמה לשימוש ב-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 (שאילתות לדקה), שמחושב כסכום של השאילתות בצד הלקוח ובצד השרת.

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

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

הופך לקובץ שמור

למידע נוסף על שמירה במטמון, אפשר לקרוא את המדיניות בנושא Geocoding API.

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

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

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

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

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

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

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

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

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