Whistland: یک سیستم نقشه برداری جمعیتی واقعیت افزوده برای حفاظت مدنی و مدیریت اضطراری

خلاصه

پیشگیری و مدیریت صحیح توالی رویدادهای بلایای طبیعی نقش کلیدی در نجات جان انسان ها دارد. در دسترس بودن سیستم‌های محاسباتی هوشمند تعبیه‌شده و سیار، راه‌های جدیدی را برای مدیریت زمین و زیرساخت‌ها توسط اپراتورهای حفاظت مدنی باز می‌کند. تا به امروز، تحقیقات استفاده از شبکه‌های اجتماعی را برای مدیریت بلایای مرتبط با رویدادهای هواشناسی/هیدروژنیک یا زمین‌لرزه، اما بدون تأکید بر اهمیت یک سیستم یکپارچه، مورد بررسی قرار داده است. ویژگی اصلی سیستم Whistland پیشنهاد شده در این مقاله، استفاده هم افزایی از واقعیت افزوده (AR)، نقشه برداری جمعی (CM)، شبکه های اجتماعی، اینترنت اشیا (IoT) و شبکه های حسگر بی سیم (WSN) با بهره برداری از فناوری ها است. و چارچوب های Web 2.0 و GIS 2.0 برای تصمیم گیری آگاهانه در مورد زنجیره رویدادها. سیستم Whistland از یک سرور جغرافیایی، یک برنامه تلفن همراه با AR و یک داشبورد تجزیه و تحلیل تشکیل شده است. ژئو سرور به عنوان مرکز حسگر و شبکه های اجتماعی عمل می کند. مفهوم انتزاعی در این معنا تبدیل دامنه کاربر به “حسگرهای هوشمند” برای کل حوزه مدیریت بحران است. ادغام شبکه اجتماعی از طریق یک مکانیسم کارآمد اشاره گر انجام می شود که نیاز به ذخیره سازی را از طریق یک برنامه تلفن همراه مبتنی بر موتور واقعیت افزوده پایین نگه می دارد و اطلاعات کیفی را ارائه می دهد که حسگرها قادر به گرفتن آن نیستند. تجزیه و تحلیل بلادرنگ، جستجوهای جغرافیایی و قابلیت بررسی تاریخچه رویدادها با موتور واقعیت افزوده، همگی به ذینفعان کمک می کنند تا وضعیت منابع تحت نظارت/نظارت را بهتر درک کنند.

کلید واژه ها:

حفاظت مدنی ؛ مدیریت اضطراری ؛ واقعیت افزوده ؛ نقشه برداری جمعیت ; شبکه های اجتماعی ؛ شبکه های حسگر ؛ ژئوماتیک ; هیدروژئولوژی

1. انگیزه و کارهای مرتبط

مفاهیم نوظهور مانند واقعیت افزوده (AR)، نقشه برداری جمعی (CM)، شبکه های اجتماعی (به عنوان مثال، توییتر، اینستاگرام، فیس بوک)، اینترنت اشیا (IoT) و شبکه های حسگر بی سیم (WSN) مورد توجه قرار گرفته اند. شرکت ها و محققان برای توسعه برنامه های کاربردی جدید و کاربر محور. با توجه به تازگی آنها، توجه زیادی به بهبود عملکرد که از طریق یکپارچه سازی دقیق تر این زیرسیستم های مختلف حاصل می شود، صورت نگرفته است.

امروزه بسیاری از شبکه‌های اجتماعی با پیاده‌سازی برچسب‌گذاری جغرافیایی محتوا (متن، صدا، تصاویر/فیلم‌ها) در رابط‌های برنامه کاربردی خود (API) برای برنامه‌های تلفن همراه، به وب فضایی نوظهور [ 1 ] کمک می‌کنند. موقعیت جغرافیایی محتوای منتشر شده در شبکه‌های اجتماعی امکان توسعه سیستم‌هایی را فراهم می‌کند که می‌توانند روندهای بلادرنگ را از هر نوع تشخیص دهند. تجزیه و تحلیل مکانی-زمانی روندهای رسانه های اجتماعی برای تشخیص رویدادهای غیرعادی [ 2 ، 3 ] امکان شناسایی رویدادهای کوتاه مدت مورد علاقه در یک منطقه خاص، به ویژه درگیر مردم و مقامات حفاظت مدنی را فراهم می کند.

در اکتبر 2014، شهر جنوا ایتالیا یک حادثه سیل را تجربه کرد. سیستم OpenGenova ( http://www.opengenova.org/maps/angelidelfango/ ، آخرین دسترسی: 7 فوریه 2017) برای ترسیم نقشه منطقه بحران با استفاده از عکس‌ها و هشتگ‌های (جغرافیایی) در شبکه اجتماعی اینستاگرام توسعه داده شد. به طور مشابه، زلزله هائیتی در ژانویه 2010، نقشه‌برداران بحران را بر آن داشت تا از طریق مدل جدیدی از همکاری که شامل نقشه‌های ماهواره‌ای/هوایی و مدل‌های شهر، و همچنین نمودارهای جاده‌ای [4] برای افزایش تراکم اطلاعات در دسترس تیم‌های مدیریتی بود، واکنش نشان دهند . پیامدهای بحران زیرا CM [ 5 ، 6 ، 7 ، 8] از داده‌های جغرافیایی مرموز (تصاویر ماهواره‌ای/هوایی) به دست می‌آید، مزیت در نظر گرفتن هر دو فید CM و AR با هم نشان‌دهنده یک پیشرفت کلیدی برای مدیریت و کنترل بلایای طبیعی است.

AR یک فناوری امیدوارکننده است که در بسیاری از زمینه‌های مختلف مانند میراث فرهنگی [ 9 ، 10 ] ، آموزش [ 11 ]، تجسم جغرافیایی [ 12 ]، نظارت بر محیط زیست [ 13]، و همچنین مدیریت بلایا [14،15 ] استفاده می‌شود . . توانایی انتزاع از طریق تجسم در زمان واقعی اطلاعات عینی که بر تصاویر گرفته شده از دوربین ها پوشانده می شود، تجربه کاربر را افزایش می دهد، به طوری که او می تواند محتوای متنی بهتری را مشاهده و کاوش کند، که اغلب از وب منبع می شود (یعنی محتوای مرتبط با چند رسانه ای یا اطلاعات جغرافیایی مرجع) [ 16 ].

ترکیبی از اطلاعات اجتماعی و داده‌های حسگر خام به‌دست‌آمده به‌طور خودکار می‌تواند برای کاربران سیستم‌های حفاظت مدنی و مدیریت اضطراری مخرب باشد. طی چند سال اخیر، پدیده اینترنت اشیا علاقه زیادی را از سوی گروه های صنعتی و تحقیقاتی در زمینه های مختلف کاربردی برانگیخته است. کار اخیر از استفاده از WSN برای مدیریت بلایا بهره برداری کرده است [ 17 ، 18 ] و آگاهی از زمینه را با جریان فراگیر و مداوم اطلاعات خام افزایش می دهد. گروه تحقیقاتی ما پیشینه ای در شبکه های حسگر دارد [ 19 ، 20 ، 21 ] و قبلاً در مورد مزایای به روز رسانی پایگاه های دانش از طریق جمع آوری داده های کاربر محور [ 22 ] گزارش داده است.].

با شروع از این تجربه نقشه برداری جمعی، ما نمونه اولیه سیستم Whistland را با هدف بهره برداری از پلتفرم های رسانه های اجتماعی و شبکه های حسگر به عنوان منابع داده بلادرنگ (نوآوری) با هدف ارائه یک سیستم تعاملی پیشرفته مدیریت داده به کاربران ارائه کرده ایم. در مورد مفهوم AR

سیستم Whistland AR، نقشه برداری جمعیت، شبکه های اجتماعی، IoT و WSN را برای مدیریت بحران ناشی از رویدادهای طبیعی یکپارچه می کند. ویژگی نوآورانه آن ادغام شبکه اجتماعی از طریق یک مکانیسم جدید اشاره گر است. مکانیسم اشاره گر طوری طراحی شده است که نیاز ذخیره سازی را به حداقل برساند و امکان بازیابی سریع محتوای اصلی را فراهم کند. سیستم پیشنهادی یک راه حل شبکه ای مشارکتی است که امکان تجزیه و تحلیل مکانی-زمانی را از یک پایگاه دانش گسترده و بسیار در دسترس فراهم می کند. علاوه بر این، ادغام همه این فناوری‌ها گامی رو به جلو است و راه‌های جدید و هنوز ناشناخته‌ای را برای توسعه آینده باز می‌کند، همانطور که در بخش 7 بیان شد .

