وب GIS چیست؟

وقتی اکثر مردم به وب GIS فکر می کنند، به انتشار نقشه یا مجموعه داده ای برای دیدن جهان فکر می کنند. این قطعاً بخشی از آن است، اما فقط یک بخش کوچک. برای سال‌های زیادی که سعی می‌کردم کارفرمایانم را در مفهوم وب GIS بفروشم، آنها پاسخ می‌دادند: «ما نمی‌خواهیم همه اطلاعات اختصاصی ما را ببینند». پس از کاوش و یادگیری بیشتر به تنهایی، متوجه شدم که GIS وب بسیار بیشتر از انتشار محتوا است.

برای اهداف این پست، وب GIS هر روشی برای دسترسی، تجزیه و تحلیل و نمایش داده‌های مکانی با استفاده از فناوری‌های استاندارد وب است. این شامل فناوری های استاندارد سمت مشتری مانند HTML، CSS و جاوا اسکریپت می شود. در سمت سرور می‌تواند شامل چندین زبان مورد استفاده برای تعامل با پایگاه داده باشد. رایج‌ترین آنها PHP است، اما می‌تواند شامل جاوا، پایتون، مایکروسافت Asp.NET، Perl، Ruby و حتی جاوا اسکریپت بیشتری با استفاده از Node.JS باشد.

مزایای تعامل با GIS از طریق وب بسیار زیاد است

• داده های GIS شما در هر رایانه ای از هر جایی که اتصال اینترنتی وجود دارد قابل دسترسی است. این شامل دستگاه‌های تلفن همراه می‌شود که اتصال داده سلولی داشته باشند.
• دسترسی به داده‌های شما از طریق وب نیازی به هزینه‌های مجوز نرم‌افزار ندارد، اگرچه بسته به روشی که انتخاب می‌کنید ممکن است همچنان هزینه‌های نرم‌افزاری وجود داشته باشد.
• Web GIS در مواجهه با فناوری‌های در حال تغییر پایدارتر است. اینطور نیست که فناوری‌های وب هرگز آنقدر تغییر نمی‌کنند که تلاش زیادی برای سازگاری با گذشته انجام می‌دهند. این به این معنی است که راه حل های شما نسبت به GIS دسکتاپ به احتمال زیاد در 5 سال اجرا می شوند. این به احتمال زیاد در مورد فن آوری های وب منبع باز اولیه بیشتر از راه حل های تجاری صادق است.

با وب GIS چه کاری می توانید انجام دهید؟

پاسخ کوتاه این است که تقریباً هر کاری که می توانید با GIS دسکتاپ انجام دهید با وب GIS امکان پذیر است. با این حال، واقعیت این است که برخی چیزها برای وب GIS بهتر از موارد دیگر مناسب هستند. Web GIS نباید به عنوان جایگزینی برای GIS دسکتاپ در نظر گرفته شود. به عنوان ابزاری برای پرداختن به مشکلات خاص به جای موارد کلی مناسب تر است. چند نمونه از کاربردهای خوب وب GIS عبارتند از:

• انتشار نقشه و/یا داده های خود برای عموم مردم. این رایج ترین کاربرد است و بیشتر مردم هنگام فکر کردن به وب GIS به آن فکر می کنند.
• ارائه پورتال های امن برای مشتریان شما در 15 سال به عنوان یک متخصص GIS برای شرکت‌های مشاوره محیطی، زمان زیادی را صرف بسته‌بندی محصولات داده‌ای که ایجاد کرده بودیم و ارسال آن‌ها به مشتریان کردم تا بتوانند آنها را در سیستم‌های GIS خود مشاهده کنند. در بسیاری از موارد، ارائه یک ورود امن به یک برنامه GIS وب به مشتری، بسیار کارآمدتر بود تا بتواند آن داده ها را از طریق اینترنت مشاهده یا حتی احتمالاً ویرایش کند.
• ارائه دسترسی محدود GIS به کاربران سبک در سازمان شما که به مجوز کامل دسکتاپ نیاز ندارند. این ممکن است شامل بینندگان قابل دسترسی وب برای مدیران پروژه برای مشاهده داده های جمع آوری شده توسط خدمه میدانی باشد. همچنین ممکن است شامل ایجاد داده های سبک و قابلیت ویرایش برای خدمه میدانی باشد.
• نقشه برداری موبایل و جمع آوری داده ها. می توانید یک صفحه وب بسازید که برای دستگاه های تلفن همراه طراحی شده است و مانند یک برنامه بومی عمل می کند. این به پرسنل میدانی اجازه می دهد تا در میدان حرکت کنند و داده هایی را جمع آوری کنند که بلافاصله در دسترس مدیران پروژه در دفتر باشد. اگر اتصال داده ای در دسترس نباشد، ذخیره داده ها در دستگاه و به روز رسانی پایگاه داده مرکزی در صورت وجود اتصال نسبتاً ساده است.
• توسعه ابزارهای تحلیلی که برای همه، از هر جایی که اتصال اینترنتی وجود دارد، در دسترس باشد. ابزارهای تحلیلی مبتنی بر وب کمتر به تغییرات چرخه ارتقاء نرم افزار تجاری وابسته هستند. آخرین چیزی که هر توسعه‌دهنده‌ای می‌خواهد این است که یک کلاینت در عرض دو سال بازگردد و به آنها بگوید که ابزار آنها کار نمی‌کند، زیرا نرم‌افزاری که برای آن توسعه داده شده بود نسخه جدیدی منتشر کرد.
• Citizen Science یا جمع آوری داده های جمع آوری شده. اگر برای جمع‌آوری داده‌ها به مردم متکی هستید، می‌خواهید آنها بتوانند این اطلاعات را از طریق یک وب‌سایت به جای خرید نرم‌افزار یا دستگاه‌های گران‌قیمت ارائه کنند.

مثال ها

