كيف يمكنني حساب منحنى تساوي الوقت لـ "رحلة القدوم إلى العمل" (السفر إلى وجهة) مقابل منحنى تساوي الوقت لـ "رحلة الذهاب" (السفر من نقطة الانطلاق)؟
تتوفّر إمكانية حساب كلّ من منحنى تساوي الوقت للرحلة إلى العمل ومنحنى تساوي الوقت للرحلة من مكان معيّن في الإصدار الأول من واجهة برمجة التطبيقات باستخدام المَعلمة travel_direction:
FROM(من مكان معيّن): يتم حساب المنطقة التي يمكن الوصول إليهاfromنقطة معيّنة خلال المدة الزمنية المحدّدة. ويكون هذا الخيار مناسبًا لحالات الاستخدام مثل مناطق التسليم أو نطاق الخدمة.TO(رحلة قدوم): يتم حساب المنطقة التي يمكنك السفر منهاtoنقطة الانطلاق خلال المدة الزمنية المحدّدة. ويكون هذا الخيار مناسبًا لتطبيقات مثل ميزات الرحلة إلى العمل أو تحديد مناطق التجميع حول مكتب مركزي أو مركز نقل.
في بعض الأحيان، يبدو المضلّع الذي يتم عرضه على شكل مربّعات أو تكون حوافه متقطّعة أو متدرّجة، خاصةً بالنسبة إلى المدد الأطول. لماذا يتغيّر مستوى التفاصيل؟
تعدّل Isochrones API بشكلٍ ديناميكي دقة شبكة الحسابات المكانية استنادًا إلى travel_duration وtravel_mode المطلوبَين:
- المدد الأقصر: يتم استخدام شبكة عالية الدقة ومحسّنة للغاية لأنّ المساحة الإجمالية صغيرة، ما يؤدي إلى ظهور حدود مفصّلة.
- المدد الأطول: يتم الانتقال إلى شبكة أقل دقة وأكثر خشونة لتغطية المنطقة الجغرافية الواسعة بكفاءة بدون التسبب في حالات تأخير شديدة.
يمكنك ضبط polygon_fidelity الاختيارية على HIGH أو MEDIUM أو LOW إذا كنت بحاجة إلى مستوى تفاصيل محدّد وثابت بغض النظر عن المدة.
لماذا يؤدي طلب منحنى تساوي الوقت لإحداثية داخل حديقة أو بحيرة أو مجمّع صناعي كبير في بعض الأحيان إلى ظهور الخطأ "لم يتم العثور على النتيجة"؟
تحسب Isochrones API مُدد الرحلات باستخدام الطرق والمسارات. يجب أن "تثبّت" واجهة برمجة التطبيقات النقطة على أقرب جزء متوافق قبل بدء الحساب إذا لم تكن إحداثيات نقطة البداية المطلوبة تقع على طريق معترف به.
لكل وضع سفر حد أقصى محدّد لمسافة التثبيت:
DRIVE: 200 متر (يتم تجاهل المسارات المخصّصة للمشاة فقط).TWO_WHEELER: 200 متر (يتم تجاهل المسارات المخصّصة للمشاة فقط).BICYCLE: 180 مترWALK: 150 متر
إذا كانت إحداثية نقطة البداية تقع على مسافة أبعد من هذه الحدود عن جزء طريق صالح ومتوافق مع وضع السفر، يتعذّر التثبيت وتعرض واجهة برمجة التطبيقات الخطأ NOT_FOUND. لحلّ هذه المشكلة، تأكَّد من وضع الإحداثيات بالقرب من شارع أو مسار عام.
لماذا تظهر لي رسالة خطأ عند طلب توجيه مراعٍ لحركة المرور للمشي أو ركوب الدراجة؟
تتوفّر إمكانية استخدام أحوال حركة المرور المباشرة (TRAFFIC_AWARE) لوضعَي السفر DRIVE وTWO_WHEELER. إذا حاولت طلب منحنى تساوي الوقت لوضعَي السفر WALK أو BICYCLE مع ضبط routingPreference على TRAFFIC_AWARE، ستعرض واجهة برمجة التطبيقات الخطأ 400 INVALID_ARGUMENT.
عند عرض استجابة GeoJSON على الخريطة، يظهر الشكل في مكان غير صحيح أو مشوّه أو لا يتم عرضه. ما هو سبب حدوث ذلك؟
يرجع ذلك دائمًا تقريبًا إلى عدم تطابق ترتيب الإحداثيات.
وفقًا لمعيار GeoJSON (RFC 7946)، تعرض Isochrones API الإحداثيات
بالترتيب [longitude, latitude] ومع ذلك، تتوقّع العديد من حِزم تطوير الخرائط والكيانات الهندسية المخصّصة
الإحداثيات بالترتيب [latitude, longitude].
إذا كان عرض الخريطة غير صحيح، تحقَّق من طريقة تعامُل حزمة تطوير الخرائط مع GeoJSON:
- Google Maps JavaScript API: إذا كنت تستخدم طبقة البيانات (
map.data.addGeoJson())، يتم التعامل مع هذا الترتيب تلقائيًا ولا يلزم اتخاذ أي إجراء. - الكيانات المخصّصة أو حِزم تطوير البرامج الأخرى: إذا كنت تحلّل الاستجابة يدويًا
إلى كائنات
LatLng، عليك تكرار الإحداثيات في حمولة GeoJSON ونقل قيم[lng, lat]إلى أزواج[lat, lng]قبل العرض.
لماذا تظهر "ثقوب" فارغة داخل مضلّع منحنى تساوي الوقت، وهل يمكنني الحصول على شكل مصمت بدلاً من ذلك؟
تمثّل الثقوب المناطق التي لا تتضمّن طرقًا يمكن الوصول إليها خلال المدة الزمنية المحدّدة. ويحدث ذلك عادةً في المناطق التي تضم غابات كبيرة أو مسطحات مائية أو مطارات أو عقارات خاصة لا يمكن للمركبات أو المشاة السفر فيها.
لا يعرض الإصدار الأول من واجهة برمجة التطبيقات الخارجية مَعلمة لإزالة الثقوب تلقائيًا. إذا كان تطبيقك يتطلّب حدودًا مصمتة، مثلاً لإجراء عمليات تحقّق من احتواء نقطة داخل مضلّع، يمكنك إجراء ما يلي:
- اضبط المَعلمة
polygon_fidelityعلىMEDIUMأوLOWلتشجيع الخوارزمية على التعميم والدمج فوق هذه الفجوات الداخلية. - استخدِم مكتبة نظم المعلومات الجغرافية من جهة العميل (مثل Turf.js) لتحليل GeoJSON واستخراج حلقة الإحداثيات الأولى فقط (الطبقة الخارجية)، مع تجاهل أي حلقات داخلية لاحقة (الثقوب).
هل يجب تفعيل الخيار enable_smoothing لتحليل البيانات المكانية من جهة الخلفية؟
لا، تم تصميم المَعلمة enable_smoothing لأغراض جمالية بحتة.
فهي تُدوّر الزوايا الحادة لشبكة الحسابات الأساسية لجعل الشكل يبدو طبيعيًا على الخريطة.
لا يُنصح باستخدام ميزة التنعيم لإجراء تحليل مكاني دقيق لأنّها تغيّر الرؤوس وتُزيح الحدود قليلاً. بالنسبة إلى عمليات الحساب من جهة الخلفية أو طلبات البحث في قاعدة البيانات أو اختبارات النقطة داخل المضلّع، اضبط enable_smoothing على false لضمان استخدام الحدود المحسوبة بدقة رياضية.