کاربر این سیستم یک شهروند عادی یا یک کارشناس حفاظت مدنی در نظر گرفته شده است. یک برنامه کاربردی تلفن همراه غنی [ 23 ] یک خط لوله بلادرنگ را در دسترس قرار می دهد و اطلاعات به دست آمده از طریق موتور AR خود را در مورد آنچه در منطقه اطراف اتفاق می افتد ارائه می دهد. این جنبه شبکه ای که به طور طبیعی به عنوان عنصری از طراحی وجود دارد به سایر کاربران اجازه می دهد تا به طور مؤثر مشارکت کنند و همچنین داده ها را از شبکه های حسگر به طور کلی بازیابی کنند. مشارکت ایجاد شده توسط کاربر صرفاً اطلاعاتی است که در این مرحله مبتنی است. این شامل چند رسانه ای، مانند متون، تصاویر، صدا/فیلم و مدل های سه بعدی است.

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

این مقاله به شرح زیر تنظیم شده است:

بخش 2 سناریوهای معناداری را برای هدف قرار دادن برنامه در زمینه گسترده ای از برنامه های ممکن برای حفاظت مدنی و مدیریت اضطراری ارائه می دهد. در بخش 3 ، معماری کلی سیستم ارائه شده است که اجزای اصلی را با ویژگی های اصلی آنها مشخص می کند. بخش 4 مؤلفه سمت سرور را که اطلاعات را ذخیره و مدیریت می کند، توضیح می دهد. در بخش 5 ، جزئیات برنامه تلفن همراه با اشاره خاص به فناوری AR در داخل نشان داده شده است، در حالی که بخش 6 پلت فرم وب-GIS سبک را ارائه می دهد که برای تجزیه و تحلیل داده ها پیاده سازی شده است. بخش 7 نتیجه گیری و کارهای آینده برنامه ریزی شده را بیان می کند.

2. سناریوها

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

همراه با شبکه‌های حسگر که امکان اندازه‌گیری مداوم و تغذیه داده‌ها را فراهم می‌کنند، هر مرحله نظارتی باید بررسی‌های دوره‌ای در محل را نیز فراهم کند. کاهش سیستماتیک این گونه بررسی ها، با حفظ سطح نظارت کافی، کارایی عملیاتی سیستم را افزایش می دهد.

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

با گسترش این امر به متخصصان مدیریت قلمرو، همان اصل اعمال می شود. اپراتورهای حفاظت غیرنظامی که مسئول جمع آوری داده ها در مورد یک منطقه خاص تحت کنترل خود هستند، پتانسیل های خطر را با جزئیات بیشتری ارزیابی می کنند. واضح است که داده‌های جمع‌آوری‌شده توسط متخصصان باید به وضوح تفاوت‌ها یا تغییرات در پتانسیل خطر یک سیستم منطقه‌ای تأسیسات را شناسایی کند [ 24 ].

با در دسترس بودن پیشنهادی چنین سیستمی که به عنوان مثال تصاویر دارای برچسب جغرافیایی را جمع‌آوری می‌کند و آنها را در نماهای واقعیت افزوده نشان می‌دهد، حجم کاری اپراتور برای جمع‌آوری داده‌ها با همان جهت کاهش می‌یابد که به نوبه خود قابلیت اطمینان بیشتری را ایجاد می‌کند. همین مفهوم در فعالیت‌های پس از رویداد، یعنی برای گزارش‌های خسارتی که توسط مقامات تهیه می‌شود، معنادار است. این مزیت نسبت به پروژه اتحادیه اروپا کوپرنیک دارد ( http://www.copernicus.eu ، آخرین دسترسی: 7 فوریه 2017)، به این دلیل که یک رویکرد نقشه برداری جمعی برای ترسیم زمینه قبل و بعد از یک رویداد خاص می تواند یکپارچه شود. آن اطلاعات به روشی مؤثرتر از روشی که از روشی جهانی و فراگیر برای بازیابی اطلاعات متنی در مورد محیط استفاده می کند.

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

برای کشف این، می‌توانیم یک سناریوی نمونه را ترسیم کنیم، به ویژه برای سیستم پشتیبانی تصمیم (DSS) که تعامل بین شهروندان و حفاظت مدنی را در طول یک رویداد سیلاب ایجاد می‌کند.

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

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

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

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

3. معماری سیستم

معماری Whistland (نگاه کنید به شکل 1 ) بر روی سه جزء اصلی ساخته شده است:

GeoData Collector سروری است که وظیفه جمع آوری داده ها از شبکه های اجتماعی و تجزیه و تحلیل داده ها را بر عهده دارد. همچنین می‌تواند کیفیت اطلاعات را با بهره‌برداری از سایر منابع داده‌های جغرافیایی بهبود بخشد. اینها به ویژه می‌توانند پایگاه‌های داده‌های جغرافیایی (مانند PostGIS، Oracle، موتور پایگاه داده فضایی Esri ArcSDE و SpatiaLite)، فایل‌های جغرافیایی (مثلاً GeoJSON، زبان نشانه‌گذاری جغرافیایی GMland Shapefile) یا خدمات نقشه‌برداری وب (مانند خدمات نقشه وب WMS، وب) باشند. سرویس ویژه WFS، سرویس پوشش وب WCS و سرویس پردازش وب WPS).
برنامه موبایل قادر است اطلاعات مرتبط با واقعیت افزوده در مورد محیط یا رویداد را نشان دهد.
داشبورد Analytics تجزیه و تحلیل رویدادها را با استفاده از متن ساده و تجسم های سفارشی روی نقشه ها (حرارت) امکان پذیر می کند.

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

سیستم نمونه اولیه فعلی از طریق API خود به شبکه اجتماعی توییتر به عنوان منبع اصلی اطلاعات دسترسی دارد. منطقی که برای انتخاب توییتر استفاده می‌شود، معماری بومی آن مبتنی بر پیام‌های کوتاه است که حاوی پیوندهایی به محتوای خارجی است که به‌عنوان URI بیان شده‌اند، همچنین با مفهوم هشتگ برای دسته‌بندی «کلمه کلیدی» توییت‌ها پشتیبانی می‌شود. این جنبه مفهوم داده های پیوندی (باز) (LOD) را نیز برای اهداف حفاظت مدنی امکان پذیر می کند [ 25]]. این به هیچ وجه یک عامل محدود کننده نیست، زیرا Whistland از ساختارهای داده و ماژول های نرم افزاری استفاده می کند که قابل توسعه هستند و به سایر ارائه دهندگان اجتماعی متصل می شوند. تعاملات بین اجزای سیستم ها از Whistland API استفاده می کند و از ارتباط با شبکه های اجتماعی شفاف است. به راحتی می توان رابط های دیگر را در هر مؤلفه وصل کرد تا سایر شبکه های اجتماعی (مثلاً فیس بوک) یا منابع اطلاعاتی را از طریق REST API در بر گیرد. مدل داده های داخلی نیز کاملاً کلی است به طوری که ساختار اطلاعات استخراج شده از API های خارجی نیز به راحتی قابل تغییر است. توییتر یک شبکه پاسخگو و سریع با سربار کم و پوشش داده گسترده است که به طور خاص برای افراد در هر سطح از جامعه هدف قرار گرفته است. این توپولوژی به خوبی با فلسفه Whistland مطابقت دارد، و ما API توییتر را در این مرحله با موفقیت مستقر کرده ایم. به ویژه، برای فعال کردن جمع آوری و تجزیه و تحلیل داده ها، API جستجوی توییتر امکان جستجوی توییت ها را بر اساس فیلترهای سفارشی می دهد.

با این حال، هنگام استفاده از توییتر برای این منظور محدودیت مهمی وجود دارد. API اجازه جستجو برای محتوای قدیمی‌تر از 6 تا 9 روز را نمی‌دهد. این به نوبه خود به شخص اجازه نمی دهد که از توییتر در حالت مستقیم، یعنی به عنوان ارائه دهنده محتوا استفاده کند. برای جبران این محدودیت، یک رویکرد تغذیه برنامه ریزی شده در سیستم طراحی شده است.

