چارچوب کاربردی جغرافیایی برای روابط جهت دار

خلاصه

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

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

کلید واژه ها:

روابط جهتی ؛ چارچوب های مرجع ؛ پردازش پرس و جو جغرافیایی

1. معرفی

افزایش قابل توجه در دسترس بودن داده های جغرافیایی منجر به توسعه بسیاری از برنامه های کاربردی سیستم های اطلاعات جغرافیایی (GIS) در سال های اخیر شده است. استانداردهای باز مرجع در پانورامای داده های مکانی توسط چندین سازمان مانند کنسرسیوم فضایی باز (OGC)، سازمان بین المللی استانداردسازی (ISO) و سازمان بین المللی هیدروگرافی (IHO) ایجاد شده است. از ابتدا، به نظر می رسید که تعریف روابط فضایی مناسب که تعامل انسان و ماشین را نسبت به داده های جغرافیایی ارجاع می دهد، یکی از اهداف اصلی باشد که پژوهش باید بر روی آن تمرکز کند. اولین روابط فضایی که توسعه یافت روابط توپولوژیکی بود [ 1 ، 2 ، 3]. به طور کلی، روابط فضایی در روابط توپولوژیکی، تصویری و متریک طبقه بندی شده اند [ 4 ، 5 ].

هندسه فرافکنی را می توان برای ساخت یک مدل جامع استفاده کرد که روابط میانی بین توپولوژی و متریک را پوشش می دهد. برای داشتن یک درک کیفی از روابط تصویری، فکر کردن به نماهای دو بعدی مختلف از صحنه سه بعدی دنیای واقعی از اشیاء مفید است: تغییر زاویه دید، جنبه های متریک مانند فواصل و زوایای بین اشیاء به نظر می رسد. متفاوت باشد، اما ویژگی هایی وجود دارد که در همه نماها مشترک هستند. این ویژگی های رایج، ویژگی های تصویری هستند. در این زمینه، کار بر روی روابط تصویری سه تایی (مدل 5 تقاطع) در ادبیات [ 6 ، 7 ، 8 ، 9] پیشنهاد شد.]. روابط فرافکنی شامل زیرمجموعه های مشترکی مانند روابط جهتی و روابط دید است [ 10 ، 11 ، 12 ].

روابط جهتی نشان دهنده دسته ای از روابط فضایی است که اطلاعاتی در مورد آرایش فضایی اشیاء در یک صحنه یا مکان ها در یک فضای تعبیه شده ارائه می دهد [ 13 ، 14 ]. روابط جهتی در بیشتر موارد روابط دوتایی بین دو شی فضایی هستند، اما یک چارچوب مرجع برای رفع ابهام از معنای رابطه در یک زمینه معین لازم است [ 15 ، 16 ، 17 ]. چارچوب های مرجع در ارتباط با روابط جهت دار از زمان های طولانی از طبقه بندی های تاریخی [ 18 ، 19 ، 20 ] تا تحولات اخیر [ 21 ، 22 ، 23] مورد مطالعه قرار گرفته است ].

در [ 21 ]، نویسنده مدلی از روابط جهت‌دار را در چارچوب‌های مرجع مختلف تعریف می‌کند و انواع و زیرشاخه‌های اصلی را مشخص می‌کند: این نتیجه را می‌توان هستی‌شناسی چارچوب‌های مرجع در نظر گرفت و طبقه‌بندی [19] را اصلاح می‌کند . دانش جهت ها و چارچوب های مرجع امکان تعریف مجموعه ای از عملگرهای جهت دار را می دهد که می توانند در یک زبان پرس و جو فضایی ادغام شوند. روابط جهتی به مدل 5 تقاطع نگاشت شده است، که دقیقاً تعاریف هندسی و الگوریتم هایی را برای محاسبه روابط ارائه می دهد.

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

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

2. اطلاعات پس زمینه

2.1. مدل 5 تقاطع

یک رابطه تصویری سه تایی موقعیت یک جسم اولیه A را نسبت به چارچوب مرجعی که توسط دو ناحیه دیگر B و C ساخته شده است را بیان می کند . در مدل 5 تقاطع، چارچوب مرجع حول دو منطقه مرجع B و C همانطور که در شکل 1 نشان داده شده است، ساخته شده است . ناحيه B را شيء مرجع اول ( RO ₁ ) و ناحيه C را شيء مرجع دوم ( RO ₂ ) مي نامند. یک جهت از RO ₁ به RO ₂ وجود داردکه برای تعیین نام مناطق ضروری است. از این رو، پنج ناحیه ساخت و ساز قبل ( B ، C )، بین ( B ، C )، بعد ( B ، C )، سمت چپ ( B ، C )، و سمت راست ( B ، C ) نامیده می شوند. اجازه دهید ماتریس زیر را از تقاطعات خالی/غیر خالی یک منطقه A با چنین پنج ناحیه در نظر بگیریم:

	آ ∩سمت چپ ( B , C )
آ ∩قبل از ( B , C )	آ ∩بین ( B , C )	آ ∩بعد از ( B , C )
	آ ∩رایت ساید ( B , C )

ماتریس قبلی را تقاطع 5 می نامند . در ماتریس، مقدار 0 یک تقاطع خالی را نشان می دهد، در حالی که مقدار 1 یک تقاطع غیر خالی را نشان می دهد. از آنجایی که ماتریس با هر پنج مقدار برابر با صفر با یک رابطه مطابقت ندارد، مدل 5 تقاطع قادر به شناسایی 31 رابطه تصویری است. با توجه به محدودیت فضا، ما فقط برخی از آنها را در شکل 2 نشان می دهیم . پنج رابطه اساسی که در آن ناحیه اولیه A به طور کامل در یک ناحیه قرار می گیرد، به ترتیب سمت راست ، سمت چپ ، بین ، قبل و بعد نامیده می شوند . زمانی که ناحیه اولیه Aدر بیش از یک ناحیه قرار می گیرد، روابط مرکب مانند قبل:rightside وجود دارد . جزئیات بیشتر در مورد ساختار هندسی و ویژگی های مدل را می توان در [ 24 ] یافت.

2.2. چارچوب های مرجع

در شکل 3 ، ما یک دسته بندی از چارچوب های مرجع را همانطور که در [ 21 ] پیشنهاد شده است نشان می دهیم. از این به بعد، توصیف را به سه مورد از آنها برای محدودیت فضا محدود می کنیم: چارچوب مرجع بیرونی از نوع فرعی «جغرافیایی-شمال متعارف» (که در ادامه مقاله به اختصار به عنوان چارچوب مرجع «جغرافیایی» نامیده می شود)، چارچوب مرجع ذاتی زیرمجموعه «هندسی» (که در ادامه مقاله به عنوان چارچوب مرجع «هندسی» به اختصار آمده است)، و چارچوب مرجع deictic از نوع فرعی «آلوسانتریک» (در ادامه مقاله به اختصار چارچوب مرجع «دیکتیک» است) . این سه نوع فریم مرجع در سراسر مقاله به عنوان یک مطالعه موردی مکرر مورد استفاده قرار خواهند گرفت. برای توضیح همه چارچوب های مرجع، به مقاله اصلی اشاره می کنیم [21 ].

در چارچوب جغرافیایی مرجع، اشیاء مرجع B و C از مدل 5 تقاطع با اولین شی مرجع و خط شمالی معمولی مطابقت دارد که در شکل 4 نشان داده شده است . در این چارچوب، روابط جهتی شمال_از ، شرق_از، جنوب_از و غرب_از شناسایی می شوند. آنها را می توان به روابط 5 تقاطع با تابع تبدیل زیر برای چارچوب مرجع خارجی-جغرافیایی-متعارف شمال (EGN) نگاشت کرد. ΦEجین:

ΦEجین
r	r”
شمال	بین
شرق_از	سمت راست
جنوب	قبل از
غرب_از	سمت چپ
	بعد از

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

c1.name از کشور AS c1، کشور AS c2 را انتخاب کنید
WHERE c2.name = "الجزایر" AND south_of(c1.the_geom, c2.the_geom);

به عنوان دومین نوع فرعی، اکنون چارچوب هندسی مرجع را مورد بحث قرار می دهیم. در این مورد، اشیاء B و C از مدل 5 تقاطع با دو طرف “پشت” و “جلو” جسم مرجع در شکل 5 مطابقت دارند . در این چارچوب، روابط جهت داخل، سمت راست، عقب، سمت چپ و جلو مشخص می شود. آنها را می توان با تابع تبدیل زیر برای چارچوب مرجع درونی-هندسی (IC) به روابط 5 تقاطع نگاشت کرد. Φمنسی:

Φمنسی
r	r’
داخل	بین
سمت راست	سمت راست
بازگشت	قبل از
سمت چپ	سمت چپ
جلو	بعد از

نمونه ای از پرس و جو برای چارچوب مرجع اخیر را می توان به صورت زیر نشان داد ( شکل 6 را ببینید ). اگر کاربر بخواهد بداند: «سوپرمارکت‌های مقابل ساختمانی که من در آن زندگی می‌کنم چیست؟»، در ترکیب با برخی اطلاعات فاصله (نه هدف این مقاله)، پرسش SQL به صورت زیر در می‌آید:

SELECT b1.id از ساختمان AS b1، ساختمان AS b2
WHERE b2.name = "خانه من" و جلو (b1.the_geom,b2.the_geom) AND near(b1.the_geom, b2.the_geom);

آخرین چارچوب مرجعی که در مورد آن بحث می کنیم، چارچوب مرجع است. در این مورد، اشیاء B و C از مدل 5 تقاطع با موقعیت ناظر و شی مرجع در شکل 7 مطابقت دارند . در این چارچوب، روابط جهت دار جلو، سمت راست، چپ و پشت مشخص می شود. آنها را می توان به روابط 5 تقاطعی با تابع تبدیل زیر برای چارچوب مرجع deictic-allocentric (DA) نگاشت کرد. ΦDآ:

ΦDآ
r	r’
جلو	بین
حق_از	سمت راست

چپ_از	سمت چپ
پشت	بعد از

نمونه ای از چارچوب مرجع deictic را می توان به صورت زیر نشان داد ( شکل 8 را ببینید ). فرض کنید یک گردشگر در حال قدم زدن در یک بافت شهری است و به یک بنای تاریخی نگاه می کند و می پرسد که ساختمان های سمت چپ او چیست؟ سپس کوئری SQL مربوطه به صورت زیر خواهد بود:

SELECT a.id از ساختمان AS b، ساختمان AS a
WHERE b.name = "بنای یادبود" و سمت چپ (a.the_geom,b.the_geom);

3. چارچوب برنامه

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

3.1. الزامات

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

کلاس انتزاعی ForR باید شامل متدهای انتزاعی زیر باشد که در کلاس های مشتق شده پیاده سازی خواهند شد:

روش Fi که تابع را پیاده سازی می کند Φشرح داده شده در بخش 2.2 ، که یک رابطه جهتی را به یک رابطه 5 تقاطع ترجمه می کند.
یک روش اول که می تواند بررسی کند که آیا یک رابطه جهت بین دو شی تأیید می شود یا خیر. احتمالاً، چندین رابطه نیز می تواند تأیید شود (به عنوان مثال، پشت:left_of ). به عنوان مثال، یک پرس و جو می تواند این شکل را داشته باشد: “آیا درخت در سمت چپ یا پشت ساختمان دانشگاه است؟”

بولی test_rel = fr_of_ref.relate (درخت، دانشگاه، بعد از:left_of)

از طرف دیگر، می‌توان رابطه را با یک الگوی باینری با استفاده از روش‌های مناسب patt2rel و rel2patt مشخص کرد، که ترجمه از یک رشته باینری به رابطه و بالعکس را تضمین می‌کند. مثلا:

boolean test_rel = fr_of_ref.relate (درخت، دانشگاه، "00011")
روش دوم Relate قادر به برگرداندن تمام اشیایی است که در رابطه ای با یک شی معین هستند. این تابع را می توان برای جستجوی اشیاء از یک فروشگاه داده استفاده کرد و آنها را فیلتر کرد تا رابطه بیان شده در پرس و جو را تأیید کنند.

برای هر نوع چارچوب مرجع، همه زیرگروه ها باید با کلاس های بتنی پیاده سازی شوند. به عنوان مثال، شکل 9 نمودار UML را برای چارچوب مرجع deictic-Allocentric نشان می دهد. fDآ. هر کلاسی که یک نوع فرعی را نشان می دهد ساختار یکسانی دارد که شامل ویژگی ها و متدهای زیر می شود:

زیرنوع چارچوب مرجع؛
یک شی هندسی ، که بسته به چارچوب مرجع، معنای متفاوتی دارد (اساساً شیء سوم از رابطه سه تایی که در رابطه دوتایی صریح نیست).
مجموعه ای از Rs از تمام روابط ممکن که می توان با چارچوب مرجع استفاده کرد. هر رابطه را می توان به طور کامل بر اساس یک الگو تعریف کرد: Rs آرایه ای از رشته های دو بعدی است که شامل نام رابطه و الگوی آن است. به عنوان مثال، برای چارچوب مرجع دیکتیک-آلوسنتریک، Rs به صورت زیر خواهد بود:
- Rs = رشته جدید [5][2];
- Rs[0] [0] = "10000"؛
- Rs[0] [1] = "جلو"؛
- Rs[1] [0] = "01000"؛
- Rs[1] [1] = "حق_از";
- Rs[3] [0] = "00010"؛
- Rs[3] [1] = "left_of";
- [4] [0] = "00001"؛
- Rs[4] [1] = "پشت";
توجه داشته باشید که در این چارچوب مرجع، یک رابطه از مدل 5 تقاطع (مرتبط با رابطه قبل (یا “00100”) استفاده نمی شود.
تابع تبدیل Fi، که برای چارچوب مرجع deictic-Allocentric با تابع مطابقت دارد ΦDآشرح داده شده در بخش 2.2 .
مجموعه ای از توابع بولی که می تواند روابط فردی تعریف شده در چارچوب مرجع را محاسبه کند. این روابط دودویی هستند، یعنی بین دو شی با دسترسی به نمایش هندسی آنها عمل می کنند. اجازه دهید مثال زیر را در نظر بگیریم: “آیا درخت در سمت چپ دانشگاه با توجه به دیدگاه یک ناظر است؟”. برای تأیید این نوع درخواست، تابعی که باید فراخوانی شود left_of است که متدی از کلاس ForR_Deictic_Allocentric است . فراخوانی این روش به صورت زیر است:

test_rel بولی = fr_of_ref.left_of(درخت، دانشگاه)

ما فرض می کنیم که اشیاء فضایی مورد استفاده در پرس و جوها متعلق به کلاس org.postgis.Geometry هستند که هندسه عمومی را نشان می دهد که طبق استاندارد OGC کلاس های دیگر مانند Point، Polygon و Polyline از آن به ارث می برند.

3.2. معماری چارچوب

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

3.2.1. لایه ارائه

لایه ارائه ارتباطات با نهادهای خارج از سیستم را مدیریت می کند. این لایه شامل تمام اجزایی است که با ارائه اطلاعات به مشتری سروکار دارد و امکان تعامل سطح بالا با کاربر را فراهم می کند. به عنوان یک لایه ارائه، پیاده‌سازی ما از چارچوب Openlayers استفاده می‌کند که یک کتابخانه جاوا اسکریپت برای نمایش نقشه‌ها در یک مرورگر وب است که تحت مجوز 2 بند BSD منتشر شده است. OpenLayers امکان ایجاد برنامه های GIS واقعی در وب را فراهم می کند. لایه ارائه از طریق یک وب سرویس با لایه منطق تجاری ارتباط برقرار می کند. خدمات وب بسیاری در استاندارد OGC برای تبادل اطلاعات مکانی وجود دارد. ما به ویژه به داده های برداری علاقه مند هستیم و بنابراین، وب سرویس مورد استفاده، سرویس ویژگی وب (WFS) است که امکان تبادل داده های برداری را در استاندارد OGC می دهد. اجازه دهید نحوه کار OpenLayers را عمیق تر کنیم:

var protocol = new OpenLayers.Protocol.WFS({
نسخه: "1.1.0"،
srsName: "EPSG:4326"،
آدرس اینترنتی: " http://localhost:8080/geoserver/wfs ",
featureType: "feature_name",
geometryName: "the_geom"
})

با کد بالا، OpenlLayers اجازه می دهد تا یک پروتکل WFS را اعلام کند که با آن می توان تمام درخواست ها را به سرور ارسال کرد. ویژگی‌های جدید را می‌توان ایجاد کرد، و موارد موجود را می‌توان بازیابی، به‌روزرسانی یا حذف کرد. پارامترهای کد بالا چندین جزئیات را مشخص می‌کنند، مانند نسخه پروتکل WFS، پیش‌بینی نقشه مورد استفاده ( srsName )، آدرس وب سرور ( url )، نوع اشیاء هندسی درخواست‌شده به سرور ( featureType )، و نام ویژگی هندسی ( geometryName). پس از ایجاد پروتکل، لازم است یک لایه برداری برای تجسم ویژگی های مورد نیاز ایجاد شود. لایه ها را می توان برای ارتباط دادن مجموعه داده های مختلف (مانند رودخانه ها و دریاچه ها) روی هم گذاشت. برای ایجاد یک لایه برداری می نویسیم:

var vecLayer =
new OpenLayers.Layer.Vector("Layer_name",{isBaseLayer: true});

علاوه بر تعیین نام لایه، پارامتر isBaseLayer برای نشان دادن اینکه لایه اصلی است یا خیر استفاده می شود. در مرحله بعد، لازم است لایه جدید ایجاد شده را به پروتکل WFS تعریف شده قبلی متصل کنید. در جاوا این با کد زیر مطابقت دارد:

var store = new GeoExt.data.FeatureStore({

لایه: vecLayer

فیلدها: [{نام: 'tipo'، نوع: 'string'}]،

پروکسی: new GeoExt.data.ProtocolProxy({

پروتکل: پروتکل

})

بارگذاری خودکار: درست است

})؛

به طور خاص، در آخرین قطعه کد، کتابخانه GeoExt را فراخوانی کردیم که شامل Openlayers کتابخانه است. پارامترهای مورد استفاده برای اتصال عبارتند از نام لایه برداری تعریف شده قبلی، ویژگی های اضافی ( فیلدها )، پروتکل WFS تعریف شده قبلی ( پراکسی )، و یک پارامتر Boolean که مشخص می کند داده ها باید به طور خودکار روی لایه بارگذاری شوند ( autoLoad ).

در Openlayers کاربر می تواند برخی از ویژگی های لایه برداری را انتخاب کرده و به سرور ارسال کند. انتخاب ویژگی ها از طریق رویدادها مدیریت می شود. از نظر فنی، این کار با عبارت زیر انجام می شود:

vecLayer.events.register("featureselected", vecLayer, onFeatureSelect);

مدیریت رویداد مستقیماً در لایه ایجاد شده فعال می شود. هنگامی که رویداد ویژگی‌های انتخاب شده رخ می‌دهد، تابع onFeatureSelect فراخوانی می‌شود. دومی وظیفه ارسال هندسه های انتخاب شده به سرور را از طریق یک درخواست AJAX (جاوا اسکریپت ناهمزمان و XML) انجام می دهد که دارای ساختار زیر است:

$ .ajax({

نوع: "پست"،

آدرس اینترنتی: " http://localhost:8080/pattern/App_Name "،

داده: داده،

//رویداد موفقیت

موفقیت: function(msg){

اگر (!bool){

Ext.getCmp('log').update('ویژگی های حاصل با رنگ قرمز نشان داده شده اند..');

var json = new OpenLayers.Format.JSON();

var res = json.read(msg);

کنترل کننده (res);

}دیگر{

Ext.getCmp('log').update('نتیجه رابطه: '+msg);

}

})؛

درخواست فوق از طریق Jquery ، یک چارچوب جاوا اسکریپت که قادر به مدیریت چندین ویژگی AJAX است، انجام می شود. پارامترهایی که می‌توانیم در درخواست ببینیم، نوع هستند که روی POST تنظیم شده است، زیرا ویژگی‌ها از لایه ارائه به سرور می‌روند (در غیر این صورت، نوع روی GET تنظیم می‌شود )، آدرس وب که درخواست باید به آن ارسال شود. فرستاده شده ( url )، داده هایی که باید به سرور ارسال شوند، و تابعی که در صورت تکمیل درخواست با موفقیت فراخوانی می شود. در تابع دوم، پارامتر msg نشان دهنده مقداری است که سرور در پاسخ به درخواست ارائه می دهد.

3.2.2. لایه منطق کسب و کار

لایه منطق تجاری منطق برنامه را مدیریت می کند. برای مثال، در چارچوب ما، این لایه باید هم درخواست WFS که از لایه ارائه می‌آید برای نمایش ویژگی‌های منطقه جغرافیایی انتخاب شده و هم درخواست AJAX که از لایه ارائه می‌آید را مدیریت کند تا کلاس‌های مناسب را نمونه‌سازی کند تا بتواند بتواند. برای استفاده از روابط جهتی مختلف

برای رسیدگی به درخواست WFS، به سرور WFS نیاز است. ما GeoServer، یک سرور سازگار با استاندارد OGC، چند پلتفرمی و نوشته شده در جاوا را انتخاب کردیم. GeoServer به یک کانتینر وب نیاز دارد که برای آن آپاچی تامکت را انتخاب کردیم. مرحله بعدی اتصال GeoServer به پایگاه داده فضایی یک منطقه جغرافیایی معین است. یک فروشگاه جدید باید با دسترسی به بخش فروشگاه های صفحه اصلی GeoServer ایجاد شود. در این مرحله باید منبعی برای فروشگاه مشخص شود، مانند ورودی پایگاه داده PostGIS در قسمت منابع داده برداری. برای اتصال، برخی از پارامترها (به عنوان مثال، میزبان، پورت، نام پایگاه داده) مورد نیاز است. پس از فروشگاه، یک لایه باید ایجاد شود که از طریق هر درخواست WFS قابل دسترسی باشد. شکل 11مرحله انتشار لایه را نشان می دهد. از جمله پارامترهایی که باید مشخص شوند عبارتند از نامی که باید به لایه اختصاص داده شود، سیستم مرجع مختصات مجموعه داده و مختصات حداقل مستطیل مرزی (MBR) که شامل تمام ویژگی های لایه است.

هنگامی که برخی از ویژگی های هندسی در لایه برداری مشتری انتخاب می شوند، داده های هندسی توسط لایه های باز به رشته هایی در قالب متن شناخته شده (WKT) تبدیل می شوند. سپس این رشته ها برای استفاده از آنها در محاسبه روابط جهت به سرور ارسال می شوند. خط زیر مثالی از نحوه بازیابی این داده ها از سرویس گیرنده در لایه منطق تجاری را نشان می دهد:

رشته aStr = request.getParameter("a");

هندسه ها به اشیایی از کلاس org.postgis.Geometry تبدیل می شوند. این را می توان به راحتی به دست آورد زیرا سازنده کلاس اجازه می دهد تا اشیاء را از یک رشته در قالب WKT نمونه سازی کند. به عنوان مثال، برای ایجاد یک چند ضلعی از رشته ایجاد شده قبلی a Str ، باید از عبارت زیر استفاده کنیم:

org.postgis.Polygon a = new org.postgis.Polygon(aStr);

سپس، لازم است کلاس را برای رابطه جهتی مورد نیاز نمونه سازی کنیم. با فرض اینکه کاربر چارچوب جغرافیایی مرجع را انتخاب کرده است و باید بررسی کند که آیا یک شی A در شمال شی B است، ابتدا باید چارچوب مرجع را با کد زیر نمونه سازی کنیم:

ForR_Extrinsic_geographic_conventional_north geo_fr =
جدید ForR_Extrinsic_geographic_conventional_north ("Test"، "Extrinsic"، "Geographic"، "conventional_north"، North.getNorth(cStr));

کلاس شیء را ایجاد می کند که چارچوب مرجع خارجی جغرافیایی را نشان می دهد، جایی که پارامترهای لازم مشخص می شوند: به طور جزئی آخرین پارامتر هندسه خط شمالی است که توسط تابع getNorth از کلاس North (یک کلاس کاربردی ساده) برگردانده می شود. برای محاسبه اینکه آیا رابطه جهتی بین A و B “شمال” است یا خیر، می توان از روش مربوط به روش زیر استفاده کرد:

Boolean ris = geo_fr.relate(a, b, North_of);

در عوض، اگر کاربر تمام اشیاء را در شمال یک شی انتخاب شده B درخواست کند، روشی که باید فراخوانی شود ، رابطه غیربولینی خواهد بود که مجموعه ای از اشیاء را برمی گرداند. تماس زیر استفاده خواهد شد:

ris = geo_fr.relate(list, b, North_of);

لیست پارامتر شامل تمام اشیاء در مجموعه داده است که رابطه درخواستی برای آنها تأیید شده است. سپس اشیاء به دست آمده در یک آرایه JSON قرار می گیرند که به مشتری بازگردانده می شود. از این رو، لیست پارامترها باید قادر به دسترسی به پایگاه داده فضایی باشد: کلاس جاوا مسئول در لایه داده قرار دارد.

3.2.3. لایه داده

لایه داده بخشی از معماری است که در واقع دسترسی به داده ها را انجام می دهد. در چارچوب برنامه ما، کلاس DbData است که این کار را با استفاده از متد static getDbData اجرا می کند . بنابراین، روش زیر می تواند درخواست را از لایه منطق تجاری دریافت کند، آن را به یک پرس و جوی SQL تبدیل کند، چنین پرس و جوی را به پایگاه داده فضایی ارسال کند، نتایج را استخراج کرده و به عنوان لیستی از فضایی به لایه منطق تجاری بازگرداند. اشیاء. از نظر فنی می توانیم کد این روش را به صورت زیر مشاهده کنیم:

Static Public ArrayList <org.postgis.Geometry> getDbData(string

حذف، رشته dbName، رشته tbName، کاربر رشته، پاس رشته) پرتاب می کند

ClassNotFoundException، SQLException{

Class.forName("org.postgresql.Driver");

آدرس رشته = "jdbc:postgresql://host:5432/"+dbName;

اتصال اتصال = DriverManager.getConnection(url, user, pass);

PreparedStatement ps = conn.prepareStatement("انتخاب the_geom

از \""+tbName+"\" جایی که the_geom در آن نیست (انتخاب کنید

ST_GeomFromText(?,4326))");

ps.setString(1,exclude);

ResultSet res = ps.executeQuery();

ArrayList<org.postgis.Geometry> list=

new ArrayList<org.postgis.Geometry>();

while (res.next()) {

PGgeometry geometry = (PGgeometry)res.getObject(1);

list.add(geometry.getGeometry());

}

ps.close();

conn.close();

لیست بازگشت؛}

اولین وظیفه روش فوق ثبت درایور مورد نیاز برای اتصال به پایگاه داده با Class.forName است . در این مرحله DriverManager از این درایور آگاه خواهد شد. پارامتر url محل قرار گرفتن پایگاه داده را مشخص می کند. پس از آن، اتصال را می توان با روش DriverManager.getConnection ایجاد کرد ، که سه پارامتر به آن منتقل می شود: url ، کاربر ، و رمز عبور برای اعتبار ورود به سیستم. بلافاصله پس از آن، یک بیانیه آمادهاجازه می دهد تا دستورات SQL را با یک یا چند پارامتر ارسال کنید. به این ترتیب می توان یک دستور SQL را چندین بار با مقادیر مختلف فراخوانی کرد که در آن پارامترها با علامت سوال نشان داده می شوند. سپس پرس و جو توسط متد executeQuery پردازش شده و در ResultSet res درج می شود . در نهایت، از طریق حلقه while، تمام نتایج پرس و جو در لیست آرایه ای قرار می گیرند که پس از بسته شدن اتصال برگردانده می شود.

4. ارزیابی چارچوب کاربردی

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

جغرافیای بولین : با این درخواست می توان بررسی کرد که آیا خانه ای در شمال، جنوب، غرب، شرق خانه دیگری قرار دارد یا خیر. نتیجه یک مقدار بولی است.
مجموعه جغرافیایی : تمام خانه هایی را که در شمال، جنوب، غرب، شرق یک خانه معین قرار دارند را مشخص می کند. نتیجه مجموعه ای از اشیاء است.
هندسی Boolean : با فعال کردن فیلتر می توان ساختمان هایی را که قسمت جلو و عقب بر روی آنها تعریف شده است، تجسم کرد. از این رو، می توان فهمید که ساختمانی در جلو ، راست ، چپ یا پشت ساختمان دیگر قرار دارد. داده برگشتی یک مقدار بولی است.
مجموعه هندسی : امکان شناسایی تمام ساختمان هایی که در جلو ، راست ، چپ و پشت ساختمان دیگری هستند را می دهد.
دیکتیک بولی : بر اساس موقعیت یک فرد، می توان بررسی کرد که خانه ای در سمت چپ ، راست ، جلو یا پشت خانه دیگر با توجه به دیدگاه در نظر گرفته شده است.
Collection Deictic : مانند deictic Boolean، اما تمام خانه هایی را که ویژگی ها را برآورده می کنند، بازیابی می کند.

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

4.1. چارچوب مرجع جغرافیایی

در چارچوب جغرافیایی مرجع، با انتخاب یک ساختمان، می توان یک رابطه جهتی را مشخص کرد و تمام ساختمان هایی را که در جهت معین هستند نسبت به ساختمان انتخاب شده برگرداند. شکل 13 نمونه ای را نشان می دهد که در آن رابطه North_of بررسی شده است و سپس عملیات با دکمه Find در پایین تایید شده است. امکان انتخاب روابط جهتی متعدد نیز وجود دارد. اگر هندسه دومی انتخاب شود، با یافتن رابطه بولی بین دو ساختمان انتخاب شده مطابقت دارد ( شکل 14 ).

4.2. چارچوب هندسی مرجع

چارچوب هندسی مرجع متکی بر شناسایی ویژگی های ذاتی شی مرجع است. در مورد ساختمان ها، چنین ویژگی هایی معمولاً با قسمت جلو و عقب نشان داده می شوند. در مطالعه موردی توسعه یافته در اینجا، تنها چند ساختمان دارای این سطح از جزئیات هستند. روی نقشه، فیلتری وجود دارد که امکان نمایش این ساختمان های خاص را فراهم می کند ( شکل 15 ).

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

4.3. قاب مرجع دیکتیک

در این چارچوب به کاربر این امکان داده می شود که موقعیت خود را تعیین کند. برای این منظور از یک دکمه خاص Location استفاده می شود. هنگامی که موقعیت کاربر انتخاب می شود، چارچوب مرجع به deictic تغییر می کند ( شکل 17 ). به عنوان مثال، فرض کنید که کاربر باید تمام ساختمان هایی را که بین موقعیت او و یک ساختمان معین قرار دارند انتخاب کند. کاربر باید ساختمان دوم را انتخاب کند، جبهه رابطه را انتخاب کند و روی Find کلیک کند . در شکل 18 ، نتیجه نشان داده شده است.

5. تست های کاربر از Application Framework

در این بخش، استفاده از چارچوب کاربردی را برای آزمایش کفایت شناختی روابط جهتی و چارچوب های مرجع معرفی شده در [ 21 ] تشریح می کنیم. مطالعه کاربر کاملتر موضوع تحقیقات آینده خواهد بود.

5.1. آماده سازی آزمون

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

شکل 19 a اولین نقشه ای را نشان می دهد که شرکت کنندگان برای پاسخ به دو سوال اول بررسی کردند. نقشه به چارچوب مرجع بیرونی زیرمجموعه جغرافیایی اشاره داشت و سؤالات به منظور رنگ آمیزی تمام ساختمان هایی بود که به ترتیب در شمال ساختمان برجسته و غرب آن قرار دارند. سؤالات سوم و چهارم مربوط به چهارچوب مرجع دیکتیک بود و بر اساس شکل 19 ب. در سوال اول، کاربر باید تمام ساختمان هایی را که بین موقعیت خود و ساختمان هایلایت شده قرار گرفته اند رنگ آمیزی کند. در سوال دوم از کاربر خواسته شد که تمام ساختمان های واقع در سمت راست ساختمان برجسته شده را از نظر موقعیت کاربر رنگ آمیزی کند. سوال پنجم و ششم مربوط به چارچوب مرجع ذاتی هندسی است. شکل 19c سناریویی را که برای آزمایش به کاربران داده می شود نشان می دهد. از شرکت کنندگان خواسته شد که تمام ساختمان های روبروی ساختمان برجسته شده را رنگ آمیزی کنند و در آخرین سوال، تمام ساختمان های سمت راست ساختمان برجسته را رنگ آمیزی کنند.

5.2. نتایج آزمون

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

نتایج برنامه به طور مثبت ایده ای را که کاربران از رابطه North_of دارند منعکس می کند . با این حال، برخی از ساختمان ها هستند که کاربران در نظر نگرفته اند و در گوشه سمت راست بالای شکل 20 الف قرار دارند. این را می توان با این واقعیت توضیح داد که برنامه همچنین ساختمان هایی را که فقط تا حدی در شمال واقع شده اند، اما می توانند تا حدی شرقی یا غربی نیز باشند، برمی گرداند. سوال دوم آزمون در مورد رابطه west_of در همان محیط بود. مقایسه در شکل 21 نشان داده شده است. حتی در این مورد، این دو نتیجه بسیار به یکدیگر نزدیک‌تر هستند: می‌توانیم متوجه تمایل کاربران به انتخاب روابط «دقیق‌تر»، دور انداختن ساختمان‌هایی که در جهت‌های میانی هستند، باشیم. سوال سوم مربوط به چارچوب ارجاعی است. مقایسه نتایج با پرس و جوی برنامه در شکل 22 نشان داده شده است . جالب است بدانید که در این شرایط، کاربران نسبت به درج برخی از ساختمان‌ها به سمت چپ، حتی با درصدهای پایین‌تر، سهل‌تر بودند. سوال چهارم همچنان به چارچوب مرجع در مورد رابطه right_of می پردازد . نتایج در شکل 23 مقایسه شده است. در این مورد، ما تطابق خوبی بین آزمون های برنامه و کاربر به دست آوردیم، زیرا تمام نتایج برنامه حداقل توسط یک سوم کاربران انتخاب شده است.

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

6. نتیجه گیری

روابط جهتی را می توان در هر زمینه مرتبط با داده های مکانی، از پایگاه های داده مکانی گرفته تا سیستم های ناوبری [ 26 ، 27 ] یا داده های جمع سپاری [ 28 ، 29 ] اعمال کرد. علیرغم اهمیت روابط جهت دار، استانداردهای جغرافیایی آنها را در میان مجموعه روابط فضایی موجود نمی گنجاند. شاید بتوان این فقدان را به این دلیل توضیح داد که نظریه پشت روابط جهت دار کاملاً پراکنده است و اجماع کمی در مورد تعریف و مدل های آنها ظاهر می شود. پیچیدگی بیشتری با این واقعیت اضافه می شود که روابط جهت دار باید در چارچوب یک چارچوب مرجع قرار گیرد تا ابهام زدایی شود و تعداد زیادی چارچوب مرجع متفاوت قابل تصور باشد. روابط فرافکنی [ 24] را می توان به عنوان مبنای محاسباتی برای روابط جهتی در نظر گرفت: در [ 21 ]، نگاشت بین روابط تصویری و چندین چارچوب مرجع مفید پیشنهاد شده است. به همین ترتیب، مجموعه‌ای از روابط جهت‌دار برای هر چارچوب مرجع پیشنهاد می‌شود.

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

منابع

Egenhofer، MJ; Herring, JR طبقه‌بندی روابط توپولوژیکی دوتایی بین مناطق، خطوط و نقاط در پایگاه‌های اطلاعات جغرافیایی . گزارش فنی؛ گروه مهندسی نقشه برداری، دانشگاه مین: Orono، ME، ایالات متحده آمریکا، 1990; پ. 28. [ Google Scholar ]
کلمنتینی، ای. Cohn، AG RCC*-9 و CBM*. در علم اطلاعات جغرافیایی، مجموعه مقالات هشتمین کنفرانس بین المللی، GIScience 2014، وین، اتریش، 24–26 سپتامبر 2014 ; داکهام، ام.، پبسما، ای.، استوارت، ک.، فرانک، AU، ویرایش. Springer: برلین، آلمان، 2014; جلد LNCS 8728، صفحات 349-365. [ Google Scholar ]
تارکینی، اف. کلمنتینی، E. روابط فضایی بین طبقات به عنوان محدودیت های یکپارچگی. ترانس. GIS 2008 ، 12 ، 45-57. [ Google Scholar ] [ CrossRef ]
کلمنتینی، ای. امپدانس هستی‌شناختی در مدل‌سازی داده‌های معنایی سه بعدی. در آرشیو بین المللی فتوگرامتری، سنجش از دور و علوم اطلاعات فضایی XXXVIII-4، قسمت W15، مجموعه مقالات ISPRS: پنجمین کنفرانس اطلاعات جغرافیایی سه بعدی، برلین، آلمان، 3–4 نوامبر 2010 . Kolbe, TH, König, G., Nagel, C., Eds.; Shaker Verlag GmbH: آخن، آلمان، 2010; صص 97-100. [ Google Scholar ]
بوچر، بی. فالکت، جی. کلمنتینی، ای. Sester, M. Towards a typeology of spatial روابط و خواص برای کاربردهای شهری. در 3u3d2012: Usage, Usability, and Utility of 3D City Models, Proceedings of the European Cost Action TU801 Final Conference, Nantes, France, 29–31 اکتبر 2012 . EDP Sciences: Les Ulis، فرانسه، 2012. [ Google Scholar ]
بیلن، آر. کلمنتینی، ای. معرفی یک سیستم استدلال مبتنی بر روابط تصویری سه تایی. در تحولات مدیریت داده‌های مکانی، یازدهمین سمپوزیوم بین‌المللی مدیریت داده‌های مکانی ؛ فیشر، پی، اد. Springer: برلین، آلمان، 2005; صص 381-394. [ Google Scholar ]
بیلن، آر. کلمنتینی، ای. معناشناسی هم خطی بین مناطق. در حرکت به سوی سیستم های اینترنتی معنادار 2005: کارگاه های OTM، مجموعه مقالات اولین کارگاه بین المللی در مورد سیستم های اطلاعات جغرافیایی مبتنی بر معنایی (SeBGIS’05)، آگیا ناپا، قبرس، 31 اکتبر تا 4 نوامبر 2005 . Meersman, R., Tari, Z., Herrero, P., Eds. Springer: برلین، آلمان، 2005; جلد 3762، ص 1066–1076. [ Google Scholar ]
بیلن، آر. کلمنتینی، ای. روابط فرافکنی در یک محیط سه بعدی. در علم اطلاعات جغرافیایی، مجموعه مقالات چهارمین کنفرانس بین المللی، GIScience 2006، مونستر، آلمان، 20-23 سپتامبر 2006 ; Raubal, M., Miller, H., Frank, A., Goodchild, M., Eds. Springer: برلین، آلمان، 2006; جلد 4197، ص 18–32. [ Google Scholar ]
کلمنتینی، ای. روابط فرافکنی در کره. In Advances in Conceptual Modeling — Challenges and Opportunities — ER 2008 Workshops, Proceedings of the 2nd International Workshop on Semantic and Conceptual Issues in GIS (SeCoGIS 2008), Barcelona, Spain, 20-23 اکتبر ; آهنگ، I.-Y.، Ed. Springer: برلین/هایدلبرگ، آلمان، 2008; جلد 5232، صص 313–322. [ Google Scholar ]
بارتی، پی. کلمنتینی، ای. Reitsma, F. مدلی کیفی برای توصیف آرایش اشیاء نمای شهری مرئی از دیدگاه خود محوری. محاسبه کنید. محیط زیست سیستم شهری 2013 ، 38 ، 21-34. [ Google Scholar ] [ CrossRef ]
فوگلیارونی، پ. کلمنتینی، ای. مدلسازی رویت در فضای سه بعدی: یک چارچوب مرجع کیفی. در 3D Geoinfoation Science: The Selected Papers of the 3D GeoInfo 2014 ; Breunig, M., Al-Doori, M., Butwilowski, E., Kuper, PV, Benner, J., Haefele, KH, Eds. Springer: برلین، آلمان، 2015; جلد LNG&C، صفحات 243-258. [ Google Scholar ]
بارتی، پی. رایتسما، اف. کلمنتینی، ای. کینگهام، اس. عبارات ارجاع در خدمات مبتنی بر مکان: مورد رابطه “مخالف”. در پیشرفت در مدل سازی مفهومی. پیشرفت‌های اخیر و جهت‌گیری‌های جدید – کارگاه‌های آموزشی ER 2011، مجموعه مقالات پنجمین کارگاه بین‌المللی درباره مسائل معنایی و مفهومی در GIS (SeCoGIS 2011)، بروکسل، بلژیک، 1 نوامبر 2011 ؛ De Troyer, O., Bauzer Medeiros, C., Billen, R., Hallot, P., Simitsis, A., Van Mingroot, H., Eds. Springer: برلین/هایدلبرگ، آلمان، 2011; جلد LNCS 6999، صفحات 231-240. [ Google Scholar ]
لیو، ایکس. شکر، س. Chawla، S. پردازش پرس و جو جهت دار مبتنی بر شی در پایگاه داده های فضایی. IEEE Trans. بدانید. مهندسی داده 2003 ، 15 ، 295-304. [ Google Scholar ] [ نسخه سبز ]
وربویز، م. داکهام، ام. کولیک، ال. مفاهیم مجاورت و جهت در فضای محیطی. تف کردن شناخت. محاسبه کنید. 2004 ، 4 ، 285-312. [ Google Scholar ] [ CrossRef ]
فرانک، الف. استدلال فضایی کیفی در مورد جهت گیری های اصلی. در مجموعه مقالات دهمین سمپوزیوم بین المللی کارتوگرافی به کمک کامپیوتر (AUTO CARTO 10)، بالتیمور، MD، ایالات متحده آمریکا، 25-28 مارس 1991; صص 148-167. [ Google Scholar ]
گویال، ر. Egenhofer، MJ ماتریس جهت-رابطه: نمایشی از روابط جهت برای اجسام فضایی گسترده. در مجموعه مقالات مجمع سالانه UCGIS و نشست تابستانی، بار هاربر، ME، ایالات متحده آمریکا، 15 تا 21 ژوئن 1997. [ Google Scholar ]
کولیک، ال. کلیپل، الف. استدلال در مورد جهت های اصلی با استفاده از شبکه ها به عنوان مختصات جغرافیایی کیفی. در نظریه اطلاعات فضایی: مبانی شناختی و محاسباتی علم اطلاعات جغرافیایی، مجموعه مقالات کنفرانس بین المللی COSIT’99، 25-29 اوت 1999، Stade، آلمان . Freksa, C., Mark, DM, Eds. Springer: برلین، آلمان، 1999; جلد 1661، ص 205–220. [ Google Scholar ]
لوینسون، SC چارچوب های مرجع و سوال مولینوکس: شواهد متقابل زبانی. در زبان و فضا ; بلوم، پی، پترسون، MA، نادل، ال.، گرت، MF، ویرایش. انتشارات MIT: کمبریج، MA، ایالات متحده آمریکا، 1996; صص 109-169. [ Google Scholar ]
Retz-Schmidt, G. دیدگاه های مختلف در مورد حروف اضافه فضایی. AI Mag. 1988 ، 9 ، 95-105. [ Google Scholar ]
فرانک، مدل‌های رسمی AU برای شناخت – طبقه‌بندی توصیف مکان فضایی و چارچوب‌های مرجع. در شناخت فضایی: رویکردی میان رشته ای برای بازنمایی و پردازش دانش فضایی . Freksa, C., Habel, C., Wender, KF, Eds. Springer: برلین، آلمان، 1998; جلد 1404، ص 293–312. [ Google Scholar ]
کلمنتینی، ای. روابط جهتی و چارچوب های مرجع. GeoInformatica 2013 ، 17 ، 235-255. [ Google Scholar ] [ CrossRef ]
هوآ، اچ. رنز، جی. Ge, X. بازنمایی کیفی و استدلال بر روابط جهت در چارچوب های مختلف مرجع. در اصول بازنمایی و استدلال دانش، مجموعه مقالات شانزدهمین کنفرانس بین المللی، KR 2018، Tempe، AZ، ایالات متحده آمریکا، 30 اکتبر–2 Vovember 2018 . مطبوعات AAAI: پالو آلتو، کالیفرنیا، ایالات متحده آمریکا، 2018؛ صص 551-560. [ Google Scholar ]
شیدر، اس. هان، جی. ویزر، پی. کوهن، دبلیو. محاسبات با چارچوب های مرجع فضایی شناختی در GIS. ترانس. GIS 2018 ، 22 ، 1083-1104. [ Google Scholar ] [ CrossRef ]
کلمنتینی، ای. بیلن، آر. مدل سازی و محاسبه روابط تصویری سه تایی بین مناطق. IEEE Trans. بدانید. مهندسی داده 2006 ، 18 ، 799-814. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
کلمنتینی، ای. بیلن، آر. روابط فرافکنی. در دایره المعارف GIS ، ویرایش دوم. Shekhar, S., Xiong, H., Zhou, X., Eds. Springer International Publishing: New York, NY, USA, 2016; صص 1-10. [ Google Scholar ]
مرتاری، ف. زلاتانوا، اس. لیو، ال. کلمنتینی، ای. “مدل شبکه هندسی بهبودیافته” (IGNM): یک رویکرد جدید برای استخراج نمودارهای اتصال برای ناوبری داخلی. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2014 ، II-4 ، 45-51. [ Google Scholar ] [ CrossRef ]
روسو، دی. زلاتانوا، اس. کلمنتینی، E. مسیرهای تولید مسیر با استفاده از نشانه های قابل مشاهده. در مجموعه مقالات ششمین کارگاه بین المللی ACM SIGSpatial در مورد آگاهی فضایی داخلی (ISA 2014)، تامپا، FL، ایالات متحده آمریکا، 8 تا 12 سپتامبر 2014. Claraunt, C., Li, K.-J., Zlatanova, S., Eds. ACM: نیویورک، نیویورک، ایالات متحده آمریکا، 2014; صص 1-8. [ Google Scholar ]
فوگلیارونی، پ. D’Antonio، F. کلمنتینی، ای. قابل اعتماد بودن داده ها و شهرت کاربر به عنوان شاخص های کیفیت VGI. ژئو اسپات. Inf. علمی 2018 ، 21 ، 213-233. [ Google Scholar ] [ CrossRef ]
مارتلا، آر. کری، سی. کلمنتینی، ای. چارچوب بازی سازی برای اطلاعات جغرافیایی داوطلبانه. در AGILE 2015 — علم اطلاعات جغرافیایی به عنوان توانمندساز شهرها و جوامع هوشمندتر ؛ Bacão, F., Santos, MY, Painho, M., Eds. Springer: برلین، آلمان، 2015; حجم یادداشت های سخنرانی در اطلاعات جغرافیایی و کارتوگرافی. صص 73-89. [ Google Scholar ]