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