در زیر بخش های بعدی به بررسی اجمالی معماری طراحی شده با اجزای اصلی و تعاملات خواهیم پرداخت. هر جزء در بخش اختصاصی به تفصیل توضیح داده خواهد شد.

3.1. گردآوری داده های جغرافیایی

GeoData Collector به صورت دوره ای محتوای Twitter را از طریق Twitter Search API در حالت دسته ای واکشی می کند. محتوای بازیابی شده را می توان در سرور ذخیره کرد، اما ذخیره هر توییت خام می تواند پایگاه داده توییتر را منعکس کند. بنابراین، برای کاهش اتلاف منابع ذخیره‌سازی و محاسباتی (مورد نیاز برای تجزیه و تحلیل داده‌های بزرگ)، رویکردی که ما اتخاذ کردیم، تنها یک اشاره‌گر به توییت تحلیل‌شده ذخیره می‌کند. با استفاده از این راه‌حل اشاره‌گر، هر برنامه مشتری می‌تواند اطلاعات اصلی یک توییت را از طریق Twitter REST API یکپارچه کند، که برخلاف API جستجوی توییتر، محدودیت زمانی برای جستجو ندارد.

علاوه بر اشاره گر، GeoData Collector می تواند ابرداده های تکمیلی، مانند مکان جغرافیایی، مهر زمانی و شناسه کاربری که محتوا را تولید کرده است را ذخیره کند. تمام اطلاعات بازیابی شده توسط سرور در طی مراحل تغذیه آن، از طریق یک سرویس وب RESTful ( Whistland History API ) در دسترس مشتریان قرار می گیرد. انگیزه انتخاب یک وب سرویس RESTful دو جنبه دارد: اول، استفاده از وب سرویس، جفت شدن بین سرور و کلاینت ها ضعیف باقی می ماند و ویژگی های RESTful مقیاس پذیری زیادی را در سمت سرور و همچنین امکان پذیر می کند. توسعه تین مشتریان؛ ثانیاً، در مقایسه با خدمات وب SOAP (پروتکل دسترسی به شیء ساده) [ 26]، خدمات وب RESTful منابع سرور کمتری را مصرف می کنند.

3.2. اپلیکیشن موبایل

در سطح بعدی، هدف صریح برنامه موبایل تقویت واقعیت هم برای اطلاعات اخیر (و هم زمان) موجود (“توئیت شده”) در توییتر و هم برای اطلاعات تاریخی است که دیگر از طریق APIهای رسمی قابل بازیابی نیستند. Whistland History API اطلاعات قدیمی را مدیریت می کند، در حالی که Twitter REST API و Twitter Streaming API به ترتیب برای مدیریت اطلاعات فعلی و فعال کردن اعلان بلادرنگ در مورد فیدهای محتوای جدید استفاده می شوند. مضرات استفاده از چندین API برای برنامه تلفن همراه ناشی از الزام به نازک نگه داشتن GeoData Collector تا حد امکان با انتقال پیچیدگی به سمت مشتری است.

بنابراین، نقش جمع‌آوری داده‌های جغرافیایی عمداً به یک منبع داده تاریخی جدا می‌شود، و این جداسازی به آن اجازه می‌دهد تا مقیاس بهتری داشته باشد، زیرا هر برنامه تلفن همراه یک ارتباط باز با API توییتر نگه می‌دارد، در حالی که API تاریخچه Whistland فقط یک بار برای اطلاعات تاریخی را بیاورید به این ترتیب، بدون نیاز به واکشی مستقیم و مداوم توییت‌ها از توییتر، GeoData Collector می‌تواند دانلود سریع‌تری از محتوا را فراهم کند. نتیجه مطمئناً یک تعامل AR پاسخگوتر است که منجر به کارایی بیشتر از نظر عملکرد نرم افزار می شود.

برای اینکه کاربران بتوانند محتویات (چندرسانه‌ای، مدل‌های سه‌بعدی و اطلاعات حسگر) را در یک رویکرد یکپارچه کاوش کنند، برنامه موبایل از API محتوای Whistland ویژه ارائه‌شده توسط GeoData Collector استفاده می‌کند . در نهایت، کاربران، از طریق پروفایل های توییتر خود، می توانند توییت ها را از طریق Whistland Publish API سرور منتشر کنند. این راه حل توییت های تولید شده با ذخیره محلی روی سرور باعث ایجاد یک مدار پیام رسانی مستقل می شود.

3.3. داشبورد تجزیه و تحلیل

در مؤلفه داشبورد Analytics ، به دلیل وجود API Whistland Analytics که توسط GeoData Collector ارائه شده است، چندین نما تجزیه و تحلیل برای هر رویداد ثبت شده در دسترس قرار گرفته است . برای هر رویداد، شاخص‌های مصنوعی که به شکل داده‌های جدولی و نقشه‌های حرارتی ظاهر می‌شوند در دسترس هستند: همه لایه‌های اطلاعاتی بر حسب تقاضا ایجاد می‌شوند و با توجه به بهینه‌سازی اعمال شده روی سرور، می‌توانند بر اساس فاصله زمانی در زمان واقعی تقسیم شوند. ساختارهای داده. پس از اعمال در ساختار داده و سطوح تدارکات، چنین فیدهای قدرتمند تقریباً اجتناب ناپذیر هستند. به ویژه، آنها از طراحی Whistland به حداکثر بهره برداری می کنند و راه را برای توسعه آینده هموار می کنند.

4. جمع آوری داده های جغرافیایی

ویژگی های اصلی GeoData Collector عبارتند از:

واکشی توییت ها از توییتر؛
ذخیره کارآمد توییت ها؛
انجام پرس و جوهای جغرافیایی با فیلتر زمانی.
API را برای برنامه های خارجی (به عنوان مثال، برنامه تلفن همراه ، داشبورد Analytics یا نرم افزار/برنامه شخص ثالث) در معرض نمایش قرار دهید.

GeoData Collector بر روی یک پلتفرم منبع باز، مبتنی بر توزیع لینوکس با هسته 64 بیتی توسعه یافته است. پایگاه داده شی-رابطه ای PostegreSQL به عنوان سیستم مدیریت پایگاه داده رابطه ای ذخیره سازی اصلی RDBMS به دلیل سازگاری با PostGIS آن انتخاب شده است که پشتیبانی از اشیاء جغرافیایی را اضافه می کند که امکان پرس و جوهای فضایی را در SQL فراهم می کند. سرور تمام اطلاعات را از طریق یک وب سرویس RESTful ارائه می دهد که با زبان PHP توسعه یافته و توسط یک سرور HTTP Apache قابل اعتماد ارائه می شود.

API های Whistland که توسط وب سرویس RESTful در معرض دید قرار گرفته اند، در بالای چارچوب Slim ( http://www.slimframework.com ، آخرین دسترسی: 7 فوریه 2017) برای PHP توسعه یافته اند، در حالی که احراز هویت، مجوز و منطق تجاری به اشتراک گذاشته شده است. در میان نقاط پایانی و از طریق پیاده سازی سفارشی تحقق می یابد.

ما یک مدل پایگاه داده را طراحی کردیم که در شکل 2 خلاصه شده است ، به طوری که می تواند نشانگرهای توییت های بازیابی شده ( TweetPointer ) را ذخیره کند، آنها را به رویدادها و مناطق متصل کند، زیرا کاربران بیشتر علاقه مند به رویدادهایی هستند ( رویداد ) که بر برخی مناطق خاص تأثیر می گذارد ( رویداد ). منطقه ).

TweetPointer از طریق ویژگی‌هایی ( جدول 1 ) که از توییت اصلی مشتق شده‌اند و سایر ویژگی‌هایی که از سیستم محلی محاسبه شده‌اند، ترکیب می‌شود تا آن را با یک رویداد ( event_id ) مرتبط کند و آن را با یک منطقه ( region_id ) شناسایی کند. هر اشاره گر توییت حداقل از 84 بایت استفاده می کند، که در صورت ذخیره متن، این حداقل ممکن است تا 224 (84 بایت برای اطلاعات مصنوعی و 140 بایت برای متن) افزایش یابد.

