GeoJSON چیست؟ فرمت، انواع هندسه و دام‌های محصول واقعی

GeoJSON فرمت مبتنی بر JSON است که هر نقشه وب مدرن می‌تواند بخواند. اگر تا حالا یک چندضلعی روی یک نقشه Leaflet کشیده‌اید، یک vector layer در MapLibre استایل داده‌اید یا یک منطقه خدمت در PostGIS ذخیره کرده‌اید، با GeoJSON کار کرده‌اید، حتی اگر پسوند فایل چیز دیگری گفته باشد.

در این راهنما توضیح می‌دهم GeoJSON واقعاً چیست، انواع هندسه‌اش چه معنی دارند، در سیستم‌های واقعی کجا ظاهر می‌شود و کدام دام‌ها وقتی فایل‌های GeoJSON از لپ‌تاپ توسعه‌دهنده بیرون می‌آیند و به محصول واقعی می‌رسند تیم‌ها را گاز می‌گیرند.

GeoJSON واقعاً چیست

GeoJSON یک فرمت باز برای کدگذاری ساختارهای داده جغرافیایی است که توسط IETF به‌عنوان RFC 7946 در ۲۰۱۶ استاندارد شده است. یک زیرمجموعه سختگیرانه از JSON است: هر سند GeoJSON یک JSON معتبر است، اما این spec قواعدی دربارهٔ کلیدهایی که مجاز هستند، ساختار هندسه و ترتیب مختصات اضافه می‌کند.

این فرمت عمداً کوچک است. در کل spec فقط نه نوع شیء سطح بالا وجود دارد، و یک توسعه‌دهنده توانمند می‌تواند همه آن‌ها را در ذهن نگه دارد. آن کوچکی دلیلی است که GeoJSON به lingua franca نقشه‌برداری وب تبدیل شده: خواندنش آسان است، نوشتنش آسان است و اعتبارسنجی‌اش آسان است.

مختصات همیشه به صورت [longitude, latitude] نوشته می‌شوند (با altitude اختیاری به‌عنوان مقدار سوم)، و سیستم مرجع مختصات روی WGS84 ثابت است، همان datum که GPS گوشی شما استفاده می‌کند. هیچ مذاکره‌ای، هیچ metadata پروجکشن، هیچ بحث ترتیب محور وجود ندارد. یک datum، یک ترتیب، همه‌جا.

انواع هندسه

GeoJSON هفت نوع هندسه تعریف می‌کند. سه نوع اول primitive ها هستند:

• Point: یک مختصات واحد، که برای پین‌ها، آدرس‌ها و سنسورهای فردی استفاده می‌شود
• LineString: یک لیست مرتب از دو یا چند مختصات، که برای مسیرها، جاده‌ها و رودخانه‌ها استفاده می‌شود
• Polygon: یک حلقه بسته از مختصات (نقطه اول و آخر یکسان)، که برای ساختمان‌ها، قطعات و مرزهای اداری استفاده می‌شود

سه نوع بعدی صرفاً مجموعه‌هایی از آن primitive ها هستند:

• MultiPoint: چندین نقطه در یک هندسه، مفید برای نمایش زنجیره‌ای از فروشگاه‌ها به‌عنوان یک feature واحد
• MultiLineString: چندین line string، که برای مسیرهای پاره‌پاره یا سیستم‌های رودخانه استفاده می‌شود
• MultiPolygon: چندین چندضلعی، انتخاب درست برای هر کشوری که جزایر دارد (یعنی تقریباً همه‌شان)

نوع هفتم، GeometryCollection، می‌تواند ترکیبی از هرکدام از موارد بالا را نگه دارد. این spec استفاده از آن را تشویق نمی‌کند چون بیشتر مصرف‌کننده‌ها آن را بد مدیریت می‌کنند، و تقریباً هیچ‌وقت نیازی به آن ندارید. اگر به سراغ GeometryCollection می‌روید، معمولاً نشانه این است که مدل می‌خواهد یک FeatureCollection باشد.

Feature و FeatureCollection

یک هندسه به‌تنهایی به‌ندرت مفید است. باید بدانید چه چیزی را نمایش می‌دهد. Feature برای همین است: یک Feature هندسه را با یک شیء properties که metadata دلخواه نگه می‌دارد می‌پیچد.

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [4.8952, 52.3702]
  },
  "properties": {
    "name": "Amsterdam Centraal",
    "type": "station",
    "platforms": 15
  }
}

یک FeatureCollection یک لیست از Featureهاست. تقریباً هر فایل GeoJSON واقعی که در طبیعت برخورد می‌کنید یک FeatureCollection است، چون دیتاست‌های واقعی چیزهای زیادی در خود دارند.

انتخاب طراحی حیاتی این است که properties باز است. این spec هیچ چیزی دربارهٔ اینکه چه کلیدهایی می‌تواند داشته باشد یا آن مقادیر چه نوعی باید داشته باشند نمی‌گوید. این یک ویژگی است نه یک باگ: یعنی GeoJSON برای مبلمان خیابان، مرزهای انتخاباتی، مناطق تحویل و track های کشتی AIS بدون نیاز به گسترش فرمت کار می‌کند. همچنین یعنی مصرف‌کننده‌ها باید مراقب باشند: اگر به وجود properties.population وابسته‌اید، خودتان اعتبارسنجی کنید، چون RFC 7946 این کار را نمی‌کند.

GeoJSON کجا ظاهر می‌شود

وقتی شروع به دیدن کنید، GeoJSON همه‌جا در stack ژئوفضایی است:

• کتابخانه‌های نقشه: MapLibre GL، Mapbox GL، Leaflet و OpenLayers همه GeoJSON را به‌عنوان یک منبع داده برای لایه‌ها به طور بومی مصرف می‌کنند
• پایپ‌لاین‌های vector tile: ابزارهایی مثل Tippecanoe GeoJSON می‌گیرند و مجموعه‌های MVT (Mapbox Vector Tile) خروجی می‌دهند
• Spec های map style: Mapbox Style Specification که توسط MapLibre استفاده می‌شود، GeoJSON را به‌عنوان یک نوع منبع درجه یک ارجاع می‌دهد
• پایگاه‌های داده مکانی: PostGIS، BigQuery GIS و Snowflake همه GeoJSON را از طریق توابع اختصاصی import و export می‌کنند
• خروجی‌های API: بیشتر API های geocoding، isochrone و routing مدرن نتایج را به‌عنوان Feature های GeoJSON برمی‌گردانند، تا پاسخ بتواند مستقیم روی نقشه انداخته شود
• Polyline های مسیر: پاسخ‌های ناوبری معمولاً یک هندسه LineString برای مسیر شامل می‌شوند، آماده برای رندر
• اشتراک‌گذاری داده: پورتال‌های open data، export های OpenStreetMap و انتشارهای مرز دولتی وقتی هدفشان کاربران وب است به طور پیش‌فرض GeoJSON استفاده می‌کنند

اگر یک ابزار اصلاً بتواند یک فرمت ژئوفضایی صحبت کند، تقریباً مطمئناً GeoJSON صحبت می‌کند.

دام‌ها در محصول واقعی

GeoJSON در روز اول بخشنده است و در روز نودم سختگیر. تله‌هایی که تیم‌ها را می‌گیرند:

Longitude اول. RFC 7946 ترتیب را به‌عنوان [lon, lat] ثابت می‌کند. انسان‌ها، آدرس‌ها و بیشتر مستندات lat, lon می‌نویسند. عوض کردنشان رایج‌ترین باگ GeoJSON است، و نقطه شما در اقیانوس اشتباه فرود می‌آید.

ترتیب winding چندضلعی. RFC 7946 مشخص می‌کند که حلقه‌های بیرونی باید پادساعتگرد باشند و حلقه‌های داخلی (سوراخ‌ها) ساعتگرد. بسیاری از فایل‌های GeoJSON قدیمی این را نادیده می‌گیرند. برخی renderer ها اهمیت نمی‌دهند، برخی دیگر (به‌ویژه Mapbox GL با چندضلعی‌های عبوری از خط نصف‌النهار) چندضلعی را به‌صورت معکوس آنچه می‌خواستید رندر می‌کنند: یک جزیره کوچک به یک سوراخ در اقیانوس تبدیل می‌شود که بقیه دنیا را پوشش می‌دهد.

مدیریت antimeridian. هندسه‌ای که از نصف‌النهار 180/-180 می‌گذرد باید طبق spec تقسیم شود. چندضلعی‌های ساده‌ای که از روی اقیانوس آرام کشیده شده‌اند به صورت یک نوار باریک که از مسیر طولانی دور سیاره پیچیده رندر می‌شوند.

عدم پشتیبانی native CRS فراتر از WGS84. RFC 7946 عمداً عضو قدیمی‌تر crs را حذف کرد. اگر داده شما در یک grid ملی است (British National Grid، RD New، EPSG:3857)، باید قبل از serialise کردن به WGS84 reproject کنید. ابزارهایی که GeoJSON غیر WGS84 منتشر می‌کنند از نظر فنی غیرمنطبق هستند.

اندازه فایل. یک FeatureCollection با میلیون‌ها چندضلعی جزئی می‌تواند به گیگابایت برسد. برای تحویل به browser، به vector tile ها سوئیچ کنید، هندسه را با Douglas-Peucker ساده کنید، یا با newline-delimited GeoJSON (.ndjson) stream کنید.

اعتبارسنجی. از یک linter مثل GeoJSONLint یا کتابخانه geojson-validation در CI استفاده کنید. گرفتن ترتیب winding نامعتبر یا مختصات عوض‌شده در زمان build ارزان‌تر از گرفتنش از یک تیکت مشتری است.

GeoJSON در MapAtlas

GeoJSON فرمت پیش‌فرض تبادل داده در سراسر پلتفرم MapAtlas است. محصول Dynamic Maps منابع GeoJSON را مستقیماً برای overlay های سفارشی، استایل‌دهی و لایه‌های تعاملی می‌پذیرد، بدون نیاز به پیش‌پردازش.

Geocoding API آدرس‌های match شده را به‌عنوان Feature های GeoJSON برمی‌گرداند، تا نتیجه یک forward geocode بتواند مستقیم روی نقشه انداخته شود یا در PostGIS بدون remap فیلدها ذخیره شود. Isochrone API مناطق زمان سفر را به‌عنوان چندضلعی‌های GeoJSON برمی‌گرداند، که یعنی یک کوئری "مکان‌های قابل دسترسی در ۱۵ دقیقه" یک fetch و یک فراخوانی addSource با صفحه فاصله دارد.

GeoJSON جذاب نیست. یک زیرمجموعه کوچک و عقیده‌مند از JSON با ترتیب مختصات ثابت و چند نوع هندسه است. اما همان فرمتی است که به هر لایه از یک stack مکان مدرن، از پایگاه داده مکانی تا canvas نقشه، اجازه می‌دهد روی این توافق کنند که یک مکان چیست. ترتیب longitude را درست بگیرید، winding را اعتبارسنجی کنید، و بقیه stack تمایل دارد خودش را مدیریت کند.