Skip to main content

داده‌های مکانی

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

تصمیم اصلی​

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

  1. یک ستون اصلی مکانی برای ذخیره و کوئری
  2. یک نمایش مناسب API برای خروجی
  3. ورودی‌های مشخص و قابل‌اعتبارسنجی برای ثبت مختصات
  4. تبدیل صریح بین UTM، lat/lon و geometry

این یعنی:

  • منبع حقیقت مختصات، ستون geometry است.
  • اگر API به JSON نیاز دارد، آن JSON باید از روی geometry ساخته شود.
  • latitude و longitude یا x و y فقط ورودی یا داده خام مهاجرت هستند، نه ساختار نهایی جستجو.

چرا این ساختار را انتخاب می‌کنیم؟​

چون نیازهای واقعی پروژه‌ها معمولا یکی یا چند مورد از این‌ها هستند:

  • نمایش روی نقشه
  • فیلتر در محدوده فعلی نقشه
  • پیدا کردن نزدیک‌ترین رکورد
  • تشخیص اینکه یک نقطه داخل کدام محدوده قرار دارد
  • محاسبه فاصله، مساحت یا هم‌پوشانی

در این سناریوها، نگه‌داری داده به‌صورت latitude / longitude پراکنده یا GeoJSON خام در JSON، خیلی زود باعث می‌شود کوئری‌ها کند، پیچیده و سخت‌اعتماد شوند. PostGIS این مشکل را با ذخیره‌سازی native، ایندکس مکانی و توابع استاندارد حل می‌کند.

ساختار استاندارد فیلدهای مختصات​

ستون اصلی: location​

این ستون مبنای همه کوئری‌های مکانی است و باید از نوع geometry(..., 4326) باشد.

کار این ستون:

  • منبع نهایی و قابل‌اتکای مختصات
  • پایه ایندکس GiST
  • مبنای BBox، Nearby، Point-in-Polygon و سایر کوئری‌ها

نمایش خروجی: geojson​

اگر API یا فرانت نیاز به ساختار JSON داشته باشد، آن را از location تولید می‌کنیم؛ نه اینکه GeoJSON را دستی جداگانه نگه داریم.

کار این فیلد:

  • خروجی استاندارد برای API
  • مصرف راحت‌تر در Frontend
  • جلوگیری از چندبار تبدیل در لایه اپلیکیشن

فیلدهای ورودی خام​

بسته به منبع داده، پروژه ممکن است یکی از این شکل‌ها را دریافت کند:

  • latitude / longitude
  • x / y / zone برای UTM
  • GeoJSON خام
  • فایل Shape / KML / سایر فرمت‌های ورودی

این‌ها ساختار نهایی نیستند. همه باید در نهایت به location تبدیل شوند.

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

lat/lon​

  • latitude یعنی عرض جغرافیایی
  • longitude یعنی طول جغرافیایی
  • مبنای پیشنهادی برای ذخیره نهایی در PostGIS: EPSG:4326
  • بازه معتبر:
    • latitude: از -90 تا 90
    • longitude: از -180 تا 180

برای ایران، بیشتر داده‌ها معمولا در این بازه هستند:

  • latitude: تقریبا بین 25 تا 40
  • longitude: تقریبا بین 44 تا 64

UTM​

  • x یا Easting: فاصله افقی در سیستم UTM
  • y یا Northing: فاصله عمودی در سیستم UTM
  • zone: زون UTM
  • برای ایران، در خیلی از سناریوها Zone 39N رایج است، ولی نباید بدون بررسی برای همه داده‌ها فرض شود

UTM برای ورود داده‌های نقشه‌برداری و ثبتی رایج است، اما ساختار ذخیره‌سازی نهایی پروژه نیست. این داده باید به WGS84 تبدیل و سپس در location ذخیره شود.

GeoJSON​

GeoJSON برای تبادل داده مناسب است، اما برای کوئری مکانی سنگین، ستون اصلی مناسبی نیست. اگر داده از بیرون به شکل GeoJSON می‌آید، باید Parse و به geometry تبدیل شود.

چه چیزی را استاندارد می‌کنیم؟​

از این به بعد برای فیلدهای مختصات پروژه‌ها این موارد استاندارد هستند:

  • ذخیره نهایی روی location geometry(..., 4326)
  • ایندکس مکانی GiST روی location
  • تولید geojson از روی location در صورت نیاز API
  • تبدیل صریح ورودی‌های UTM یا lat/lon به location
  • جلوگیری از کوئری مستقیم روی JSON خام