در 15 سال، من هرگز نیازی به انتشار یک نقشه یا داده برای عموم مردم به عنوان بخشی از کارم برای شرکت های مشاوره محیطی نداشته ام. این یکی از دلایلی است که بسیاری از شرکت‌های کوچک و متوسط ​​تمایل دارند قدرت وب GIS را نادیده بگیرند. با این حال، موقعیت‌های زیادی داشته‌ام که راه‌حل‌های وب GIS اگر دانش پیاده‌سازی آن‌ها را داشتم، ایده‌آل می‌بودند. من همچنین توانسته ام چند مورد از این موارد را در چند سال گذشته اجرا کنم زیرا دانش لازم را به دست آورده ام.

پورتال های مشتری ایمن

من فقط یک پورتال مشتری امن ایجاد کرده ام. این برای یک پروژه کنترل پشه بود که در آن مشتری، یک دولت منطقه، می‌خواست در زمان واقعی به خدمه‌های میدانی داده‌ها در حال جمع‌آوری اطلاعات باشند تا بتوانند کار را نظارت کنند و QA/QC را انجام دهند. اجرای آن نسبتاً آسان بود زیرا ما قبلاً آن اطلاعات را برای کارکنان دفتر خود در دسترس داشتیم. من به سادگی یک نسخه کاهش یافته از آنچه کارکنان دفتر در دسترس داشتند ایجاد کردم و از سیستم ورود به سیستم موجود برای امنیت استفاده کردم. حذف قابلیت‌ها بسیار ساده‌تر از افزودن آن‌ها است، بنابراین اجرای این پروژه تنها چند ساعت طول کشید.

نمونه‌های دیگری از کار من وجود دارد که در آن یک پورتال مشتری امن می‌توانست سودمند باشد. یکی از آنها پروژه پایش آب طوفان برای ارتقاء خط انتقال 60 مایلی بود. کارکنان میدانی ما با خدمه ساخت و ساز کار کردند تا بهترین شیوه های مدیریتی (BMP’s) را برای به حداقل رساندن کنترل رواناب آب طوفان در کل راهرو توصیه کنند. آنها همچنین هر سایت را پس از رویدادهای بارندگی زیر نظر گرفتند تا موفقیت یا شکست آنها را ارزیابی کنند. البته همه BMP ها باید نقشه برداری می شدند

مشتری ما می‌خواست به توصیه‌های BMP در زمان واقعی دسترسی داشته باشد تا بتواند مصالح را سفارش دهد و به پرسنل ساختمانی اطلاع دهد. این 10 سال پیش و در یک منطقه دور افتاده و بدون اتصال به اینترنت بود. کارکنان میدانی ما داده‌های مکان را با GPS در میدان جمع‌آوری می‌کنند و هر شب باید داده‌ها را بارگیری می‌کنند، آن‌ها را تصحیح می‌کنند، نقشه می‌سازند، نقشه را چاپ می‌کنند و با تخمین مواد مورد نیاز برای مشتری فکس می‌کنند. آنها همچنین اطلاعات را برای اهداف ردیابی در پایگاه داده Access وارد می کنند. پس از یک روز طولانی در این زمینه، زمان زیادی طول کشید. امروز من راه حلی را پیاده سازی می کنم که در آن همه کارکنان میدانی ما باید انجام دهند، جمع آوری داده ها در میدان در یک دستگاه تلفن همراه است که به طور خودکار پایگاه داده مرکزی را به روز می کند. مشتری یک پورتال امن خواهد داشت که از آن می تواند داده ها را مشاهده کند، نقشه ها را چاپ کند،

قبل از سقوط قیمت نفت به اجرای پروژه دیگری نزدیک بودم. مشتری ما یک شرکت نفت و گاز بود. کارکنان میدانی ما مکان‌های پروژه پیشنهادی را برای محدودیت‌های محیطی بالقوه که بر عملیات مشتری ما تأثیر می‌گذارد بررسی می‌کنند. اینها شامل لانه های شکارچیان، تالاب ها، زیستگاه گونه های در معرض خطر و غیره بود. توسعه در این منطقه نسبتاً متراکم بود. یک لانه شکارچی که برای یک پروژه قرار داشت اغلب بر چندین پروژه دیگر نیز تأثیر می گذارد. هزینه ای که مشتری برای یک روز استفاده نکردن از یک دکل حفاری در حدود 100000 دلار داشت، بنابراین آنها خواستار اطلاع فوری از هر یافته ای بودند که بر عملکرد آنها تأثیر می گذارد. این یک پروژه سریع، پیچیده و مستلزم هماهنگی زیادی بین خدمه میدانی، مدیران پروژه و مشتریان ما بود.

پیشنهاد من می‌توانست یک پورتال امن برای مشتری فراهم کند تا بتواند تمام داده‌های ما را در زمان واقعی که در میدان جمع‌آوری می‌شود، ببیند و اعلان‌های ایمیل خودکار را از هر یافته‌ای که بر پروژه‌های فعال تأثیر می‌گذارد دریافت کند. همچنین به مشتری این امکان را می داد که یک منطقه را روی صفحه ترسیم کند و گزارشی از محدودیت های بالقوه برای آن منطقه ایجاد کند. به دلیل اینکه پوشش ما کامل نبود و دائماً در حال تغییر نبود، نیازی به بررسی منطقه توسط خدمه میدانی ما نبود، اما اطلاعات ارزشمندی را برای اهداف برنامه ریزی در اختیار مشتری قرار می داد.

دسترسی GIS

برای پروژه کنترل پشه که در بالا توضیح داده شد، سیستمی را توسعه دادم که در آن دو مدیر پروژه به داده های GIS دسترسی کامل داشتند، از جمله دسترسی بلادرنگ به داده هایی که پرسنل میدانی جمع آوری می کردند. آن‌ها همچنین به مجموعه‌ای از گزارش‌هایی که برای مدیریت پروژه نیاز داشتند، ابزارهای QA/QC، و حتی توانایی دیدن اینکه خدمه میدانی‌شان کجا هستند و کجا بوده‌اند، دسترسی داشتند. این پروژه همچنین دارای سه نفر بود که در یک آزمایشگاه کار می کردند و به توانایی مشاهده داده ها، به روز رسانی اطلاعات تماس برای سایت های میدانی و انجام QA/QC محدود نیاز داشتند. با این حال، به پرسنل آزمایشگاه امکان ویرایش داده‌هایی که خدمه میدانی جمع‌آوری می‌کردند یا افزودن و حذف سایت‌ها یا مدیریت پرسنل میدانی داده نشد.

