تکنیک های جستجوی فضایی برای پرس و جوهای سه بعدی موبایل در محیط های وب حسگر

چکیده

توسعه سیستم‌های اطلاعات جغرافیایی سیار برای برنامه‌های کاربردی وب حسگر شامل فناوری‌هایی است که می‌توانند به اطلاعات اینترنتی مرتبط جغرافیایی و معنایی مرتبط دسترسی پیدا کنند. علاوه بر این، در دنیای وب 4.0 فردا ، پیش‌بینی می‌شود که تریلیون‌ها ریزحسگر ارزان قیمت که در سرتاسر محیط قرار می‌گیرند نیز بر اساس آدرس IP منحصربه‌فرد با مرجع جغرافیایی برای کشف در دسترس خواهند بود. کاوش در این حجم عظیم از داده‌های ناهمگون ناهمگون در تلفن‌های هوشمند امروزی با آگاهی از موقعیت مکانی و جهت‌گیری، نیازمند برنامه‌ها و سرویس‌های هوشمند آگاه از زمینه است که می‌توانند با «بار اطلاعات» مقابله کنند. 3DQ(پرس و جوی سه بعدی) نمونه اولیه تعامل فضایی سیار (MSI) جدید ما است که به عنوان یک پایگاه نسل بعدی برای تعامل انسانی در چنین محیط های وب حسگر جغرافیایی/مناظر شهری عمل می کند. این اطلاعات را با استفاده از قابلیت “حذف پرس و جو پنهان” فیلتر می کند که به طور هوشمندانه فضای جستجو را با محاسبه هندسه شکل دید سه بعدی (فضای Vista) در مکان فعلی کاربر اصلاح می کند. سپس این شکل 3 بعدی به “پنجره” پرس و جو در پایگاه داده فضایی برای بازیابی اطلاعات فقط در مورد اشیایی که در میدان دید سه بعدی واقعی کاربر قابل مشاهده است تبدیل می شود. 3DQاضافه بار اطلاعات را کاهش می دهد و با ارائه جستجوی فضای دید به عنوان یک سرویس وب تلفن همراه، آگاهی از موقعیت را در دستگاه های تجاری محدود شده افزایش می دهد. اثرات تغییرات در تکنیک های جستجوی فضایی سیار از نظر سرعت پرس و جو در مقابل دقت در این مقاله ارزیابی و ارائه شده است.

کلید واژه ها:

تعامل فضایی متحرک ; محاسبه جغرافیایی مبتنی بر مکان ; وب سنسور جغرافیایی ; iThings

1. مقدمه

اطلاعات مکانی به طور فزاینده ای به عنوان مخرج مشترک در عصر شبکه های اجتماعی نظیر به نظیر “وب 2.0” و “وب 4.0” فردا شناخته می شود – جایی که پیش بینی می شود اینترنت به تریلیون ها ریزحسگر متصل به واقعی متصل شود. اشیاء جهان از همه نوع ( به عنوان مثال ، مکانیکی و غیر مکانیکی)، همه با آدرس IP منحصر به فرد 128 بیتی خود [ 1 ]. به عبارت دیگر، اینترنت اشیا (iThings) با آگاهی از موقعیت مکانی که می تواند از نظر تئوری داده های مهر زمانی را در مورد موقعیت، حرکت، به علاوه هر تعداد دیگر از پدیده های قابل اندازه گیری، مانند داده های محیطی مانند هوا/آب، به طور مداوم جمع آوری و به ابر ارسال کند. کیفیت، داده های نور/نویز/تابش محیط، مصرف انرژی و غیرههنگامی که پتانسیل چنین شبکه حسگر جغرافیایی محقق می شود، هر ویژگی هر ساختمان، هر شی در هر خیابان، هر تابلوی راه، چراغ راهنمایی، چراغ خیابان، و درختچه می تواند به طور جداگانه مکان و شرایط محلی خود را به جهان اطلاع دهد. در چنین دنیایی، توانایی یافتن، بازجویی و فیلتر کردن اطلاعات ناخواسته/غیرضروری/ناخواسته، هم از نظر معنایی و هم از نظر فضایی، و در عین حال بازیابی داده‌های مربوط به کار برای تصمیم‌گیری آگاهانه بسیار مهم است.

تلفن های هوشمند جدید امروزی (مانند آیفون، تلفن اندروید) به سرعت به عنوان پلتفرم های محاسباتی پیشرفته از نظر مشخصات و قابلیت های سخت افزاری/نرم افزاری (مانند CPU قدرتمندتر، ظرفیت حافظه رم/ذخیره بزرگتر، رابط های صفحه نمایش لمسی) در حال تکامل هستند. به طور خاص، روند قابل توجهی از یکپارچه سازی حسگرهای آگاه از مکان و جهت (به عنوان مثالگیرنده جی‌پی‌اس، قطب‌نمای دیجیتال و شتاب‌سنج) در دستگاه‌های تلفن همراه توسعه تلفن‌های هوشمند را به‌عنوان ابزاری برای بازیابی، تجزیه و تحلیل و تجسم اطلاعات از وب جغرافیایی ارتقا داده است. با این حال، حتی در حال حاضر یک مشکل تجسم داده ها به وجود می آید زیرا مقدار اطلاعات اینترنتی موجود برای پرس و جو و نمایش فضایی برای این دستگاه ها و کاربران آنها به طور یکسان تا حدودی طاقت فرسا است. به عنوان مثال، زمانی که سعی می کنید خود را در یک محیط ناشناخته آشنا کنید – به عنوان مثال، “این ساختمان ها در اطراف من چیست؟” یا، “چه نقاط مورد علاقه (POI) در نزدیکی شما هستند؟” یا، “میزان آلودگی هوا در این خیابان چقدر است؟” – درهم و برهمی نمایشگر یا “بیش از حد اطلاعات” می تواند به یک مشکل مهم تبدیل شود. این می تواند باعث سردرگمی و سردرگمی کاربر شود،

