طراحی داشبورد GIS از تصمیم شروع می‌شود
طراحی داشبورد GIS زمانی موفق است که یک تصمیم مشخص را آسان کند. نمایش نقشه، نمودار و عدد به تنهایی هدف مناسبی برای پروژه نیست. مدیر خدمات شهری ممکن است بخواهد بداند کدام محله به اعزام گروه عملیاتی نیاز دارد؛ کارشناس شبکه آب ممکن است روند خرابی‌ها را دنبال کند. این دو مخاطب به شاخص‌ها و جزئیات یکسان نیاز ندارند. پیش از انتخاب نرم‌افزار، پرسش اصلی، دوره زمانی و اقدام پس از مشاهده نتیجه را بنویسید. سپس مشخص کنید کدام داده برای پاسخ ضروری است و چه کسی مسئول به‌روزرسانی آن خواهد بود. داشبورد باید زنجیره‌ای روشن از داده تا تصمیم داشته باشد. اگر عددی هیچ تصمیمی را تغییر نمی‌دهد، حضور آن در صفحه اصلی نیاز به بازنگری دارد.
شناخت مخاطب و سناریوی استفاده
با چند کاربر واقعی گفت‌وگو کنید و از آنها بخواهید یک روز کاری معمول را توضیح دهند. پرسش‌های کلی مانند «چه نموداری دوست دارید» معمولاً به فهرستی بلند و متناقض می‌رسند. بهتر است بپرسید آخرین بار برای یافتن یک مشکل چه گزارش‌هایی را باز کردند و کدام اطلاعات دیر به دستشان رسید. کاربران عملیاتی به جزئیات رکورد نیاز دارند، در حالی که مدیران غالباً روند، استثنا و وضعیت کلی را می‌خواهند. برای هر گروه یک سناریوی کوتاه بنویسید: انتخاب منطقه، مشاهده موارد عقب‌افتاده و بررسی محل آنها. این سناریو بعداً مبنای آزمون خواهد بود. راهنمای نیازسنجی GIS می‌تواند به تعیین دامنه و اولویت‌های این مرحله کمک کند.
تفاوت داشبورد با یک نقشه شلوغ
نقشه برای دیدن الگوی مکانی مناسب است، اما همیشه بهترین ابزار مقایسه اعداد نیست. کاربر ممکن است با یک نمودار میله‌ای سریع‌تر بفهمد کدام منطقه بیشترین درخواست را دارد. داشبورد ترکیبی از نمایش‌های مکمل است که هر کدام پرسشی مشخص را پاسخ می‌دهند. قرار دادن همه لایه‌های سازمان در یک نقشه معمولاً خوانایی را کاهش می‌دهد و زمان بارگذاری را بالا می‌برد. فقط لایه‌هایی را نگه دارید که در سناریوی جاری کاربرد دارند. اطلاعات جزئی را در پنجره رکورد یا صفحه تکمیلی قرار دهید. درباره تعداد اجزا قانون ثابت وجود ندارد؛ معیار مناسب، توان کاربر در یافتن پاسخ بدون حدس و سردرگمی است. نمونه اولیه ساده معمولاً فرصت بهتری برای اصلاح منطق نمایش فراهم می‌کند.
واحد شمارش را دقیق تعریف کنید
عدد «تعداد درخواست‌ها» ممکن است تعداد ردیف‌ها، پرونده‌های یکتا، تماس‌ها یا رخدادهای مکانی را نشان دهد. این تعریف باید پیش از ساخت شاخص روشن شود. اگر یک درخواست در چند مرحله ثبت شده باشد، شمارش ردیف‌ها حجم فعالیت را بیش از واقع نشان می‌دهد. برای هر شاخص یک شناسنامه تهیه کنید: نام، تعریف، واحد، منبع، روش تجمیع و محدودیت. عبارت «پرونده‌های یکتا ثبت‌شده در ماه جاری» از عنوان مبهم «عملکرد ماه» قابل فهم‌تر است. هنگام اتصال جدول‌ها نیز بررسی کنید رابطه یک به چند باعث تکثیر رکورد نشده باشد. مطلب تفاوت Join و Relate و Spatial Join برای شناخت این مسئله مفید است. تعریف شاخص را کنار داده نگه دارید تا تغییر نیروی انسانی منطق گزارش را از بین نبرد.
شناسه پایدار و رکوردهای تکراری
هر موجودیت اصلی باید شناسه‌ای داشته باشد که با مرتب‌سازی یا تغییر نام عوض نشود. نام محله یا آدرس معمولاً شناسه مطمئنی نیست، زیرا ممکن است چند شکل نوشتاری داشته باشد. شناسه پایدار امکان اتصال تاریخچه، پیگیری اصلاح و جلوگیری از شمارش تکراری را فراهم می‌کند. پیش از انتشار داشبورد، تکرار شناسه‌ها و رکوردهای بدون شناسه را بررسی کنید. موارد تکراری را با قاعده مستند حل کنید؛ حذف خودکار ردیف‌های مشابه ممکن است رخدادهای واقعی را از بین ببرد. اگر چند سامانه ورودی وجود دارد، روش تطبیق شناسه‌های آنها را مشخص کنید. طراحی درست ژئودیتابیس از بسیاری از مشکلات گزارش‌گیری جلوگیری می‌کند. داشبورد ظاهر داده را بهتر می‌کند، اما خطاهای ساختاری منبع را به صورت خودکار اصلاح نمی‌کند.
تاریخ ثبت، تاریخ وقوع و تاریخ پایان
یک پرونده می‌تواند تاریخ وقوع، ثبت، شروع رسیدگی و پایان داشته باشد. انتخاب هر کدام نتیجه نمودار زمانی را تغییر می‌دهد. برای مثال، رخدادهای آخر ماه ممکن است در ماه بعد ثبت شوند؛ نمودار ثبت و نمودار وقوع رفتار متفاوتی نشان خواهند داد. عنوان و توضیح نمودار باید روشن کند کدام تاریخ مبنای تحلیل است. تقویم نمایش فارسی را از مقدار زمانی ذخیره‌شده جدا در نظر بگیرید و تبدیل‌ها را با نمونه‌های معلوم آزمایش کنید. ساعت محلی و منطقه زمانی نیز در گزارش‌های روزانه اهمیت دارند. درباره پرونده‌های فاقد تاریخ قاعده مشخص داشته باشید. حذف بی‌توضیح آنها ممکن است نتیجه را منحرف کند. مرز شروع و پایان دوره باید در همه اجزای مرتبط یکسان باشد تا عدد کارت و نمودار با هم سازگار بمانند.
تعداد خام یا نرخ؟ انتخاب مخرج مناسب
منطقه پرجمعیت معمولاً درخواست بیشتری دارد، اما این الزاماً به معنای وضعیت ضعیف‌تر نیست. گاهی نرخ درخواست به جمعیت، طول شبکه یا تعداد مشترکان مقایسه منصفانه‌تری فراهم می‌کند. انتخاب مخرج باید با مسئله مرتبط باشد؛ استفاده از جمعیت برای خرابی یک شبکه صنعتی ممکن است مناسب نباشد. تاریخ و محدوده مخرج را با صورت شاخص هماهنگ کنید. اگر داده جمعیت چند سال قدیمی است، محدودیت را بیان کنید. در مخرج صفر یا ناموجود، نرخ را نامشخص نمایش دهید و از تولید عدد گمراه‌کننده جلوگیری کنید. بهتر است تعداد خام و نرخ در کنار هم قابل مشاهده باشند، چون هر کدام جنبه‌ای از مسئله را توضیح می‌دهند. تعریف دقیق نرخ به کاربران اجازه می‌دهد تفاوت میان حجم کار و شدت مسئله را بفهمند.
فیلترها و دامنه اثر آنها
فیلتر منطقه، بازه زمانی و نوع خدمت باید رفتار قابل پیش‌بینی داشته باشد. مشخص کنید هر فیلتر کدام نقشه، نمودار و شاخص را تغییر می‌دهد. اگر یک نمودار از فیلتر زمان پیروی نمی‌کند، آن را با برچسب واضح توضیح دهید. ترکیب فیلترها می‌تواند نتیجه‌ای بدون رکورد ایجاد کند؛ پیام روشن و امکان پاک کردن انتخاب‌ها ضروری است. برای بازه زمانی یک پیش‌فرض منطقی انتخاب کنید و تاریخ آن را قابل مشاهده نگه دارید. کاربر نباید حدس بزند عدد کارت متعلق به کل شهر است یا فقط محدوده انتخابی. انتخاب‌های فعال را در بالای صفحه یا نزدیک کنترل‌ها نمایش دهید. هنگام طراحی تعامل میان اجزا، ابتدا مسیر ساده را آزمایش کنید؛ واکنش‌های زنجیره‌ای زیاد ممکن است علت تغییر اعداد را برای کاربر نامعلوم کند.
ارتباط نقشه با شاخص‌ها
تغییر محدوده نقشه می‌تواند مبنای فیلتر باشد، اما باید معلوم باشد شاخص‌ها برای محدوده دید محاسبه می‌شوند یا برای منطقه اداری انتخاب‌شده. این دو رفتار یکسان نیستند. با جابه‌جایی کوچک نقشه، عدد وابسته به محدوده دید ممکن است تغییر کند و مقایسه روزهای مختلف دشوار شود. برای گزارش رسمی، محدوده ثابت و مشخص معمولاً تکرارپذیری بیشتری دارد. داده نقطه‌ای، خوشه‌بندی و نقشه تراکم نیز برداشت‌های متفاوتی ایجاد می‌کنند. خوشه نشان‌دهنده شمار رکوردهای نزدیک است و نباید بدون توضیح به عنوان مرز مسئله تفسیر شود. مقیاس نمایش و توضیح علائم را کنترل کنید. برای سازگاری موقعیت لایه‌ها، راهنمای رفع مشکل سیستم مختصات در GIS را بررسی کنید.
نبود داده با صفر فرق دارد
صفر می‌تواند نشان دهد هیچ رخدادی ثبت نشده است؛ نبود داده ممکن است ناشی از قطع ارتباط، نقص جمع‌آوری یا حذف رکورد باشد. یک رنگ یا عدد یکسان برای این دو حالت برداشت اشتباه ایجاد می‌کند. در شاخص‌ها و نقشه‌ها وضعیت نامشخص را جدا نمایش دهید. اگر سامانه ورودی یک منطقه به‌روز نشده، تعداد کم آن منطقه را نشانه عملکرد بهتر معرفی نکنید. تاریخ آخرین داده معتبر می‌تواند کنار شاخص قرار گیرد. درباره داده ناقص، پیام کوتاه و کاربردی بنویسید که محدوده تأثیر را توضیح دهد. این پیام نباید با اصطلاحات مبهم پر شود. کاربران باید بدانند کدام بخش قابل اتکاست و برای کدام بخش لازم است اطلاعات بیشتری دریافت کنند. کیفیت داده بخشی از تجربه کاربری داشبورد است.
کنترل کیفیت پیش از نمایش
پیش از ساخت ظاهر، مختصات خارج از محدوده، تاریخ‌های نامعتبر، مقادیر منفی غیرمجاز و کدهای ناشناخته را بررسی کنید. قواعد کنترل باید به معنای فیلد وابسته باشند؛ مقدار منفی برای تغییر موجودی ممکن است درست باشد اما برای تعداد پرونده معتبر نیست. نمونه‌هایی از رکوردهای مسئله‌دار را همراه با دلیل نگه دارید و مسئول اصلاح را تعیین کنید. قواعد باید در فرایند ورود و به‌روزرسانی هم اجرا شوند، زیرا یک پاک‌سازی اولیه کافی نیست. از چک‌لیست کنترل کیفیت داده GIS برای ساخت برنامه بازبینی استفاده کنید. اگر مرز مناطق تغییر کرده است، تصمیم بگیرید تاریخچه با مرز زمان وقوع محاسبه می‌شود یا با مرز فعلی. این انتخاب بر مقایسه سالانه اثر مستقیم دارد.
نمودار مناسب و خوانایی
نمودار خطی برای روند زمانی، نمودار میله‌ای برای مقایسه گروه‌ها و جدول برای یافتن مقادیر دقیق کاربرد دارند. استفاده از نمودار تزئینی بدون پرسش روشن، بار ذهنی را افزایش می‌دهد. محور، واحد و مبنای زمانی را مشخص کنید. حذف بخشی از محور ممکن است اختلاف کوچک را بزرگ جلوه دهد؛ اگر این کار برای تحلیل لازم است، نمایش باید صریح باشد. رنگ‌ها را با معنای ثابت استفاده کنید و انتقال پیام را فقط به تفاوت قرمز و سبز وابسته نکنید. متن، علامت و ترتیب هم باید به تشخیص وضعیت کمک کنند. نوشته‌ها در نمایشگر کوچک باید خوانا بمانند. اصول طراحی نقشه و چیدمان در انتخاب سلسله‌مراتب بصری داشبورد نیز کاربرد دارد.
به‌روزرسانی و زمان اعتبار اطلاعات
عبارت «زنده» زمانی معنی دارد که فاصله ورود رخداد تا نمایش آن معلوم باشد. ممکن است صفحه هر دقیقه تازه شود اما سامانه منبع روزی یک بار داده دریافت کند. بنابراین زمان تازه‌سازی صفحه را با زمان تازگی داده اشتباه نگیرید. آخرین به‌روزرسانی موفق و دوره پوشش اطلاعات را نمایش دهید. اگر انتقال داده شکست خورد، نگهداری آخرین نسخه معتبر همراه با هشدار روشن می‌تواند بهتر از نمایش مجموعه ناقص باشد. مسئول نگهداری باید وضعیت ارتباط و حجم رکوردهای تازه را بررسی کند. افت ناگهانی تعداد داده گاهی نشانه خرابی فرایند انتقال است. برای گزارش‌های مدیریتی، ثبت نسخه یا تصویر داده در زمان گزارش به بازسازی نتیجه کمک می‌کند. سامانه قابل اعتماد باید رفتار خود در زمان تأخیر را هم تعریف کرده باشد.
کارایی و حجم داده
دانلود همه رکوردها برای هر بازدید همیشه ضرورت ندارد. اگر کاربر تنها مجموع مناطق را می‌خواهد، استفاده از داده تجمیع‌شده می‌تواند زمان پاسخ را کاهش دهد. با این حال، تجمیع باید تعریف شاخص و قابلیت فیلتر مورد نیاز را حفظ کند. لایه جزئیات را در زمان مناسب بارگذاری کنید و فیلدهای غیرضروری را در نمایش عمومی قرار ندهید. سرعت را با حجم واقعی داده و شرایط معمول اینترنت کاربران بررسی کنید. یک نمونه کوچک ممکن است مشکلات پروژه اصلی را نشان ندهد. میزان انتظار قابل قبول را برای سناریوی کاری تعیین کنید و خطای بارگذاری را با پیام روشن نمایش دهید. انتخاب معماری مناسب در طراحی و توسعه WebGIS باید به تعداد کاربران، الگوی به‌روزرسانی و نیاز تحلیل وابسته باشد.
نمونه عملی خدمات شهری
فرض کنید داشبوردی برای پیگیری درخواست تعمیر روشنایی طراحی می‌کنید. شاخص نخست می‌تواند تعداد درخواست‌های باز باشد، اما تعریف «باز» باید با وضعیت‌های سامانه هماهنگ شود. شاخص دوم زمان سپری‌شده از ثبت تا رسیدگی است؛ پرونده‌های هنوز بسته‌نشده را نباید بدون توضیح از تحلیل حذف کرد. نقشه محل درخواست‌ها به برنامه‌ریزی مسیر کمک می‌کند و نمودار منطقه‌ای حجم کار را نشان می‌دهد. برای مقایسه عملکرد، تفاوت تعداد تجهیزات هر منطقه را نیز بررسی کنید. یک منطقه با تجهیزات بیشتر ممکن است خرابی بیشتری ثبت کند. این مثال آموزشی است و هیچ عدد واقعی از شهر خاصی را گزارش نمی‌کند. خدمات GIS خدمات شهری باید بر فرایند واقعی سازمان و تعریف قابل سنجش خدمت بنا شوند.
آزمون با پاسخ‌های از پیش معلوم
برای آزمون داشبورد مجموعه کوچکی از رکوردها بسازید که جمع‌ها و وضعیت آنها را دستی می‌دانید. یک پرونده تکراری، تاریخ مرزی، مقدار ناموجود و منطقه بدون رکورد را در نمونه قرار دهید. سپس هر فیلتر را فعال کنید و عدد کارت، نمودار و نقشه را با پاسخ مورد انتظار مقایسه کنید. آزمون فقط مشاهده ظاهر نیست؛ باید منطق تجمیع و اتصال‌ها را هم بررسی کند. کاربر واقعی نیز سناریوی اصلی را اجرا کند و نقاط ابهام را توضیح دهد. پس از تغییر منبع داده یا تعریف شاخص، آزمون‌های مرتبط را تکرار کنید. برای مدل‌های پیش‌بینی در داشبورد، راهنمای اعتبارسنجی مکانی یادگیری ماشین یادآوری می‌کند که نمودار زیبا جای ارزیابی مستقل مدل را نمی‌گیرد.
تحویل، مستندسازی و مسئولیت نگهداری
تحویل داشبورد فقط ارسال یک نشانی نیست. فهرست منابع داده، تعریف شاخص‌ها، دوره به‌روزرسانی و راهنمای کوتاه کاربر باید همراه آن باشد. دسترسی افراد را مطابق وظیفه آنها تنظیم کنید و جزئیات حساس را بی‌دلیل در خروجی عمومی نمایش ندهید. نسخه تنظیمات و مسیر بازیابی را مشخص کنید تا تغییر کوچک به وابستگی دائمی به سازنده منجر نشود. مسئول بررسی کیفیت داده و مسئول نگهداری سامانه ممکن است دو نفر متفاوت باشند؛ حدود کار هر کدام باید روشن باشد. برای تغییر شاخص‌ها یک روند ثبت درخواست داشته باشید. اگر تعریف یک شاخص تغییر کرد، تاریخ تغییر را در گزارش نگه دارید تا مقایسه گذشته و حال گمراه‌کننده نشود. طراحی قابل نگهداری بخشی از کیفیت محصول نهایی است.
پرسش‌های رایج درباره داشبورد GIS
آیا همه داشبوردها به داده لحظه‌ای نیاز دارند؟ خیر؛ دوره به‌روزرسانی باید با تصمیم هماهنگ باشد. گزارش برنامه‌ریزی ماهانه ممکن است با داده روزانه یا هفتگی کافی باشد. آیا داشتن نقشه برای هر شاخص ضروری است؟ خیر؛ بعضی مقایسه‌ها با نمودار و جدول روشن‌تر هستند. آیا با تغییر رنگ‌ها می‌توان کیفیت داشبورد را حل کرد؟ ظاهر مهم است، اما تعریف شاخص، کنترل داده و رفتار فیلترها مقدم هستند. از کجا شروع کنیم؟ یک سناریوی اصلی و چند شاخص محدود را انتخاب کنید، سپس نمونه را با کاربر واقعی آزمایش کنید. برای تعیین داده و معماری متناسب با پروژه می‌توانید از مشاوره GIS استفاده کنید. توسعه تدریجی پس از ارزیابی نمونه، احتمال ساخت صفحه‌ای پرهزینه و کم‌کاربرد را کاهش می‌دهد.
مطالب مرتبط
- GeoPackage یا Shapefile؟ راهنمای انتخاب فرمت و تحویل داده GIS
- اعتبارسنجی مکانی در یادگیری ماشین GIS؛ جلوگیری از نشت داده
بدون دیدگاه