وب GIS کنترل دقیق ویژگی هایی را که برای چه پرسنلی در دسترس است آسان می کند. دو مزیت اضافی این بود که:

• رابط های وب GIS از هر رایانه ای، هر جایی که اتصال اینترنتی داشت، در دسترس بود. حتی تبلت ها و گوشی ها اگر برای نمایشگرهای کوچکتر طراحی شده باشند. این به مدیران پروژه این امکان را می‌دهد که در هنگام سفر یا اگر آنقدر مریض هستند که نمی‌توانند به دفتر بیایند، پروژه‌های خود را زیر نظر داشته باشند.
• هیچ یک از این رابط ها مجوز GIS دسکتاپ را مصرف نکردند که باعث صرفه جویی قابل توجهی در هزینه شرکت شد.

یک برنامه دسکتاپ GIS مانند ArcMap فوق العاده انعطاف پذیر و قدرتمند است. با این انعطاف‌پذیری و قدرت، با کمی پیچیدگی همراه است. در تجربه من، هر سازمانی دارای طیف گسترده ای از پرسنل با طیف وسیعی از دانش و علایق GIS است. برخی از مردم استفاده از GIS را دوست دارند و مشتاق کسب اطلاعات بیشتر هستند، برخی دیگر آن را صرفاً به عنوان یک ابزار می بینند، و برخی دیگر هنوز آن را منبع ناامیدی دائمی می دانند و ترجیح می دهند بیش از حد ضروری از آن استفاده نکنند. بازخوردی که اغلب از کارکنان میدانی‌مان دریافت می‌کردیم این بود: «چرا نمی‌توانیم چیزی مانند نقشه‌های گوگل داشته باشیم، اما داده‌هایمان روی آن باشد؟»

Web GIS این توانایی را برای یک سازمان فراهم می کند تا به آن کارکنان علاقه و/یا توانایی کمتری با یک رابط وب ساده تر و خاص پروژه ارائه دهد که به آنها امکان می دهد داده ها را مشاهده کنند، ویژگی ها را ویرایش کنند، ویژگی های جدید اضافه کنند و غیره. آنها از Google ساده بسیار قدردانی کردند. رابط نوع نقشه ها، به ویژه برای کارهای میدانی. کاربران نیرو در سازمان همچنان می توانند به قدرت و انعطاف پذیری کامل GIS دسکتاپ دسترسی داشته باشند.

اگر این فناوری زودتر در دسترس بود، وب GIS می‌توانست شرکت‌هایی را که برای زمان و هزینه قابل توجهی در پروژه‌های دیگر کار می‌کردم نجات دهد. یک پروژه شامل نقشه برداری از تالاب ها در کل منطقه حفاظت شده ناواهو بود. منطقه ای بزرگتر از چندین ایالت. ما از دانشجویان کالج دینا برای کمک به مراحل اولیه نقشه برداری استفاده کردیم و نصب ابزارهایی که برای دیجیتالی کردن در ArcMap در کامپیوترهای دانشگاه ایجاد کرده بودم چالش برانگیز بود. علاوه بر این، ما با مسائل دسترسی چند کاربره دست و پنجه نرم کردیم و یک رویکرد وب GIS می‌توانست هر دوی این مشکلات را حل کند.

در پروژه نفت و گاز که در بالا توضیح دادم چهار مدیر پروژه داشتیم. دو نفر از آنها با ArcMap آشنا و راحت بودند، اما دو نفر دیگر به سادگی می خواستند بتوانند مناطق پروژه خود و داده های محدودیت های محیطی را ببینند. آنها دائماً می پرسیدند که چرا نمی توانند داده ها را در Google Earth ببینند. یک رویکرد وب GIS می‌توانست این توانایی را فراهم کند و ناامیدی و هزینه‌های زیادی را از جانب همه کاهش دهد.

دسترسی به داده های تلفن همراه و جمع آوری داده ها

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

به این دلایل، حتی با وجود یکسان بودن فن‌آوری‌های اساسی وب، ترجیح داده می‌شود که رابط‌های مخصوص موبایل برای داده‌های خود طراحی کنید. برای پروژه کنترل پشه ما، نیاز خدمه میدانی ما برای وارد کردن داده‌ها در میدان، چیزی بود که شرکت ما را به استفاده از رویکرد GIS وب برای این پروژه سوق داد. ما با 18 شهرداری مختلف قرارداد داشتیم و هر کدام کمی قوانین و مقررات متفاوتی داشتند. ما به نرم‌افزار جمع‌آوری داده‌ها نیاز داشتیم که از تبعیت از قوانین اطمینان حاصل کند، زیرا پیامدهای قانونی و فرآیند QA/QC دقیق وجود دارد، بنابراین دستگاه‌ها/نرم‌افزار جمع‌آوری داده‌های GPS استاندارد کافی نبودند. ما قبلاً جمع‌آوری داده‌ها را با نسخه سفارشی‌سازی شده ArcPad در دستگاه‌های موبایل ویندوز انجام داده بودیم. این به مدت 5 سال به خوبی کار کرد، اما عمر مفید دستگاه ها بیشتر شده بود و رویکرد جدیدی مورد نیاز بود.

