یک سرویس وب برای مدیریت زمینه فضایی اختصاص داده شده به بازی های جدی در گوشی های هوشمند و برای آن

چکیده

پروژه GeoEduc3D با هدف ارائه بازی های آموزشی برای گوشی های هوشمند مبتنی بر Geomatics و استفاده از تکنیک های واقعیت افزوده به منظور فراگیرتر کردن این بازی ها است. برای بهبود جنبه‌های همهجانبه و تعاملی آن بازی‌ها، ما بر بهره‌برداری از زمینه فضایی در این چارچوب کاربردی خاص (بازی‌های جدی، واقعیت افزوده، تلفن‌های هوشمند و محیط چند کاربره) تمرکز کردیم. بنابراین، کار ما منجر به طراحی راه حلی شده است که به مدیریت زمینه فضایی در یک محیط چند نفره روی و برای تلفن های هوشمند اختصاص داده شده است. چندین مشارکت انجام شده است: مدل‌سازی بافت فضایی، پیشنهاد یک معماری سرویس‌محور برای مدیریت این زمینه، تعریف بستر فضایی وب سرویس (WSCS) و پیاده‌سازی یک نمونه اولیه WSCS و یک مشتری تلفن همراه با توجه به محیطی که از FourSquare بهره‌برداری می‌کند،

1. مقدمه

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

بنابراین پروژه GeoEduc3D ¹ یک چارچوب کاربردی ممتاز و منحصر به فرد است که در آن تعاملات متعدد و از انواع مختلفی مانند: تعامل بین بازیکن و اشیاء واقعیت افزوده، تعامل بین خود بازیکنان و به طور کلی تعامل بین بازیکن و بازی است. در رابطه با این تعاملات، چندین سؤال باقی می ماند، از جمله:

Ÿ چگونه متوجه شویم که بازیکن در مکان صحیح نسبت به یک شی واقعیت افزوده (AR) قرار دارد که به او اجازه می دهد شی را از یک دیدگاه خاص ببیند؟

Ÿ چگونه می توان مکان سایر بازیکنان را به بازیکن در بازی نشان داد، یا آنها (حریفان یا هم تیمی ها) با در نظر گرفتن جنبه زمان واقعی چه کسانی هستند؟

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

در طول دهه گذشته، برنامه‌ها و سیستم‌های آگاه از زمینه در دنیای کامپیوتر مورد بررسی قرار گرفته‌اند [1-6]. امکان بهره برداری از زمینه پویای واقعی کاربر به منظور ارائه خدمات و مطالب کاملاً متناسب با نیازهای او در زمان واقعی، در تعداد زیادی از زمینه ها مانند گردشگری یا سلامت مورد توجه قرار گرفته است [5-8]. اخیراً تلاش‌های زیادی برای تعریف پلتفرم‌هایی صورت گرفته است که بتوانند به طور مؤثر از کسب و انتشار زمینه حمایت کنند. با این حال، راه‌حل‌های ارائه‌شده اجازه مدیریت زمینه فضایی در یک محیط چند نفره را که بازی‌های مجموعه‌شده در پروژه GeoEduc3D می‌خواهند، نمی‌دهند. مدل‌های زمینه پیشنهادی [9-21] برای بازی‌های تعاملی جدی با استفاده از گوشی‌های هوشمند در محیط چند نفره قابل اجرا نیستند. علاوه بر این، هیچ سیستم از راه دور و قابل همکاری برای تبادل داده بین سیستم عامل های تلفن همراه (حسگرها و برنامه های مشتری) در چنین محیطی وجود ندارد. این یک سوال اساسی را ایجاد می کند: چگونه می توان داده های زمینه مکانی را برای هر برنامه کاربردی، در هر مکان و در هر زمان با در نظر گرفتن جنبه های واقعیت افزوده، بازی آموزشی، تحرک و چند بازیکن مناسب برای چارچوب کاربردی خاص ما در دسترس قرار داد؟

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

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

بنابراین تحقیق ما بر سه هدف فرعی خاص متمرکز شد که عبارتند از:

Ÿ تعریف و مدل سازی بافت فضایی (AR، موبایل، بازی).

Ÿ توسعه معماری برای مدیریت بافت فضایی.

Ÿ طراحی و اجرای یک نمونه اولیه سرویس زمینه فضایی وب با در نظر گرفتن جنبه های خاص پروژه.

در ادامه این مقاله، تعاریف کلی مفاهیم زمینه و بافت فضایی (بخش 2)، همراه با مدل بافت فضایی که ما اتخاذ کرده‌ایم و با توجه به چارچوب کاربردی خود با نیازهای خود سازگار کرده‌ایم، ارائه می‌شود. سپس، بخش 3 ویژگی های فنی شناسایی شده برای به دست آوردن و انتشار زمینه توسط سرویس جهت دار و به دنبال آن معماری سیستم و عملکرد آن را نشان می دهد. سپس طراحی یک سرویس زمینه فضایی وب (WSCS) در بخش 4 پیشنهاد می شود، جایی که قرارداد خدمات و فرمالیسم تبادل داده پیشنهادی ارائه خواهد شد. در بخش 5، یک سناریوی تست بازی به نام EcoSquare را بر اساس Foursquare API ^{2 شرح می دهیم.}که به ما اجازه می دهد تا سرویس وب خود را در شرایط بازی واقعی آزمایش و تأیید کنیم. شرحی از محیط پیاده‌سازی و آزمایش‌ها و نتایج به‌دست‌آمده از راه‌اندازی مشتری و WSCS ما ارائه خواهد شد. ما این مقاله (بخش 6) را با ارائه مشارکت ها و محدودیت های راه حل فعلی و کار آینده خود به پایان می بریم.

