نقل البيانات من الإصدار 3 إلى الإصدار 4 من Geocoding API

المطوّرون في المنطقة الاقتصادية الأوروبية

يقدّم الإصدار 4 من Geocoding API عدة طرق جديدة تحلّ محل الوظائف في الإصدار 3 من واجهة برمجة التطبيقات. يوضّح لك هذا الدليل كيفية نقل تطبيقك لاستخدام طرق الإصدار 4 الجديدة.

يمكنك استخدام مفاتيح واجهة برمجة التطبيقات الحالية مع طرق الإصدار 4 الجديدة. ومع ذلك، إذا كنت قد طلبت زيادة الحصة المتاحة في الإصدار 3 من واجهة برمجة التطبيقات، عليك طلب زيادة الحصة المتاحة في الإصدار 4 الجديد من واجهات برمجة التطبيقات.

النقل من الإصدار 3 من خدمة الترميز الجغرافي

إذا كنت تستخدم الإصدار 3 من الترميز الجغرافي لترميز العناوين جغرافيًا، عليك نقل البيانات إلى طريقة الترميز الجغرافي لعنوان في الإصدار 4، والتي تقبل طلب GET.

تغيّر واجهة برمجة التطبيقات الإصدار 4 الأسماء والبنية وتتوقف عن إتاحة عدة مَعلمات. ننصحك بشدة باستخدام قناع حقل لتحديد الحقول التي تريد عرضها في الاستجابة.

تغييرات مَعلمات الطلب

مَعلمة الإصدار 3 المَعلمة v4 ملاحظات
‫address، components address يتم الآن تمرير العنوان غير المنظَّم (الإصدار 3 address) في مسار عنوان URL. يتم الآن تمرير فلاتر المكوّنات (الإصدار 3 components) كمَعلمات طلب بحث address.*.
bounds locationBias.rectangle تمت إعادة تسميته، وتم تغيير البنية إلى عنصر.
language languageCode تمت إعادة التسمية.
region regionCode تمت إعادة التسمية.
extra_computations مُزال

تغييرات حقل الردّ

الحقل v3 الحقل v4 ملاحظات
‫status، error_message مُزال يستخدم الإصدار 4 رموز حالة HTTP ونصوص الأخطاء.
results.address_components.long_name / results.address_components.short_name results.addressComponents.longText / results.addressComponents.shortText تمت إعادة التسمية.
results.geometry.location_type results.granularity تمت إعادة التسمية.
results.geometry.location results.location أسماء الحقول: lat/lng -> latitude/longitude
results.geometry.viewport results.viewport أسماء الحقول: northeast/southwest -> high/low
results.postcode_localities results.postalCodeLocalities تمت إعادة التسمية. يتم الآن عرضها لبلدية واحدة أو أكثر (الإصدار 3 مطلوب > 1).
results.partial_match مُزال
الأرباح الجديدة results.addressComponents.languageCode لغة مكوّن العنوان المحدّد.
الأرباح الجديدة results.bounds حدود صريحة باستخدام high/low
الأرباح الجديدة results.place اسم المرجع الخاص بالمكان
الأرباح الجديدة results.postalAddress عنصر PostalAddress منظَّم

نقل البيانات من الإصدار 3 من خدمة "عكس الترميز الجغرافي"

إذا كنت تستخدم الإصدار 3 من خدمة عكس الترميز الجغرافي لتحويل الإحداثيات إلى عناوين، عليك نقل البيانات إلى طريقة عكس الترميز الجغرافي لموقع جغرافي في الإصدار 4، والتي تقبل طلب استرداد بيانات باستخدام GET.

تغيّر واجهة برمجة التطبيقات الإصدار 4 الأسماء والبنية وتتوقف عن إتاحة عدة مَعلمات. ننصحك بشدة باستخدام قناع حقل لتحديد الحقول التي تريد عرضها في الاستجابة.

تغييرات مَعلمات الطلب

مَعلمة الإصدار 3 المَعلمة v4 ملاحظات
language languageCode تمت إعادة التسمية.
region regionCode تمت إعادة التسمية.
result_type types تمت إعادة تسميته، ويستخدم مَعلمات طلب بحث متكرّرة.
location_type granularity تمت إعادة تسميته، ويستخدم مَعلمات طلب بحث متكرّرة.
extra_computations مُزال

تغييرات حقل الردّ