در اینجا توجه داشته باشید که نسبت بین اندازه اشاره گر و اندازه داده خام 0.375 است، که نشان می دهد این رویکرد می تواند تقریباً سه برابر بیشتر از روشی که داده ها به صورت محلی در سرور ذخیره می شوند، داده ها را مدیریت کند. علاوه بر این، اگر داده‌های مرتبط (مانند تصاویر، اشاره‌های کاربر و غیره) در ارزیابی لحاظ شوند، مزایای رویکرد اشاره‌گر بیشتر خواهد بود. به طور خاص، ممکن است به دلیل کاهش هزینه‌های ارتباطی با حذف فلسفه ذخیره‌سازی داده‌های خام، مزیت قابل‌توجهی وجود داشته باشد.

فیلد مکان (از پسوند PostGIS) و قسمت post_date برای ارائه تجزیه و تحلیل مکانی و زمانی بر حسب تقاضا از طریق API Whistland Analytics نمایه می شوند . همچنین GeoData Collector می‌تواند تجزیه و تحلیل‌های انجام‌شده را بایگانی کند تا عملیات خواندن سریع‌تر را امکان‌پذیر کند. فیلد flags اطلاعات مربوط به فراداده توییت را ذخیره می کند، مانند وضعیت بازتوییت آن، در دسترس بودن تصاویر یا URL در بدنه. این فیلد برای غنی سازی رابط کاربری ارائه شده به کاربران بدون سربار تماس های شبکه برای همه توییت های قابل مشاهده مفید است.

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

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

جمع‌آوری داده‌های جغرافیایی ، با استفاده از روش تغذیه، به‌طور سیستماتیک و سریع نشانگرهای توییت‌ها را جمع‌آوری می‌کند. این مرحله از نظر فنی در یک اسکریپت PHP برای به حداکثر رساندن استفاده مجدد از کد پیاده سازی شده است، این مرحله شامل یک فرآیند دسته ای است که برنامه ریزی شده برای اجرا در یک بازه زمانی از پیش تعریف شده برنامه ریزی شده است. برای هر رویداد فعال ، مجموعه عملیات زیر را انجام می دهد:

شناسه آخرین توییت ( lt_id ) بازیابی شده در فیدهای قبلی را بررسی کنید.
اگر lt_id در دسترس است (بعد از اجرای اجرای حداقل یک توییت برای رویداد فعلی )، آن را به عنوان یک کران پایین در API جستجوی توییتر تنظیم کنید تا از تجزیه و تحلیل مجدد بخش عمده ای از محتوایی که قبلاً تجزیه و تحلیل شده است جلوگیری کنید.
پرس و جو را با استفاده از فیلتر جستجوی مشخص شده برای رویداد فعلی تنظیم کنید .
جستجو را در توییتر اجرا کنید، هر صفحه از محتویات را (از آنجایی که نتایج API جستجوی توییتر صفحه‌بندی می‌شوند) تا کران پایین.
برای هر توییتی که با موفقیت بازگردانده شده است، اطلاعات را دقیق تر کنید (با استفاده از کلاس TweetProxy ) و یک شی TweetPointer ایجاد کنید (با فراخوانی روش buildTweetPointer ).
lt_id رویداد فعلی را به‌روزرسانی کنید تا در اجرای بعدی کران پایین‌تری داشته باشید.

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

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

در واقع، یک مدیر سیستم ممکن است تصمیم بگیرد یک کلاس سفارشی (به عنوان مثال کلاس های TweetProxy را گسترش دهد و روش پایه buildTweetPointer را لغو کند ) برای هر رویداد تعیین کند. این اضافه بار مؤثر سپس روش ها و تحلیل ها را به غیر از رفتار پیش فرض تخصصی می کند.

از آنجایی که فرآیند تغذیه اطلاعات یک کار دوره ای است، همه توییت های منتشر شده را نمی توان مستقیماً توسط GeoData Collector مدیریت کرد . به عنوان مثال، اگر این کار هر روز در نیمه شب برنامه ریزی شده بود، برنامه ای که در ظهر اجرا می شود در نهایت دوازده ساعت آخر توییت ها را از دست می دهد، اگر فقط اطلاعات مدیریت شده توسط GeoData Collector را بارگیری کند .

بنابراین، در تلاش برای پرداختن به این مشکل، برنامه‌های سرویس گیرنده باید اطلاعات بازیابی شده از GeoData Collector (از طریق Whistland History API آن ) را با توییت‌هایی که با API جستجوی توییتر قابل بازیابی هستند، یکپارچه کنند. علاوه بر این، فرآیند تغذیه می‌تواند توسط کاربرانی که دارای امتیازات سرپرست هستند مجبور شوند تا اطلاعات یک رویداد را در اسرع وقت استخراج کنند. این فرصت ممکن است برای اپراتوری مفید باشد که نیاز به تجزیه و تحلیل بر روی داده های به روز شده دارد.

برای فعال کردن یک برنامه مشتری برای بارگیری دارایی‌های ویژه با Whistland Content API ، محتویات در لایه‌ها سازماندهی می‌شوند و در نهایت به یک رویداد و/یا به یک منطقه متصل می‌شوند . یک لایه می‌تواند یک GeoService باشد که خدمات نقشه‌برداری وب (WMS، WFS، WCS) را در معرض نمایش قرار می‌دهد، یا در عوض، می‌تواند داده‌های مرجع جغرافیایی را در یک سری از PointOfInterest گروه‌بندی کند .

این داده‌های جغرافیایی منبعی ذخیره‌شده یا پیوندی هستند، از طریق DataContent که معمولاً برای متون، جداول، تصاویر، فایل‌های صوتی/فیلم‌ها و مدل‌های سه‌بعدی استفاده می‌شوند، اما همچنین برای مجموعه‌های تصویری چند زمانی استفاده می‌شوند. این داده‌ها را می‌توان با استفاده از برنامه تلفن همراه با فیلتر موتور واقعیت افزوده، توییت‌هایی که به منطقه جغرافیایی و/یا محدودیت زمانی خاص مرتبط نیستند، کاوش کرد.

در حال حاضر، برای داده‌های حسگر، از DataContent با جدول داده‌های قابل پرسش استفاده می‌کنیم. به طور متفاوت، ما DataService را برای توسعه پشتیبانی از استاندارد OGC-SWE (“Open Geospatial Consortium-Sensor Web Enablement”) مدل کردیم [ 27 ]. به دلیل این استاندارد، مشتریان مجاز می توانند به حسگر متصل شوند، پرس و جو کرده و اطلاعات را مستقیماً از آن به دست آورند، بنابراین تلاش سرور را بیشتر برای مرحله بازیابی داده تخلیه می کنند. با توجه به انعطاف‌پذیری پلتفرم توسعه‌یافته، حسگرهایی که به‌عنوان PointOfInterest با جریان داده‌های قابل استعلام مرتبط نشان داده می‌شوند، به‌عنوان منبع اطلاعات اضافی همراه با متون، تصاویر، صدا/فیلم، مدل‌های سه بعدی و سایر منابع ذخیره‌شده/پیوند شده در دسترس خواهند بود. بر اساس مجموعه همه کاره ازAPI های Whistland ، این رویکرد انعطاف پذیری گسترده ای را برای رسیدگی به سناریوهای مختلف و اجازه دادن به ماژولار بودن در توسعه برنامه های کاربردی مشتری را تضمین می کند.

5. برنامه موبایل

ویژگی های اصلی اپلیکیشن موبایل عبارتند از:

یک منطقه را که محتوای چند رسانه ای را نیز پیوند می دهد (نقشه برداری جمعیت) برچسب جغرافیایی بزنید.
نقطه مورد علاقه (POI) را نزدیک به منطقه کاربر فعلی ببینید.
واکشی داده های تاریخی؛
مشاهده داده های زمان واقعی از سنسورها.
در صورت عدم اتصال به اینترنت، محتوای کش را ذخیره کنید.

دید کاربران در کل به عنوان «حسگرهای» فراگیر که از طریق دستگاه‌های هوشمندشان فعال می‌شوند، خواسته‌های خاصی را برای طراحی اپلیکیشن موبایل ایجاد می‌کند. در چرخه توسعه فعلی، برنامه تلفن همراه بر روی اکوسیستم اندروید میزبانی می‌شود، اما به دلیل استفاده از پلتفرم‌های متقابل SDK که برای تعامل AR استفاده می‌شود، می‌توان به نتایج مشابهی در پلتفرم‌های دیگر، مانند iOS یا Windows Phone، با کمی تلاش بیشتر دست یافت. و تجسم سه بعدی هدف اصلی این اپلیکیشن ارائه ابزارهای کمکی برای مدیریت رویداد به کاربران است. به طور خاص، از طریق رابط AR، کاربران می توانند به اطلاعات ذخیره شده جغرافیایی دسترسی پیدا کنند تا از محتوای رویداد محیط (های) محلی خود آگاه شوند. موتور AR تجسم POI را در یک منطقه معین قادر می‌سازد و داده‌های غیر مرتبط را فیلتر می‌کند. این یک راه آسان برای کاوش محتوایی است که به منطقه واقعی کاربر “پیوند” است. رابرنامه موبایل این قابلیت را با بهره گیری از اطلاعاتی که سرور از طریق یک کلاینت RESTful در معرض نمایش قرار می دهد، ارائه می دهد.

