طراحی سامانه‌های هوشمند مکانی، تبدیل داده و تحلیل به خدمتی است که کاربر نهایی بتواند روزانه بر آن تکیه کند. در این خط خدمتی، کار از تحلیل نیاز آغاز می‌شود و با تعریف معماری، بانک اطلاعاتی مکانی، موتور پردازش، لایه سرویس و رابط کاربری ادامه می‌یابد. هدف آن است که سامانه‌ای ساخته شود که داده‌ی کارفرما را در یک چارچوب مکانی یکسان بپذیرد، پردازش‌های سنگین را به‌صورت کنترل‌شده اجرا کند و خروجی خود را در قالب خدمات استاندارد به کاربر برساند. در این صفحه مؤلفه‌های اصلی معماری، تصمیم‌های فنی رایج، سازوکار احراز هویت و نقش‌ها، کار میدانی آفلاین و جایگاه مدل‌های هوش مصنوعی و ارزیابی آن‌ها تشریح می‌شود. نقش داده‌ی برچسب‌خورده به‌عنوان عاملی تعیین‌کننده در کیفیت مدل نیز صریح بیان می‌گردد.
تحلیل نیاز و تدوین دامنه کار
نخستین گام، تبدیل خواسته‌ی کلی کارفرما به فهرستی از پرسش‌های عملیاتی است. برای این کار فرایند کنونی کار، نقش‌ها و مسئولیت‌ها، داده‌های موجود، محدودیت‌های سازمانی و شکل تصمیمی که باید پشتیبانی شود بررسی می‌گردد. خروجی این مرحله، سندی است که دامنه‌ی کار، کاربران سامانه، ورودی‌ها و خروجی‌های مورد انتظار را روشن می‌کند.
در تحلیل نیاز، معیارهای پذیرش نیز تعریف می‌شوند تا در پایان کار بتوان درباره‌ی تحقق آن‌ها داوری کرد. این معیارها می‌توانند زمان پاسخ یک پرس‌وجوی مکانی، شمار کاربران همزمان، دقت نمایش‌ی لایه‌ها یا سطح دسترسی هر نقش باشند. تعریف روشن این معیارها پیش از شروع پیاده‌سازی، از تغییر مکرر دامنه جلوگیری می‌کند.
بخشی از تحلیل نیاز به کیفیت داده اختصاص دارد: بررسی اینکه داده‌های موجود کارفرما در چه سامانه‌ی مختصاتی ثبت شده‌اند، چه سطحی از دقت و کامل بودن دارند و چه میزان آماده‌سازی برای ورود به سامانه لازم است. بسیاری از تأخیرهای پروژه از همین موضوع ناشی می‌شود، نه از بخش نرم‌افزاری.
- فهرست کاربران، نقش‌ها و کارکردی که هر گروه باید در سامانه انجام دهد.
- فهرست داده‌های ورودی، منبع، فرمت و مسئول تأمین هر داده.
- معیارهای پذیرش قابل سنجش برای کارکردهای کلیدی سامانه.
- تفکیک صریح آنچه در دامنه‌ی این مرحله است از آنچه بیرون آن می‌ماند.
معماری سامانه و انتخاب مؤلفه‌ها
معماری معمول این سامانه‌ها لایه‌ای است و از چهار بخش اصلی تشکیل می‌شود: بانک اطلاعاتی مکانی، موتور پردازش، لایه سرویس و رابط کاربری. جدا نگه‌داشتن این لایه‌ها به این معناست که تغییر در رابط کاربری یا افزودن یک موتور پردازش تازه، نیازمند بازنویسی کل سامانه نیست. ارتباط لایه‌ها از طریق واسط‌های مشخص انجام می‌شود تا هر بخش مستقل از دیگری قابل آزمون و جایگزینی باشد.
انتخاب فناوری بر پایه‌ی نیاز واقعی سامانه انجام می‌شود، نه بر پایه‌ی تازگی ابزار. برای سامانه‌هایی که با حجم زیاد داده‌ی مکانی و نوشت و خواندن همزمان سروکار دارند، پایگاه‌داده‌ی رابطهای با افزونه‌ی مکانی مانند PostgreSQL و PostGIS گزینه‌ی متعارفی است. سبک‌سازی مؤلفه‌ها، ثبت رویداد و پایش وضعیت سامانه نیز از ابتدا در معماری دیده می‌شود.
طراحی باید توان رشد را در نظر بگیرد: جدا کردن پردازش‌های سنگین از مسیر پاسخ‌گویی، امکان افزودن گره‌های پردازش و تعریف صف کار برای کارهای زمان‌بر. همچنین تعیین می‌شود که کدام داده در سمت سرور پردازش می‌شود و کدام بخش به سمت مرورگر یا اپلیکیشن منتقل می‌گردد.
بانک اطلاعاتی مکانی و موتورهای پردازش
بانک اطلاعاتی مکانی قلب سامانه است. طراحی آن با مدل‌سازی داده آغاز می‌شود: تعیین اینکه هر عارضه در چه جدولی ذخیره می‌شود، چه صفت‌هایی دارد، روابط میان جدول‌ها چیست و کدام قواعد یکپارچگی باید برقرار باشد. تعریف قواعد توپولوژی و اعتبارسنجی هندسه در همین مرحله انجام می‌شود تا داده‌ی ناسازگار وارد سامانه نشود.
نمایه‌گذاری مکانی نقش کلیدی در سرعت پرس‌وجوها دارد؛ بدون آن، جست‌وجوهای مکانی روی جدول‌های بزرگ کند می‌شود. برای داده‌های حجیم نیز راهبردهایی مانند تقسیم جدول‌ها، تولید نسخه‌های کاشی‌بندی‌شده و ذخیره‌سازی موقت نتیجه‌ها به کار می‌رود.
موتور پردازش، لایه‌ای است که داده‌ی خام و لایه‌های موجود را به خروجی‌های اطلاعاتی تبدیل می‌کند. این موتور می‌تواند شامل زنجیره‌ای از پالایش‌ها، اجرای شاخص‌های طیفی، تحلیل‌های مکانی، طبقه‌بندی یا اجرای مدل‌های یادگیری ماشین باشد. پردازش‌های زمان‌بر در صف کار اجرا می‌شوند و وضعیت پیشرفت آن‌ها برای کاربر قابل پیگیری است.
- مدل‌سازی داده و تعریف قواعد توپولوژی و یکپارچگی.
- نمایه‌گذاری مکانی و راهبردهای مدیریت حجم داده.
- طراحی زنجیره‌ی پردازش و صف کار برای اجرای کارهای سنگین.
- ثبت لاگ اجرا و امکان بازتولید یک پردازش با همان پارامترها.
لایه سرویس: استانداردهای OGC و API
لایه سرویس، مکانیزم انتشار داده و کارکرد سامانه است. برای انتشار لایه‌های مکانی، خدمات استاندارد OGC به کار می‌رود: WMS برای تصویر نقشه، WMTS برای کاشی‌های آماده، WFS برای عارضه‌های برداری و WCS برای داده‌های رستری. انتخاب میان این خدمات بر پایه‌ی نوع مصرف انجام می‌شود؛ نمایش سریع نقشه با کاشی، و دسترسی تحلیلی و ویرایشی با عارضه‌های برداری.
در کنار خدمات استاندارد، رابطهای برنامه‌نویسی کاربردی برای کارکردهای اختصاصی سامانه طراحی می‌شود تا اپلیکیشن‌های موبایل، داشبوردها و سامانه‌های دیگر سازمان بتوانند با سامانه کار کنند. طراحی این رابط‌ها بر پایه‌ی اصول روشن انجام می‌شود: تفکیک منابع، پاسخ‌های ساختاریافته مانند GeoJSON، کدهای وضعیت استاندارد و نسخه‌بندی برای جلوگیری از شکستن یکپارچگی در آینده.
سرورهای نقشه مانند GeoServer یا MapServer می‌توانند نقش واسط میان بانک اطلاعاتی و خدمات استاندارد را ایفا کنند. انتخاب میان آن‌ها و پیاده‌سازی مستقیم سرویس، تابعی از حجم درخواست‌ها، نیاز به کش و سطح کنترل دسترسی است.
رابط کاربری وب، مدل سه‌بعدی و کاشی‌ها
رابط کاربری تعیین می‌کند که سامانه تا چه اندازه در کار روزمره پذیرفته می‌شود. برای سامانه‌های دوبعدی، کتابخانه‌هایی مانند Leaflet و OpenLayers به کار می‌رود و برای نمایش سه‌بعدی و مدل‌سازی شهری، CesiumJS گزینه‌ی متعارفی است. انتخاب کتابخانه با معیار اندازه‌ی داده، نوع تحلیل و پیچیدگی نمایش انجام می‌شود.
برای روان بودن نمایش، داده به کاشی‌های برداری و کاشی‌های سه‌بعدی تبدیل می‌شود تا مرورگر تنها بخش دیده‌شده را بارگذاری کند. در کاربردهای سه‌بعدی، قالب‌هایی مانند 3D Tiles و مدل‌سازی داده بر پایه‌ی CityGML برای نمایش و تحلیل حجم‌های شهری به کار می‌آید.
سطح نمایش نقشمحور است: برخی کاربران تنها به مشاهده و جست‌وجو نیاز دارند، برخی باید ویرایش انجام دهند و گروهی دیگر گزارش و آمار می‌خواهند. رابط کاربری برای هر گروه به‌صورت جداگانه طراحی می‌شود تا پیچیدگی غیرلازم به همه‌ی کاربران تحمیل نشود.
- نمایش دوبعدی با Leaflet و OpenLayers، و نمایش سه‌بعدی با CesiumJS.
- تبدیل داده به کاشی‌های برداری و سه‌بعدی برای بارگذاری تکه‌ای.
- طراحی نقشمحور رابط کاربری به‌تناسب وظیفه‌ی هر گروه.
- ابزارهای اندازه‌گیری و پرس‌وجوی مکانی در همان بستر نمایش.
احراز هویت، نقش‌ها و کار میدانی آفلاین
کنترل دسترسی در سامانه‌های سازمانی از ابتدا طراحی می‌شود. احراز هویت می‌تواند با نام کاربری و گذرواژه، توکن‌های امضاشده یا اتصال به سرویس‌های هویت سازمانی انجام شود. در معماری مبتنی بر توکن، هر درخواست به API همراه توکن معتبر فرستاده می‌شود و سمت سرور اختیار کاربر بررسی می‌گردد.
نقش‌ها تعیین می‌کنند که چه کسی چه کاری می‌تواند انجام دهد: مشاهده، ویرایش، تأیید، صدور گزارش یا مدیریت کاربران. سطح دسترسی می‌تواند به لایه‌های جغرافیایی نیز بسته شود تا هر کاربر تنها داده‌ی مرتبط با محدوده‌ی مسئولیت خود را ببیند. ثبت رویداد اقدامات کاربران برای پیگیری تغییرات ضروری است.
در کار میدانی، دسترسی به شبکه‌ای مطمئن همیشه برقرار نیست؛ بنابراین اپلیکیشن میدانی با رویکرد آفلاین‌محور طراحی می‌شود. داده‌ی پایه‌ی مورد نیاز به شکل محلی ذخیره می‌گردد، ثبت‌های میدانی همراه عکس و موقعیت مکانی در نبود شبکه در حافظه‌ی دستگاه می‌ماند و پس از برقراری اتصال، همگام‌سازی و رفع تعارض انجام می‌شود. تعریف رفتار سامانه در حالت تعارض داده‌ی محلی و سروری بخشی از طراحی است.
هوش مصنوعی مکانی، داده‌ی برچسب‌خورده و ارزیابی مدل
در بخش هوشمندسازی، کارکردهایی مانند بخش‌بندی معنایی تصویر، تشخیص شیء و طبقه‌بندی تصویری به کار می‌رود. بخش‌بندی معنایی هر پیکسل را به یک کلاس نسبت می‌دهد، تشخیص شیء چارچوب و کلاس هر عارضه را بازمی‌گرداند و طبقه‌بندی، کل تصویر یا قطعه را به یک دسته تخصیص می‌دهد. انتخاب میان این‌ها به شکل پرسش کارفرما وابسته است.
کیفیت این مدل‌ها پیش از هر چیز به داده‌ی برچسب‌خورده وابسته است، نه تنها به معماری شبکه. تعیین حجم و تنوع داده‌ی آموزش، یکنواخت بودن برچسب‌گذاری و پوشش کلاس‌هایی که در عمل دیده می‌شوند، بخش اصلی کار است. این موضوع باید از ابتدا با کارفرما روشن شود تا انتظار از دقت مدل واقع‌بینانه تنظیم گردد.
ارزیابی مدل با سنجه‌های کمی انجام می‌شود: دقت و فراخوانی، معیار F۱، و برای بخش‌بندی، همپوشانی سطحی یا IoU. مجموعه‌ی آزمون باید از داده‌ی آموزش جدا باشد و در صورت امکان، از محدوده‌ای متفاوت انتخاب شود تا نتیجه‌ی ارزیابی خوش‌بینانه نباشد. گزارش روش آموزش، نسخه‌ی مدل و محدودیت‌های کاربرد آن بخشی از تحویل است.
- تعریف کارکرد هوشمند بر پایه‌ی پرسش عملیاتی، نه نوع مدل.
- تعیین الزامات داده‌ی برچسب‌خورده و روش برچسب‌گذاری پیش از آموزش.
- ارزیابی با سنجه‌های دقت، فراخوانی، F۱ و IoU روی مجموعه‌ی آزمون مستقل.
- اعلام صریح وابستگی کیفیت مدل به داده‌ی برچسب‌خورده.
جمع‌بندی
طراحی سامانه‌های هوشمند مکانی، پیش از آنکه کار برنامه‌نویسی باشد، کار تصمیم‌گیری معماری است: تعریف دقیق نیاز، جدا کردن لایه‌ها، طراحی درست بانک اطلاعاتی مکانی و روشن ساختن مسیر سرویس‌دهی. سامانه‌ای که بر این پایه ساخته شود، پذیرش داده‌ی تازه و افزودن کارکرد را بدون بازنویسی ممکن می‌کند.
خروجی این خط خدمتی می‌تواند سامانه‌های WEB GIS، سامانه‌های سنجش از دوری، موتورهای هوشمند پردازش و رابطهای کاربری وب یا موبایل باشد، بسته به نیاز کارفرما. در همه‌ی حالت‌ها، سند معماری، مدل داده، مستندات سرویس و گزارش ارزیابی بخشی از تحویل است.
برای آغاز کار، مشخص کردن فرایند کنونی، نقش‌های کاربری، داده‌های موجود و معیارهای پذیرش کافی است؛ بر همین پایه می‌توان معماری، فهرست مؤلفه‌ها و برنامه‌ی اجرا را تدوین کرد.