در تحقیقات تعامل فضایی موبایل (MSI)، نحوه رسیدگی به مشکل بهینه‌سازی اطلاعات برای نیازهای شخصی از طریق بازیابی و نمایش هوشمند اساساً در قلب این فرآیند قرار دارد. کار قبلی در این رابطه یک مدل دید محلی را پیشنهاد کرد که اطلاعات را با در نظر گرفتن میدان دید واقعی کاربر جستجو می‌کند [ 2 ]. در [ 3 ]، یک پردازنده پرس و جوی دوبعدی بر روی یک مدل دید مشابه ساخته شده است، که در آن خطوط کلی بلوک های ساختمانی به عنوان “ردپای” مورد استفاده برای برش جغرافیایی فضای جستجوی قابل مشاهده در صفحه افقی استفاده می شود. روش‌های دیگر برای کاهش اضافه بار اطلاعات، به استفاده از تکنیک‌های شخصی‌سازی نقشه می‌پردازد که بر عملکرد قبلی کاربر/نقشه نظارت می‌کند تا سطوح بعدی جزئیات نمایش را کمک کند و/یا توصیه کند [ 4 ], 5 , 6 , 7 ]. مکانیزم‌های فیلتر مبتنی بر معنایی برای بهره‌برداری از هستی‌شناسی‌ها و توصیف‌های RDF (چارچوب توصیف منابع) از داده‌های مرتبط و دانش شبکه‌ای طراحی شده‌اند تا اساساً کاوش دنیای واقعی را با محدودیت‌های پردازش/نمایش دستگاه‌های تلفن همراه کاهش داده و تطبیق دهند . در دوران افزایش روزافزون مناظر شهری چندحسی‌گر، ما راه دیگری را برای بهبود ارتباط متنی برای کاربران پیشنهاد می‌کنیم، فیلتر فضایی این ذخیره‌گاه داده‌های در حال نصب با اصلاح هوشمندانه فضای جستجو در سه بعدی.

3DQ (پرس و جوی سه بعدی) نمونه اولیه MSI جدید ما برای محاسبه شکل دید سه بعدی (فضای Vista) در مکان فعلی کاربر در خارج از افق در یک محیط ساخته شده است. سپس 3DQ از این شکل به عنوان یک “پنجره” برای بازیابی اطلاعات فقط در مورد آن اشیاء/حسگرهایی استفاده می کند که در میدان دید سه بعدی کاربر هنگام حرکت در منظر شهری قابل مشاهده هستند. جستجوی شکل دید با ارائه عملکرد “حذف پرس و جو پنهان” (HQR) برای افزایش آگاهی از وضعیت در این دستگاه های تجاری خارج از قفسه (COTS) مشکل اضافه بار اطلاعات را برطرف می کند. در 3DQما عملکرد پرس و جوی محدوده نوع بافر دوبعدی معاصر را که در بسیاری از برنامه های کاربردی LBS موبایل امروزی یافت می شود گسترش می دهیم تا اکنون اشیاء و فضاهای پایگاه داده را در بعد عمودی ترکیب کنیم. به طور خاص، ما از محیط‌های پردازش دسکتاپ GIS سنتی به یک الگوی پرس و جوی دید که برای عملکرد در محیط‌های شهری در گوشی‌های هوشمند طراحی شده است، حرکت می‌کنیم. نتیجه یک نتیجه جستجوی دقیق‌تر و مورد انتظار برای برنامه‌های کاربردی LBS تلفن همراه است که با برگرداندن اطلاعات فقط در مورد اشیایی که در میدان دید سه بعدی واقعی کاربر قابل مشاهده است ( شکل 1 ) است. بر خلاف این پرس و جوی دید، بازیابی اشیایی که فقط دور از دید هستند با کم کردن مجموعه نتایج قابل مشاهده از یک پرس و جوی محدوده دو بعدی استاندارد که در همان مکان ارسال می شود امکان پذیر است.

شکل 1. فضای جستجوی 3DQ در تعامل با یک مدل منظر شهری 3 بعدی. تنها چیزهایی که حجم گنبدی شکل را قطع می کنند، توسط پرس و جو برگردانده می شوند.

تجسم مجموعه داده های محیط ساخته شده سه بعدی در دستگاه های COTS سیار (مثلاً Google Maps 5 برای Android 2.3+) اکنون نیز یک واقعیت است. این امر با رندر کردن نقشه موبایل از یک مجموعه واحد از داده های برداری به جای مجموعه های متعدد کاشی های تصویر شطرنجی امکان پذیر می شود، بنابراین امکان مشاهده و مقیاس گذاری یکنواخت و پیوسته نقشه از منظرهای مختلف با استفاده از مجموعه داده های برداری یکسان را فراهم می کند. اگرچه Google Maps 6 هنوز عکس واقعی نیست، مدل‌های سه بعدی حاصله از نظر هندسی دقیق هستند زیرا از اکسترود کردن ردپاهای ساختمان به ارتفاعات شناخته شده برای بخش‌های مختلف ساختمان مشتق شده‌اند ( شکل 2 ).

شکل 2. شیب، بزرگنمایی و چرخش سه بعدی نقشه تلفن همراه فعال شده در Google Maps 6 برای دستگاه‌های Android نمایش داده شده است [ 9 ].

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

بقیه این مقاله به صورت زیر سازماندهی شده است: بخش 2 طراحی و پیاده سازی سیستم 3DQ را معرفی می کند، که همچنین شامل مقدمه ای بر مجموعه داده های برداری مورد استفاده در کار ما است. بخش 3 مشارکت های اصلی ما را با ارائه یک بحث جامع در مورد الگوریتم های پرس و جو و اجرای نمونه اولیه 3DQ توضیح می دهد. این در بخش 4 با ارزیابی هایی از عملکرد 3DQ از نظر سرعت پرس و جو در مقابل دقت هنگام استفاده از الگوریتم ها و پارامترهای جستجوی مختلف دنبال می شود. نتیجه گیری و برنامه ریزی برای کار آینده در بخش 5 آمده است.

2. طراحی و پیاده سازی سیستم 3DQ

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

با توجه به حجم داده‌های ارجاع‌شده جغرافیایی که قبلاً در وب جغرافیایی امروزی موجود است – بیشتر آنها داوطلبانه [ 10 ] – به علاوه میراث اضافه شده مجموعه‌های داده‌های محیطی ساخته‌شده آژانس نقشه‌برداری مختلف، انجام تمام وظایف پردازشگر به طور موثر در شبکه عملی نیست. خود دستگاه تلفن همراه در چنین مواردی، معماری «مشتری-سرور» گزینه ترجیحی است که در آن وظایف محاسباتی فشرده در سمت سرور انجام می‌شود و دستگاه تلفن همراه را به عنوان یک مشتری نازک می‌گذارد تا از ارسال درخواست‌ها، دریافت پاسخ‌ها و نمایش نتایج پرس و جو به کاربران مراقبت کند. . در واقع، پارادایم ارتباط مشتری-سرور عنصر کلیدی بسیاری از پیاده سازی های LBS معاصر است [ 11 ، 12 ].