5.1. معماری

از آنجایی که تجزیه و تحلیل رویداد محور است، اولین گام بازیابی همه رویدادهای بالقوه مورد نیاز یک کاربر نهایی است. با انتخاب رویداد از یک نمای شبکه ای (در ابتدا فقط با رویدادهای فعال فیلتر شده بود)، کاربر می تواند مستقیماً وارد حالت AR شود. در همین حال، برنامه به صورت ناهمزمان و به صورت صفحه بندی شده، توییت های انتخاب شده را بارگذاری می کند تا به سرعت آنها را در کنسول نمایش دهد. توییت‌های انتخاب‌شده به‌صورت زمانی مرتب شده و با بهره‌برداری از ساختار داده بهینه‌شده TweetPointer ، همانطور که در بخش 4 توضیح داده شد، به‌صورت مکانی فیلتر می‌شوند .

برنامه موبایل عکس فوری رویداد (فرمت JSON) را از GeoData Collector از طریق Whistland History API دریافت می کند و آن را با اطلاعات توییت های فعلی قابل بازیابی با Twitter REST API، همانطور که در بخش 4 توضیح داده شده است، یکپارچه می کند . در نهایت، برای اینکه مشتری در زمان واقعی به انتشار توییت‌های جدید واکنش نشان دهد، از Twitter Streaming API نیز استفاده شده است. به این ترتیب، این سه API ( Whistland History API ، Twitter REST API، Twitter Streaming API) در یک مؤلفه منحصربه‌فرد ادغام شده‌اند تا مدیریت یکنواخت را در سمت رابط کاربری فعال کنند.

به طور خاص، TweetPointer یک زیر مجموعه منحصر به فرد از یک توییت عمومی است. بنابراین، هر توییت بازیابی شده با استفاده از API توییتر به TweetPointer مربوطه خود تبدیل می شود . به این ترتیب، تمام TweetPointer ها ابتدا در اشیاء TweetContent پیچیده می شوند . سپس اینها در حافظه پنهان ذخیره می شوند و مانند DataContent به کنترل کننده AR ارسال می شوند .

5.2. واقعیت افزوده

