ملی ای‌پی‌آی

مختصات جغرافیایی کد پستی چقدر دقیق است و چطور خوانده می‌شود؟

مختصات کد پستی نقطه‌ای است که به آن کد نگاشت شده، نه موقعیت در؛ برای انتخاب انبار کافی است و برای «کدام در» کافی نیست.

مختصات کد پستی یک نقطه است، نه یک ساختمان. دو عدد می‌گیرید، عرض و طول جغرافیایی، و آن دو را به نقطه‌ای روی نقشه تبدیل می‌کنید که به آن کد پستی نگاشت شده. نزدیک به در خانه است، اما قرار نیست روی خود در بنشیند.

این تمام پاسخ سؤالی است که زیاد پرسیده می‌شود: «دقت مختصات کد پستی چقدر است؟». بقیهٔ مقاله توضیح می‌دهد این برای کار شما یعنی چه، و چرا بیشتر اشتباه‌ها از ترتیب دو عدد می‌آید، نه از دقت.

دو عدد، یک ترتیب که همه جا یکی نیست

سرویس مختصات کد پستی در پاسخ نمونه‌اش این فیلدها را دارد: postal_code، latitude و longitude. نام فیلد روشن است، پس اینجا قاعده این است: همیشه با نام بخوانید، نه با جای عدد.

مشکل از جای دیگری شروع می‌شود. کتابخانه‌های نقشه در ترتیب جفت‌ها با هم یکی نیستند. بعضی «عرض، طول» می‌خواهند و بعضی «طول، عرض». اگر عددها را بی‌نام دست‌به‌دست کنید، نقطهٔ تهران ناگهان جایی در روسیه می‌افتد. رایج‌ترین باگ این حوزه همین است.

یک آزمون سه‌ثانیه‌ای بنویسید. ایران تقریباً بین عرض ۲۵ تا ۴۰ و طول ۴۴ تا ۶۴ قرار دارد (مقادیر تقریبی، فقط برای تشخیص جابه‌جایی). اگر عدد «عرض» شما بالای ۴۰ بود، احتمالاً آن را طول گذاشته‌اید:

js function looksSwapped(lat, lng) { // فقط برای گرفتن جابه‌جایی بدیهی؛ مرز دقیق کشور نیست return lat > 40 && lng < 40; }

این تابع مرز کشور را نمی‌سنجد، فقط جابه‌جایی را می‌گیرد. اگر مختصات از سرویس به جای دیگری رفت و قبل از رسیدن به نقشه چنین بررسی ارزانی داشت، بیشتر باگ‌ها همان‌جا گرفته می‌شود.

دقت: چه چیزی را می‌توان گفت و چه چیزی را نه

سرویس مختصات را به کد پستی نگاشت می‌کند. یعنی نقطه مال آن کد پستی است. این سه معنا دارد:

  • برای دو کد پستی همسایه (مثلاً دو واحد یک ساختمان)، ممکن است نقاط یکی یا بسیار نزدیک باشند؛ روی این حساب نکنید. تفکیک آن‌ها روی نقشه کار این عدد نیست.
  • برای مسیریابی آخرین متر، یعنی «پیک دقیقاً کدام در را بزند»، نشانی متنی همچنان لازم است.
  • برای کارهایی که فاصلهٔ تقریبی کافی است (کدام انبار نزدیک‌تر است، آیا مشتری داخل محدوده است) این نقطه معمولاً مناسب است، ولی مرز محدوده‌های باریک را با احتیاط بسنجید.

عددی برای «چند متر خطا» نمی‌دهیم، چون از داده‌ای که در دست داریم درنمی‌آید و حدس زدنش دقیقاً همان چیزی است که این مقاله نباید بکند. اگر دقتی برایتان حیاتی است، چند ده کد پستی شناخته‌شده را بسنجید و روی نقشه ببینید نقطه کجا می‌افتد.

چطور خودتان درستی را وارسی کنید

یک روش ارزان که در همان روز اول انجام‌شدنی است:

  1. ده تا بیست کد پستی بردارید که نشانی‌اش را از نزدیک می‌شناسید (دفتر خودتان، انبار، چند مشتری قدیمی).
  2. برای هرکدام مختصات بگیرید.
  3. هر نقطه را روی نقشه‌ای که در محصولتان استفاده می‌کنید بگذارید.
  4. فاصلهٔ نقطه تا ساختمان واقعی را با چشم یادداشت کنید.

نتیجه یک جدول کوچک است که به شما می‌گوید در شهر و منطقهٔ خودتان نقطه معمولاً کجا می‌افتد. این از هر عدد کلی که از جایی بخوانید قابل‌اعتمادتر است، چون به کار شما مربوط است.

نکتهٔ مهم: کدام نقشه

مختصات یک سیستم مرجع جغرافیایی دارد. نقشه‌های متداول وب با طول و عرض کار می‌کنند و کتابخانه‌های معروف همین را می‌پذیرند. اگر محصول شما با سیستم مختصات دیگری کار می‌کند (مثلاً نقشه‌های مهندسی با UTM)، پیش از رسم نقطه تبدیلش کنید؛ پاسخ را طول و عرض فرض کنید و تبدیل به سیستم دیگر با خودتان است.

چه چیزهایی در پاسخ نیست

نشانی نیست. اگر هم نقطه و هم متن می‌خواهید، هر کدام یک فراخوان جداست: استعلام نشانی متن می‌دهد و مختصات فقط دو عدد.

ارتفاع، شکل ساختمان یا محدوده کد پستی هم نیست. کد پستی در پاسخ یک نقطه است نه یک چندضلعی. پس سؤال «این نقطه داخل محلهٔ X است؟» را این سرویس مستقیم جواب نمی‌دهد؛ برای آن به لایهٔ مرز محله‌ها نیاز دارید که باید از منبع دیگری بیاورید.

اگر کد پستی نامعتبر یا بی‌رکورد باشد، پاسخ مختصات ندارد. در invalid_input هزینه‌ای کسر نمی‌شود، ولی not_found پاسخ معتبری است که هزینه دارد. در فرمتان این دو را از هم جدا نشان بدهید.

ذخیره‌کردن نتیجه

نقطهٔ یک کد پستی عملاً ثابت است؛ فراخوان دوباره برای همان کد، چیز تازه‌ای نمی‌آورد. پس نتیجه را کنار کد پستی در پایگاه‌داده خودتان نگه دارید. هنگام ذخیره، fetchedAt پاسخ را هم نگه دارید تا بعداً بدانید عدد چه موقع گرفته شده. جزئیات شکل پاسخ در مستندات API است.

مثال: چک‌کردن یک انبار

فرض کنید انبار شما کد پستی مشخصی دارد. مختصاتش را از سرویس مختصات کد پستی می‌گیرید و روی نقشه می‌گذارید. اگر نقطه حدود دو محله آن‌طرف‌تر افتاد، دو احتمال دارید: کد پستی انبار را از واحد دیگری برداشته‌اید، یا نقطهٔ ثبت‌شده برای آن کد با موقعیت واقعی فرق دارد. برای تشخیص، کد پستی را از قبض یا سند خود انبار بخوانید و دوباره بگیرید.

این وارسی یک‌بار انجام می‌شود، چون انبار تغییر نمی‌کند. ولی اگر مشتری‌ها هزاران کد پستی متفاوت هستند، فقط نمونه‌ای از آن‌ها را روی نقشه ببینید و باقی را به آستانه‌های ساده (مثل بررسی جابه‌جایی طول و عرض) بسپارید. هیچ‌کس هزاران نقطه را چشمی نمی‌بیند.

سه خطای رایج دیگر در نمایش روی نقشه

نمایش بدون بررسی خالی‌بودن. اگر برای یک کد پستی پاسخ مختصات نیامد (رکورد نبود)، فرم نباید نقطه‌ای در مبدأ مختصات بگذارد. مقدار صفر برای طول و عرض نقطه‌ای وسط اقیانوس است و هیچ‌کس از «پاسخ خالی» به آن فکر نمی‌کند. پیش از رسم، هر دو عدد را بررسی کنید که واقعاً عدد هستند.

گردکردن زودهنگام. اگر عددها را پیش از ذخیره به یکی دو رقم اعشار گرد کنید، نقطه چند کیلومتر جابه‌جا می‌شود. عدد را همان‌طور که برگشت ذخیره کنید و گرد کردن را فقط در نمایش انجام دهید.

رشته یا عدد. بعضی ابزارها مختصات را به‌صورت رشته می‌گیرند و مقایسه‌های عددی (مثل بزرگ‌تر یا کوچک‌تر) روی رشته غلط جواب می‌دهد. پیش از مقایسه به عدد تبدیل کنید.

هر سه خطا با یک آزمون واحد قابل گرفتن‌اند: چند کد پستی را از ورودی تا نقشه دنبال کنید و در هر مرحله مقدار را چاپ کنید.

در یک نگاه

مختصات کد پستی را نقطه‌ای بدانید که به آن کد نگاشت شده، نه موقعیت در. با نام فیلد بخوانیدش، جابه‌جایی طول و عرض را با یک بررسی ساده بگیرید، چند کد پستی آشنا را روی نقشه خودتان بسنجید و نتیجه را ذخیره کنید. این برای انتخاب انبار و محدوده پوشش کافی است؛ برای «کدام در»، نشانی متنی را هم کنارش نگه دارید.

آخرین بازبینی: تیم تحریریه ملی ای‌پی‌آی

وب‌سرویس مرتبط با این راهنما

API مختصات جغرافیایی کد پستی

طول و عرض جغرافیایی نقطه متناظر با یک کد پستی.

مشاهده مشخصات فنی و تعرفه

راهنماهای مرتبط

پرسش و تجربه کاربران

اگر این راهنما جوابتان را نداد، همین‌جا بپرسید. پرسش‌ها را تیمملی ای‌پی‌آی پاسخ می‌دهد و هر نظر پیش از انتشار بررسی می‌شود.

هنوز پرسشی ثبت نشده، اولین نفر باشید.