شکل 3. نمودار جزء برای معماری کلی سیستم 3DQ .

با توجه به تنوع سیستم عامل های تلفن همراه رقیب موجود (به عنوان مثال، سیستم عامل iPhone، Nokia Symbian/Windows Phone8، Google Android)، 3DQ پرس و جو فضایی موبایل را به عنوان یک سرویس وب سازگار با مرورگر ارائه می کند تا از پیاده سازی های اختصاصی متعدد جلوگیری کند. سرویس‌های ما از قالب RESTful استفاده می‌کنند، جایی که مشتری دستگاه تلفن همراه خوانش‌ها را از حسگرهای یکپارچه خود (به عنوان مثال، GPS، قطب‌نما، شتاب‌سنج) جمع‌آوری می‌کند، آنها را در یک URL استاندارد می‌سازد و برای پردازش به سرور می‌فرستد. هنگامی که سرور با عملیات پرس و جو به پایان رسید، مجموعه نتایج در قالب GEO-JSON ، که سازگار با استاندارد OGC و کاملاً مبتنی بر متن است، سازماندهی و ارسال می شود [ 13 ]]. یک نمودار مؤلفه برای معماری کلی سیستم 3DQ در شکل 3 نشان داده شده است ، که در آن ارتباط بین کلاینت و سرور از رویکرد ذکر شده در بالا پیروی می کند در حالی که مجموعه داده های فضایی دوبعدی و سه بعدی (به عنوان مثال، اشیاء از وب جغرافیایی، مدل های محیط ساخته شده 2 بعدی/3 بعدی) وجود دارند. در پایگاه داده های فضایی در سمت سرور.

علاوه بر رویکرد سرویس گیرنده-سرور استاندارد LBS، ما همچنین آخرین فناوری‌های منبع باز را برای محاسبات فضایی سمت مشتری برای ذخیره و فهرست‌بندی داده‌ها و انجام وظایف محاسباتی به صورت محلی بر روی خود دستگاه تلفن همراه به کار می‌گیریم. به عنوان مثال، با کمک یک پایگاه داده فضایی قابل حمل (SpatiaLite) و نرم افزار رندر نقشه شطرنجی (TileMill)، می توانیم تمام عملکردهای پرس و جوی دوبعدی را به صورت محلی انجام دهیم و متعاقباً نتایج را بر روی نقشه های تلفن همراه ذخیره شده محلی به صورت “آفلاین” تجسم کنیم (به عنوان مثال ، بدون اتصال شبکه) حالت [ 10 ].

2.2. الزامات مجموعه داده برداری

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

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

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

شکل 4. ( الف ) داده‌های بستر آزمایشی ردپای دوبعدی پردیس موسسه فناوری دوبلین (DIT) در دوبلین ( ب ) مدل‌های ساختمان‌های سه بعدی اکسترود شده در همان مکان.

شکل 5. یک مدل سه بعدی واقعی (از لحاظ هندسی) از ساختمان دانشگاه که از اسکن لیزری دقیق به دست آمده است. ویژگی های فردی به طور جداگانه در پایگاه داده ذخیره می شوند.

نمایه سازی سه بعدی یک الزام برای ذخیره و جستجوی کارآمد اشیاء برداری سه بعدی برای پردازش بلادرنگ است، که در زمان نگارش گزینه های پایگاه داده فضایی ما را به Oracle Spatial 11g R2 محدود می کند، اگرچه PostgreSQL با پسوند PostGIS 2.0 پیش بینی شده خود برای نمایه سازی سه بعدی یک گزینه خواهد بود. علاوه بر منبع باز مفید به این لیست بسیار کوتاه. با این حال، هنگام تلاش برای تعیین روابط فضایی بین هندسه‌های سه‌بعدی، محدودیت‌های واضحی را با عملگرهای جستجوی فضایی Oracle کشف کرده‌ایم. اینها شامل ایجاد نمایه های سه بعدی R-Tree در هندسه های سه بعدی با استفاده از یک مکعب حداقل محدود است. Oracle فقط در نظر می گیرد که آیا این مکعب ها با یکدیگر تلاقی می کنند، به عنوان روشی برای تعیین اینکه آیا هندسه های سه بعدی زیرین آنها واقعاً تلاقی دارند یا خیر. متاسفانه،

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

همچنین، برای یک حجم ایزویست سه بعدی دقیق محاسبه شده، شکل گنبد تولید شده معمولاً دارای تعداد زیادی عناصر سطحی نسبت به پیچیدگی محیط اطراف خواهد بود. اگر بخواهیم این گنبد را به عنوان یک شکل پرس و جوی سه بعدی (سطح) در قالب Oracle SDO_GEOMETRY در نظر بگیریم (به منظور استفاده از عملگر پرس و جو SDO_INTERSECTION )، متوجه می شویم که تعداد کل عناصر سطح آن معمولاً از تعداد بیشتر خواهد شد. از عناصر مجاز در SDO_ELEM_INFO_ARRAY – جایی که به نظر می رسد حداکثر دلخواه 999 مختصات ( یعنی 333 نقطه سه بعدی) مجاز است.

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

2.3. نرم افزارهای جایگزین تجاری

برخی از روش‌های تحلیل فضایی مبتنی بر دید نیز در پلتفرم‌های GIS رومیزی معاصر موجود هستند. به عنوان مثال، ArcGIS دو جعبه ابزار اصلی را برای تجزیه و تحلیل دید سه بعدی فراهم می کند. خط دید و نمای سه بعدی. با این حال، این دو پیاده سازی تجاری با رویکرد ما در آن 3DQ متفاوت استابتدا شکل دید سه بعدی را استخراج می کند و سپس از این شکل سه بعدی به عنوان “پنجره” جستجو در پایگاه داده فضایی برای بازیابی اطلاعات ویژگی در مورد محیط اطراف کاربر استفاده می کند. درعوض، تابع خط دید ArcGIS عمدتاً برای هدف برنامه ریزی معماری طراحی شده است، جایی که یک پرتو برای نشان دادن دید در یک جهت خاص برای تعیین اینکه آیا این پرتو با هر شی (به عنوان مثال، ساختمان) در صفحه مورد علاقه است یا خیر، استفاده می شود. – و کدام قسمت از پرتو قابل مشاهده است و کدام قسمت نیست – بدون بازیابی اطلاعاتی در مورد اجسامی که آنها را قطع می کند.

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

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