الحقل v3 الحقل v4 ملاحظات
‫status، error_message مُزال يستخدم الإصدار 4 رموز حالة HTTP ونصوص الأخطاء.
results.address_components.long_name / results.address_components.short_name results.addressComponents.longText / results.addressComponents.shortText تمت إعادة التسمية.
results.geometry.location_type results.granularity تمت إعادة التسمية.
results.geometry.location results.location أسماء الحقول: lat/lng -> latitude/longitude
results.geometry.viewport results.viewport أسماء الحقول: northeast/southwest -> high/low
الأرباح الجديدة results.addressComponents.languageCode لغة مكوّن العنوان المحدّد.
الأرباح الجديدة results.bounds حدود صريحة باستخدام high/low
الأرباح الجديدة results.place اسم المرجع الخاص بالمكان
الأرباح الجديدة results.postalAddress عنصر PostalAddress منظَّم

الترحيل من الإصدار 3 من واصفات العناوين

إذا كنت تستخدم address_descriptor للحصول على معلومات إضافية عن موقع جغرافي باستخدام الإصدار 3 من الترميز الجغرافي، عليك الانتقال إلى استخدام الحقل landmarks في SearchDestinationsResponse.

نقل البيانات من الإصدار 3 من خدمة الترميز الجغرافي للأماكن

إذا كنت تستخدم place_id للحصول على عنوان معرّف مكان معيّن باستخدام الإصدار 3 من Geocoding، عليك الانتقال إلى الإصدار 4 من طريقة Place Geocoding التي تقبل طلب GET.

تغيّر واجهة برمجة التطبيقات الإصدار 4 الأسماء والبنية وتتوقف عن إتاحة عدة مَعلمات. ننصحك بشدة باستخدام قناع حقل لتحديد الحقول التي تريد عرضها في الاستجابة.

تغييرات مَعلمات الطلب

مَعلمة الإصدار 3 المَعلمة v4 ملاحظات
place_id الحقل place في بروتوكول الطلب يتم الآن تقديم معرّف المكان كمعلَمة مسار places/{place}، على سبيل المثال: https://geocode.googleapis.com/v4/geocode/places/ChIJj61dQgK6j4AR4GeTYWZsKWw. ويتم ربط ذلك بحقل المكان في الطلب الأساسي.
language languageCode تمت إعادة التسمية.
region regionCode تمت إعادة التسمية.

تغييرات حقل الردّ

الحقل v3 الحقل v4 ملاحظات
‫status، error_message مُزال يستخدم الإصدار 4 رموز حالة HTTP ونصوص الأخطاء.
results (الجذر) تعرض الإصدار 4 عنصر نتيجة واحدًا، وليس مصفوفة results.
results.address_components.long_name / results.address_components.short_name addressComponents.longText / addressComponents.shortText تمت إعادة التسمية.
results.geometry.location_type granularity تمت إعادة التسمية.
results.geometry.location location أسماء الحقول: lat/lng -> latitude/longitude
results.geometry.viewport viewport أسماء الحقول: northeast/southwest -> high/low
results.postcode_localities postalCodeLocalities تمت إعادة التسمية. يتم الآن عرضها لبلدية واحدة أو أكثر (الإصدار 3 مطلوب > 1).
الأرباح الجديدة addressComponents.languageCode لغة مكوّن العنوان المحدّد.
الأرباح الجديدة bounds حدود صريحة باستخدام high/low
الأرباح الجديدة place اسم المرجع الخاص بالمكان
الأرباح الجديدة postalAddress عنصر PostalAddress منظَّم

الانتقال من Geocoding Hyperlocal Data إلى Destinations

سيتم استبدال الميزات التالية في الإصدار 3 من Geocoding API بطريقة SearchDestinations في الإصدار 4 من Geocoding API:

  • مرّات الدخول
  • نقاط التنقّل
  • مخطّطات المباني
  • الأراضي المحيطة

إذا كنت تستخدم الإصدار 3 من Geocoding API للميزات المذكورة أعلاه، يمكنك الاستعانة بهذا المستند للمساعدة في استخدام طريقة SearchDestinations بدلاً من ذلك للحصول على هذه الميزات. يوضّح هذا المستند المكان الذي يمكن فيه العثور على هذه الميزات في الردّ SearchDestinations، والاختلافات في طريقة تمثيل هذه الميزات في الردود من واجهة برمجة التطبيقات بين الإصدار 3 من Geocoding API والطريقة SearchDestinations للإصدار 4 من Geocoding API.

مرّات الدخول

للحصول على المداخل المرتبطة بـ destination، استخدِم الحقل destination.entrances.