2. مدل زمینه فضایی

در این بخش، ابتدا مروری بر مفاهیم زمینه و بافت فضایی را پیشنهاد می‌کنیم و سپس یک مدل بافت مکانی مربوط به چارچوب کاربردی خود را ارائه می‌کنیم. این مدل سازی زمینه [ 22 ] به منظور تسهیل طراحی یک ساختار داده برای سرویس زمینه فضایی وب ما و برای تبادل اطلاعات متنی انجام شد. این طراحی بر اساس دسته بندی تمام اطلاعات مرتبط با چارچوب برنامه و با توجه به تعریف اتخاذ شده برای بافت فضایی است.

2.1. تعریف زمینه و زمینه فضایی

در میان تعاریف زمینه ارائه شده در ادبیات [21،23-31]، بیشترین استفاده و مرتبط ترین تعریف ارائه شده توسط دی [ 32 ] است. به گفته وی، زمینه عبارت است از “هر اطلاعاتی که می تواند برای توصیف وضعیت یک موجودیت استفاده شود، یک موجودیت ممکن است یک شخص، مکان یا شیئی باشد که در تعامل بین یک کاربر و یک برنامه کاربردی (هر دو شامل) مرتبط در نظر گرفته شود.” . در اینجا، “مکان” جغرافیایی مانند اتاق ها، ادارات، ساختمان ها و خیابان ها را نشان می دهد. یک “فرد” می تواند یک فرد یا گروهی از افراد باشد که به صورت مکانی جمع شده یا پخش شده اند. یک “شی” یا یک شی فیزیکی یا یک جزء نرم افزاری را نشان می دهد.

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

در ادبیات، مطالعات مختلف از جنبه مکان کاربر به عنوان یک عنصر یا زیرمجموعه زمینه بهره برداری می کنند [9-33]. با این حال، این مفهوم بیشتر در مفهوم بافت جغرافیایی پیشنهاد شده توسط [ 34 ] مرتبط است. به عقیده نگارنده، بافت فضایی که یک مکان فعلی ساده نیست، تمام اطلاعات جغرافیایی یا غیر جغرافیایی را در بافت های ایستا، پویا و درونی توزیع می کند. زمینه استاتیک مربوط به تمام اطلاعات جغرافیایی ذخیره شده ای است که می تواند بر محیط کاربر تأثیر بگذارد. در همین حال، زمینه پویا شامل هر گونه اطلاعات، در مورد جنبه های متغیر محیط کاربر، به دست آمده از طریق حسگرهای زمان واقعی است. در نهایت، زمینه داخلی شامل اطلاعات کاربر و ترجیحات، مکان، سرعت و جهت او است.

در مورد ما، برای پاسخگویی به نیازهای چارچوب برنامه ما، یک تعریف جدید بر اساس زمینه جغرافیایی پیشنهاد می کنیم [ 22]: «زمینه فضایی با هر اطلاعاتی، فضایی یا مرتبط، مشخص می‌شود که زمینه استاتیک، پویا یا درونی یک موجودیت را مشخص می‌کند که می‌تواند یک شخص، مکان یا شیئی باشد که در تعامل بین یک کاربر و یک برنامه مرتبط در نظر گرفته شود، هر دو شامل “. بنابراین، در چارچوب برنامه ما، زمینه استاتیک توسط اطلاعات ذخیره شده (نقاط مورد علاقه AR POI، ساختمان ها، جاده ها و غیره)، زمینه پویا توسط حسگرهای فیزیکی (سخت افزار مانند GPS، شتاب سنج، حسگرهای لمسی و غیره) تغذیه می شود. و منطقی (داده های مشتق شده از انواع دیگر حسگرها) و زمینه داخلی توسط حسگرهای مجازی (داده های برنامه یا فرآیند: ورودی های تقویم، ایمیل ها، ورودی های نمایه فرم و غیره). ما این تعریف را برای ادامه کار خود، به ویژه برای مدل سازی بافت فضایی که در بخش بعدی کشف خواهیم کرد، اتخاذ کردیم.

2.2. مدلسازی زمینه فضایی

یکی از اهداف ما پیشنهاد یک مدل زمینه فضایی خاص است که متناسب با ویژگی‌های (تحرک، بازی، چند نفره، AR) چارچوب برنامه ما باشد. این مدل باید امکان شناسایی اطلاعات زمینه مکانی را با توجه به بهره برداری از آنها فراهم کند تا برنامه های بازی از زمینه گیمر، هر بازی، پلت فرم تلفن همراه و منطقه بازی آگاه شوند. مدل‌های موجود در ادبیات [9،10،13] در درجه اول با چارچوب کاربردی که در آن طراحی شده‌اند، تطبیق داده شده‌اند. بنابراین هیچ یک از آنها در کار ما قابل استفاده نیستند. بر اساس تعریف خود از زمینه فضایی، ما یک مدل توصیفی از بافت فضایی در هشت (8) دسته، با زیرمجموعه‌ها، شامل تمام اطلاعات پس‌زمینه مربوط به محیط چند نفره خود ایجاد کردیم: محیط زمان اجرا، پخش کننده، مکان، بازی، محیط، دستگاه. ،22 ]. این مدل در جدول زیر ارائه شده است ( جدول 1 ).

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

چنین مدلی انعطاف پذیر است زیرا همیشه امکان پذیر است

جدول 1 . مدل توصیفی بافت فضایی [ 22 ].

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