3. الگوریتم های جستجوی فضایی 3DQ

از زمان معرفی مفهوم “ایزویست” در [ 14 ] برای توصیف شکل دید دوبعدی یا حجم دید سه بعدی در یک موقعیت معین، تعدادی پیشرفت وجود داشته است که از رویکردهای ایزویست مانند برای تحلیل محیط شهری استفاده می کند. مفهوم “شاخص باز بودن فضایی” (SOI) که در [ 15 ، 16 ] توسعه یافته است، حجم ادراک بصری در یک کره اطراف را از یک نقطه دید معین، اما بدون تعریف شکل آن، اندازه گیری می کند. سایر تکنیک ها برای اندازه گیری دید دو بعدی و سه بعدی در یک محیط شهری در [ 17 ] نشان داده شده است]، که میزان دید مختصات پیکسل را در مدل های ارتفاعی دیجیتال (DEMs) محاسبه می کند. “ماتریس iso-visi” پیشنهادی آنها ادعا می کند که از دیدگاه ادراک بصری بسیار مفید است. متفاوت از این رویکردها، الگوریتم‌های مدل‌سازی دید توسعه‌یافته در [ 18 ، 19 ]، میزان دید نشانه‌های محلی را در یک بافت شهری محاسبه می‌کنند. آن‌ها نمایان بودن «ویژگی مورد علاقه» (FOI) را برای برنامه‌های LBS تعیین می‌کنند که به کاربران اطلاع می‌دهند زمانی که در موقعیتی قرار می‌گیرند که واقعاً می‌توانند آن نشانه‌ها را ببینند. 3DQاهمیت و سودمندی انجام تجزیه و تحلیل مبتنی بر دید 2 بعدی/3 بعدی در محیط شهری را تصدیق می کند و هدف آن گسترش این ایده با بهره برداری از شکل واقعی دید سه بعدی (حجم) به عنوان یک “پنجره” در یک پایگاه داده فضایی برای بازیابی اطلاعات تنها در مورد آن موارد است. اشیایی که کاربر می تواند از نظر فیزیکی آنها را ببیند.

هنگام محاسبه ایزوویست های سه بعدی، ادراک بصری کاربر معمولا شبیه سازی شده و به عنوان مجموعه ای از برخوردهای “خطوط دید” یا “خط دید” با اجسام فضایی در محیط تفسیر می شود [ 20 ]]. در این راستا، تکنیک ریخته‌گری پرتویی یک رویکرد رایج برای تعیین تقاطع‌های خط دید/اشیاء است که در آن نقاط تقاطع جمعی برخوردها در نهایت شکل دید مورد استفاده به عنوان پنجره پرس و جو سه بعدی را تشکیل می‌دهند. در اکثر برنامه‌های بازی رایانه‌ای مدرن، تکنیک‌های تشخیص برخورد به خوبی برای تعیین و ارائه تنها آن اشیاء قابل مشاهده در صحنه بازی برای بهینه‌سازی سرعت نمایش، توسعه یافته‌اند. با این حال، این نوع محاسبات معمولاً عملیات مبتنی بر مقدار بولی هستند، به این معنی که اگر پرتو به یک شی برخورد کند، مقدار بازگشتی “درست” است، اما بدون هیچ جزئیات مختصاتی. برای هدف رندر لایه ای گرافیک کامپیوتری، این تکنیک (بدون محاسبه بیشتر نقطه تقاطع) کاملاً کارآمد است [ 21 ، 22 ، 23 ]]. با این حال، نمونه اولیه 3DQ ما به چیزی بیش از تعیین اینکه کدام اشیاء یک صحنه را از دید کاربر تشکیل می‌دهند، نیاز دارد، ما همچنین به خود شکل ایزویست سه بعدی برای تعیین محل تلاقی اشیا (به عنوان مثال، ساختمان‌ها، حسگرها، اطلاعات مرتبط با حسگر وب) نیاز داریم. بنابراین، رئوس دقیق (نقاط تقاطع) شکل دید لزوماً برای تشکیل حجم پرس و جو مربوطه در یک پایگاه داده فضایی برای عملیات پردازش پرس و جو فضایی بعدی لازم است.

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

نمونه ای از جستجوی دید در یک محیط دو بعدی (به عنوان مثال ، ایزویست دو بعدی) در یک مکان معین در شکل 6 (الف) نشان داده شده است. مربع سیاه نشان دهنده مکان فعلی کاربر است که از GPS روی دستگاه تلفن همراه دریافت می شود. محیط ساخته شده اطراف از رد پای تمام بلوک های ساختمانی در 200 متر ساخته شده است. با بهره مندی از نمایه سازی R-Tree در Oracle Spatial 11g، بازیابی همه ساختمان ها از یک مکان مشخص کاملاً کارآمد است [ 24 ]. چند ضلعی شکل نامنظم پر شده، شکل دید 360 درجه کاربر در آن مکان است. سپس از این شکل دوبعدی ایزویست به عنوان پنجره پرس و جو (چند ضلعی) برای بازیابی تمام اشیاء پایگاه داده که آن را قطع می کنند استفاده می شود. فرآیند ساخت ایزوویستی مبتنی بر روش توسعه یافته در [25 ]، که یک کتابخانه منبع باز برای الگوریتم های سریع دید با نقطه شناور دو بعدی است. علاوه بر این، نمای 360 درجه را می توان به هر زاویه ای تغییر داد (از طریق زوم دوربین موبایل داخلی) برای شبیه سازی “میدان دید” دو بعدی واقعی کاربر یا به 0 درجه برای مطابقت با یک پرتو منفرد که در جهت دستگاه تلفن همراه اشاره شده است. رو به رو این تنوع در زاویه دید، انعطاف‌پذیری را برای کاربران فراهم می‌کند تا نتایج جستجوی بازگردانده شده از وب حسگر را به صورت فضایی فیلتر کنند.

شکل 6. ( الف ) نمای ایزویست دو بعدی ( ب ) ایزویست 2.5 بعدی اکسترود شده در یک محیط سه بعدی.