يُرجى العِلم أنّ تنسيق entrance يختلف قليلاً عن تنسيق المدخل في الإصدار 3 من Geocoding API. يحتوي كل مدخل في destination.entrances على الحقول التالية:

  • ‫displayName: هذا حقل اختياري جديد يتضمّن اسمًا يمكن قراءته للمدخل، مثل "البوابة B".
  • location: هذا هو موقع جغرافي من النوع LatLng، وهو يختلف عن التنسيق المستخدَم في الإصدار 3 من Geocoding API.
  • ‫tags: هذا الحقل هو نفسه الحقل tags الخاص بالمداخل من الإصدار 3 من Geocoding API.
  • place: مشابه للحقل buildingPlaceId الخاص بالمداخل من الإصدار 3 من Geocoding API. ومع ذلك، يمكن أن يكون رقم تعريف المكان في هذا الحقل خاصًا بمكان من أي نوع، وليس بالضرورة مبنى فقط.

للحصول على نقاط التنقّل المرتبطة بـ destination، استخدِم الحقل destination.navigationPoints.

يُرجى العِلم أنّ تنسيق navigationPoint يختلف قليلاً عن تنسيق نقطة التنقّل في Geocoding API الإصدار 3. يحتوي كل عنصر من عناصر التنقّل في destination.navigationPoints على الحقول التالية:

  • ‫displayName: هذا حقل اختياري جديد يتضمّن اسمًا يمكن قراءته للنقطة المخصّصة للتنقّل، مثل "شارع 5".
  • location: هذا هو موقع جغرافي من النوع LatLng، وهو يختلف عن التنسيق المستخدَم في الإصدار 3 من Geocoding API.
  • ‫travelModes: يشبه هذا الحقل الحقل restrictedTravelModes الخاص بنقاط التنقّل من الإصدار 3 من Geocoding API. قيم التعداد المحتملة هي نفسها، والفرق الوحيد هو أنّ هذا الحقل يمثّل الآن وسائل النقل المقبولة لنقطة التنقّل، بدلاً من وسائل النقل المحظورة.
  • ‫usage: هذا حقل جديد يحتوي على حالات الاستخدام التي تتيحها نقطة التنقّل. يُرجى العِلم أنّ معظم نقاط التنقّل ستتضمّن استخدامًا UNKNOWN، ولكن هذا لا يعني بالضرورة أنّ استخدام نقطة التنقّل مقيّد بأي شكل من الأشكال.

مخطّطات المباني

للحصول على المخططات التفصيلية للمباني المرتبطة بـ destination، يجب استخدام الحقل displayPolygon في عناصر placeView ضمن destination التي تمثّل المباني. بالنسبة إلى كل placeView، يمكنك التحقّق مما إذا كان مبنى باستخدام الحقل placeView.structureType. إذا كان نوع البنية هو BUILDING، يمكنك الحصول على المخطط التفصيلي من الحقل placeView.displayPolygon. سيتضمّن placeView أيضًا حقولاً إضافية للمبنى لم تكن متوفّرة في الإصدار 3 من Geocoding API.

يمكن أن يتضمّن destination عنصر placeView يمثّل مبنى في الحقول التالية:

  • ‫destination.primary: هذا هو المكان الأساسي للوجهة.
  • ‫destination.containingPlaces: هذا حقل متكرّر يمكنه استيعاب أماكن أكبر "تحتوي" على المكان الأساسي. على سبيل المثال، إذا كان المكان الأساسي هو subpremise، سيحتوي containingPlaces عادةً على placeView الذي يمثّل المبنى.
  • ‫destination.subDestinations: هذا حقل متكرّر يمكنه استيعاب وجهات فرعية للمكان الأساسي. على سبيل المثال، الوحدات السكنية الفردية في مبنى. لا يتضمّن هذا الحقل عادةً placeView يمثّل مبنى.

يُرجى العِلم أنّ تنسيق placeView.displayPolygon يتطابق مع تنسيق المخطط التفصيلي للمبنى في الإصدار 3 من Geocoding API، وهو تنسيق GeoJSON، باستخدام تنسيق RFC 7946.

الأراضي المحيطة

على غرار إنشاء مخططات تفصيلية للمباني، للحصول على الأراضي المرتبطة بـ destination، عليك استخدام الحقل displayPolygon الخاص بكائنات placeView في destination التي تمثّل الأراضي. بالنسبة إلى كل placeView، يمكنك التحقّق مما إذا كان سببًا باستخدام الحقل placeView.structureType. إذا كان نوع البنية هو GROUNDS، يمكنك الحصول على المخطط التفصيلي من الحقل placeView.displayPolygon. ستتضمّن placeView أيضًا حقولاً إضافية للأراضي غير المضمّنة في الإصدار 3 من Geocoding API.

يمكن أن يتضمّن destination عنصر placeView يمثّل أسبابًا في الحقول التالية:

  • destination.primary
  • destination.containingPlaces
  • destination.subDestinations

يُرجى العِلم أنّ تنسيق placeView.displayPolygon يتطابق مع تنسيق مخطط الأراضي في Geocoding API الإصدار 3، وهو تنسيق GeoJSON، باستخدام تنسيق RFC 7946.

