الأخبار

نقطة نهاية أسرع للارتفاع في المسارات الطويلة

نادرًا ما يكون مقطع الارتفاع لمسار مشي أو طريق قيادة إحداثية واحدة. بل هو عشرات النقاط، وأحيانًا مئات، على طول مسار، تحتاج كل منها إلى قيمة ارتفاع لبناء مخطط الصعود أو تقدير الجهد على طول الطريق. ونمط الاستخدام هذا، أي إحداثيات كثيرة تخدم مسارًا متصلًا واحدًا، هو ما حسّناه تحديدًا في مراجعة حديثة لـ /v1/elevation.

لم يتغير شكل الطلب والاستجابة في نقطة النهاية، ولا يزال كل ما هو موثق في /docs/elevation-lookup/ ساريًا تمامًا كما هو مكتوب. ما تغير هو مدى كفاءة المعالجة الداخلية لدفعة كبيرة من الإحداثيات على طول مسار، بهدف تقليل الوقت اللازم لاستعادة مقطع الارتفاع لمسار طويل بدلًا من نقطة واحدة منفردة.

بما أن الطلب المجمع يحتسب كل إحداثية عنصرًا واحدًا، تمامًا كما كان دائمًا، فإن هذا التحسين يؤثر في السرعة، لا في التسعير أو سلوك الحصة. فالمسار الذي يضم مئتي نقطة إحداثية لا يزال يُحتسب مئتي طلب من الحصة المطبقة أيًا كانت، سواء كانت الحصة اليومية المجانية أو الرصيد مسبق الدفع بسعر 0.0001 € للطلب أو التغطية ضمن باقة Unlimited. ما يتغير هو المدة التي تستغرقها الاستجابة للعودة، وهو أمر مهم مباشرة لأي شيء يبني مقطع مسار بشكل تفاعلي بدلًا من مهمة في الخلفية.

ينتقل هذا التحسين نفسه إلى مضيف التوافق الخاص بـ Open-Elevation لدينا في /compatibility/open-elevation/، لأنه يعتمد على نقطة نهاية الارتفاع الأساسية نفسها. وكل ما يرسل بالفعل دفعات بطول مسار عبر ذلك المضيف يستفيد من المعالجة الأسرع دون الحاجة إلى أي تغيير من جانب التكامل.

تميل تطبيقات التوجيه والمشي إلى أن تكون المكان الذي يُلمس فيه هذا النوع من التحسين بشكل مباشر أكثر من غيره، لأن مقطع الارتفاع الذي يستغرق تحميله وقتًا أطول بوضوح من المسار نفسه يُحدث تأخيرًا مرئيًا لمستخدم ينتظر أمام الخريطة. والاستجابة الأسرع لهذه الدفعات الأطول ذات شكل المسار تسد تلك الفجوة.

إذا كان تطبيقك يطلب الارتفاع لمسارات تتكون من إحداثيات كثيرة، سواء للمشي أو ركوب الدراجات أو اتجاهات القيادة، فينبغي أن تلاحظ ذلك تحسنًا هادئًا في سرعة عودة المقطع الكامل، دون الحاجة إلى تغيير أي شيء آخر في التكامل. ويبقى التوثيق الكامل لنقطة النهاية في /docs/elevation-lookup/.