پرس و جو ایزویست دوبعدی به ویژه برای جستجوهای معمولی نقشه موبایل دوبعدی مفید است، جایی که می تواند به عنوان فیلتر اولیه برای کاهش مقدار گاه بسیار زیاد اطلاعات اینترنتی موجود در یک مکان معین عمل کند. با این حال، از آنجایی که Google Maps 6 اکنون نقشه های موبایل دوبعدی را به سه بعدی تبدیل کرده است، ظاهر و احساس واقعی تری از منظر شهری در دسترس است. اگرچه، با این بعد عمودی اضافه شده، محاسبات دید سه بعدی بسیار پیچیده تر از دو بعدی است. به عنوان مثال، فلش در شکل 6(الف) به یک بلوک ساختمانی کوچک اشاره می کند که در آن یک پرتو ایزویست دو بعدی که از موقعیت فعلی کاربر (مربع سیاه) منشا می گیرد، کوتاه می شود. اما ارتفاع این ساختمان بسیار کمتر از ساختمان های اطراف است، بنابراین خط دید کاربر در واقع می تواند بالای این بلوک کوچک را ببیند. اگرچه از نظر محاسباتی سریع است، اما اکسترود کردن یک ایزویست 2 بعدی به 2.5 بعدی، همانطور که در شکل 6 (ب) نشان داده شده است، ناقص خواهد بود زیرا در این اختلاف ارتفاع مشاهده نمی شود. در واقع، نتایج بازیابی شده از یک ایزویست 2.5 بعدی اکسترود شده تفاوتی با نتایج بازگردانده شده از یک ایزویست دو بعدی نخواهد داشت، زیرا مختصات سه بعدی برای هر شیء برگشتی مقادیر x و y یکسانی دارند. با این حال، برای استخراج یک ایزویست سه بعدی دقیق همانطور که در [ 26] بسیار محاسباتی برای تجسم و جستجوی بلادرنگ است و بنابراین برای سرویس دهی به چندین کاربر به عنوان یک وب سرویس تلفن همراه بهینه نیست. بنابراین، ما تکنیک‌های ریخته‌گری پرتوی را روی مجموعه داده‌های برداری با استفاده از یک شعاع تعریف‌شده توسط کاربر برای کمک به صرفه‌جویی در تلاش محاسباتی توسعه دادیم. بنابراین شکل جستجوی نهایی ایزویست سه بعدی به صورت شکل “گنبد” نشان داده شده در شکل 1 ظاهر می شود که در آن رئوس هایی که گنبد را تشکیل می دهند، نقاط تقاطع بین هر پرتو و هر جسمی است که پرتو به آن برخورد می کند، در این مثال تا 200 متر.

برای غلبه بر این محدودیت ایزوویستی 2.5 بعدی، اولین آزمایش ما شامل مثالی است که نشان می دهد چگونه رئوس تقاطع اشیاء سه بعدی با استفاده از الگوریتم جستجوی 1 شناسایی می شوند ( شکل 7 ). در این تصویر، فرض کنید بلوک‌های ساختمانی با ارتفاع‌های مختلف در امتداد مسیری هستند که پرتو ایزویستی طی می‌کند. در صفحه افقی، فاصله بین هر پرتو به طور پیش فرض در 6 درجه از پیش تعریف شده است (فاصله پرتو افقی). در حالی که در صفحه عمودی هستیم، ابتدا تشخیص می دهیم که پرتو به چه اجسامی برخورد می کند و سپس نقطه تقاطع سه بعدی مربوطه را محاسبه می کنیم. پرتو بعدی در امتداد همین جهت افقی با زاویه شیب 15 درجه و به همین ترتیب (فاصله پرتو عمودی) تا انحراف 90 درجه ریخته می شود.

همانطور که قبلا ذکر شد، Oracle Spatial نقطه تقاطع سه بعدی دقیق را هنگامی که یک پرتو به بلوک های ساختمان برخورد می کند، بر نمی گرداند. در عوض، اشعه و بلوک‌های ساختمانی را روی یک صفحه افقی پخش می‌کند و مجموعه‌ای از بخش‌های خط دوبعدی را برمی‌گرداند. سپس نقطه تقاطع با گرفتن اولین نقطه تقاطع از همه بخش ها به همراه زاویه کج θ تعیین می شود. سپس پرتو به تشخیص نقطه تقاطع بعدی ادامه می دهد و به همین ترتیب ادامه می دهد تا زمانی که زاویه عنوان θ به 90 درجه می رسد متوقف شود. این رویکرد از نمایه سازی فضایی سه بعدی و عملگرهای پرس و جو ارائه شده توسط Oracle Spatial بهره می برد و اولین تقریب خوبی از شکل گنبد واقعی است. اما در شکل 7 قابل مشاهده استکه ساخت گنبد ایزویست با استفاده از رویکرد زاویه کج ممکن است نقاط تقاطع خاصی را به صورت عمودی از دست بدهد زیرا ممکن است پرتو از یک بلوک ساختمانی به دلیل شکاف بین هر دو زاویه کج ثابت عبور کند.

کد شبه الگوریتم جستجوی 1 به شرح زیر است:

الگوریتم 1: رویکرد پرتو کج.

آزمایش دوم ما در الگوریتم 1 با حذف هر گونه شکاف عمودی در پرتوهای ایزویست پیش بینی شده بهبود می یابد. الگوریتم جستجوی 2 مانند یک “جریان آب معکوس” عمل می کند، که در آن پرتو در یک نقطه تقاطع متوقف نمی شود بلکه در همان جهت ادامه می دهد تا تقاطع بعدی و بعدی را تعیین کند تا در نهایت در شعاع مشخص شده متوقف شود ( شکل 8). ). این فرآیند ابتدا با تعیین نقاط تقاطع بین هر پرتو ایزویست و ردپای بلوک های ساختمانی در صفحه افقی در فواصل از پیش تعریف شده (فاصله پرتو افقی 6 درجه) شروع می شود. تقاطع های واقعی لیستی از پاره خط هستند و هر یک از آنها دارای یک جفت نقطه تقاطع <I _in , I _out > هستند. مجموعه من _درامتیازها بر اساس فاصله آنها از مکان کاربر مرتب می شود. سپس اولین نقطه تقاطع I را تعیین می کنیم _که نشان دهنده اولین ضربه بین یک اشعه و یک شی پایگاه داده است. پرتو _ابتدا از I شروع مجدد می شود و یک زاویه کج θ ₁ پس از رسیدن به بالای ساختمان مقدار دهی اولیه می شود. محاسبه بعدی _در نقطه I بعدی در لیست اتفاق می افتد، جایی که اگر ارتفاع پرتو در آن نقطه از ارتفاع ساختمان بیشتر باشد، فرآیند به نقطه I بعدی _در لیست ادامه می یابد، در غیر این صورت، یک زاویه کج جدید ایجاد می شود و همان فرآیند تا I بعدی _در نقطه تکرار می شود.