ما تصمیم گرفتیم با یک رویکرد وب GIS که بر روی تبلت های اندرویدی اجرا می شود، برویم. سخت افزار بسیار ارزان تر بود و دیگر مجبور نبودیم برای مجوز ArcPad هزینه ای بپردازیم. این صرفه جویی باعث شد که بتوانیم نرم افزار خودمان را توسعه دهیم که دقیقاً همان چیزی را که ما نیاز داشتیم انجام می دهد و نه بیشتر. ما به توانایی پرسنل میدانی خود نیاز داشتیم تا روی نقشه ببینند که کدام مکان‌ها باید بازرسی شوند و نتایج بازرسی‌های قبلی. ما به پرسنل میدانی خود نیاز داشتیم تا بتوانیم اطلاعات دسترسی به سایت را مشاهده کنیم زیرا اکثر سایت ها در زمین خصوصی بودند. مهمتر از همه، ما به این نرم افزار نیاز داشتیم تا اعتبارسنجی بلادرنگ انجام دهد تا احتمال خطاهای برنامه درمانی را کاهش دهد و قوانین برای هر یک از 18 شهرداری که برای آن کار می کردیم متفاوت بود. ما همچنین می‌خواستیم که کارکنان دفتر بتوانند پیام‌هایی را برای کارکنان میدانی ارسال کنند تا آنها را از درخواست‌های «نقطه داغ» اخیراً اضافه‌شده و خدمه میدانی به کارکنان دفتر از تغییرات دسترسی به سایت مطلع کنند. و ما می خواستیم کارکنان دفتر بتوانند ببینند که اعضای خدمه کجا هستند و چه کسانی در هر روز کار می کنند تا وظایف را به درستی تعیین کنند. علاوه بر این، پوشش داده‌های سلولی در برخی از قسمت‌های منطقه ما ناچیز بود، بنابراین ما نیاز داشتیم که برنامه حتی اگر سیگنال داده سلولی در دسترس نباشد، کار کند. طراحی نرم افزار سفارشی خودمان با فناوری وب GIS به ما این توانایی را داد که تمام این الزامات را به شیوه ای مقرون به صرفه برآورده کنیم. و ما می خواستیم کارکنان دفتر بتوانند ببینند که اعضای خدمه کجا هستند و چه کسانی در هر روز کار می کنند تا وظایف را به درستی تعیین کنند. علاوه بر این، پوشش داده‌های سلولی در برخی از قسمت‌های منطقه ما ناچیز بود، بنابراین ما نیاز داشتیم که برنامه حتی اگر سیگنال داده سلولی در دسترس نباشد، کار کند. طراحی نرم افزار سفارشی خودمان با فناوری وب GIS به ما این توانایی را داد که تمام این الزامات را به شیوه ای مقرون به صرفه برآورده کنیم. و ما می خواستیم کارکنان دفتر بتوانند ببینند که اعضای خدمه کجا هستند و چه کسانی در هر روز کار می کنند تا وظایف را به درستی تعیین کنند. علاوه بر این، پوشش داده‌های سلولی در برخی از قسمت‌های منطقه ما ناچیز بود، بنابراین ما نیاز داشتیم که برنامه حتی اگر سیگنال داده سلولی در دسترس نباشد، کار کند. طراحی نرم افزار سفارشی خودمان با فناوری وب GIS به ما این توانایی را داد که تمام این الزامات را به شیوه ای مقرون به صرفه برآورده کنیم.

توسعه ابزارهای تحلیلی مبتنی بر وب

زمانی که هیچ راه حلی در برنامه های استاندارد GIS دسکتاپ وجود نداشت، ابزارهای سفارشی زیادی را برای مردم ایجاد کرده ام. همانطور که نرم افزارهای دسکتاپ GIS مانند ArcMap و QGIS قدرتمند و منعطف هستند، آنها به سادگی نمی توانند برای هر نیاز تحلیلی خارج از جعبه راه حلی ارائه دهند. راه‌حل‌هایی که توسعه دادم بیشتر دوران حرفه‌ای من در قالب افزونه‌های ArcGIS بود. ESRI از نسخه 10 پیشرفت های زیادی در توانایی توزیع این افزونه ها ایجاد کرده است، با این حال آنها همچنان به ویژوال استودیو مایکروسافت و چارچوب دات نت آن وابسته بودند. زمانی که ESRI نسخه‌های جدید ArcGIS را منتشر کرد، آنها بر اساس آخرین نسخه چارچوب دات‌نت مایکروسافت ساخته شدند و افزونه‌های ایجاد شده با نسخه‌های قدیمی‌تر دیگر کار نمی‌کنند.

در یک موقعیت، من ابزاری را برای محاسبه تنوع گونه‌ها در پاسخ به پستی در فهرست خدمات حفاظتی که با آن درگیر هستم، توسعه دادم. من هیچ هزینه ای برای این کار نکردم، فقط یک یا دو ساعت طول کشید و می دانستم که این کار باعث صرفه جویی در ساعت های زیادی از ویرایش پیش پا افتاده مشتری می شود و این دلیلی بود که می خواستم از آن حمایت کنم. چندین سال بعد با من تماس گرفتند و به من گفتند که این ابزار دیگر در آخرین نسخه ArcMap که آنها نصب کرده بودند کار نمی کند. من حتی به یاد نداشتم که ابزار را ایجاد کنم و حتی کد منبع را هم نداشتم. بدتر از آن، ESRI اجازه نمی‌دهد چندین نسخه از ArcMap روی یک کامپیوتر وجود داشته باشد و من در پروژه‌ای که از نسخه قبلی ArcMap استفاده می‌کرده بودم، حتی به نسخه‌های اخیرا منتشر شده ArcMap یا Visual دسترسی نداشتم. استودیو.

هم برای توسعه دهندگان و هم برای کسانی که از ابزارهایی که توسعه دهنده ایجاد می کند استفاده می کنند تا در چرخه به روز رسانی نرم افزار ESRI قرار بگیرند بسیار ناامید کننده است. مطمئن نیستم که این ممکن است با ابزارهای ایجاد شده با پایتون مشکل کمتری داشته باشد. این مشکل کمتری با QGIS است زیرا هیچ مشکلی با داشتن چندین نسخه در یک رایانه وجود ندارد. با این حال، برخی از افراد علاقه ای به نصب نرم افزار جدید روی رایانه خود ندارند، حتی اگر رایگان باشد. حتی برخی از سازمان ها محدودیت های شدیدی در مورد نصب نرم افزارهای غیرمجاز دارند. و البته، برخی از افراد به دلیل منحنی یادگیری در امتحان نرم افزار جدید مردد هستند، بنابراین حتی اگر یک افزونه QGIS توسعه دهید، ممکن است افراد در استفاده از آن مردد باشند.

