سامانه وب GIS، بستری است که داده‌های مکانی سازمان را از پایگاه داده تا مرورگر کاربر، در یک زنجیره پیوسته در دسترس قرار می‌دهد. طراحی چنین سامانه‌ای با انتخاب یک کتابخانه نقشه آغاز نمی‌شود، بلکه از معماری داده و لایه سرویس شروع می‌گردد و به تجربه کاربر و راهبرد انتشار ختم می‌شود. یک سامانه وب GIS کارآمد باید جست‌وجوی سریع، نمایش روان لایه‌های سنگین و کنترل دسترسی نقش‌محور را با هم فراهم کند. در بسیاری از پروژه‌ها، سامانه باید روی زیرساخت محدود و حتی یک سرور واحد پاسخ‌گو بماند. در این صفحه اجزای معماری و تصمیم‌های کلیدی چنین سامانه‌ای بررسی می‌شود.
معماری کلی و انتخاب فناوری
معماری متعارف این سامانه‌ها از چهار لایه ساخته می‌شود: پایگاه داده مکانی، لایه سرویس، لایه کاشی و واسط کاربر. جداسازی این لایه‌ها سبب می‌شود تغییر در ابزار نقشه سمت کاربر نیازمند بازنویسی منطق داده نباشد.
انتخاب فناوری باید بر پایه حجم داده، شمار کاربران همزمان و نیاز به تحلیل سمت سرور انجام شود، نه بر پایه محبوبیت ابزار. برای پروژه‌های کوچک و متوسط، مجموعه‌ای سبک از یک پایگاه داده مکانی و یک سرویس‌دهنده نقشه کافی است.
طراحی باید از آغاز برای رشد آماده باشد: افزودن لایه جدید، نقش کاربری تازه یا سرویس تازه نباید مستلزم بازطراحی شود.
- پایگاه داده مکانی برای نگه‌داری بردارها، صفت‌ها و فراداده.
- سرویس‌دهنده برای انتشار لایه‌ها بر پایه استانداردهای OGC.
- لایه کاشی برای نمایش سریع و مقیاس‌پذیر داده پرحجم.
- واسط وب برای نمایش، جست‌وجو و ویرایش داده.
پایگاه داده مکانی و نمایه‌سازی
ستون فقرات سامانه، پایگاه داده مکانی است. نگه‌داری هندسه و صفت در یک پایگاه داده رابطه‌ای با افزونه مکانی، امکان پرس‌وجوی ترکیبی و اعمال قواعد توپولوژیک را فراهم می‌کند و از پراکندگی داده در فایل‌های پراکنده جلوگیری می‌نماید.
نمایه مکانی برای پاسخ‌گویی سریع ضروری است؛ بدون آن، پرس‌وجوهای محدوده‌ای روی داده سنگین به کندی می‌انجامد. نرمال‌سازی جدول‌ها و تعریف کلیدهای پیوند، از تکرار داده و ناسازگاری جلوگیری می‌کند.
قواعد توپولوژیک و صحت‌سنجی هندسه باید در سطح پایگاه داده سنجیده شوند تا داده ورودی نامعتبر پیش از رسیدن به لایه نمایش پالایش شود.
لایه سرویس و رابط برنامه‌نویسی
لایه سرویس، واسط میان داده و مصرف‌کننده‌هاست. انتشار برداری با WFS، انتشار تصویری و نقشه‌ای با WMS و WMTS، و تحویل داده رستری خام با WCS، الگوی استاندارد دسترسی به داده مکانی را تشکیل می‌دهند.
در کنار سرویس‌های استاندارد، یک رابط برنامه‌نویسی اختصاصی برای منطق کاربردی سامانه لازم است. قالب داده‌ای سبک مانند GeoJSON برای تعامل‌های کوچک و پاسخ‌های API مناسب است، در حالی که برای داده سنگین باید از کاشی یا فایل‌های برداری‌شده بهره برد.
قرارداد API باید پایدار و مستند باشد تا امکان توسعه اپلیکیشن موبایل یا سامانه‌های جانبی روی همان منطق فراهم شود و منطق داده در چند جا تکرار نگردد.
کاشی‌های برداری و راهبرد انباره موقت
کاشی‌های برداری، داده را در چند سطح بزرگ‌نمایی و به شکل آماده نمایش تحویل می‌دهند؛ در نتیجه حجم انتقال و بار پردازش سمت مرورگر کاهش می‌یابد. این روش برای لایه‌های پرتراکم شهری رفتار روان‌تری از ارسال مستقیم GeoJSON دارد.
انباره موقت (caching) پاسخ سرویس‌ها را ذخیره می‌کند و بار پایگاه داده را در درخواست‌های تکرارشونده کاهش می‌دهد. تعیین سطح‌های مجاز کاشی و مدت اعتبار انباره، هم تازگی داده و هم سرعت را متعادل می‌کند.
برای داده‌هایی که تغییر مکرر دارند، بهتر است انباره بر پایه زمان یا رویداد به‌روزرسانی شود تا کاربر داده کهنه نبیند.
نقشه در سمت کاربر و تجربه تعامل
انتخاب کتابخانه نقشه سمت کاربر بر پایه نیاز تعاملی انجام می‌شود. کتابخانه‌های سبک برای نقشه‌های دوبعدی و تعامل سریع مناسب‌اند و کتابخانه‌های سه‌بعدی برای نمایش مدل‌های حجمی و تحلیل‌های فضایی کاربرد دارند.
طراحی تجربه کاربر باید از پرسش واقعی کاربر آغاز شود: جست‌وجوی یک عارضه، پیمایش محدوده، اندازه‌گیری و در نهایت اقدام روی رکورد. لایه‌های پایه و پوشش‌ها باید به شکل کنترل‌شده و با نام‌گذاری روشن نمایش داده شوند.
واکنش‌گرایی و دسترس‌پذیری نیز بخشی از طراحی است، به‌ویژه اگر کاربران از تبلت در عملیات میدانی استفاده کنند.
- ابزار اندازه‌گیری فاصله، مساحت و در صورت نیاز حجم و پروفیل.
- ابزار انتخاب، شناسایی و بررسی صفت‌های هر عارضه.
- کنترل وضعیت لایه‌ها و ذخیره‌سازی نمای مورد علاقه کاربر.
جست‌وجو، پالایش و داشبورد
جست‌وجو در سامانه‌های مکانی دو صورت دارد: جست‌وجوی مکانی بر پایه نقطه، محدوده یا همجواری، و جست‌وجوی توصیفی بر پایه صفت‌ها. ترکیب این دو، پرسش‌هایی مانند یافتن همه رکوردهای یک رده در یک محدوده مشخص را ممکن می‌سازد.
داشبوردها داده مکانی را به شاخص‌های قابل خواندن تبدیل می‌کنند و گزارش‌گیری خروجی رسمی سامانه است. تولید خروجی در قالب‌های رایج مانند PDF، فایل جدولی و فایل مکانی، نیاز کاربران اداری را برآورده می‌کند.
در طراحی داشبورد باید از نمایش‌های پرجزئیات و بدون پیام پرهیز شود؛ هر نمودار باید به یک تصمیم یا پرسش مشخص پاسخ دهد.
احراز هویت، نقش‌ها و کارایی زیر بار
کنترل دسترسی نقش‌محور تعیین می‌کند هر کاربر چه داده‌ای را می‌بیند و چه اقداماتی انجام می‌دهد. احراز هویت توکن‌محور برای سامانه‌هایی که هم اپ موبایل و هم داشبورد وب دارند، الگوی ساده و کارآمدی است.
کارایی سامانه به سه عامل وابسته است: نمایه مکانی، اندازه پاسخ و راهبرد انباره. محدود کردن تعداد عوارض بازگشتی و استفاده از کاشی به جای پاسخ‌های یک‌باره، پایدارترین اثر را دارد.
برای کاربران با باند کم یا اتصال ناپایدار، کاهش حجم تصاویر پایه، امکان ذخیره‌سازی موقت سمت مرورگر و ارسال سبک داده اهمیت دارد. سامانه باید روی یک سرور واحد نیز با تنظیم درست منابع، پاسخ‌گوی بار متعارف باشد.
جمع‌بندی
طراحی سامانه وب GIS، پرسشی درباره معماری است: پایگاه داده منظم، لایه سرویس روشن، راهبرد کاشی و انباره کارآمد، و واسط کاربری که با پرسش واقعی کاربر همخوان باشد. هر یک از این لایه‌ها بر کارایی لایه دیگر اثر می‌گذارد.
توصیه می‌شود نمایه مکانی و قواعد توپولوژیک جدی گرفته شود، API پایدار و مستند ارائه گردد و کنترل دسترسی از آغاز در طراحی لحاظ شود. رعایت این اصول، سامانه را از یک نمایشگر نقشه به بستر عملیاتی سازمان تبدیل می‌کند.
در نهایت، سامانه‌ای که روی زیرساخت محدود نیز پاسخ‌گوی کار روزمره باشد، ارزش عملی بیشتری از سامانه‌ای پرجزئیات اما شکننده دارد.