شکل 7. الگوریتم جستجو 1 که تقاطع های خطوط دید را در یک محیط سه بعدی واقعی تعیین می کند. خط سیاه ضخیم شکل مرز پرس و جو نهایی گنبد ایزویست سه بعدی را در این جهت مشخص می کند.

شکل 8. الگوریتم جستجو 2 که تقاطع های خطوط دید را در یک محیط سه بعدی واقعی تعیین می کند.

مزیت دیگر الگوریتم جستجوی 2 این است که به جای استفاده از فاصله پرتوهای عمودی برای تولید چندین پرتو در یک جهت، فقط باید یک پرتو را در صفحه افقی پردازش کند و سپس اطلاعات ارتفاع تمام بلوک های ساختمانی را در مسیر خود جمع آوری کند. در الگوریتم 2، اشیاء ساختمانی سه بعدی، که به صورت جامد در Oracle Spatial نشان داده می شوند، به عنوان ساختارهای داده 2.5 بعدی با مقدار ارتفاع به عنوان یک ویژگی غیرمکانی به هر ردپای ساختمان متصل شده است. بنابراین، هنگام استخراج فهرست تقاطع اولیه، می تواند از نمایه سازی فضایی دوبعدی بهره مند شود، که ساختار داده ای ساده تر و بسیار سریعتر از نمایه سازی فضایی سه بعدی دارد.

کد شبه الگوریتم جستجوی 2 به شرح زیر است:

الگوریتم 2: رویکرد جریان معکوس آب.

یک ویژگی مشترک که در هر دو الگوریتم 3DQ 1 و 2 یافت می شود، فاصله پرتو افقی از پیش تعریف شده است. با این حال، مهم نیست که این فاصله چقدر کوچک باشد، همچنان خطر از دست دادن نقاط تقاطع خاصی وجود دارد، که دقت نهایی شکل پرس و جو نهایی را کاهش می دهد. همانطور که در محاسبه ایزویست دو بعدی در شکل 6 (الف) مشاهده شد، شکل دید دوبعدی در پر کردن هر گوشه / شکاف قابل مشاهده بین هندسه های ساختمان پیوسته است. بنابراین آزمون سوم ما الگوریتم 2 را در بالای یک شکل ایزویست دو بعدی اعمال می کند. هنگامی که ایزویست دو بعدی محاسبه می شود، هر رأس چند ضلعی ایزویست همراه با مکان کاربر یک جهت پرتو را مشخص می کند. یک مثال در شکل 9 نشان داده شده است، که در آن پرتوها از هر یک از رئوس یک چند ضلعی ایزویست دو بعدی عبور می کنند به جای اینکه با یک مقدار زاویه ای ثابت فاصله داشته باشند. اگرچه الگوریتم 3 شامل دو مرحله پردازش است، اما الگوریتم 3 نمایش دقیق تری از فضای دید سه بعدی واقعی ایجاد می کند.

شکل 9. نمونه ای از تولید پرتوهای افقی به شعاع مشخص شده توسط کاربر و از طریق رئوس تقاطع های ایزویست 2 بعدی / ردپای ساختمان.

شبه کد الگوریتم جستجوی 3 به شرح زیر است:

الگوریتم 3: رویکرد جاروب پرتو مبتنی بر ایزویست دوبعدی

همانطور که قبلا ذکر شد، در یک Isovist سه بعدی محاسبه شده دقیق، گنبد تولید شده معمولاً دارای تعداد زیادی سطوح نسبت به پیچیدگی محیط اطراف است. به دلیل محدودیت‌های ذخیره‌سازی ویژگی با Oracle Spatial DBMS، بنابراین باید شکل گنبدی کامل را به سه بخش تقسیم کنیم و سپس به‌جای ایجاد یک حجم 3 بعدی برای شکل پرس‌وجو، آنها را به‌صورت جداگانه در برابر پایگاه داده جستجو کنیم. این ما را بر آن داشت تا پایگاه داده فضایی را در سه سرور منعکس کنیم و سپس هر درخواست بخش گنبدی سه بعدی را به یک پایگاه داده جداگانه ارسال کنیم. در عصر محاسبات ابری امروزی، ممکن است بتوان این رویکرد را به عنوان یک سرویس مبتنی بر ابر با چندین پایگاه داده فضایی که همزمان در ماشین‌های مجازی مختلف اجرا می‌شوند، به کار برد.

4. ارزیابی سرعت پرس و جو در مقابل دقت

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

شکل 10. مدل سه بعدی محوطه دانشگاه با 100 حسگر محیطی شبیه سازی شده الصاق شده است.

ارزیابی هر الگوریتم جستجو در پنج مکان مختلف (که هر کدام در شکل 10 نشان داده شده است ) در اطراف دانشگاه انجام شد. برای آزمایش رویکرد ما بر روی مجموعه‌های داده بزرگ‌تر، ردپای دوبعدی که بیشتر شهر دوبلین را پوشش می‌دهد و شامل 345316 چند ضلعی با مقادیر ارتفاع به عنوان یک ویژگی است نیز مورد آزمایش قرار گرفت. مجموعه داده ها در سه پایگاه داده فضایی Oracle ذخیره می شوند که در سه ماشین مختلف منعکس شده اند. به طور دقیق تر، دستگاه یک ویندوز 7 (32 بیت) با رم 4G و پردازنده مرکزی Core2Duo 2.8 گیگاهرتز را اجرا می کند، دو دستگاه دیگر از ماشین های مجازی تحت ویندوز XP (32 بیت) با رم 2G و CPU Core2Duo 2.2 گیگاهرتز استفاده می کنند. زبان برنامه نویسی پایتون 2.7 با قابلیت ارائه خروجی GEO-JSON سازگار با استاندارد OGC به دستگاه های تلفن همراه است.

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

شکل 11 مقایسه سرعت پرس و جو را برای سه الگوریتم جستجوی مختلف نشان می دهد. الگوریتم جستجو 1 به مجموعه داده جامد 3 بعدی محدود از منطقه پردیس مجاور اعمال شد در حالی که الگوریتم های جستجو 2 و 3 در برابر نقشه چند ضلعی کامل دوبعدی شهر دوبلین با ارتفاع ساختمان ذخیره شده به عنوان یک ویژگی غیر فضایی اعمال شد. توجه داشته باشید که چگونه پرس و جوی سه بعدی در مجموعه داده های دوبعدی به طور مفیدی سریعتر است – حتی اگر نمایه سازی درخت R فضایی Oracle فضای جستجو را فقط به آن دسته از اشیاء پایگاه داده محدود می کند که در هر دو مورد در شعاع دو بعدی مشخص قرار دارند.