اگر بتوانید ابزار خود را با فناوری های وب GIS پیاده سازی کنید، این مشکلات ناپدید می شوند. ابزار شما برای هر کسی که به اینترنت متصل است در دسترس خواهد بود، خواه از QGIS، ArcGIS، Manifold، Mapinfo یا هر سیستم GIS دیگری استفاده کند. برای افرادی که از ویندوز، مک‌اینتاش، لینوکس یا یک دستگاه تلفن همراه استفاده می‌کنند، در دسترس خواهد بود. اکثر مردم رفتن به یک صفحه وب جدید را به عنوان یادگیری نرم افزار جدید نمی بینند و در واقع چیزی روی رایانه خود نصب نمی کنند، بنابراین موانع روانی و نهادی نیز ناپدید می شوند. البته هر ابزاری برای وب GIS مناسب نیست. پیاده سازی ابزارهایی که نیاز به خروجی یک مجموعه داده جدید دارند دشوارتر است (اگرچه غیرممکن نیست). ابزارهایی که به سادگی ورودی را دریافت می کنند و یک جدول خروجی، گزارش یا نتیجه را برای نمایش روی نقشه تولید می کنند، از طرف دیگر، عموما ساده تر هستند.

Citizen Science یا جمع آوری داده های جمع آوری شده

یکی از اولین پروژه‌هایی که وقتی شروع به جستجوی وب GIS کردم، شامل یک کار غیرانتفاعی کوچک (یک نفره) برای افزایش آگاهی از فعالیت خرس سیاه در شهر کوهستانی کوچکی بود که در آن زندگی می‌کردم. گزارش هایی از مشاهده خرس در شهر جمع آوری کنید و نقشه ای تهیه کنید که در روزنامه های محلی ظاهر شود. آنها در این فکر بودند که برای ایجاد یک وب سایت که در آن شهروندان بتوانند خود تصاویر مشاهده شده را اضافه کنند، چه چیزی لازم است. با توجه به آموزش من به عنوان یک زیست شناس حیات وحش، برای اجرای این پروژه هیجان زده بودم زیرا مزایای زیادی را برای داشتن این اطلاعات به صورت دیجیتالی برای ردیابی تغییرات فعالیت خرس بر اساس زمان روز، فصل، در پاسخ به تأثیرات سالانه دیدم. به عنوان خشکسالی و سرما که بر دسترسی طبیعی غذا تأثیر می گذارد،

امروز می‌توانم پروژه‌ای مانند این را در چند ساعت با استفاده از نرم‌افزار متن‌باز بدون هیچ هزینه‌ای جز چند دلار در ماه برای میزبانی وب پیاده‌سازی کنم. با این حال، ده سال پیش، هم دانش و هم فناوری موجود من پیشرفت بسیار کمتری داشتند. من چندین دوره در زمینه ایجاد نقشه های وب با API جاوا اسکریپت ESRI گذرانده بودم، اما امکان ویرایش داده ها از طریق رابط های وب جدید بود و به ArcServer دسترسی نداشتم. ArcGIS آنلاین هنوز در مراحل ابتدایی خود بود و توانایی‌های امروزی را نداشت. هزاران دلار در نرم افزار و احتمالاً چندین هفته از زمان من برای یادگیری آنچه برای اجرای این پروژه نیاز داشتم صرف می شد و من نتوانستم رئیسم را متقاعد کنم که مزایای بلند مدت هزینه برای او را توجیه می کند.

وب GIS چگونه کار می کند

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

وب به شکلی از پایین به بالا با سازماندهی یا کنترل کمی از بالا به پایین تکامل یافته است. فن آوری هایی که به عنوان استاندارد پذیرفته شدند تا حد زیادی به این دلیل انجام شدند که بزرگترین پایگاه کاربر را داشتند. برای مثال، PHP توسط Rasmus Lerdorf برای استفاده خودش در وب سایت شخصی خود توسعه داده شد. او هرگز قصد نداشت آن را یک زبان برنامه نویسی کند، چه رسد به اینکه با پایگاه های داده تعامل داشته باشد. با این وجود، PHP در حال حاضر در بیش از 80 درصد از صفحات وب که دارای مؤلفه پایگاه داده سمت سرور هستند استفاده می شود. این رویکرد از پایین به بالا دلیل این است که فناوری‌های بسیار متفاوتی وجود دارد و اینکه چرا برنامه‌نویسی روی کلاینت از زبان کاملاً متفاوتی نسبت به برنامه‌نویسی روی سرور استفاده می‌کند (مگر اینکه با Node.JS روی سرور برنامه‌نویسی می‌کنید). این مجموعه ای از فناوری های مختلف اغلب برای افرادی که تازه شروع به یادگیری برنامه نویسی وب کرده اند، خسته کننده است.

GIS وب سمت مشتری

برنامه نویسی روی مشتری تا حد زیادی بر روی سه فناوری کلی استاندارد شده است. HTML ساختار صفحه وب را فراهم می کند و شامل محتوا می شود. CSS به ساختار و محتوای موجود در HTML اجازه می دهد تا ظاهری جذاب داشته باشد. جاوا اسکریپت یک زبان برنامه نویسی کامل است که به برنامه نویس اجازه می دهد محاسبات را انجام دهد، به رویدادها پاسخ دهد و به طور کلی به مرورگر وب اجازه می دهد کارهایی غیر از نمایش محتوا را انجام دهد. از نظر وب، مشتری یک مرورگر وب است. همه مرورگرهای وب مدرن می توانند HTML، CSS و جاوا اسکریپت را تفسیر کنند. همچنین تعداد بی‌شماری از کتابخانه‌های عمومی وجود دارد که با استفاده از سه فناوری اساسی ساده می‌شوند. Bootstrap یک کتابخانه CSS بسیار محبوب و jQuery یک کتابخانه جاوا اسکریپت بسیار محبوب است.

