لماذا يمكنني طلب منحنى زمني متساوي للمشي أو ركوب الدراجة لمدة تصل إلى ساعتين، ولكن لا يمكنني طلب منحنى زمني متساوي للقيادة إلا لمدة ساعة واحدة؟
ويستند هذا الحدّ إلى التعقيد الحسابي للعمليات الحسابية. تقطع المركبة مسافة أكبر بكثير من المسافة التي يقطعها المشاة أو راكبو الدراجات خلال المدة نفسها، ما يعني أنّ شبكة الطرق الأساسية التي يجب تحليلها تتوسّع بشكل كبير. تقتصر مدة القيادة على ساعة واحدة كحد أقصى (3,600 ثانية) لضمان إمكانية أن تعرض واجهة برمجة التطبيقات ردًا خلال فترة زمنية متزامنة وسريعة وفي الوقت الفعلي، بينما يمكن تتبُّع المشي وركوب الدراجات لمدة تصل إلى ساعتين (7,200 ثانية).
كيف يمكنني احتساب منحنى تساوي الوقت "للتنقّل إلى العمل" الوارد (التنقّل إلى وجهة) مقارنةً بمنحنى تساوي الوقت الصادر (التنقّل من نقطة انطلاق)؟
تتوفّر العمليات الحسابية الواردة والصادرة في الإصدار 1 من واجهة برمجة التطبيقات باستخدام المَعلمة
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. لحلّ هذه المشكلة، تأكَّد من أنّ إحداثياتك موضوعة بالقرب من شارع أو مسار عام.
لماذا تظهر لي رسالة خطأ عند طلب ميزة "تحديد المسار حسب الازدحام" للمشي أو ركوب الدرّاجة؟
تتوفّر أحوال حركة المرور المباشرة (TRAFFIC_AWARE) حصريًا لوضع السفر DRIVE. إذا حاولت طلب منحنى تساوي الزمن لـ WALK أو BICYCLE مع ضبط routingPreference على TRAFFIC_AWARE، ستعرض واجهة برمجة التطبيقات الخطأ 400 INVALID_ARGUMENT.
عند عرض استجابة GeoJSON على الخريطة، يظهر الشكل في المكان غير الصحيح أو يكون مشوّهًا أو يتعذّر عرضه. ما هو سبب ذلك؟
ويحدث ذلك عادةً بسبب عدم تطابق ترتيب الإحداثيات.
وفقًا لمعيار GeoJSON (RFC 7946)، تعرض واجهة برمجة التطبيقات Isochrones API الإحداثيات بالترتيب [longitude, latitude]. ومع ذلك، تتوقّع العديد من حِزم تطوير البرامج (SDK) الخاصة بربط البيانات وكائنات الأشكال الهندسية المخصّصة أن تكون الإحداثيات بالترتيب [latitude, longitude].
إذا كان عرض الخريطة غير صحيح، تحقَّق من طريقة تعامل حزمة تطوير البرامج (SDK) الخاصة بالخرائط مع GeoJSON:
- واجهة برمجة تطبيقات JavaScript لخرائط Google: إذا كنت تستخدم "طبقة البيانات" (
map.data.addGeoJson())، يتم التعامل مع هذا الترتيب تلقائيًا ولا يلزم اتّخاذ أي إجراء. - الكائنات المخصّصة أو حِزم SDK الأخرى: إذا كنت تحلّل الردّ يدويًا إلى كائنات
LatLng، عليك تكرار الإحداثيات في حمولة GeoJSON وتحويل قيم[lng, lat]إلى أزواج[lat, lng]قبل العرض.
لماذا توجد "ثقوب" فارغة داخل مضلّع منحنى التساوي الزمني، وهل يمكنني الحصول على شكل مصمت بدلاً من ذلك؟
تمثّل الثغرات المناطق التي لا يمكن الوصول إليها عبر الطرق خلال المهلة الزمنية المحدّدة. ويشيع ذلك في المناطق التي تضم غابات أو مسطحات مائية أو مطارات أو ممتلكات خاصة كبيرة لا يمكن للمركبات أو المشاة التنقّل فيها.
لا تعرض واجهة برمجة التطبيقات الخارجية الإصدار 1 مَعلمة لإزالة الثقوب تلقائيًا. إذا كان تطبيقك يتطلّب حدودًا ثابتة، مثلاً لإجراء عمليات التحقّق من احتواء نقطة ضمن مضلّع، يمكنك اتّباع ما يلي:
- اضبط المَعلمة
polygon_fidelityعلىMEDIUMأوLOWلتشجيع الخوارزمية على التعميم والدمج على مستوى هذه الفجوات الداخلية. - استخدِم مكتبة GIS من جهة العميل (مثل Turf.js) لتحليل GeoJSON واستخراج حلقة الإحداثيات الأولى فقط (الغلاف الخارجي)، مع تجاهل أي حلقات داخلية لاحقة (الثقوب).
هل يجب تفعيل الخيار enable_smoothing للتحليل المكاني في الخلفية؟
لا، تم تصميم المَعلمة enable_smoothing لأغراض جمالية بحتة.
تعمل هذه السمة على تقريب الزوايا الحادة لشبكة الحساب الأساسية لجعل الشكل يبدو طبيعيًا على الخريطة.
لا يُنصح باستخدام التنعيم لإجراء تحليل مكاني دقيق لأنّه يغيّر الرؤوس ويؤدي إلى إزاحة الحدود قليلاً. بالنسبة إلى العمليات الحسابية في الخلفية أو طلبات البحث في قاعدة البيانات أو اختبارات النقطة داخل المضلّع، اضبط قيمة enable_smoothing على false لضمان استخدام الحدود المحسوبة بدقة رياضية.