شکل 11. مقایسه سرعت پرس و جو برای الگوریتم های جستجوی مختلف در پنج موقعیت روی مجموعه داده های کوچک سه بعدی جامد و دو بعدی چند ضلعی بزرگ شهر دوبلین.

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

جدول 1 مقایسه ای از دقت را برای همه الگوریتم های پرس و جوی مشاهده نشان می دهد. در مقایسه با یک جستجوی محدوده استاندارد، که در آن بازگرداندن اطلاعات در تمام 100 iThing حسگر باعث بارگیری بیش از حد نمایشگر تلفن همراه در هر موقعیت جستجوی آزمایشی می‌شود، الگوریتم جستجوی 3 نشان داده شده است که حسگرهای قابل مشاهده را در هر موقعیت پرس و جو با کمترین هزینه برای سرعت پرس و جو با بیشترین دقت برمی‌گرداند (~ 1/2 ثانیه).

شکل 12. مقایسه سرعت پرس و جو برای الگوریتم های جستجوی مختلف در پنج موقعیت در مجموعه داده های جامد سه بعدی بزرگ شهر دوبلین.

جدول 1. مقایسه دقت سه الگوریتم جستجو در پنج موقعیت پرس و جو به همراه حداکثر تعداد حسگرهایی که واقعاً در هر موقعیت قابل مشاهده هستند.

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

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

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

این مقاله سه الگوریتم جستجوی فضایی سیار را ارائه می‌کند که برای نمونه اولیه 3DQ ما توسعه داده شده است تا به طور هوشمندانه مشکل اضافه بار اطلاعات را با ارائه عملکرد “حذف پرس و جو پنهان” حل کند، که پرس و جوهای محدوده تلفن همراه امروزی بر اساس شکل‌های جستجوی جعبه محدود یا دایره به سادگی انجام نمی‌دهند. سرعت و دقت دو الزام بسیار مهم هر برنامه LBS تلفن همراه است. در بین سه الگوریتم جستجوی آزمایش شده، الگوریتم جستجوی 3 دقیق‌ترین است در حالی که الگوریتم جستجوی 2 سریع‌ترین سرعت را دارد. مطالعات بیشتر در مورد مبادله بین سرعت و دقت در حال انجام است تا مناسب ترین رویکرد برای استقرار 3DQ پیدا شود.در یک برنامه eCampus تلفن همراه در دنیای واقعی برای کاربران دانش‌آموز/کارمند—در حال حاضر در حال ساخت در زمان سال تحصیلی 2013 است.

هدف نهایی ما برای 3DQ این است که به عنوان یک پایگاه نسل بعدی برای تعامل انسانی در چنین محیط های وب حسگر جغرافیایی/مناظر شهری در زمان واقعی عمل کنیم: جایی که نمایش شکل گنبد ایزوویستی سه بعدی به صورت پویا در بالای نقشه سه بعدی متحرک تغییر می کند. کاربر در اطراف شهر خود قدم می زند، همراه با پیوندهایی به نتایج جستجو که به خود گنبد دوخته شده است. در حال حاضر، Google Maps 6 Visualization API هنوز به صورت عمومی برای این مورد در دسترس نیست، اگرچه انتظار می‌رود در سال 2013 منتشر شود. با این حال، گزینه‌های جایگزینی وجود دارد که می‌توان در این مدت برای آزمایش استفاده کرد. برای مثال، VisioDevKit [ 27 ] قابلیت‌های رندر سه بعدی را فراهم می‌کند، به طوری که هر شکل دید تولید شده توسط 3DQرا می توان روی صفحه نمایش تلفن همراه پوشاند. برای دستیابی به هدف محاسبه/تجسم ایزویستی سه بعدی بلادرنگ، بهبود کارایی در سه الگوریتم جستجو بیشتر مورد بررسی قرار خواهد گرفت. از آنجایی که نمونه اولیه ما در حال حاضر معماری «مشتری-سرور» را اتخاذ می کند، عملکرد عمدتاً به تأخیر شبکه های تلفن همراه محدود می شود. از آنجایی که دستگاه های تلفن همراه به مرور زمان به پلتفرم های محاسباتی قدرتمندتر تبدیل می شوند، همراه با پیشرفت در گزینه های پایگاه داده فضایی تلفن همراه منبع باز، پیاده سازی الگوریتم های جستجوی 3DQ 2 و 3 به عنوان برنامه های کاربردی مستقل به طور کامل بر روی خود دستگاه تلفن همراه، دیگر جهت گیری های آینده برای این کار است.

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

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

نمونه اولیه 3DQ قرار است به عنوان بخشی از NUIM eCampus Demonstrator برای دانلود رایگان در سال 2013 بر روی هر دو سیستم عامل اندروید و iOS منتشر شود. نمایشگر در حال حاضر در حال ساخت نهایی است و همه شرکای پروژه با قابلیت‌های وب سرویس توسعه یافته در هر گروه تحقیقاتی همکاری می‌کنند.

مراجع و یادداشت ها