همچنین کتابخانه هایی برای اهداف خاص مانند نقشه برداری در دسترس هستند. Google Maps یک API ارائه می دهد که به شما امکان می دهد برای مثال با افزودن داده های خود با نقشه های گوگل تعامل داشته باشید. ESRI همچنین یک API جاوا اسکریپت ارائه می‌کند که می‌تواند شامل لایه‌های پایه ESRI و داده‌های ویژگی ArcServer باشد. Leaflet و OpenLayers کتابخانه های جاوا اسکریپت منبع باز هستند که هر کدام مزایا و معایب خاصی دارند. به طور کلی برگه یک کتابخانه ساده و سبک است که برای قابلیت های پیشرفته تر به افزونه های ارائه شده توسط جامعه بستگی دارد. این به برنامه نویس اجازه می دهد تا دقیقاً چه ویژگی هایی را که می خواهد شامل شود، انتخاب و انتخاب کند. لایه‌های باز یک کتابخانه کامل‌تر و با امکانات کامل‌تر است.

مهم نیست که کدام کتابخانه نقشه برداری را انتخاب می کنید، اولین کاری که اکثر کاربران GIS می خواهند انجام دهند این است که داده های خود را روی آن قرار دهند. اگر به سرور ArcGIS دسترسی دارید، API جاوا اسکریپت ESRI گنجاندن آن داده ها را بر روی نقشه شما آسان می کند. OpenLayers با سرویس های منبع باز WMS و WFS به خوبی کار می کند. هر چهار مورد می توانند داده های ذخیره شده در قالب GeoJSON (یا بازیابی شده از پایگاه داده روی سرور و تبدیل به GeoJSON) را نمایش دهند. GeoJSON یک استاندارد مبتنی بر متن برای ذخیره داده های GIS برداری است که به خوبی با جاوا اسکریپت و PHP کار می کند. می‌توانید از جاوا اسکریپت برای تعامل با داده‌های خود استفاده کنید، به عنوان مثال با فیلتر کردن آن، جستجوی ویژگی‌های خاص، مشاهده ویژگی‌های ویژگی، بزرگ‌نمایی و پاننگ، و غیره. همچنین یک کتابخانه جاوا اسکریپت عالی به نام Turf.js وجود دارد که قابلیت تجزیه و تحلیل فضایی را در مشتری. چمن.

اگر تنها کاری که باید انجام دهید این است که داده های ثابت را روی نقشه نمایش دهید، تنها با فناوری های سمت مشتری می توانید از آن استفاده کنید. می توانید داده های خود را در قالب GeoJSON ذخیره کنید و آنها را روی نقشه بارگذاری کنید، آنها را بر اساس ویژگی ها فیلتر کنید و تجزیه و تحلیل مکانی روی آنها انجام دهید. اگر داده های شما ثابت است و تغییر زیادی نمی کند، به پیچیدگی سرور پایگاه داده نیاز ندارید.

وب GIS سمت سرور

اگر داده‌های شما به سرعت در حال تغییر هستند و می‌خواهید کاربر جدیدترین داده‌ها را ببیند، یا اگر می‌خواهید به کاربر توانایی اضافه کردن و/یا اصلاح داده‌ها را بدهید، باید آن داده‌ها را در یک پایگاه داده روی سرور ذخیره کنید. همچنین برای تعامل با پایگاه داده باید در مورد فناوری های سمت سرور و احتمالاً یک زبان برنامه نویسی متفاوت نیز بیاموزید. پی اچ پی رایج ترین زبان برنامه نویسی سمت سرور است، اما زبان های دیگر شامل جاوا، روبی، پایتون، سی شارپ (با استفاده از فناوری ASP.NET مایکروسافت) است. همچنین می توانید کد سمت سرور را در جاوا اسکریپت با استفاده از Node.JS بنویسید. همچنین می‌توانید همان داده‌ها را روی سرور از اکثر نرم‌افزارهای رومیزی GIS مدیریت کرده و با آنها تعامل داشته باشید.

ESRI یک پسوند پایگاه داده به نام ArcSDE توسعه داده است که عملکردهای مکانی را به چندین پایگاه داده تجاری و منبع باز، از جمله SQLServer، Oracle، و PostgreSQL اضافه می کند. PostGIS تا حد زیادی رایج ترین پسوند پایگاه داده فضایی در دنیای منبع باز است. PostGIS فقط با پایگاه داده PostgreSQL کار می کند، اگرچه اکثر پایگاه های داده منبع باز دارای سطحی از قابلیت فضایی هستند.  پایگاه داده‌های دارای قابلیت فضایی معمولاً سه عملکرد اصلی را اضافه می‌کنند.

• ذخیره سازی داده های مکانی – به طور کلی، داده های مکانی (مختصات) در قالب باینری به عنوان یک فیلد BLOB ذخیره می شوند، در حالی که ویژگی ها به سادگی به عنوان فیلدهای متنی و عددی در پایگاه داده ذخیره می شوند.
• توابع فضایی – اکثر پایگاه های داده فضایی شامل مجموعه ای از توابع سفارشی هستند که توانایی تبدیل بین انواع داده ها و مرجع فضایی و همچنین انجام تجزیه و تحلیل فضایی را فراهم می کنند. PostGIS بیش از 1000 مورد از این توابع سفارشی را دارد.
• نمایه‌های فضایی – پایگاه‌های اطلاعاتی سازمانی برای نمایه‌سازی بسیار بهینه شده‌اند و پایگاه‌های داده فضایی نیز برای نمایه‌سازی مکانی بهینه شده‌اند. این باعث می شود جستجو و پردازش جغرافیایی کارآمدتر شود.

صفحه وب شما می تواند با استفاده از دستورات SQL با پایگاه داده تعامل داشته باشد. زبان پرس و جو ساختاریافته یا SQL به شما امکان می دهد داده های ذخیره شده در پایگاه داده را ایجاد، اصلاح، حذف و بازیابی کنید. در حالی که کل دوره ها را می توان و در مورد SQL نوشته شده است، اصول اولیه بسیار ساده است و شما می توانید کارهای زیادی را با اصول اولیه انجام دهید. اگر تا به حال از سازندگان پرس و جو بصری در ArcGIS یا QGIS برای انتخاب بر اساس ویژگی ها استفاده کرده اید، از SQL استفاده کرده اید. آنها فقط رابط های بصری برای ساخت یک SQL Where clause هستند. PostGIS SQL را با توابع فضایی سفارشی خود گسترش می دهد، بنابراین معیارهای فضایی را در جستارهای خود بگنجانید، مانند بازیابی تمام خطوطی که در فاصله 200 فوتی یک نقطه هستند یا تمام نقاطی که یک چند ضلعی را قطع می کنند.

