كيف يمكنني حساب خطوط متساوية الزمن لرحلة الذهاب "من المنزل إلى العمل" (السفر إلى وجهة معيّنة) مقارنةً بخطوط متساوية الزمن لرحلة العودة (السفر من نقطة انطلاق معيّنة)؟
تتوفّر عمليات احتساب الرحلات الواردة والصادرة في الإصدار 1 من واجهة برمجة التطبيقات باستخدام المَعلمة travelDirection (travel_direction):
FROM(رحلة الذهاب): تحتسب هذه المَعلمة المنطقة التي يمكن الوصول إليهاfromنقطة الانطلاق ضمن المهلة الزمنية المحدّدة. وهذا مناسب لحالات الاستخدام مثل مناطق التسليم أو تغطية الخدمة.TO(الرحلات القادمة): يتم احتساب المنطقة التي يمكنك السفر منهاtoنقطة الانطلاق خلال المهلة الزمنية المحدّدة. وهذا مناسب لتطبيقات مثل ميزات التنقل إلى العمل أو تحديد مناطق التجمع حول مكتب مركزي أو مركز نقل.
ما هي الاختلافات بين أوضاع السفر الأربعة (DRIVE وTWO_WHEELER وBICYCLE وWALK)؟
يستخدم كل وضع قواعد الوصول إلى شبكة الطرق وتكاليف الانعطاف ونموذج السرعة الخاصة به:
DRIVE: يتنقّل عبر الطرق الصالحة للقيادة باستخدام السرعات المنشورة أو سرعات التدفق الحر أو سرعات حركة المرور المباشرة (TRAFFIC_AWARE)، لمدة تصل إلى 3,600 ثانية (60 دقيقة).-
TWO_WHEELER: تعبر الطرق التي يمكن للمركبات الآلية ذات العجلتين الوصول إليها بسرعات نموذجية أقل منDRIVEعلى الطرق السريعة ومساراتTRAFFIC_AWAREاختيارية، لمدة تصل إلى 3,600 ثانية (60 دقيقة). ونتيجةً لذلك، يكون خط تساوي الزمنTWO_WHEELERأكبر منBICYCLEولكنه أصغر منDRIVEعلى طول الطرق السريعة. -
BICYCLE: يعبر الشوارع ومسارات الدراجات والمسارات المخصصة للدراجات بسرعات معدَّلة حسب نوع الطريق والمنحدر (باستثناء الطرق السريعة والطرق السريعة المفتوحة)، لمدة تصل إلى 7,200 ثانية (120 دقيقة). -
WALK: يعبر أرصفة المشاة والمسارات والشوارع بسرعة المشي المعدَّلة حسب المنحدر (مع تجاهل القيود المفروضة على المركبات ذات الاتجاه الواحد)، لمدة تصل إلى 7,200 ثانية (120 دقيقة).
هل تتضمّن Isochrones API العبّارات أو المعابر المائية؟
لا، لأنّ واجهة برمجة التطبيقات Isochrones API تتنقّل عبر الطرق والجسور والأنفاق والمسارات فقط. يتم استبعاد مسارات العبّارات ومعابر النقل المائي في جميع أوضاع السفر. لن يتم تضمين الجزر أو أشباه الجزر المتصلة فقط بالعبّارة في خط متساوي الزمن يتم إنشاؤه من البر الرئيسي.
في بعض الأحيان، يبدو المضلّع الذي تم عرضه ممتلئًا أو له حواف خشنة ومتدرجة، خاصةً في الفترات الطويلة. لماذا يتغيّر مستوى التفاصيل؟
تعدّل Isochrones API بشكل ديناميكي دقة شبكة الحسابات المكانية
استنادًا إلى travel_duration وtravel_mode المطلوبَين:
- المدد الأقصر: استخدِم شبكة دقيقة للغاية وعالية الدقة لأنّ المساحة الإجمالية صغيرة، ما يؤدي إلى حدود مفصّلة.
- المدد الأطول: يتم الانتقال إلى شبكة أوسع وأقل دقة لتغطية المنطقة الجغرافية الشاسعة بكفاءة بدون التسبب في وقت استجابة طويل.
يمكنك ضبط السمة الاختيارية polygon_fidelity على HIGH أو MEDIUM أو LOW إذا كنت
بحاجة إلى مستوى معيّن ومتّسق من التفاصيل بغض النظر عن المدة.
لماذا يؤدي طلب خط متساوي الزمن لإحداثيات داخل متنزّه أو بحيرة أو مجمّع صناعي كبير في بعض الأحيان إلى ظهور الخطأ "لم يتم العثور على الموقع الجغرافي"؟
تحتسب واجهة Isochrones API مُدد الرحلات باستخدام الطرق والمسارات. يجب أن "تثبّت" واجهة برمجة التطبيقات النقطة على أقرب جزء متوافق قبل بدء الحساب إذا لم تكن إحداثيات نقطة الانطلاق المطلوبة تقع على طريق معروف.
يبلغ الحد الأقصى لمسافة المحاذاة لكل وضع سفر حوالي 200 متر أو أقل.
يستخدم WALK وBICYCLE مسافات أقصر من DRIVE وTWO_WHEELER، ويتجاهل DRIVE وTWO_WHEELER المسارات المخصّصة للمشاة فقط.
إذا كان إحداثي نقطة الانطلاق يقع على مسافة أبعد من هذه المسافة من جزء طريق صالح ومتوافق مع الوضع، يتعذّر الالتزام بالمسار، وتعرض واجهة برمجة التطبيقات الخطأ NOT_FOUND. لحلّ هذه المشكلة، تأكَّد من أنّ إحداثياتك قريبة من شارع أو ممر عام.
لماذا تظهر لي رسالة خطأ عند طلب مسار يتجنّب الازدحام المروري للمشي أو ركوب الدراجات؟
تتوفّر أحوال حركة المرور في الوقت الفعلي (TRAFFIC_AWARE) لوضعَي السفر DRIVE وTWO_WHEELER. إذا حاولت طلب خط متساوي الزمن
لـ WALK أو BICYCLE مع ضبط routingPreference على TRAFFIC_AWARE، ستعرض واجهة برمجة التطبيقات
الخطأ 400 INVALID_ARGUMENT.
عندما أعرض استجابة GeoJSON على خريطتي، يظهر الشكل في المكان الخطأ أو يكون مشوّهًا أو يتعذّر عرضه. ما هو سبب هذه المشكلة؟
يحدث هذا عادةً بسبب عدم تطابق ترتيب الإحداثيات.
وفقًا لمعيار GeoJSON (RFC 7946)، تعرض واجهة Isochrones API الإحداثيات
بالترتيب [longitude, latitude]. ومع ذلك، فإنّ العديد من حزم تطوير البرامج (SDK) الخاصة بالخرائط وعناصر الأشكال الهندسية المخصّصة تتطلّب إدخال الإحداثيات بالترتيب [latitude, longitude].
إذا كان عرض الخريطة غير صحيح، تحقَّق من كيفية تعامل حزمة تطوير البرامج (SDK) للخريطة مع GeoJSON:
- Google Maps JavaScript API: إذا كنت تستخدم طبقة البيانات
(
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 لضمان استخدام الحدود المحسوبة بدقة رياضية.