فعالیت AR از طریق Metaio SDK ساخته شده است ( http://www.metaio.com/sdk ، آخرین دسترسی: 1 اکتبر 2015): با توجه به خرید اخیر شرکت Metaio توسط Apple Inc.، کار در حال انجام است تا سایر موارد را اتخاذ کند. AR-SDKهایی که جدیدترین استاندارد زبان نشانه گذاری واقعیت افزوده (ARML) 2.0 را اجرا می کنند [ 28 ]. Metaio SDK به این دلیل انتخاب شد که یک AR-SDK چند پلتفرمی را با ثبات عالی در ردیابی (بر اساس مکان، بر اساس نشانگر و مبتنی بر تصویر) و مدیریت آسان محتوای چند رسانه ای (صوتی/تصویری و مدل های سه بعدی) ارائه می دهد.

برای هر TweetContent ارائه شده ( ویژگی ، در استاندارد ARML)، یک نشانگر سه بعدی ( VisualAsset ، در استاندارد ARML) در بالای تصاویر گرفته شده توسط دوربین دستگاه ترسیم می شود. این نشانگر بر اساس مختصات آن ( لنگر ، در استاندارد ARML) و وضعیت فعلی GPS و قطب نما روی دستگاه قرار می گیرد و می چرخد. نشانگر یک POI را نشان می دهد و در یک مکان جغرافیایی خاص به عنوان محتوای AR با استفاده از ردیابی مبتنی بر مکان، همانطور که در شکل 3 نشان داده شده است، قرار می گیرد .

علاوه بر این، فاصله بین موقعیت فعلی دستگاه و نشانگر سه‌بعدی در دنیای واقعی، مسئول اندازه نشانگر صفحه یا خود گرافیک است: نشانگر صفحه نزدیک‌تر اندازه بزرگ‌تری نسبت به نشانگر دیگر دارد. اگر کاربر یک نشانگر صفحه نمایش را لمس کند، برنامه سعی می کند با استفاده از Twitter REST API اطلاعات اصلی مربوط به توییت اصلی را بازیابی کند.

هنگامی که توییت اصلی بازیابی شد، محتوای آن طبق معمول توسط شی TweetContent کش و بسته بندی می شود ، بنابراین اقدامات بعدی نیازی به تماس شبکه دیگری ندارد. این مکانیسم بسته بندی بر روی مؤلفه ای که سه جریان API را خطی می کند، پیاده سازی شده است. برای سرعت بخشیدن به روند بازیابی، همه محتوای Tweet از APIهای توییتر دارای یک مرجع آماده به توییت اصلی هستند. وقتی این در دسترس باشد، یک پانل پوشاننده اطلاعات اصلی مانند کاربر (آواتار، نام و نام خانوادگی)، متن و تاریخ توییت و در نهایت تصویر پیوست شده را نمایش می‌دهد.

علاوه بر این، برای هر رویداد، یک پانل جمع آوری تمام دارایی های ویژه ای که ممکن است برای تجزیه و تحلیل مورد علاقه هستند در دسترس باشد: برنامه تلفن همراه از فرمت های رایج برای تصاویر، صداها/فیلم ها و مدل های سه بعدی پشتیبانی می کند.

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

پلاگین سه بعدی در بالای کتابخانه های VES/VTK ( http://www.vtk.org ، آخرین دسترسی: 7 فوریه 2017) ساخته شده است و امکان کاوش و استفاده پیشرفته از مدل های مدیریت شده را فراهم می کند. این به عنوان یک افزونه خارجی برای نازک نگه داشتن برنامه اصلی تا حد امکان و مناسب ساختن آن برای عملکرد دستگاه قدیمی توسعه داده شد. علاوه بر این، انتخاب استفاده از یک افزونه خارجی، ماژولاریت بیشتری را به اپلیکیشن موبایل می‌دهد، که کاملاً مطابق با فلسفه و الزامات مهندسی نرم‌افزار پروژه Whistland است.

5.3. سیستم کش

دستگاه های تلفن همراه مصرف کننده معمولاً در شبکه های تلفن همراه عمومی بدون ضمانت خاصی برای قابلیت اطمینان و در دسترس بودن کار می کنند. فقدان اتصال پایدار مشکل مهمی است که باید در مواقع اضطراری مدنی برطرف شود. به همین دلیل، TweetContent و دیگر ساختارهای داده مدل‌سازی می‌شوند تا ذخیره‌سازی آن‌ها در یک زیرسیستم کش امکان‌پذیر شود. از آنجایی که پلتفرم‌های اندروید (و سایر پلتفرم‌ها) شامل یک پایگاه داده SQLite در سیستم‌عامل هستند، زیرسیستم کش از آن برای بهره‌گیری از ابزار نگاشت ارتباطی شی (ORM) استفاده می‌کند. وقتی اتصال داده در دسترس باشد، برنامه محتویات را از توییتر و از GeoData Collector بازیابی می کند، آن را در زیرسیستم کش ذخیره می کند و در نهایت سیستم های موجود را به روز می کند. هنگامی که اتصال داده در دسترس نیست، برنامه از محتویات ذخیره شده در زیرسیستم کش به عنوان منبع جایگزین برای لودرهای Android استفاده می کند و در صورت نیاز امکان کاوش واقعیت افزوده بدون دسترسی به اینترنت را فراهم می کند. ماژول برنامه AR همیشه TweetContent ها را از زیرسیستم کش به روشی شفاف بارگیری می کند و عملیات بازیابی را محول می کند ( شکل 4 را ببینید ).

5.4. مدیریت اطلاعات

فرصتی برای کاربر که به عنوان یک نقشه‌بردار جمعیت عمل می‌کند، برای نوشتن پستی درباره رویدادی که در حال حاضر در حال «کاوش» است، یکی دیگر از ویژگی‌های ضروری است که در سمت مشتری پیاده‌سازی شده است. از همان ابزار ORM برای ذخیره محلی توییت‌های معلق نوشته شده توسط کاربر برنامه استفاده شده است. این انتخاب برای رفع مشکل عدم اتصال به سرور انجام شده است. اگر کاربر در حالی که دستگاه آفلاین است، پستی بنویسد، سیستم تمام اطلاعات را در حافظه محلی فلش ذخیره می‌کند و آن را به‌عنوان در انتظار علامت‌گذاری می‌کند، که این روش استاندارد برای سرویس‌های ابری قابل استفاده است. هنگامی که یک اتصال داده مناسب در دسترس قرار می گیرد، برنامه توسط سیستم اندروید از طریق یک هدف پخش مطلع می شود: در این زمان، یک سرویس Android شروع می شود و تمام توییت های در انتظار ذخیره شده در حافظه پنهان را ارسال می کند.Whistland Publish API به GeoData Collector ، که در واقع آنها را از طرف کاربرانی که وارد شده اند در توییتر پست می کند.

همچنین می‌توان لایه‌های دیگر را جدا از منبع اجتماعی اطلاعات در نمای AR پوشاند. برای مقابله با برخی از الزامات در سناریوهای نشان داده شده در بخش 2 ، ما در حال حاضر در حال توسعه نسخه جدیدی از سیستم Whistland هستیم که قادر به مدیریت حسگرهای فعال برای استاندارد OGC-SWE است. به طور خاص، GeoData Collector به عنوان یک رجیستری از حسگرهای جغرافیایی مرجع عمل می کند و ابرداده های خود را در اختیار برنامه های مشتری قرار می دهد. چنین اطلاعاتی نمونه ای از مواردی است که می تواند نمای AR را همراه با فید اجتماعی افزایش دهد. این قابلیت سودمندی و تخصص برنامه را به محیط‌های مختلف گسترش می‌دهد و معیارهای شخصی‌سازی و عملکرد کلی آن را مطابق با آنچه یک سازمان ممکن است انتظار داشته باشد، ارتقا می‌دهد.

قابلیت حسگر به مشتری اجازه می‌دهد حسگرها را در نمای AR بومی‌سازی کند و اطلاعات آن‌ها را با استفاده از استاندارد سرویس مشاهدات حسگر ( http://www.opengeospatial.org/standards/sos ، آخرین دسترسی: 7 فوریه 2017) بازیابی کند. با توجه به نوع حسگر درگیر، نمای AR می تواند این اطلاعات را به درستی ارائه کند: به عنوان مثال، یک سنسور روی پل با وضعیت هشدار می تواند به عنوان یک دارایی چشمک زن قرمز ارائه شود تا توجه اپراتور را به خود جلب کند. همچنین می توان وسایل نقلیه را به عنوان حسگرهای متحرک در نظر گرفت (یک PointOfInterest با مکان پویا) و به راحتی آنها را در نمای AR ادغام کرد تا تمام عناصر مورد نیاز سناریوهای توضیح داده شده را فراهم کند. غنی سازی بصری برنامه دستی حاصل واضح است.

در نهایت، برنامه تلفن همراه به کاربر اجازه می دهد تا به داشبورد تجزیه و تحلیل ، همانطور که در بخش 6 توضیح داده شده است، دسترسی داشته باشد ، که به گونه ای طراحی شده است که به راحتی در دستگاه های تلفن همراه قابل مشاهده است.

6. داشبورد تجزیه و تحلیل

ویژگی های اصلی داشبورد Analytics عبارتند از:

ایجاد گزارش رویدادها/مناطق/ترکیبات آنها (جغرافیایی پرس و جو)؛
ایجاد نقشه های حرارتی برای مشاهده نتیجه ژئو پرس و جو.
برای تمرکز روی یک بازه زمانی معین، یک فیلتر زمانی اعمال کنید.

برای درک بهتر منطقه جغرافیایی درگیر در یک رویداد یا دانستن و تجزیه و تحلیل همه رویدادهایی که بر یک منطقه خاص تأثیر گذاشته اند، داشبورد وب ابزاری انعطاف پذیرتر و قابل استفاده تر است. داشبورد Analytics دقیقاً بر روی این خطوط طراحی شده است و با یک موتور قالب پاسخگو به نام Bootstrap ( http://www.getbootstrap.com ، آخرین دسترسی: 7 فوریه 2017) ساخته شده است.

یک کلاینت نازک جاوا اسکریپت با بهره‌برداری از RESTful Whistland History API و API Whistland Analytics که توسط GeoData Collector ارائه شده است، پیاده‌سازی شده است: سرور فقط اطلاعات متنی (فرمت JSON) را برمی‌گرداند، به طوری که مشتری مسئول پردازش بیشتر و رندر است. به این ترتیب، سرور توسط عملیات غیرضروری (یعنی پردازش و رندر) بیش از حد بارگذاری نمی‌شود و بار بین همه مشتریان توزیع می‌شود و به طور موثر یک چارچوب محاسباتی توزیع شده را به عنوان بخشی طبیعی از طراحی پیاده‌سازی می‌کند.

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

نقشه حرارتی geo-tweet فقط توییت هایی را با مختصات GPS اختصاص داده شده در نظر می گیرد و توییت هایی را که هیچ مختصات صریحی ندارند نادیده می گیرد. برای مثال شکل 5 را ببینید . نقشه حرارتی منطقه کلان به مفهومی که در بخش 4 نشان داده شده است ، از ناحیه مرتبط با فیلتر کردن توییت‌های توییت بدون مناطق مرتبط اشاره دارد.

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

هر دو نقشه حرارتی می‌توانند متحرک شوند و تمام توییت‌های رویداد را در پنجره‌های زمانی برش دهند و از تکنیک توضیح‌داده‌شده در [ 29 ] استفاده کنند.

هر پنجره دارای یک تاریخ شروع و پایان است و شامل تمام توییت های منتشر شده در این فاصله است. موتور زمان‌بندی به‌عنوان بازیکنی برای نقشه‌های حرارتی عمل می‌کند و تمام توییت‌های داخل هر پنجره را بازیابی می‌کند. این فرآیند با یک پخش کننده رسانه قابل مقایسه است که هر پنجره مربوط به یک “قاب” ویدئو است. اپراتور می تواند مرزهای زمانی تحلیل و طول پنجره را مشخص کند. داشبورد تجزیه و تحلیلهمه توییت‌های رویداد را در محدوده‌های زمانی مشخص بارگیری می‌کند و توییت‌ها را با توجه به طول پنجره برش می‌دهد. علاوه بر این، پس از انجام این کار، دانه بندی فریم و سرعت پخش قابل تنظیم است. این مکانیسم به کاربر اجازه می دهد تا پویایی یک رویداد را با در نظر گرفتن بعد زمانی در کنار قابلیت انجام پرس و جوهای فضایی، همانطور که در شکل 7 نشان داده شده است، درک کند . افزودن بعد زمانی به تحلیل به این ترتیب مرحله تحلیل را به صورت اساسی و مهم تکمیل می کند. به طور خاص، با اشاره به نکته ای که در بالا در مورد تجزیه و تحلیل های مشتق شده از مجموعه قدرتمندی از کلاس های داده پایه ذکر شد، تسهیلات زمانی پتانسیل زیادی برای توسعه آینده سیستم Whistland دارد.

برای افزایش قابلیت‌های تجزیه و تحلیل کاربر، داشبورد Analytics اجازه می‌دهد تمام داده‌های ارجاعی جغرافیایی ذخیره شده در GeoData Collector به‌عنوان لایه روی نقشه‌ها همپوشانی شود . بیننده وب GIS همچنین می‌تواند منابع دیگری از داده‌های جغرافیایی منتشر شده در اینترنت را که توسط کتابخانه Google Maps مورد استفاده برای توسعه آن پشتیبانی می‌شود، تجسم کند. این ویژگی برای ادغام داشبورد تجزیه و تحلیل به عنوان ابزاری برای مدیریت قلمرو، هر زمان که نیاز به تجسم داده‌های جانبی مورد اعتماد یک منبع دولتی وجود داشته باشد، بسیار مهم است. از سوی دیگر، با افشای داده ها در قالب GeoJSON، API Whistland Analytics به Whistland اجازه می دهد تا به راحتی در یک پلت فرم مدیریت موجود ادغام شود.

7. نتیجه گیری و کارهای آینده

در این مقاله، ما یک نمونه اولیه از سیستم Whistland، یک برنامه نقشه برداری جمعیتی برای حفاظت مدنی و مدیریت اضطراری ارائه کردیم.

سیستم Whistland نقشه برداری جمعیت، حسگرها و شبکه های اجتماعی، اینترنت اشیا و واقعیت افزوده را ادغام می کند. ویژگی اصلی آن ارائه یک راه حل شبکه مشارکتی است که داده ها را از یک پایگاه دانش گسترده و بسیار در دسترس تغذیه می کند و تجزیه و تحلیل می کند که وضعیت مکانی-زمانی یک قلمرو را در زمان واقعی طبقه بندی می کند. قابلیت بازیابی و ذخیره سازی اطلاعات جامع و در مقیاس بزرگ، یک لایه فناوری اطلاعات را ارائه می دهد که مدیریت عملیات مقامات حفاظت مدنی را با اطلاعات موجود در اینترنت به طور گسترده برای رویدادهای مرتبط با مدیریت بلایا به هم پیوند می دهد.

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

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

بنابراین در نظر گرفته شده، سیستم Whistland طراحی و توسعه یافته است تا یک سیستم پشتیبانی تصمیم گیری انعطاف پذیر برای حفاظت مدنی و مدیریت اضطراری باشد، که یک سیستم مکانی-زمانی کامل را برای توسعه بیشتر برنامه ارائه می دهد:

تجزیه و تحلیل زبان طبیعی متن توییت، دقت جغرافیایی سازی، استنتاج جریان ها را همانطور که در [ 30 ] توضیح داده شد، افزایش می دهد.
پشتیبانی کامل از استانداردهای ARML 2.0 و OGC-SWE یکپارچگی بهتر و گسترده تر از منابع داده خارجی در برنامه تلفن همراه توسعه یافته را تضمین می کند.
تولید مدل های سه بعدی از تصاویر ثبت شده توسط دوربین دستگاه، مفید بودن و جذابیت اپلیکیشن را افزایش می دهد.

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

منابع

الوود، اس. علم اطلاعات جغرافیایی: تحقیقات در حال ظهور در مورد پیامدهای اجتماعی وب جغرافیایی. Prog. هوم Geogr. 2010 ، 34 ، 349-357. [ Google Scholar ] [ CrossRef ]
چای، جی. تام، دی. بوش، اچ. جانگ، ی. ماسیجوسکی، آر. ایبرت، دی. Ertl، T. تجزیه و تحلیل رسانه های اجتماعی فضایی-زمانی برای تشخیص و بررسی رویدادهای غیرعادی با استفاده از تجزیه روند فصلی. در مجموعه مقالات کنفرانس IEEE در علم و فناوری تجزیه و تحلیل بصری 2012، VAST 2012، سیاتل، WA، ایالات متحده آمریکا، 14-19 اکتبر 2012. صص 143-152.
یین، جی. لامپرت، ا. کامرون، ام. رابینسون، بی. پاور، آر. استفاده از رسانه های اجتماعی برای افزایش آگاهی وضعیت اضطراری. IEEE Intell. سیستم 2012 ، 27 ، 52-59. [ Google Scholar ] [ CrossRef ]
بوکاردو، پی. Pasquali, P. خدمات نقشه برداری وب در یک محیط crowdsource برای مدیریت بلایا: پیشرفته ترین و توسعه بیشتر. در مجموعه مقالات آرشیو بین المللی فتوگرامتری، سنجش از دور و علوم اطلاعات فضایی – آرشیو ISPRS، ملبورن، استرالیا، 25 اوت تا 1 سپتامبر 2012. جلد 39، ص 543-548.
فوکس کیتوفسکی، اف. فاوست، دی. معماری سیستم‌های جمع‌سپاری سیار. در یادداشت های سخنرانی در علوم کامپیوتر (شامل یادداشت های سخنرانی های فرعی در هوش مصنوعی و یادداشت های سخنرانی در بیوانفورماتیک) ؛ Springer: Cham, Switzerland, 2014; صص 121-136. [ Google Scholar ]
فکته، ا. تزاولا، ک. آرماس، من. بینر، جی. گارشاگن، ام. گیوپونی، سی. مجتهدی، و. پتیتا، م. اشنایدرباوئر، اس. Serre, D. منبع داده بحرانی; ابزار یا حتی زیرساخت؟ چالش های سیستم های اطلاعات جغرافیایی و سنجش از راه دور برای حاکمیت خطر بلایا ISPRS Int. J. Geo-Inf. 2015 ، 4 ، 1848-1869. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
هاکلی، ام. دانش شهروندی و اطلاعات جغرافیایی داوطلبانه: بررسی اجمالی و گونه‌شناسی مشارکت. در جمع سپاری دانش جغرافیایی ; Sui, D., Elwood, S., Goodchild, M., Eds. Springer: Dordrecht، هلند، 2013; صص 105-122. [ Google Scholar ]
یانگ، دی. ژانگ، دی. فرانک، ک. رابرتسون، پی. جنینگز، ای. رادی، م. Lichtenstern، M. ارائه کمک در زمان واقعی در امداد رسانی به بلایا با استفاده از قدرت جمع سپاری. پارس محاسبات همه جا حاضر. 2014 ، 18 ، 2025–2034. [ Google Scholar ] [ CrossRef ]
کلینی، پ. فروتونی، ای. کواترینی، آر. Pierdicca، R. تجربه واقعیت افزوده: از کسب وضوح بالا تا محتوای افزوده شده در زمان واقعی. Adv. چندتایی. 2014 . [ Google Scholar ] [ CrossRef ]
پیردیکا، آر. فروتونی، ای. زینگارتی، پ. استوری، م. کلینی، پ. Quattrini, R. تعامل پیشرفته با نقاشی ها با واقعیت افزوده و تجسم با وضوح بالا: یک نمایشگاه موردی واقعی. در واقعیت افزوده و مجازی ؛ Springer: Cham, Switzerland, 2015; صص 38-50. [ Google Scholar ]
رادو، I. واقعیت افزوده در آموزش: یک بررسی فرامروری و تجزیه و تحلیل متقابل رسانه ای. پارس محاسبات همه جا حاضر. 2014 ، 18 ، 1533-1543. [ Google Scholar ] [ CrossRef ]
پورتالس، سی. لرما، جی ال. ناوارو، اس. واقعیت افزوده و فتوگرامتری: هم افزایی برای تجسم محیط های فیزیکی و مجازی شهر. ISPRS J. Photogramm. Remote Sens. 2010 ، 65 ، 134-142. [ Google Scholar ] [ CrossRef ]
ویس، ای. گرست، آر. فرنجیک، آی. گرونوالد، تی. Schmalstieg، D. موبایل واقعیت افزوده برای نظارت بر محیط زیست. پارس محاسبات همه جا حاضر. 2013 ، 17 ، 1515-1531. [ Google Scholar ] [ CrossRef ]
کامات، وی. El-Tawil, S. ارزیابی واقعیت افزوده برای ارزیابی سریع آسیب ساختمان های ناشی از زلزله. جی. کامپیوتر. مدنی مهندس 2007 ، 21 ، 303-310. [ Google Scholar ] [ CrossRef ]
عامر، ر. سوفی، س. Roohie, N. واقعیت افزوده برای خدمات آتش نشانی و اورژانس. در مجموعه مقالات کنفرانس بین المللی روندهای اخیر در ارتباطات و شبکه های کامپیوتری، Comnet 2013، حیدرآباد، هند، 8-9 نوامبر 2013.
پیردیکا، آر. فروتونی، ای. زینگارتی، پ. مانچینی، آ. Malinverni، ES; Tassetti، AN; مارچگیانی، ای. گالی، الف. نگهداری هوشمند سواحل رودخانه با استفاده از لایه داده استاندارد و واقعیت افزوده. محاسبه کنید. Geosci. 2016 ، 95 ، 67-74. [ Google Scholar ] [ CrossRef ]
بنخلیفه، من. نوعلی تبوجمت، ن. Moussaoui, S. پروژه های مدیریت بلایا با استفاده از شبکه های حسگر بی سیم: یک مرور کلی. در مجموعه مقالات بیست و هشتمین کنفرانس بین المللی 2014 در واینا، ویکتوریا، BC، کانادا، 13 تا 16 مه 2014.
نوران، او. مدیریت بلایای مشترک: یک رویکرد بین رشته ای. محاسبه کنید. Ind. 2014 , 65 , 1032-1040. [ Google Scholar ] [ CrossRef ]
اسکانی، ع. فروتونی، ای. مانچینی، آ. Zingaretti، P. شبکه حسگر بی سیم برای مدیریت جمع آوری روغن خسته شده. در مجموعه مقالات کنفرانس بین المللی IEEE/ASME 2010 در مورد مکاترونیک و سیستم ها و برنامه های کاربردی جاسازی شده (MESA)، چینگدائو، چین، 15 تا 17 ژوئیه 2010.
کاتانی، ال. فروتونی، ای. Zingaretti، P. چارچوبی مبتنی بر حسگرهای بینایی برای مدیریت خودکار مناطق پارکینگ تبادل. در مجموعه مقالات کنفرانس بین المللی IEEE/ASME 2010 در مورد مکاترونیک و سیستم ها و برنامه های کاربردی جاسازی شده (MESA)، چینگدائو، چین، 15 تا 17 ژوئیه 2010.
فروتونی، ای. مانچینی، آ. Zingaretti، P. تشخیص زمان واقعی از قفسه با استفاده از شبکه حسگر تعبیه شده. در مجموعه مقالات دهمین کنفرانس بین المللی IEEE/ASME 2014 در مورد سیستم ها و کاربردهای مکاترونیک و جاسازی شده (MESA)، Senigallia، ایتالیا، 10-12 سپتامبر 2014.
فروتونی، ای. مانچینی، آ. زینگارتی، پ. Malinverni، ES; پسری، س. بیوندی، ای. پاندولفی، م. مارسگلیا، ام. استوری، م. Zabaglia, C. SIT-REM: یک سیستم اطلاعات جغرافیایی وب تعاملی و تعاملی برای مدیریت داده های جانوران، گیاهان و گیاهان. ISPRS Int. J. Geo-Inf. 2014 ، 3 ، 853-867. [ Google Scholar ] [ CrossRef ]
ابوالفضلی، س. سنایی، ز. گانی، ع. شیا، اف. یانگ، LT Rich برنامه های تلفن همراه: پیدایش، طبقه بندی، و مسائل باز. J. Netw. محاسبه کنید. Appl. 2014 ، 40 ، 345-362. [ Google Scholar ] [ CrossRef ]
مانچینی، آ. فروتونی، ای. زینگارتی، پ. Longhi, S. نقشه برداری با وضوح بالا از مناطق رودخانه و مصب با استفاده از سکوهای هوایی و سطحی بدون سرنشین. در مجموعه مقالات کنفرانس بین المللی 2015 در مورد سیستم های هواپیمای بدون سرنشین، ICUAS 2015، دنور، CO، ایالات متحده آمریکا، 9-12 ژوئن 2015.
چاروات، ک. بارویکا، اس. آلبرتز، ام. داده های باز مرتبط برای حفاظت از محیط زیست در مناطق هوشمند – چالش جدید برای استفاده از داده ها و اطلاعات محیطی. در مجموعه مقالات نوزدهمین کنفرانس بین المللی برنامه ریزی شهری و توسعه منطقه ای در جامعه اطلاعاتی، بخش: برنامه ریزی هوشمندانه، وین، اتریش، 21-23 مه 2014.
مولیگان، جی. Gračanin، D. مقایسه اجرای SOAP و REST یک چارچوب میان‌افزار مستقل تعامل مبتنی بر سرویس. در مجموعه مقالات کنفرانس شبیه سازی زمستانی 2009 (WSC)، آستین، TX، ایالات متحده، 13-16 دسامبر 2009.
بوتس، ام. پرسیوال، جی. رید، سی. Davidson, J. OGC® سنسور فعال سازی وب: نمای کلی و معماری سطح بالا. در شبکه های ژئوسنسور ؛ Springer: برلین/هایدلبرگ، آلمان، 2008; صص 175-190. [ Google Scholar ]
Lechner, M. ARML 2.0 در زمینه فرمت های داده AR موجود. در مجموعه مقالات ششمین کارگاه 2013 در زمینه مهندسی نرم افزار و معماری برای سیستم های تعاملی بیدرنگ (SEARIS)، اورلاندو، FL، ایالات متحده آمریکا، 17 مارس 2013.
لوچتی، جی. سرویسی، جی. فروتونی، ای. مانچینی، آ. Zingaretti, P. طراحی و تست ردیاب GPS موبایل دقیق. در مجموعه مقالات بیست و یکمین کنفرانس مدیترانه ای 2013 در مورد کنترل و اتوماسیون، MED 2013، کرت، یونان، 25-28 ژوئن 2013.
چوا، ا. مارچگیانی، ای. سرویلو، ال. Moere، AV FlowSampler: تجزیه و تحلیل بصری جریان های شهری در داده های رسانه های اجتماعی جغرافیایی. در انفورماتیک اجتماعی ; Springer: برلین/هایدلبرگ، آلمان، 2014. [ Google Scholar ]

شکل 1. معماری سیستم Whistland. خطوط نشان دهنده API ها هستند که بین Whistland و Twitter، تعامل بین اجزای سیستم و پلت فرم توییتر متمایز می شوند.

شکل 2. مدل پایگاه داده جزئی Whistland، نشان دهنده جداول درگیر مستقیم در مدیریت رویداد و محتوا است. هر جدول که به‌عنوان موجودیت مربوطه نام‌گذاری می‌شود، حاوی فیلدهای پیوند ( PK کلیدهای اولیه، FK کلیدهای خارجی هستند) و فیلدهای querying (در جست‌وجوهای فضایی/زمانی و در فیلتر کردن محتوا استفاده می‌شود). ویژگی هایی که برای درک روابط ضروری نیستند (مثلاً نام، توصیف، …) گزارش نمی شوند.

شکل 3. برنامه موبایل در حالت های مختلف عملیاتی. بالا سمت چپ : منوی اصلی با بیشتر رویدادهای مرتبط. بالا سمت راست : جزئیات مربوط به نشانگر جغرافیایی؛ پایین : نمونه ای از همپوشانی توئیت های جغرافیایی نزدیک به کاربر در حالت AR.

شکل 4. مکانیسم ادغام و ذخیره سازی. عملیات ادغام توسط “TweetManager” انجام می شود که ابتدا توییت ها را از Twitter Streaming API و Twitter REST API به TweetPointer تبدیل می کند و سپس آنها را با TweetPointer از Whistland History API ادغام می کند . عملیات کش توسط “CacheManager” اجرا می شود که TweetContent ها را می گیرد و آنها را به “برنامه AR” ارسال می کند، که به نوبه خود توییت اصلی (پس از بازیابی) را در “CacheManager” ذخیره می کند و TweetContent مربوطه را به روز می کند .

شکل 5. نمونه ای از نقشه حرارتی توئیت جغرافیایی: توزیع توییت های درگیر در یک رویداد مشخص، تنها با استفاده از توییت های محلی سازی شده جغرافیایی. سبز تند تر نشان دهنده چگالی بالاتر است، در حالی که قرمز نشان دهنده حداکثر غلظت است.

شکل 6. نمونه ای از نقشه حرارتی منطقه کلان: توزیع توییت های درگیر در یک رویداد مشخص، با استفاده از مناطق مرتبط با توییت ها. قرمز شدیدتر به معنای توییت های بیشتر در آن ناحیه است.

شکل 7. نقشه حرارتی geo-tweet متحرک. این سه شکل نقشه ارائه شده توسط پنجره های زمانی متوالی یک رویداد را نشان می دهند. هر پنجره روی نقشه فقط توئیت های جغرافیایی منتشر شده در محدوده زمانی تعریف شده را ارائه می کند.

جدول 1. ساختار داده TweetPointer .

© 2017 توسط نویسندگان. دارنده مجوز MDPI، بازل، سوئیس. این مقاله یک مقاله با دسترسی آزاد است که تحت شرایط و ضوابط مجوز Creative Commons Attribution (CC BY) ( http://creativecommons.org/licenses/by/4.0/ ) توزیع شده است.

;کاربردهای GIS مقالات

درخواست مشاوره

09120049370

8 صبح تا 12 شب