بیشتر تعامل شما با پایگاه داده در صفحه وب شما به شکل دستورات SQL برای بازیابی مجموعه خاصی از داده ها خواهد بود. این داده ها باید به فرمی تبدیل شوند که API نقشه برداری شما بتواند آن را درک کند. زبان‌های برنامه‌نویسی سمت سرور مانند PHP می‌توانند داده‌های بازیابی شده را به فرمت GeoJSON تبدیل کنند و سپس می‌توانید آن را برای نمایش بر روی نقشه به مشتری ارسال کنید.

همچنین می توانید یک سرویس برای تعامل با پایگاه داده راه اندازی کنید. این کاری است که ArcGIS Server انجام می دهد. در دنیای متن‌باز، GeoServer و MapServer می‌توانند همین کار را با داده‌های PostGIS و سایر قالب‌های پایگاه داده استاندارد انجام دهند. من شخصاً هنوز چیزی را پیدا نکرده ام که نتوانم با پرس و جوهای مستقیم SQL به پایگاه داده انجام دهم و بنابراین نیازی به اضافه کردن یک لایه پیچیدگی اضافی به برنامه های خود ندیده ام. اگر می‌خواهید به افراد دیگر توانایی اضافه کردن داده‌های خود را در نقشه‌های خود بدون دسترسی به پایگاه داده خود ارائه دهید، می‌توانید با انتشار داده‌های خود به‌عنوان یک سرویس وب با استفاده از GeoServer، MapServer یا ArcGIS Server این کار را انجام دهید. اگر داده‌های شطرنجی دارید که می‌خواهید در یک صفحه وب ارائه کنید، ممکن است از GeoServer یا ابزار مشابهی نیز بهره مند شوید.

چه طور باید شروع کرد

رویکردهای غیر برنامه نویسی

اساساً دو رویکرد برای شروع کار با وب GIS وجود دارد. ESRI رویکرد «غیربرنامه‌نویسی» خود را به‌ویژه با ArcGIS Online پیش برده است. آنها همچنین مجموعه ای از برنامه های تلفن همراه را ارائه می دهند که عمدتاً بر روی داده هایی عمل می کنند که به عنوان خدمات توسط ArcGIS Server یا میزبانی شده در ArcGIS Online عمل می کنند. آنها به شما اجازه می دهند نقشه ای را در دسکتاپ ArcGIS بنویسید و آن را در ArcGIS Online یا سرور ArcGIS منتشر کنید. اگر کاربر ESRI هستید و به محصولات آنها دسترسی دارید، کارهای زیادی می توانید بدون برنامه نویسی انجام دهید. من نمی توانم بیشتر از این به شما بگویم زیرا چندین سال پیش به دلایل مختلف از محصولات ESRI صرف نظر کردم. به‌عنوان یک برنامه‌نویس، توسعه برنامه‌های کاربردی خود را بسیار ساده‌تر از تلاش برای کشف رویکردهای مجوز و حساب کاربری آنها یافتم و نمی‌توانم هزینه‌های آنها را به مشتریانم توجیه کنم.

QGIS همچنین توانایی ایجاد نقشه های وب استاتیک را دارد. پلاگین QGIS2Webیک سند نقشه QGIS را می گیرد و در وب “انتشار” می کند، اگرچه این فرآیند بسیار ساده تر و محدودتر از رویکرد ESRI است. کاری که در واقع انجام می دهد ایجاد یک برنامه وب با استفاده از Leaflet یا OpenLayers برای بوم نقشه است. داده های روی نقشه به فایل های GeoJSON تبدیل می شوند، نمادشناسی تا حد امکان حفظ می شود و حتی پاپ آپ هایی که در QGIS ایجاد می کنید به نقشه وب تبدیل می شوند. سپس می توانید به سادگی فایل های HTML، CSS و داده ها را در صفحه وب شرکت خود آپلود کنید. این به عنوان نقطه شروعی برای انتشار داده ها عالی عمل می کند. اگر شرکت شما قبلاً یک سیستم ورود به سیستم مشتری ایمن راه‌اندازی کرده است، می‌توانید به راحتی یک نقشه وب استاتیک را به منطقه دسترسی آنها اضافه کنید. جنبه منفی این است که شما فقط داده های استاتیک را ارائه می دهید و بنابراین توانایی ویرایش آن را ندارید.

همچنین یک پروژه منبع باز به نام GeoNode وجود دارد که به نظر می رسد عملکردی مشابه با ArcGIS Online دارد. من از GeoNode استفاده نکرده‌ام، چیز زیادی در مورد آن نمی‌دانم، اما به شما اجازه می‌دهد تا حساب‌های کاربری و میزبانی داده‌های GIS را همانطور که با ArcGIS Online انجام می‌دهید، تنظیم کنید. همچنین امکان ویرایش داده های میزبانی شده را فراهم می کند. شاید یکی از خوانندگان من تجربه استفاده از GeoNode را داشته باشد که بتواند آن را به اشتراک بگذارد.

رویکردهای برنامه نویسی

همانطور که یک رویکرد “غیر برنامه نویسی” برای ساختن نقشه های وب جذاب است، محدودیت هایی نیز دارند. شاید من به عنوان یک برنامه نویس مغرض هستم. من دوست دارم بفهمم که چگونه همه چیز در زیر کاپوت کار می کند. زمانی که از نرم‌افزاری استفاده می‌کنم که نمی‌تواند کار ساده‌ای را انجام دهد که به آن نیاز دارم و مجبور می‌شوم ساعت‌ها کار یکنواخت را با دست انجام دهم، استفاده می‌کنم، وقتی می‌دانم که می‌توان آن را خودکار کرد، واقعاً ناامید می‌شوم. از ناکارآمدی متنفرم من خیلی ترجیح می‌دهم برنامه‌های خودم را بنویسم تا دقیقاً همان چیزی را که می‌خواهم انجام دهم و نه بیشتر، و اگر مشکلاتی وجود داشت یا نیازهای پروژه تغییر کرد، بتوانم خودم را برطرف کنم.