بال، ام. چگونه جمع سپاری، اینترنت اشیا و کلان داده ها بر روی فناوری جغرافیایی همگرا می شوند؟ در دسترس آنلاین: http://www.vector1-media.com/dialog/perspectives/23362-how-do-crowdsourcing-the-internet-of-things-and-big-data-converge-on-geospatial-technology.html (دسترسی در 20 ژوئن 2012).
فرولیچ، پ. بالدوف، پ. رایکل، ام. Tobler، چالش های ارائه تصویری RF برای کاربردهای فضایی موبایل: سه مطالعه موردی. در مجموعه مقالات تجسم اطلاعات IV ’08 دوازدهمین کنفرانس بین المللی، لندن، انگلستان، 8 تا 11 ژوئیه 2008; صص 533-538.
گاردینر، ک. Carswell، جست‌وجوی جهت‌گیری مبتنی بر JD Viewer برای برنامه‌های موبایل. در مجموعه مقالات چهارمین کارگاه بین المللی سیستم های اطلاعات جغرافیایی وب و بی سیم (W2GIS2003)، رم، ایتالیا، 13 دسامبر 2003.
سري، اس. برادرانی، پ. Bongio، A.; برامبیلا، ام. کومایی، اس. Matera, M. طراحی برنامه های کاربردی وب با داده فشرده (سری مورگان کافمن در سیستم های مدیریت داده) ; Morgan-Kaufmann Publishers: San Francisco, CA, USA, 2002. [ Google Scholar ]
دی مارتینو، اس. فروچی، اف. مک آردل، جی. پتیلو، جی. تولید خودکار یک WebGIS تطبیقی. در مجموعه مقالات نهمین سمپوزیوم بین المللی در وب و سیستم های اطلاعات جغرافیایی بی سیم (W2GIS 2009)، Maynooth، ایرلند، 7-8 دسامبر 2009; جلد 5886، ص 171–186.
MacAodih، E. ویلسون، دی. برتولتو، M. مطالعه رفتار تعامل فضایی برای ارائه بهبود یافته نقشه های مبتنی بر وب. در مجموعه مقالات نهمین سمپوزیوم بین المللی در وب و سیستم های اطلاعات جغرافیایی بی سیم (W2GIS2009)، Maynooth، ایرلند، 7-8 دسامبر 2009; جلد 5886، ص 120–134.
کوه، فیلترهای فضایی DM برای بازیابی اطلاعات موبایل. در مجموعه مقالات چهارمین کارگاه ACM در مورد بازیابی اطلاعات جغرافیایی (GIR’07)، نیویورک، نیویورک، ایالات متحده آمریکا، 6 تا 10 نوامبر 2007. صص 61-62.
SIG.MA. ترکیب اطلاعات معنایی . در دسترس آنلاین: http://sig.ma (دسترسی در 20 ژوئن 2012).
Google Maps 6 . در دسترس آنلاین: https://play.google.com/store/apps/details?id=com.google.android.apps.maps&hl=en (در 1 مارس 2013 قابل دسترسی است).
یین، جی. Carswell، JD MobiSpatial: تعامل فضایی موبایل با منبع باز فعال. در مجموعه مقالات بیست و هفتمین سمپوزیوم محاسبات کاربردی (SAC 2012)، ترنتو، ایتالیا، 26 تا 30 مارس 2012.
Shek, S. خدمات مبتنی بر موقعیت مکانی نسل بعدی برای دستگاه های تلفن همراه. کمک های مالی CSC در دسترس آنلاین: http://assets1.csc.com/lef/downloads/ (در 20 ژوئن 2012 قابل دسترسی است).
سیمون، آر. Frohlich، P. چارچوب کاربردی موبایل برای وب جغرافیایی. در مجموعه مقالات WWW ’07 شانزدهمین کنفرانس بین المللی وب جهانی، Banff، AB، کانادا، 8-12 مه 2007.
Carswell, JD 3DQ: پرس و جوی دید گنبدی تهدید در دستگاه های تلفن همراه. GIM Int. 2010 ، 24 ، 24-29. [ Google Scholar ]
بندیکت، ام ال برای تصرف فضا: ایزویست ها و میدان های ایزویست. محیط زیست طرح. B 1979 ، 6 ، 47-65. [ Google Scholar ]
فیشر-گویرتزمن، دی. واگنر، IA باز بودن فضایی به عنوان یک معیار عملی برای ارزیابی محیط های ساخته شده. محیط زیست طرح. B 2003 ، 30 ، 37-49. [ Google Scholar ] [ CrossRef ]
فیشر-گویرتزمن، دی. برت، ام. Tzamir, Y. یک روش بصری سه بعدی برای ارزیابی مقایسه ای محیط های متراکم ساخته شده. محیط زیست طرح. B طرح. طراحی 2003 ، 30 ، 575-587. [ Google Scholar ] [ CrossRef ]
مورلو، ای. کارلو، آر. تصویر دیجیتالی از شهر: ایزوویست های سه بعدی در تحلیل شهری لینچ. محیط زیست طرح. B 2009 ، 36 ، 837-853. [ Google Scholar ] [ CrossRef ]
بارتی، پی. میلز، اس. کینگهام، اس. یک نمای شهری خودمحور: روشی برای نگاشت نمای نقطه عطف برای خدمات مبتنی بر مکان عابر پیاده. در چشم انداز جغرافیایی – ابعاد جدید در نقشه برداری ; Moore, A., Drecki, I., Eds. Springer: Auckland, New Zealand, 2008; صص 61-85. [ Google Scholar ]
بارتی، پی. ریتسما، اف. کینگهام، اس. Mills, S. الگوریتم‌های مدل‌سازی دید پیشرفته برای محیط‌های شهری. محاسبه کنید. محیط زیست سیستم شهری 2010 ، 34 ، 518-531. [ Google Scholar ] [ CrossRef ]
اسکای لاین گلوب. نمایشگر TerraExplorer برای زمین سه بعدی . در دسترس آنلاین: http://www.-skylinesoft.com/ (در 20 ژوئن 2012 قابل دسترسی است).
برگن، جی. تشخیص برخورد در محیط‌های سه بعدی تعاملی . CRC Press-Taylor & Francis Group LLC: Boca Raton، FL، ایالات متحده آمریکا، 2003. [ Google Scholar ]
اریکسون، سی. تشخیص برخورد در زمان واقعی (سری مورگان کافمن در فناوری تعاملی سه بعدی) ; CRC Press-Taylor & Francis Group LLC: Boca Raton، FL، ایالات متحده آمریکا، 2004. [ Google Scholar ]
وات، ا. Policarpo, F. 3D Games: Rendering Real-Time and Software Technology ; انتشارات Addison-Wesley: Reading، MA، ایالات متحده آمریکا، 2000. [ Google Scholar ]
راوادا، اس. کزار، بی.ام. Kothuri، R. پردازش پرس و جو در پایگاه داده های فضایی سه بعدی: تجربه با Oracle Spatial 11g. 3D Geo-Inform. علمی 2009 . [ Google Scholar ] [ CrossRef ]
Obermeyer، KJ کتابخانه VisiLibity. در دسترس آنلاین: http://www.VisiLibity.-org (دسترسی در 20 ژوئن 2012).
ایزوویست سه بعدی پسوند Grasshopper برای محاسبه Isovist 3D . در دسترس آنلاین: http://parametricmodel.com/3DIsovist/32.html (در 20 ژوئن 2012 قابل دسترسی است).
VISIODEVKIT. یک موتور رندر 2 بعدی/3 بعدی برای دستگاه های موبایل . در دسترس آنلاین: http://www.nn4d.com/site/global/developer_resources/apis_sdks (در 20 ژوئن 2012 قابل دسترسی است).

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

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

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

09120049370

8 صبح تا 12 شب