3. طراحی خدمات زمینه فضایی وب (WSCS)

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

3.1. تحلیل عملکردی سیستم

برای مدیریت اطلاعات زمینه ای، راه حل ما باید دارای ویژگی های اصلی باشد، که مخصوص دستکاری داده های متنی است. این ویژگی ها پس از مطالعه [21،31،35] موجود و با توجه به نیاز سیستم ما تعریف شد. در مقدمه به سه موضوع مهم اشاره کردیم که تفکر ما را در مورد راه حل ارائه کرده است. بازگشت به این مسائل به ما اجازه می دهد تا نیازهایی را که سیستم ما باید به آنها پاسخ دهد را در اینجا شرح دهیم. در واقع، برای بهره برداری از زمینه فضایی در چارچوب برنامه ما با در نظر گرفتن محیط چند نفره، ما عمدتاً نیاز داریم: 1) داده های متنی را بازیابی کنیم، 2) آنها را در جایی ذخیره کنیم، و در نهایت، 3) آنها را بین افراد مختلف به اشتراک بگذاریم. پلتفرم ها در زمان واقعی ویژگی های شناسایی شده برای رفع این نیازها عبارتند از:

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

2) ذخیره سازی متنی داده ها: شما نمی توانید در مورد اکتساب داده ها بدون ذکر ذخیره سازی چنین داده هایی صحبت کنید. در واقع، ما اکنون با مجموعه بسیار بزرگی از داده های چند منبعی و چند مقیاسی روبرو هستیم که باید در یک ساختار متمرکز شوند (نیاز ۲) تا در هر زمان قابل جستجو باشند. بنابراین لازم است مدلی از ذخیره سازی داده های زمینه مکانی داشته باشیم.

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

4) پرس و جو توسط فیلترهای فضایی بر روی داده ها: یکی از مؤثرترین راه ها برای بازیابی داده ها با ابعاد مکانی، اعمال فیلترهای فضایی است. به عنوان مثال، می‌توان از آن برای یافتن مجموعه‌ای از POI که در فاصله «d» یک بازیکن قرار دارند، یا برای دانستن لیست تمام حریفانی که در فاصله «d» یک بازیکن قرار دارند، استفاده کرد. نمونه دیگری از استفاده، بازیابی تمام ساختمان های واقع در یک منطقه جغرافیایی محدود شده توسط یک پاکت شناخته شده است.

5) پرس و جو توسط فیلترهای اسکالر روی داده ها: این عباراتی هستند که از مقایسه کننده های منطقی استفاده می کنند که برای مرتب سازی داده ها به منظور هدف قرار دادن پاسخ های مورد نظر به یک پرس و جو ایجاد شده روی داده های متنی اعمال می شوند. این فیلترها مفید هستند، به عنوان مثال، اگر بخواهیم پروفایل های بازیکن X و بازیکن Y یا مکان بازیکنانی که سن آنها بین 10 تا 15 سال است را بازیابی کنیم. عاقلانه است که فرصت اعمال چنین فیلترهایی را روی داده های متنی داشته باشیم. این ویژگی و ویژگی قبلی مطابق نیاز 3 عملکرد 3 را تکمیل می کند.

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

3.2. معماری و بهره برداری

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

سیستم مدیریت داده زمینه خدمات گرا ما به دنبال کسب و در دسترس قرار دادن داده های زمینه مطابق با چارچوب برنامه ما است. این داده ها از حسگرهای مختلف ساخته شده در دستگاه های تلفن همراه یا از حسگرهای خارجی مانند ایستگاه های هواشناسی می آیند [ 36 ]. بنابراین، آنها را می توان بین برنامه های مختلف بازی های تلفن همراه به اشتراک گذاشت. شکل 1 معماری عملکردی این سیستم را با یک وب سرویس (WSCS—Web Spatial Context Service) به عنوان عنصر مرکزی نشان می دهد. این WSCS مبتنی بر توصیه‌های مشخصات OWS ³ است که مرجعی برای پیاده‌سازی خدمات وب در زمینه مکانی است.

4. سرویس زمینه فضایی وب (WSCS)

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

4.1. قرارداد خدمات

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

ما انتخاب کردیم که WSCS خود را به عنوان یک سرویس “RESTful” تعریف کنیم. بنابراین از طریق HTTP (پروتکل انتقال متن فوق العاده) با ارسال درخواست های GET یا POST فراخوانی می شود. هر عملیات توسط یک URL (Uniform Resource Locator) قرار می گیرد که برای ارسال پارامترهای درخواستی مناسب یا پرس و جوهای کدگذاری شده در بدنه POST سند استفاده می شود.

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

این پنج (5) عملیات WSCS عبارتند از:

Ÿ عملیات GetCapabilities: اطلاعاتی را در مورد شناسایی سرویس (نسخه، نوع، نام، عنوان و شرح خلاصه) و همچنین در مورد ظرفیت های آن یعنی عملیات و فیلترهای پشتیبانی شده به مشتریان می دهد. این عملیات ضروری است زیرا به مشتری اجازه می دهد تا سرویس را کشف کند و عناصر لازم برای بهره برداری بهینه از آن را بدست آورد. در اینجا نمونه ای از درخواست GetCapabilities آورده شده است:

https://localhost:8080/testwscs/wscs؟

درخواست=GetCapabilities

Ÿ عملیات GetContextFeature: وجود این عملیات در قرارداد ما با نیاز 3 توجیه می شود (به بخش 2.3 مراجعه کنید). به منظور بازیابی داده‌های متنی ذخیره‌شده قبلی، مهم است که عملیاتی را به مشتریان ارائه دهیم که به آنها، در هر مکان یا محیط فنی، امکان دسترسی به آنها را از طریق پرس‌و‌جوهای با پارامتر مناسب ارائه می‌دهد. به دنبال مدل بافت فضایی ما ارائه شده در بخش 2.2، یک بافت معین با یک نوع (یا دسته بندی) مشخص مشخص می شود. برای اینکه در انتخاب عبارات مورد استفاده نسبتاً برای اجرای WSCS دقیق تر باشیم، در ادامه این مقاله با عبارت “عنصر” یک داده متنی (به عنوان مثال طول جغرافیایی، طول جغرافیایی، آدرس) را مشخص می کنیم. علاوه بر این، تمام عناصر زمینه ای ارائه شده به عنوان نتایج، اشیا هستند (“ویژگی”). بنابراین، این عملیات نام درخواست (Request) را به عنوان ورودی می گیرد. فرمت خروجی مورد نظر (Output Format)، نام نوع داده متنی (Type Name)، نام عناصر مورد نظر (Element Names)، با طول و عرض جغرافیایی یک نقطه برای تعریف مناطق بافر (Coords)، حداکثر تعداد از ویژگی های مورد انتظار (حداکثر ویژگی ها)، سطح عمق مورد نظر برای داده های برگشتی (سطح) و در نهایت تعریف فیلتری که می خواهیم برای داده ها اعمال کنیم (Filter). اطلاعات درخواست شده را در قالب ذکر شده (به طور پیش فرض JSON) برمی گرداند. رمزگذاری ها در بخش 4.1.2 با مثال های پشتیبانی توضیح داده شده است. سطح عمقی که برای داده های برگشتی مورد نظر است (Level) و در نهایت تعریف فیلتری که می خواهیم روی داده اعمال کنیم (Filter). اطلاعات درخواست شده را در قالب ذکر شده (به طور پیش فرض JSON) برمی گرداند. رمزگذاری ها در بخش 4.1.2 با مثال های پشتیبانی توضیح داده شده است. سطح عمقی که برای داده های برگشتی مورد نظر است (Level) و در نهایت تعریف فیلتری که می خواهیم روی داده اعمال کنیم (Filter). اطلاعات درخواست شده را در قالب ذکر شده (به طور پیش فرض JSON) برمی گرداند. رمزگذاری ها در بخش 4.1.2 با مثال های پشتیبانی توضیح داده شده است.

از طریق پارامتر فیلتر که بیان رمزگذاری فیلتر (استاندارد OGC) را دریافت می کند، از ناوبری از طریق سلسله مراتب عناصر (به منظور به دست آوردن عناصر یک سطح یا فرزندان یک عنصر) و عملیات فیلتر فضایی یا اسکالر پشتیبانی می کند. این گزینه به ما امکان می دهد تا نیازهای 4 و 5 را برآورده کنیم (بخش 2.3).

در اینجا نمونه ای از درخواست بدون پارامتر فیلتر آمده است:

https://localhost:8080/testwscs/wscs?request=getContextFeature&typeName=localisation&elementNames=id,lat,lng,user&maxFeatures=2&level=2 نمونه دیگری از درخواست با پارامتر فیلتر:

https://localhost:8080/testwscs/wscs?request=getContextFeature&typeName=localisation

&elementNames=id، lat،lng،user

&maxFeatures=2&level=2

&فیلتر= هندسه 71.4،-47.8 <distanceunits=’m’>1000</distanceunits=’m’>

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

در اینجا نمونه ای از درخواست است:

https://localhost:8080/testwscs/wscs؟

request=describeContextFeatureType

&typeName=محلی سازی

Ÿ LockContextFeature Operation: این عملیات به مشتریان اجازه می دهد تا درخواست قفل کردن ویژگی مورد نظر خود را برای ایجاد یا به روز رسانی کنند. در نتیجه تضادهای دسترسی و یکپارچگی داده ها به خوبی مدیریت می شوند. نام نوع داده متنی (نام نوع)، نحوه قفل شدن ویژگی ها (عمل قفل)، مدت زمان قفل (انقضا) و ویژگی هایی از نوع ContextFeature که باید مسدود شوند (فیلتر) را به عنوان ورودی می گیرد. در نتیجه، شناسه‌های قفل را برمی‌گرداند که می‌توان از آنها برای عمل بر روی داده‌های قفل‌شده استفاده کرد.

Ÿ عملیات تراکنش: این به مشتریان اجازه می دهد تا یک ویژگی را ایجاد، به روز کنند یا حذف کنند. این عملیات مکمل عملیات LockContextFeature برای رفع نیازهای (1 و 2 ارائه شده در بخش 2.3) در رابطه با جمع آوری و ذخیره سازی داده ها است. این عملیات به عنوان ورودی برای انجام تراکنش نیاز دارد، یعنی درج، به روز رسانی یا سرکوب (Transaction)، شناسه اشیاء قفل شده (شناسه قفل) و نحوه پردازش ویژگی های قفل شده پس از تکمیل تراکنش.

در بخش بعدی، با استفاده از مثال عملگر GetContextFeature، یک کدگذاری برای پاسخی که توسط سرویس مشتری برگردانده شده است، پیشنهاد می کنیم.

4.2. رمزگذاری پاسخ

سرویس وب ما برای به دست آوردن و انتشار عناصر زمینه در تلفن های هوشمند و برای مشتریان تلفن همراه طراحی شده است. یکی از رویکردهای توصیفی موجود برای این نوع داده، نشان دادن آنها توسط جفت های ویژگی-مقدار [ 36 ] است. ما این رویکرد را انتخاب می‌کنیم، زیرا این مزیت، در میان دیگران، ارائه پشتیبانی جزئی از معناشناسی (که در صفت موجود است) را دارد. طبق این تکنیک، زمینه یک گیمر مجموعه ای از جفت های ویژگی-مقدار در هر زمان معین خواهد بود. بنابراین، هنگامی که مشتری یک درخواست GetContextFeature را به سرویس ارسال می کند، در ازای آن مجموعه ای از ویژگی ها-مقدارهای سازماندهی شده در دسته یا نوع زمینه دریافت می کند. کاربر همچنین می‌تواند نمایشی از پاسخ (یا قالب) در JSON یا XML داشته باشد. به طور کلی عناصر موجود در ساختار پاسخ عبارتند از:

Ÿ عنصر ریشه، مجموعه ویژگی: مجموعه ای از ویژگی های زمینه.

Ÿ یک یا چند ویژگی، ویژگی زمینه: موجودیت زمینه از نوع یا دسته خاصی (موقعیت مکانی، پخش کننده و غیره)، که توسط عناصر زمینه درخواستی تشکیل شده است.

Ÿ شناسه شناسه برای شناسایی یک ویژگی زمینه.

Ÿ نوع: هر نوع ویژگی متنی (دسته) در پاسخ ظاهر می شود.

Ÿ یک یا چند عنصر زمینه شامل تمام عناصری است که یک ویژگی زمینه را تشکیل می دهند. سپس این عناصر متنی به عنوان ویژگی-مقدار بیان می شوند.

جدول 2 نمونه ای از پاسخ ها را بر اساس فرمت JSON یا XML ارائه می دهد.

برای داشتن یک قالب کلی، عناصر باید به عنوان جفت ویژگی-مقدار توصیف شوند. داده های ارائه شده، منشأ یا ویژگی آنها نسبت به چارچوب برنامه هر چه باشد، قالب برگشتی همچنان معتبر است. علاوه بر این، با چنین نوشتاری، می توانید کل عناصر زمینه ارائه شده در مدل ما را بگنجانید (یا در صورت نیاز به دسته ها یا زیر مجموعه ها اضافه کنید).

5. نمونه سازی

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

جدول 2 . کدگذاری نمونه پاسخ در JSON و XML.

امکان سنجی رویکرد ما و اقدام به اعتبار سنجی سرویس زمینه فضایی وب ما، ما عمداً بر جنبه پرس و جو به جای اکتساب تأکید کرده ایم. ما پیاده سازی عملیات GetContextFeature را انتخاب کردیم، زیرا برای ارزیابی سودمندی و اثربخشی سرویس ما در جنبه پرس و جو مناسب ترین است.

عدم اجرای ویژگی اکتساب داده های متنی در نمونه اولیه ما مستلزم داشتن یک مجموعه داده واقعی متناسب با نیازهای مربوط به پروژه GeoEduc3D ما است. این مجموعه داده‌ها باید جنبه‌های زمینه مرتبط با دسته‌هایی را که قبلاً تعریف کرده‌ایم در نظر بگیرد (به بخش 2.2 مراجعه کنید). برای این کار، ما استفاده از برنامه FourSquare ⁴ را انتخاب کردیم که بسیاری از این جنبه‌های زیر را ارائه می‌دهد: تحرک، مکان، بازی، اجتماعی، بازیکن. این اپلیکیشن در سال‌های گذشته بسیار محبوب بوده است، زیرا از طریق یک API، به تعداد زیادی از داده‌های جغرافیایی (یا نه) ایجاد شده در طول ماه‌ها توسط شهروندان از طریق افزودن مکان‌های بازدید شده از طریق برنامه تلفن همراه، دسترسی پیدا می‌کند. این برنامه یک رابط RESTful ارائه می دهد که روش هایی را برای دسترسی به منابعی مانند مکان ها یا کاربران در URL های تعریف شده ارائه می دهد.

برای بازیابی اطلاعات، مشتری به سادگی یک درخواست HTTP GET یا POST ساده به API ارسال می کند و پاسخ ها در قالب JSON یا JSONP برگردانده می شوند. برای اطمینان از ایمنی این حجم مهم از داده ها، FourSquare API فقط اجازه دسترسی از طریق استاندارد احراز هویت OAuth 2.0 ^{5 را می دهد.} این انتخاب به این معنی است که همه درخواست ها باید توسط HTTPS ایمن شوند. علاوه بر دسترسی به این داده ها، ما همچنین پایگاه داده ای را بر اساس ساختار مدل بافت فضایی ارائه شده در بخش 2.2 ایجاد کردیم. این پایگاه داده با داده های شبیه سازی شده ترکیب شده با داده های ارائه شده توسط FourSquare پر شده است.

در قسمت بعدی سناریوی بازی اتخاذ شده را توضیح خواهیم داد تا درک داده های تست ها و نمونه هایی از درخواست های ارسالی و پاسخ آنها را تسهیل کنیم.

5.1. سناریوی بازی: EcoSquare

سناریوی پیشنهادی در درجه اول برای اجازه دادن به اعتبار مدل بافت فضایی و سرویس بافت فضایی وب ما (WSCS) طراحی شده است. این با انتظارات و اهداف پروژه GeoEduc3D با بازی های جدی، دستگاه های تلفن همراه، واقعیت افزوده و موضوع محیطی مطابقت دارد. نام بازی را EcoSquare گذاشتیم. این بازی جامعه نوجوانان 12 تا 18 ساله را مخاطب قرار می دهد. همانطور که از نام آن پیداست، بر اساس برنامه FourSquare است و برخی از مفاهیم اکولوژیکی را به کار می برد. برای توصیف مختصر بازی، هر بازیکن این فرصت را دارد که از یک ساختمان بازدید کند، آن را ارزیابی کند، نظر یا نکته ای بنویسد (نکته زیست محیطی) و/یا عکسی را که در محل با استفاده از خود گرفته شده ارسال کند.

گوشی های هوشمند. از آنجایی که همه بازیکنان می‌توانند همه این اطلاعات را ببینند، ما جامعه‌ای از بازیکنان داریم که قدردانی خود را از مکان‌های بازدید شده به اشتراک می‌گذارند، در حالی که در مورد یک منطقه جغرافیایی می‌آموزند. علاوه بر این، جنبه اکولوژیکی مربوط به ارائه یک ابزار ارزیابی بر اساس معیارهایی است که باید توسط ساختمان ها رعایت شود تا دوستدار محیط زیست اعلام شوند: پاکیزگی، دسترسی، انرژی، گرمایش، هوای داخل خانه، بازیافت یا اقدامات سبز. این معیارها از گواهینامه های مسکن و محیط زیست فرانسه (H & E ⁶ ) و LEED ⁷ آمریکای شمالی (رهبری در طراحی انرژی و محیط زیست) استخراج شده اند. جدول 3بازیگران، موارد استفاده شده و کلمات کلیدی مرتبط با بازی ما را ارائه می دهد. به طور خلاصه، بازیکنان در تیم های دو یا چند نفره گروه بندی می شوند. هر بازیکن در یک زمان به یک تیم تعلق دارد و ممکن است کاپیتان تیم یا “اکوبریگادیر” باشد. هدف اصلی این تیم ها اشغال بیشترین تعداد “Ecolieux” برای رهبری رده بندی کلی تیم ها است.

به‌علاوه، برای بهره‌برداری بیشتر از بعد فضایی، بازیکن می‌تواند از فیلترها، از نقشه «ÉcoChamp» (نگاه کنید به شکل 3 ، تصویر سمت راست)، روی «Écolieux» که اشغال می‌کند، «Écolieux» حریف، یا تیم “écolieux”.

5.2. محیط پیاده سازی

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

جدول 3 . جدول توصیفی موارد استفاده EcoSquare.

منبع باز و “نرم افزار رایگان” به عنوان معیار انتخاب، زیرا از جمله ویژگی های انعطاف پذیری و دسترسی را ارائه می دهد.

برای هر لایه (مشتری، سرور، منابع) معماری ما، ابزارهای مورد استفاده را خواهیم دید که نحوه و چرایی انتخاب آنها را توضیح می دهد و به ما اجازه اجرای چه چیزی را داده است. نتایج بعداً در بخش 6 با مثال‌ها و اسکرین‌شات‌هایی از رابط‌های مشتری توضیح داده خواهد شد.

5.2.1. مشتری

برای پیاده سازی مشتری خود، ما به یک چارچوب توسعه برنامه وب تلفن همراه روی آوردیم تا به ما استقلال از هر پلت فرم بومی تلفن هوشمند بدهد. بنابراین برنامه بازی ما را می توان بر روی هر پلت فرم تلفن همراه (iOS، Android) بدون نیاز به تغییرات عمده کد یا تغییر در محیط برنامه نویسی مستقر کرد. علاوه بر این، چارچوب توسعه باید برخی از معیارها را برآورده کند: بدون زبان مادری. قابل حمل بودن؛ دسترسی به API بومی از طریق یک لایه دسترسی میانی. رایگان؛ وب گرا برای عدم وابستگی به پلت فرم تلفن همراه و خواندن داده ها در قالب XML یا JSON.

امروزه چندین ابزار برخی از این معیارها را برآورده می کنند، رایگان یا تجاری، منبع باز یا غیر. آنها عمدتاً مبتنی بر ترکیبی از فناوری‌های HTML5، CSS3 و جاوا اسکریپت برای رسیدگی به مشکل چند پلتفرم هستند: jQTouch ⁸ ، Phonegap ⁹ ، Rhomobile Rhodes ¹⁰ یا Sencha Touch ¹¹ . با توجه به معیارهایمان، ما انتخاب کردیم که از Sencha Touch، یکی از محبوب‌ترین ابزارهای رایگان، تحت مجوز GNU GPL v3 استفاده کنیم. این به توسعه برنامه های کاربردی وب تلفن همراه برای iPhone، Android و BlackBerry کمک می کند. علاوه بر این، Sencha Touch توسعه سریع برنامه های کاربردی وب تلفن همراه را با امکان درخواست داده از طریق فناوری AJAX یا JSONP امکان پذیر می کند.

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

علاوه بر این، جالب‌ترین ویژگی، برگه EcoChamp است که حاوی نقشه Google Maps است که «Écolieux» بازیابی شده از نمونه اولیه WSCS ما را نشان می‌دهد. ما همچنین فیلترهایی را روی “Écolieux” پیاده سازی کردیم ( شکل 2 ، تصویر سمت راست را ببینید).

5.2.2. سرور

هنگامی که یک وب سرویس باید پیاده سازی و اجرا شود، باید به چهار چالش اساسی پرداخت: 1) شرح سرویس، 2) اجرای سرویس، 3) انتشار، کشف و اتصال سرویس و 4) فراخوانی و اجرای وب سرویس. PHP، NET و J2EE پلتفرم های موجود هستند که معماری ها و استانداردهای مناسب برای مدیریت موثر این جنبه های مختلف را ارائه می دهند. انتخاب هر یک از این پلتفرم‌ها نه تنها بر سطح پیچیدگی و کاهش زمان توسعه تأثیر می‌گذارد، بلکه بر عملکرد و نگهداری خدمات نیز تأثیر می‌گذارد. در مورد ما، ما ترجیح دادیم با استانداردهای J2EE کار کنیم زیرا انتخاب گسترده ای از ابزارهای توسعه، سرورهای برنامه و اجرای Java Servlet از کتابخانه های منبع باز برای XML یا JSON وجود دارد. و همچنین کتابخانه های دستکاری اشیاء جغرافیایی و پردازش فضایی در دنیای جاوا. پیاده سازی ما در نهایت بر اساس زبان جاوا، Eclipse Galileo IDE و منبع باز آپاچی تامکت به عنوان ظرف سرولت است. این ابزارها به ما این امکان را داده اند که بخشی از قرارداد خدمات خود را (به بخش 4.1.1 مراجعه کنید) با اپراتور GetContextFeature (برای اثبات مفهوم) پیاده سازی کنیم و از سرور پایگاه داده و FourSquare پرس و جو کنیم.

5.2.3. منابع

نیاز حیاتی ما در اینجا داشتن یک سیستم مدیریت پایگاه داده (DBMS) است که داده های زمینه را از حسگرهای مختلف پراکنده در محیط چند نفره جدول 4 ذخیره می کند. اجزای رابط گرافیکی مشتری تلفن همراه ما.

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

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

5.3. WSCS و EcoSquare در عمل

در این بخش، به اختصار برخی از آزمایش‌هایی را که بر روی نمونه اولیه وب سرویس و EcoSquare انجام دادیم، ارائه می‌کنیم. این آزمایش‌ها برای تأیید اثربخشی، ارتباط و امکان‌سنجی راه‌حل ما خدمت می‌کنند.

ابتدا، رابط مشتری زبانه هایی از جمله برگه “EcoChamp” را نشان می دهد، که به بازیکن یک نمای نقشه از منطقه بازی را می دهد. بازیکن می تواند مکان فعلی خود و همچنین تمام “Écolieux” موجود در نزدیکی را همانطور که در تصویر سمت چپ شکل 2 نشان داده شده است، مشاهده کند.

با انتخاب یک «Écolieu» از این رابط، او می‌تواند بررسی کند و نظرات یا رتبه‌بندی‌ها را بگذارد. برای نمایش این داده ها بر روی نقشه و دریافت اطلاعات متنی مانند نام مکان، آدرس، بازیکن اشغال کننده مکان یا فاصله بین مکان و مکان فعلی خود، با استفاده از عملگر GetContextFeature با سرویس خود تماس گرفتیم.

برای نشان دادن استفاده از وب سرویس ما، از طریق شکل 3 ، نمونه ای از درخواست GET ارسال شده به WSCS و پاسخ را در قالب JSON نشان می دهیم. این مثال یک ابزار قوی برای آزمایش دسترسی مشتری به اطلاعات بافت مکانی مربوط به عناصر “Écolieux” برای اشغال کردن را نشان می دهد. مثال زیر می خواهد سه ویژگی زمینه اول نوع “Écolieux” را از مختصات داده شده بازیابی کند. آدرس درخواست اینجاست:

https://localhost:8080/testwscs/wscs?request=

getContextFeature&typeName=ecolieux

&maxFeatures=3&coords=46.78,-71.27 در شکل 3 ، پاسخ کامل این پرس و جو را در قالب JSON پیدا می کنیم. با استفاده از مختصات داده شده به عنوان پارامتر، ما قادریم از جمله اطلاعات “فاصله” را که نسبت به عناصر “Écolieux” محاسبه می شود، بازیابی کنیم. این اطلاعات بعداً برای محدود کردن داده های برگشتی بر اساس یک منطقه بافر استفاده می شود. برای انجام این کار،

کلاینت می تواند از پارامتر Filter برای محدود کردن داده های برگشتی به یک ناحیه بافر خاص که پخش کننده مرکز آن است استفاده کند. در حال حاضر، به طور پیش فرض، 10 “Écolieux” واقع در فاصله 500 متری دور را به مشتری برمی گردانیم. توجه داشته باشید که این محبوب‌ترین «Écolieux» از API است که پدیدار شد، زیرا ممکن است بدون داشتن داده‌های زیادی برای مشورت، به سرعت بدانید «دشمنان» کجا هستند.

مثال زیر استفاده از درخواست GetContextFeature را با یک فیلتر در فاصله (DWithin) نشان می دهد. ما در اینجا 10 “Écolieux” را که در شعاع 1000 متری از محل فعلی یک بازیکن قرار دارند، بازیابی می کنیم ( شکل 4 ). برخلاف مثال قبلی، اینها موارد محبوب نیستند، بلکه همه آنهایی هستند که در ناحیه محدود شده توسط فیلتر هستند. در اینجا مشتری به صورت شفاف به داده ها در صورت نیاز دسترسی پیدا می کند. آدرس اینترنتی این است:

https://localhost:8080/testwscs/wscs?request=getContextFeature&typeName=ecolieux&maxFeatures=3

&فیلتر= هندسه 46.78،-71.2 <distanceunits=’m’>1000</distanceunits=’m’>

با اطلاعات فاصله نسبت به موقعیت بازیکن، آزمایشی را روی داده‌های بازگردانده شده اعمال کردیم، تنها با نگه‌داشتن آن‌هایی که در منطقه بافر درخواستی یافت می‌شوند. توجه می کنیم که در واقع تعداد بیشتری “Écolieux” روی صفحه نمایش داده می شود ( شکل 5 ). وقتی از نزدیک به پاسخ نگاه می کنیم، می توان مشاهده کرد که مقادیر فاصله کمتر از 1000 متر است.

6. نتیجه گیری/چشم انداز

در این مقاله، ما پیشنهاد یک وب سرویس اختصاص داده شده به مدیریت اطلاعات زمینه مکانی را به عنوان بخشی از پروژه GeoEduc3D بیان کردیم. ما ابتدا مروری بر مفاهیم زمینه و بافت فضایی و همچنین مدل بافت فضایی که توسعه دادیم، انجام دادیم. سپس نیازهای مربوط به چارچوب برنامه را به همراه عملکردهایی که چنین نیازهایی را برآورده می کنند، شناسایی کرده ایم. این مشخصات در دست، ما معماری راه حل خود را با تمرکز بر عملکرد سطوح مختلف (مشتری، سرور، منبع) توسعه دادیم. این ما را با ارائه یک قرارداد خدمات متناسب با نیازهای ما و بر اساس مشخصات OGC WFS و Filter Encoding و همچنین یک رمزگذاری برای پاسخ‌های بازگردانده شده توسط سازمان، به مشارکت جدیدی در تعریف سرویس زمینه فضایی وب (WSCS) سوق داد. سرویس، در قالب XML و/یا JSON. در نهایت، ما یک نمونه اولیه از WSCS و یک کلاینت برنامه بازی EcoSquare را پیاده‌سازی کردیم که به نشان دادن امکان‌پذیری رویکرد ما و همچنین مفید بودن آن کمک می‌کند. بنابراین، با کمک های ما، ما معتقدیم که اکنون می توان زمینه فضایی را برای برنامه های بازی مشتری در محیط های چند نفره در دسترس قرار داد. راه حل ما این مزیت را دارد که قابلیت تعامل، انعطاف پذیری و مستقل بودن از برنامه مشتری و ویژگی های آن از نظر داده های متنی را دارد. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. ما یک نمونه اولیه از WSCS و یک کلاینت برنامه بازی EcoSquare را پیاده سازی کردیم که به نشان دادن امکان سنجی رویکرد ما و همچنین مفید بودن آن کمک می کند. بنابراین، با کمک های ما، ما معتقدیم که اکنون می توان زمینه فضایی را برای برنامه های بازی مشتری در محیط های چند نفره در دسترس قرار داد. راه حل ما این مزیت را دارد که قابلیت تعامل، انعطاف پذیری و مستقل بودن از برنامه مشتری و ویژگی های آن از نظر داده های متنی را دارد. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. ما یک نمونه اولیه از WSCS و یک کلاینت برنامه بازی EcoSquare را پیاده سازی کردیم که به نشان دادن امکان سنجی رویکرد ما و همچنین مفید بودن آن کمک می کند. بنابراین، با کمک های ما، ما معتقدیم که اکنون می توان زمینه فضایی را برای برنامه های بازی مشتری در محیط های چند نفره در دسترس قرار داد. راه حل ما این مزیت را دارد که قابلیت تعامل، انعطاف پذیری و مستقل بودن از برنامه مشتری و ویژگی های آن از نظر داده های متنی را دارد. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. بنابراین، با کمک های ما، ما معتقدیم که اکنون می توان زمینه فضایی را برای برنامه های بازی مشتری در محیط های چند نفره در دسترس قرار داد. راه حل ما این مزیت را دارد که قابلیت تعامل، انعطاف پذیری و مستقل بودن از برنامه مشتری و ویژگی های آن از نظر داده های متنی را دارد. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. بنابراین، با کمک های ما، ما معتقدیم که اکنون می توان زمینه فضایی را برای برنامه های بازی مشتری در محیط های چند نفره در دسترس قرار داد. راه حل ما این مزیت را دارد که قابلیت تعامل، انعطاف پذیری و مستقل بودن از برنامه مشتری و ویژگی های آن از نظر داده های متنی را دارد. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. انعطاف پذیر و مستقل از برنامه مشتری و ویژگی های آن از نظر داده های متنی. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما. انعطاف پذیر و مستقل از برنامه مشتری و ویژگی های آن از نظر داده های متنی. قرارداد خدمات یک بار تعریف می شود و اپراتورهای آن به ما اجازه می دهند تا نیازهای سامانه را پوشش دهیم. اجرای کامل عملیاتی این WSCS و آزمایش‌های واقعی هنوز باید انجام شود، همراه با پرسش‌نامه‌هایی برای مصرف‌کنندگان بالقوه مدل زمینه برای بهبود و اعتبارسنجی پیشنهادات ما.

Elodie Edoh-Alove، Frédéric Hubert، Thierry Badard (AR، Games، Mobile)، عاقلانه است که یک استاندارد هستی شناسی بسازیم که این مزیت را داشته باشد که امکان توسعه فرآیندها و تجمیع های هوشمند با داده های بازگردانده شده توسط WSCS را داشته باشد. چنین هستی شناسی احتمالاً منجر به جایگزینی رمزگذاری با جفت ارزش نام با رمزگذاری با یک مدل مبتنی بر هستی شناسی (OWL-Web Ontology Language و RDF-Resource Description Framework) خواهد شد.

منابع