بیشتر پروژه هایی که من روی آنها کار کرده ام به اندازه کافی پیچیده بوده اند که رویکردهای “غیر برنامه ریزی” کافی نبودند. این ضربه ای به ESRI و شرکت های دیگر نیست که تلاش زیادی برای انعطاف پذیری چیزها انجام می دهند تا غیر برنامه نویسان بتوانند از آنها به طور سازنده استفاده کنند. فقط این است که دنیای واقعی پیچیده است و هیچ راهی برای پیش‌بینی تمام کارهای ممکنی که ممکن است یک برنامه وب GIS برای انجام آن فراخوانده شود وجود ندارد. در پروژه کنترل پشه که در بالا توضیح دادم، من مجبور شدم کدهای سختی را در قوانین تعیین کنم که بسته به ورودی های چندین ویژگی قبلی، کدام درمان و چه مقدار باید اعمال شود. به سادگی هیچ راهی برای پیش بینی آن چیزها در یک رویکرد غیربرنامه نویسی تعمیم یافته وجود ندارد. گزینه جایگزین این است که آن قوانین را در بر نگیرد و داده ها را در زمان ورود تأیید نکنید. با این حال، انجام این کار،

پس از جهش به یادگیری فن آوری های اساسی مورد نیاز برای وب GIS، من به طور کلی می توانم یک نقشه وب اولیه یا برنامه جمع آوری داده های تلفن همراه را که می تواند با رویکرد “غیر برنامه نویسی” در چند ساعت انجام شود، جمع آوری کنم. و سپس اگر مشتری از من بپرسد که آیا می توانم یک ویژگی خاص را اضافه کنم، معمولا می توانم بگویم “بله”. و من معمولاً می توانم آن ویژگی را خیلی سریعتر از آن چیزی که بتوانم بررسی کنم که آیا بدون برنامه نویسی در دسترس است و چگونه آن را پیاده سازی کنم اضافه کنم. و هنگامی که، همانطور که معمولاً اتفاق می‌افتد، متوجه می‌شوم که نیاز به یک اصلاح سفارشی دارد، پیاده‌سازی آن بسیار ساده‌تر از تلاش برای کشف کد شخص دیگری برای اصلاح آن است. مهمتر از همه، اگر پروژه قرار است تعداد زیادی کاربر نداشته باشد، می توانم خودم پیشنهاد میزبانی سایت را بدهم.

انجام آن پرش آسان نبود. من دوره های زیادی برای توسعه وب گذراندم. من بسیاری از سوراخ های خرگوش را در تعقیب جدیدترین و بهترین فناوری ها فرو کردم. من از همه آنها چیزهای زیادی یاد گرفتم، اما در نهایت به این نتیجه رسیدم که یک پایه محکم در فناوری های اساسی HTML، CSS، جاوا اسکریپت، PHP و SQL بهترین رویکرد است. با این زبان ها، کاری که نمی توانید با وب GIS انجام دهید وجود دارد. بسته به کاربردتان، ممکن است بتوانید برخی کارها را با Angular.js، React، Node، MongoDB یا سایر فناوری‌های پیشرفته‌تر کارآمدتر انجام دهید، اما قبل از اینکه بتوانید پرواز را یاد بگیرید، باید راه رفتن را یاد بگیرید.

یادگیری هر یک از آن زبان ها چندان دشوار نیست. منابع زیادی برای همه آنها در دسترس است. کتاب‌ها، دوره‌های آنلاین، و غیره. چیزی که دشوار بود درک این بود که چگونه همه آنها با هم کار می‌کنند تا یک برنامه وب را تشکیل دهند. به طور خاص، برخی تفاوت های خاص بین توسعه یک برنامه وب GIS و یک برنامه وب استاندارد غیر نقشه برداری وجود دارد.

• برخی از بخش‌های جاوا اسکریپت، مانند آبجکت‌ها و JSON، برای درک برنامه‌های GIS وب حیاتی هستند، اما معمولاً در دوره‌های استاندارد توسعه وب اولویت‌بندی نمی‌شوند.
• اکثر دوره های توسعه وب از MySQL به عنوان پایگاه داده پشتیبان استفاده می کنند. این امر منطقی است زیرا در خدمات میزبانی وب ساده و بسیار رایج است. با این حال، اکثر برنامه‌های GIS وب از PostgreSQL به‌عنوان پایگاه داده پشتیبان به دلیل در دسترس بودن PostGIS استفاده می‌کنند. اگر می‌خواهید PostgreSQL را نصب کنید و کد را برای استفاده از PostGIS تغییر دهید، خودتان هستید.
• از آنجایی که برنامه های GIS وب به کتابخانه نقشه برداری جاوا اسکریپت متکی هستند، منطقی است که آنها بر اساس جاوا اسکریپت ساخته شوند و از AJAX برای برقراری ارتباط با سرور استفاده کنند. با این رویکرد PHP فقط برای پاسخ به درخواست های AJAX استفاده می شود. بسیاری از دوره های PHP زمان زیادی را صرف آموزش ساختن برنامه های PHP می کنند که برای برنامه های نقشه برداری مناسب نیستند.
• بسیاری از دوره های PHP روش هایی را برای تعامل با پایگاه داده آموزش می دهند که ذاتاً ناامن هستند. در حالی که یادگیری این روش ها به خاطر سادگی اشکالی ندارد، به نظر من، پایان دادن به دوره بدون آموزش روش های امن تر به دانش آموزان، اشکالی ندارد. یادگیری در مورد مسائل امنیتی و نحوه رسیدگی به آنها زمان زیادی را صرف من کرد، حتی بعد از اینکه می دانستم چگونه به شیوه ای ناامن “کارها را به درستی انجام دهم”.