دقة النتائج

في الإصدار 3 من Geocoding API، كان الحقل location_type في شكل الردّ الهندسي يشير إلى دقة النتائج، وكان بعض العملاء يصنّفون النتائج أو يفلترونها استنادًا إلى هذه القيم (ROOFTOP وRANGE_INTERPOLATED وGEOMETRIC_CENTER وAPPROXIMATE). في عمليات نقل البيانات العادية إلى الإصدار 4 من Geocoding API، تتم إعادة تسمية هذا الحقل إلى granularity.

في Destinations API (الإصدار 4 SearchDestinations)، لا يتوفّر الحقل location_type. بدلاً من ذلك، يتم التعامل مع المعلومات المكانية بشكل مختلف:

  • لا حاجة إلى فلترة يدوية من جهة العميل: على الرغم من أنّ خدمة الترميز الجغرافي العادية توفّر نتائج متعدّدة بمستويات تفصيل مختلفة، تقلّل طريقة SearchDestinations من الغموض من خلال تحديد وجهة واحدة محسّنة كلما أمكن ذلك. ويؤدي ذلك إلى إزالة الحاجة إلى أن يفلتر العملاء حسب نوع الموقع الجغرافي لتحديد النتيجة الأفضل.
  • المعلومات المكانية الممثَّلة بنوع البنية والمضلّعات المعروضة: يتم الإشارة إلى الهندسة المكانية والبنية من خلال:
    • displayPolygon (للحصول على تطابق تام في الشكل الهندسي)
    • الحقل structureType ضمن العنصر placeView
  • ربط أنواع البنية:
    • إنّ structureType التي تتضمّن POINT أو BUILDING أو SECTION تتوافق بشكل عام مع ما كان يُعرف سابقًا باسم ROOFTOP.
    • يشير structureType بقيمة GROUNDS عادةً إلى GEOMETRIC_CENTER.

استخدام قناع حقل لطلب هذه الميزات

تتطلّب طريقة SearchDestinations قناع حقل، كما هو موضّح في اختيار الحقول التي سيتم عرضها. يمكن ضبط قناع الحقل على * لعرض جميع الحقول، أو يمكنك ضبطه على الحقول المحدّدة التي تريد تلقّيها. على سبيل المثال، يضبط طلب البيانات من واجهة برمجة التطبيقات التالي قناع الحقل لتلقّي جميع الحقول المطلوبة للحصول على المداخل ونقاط التنقّل ومخططات المباني والمساحات الخارجية لوجهة معيّنة:

curl -X POST -d '{"place": "places/ChIJG3kh4hq6j4AR_XuFQnV0_t8"}' \
  -H "X-Goog-Api-Key: API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Goog-FieldMask: destinations.entrances,destinations.navigationPoints,destinations.primary,destinations.containingPlaces,destinations.subDestinations" \
  https://geocode.googleapis.com/v4/geocode/destinations

الاعتبارات الأمنية

تم تصميم الإصدار 4 من Geocoding API ليكون واجهة برمجة تطبيقات من خادم إلى خادم. لا يتوفّر مسار نقل بيانات مباشر لمستخدمي JavaScript من الإصدار 3 إلى الإصدار 4. إنّ استدعاء طرق الإصدار 4 مباشرةً من JavaScript من جهة العميل (على سبيل المثال، في متصفّح) باستخدام مفتاح واجهة برمجة التطبيقات يعرّض مفتاح واجهة برمجة التطبيقات لخطر كبير من السرقة وإساءة الاستخدام.

على الرغم من أنّ قيود الإحالة الناجحة عبر HTTP مفيدة، إلا أنّها لا توفّر حماية كافية لنقاط نهاية خدمة الويب لأنّه يمكن للمهاجمين تجاوزها بسهولة من خلال تزوير عنوان Referer في طلباتهم.

الطريقة المقترَحة لاستخدام الإصدار 4 من Geocoding API هي من خادم الخلفية الخاص بك. يجب أن يرسل تطبيق العميل طلبات إلى هذا الخادم الوسيط، الذي يطلب بعد ذلك من Google API بشكل آمن باستخدام مفتاح واجهة برمجة تطبيقات محمي (على سبيل المثال، مفتاح مخزّن في متغيّر بيئة أو مدير أسرار). يضمن ذلك عدم عرض مفتاح واجهة برمجة التطبيقات في رمز الواجهة الأمامية.

بدائل لاحتياجات من جهة العميل

إذا كانت لديك احتياجات من جهة العميل تتطلّب ترميزًا جغرافيًا، ننصحك باستخدام أحد الحلول الحالية من جهة العميل: