نقشه راه GIS

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

09120049370

8 صبح تا 12 شب

09120049370

Telegram Whatsapp Youtube
کاربرد جی ای اس

 

چکیده

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

تحقیق ; وندالیسم ؛ تشخیص ; OpenStreetMap ; اطلاعات جغرافیایی داوطلبانه (VGI)

 

 

1. مقدمه

محتوای تولید شده توسط کاربر (UGC) [ 1 ] یک پدیده شناخته شده جنبش وب 2.0 است. با در دسترس بودن همه جا دستگاه های مجهز به GPS، مانند گوشی های هوشمند، دوربین ها یا تبلت ها، کاربران نه تنها UGC را جمع آوری کردند، بلکه شروع به ارجاع جغرافیایی اطلاعات جمع آوری شده خود کردند. این روند جدید تحت عنوان “اطلاعات جغرافیایی داوطلبانه” (VGI) [ 2 ] یا داده های جغرافیایی با منبع جمعی [ 3 ] رایج شد. آماتورها و حرفه ای ها به طور مشترک داده های جغرافیایی را برای پلتفرم های خاص VGI جمع آوری، به اشتراک می گذارند و بهبود می بخشند. اساساً، همه می‌توانند و اجازه دارند از VGI موجود برای برنامه‌ها و خدمات خود بدون پرداخت هزینه استفاده کنند.
یکی از محبوب ترین و متنوع ترین پروژه ها برای VGI، پروژه OpenStreetMap (OSM) است [ 4 ، 5 ، 6 ]. این پروژه در ابتدا با هدف ایجاد یک نقشه وب جهانی، به زودی بسیار فراتر از آن تبدیل شد. امروزه OSM را می توان به عنوان یک پایگاه داده جغرافیایی جهانی در نظر گرفت که همه می توانند به آن دسترسی داشته باشند، ویرایش کنند و از آن استفاده کنند. یک جامعه به سرعت در حال رشد و تقاضای در حال ظهور برای داده های جغرافیایی باز، OSM را به یکی از پرکاربردترین نقشه های آنلاین غیر اختصاصی و منبعی از داده های جغرافیایی و اطلاعات برای بسیاری از برنامه های شخص ثالث، مانند برنامه ریزی مسیر و کدگذاری جغرافیایی [ 7 ]، 3 بعدی [ 8 ] تبدیل کرد. ] یا داخلی [ 5] برنامه های کاربردی. اگرچه کاربران OSM باید قبل از مشارکت ثبت نام کنند، مدل OSM تحت یک رویکرد دسترسی آزاد طراحی شده است. با این حال، اگرچه این رویکرد باز را می‌توان کلید موفقیت OSM در نظر گرفت، اما می‌تواند منبع مشکلات مختلفی نیز باشد. در حالی که بیشتر مشارکت‌ها مشروع هستند، برخی از حملات توسط لابی‌گران یا ارسال‌کنندگان هرزنامه منجر به خرابکاری می‌شود. یکی از محبوب‌ترین نمونه‌های خرابکاری در OSM موردی است که دو کارمند یک موتور جستجوی محبوب ویژگی‌های OSM را در منطقه لندن حذف کردند [ 9 ]. با این حال، هنوز تحقیقات کلی در مورد تأثیر و کمیت خرابکاری در OSM صورت نگرفته است، و هیچ کارگروه مشخصی برای مقابله با خرابکاری تاکنون در OSM اجرا نشده است ( به «گروه وظیفه تخریب ظریف ویکی‌پدیا» مراجعه کنید.10 ]). هنگامی که با “اختلافات جدی و خرابکاری” [ 11 ] مواجه شد، می توان با “گروه کاری داده” OSM تماس گرفت . با این حال، “حوادث جزئی خرابکاری باید توسط جامعه محلی رسیدگی شود” [ 11 ].
با این وجود، به دنبال ایده دانش جمعی، فرض بر این است که خرابکاری توسط سایر مشارکت کنندگان OSM در یک دوره زمانی (ناشناخته) شناسایی و تصحیح می شود. در مورد OSM، وندالیسم می تواند عمدی و غیرعمدی رخ دهد، که با تعریف سنتی اصطلاح “وندالیسم” در تضاد است. با این حال، این به شدت به خود تغییر بستگی دارد (تخریب یک هندسه احتمالا واضح تر از خرابکاری اطلاعات معنایی است)، و همچنین به منطقه ای که ویرایش در آن انجام شده است، به عنوان مثال، خرابکاری در یک منطقه شهری احتمالاً شناسایی و اصلاح خواهد شد. بسیار سریع، در حالی که خرابکاری در یک منطقه بسیار روستایی به طور بالقوه برای مدت زمان بسیار طولانی باقی خواهد ماند.
به طور کلی، اعتبار سنجی داده ها و تشخیص خرابکاری باید از یکدیگر متمایز شوند. در حالی که اعتبار سنجی داده ها متدولوژی های مختلفی را برای تضمین کیفیت ترکیب می کند، خرابکاری بر فسادهای فعال داده ها تمرکز دارد. در این مقاله، ما بر روی مورد دوم تمرکز خواهیم کرد. اگرچه روش های خودکار برای تشخیص خرابکاری در OSM باید هم برای مشارکت کنندگان و هم برای مصرف کنندگان پروژه مورد توجه قرار گیرد، تنها چند ابزار یا پیشرفت های مهم دیگر در این زمینه در سال های اخیر انجام شده است. در زمان نوشتن، تنها دو ابزار در دسترس هستند که می توانند یک منطقه از پیش تعریف شده مورد علاقه را مشاهده کنند. ابزارها عبارتند از “OpenWatchList” [ 12 ]، که تحت استانداردهای منبع باز توسعه یافته است، و “OSM Mapper” توسعه یافته توسط ITO [ 13 ].]. هر دو ابزار امکان ثبت نام در فید RSS را فراهم می کنند که اطلاعاتی در مورد آخرین تغییرات در یک منطقه مشخص ارائه می دهد. کارکرد ابزارها را می توان با فهرست های به اصطلاح تماشا در ویکی پدیا مقایسه کرد که ویرایش های انجام شده در مقالات انتخابی را دنبال می کنند [ 14 ]. بسیاری از شباهت‌های دیگر بین OSM و Wikis وجود دارد که امروزه در اینترنت گسترده شده‌اند، مانند اتکا به «اعتماد رادیکال» [ 15 ] و شهروندانی که به «منابع داده‌ها» تبدیل می‌شوند [ 14 ].]. وجه مشترک همه این ابزارها این است که به جای ارزیابی ویرایش مربوطه و برجسته کردن موارد بالقوه خرابکاری، کاربران ثبت نام شده را در مورد هر ویرایش در یک منطقه از پیش تعریف شده مطلع می کنند. یعنی کاربر هنوز باید (به صورت دستی) تک تک ویرایش ها را بررسی کند که تلاش بسیار زمان بر و خسته کننده ای است. با این وجود، تشخیص خرابکاری در OSM نقش مهمی ایفا می‌کند و به دلیل محبوبیت فزاینده پروژه، که به شدت به کیفیت داده‌های آن بستگی دارد، اهمیت بیشتری پیدا می‌کند [ 4 ، 16 ].
در مورد ویکی‌پدیا، چند رویکرد در دسترس است که بر خرابکاری متمرکز است ( ر.ک. [ 17 ، 18 ، 19 ، 20 ]). همانطور که توسط ون دن برگ و همکاران ذکر شده است. [ 14 ]، استفاده از رویکردها، روش‌ها و فناوری‌های مشابه، که قبلاً در سایر پروژه‌های منبع باز و دایره‌المعارف‌های وب 2.0 مورد استفاده قرار گرفته‌اند، می‌تواند برای شناسایی خرابکاری در OSM و/یا بازگرداندن تغییرات غیرسازنده مفید باشد.
بنابراین، سهم اصلی این مقاله بررسی خرابکاری در OSM، و همچنین توسعه یک سیستم مبتنی بر قانون برای تشخیص خودکار خرابکاری در OSM است. مجموعه ای جامع از قوانین با بررسی حوادث خرابکاری گذشته، پایگاه داده فعلی OSM و مشارکت های آن، و همچنین ابزارهای مربوط به شناسایی خرابکاری ویکی پدیا تعریف شده است. سیستم ما شهرت فردی کاربر و همچنین اقدام انجام شده را در بر می گیرد. هر دو پارامتر مستقل از یکدیگر ارزیابی می شوند، که اجازه می دهد تا یک تعریف جداگانه از وزن برای هر دو پارامتر پس از تشخیص مربوطه انجام شود. اساساً، این امکان را به اعضای اختصاصی OSM (گشت‌گان) می‌دهد تا وزن‌های مناسب را به‌صورت جداگانه تعریف کنند، زیرا گشت‌های فردی احتمالاً اهمیت شهرت کاربر را متفاوت ارزیابی می‌کنند. به طور مشخص، خود تغییر جزء بسیار مهمی است که نیاز به بررسی دارد. بنابراین، این تغییر بر اساس معیارهای شناخته شده جامعه، مانند ویژگی های ارائه شده، یا ویژگی های نقشه پذیرفته شده توسط جامعه و موارد دیگر آزمایش می شود. گنجاندن شهرت کاربر عامل مهم دیگری است، زیرا تحقیقات در مورد خرابکاری برای سایر پروژه های وب 2.0 (به عنوان مثال ، ویکی‌پدیا) نشان داد که در بیشتر موارد، خرابکاری توسط اعضای جدید جامعه (احتمالاً بی‌تجربه) به جای اعضای با تجربه‌تر جامعه انجام می‌شود [ 21 ]. معماری سیستم توسعه‌یافته به‌طور نمونه اولیه پیاده‌سازی شده و به یک پایگاه داده OSM به‌روزرسانی شده اضافه شده است. به این ترتیب، امکان اعمال برخی از نتایج اولیه اولیه برای اصلاح قوانین پایه تعریف شده و بهبود بیشتر تشخیص خودکار خرابکاری وجود داشت.
ساختار باقی مانده این مقاله به شرح زیر است: بخش زیر یک مقدمه کلی از پروژه OSM ارائه می دهد، در حالی که بخش سوم مقاله انواع مختلف خرابکاری را که می تواند در OSM رخ دهد، توصیف می کند. بخش‌های چهار و پنج سیستم مبتنی بر قوانین توسعه‌یافته و نتایجی را که پس از اعمال روش‌شناسی ما جمع‌آوری شده‌اند، توصیف می‌کنند. بخش آخر یافته های ما را مورد بحث قرار می دهد و پیشنهادهایی برای کار و تحقیقات آینده ارائه می دهد.

2. OpenStreetMap

پروژه OSM که در سال 2004 در دانشگاه کالج لندن تأسیس شد، ایجاد یک پایگاه داده رایگان با اطلاعات جغرافیایی برای کل جهان است. طیف وسیعی از انواع مختلف داده‌ها و ویژگی‌های مکانی، مانند جاده‌ها، ساختمان‌ها، مناطق کاربری زمین یا نقاط مورد علاقه (POI)، در پایگاه داده جمع‌آوری می‌شوند. با پیروی از رویکرد Web 2.0 ایجاد مشترک داده های انبوه، هر کاربری می تواند پس از یک ثبت نام آنلاین کوتاه، مشارکت در پروژه را آغاز کند. اساساً، هر کاربر ثبت نام شده می تواند عناصر جدیدی را اضافه کند، و همچنین عناصر موجود را تغییر یا حذف کند. این رویکرد ساده – مشابه ویکی‌پدیا – تا اوت 2012 به بیش از 700000 عضو منجر شد [ 22 ]]. در مجموع، تقریباً 200000 عضو حداقل یک ویرایش را انجام دادند و تقریباً 3٪ از همه اعضا حداقل یک تغییر در هر ماه در پایگاه داده تا پایان سال 2011 انجام دادند [ 23 ]، یعنی آنهایی که می توانند به عنوان مشارکت کنندگان عادی در نظر گرفته شوند.
چندین مطالعه تحقیقاتی مختلف در مورد کیفیت و کامل بودن داده های OSM در مقایسه با سایر منابع داده (به عنوان مثال، دولتی یا تجاری) در سال های اخیر منتشر شده است (به عنوان مثال، [ 4 ، 24 ، 25 ، 26 ، 27 ]). در اروپا، OSM سطح مناسبی از پوشش داده را برای مناطق شهری نشان می‌دهد، که امکان توسعه و توزیع خدمات نقشه یا سایر برنامه‌ها، مانند سرویس مبتنی بر مکان (LBS) را فراهم می‌کند. با این حال، مناطق کمتر پرجمعیت سطح کاملی یکسانی را در OSM نشان نمی دهند، که باعث می شود مجموعه داده در آن مناطق غیرقابل اعتماد باشد. بنابراین، داده‌های OSM می‌توانند بسیار وابسته به موارد استفاده باشند، و الزامات باید به دقت در نظر گرفته شوند [ 28 ].
همانطور که در بالا گفته شد، هر عضو جامعه می تواند پایگاه داده OSM فعلی را تغییر دهد. با این حال تغییرات ناشناس پشتیبانی نمی شوند [ 4 ]. این یک تفاوت اساسی بین ویکی‌پدیا و OSM است و حداقل یک مزیت کوچک به همراه دارد: «کاربران OSM با نام کاربری‌شان شناسایی می‌شوند که می‌توان آن‌ها را مسدود کرد. در ویکی‌پدیا، کاربران با نام کاربری یا آدرس IP شناسایی می‌شوند و بیش از یک کاربر ممکن است از همان آدرس IP استفاده کنند.» [ 14 ]. با این حال، پس از آپلود داده ها در جامعه، تغییر بلافاصله به صورت زنده انجام می شود، یعنی در سیستم تولیدی اعمال می شود. اساساً، برخلاف Google MapMaker [ 29 ]، هیچ کنترل کیفیت یا خرابکاری قبل از انتشار وجود ندارد.]، که در آن کاربران با تجربه محتوای ارسال شده جدید را بررسی می کنند. افکار عمومی در مورد نحوه واکنش یک کاربر OSM در صورت شناسایی داده های خرابکاری شده در پروژه را می توان در صفحه وب خرابکاری در OSM Wiki یافت [ 30 ].
کاربران ثبت نام شده می توانند داده ها را به روش های مختلف به OSM کمک کنند. روش کلاسیک جمع آوری داده ها با یک گیرنده GPS است که پس از آن می توان آن را با یکی از ویرایشگرهای مختلف رایگان در دسترس مانند Potlatch یا JOSM ویرایش کرد. از نوامبر 2010، کاربران صراحتاً مجاز به ردیابی داده ها از تصاویر هوایی Bing و اضافه کردن داده ها به OSM هستند [ 31]. این به کاربر امکان می‌دهد بدون حضور فیزیکی در یک مکان مشخص، اطلاعات را جمع‌آوری کند (بنابراین کاربر آلمانی می‌تواند اطلاعات مربوط به شهری در فرانسه را نیز ارائه دهد). صرف نظر از نحوه جمع‌آوری داده‌ها، کاربران می‌توانند اطلاعات بیشتری مانند نام خیابان‌ها یا انواع ساختمان‌ها در مورد ویژگی‌های مختلف OSM ارائه دهند. در هشت سال پس از شروع، 1.5 میلیارد نقطه ارجاع جغرافیایی (گره ها در اصطلاحات OSM)، 144 میلیون راه (هم رشته های خطی و هم چند ضلعی های ساده) و 1.5 میلیون رابطه (برای توصیف روابط، مانند محدودیت های چرخشی یا چند ضلعی های پیچیده با سوراخ) [ 32 ] از امروز (اوت 2012) جمع آوری شده اند.
هر یک از اشیاء شامل یک شماره نسخه، یک شناسه منحصر به فرد، نام آخرین ویرایشگر و تاریخ آخرین اصلاح ( به عنوان مثال ، تاریخ ایجاد اشیاء جدید) است. علاوه بر این، جفت های به اصطلاح برچسب-مقدار حاوی اطلاعات اضافی (ارائه شده توسط کاربر) به هر ویژگی متصل می شوند. هر تغییری که کاربر در یک ویژگی در OSM انجام می دهد در یک مجموعه تغییرات به اصطلاح ذخیره می شود که حاوی اطلاعات مربوط به خود تغییر و همچنین ویرایشگر و زمان ویرایش است.
اگر کاربر بخواهد داده های پروژه OSM را برای یک برنامه کاربردی (به عنوان مثال نقشه ای برای حمل و نقل عمومی) پیاده سازی کند، یک فایل سیاره که حاوی تمام اطلاعات آخرین پایگاه داده پروژه است، قابل دانلود است [ 33]. با این حال، از آنجایی که افراد در هر دقیقه داده‌ها را ارائه می‌کنند، یک مجموعه داده پس از مدت کوتاهی (احتمالاً پس از یک دقیقه) قدیمی می‌شود. برای جلوگیری از استقرار یک پایگاه داده کامل OSM هر بار که نیاز به به روز رسانی است (که به سختی برای یک پایگاه داده به روز شده دقیقه یا ساعتی امکان پذیر نیست)، پروژه OSM به اصطلاح OSM Change-Files (OSC) را ارائه می دهد که به آن “تفاوت” نیز گفته می شود. “، که قابل دانلود است. این فایل ها فقط حاوی آخرین تغییرات پایگاه داده هستند و برای بازه های زمانی مختلف مانند هر دقیقه، ساعت یا روز در دسترس هستند. فرمت فایل های OSC در بخش بعدی این مقاله با جزئیات بیشتر توضیح داده خواهد شد. شکل 1یک نسخه ساده شده از زیرساخت پروژه OSM را نشان می دهد. با استفاده از یکی از ویرایشگرهای OSM آزادانه موجود، مشارکت کنندگان می توانند هر شی از پایگاه داده پروژه را ویرایش کنند. برنامه های کاربردی خارجی، مانند برنامه های مسیریابی یا نقشه برداری، می توانند از داده های پروژه با بازیابی فایل های dump- و diff- از پایگاه داده استفاده کنند.
Ijgi 01 00315 g001 1024
شکل 1. OpenStreetMap Infrastructure/Geostack (ساده شده).
به طور متوسط، تقریباً 700 عضو جدید هر روز بین ژانویه و مارس 2012 در پروژه ثبت نام کرده اند. طبق [ 23 ]، نزدیک به 30 درصد از آن مشارکت کنندگان تازه ثبت نام شده، مشارکت کنندگان فعال (و نه تنها یک کاربر ثبت نام شده) خواهند بود. یعنی هر روز در سال 2012، 230 عضو جدید OSM شروع به کمک به OSM کردند. جدول 1 شامل میانگین تعداد ویرایش‌ها برای هر شی OSM (گره، راه و رابطه) در روز بین ژانویه و ژوئن 2012 است.
جدول
جدول 1. تعداد اشیاء OSM ویرایش شده روزانه (ژانویه تا ژوئن 2012).
با در نظر گرفتن این اعداد برای تخمین بارهای کاری پردازش آینده برای ابزار پیشنهادی ما، می توان تعیین کرد که (به طور متوسط) در هر دقیقه، 830 ایجاد گره، 190 تغییر گره و 135 حذف گره باید انجام شود. علاوه بر این، 90 راه جدید، 48 روش اصلاح شده و 11 روش حذف شده و یک رابطه جدید، دو رابطه اصلاح شده و 0.2 حذف شده باید پردازش شوند. بدیهی است که این اعداد می توانند در طول روز متفاوت باشند، اما اولین نشانه ای را در مورد میزان ویرایش داده ها ارائه می دهند.

3. انواع وندالیسم

رویکرد باز جمع آوری داده ها در پروژه OSM می تواند انواع مختلفی از خرابکاری ها را ایجاد کند. ممکن است یک مشارکت کننده به طور عمدی یا تصادفی تغییراتی در مجموعه داده ایجاد کند که به هدف اصلی پروژه آسیب برساند. انواع متداول خرابکاری که در پایگاه داده جغرافیایی واقعی OSM ظاهر می شوند (بر اساس [ 30 ]):
  • یک شی جدید بدون ویژگی های رایج
  • اصلاح هندسی غیر منظم یک شی (“گرافیتی”)
  • اصلاح غیر متداول ویژگی های یک شی
  • حذف تصادفی اشیاء موجود
  • یک رفتار غیرعادی کلی توسط یک مشارکت کننده
  • تولید اشیاء خیالی و غیر موجود
  • استفاده نامناسب از ویرایش های خودکار (ربات ها) در پایگاه داده
  • استفاده از ویرایش های مکانیکی (به عنوان مثال، انتخاب 100 ساختمان و اضافه کردن کلید ساختمان: سقف: شکل = مسطح)
انواع دیگر خرابکاری را می توان در پروژه OSM یافت، اما تنها به داده های جغرافیایی واقعی که در پایگاه داده ذخیره می شود محدود نمی شود:
  • نقض حق نسخه برداری، به عنوان مثال، ردیابی داده ها از Google Maps
  • اختلافات در پروژه ویکی
  • رفتار مخرب یا ارسال هرزنامه یک عضو (به عنوان مثال، در ویرایش های او، در انجمن، در لیست های پستی یا در صفحه کاربری او)
شکل 2 زیر نمونه ای از خرابکاری “گرافیتی” را در سال 2011 در Zwijndrecht (هلند) نشان می دهد. کاربرانی که باعث این اختلال در ویژگی‌ها شده‌اند از ویرایشگر Potlatch OSM استفاده می‌کنند که مستقیماً تغییرات را در پایگاه داده OSM زنده اعمال می‌کند.
Ijgi 01 00315 g002 1024
شکل 2. مثالی از خرابکاری “گرافیتی” در OSM در Zwijndrecht (هلند) [ 34 ].
پوتاست و همکاران [ 35 ] و وست و همکاران. [ 21 ] وندالیسم را به صورت دستی در ویکی پدیا تجزیه و تحلیل کرد تا در مورد ویژگی های خاص اطلاعات کسب کند. برای تجزیه و تحلیل خود، از رویکرد مشابهی استفاده کردیم و 204 بلوک کاربر پروژه را به صورت دستی تجزیه و تحلیل کردیم تا اطلاعات دقیق تری در مورد خرابکاری در OSM جمع آوری کنیم. اعضای گروه کاری داده های OSM یا ناظران مجازند سایر اعضای OSM را برای مدت کوتاهی (بین 0 تا 96 ساعت) مسدود کنند [ 36 ]. اعضای مسدود شده باید به وب سایت اصلی OSM وارد شوند و اعلان خود را بخوانند تا بتوانند حساب های خود را رفع انسداد کنند. دلایل متعددی برای چنین بلوکی وجود دارد، مانند وارد کردن داده‌هایی که دستورالعمل‌های واردات را نقض می‌کنند [ 37 ]]، ایجاد ویرایش های انبوه که از کد رفتار [ 38 ] پیروی نمی کنند یا به نوعی داده ها را خراب می کنند. از بین این 204 کاربر که بین 7 اکتبر 2009 و 31 ژوئیه 2012 مسدود شده بودند، ما توانستیم 51 مورد رویداد خرابکاری داده را بدون احتساب اعضایی که چندین بار مسدود شده بودند، تعیین کنیم. الگوی جغرافیایی نشان داد که موارد خرابکاری را می توان در سرتاسر جهان در پایگاه داده OSM با تمرکز جزئی بر شهرهای بزرگتر یافت. جدول 2 نتایج ما را از موارد وندالیسم جمع آوری شده به صورت دستی و ویژگی های آنها خلاصه می کند.
جدول
جدول 2. ویژگی های وندالیسم در OSM (اکتبر 2009-ژوئیه 2012).
هنگامی که یک رویداد خرابکاری در یکی از مقالات ویکی‌پدیا شناسایی می‌شود، معمولاً در عرض چند دقیقه برگردانده می‌شود [ 39 ]. در تجزیه و تحلیل OSM ما، 63٪ از رویدادهای خرابکاری در عرض 24 ساعت و 76.5٪ در 48 ساعت برگردانده شدند. برخی از نقاط پرت را می توان تعیین کرد، که به بیش از 5 روز تا حداکثر 29 روز نیاز داشتند.
همانطور که قبلا ذکر شد، سه نوع شیء مورد استفاده در پایگاه داده وجود دارد: گره ها، راه ها و روابط. هر سه نوع شی را می توان توسط هر یک از اعضای پروژه ایجاد، اصلاح یا حذف کرد. اساساً، هر عضو همچنین می‌تواند اشیایی را که قبلاً توسط یک عضو دیگر جامعه ایجاد یا تغییر داده شده است را تغییر دهد. تغییرات در پایگاه داده OSM را می توان با بررسی فایل های “Diff” (که فایل های OSM-Change نیز نامیده می شود) تجزیه و تحلیل کرد. هر فایل “Diff”، خواه حاوی اطلاعاتی در مورد هر دقیقه، ساعت یا روز باشد، اطلاعاتی را در مورد تمام تغییراتی که در این بازه زمانی مشخص در پایگاه داده ایجاد شده است ارائه می دهد. جدیدترین ویرایش ها، یعنی تغییراتی که پس از ایجاد فایل تفاوت قبلی رخ داده است، بر اساس عملکرد آنها (“ایجاد”، “تغییر” یا “حذف”) و نوع شی (“گره”) گروه بندی می شوند. “راه” یا “رابطه”). با این حال، فایل‌های diff فقط حاوی ارجاع جغرافیایی گره‌ها هستند (به عنوان مثال ، طول و عرض جغرافیایی)، اما نه هندسه واقعی ویژگی های راه یا رابطه. علاوه بر این، اگر یک ویژگی اصلاح شده باشد، فایل هیچ اطلاعات خاصی در مورد تغییر واقعی ارائه نمی دهد. برای مثال، اگر یک گره جابه جا شده باشد، فایل تغییر فقط حاوی مکان جدید گره خواهد بود و نه هر دو مکان (یا بردار تفاوت). نوع عمل “ایجاد” و “حذف” فقط برای ایجاد یا حذف یک شی هندسی معتبر هستند (به عنوان مثال، ایجاد یک گره یا حذف یک رابطه کامل). در مقابل، هر زمان که اطلاعات اضافی (معنی) اضافه شود ( یعنی ایجاد)، تغییر داده شود ( یعنی اصلاح شود) یا حذف شود ( یعنی، حذف)، این تغییر به‌عنوان یک تغییر تغییر نشان داده می‌شود، نه یک اقدام ایجاد یا حذف. بنابراین، برای تجزیه و تحلیل دقیق‌تر شی (به‌ویژه برای یک اقدام اصلاحی)، اغلب لازم است تاریخچه شیء جمع‌آوری شود. اگر تغییر به منزله ایجاد یک شی باشد، لازم است نگاه دقیق‌تری به نوع شی ایجاد شده داشته باشیم و برای مثال بررسی کنیم که کدام ویژگی برای ایجاد اولیه استفاده شده است. در مورد تغییر یک شی موجود، جنبه های اضافی باید در نظر گرفته شود، مانند: آیا هندسه یا ویژگی های جسم تغییر کرده است؟ برای اینکه بتوانیم اطلاعاتی در مورد این تغییرات خاص ارائه کنیم، شی قبلی و به روز شده باید با هم مقایسه شوند. اطلاعات مفید اضافی را می توان با تعیین مالک سابق شیء جمع آوری کرد. شماره نسخه و تاریخ شی قبلی. اگر تغییری که در پایگاه داده انجام شده است حذف یک شی OSM باشد، ویژگی های مشابه فرآیند تحلیل اصلاح، مانند تعیین نوع شی و اینکه ابرداده شی قبلی چگونه به نظر می رسید، باید در نظر گرفته شود.

4. سیستم تشخیص خرابکاری مبتنی بر قانون

شناسایی انواع معرفی شده خرابکاری در پایگاه داده، امکان اجرای نمونه اولیه یک سیستم تصمیم گیری مبتنی بر قانون، به نام OSMPatrol را فراهم کرد. یکی از اهداف اصلی نمونه اولیه تشخیص خرابکاری در سریع ترین زمان ممکن بود. برای این منظور ما از فایل های OSM “Diff” و اطلاعات موجود در مورد تغییرات در پایگاه داده که در هر دقیقه ایجاد می شود استفاده کردیم. علاوه بر این، یک پایگاه داده OSM ایجاد شد تا بتوان شی OSM قبلی و جدید را با هم مقایسه کرد. همانطور که توضیح داده شد، کاربران در OSM اساساً می توانند هر نوع اطلاعات اضافی (معنی) را با برچسب گذاری ویژگی OSM مربوطه با جفت های کلید-مقدار ارائه دهند. هر دو، کلید و مقدار معمولاً می توانند حاوی هر محتوای دلخواه باشند. با این وجود، ویژگی های نقشه OSM شناخته شده و پذیرفته شده توسط جامعه [ 40]. برای اینکه بتوانیم احتمال خرابکاری اطلاعات اضافی (معانی) را مقایسه و قضاوت کنیم، برنامه نمونه اولیه ما اطلاعات اضافه شده (یا تغییر یافته) را با ویژگی های نقشه شناخته شده OSM مطابقت می دهد. این با تجزیه صفحه ویکی OSM برای ویژگی های نقشه، استخراج ویژگی های مختلف (به عنوان مثال، جفت کلید-مقدار) و ذخیره آنها در پایگاه داده. تصمیم گرفته شد که از هر دو نسخه انگلیسی و آلمانی وب سایت به عنوان مرجع استفاده شود، زیرا معمولاً حاوی بیشترین جزئیات است. تا 13 آگوست 2012، در مجموع 1139 ویژگی نقشه در پایگاه داده ما وجود داشت. هنگام ارزیابی تغییرات فردی، جفت کلید-مقدار اعمال شده در برابر پایگاه داده با تمام ویژگی های نقشه آزمایش می شود. علاوه بر این، برای بازیابی اطلاعات بیشتر در مورد کاربر OSM، پایگاه داده مشابهی را که توسط Neis [ 41 ] پیاده سازی شده بود، ساختیم. این جدول مشارکت کننده حاوی اطلاعات دقیقی است مانند:
  • یک مشارکت کننده OSM چند گره، راه و رابطه ایجاد، اصلاح یا حذف می کند؟
  • تاریخ ثبت نام او چه زمانی است؟ چه زمانی او شروع به مشارکت کرد؟
  • هر چند وقت یکبار او از یکی از متداول‌ترین برچسب‌ها در یک شی OSM مانند آدرس، امکانات رفاهی، مرز، ساختمان، بزرگراه، کاربری زمین، اوقات فراغت، نام، طبیعی، راه‌آهن، ورزش یا آبراه استفاده می‌کند؟
هر دو جدول در پایگاه داده OSMPatrol PostgreSQL ذخیره می شوند. شکل 3 معماری کامل نمونه اولیه توسعه یافته را در رابطه با معماری پروژه OSM نشان می دهد. برای بازیابی فایل های OSM “Diff” که حاوی تغییراتی است که در هر دقیقه در پایگاه داده ایجاد شده است، ابزار OSMOSIS اعمال می شود. OSMOSIS [ 42 ] یک ابزار JAVA خط فرمان منبع باز است که داده های OSM را به روش های مختلف پردازش می کند. در مورد خاص ما، همچنین مهم بود که پایگاه داده OSM PostgreSQL جدید ایجاد شده را با اطلاعات فایل “Diff” به روز کنیم تا بتوانیم اشیاء OSM قبلی و جدید ایجاد یا به روز شده را مقایسه کنیم.
Ijgi 01 00315 g003 1024
شکل 3. معماری OSM و OSMPatrol .
برای توضیح بهتر مراحل مختلف پردازش که هر دقیقه برای شناسایی خرابکاری احتمالی در پایگاه داده انجام می شود، شکل 4 نمودار توالی UML را نشان می دهد.
Ijgi 01 00315 g004 1024
شکل 4. نمودار توالی UML ابزار تشخیص خرابکاری ( OSMPatrol ).
این فرآیند با دانلود آخرین فایل OSM “Diff” از طریق OSMOSIS آغاز می شود. به محض اتمام دانلود، ابزار اصلی، OSMPatrol، این فایل را برای نشانه های خرابکاری تجزیه و تحلیل می کند. قبل از آزمایش هر ویرایش فایل بازیابی شده، ابزار دو لیست را درخواست می کند که ما تعریف کرده ایم و حاوی اطلاعات زیر است: (الف) لیستی از کاربرانی که سابقه حوادث خرابکاری دارند (لیست سیاه). و، (ب) لیستی از کاربرانی که نباید در طول آزمایش برای خرابکاری در نظر گرفته شوند (لیست سفید). در طول فرآیند بررسی هر ویرایش OSM فایل “Diff”، اطلاعاتی مانند شهرت مشارکت کننده، کیفیت ویژگی هایی که استفاده شده است و در صورت لزوم، نسخه های شی قبلی درخواست می شود. اگر ویرایشی به عنوان خرابکاری تشخیص داده شود، در یک جدول اضافی با برخی اطلاعات اضافی ذخیره می شود. پس از آزمایش همه ویرایش‌ها، ابزار OSMOSIS پایگاه داده OSM را با فایل معمولی «Diff» به‌روزرسانی می‌کند، که آخرین مرحله مهم است.
علاوه بر معماری منظم و توالی ابزار خرابکاری، یک جنبه اصلی تخصیص هر ویرایش به نوع خرابکاری مربوطه است. همانطور که در نمودار توضیح داده شده است ( شکل 4)، هر ویرایش در OSM آزمایش خواهد شد. یک فرضی که می توان مطرح کرد این است که مشارکت کنندگان جدیدی که به تازگی به پروژه ملحق شده اند در مقایسه با یک عضو باتجربه تر مستعد خطا، اشتباه یا خرابکاری هستند. بنابراین، ارزش کلی، که توضیح می‌دهد که آیا ویرایش یک عمل خرابکارانه بالقوه است، به دو بخش تقسیم می‌شود: مقدار اول شهرت مشارکت‌کننده را خلاصه می‌کند و مقدار دوم به خود ویرایش امتیاز می‌دهد. علاوه بر این، ممکن است نتایج را بر اساس نوع خرابکاری مربوطه و/یا با ویرایش‌هایی که توسط مشارکت‌کنندگان جدید ایجاد شده‌اند فیلتر کنید. با این حال، برای اینکه بتوان مقداری را تعیین کرد که نشان دهنده شهرت یک عضو است، چندین مقدار باید ادغام شوند. اشیاء ایجاد شده و تگ های مربوطه که در طول ایجاد استفاده شده اند باید به همان اندازه در ارزش شهرت یک کاربر در نظر گرفته شوند. مشارکت‌کنندگان فوق‌الذکر پروژه، گره‌ها/راه‌های بیشتری ایجاد می‌کنند، بنابراین شی رابطه وزن کمتری می‌گیرد. تگ های استفاده شده به تگ های “Top12” استفاده شده پروژه تقسیم می شوند. اینها شامل تمام دسته‌های کلیدی مشخص شده ویژگی‌های نقشه OSM [40 ] فهرست ارزش شهرت برای یک مشارکت کننده می تواند بین 0 تا 100٪ باشد که در آن 0 نشان دهنده ارزش یک عضو جدید و 100٪ یک عضو متخصص است. لیست زیر وزن هر جنبه را برای محاسبه شهرت کاربر نهایی نشان می دهد:
  • حداکثر 20٪ برای تعداد گره های ایجاد شده توسط مشارکت کننده
  • حداکثر 20٪ برای تعداد راه های ایجاد شده توسط مشارکت کننده
  • حداکثر 12٪ برای تعداد روابط ایجاد شده توسط مشارکت کننده
  • حداکثر 4٪ برای تعداد هر یک از برچسب های “12 برتر” (آدرس، امکانات رفاهی، مرز، ساختمان، بزرگراه، کاربری زمین، اوقات فراغت، نام، طبیعی، راه آهن، ورزش یا آبراه)
تاریخ ثبت نام یک عضو برای تعیین شهرت یک مشارکت کننده در نظر گرفته نشده است، اما در فرآیند تشخیص خرابکاری از آن استفاده شده است. شکل 5 نمودار فعالیت UML را برای فرآیند تشخیص خرابکاری احتمالی ویرایش OSM نشان می دهد. به طور کلی می توان بین ایجاد، اصلاح و حذف یک شی تمایز قائل شد. در مرحله اول، مشارکت کننده ای که شی را ویرایش کرده است مشخص می شود. بسته به نوع ویرایشی که انجام شده است، مقدار بالای 0٪ تعیین می کند که آیا ویرایش می تواند به عنوان خرابکاری در نظر گرفته شود یا خیر.
اگر ویرایش یک شی تازه ایجاد شده باشد، فقط از ویژگی های شی، در صورت موجود بودن، برای تعیین استفاده می شود. در همان زمان، همه ویژگی‌ها با فهرست ویژگی‌های نقشه مطابقت داده می‌شوند (نگاه کنید به بالا). اگر ترکیبی در لیست ویژگی های نقشه موجود نباشد، ارزش خرابکاری این ویرایش افزایش می یابد. بنابراین، ارزش کلی خرابکاری یک ویرایش می تواند با توجه به تعداد تگ های آن افزایش یابد.
اگر ویرایش تغییر یا حذف یک شی باشد، برخی از پارامترهای اضافی بررسی خواهند شد. آخرین نسخه شیء با ویرایش ( یعنی نسخه جدید) مقایسه می‌شود تا به سؤالاتی پاسخ داده شود: مالک شی سابق کیست و آیا شهرت کاربر بالایی را نشان می‌دهد؟ شماره نسخه شی قبلی چیست و تاریخ ویرایش شی قبلی چیست؟ هر سه مورد دوباره برای افزایش ارزش کلی خرابکاری یک ویرایش استفاده خواهند شد. به‌علاوه، اگر ویرایش یک اصلاح باشد، هندسه‌ها با یکدیگر مقایسه می‌شوند تا تشخیص دهند که آیا یک شی بیشتر از مثلاً 11 متر جابجا شده است یا خیر. همچنین تگ های آخرین و شی قبلی با هم مقایسه می شوند تا اینکه کدام تگ (کلید/مقدار) تغییر، اضافه یا حذف شده است، تجزیه و تحلیل شود.
Ijgi 01 00315 g005 1024
شکل 5. نمودار فعالیت UML برای تشخیص انواع خرابکاری یک OSM ویرایش نمودار توالی ابزار تشخیص خرابکاری ( OSMPatrol ).

5. نتایج تجربی

پس از آزمایش نمونه اولیه توسعه یافته برای مناطق کوچک با موارد خرابکاری سنگین و سبک شناخته شده، ما تجزیه و تحلیل نهایی خود را با اجرای نمونه اولیه بر روی یک سرور اختصاصی به مدت یک هفته (14 اوت 2012 تا 21 اوت 2012) انجام دادیم. سخت افزار این سرور شامل یک CPU 16 هسته ای با 2.93 گیگاهرتز، 35 گیگابایت رم و فضای کلی 3 ترابایت هارد دیسک با سرعت های بین 5400 تا 7200 RPM بود. در طول مرحله آزمایش، OSMPatrol حدود هفت ویرایش Mio “وندالیسم” 9200 کاربر مختلف را برای کل هفته شناسایی کرد. در همان بازه زمانی، حدود 16 ویرایش Mio در پایگاه داده OSM انجام شد. این بدان معنی است که نمونه اولیه 44٪ از تمام ویرایش ها را به عنوان خرابکاری احتمالی مشخص کرده است. شکل 6 زیرتوزیع مقادیر تحت تأثیر گره ها، راه ها و روابط را نشان می دهد. علاوه بر این، شکل اطلاعاتی در مورد تعداد اشیاء آسیب دیده در طول ایجاد، اصلاح یا حذف ارائه می دهد.
Ijgi 01 00315 g006 1024
شکل 6. توزیع اشیا و انواع ویرایش در خرابکاری شناسایی شده (14-21 اوت 2012).
همانطور که توسط Neis و Zipf [ 23 ] توضیح داده شد، این هفته اساساً یک هفته متوسط ​​را نشان می دهد (با توجه به رفتار مشارکت)، به این معنی که اعضای OSM به روشی مشابه هر هفته در میان به پروژه کمک می کنند. بیانیه مشابهی را می توان در مورد ویرایش های خرابکاری نیز بیان کرد. ما نتوانستیم روز خاصی از هفته را تعیین کنیم که در آن تعداد ویرایش‌های خرابکاری بیشتر صورت گرفته باشد. جالب اینجاست که تقریباً 1/3 از 9200 کاربری که به عنوان مرتکب احتمالی خرابکاری شناسایی شدند، مشارکت کنندگان جدید این پروژه بودند. شکل 7 زیر توزیع ویرایش هایی را نشان می دهد که بر اساس شهرت کاربر به عنوان خرابکاری شناسایی شده اند. حدود 50 درصد از کاربران، که برای آنها OSMPatrolیک مورد احتمالی خرابکاری را شناسایی کرد، شهرت کاربر بیش از 66٪، نشان می دهد که اقدامات مشارکت کنندگان با تجربه نیز می تواند به عنوان خرابکاری شناخته شود. بر اساس نتایج جمع‌آوری‌شده، کاربرانی با سطح شهرت بیش از ۶۶ درصد، ۴۸ درصد از موارد خرابکاری احتمالی شناسایی‌شده را مرتکب شدند. با توجه به این مقادیر، حدود 43 درصد از تمام ویرایش های خرابکاری شناسایی شده توسط کاربران جدید پروژه با شهرت کم انجام شده است. به طور کلی، تقریباً 1/3 (36٪) از تمام کاربران خرابکاری، کاربران جدید بودند.
Ijgi 01 00315 g007 1024
شکل 7. توزیع کاربران خرابکاری و ویرایش های خرابکاری بر اساس شهرت کاربر (14 تا 21 اوت 2012).
روش های مختلفی برای شناسایی موارد بالقوه خرابکاری استفاده شد. برای هر ویرایش خرابکاری ذخیره شده، ویژگی‌های اضافی موجود است، به عنوان مثال، مهر زمانی، کاربر و شهرت او، ارزش خرابکاری و یک نظر متنی با برخی اطلاعات که چرا ویرایش به عنوان خرابکاری علامت‌گذاری شده است.
بر اساس این مقادیر ما سه فیلتر اصلی ایجاد کردیم:
  • نمایش تمام ویرایش های کاربران جدید و/یا کاربران با شهرت بسیار کم (<5٪).
  • نمایش همه کاربرانی که بیش از 500 شی را در یک ساعت تغییر داده یا حذف کرده اند.
  • نمایش همه کاربرانی که اشیاء گره را تغییر داده و شی را برای بیش از 500 متر جابجا کرده اند.
بر اساس فیلتر اول، ویرایش های تقریباً 500 کاربر باید هر روز بررسی می شد. فیلتر دو تقریباً 75 کاربر را نشان می‌دهد و سه نفر را حدود 100 کاربر در روز در مرحله آزمایشی ما در آگوست 2012 فیلتر می‌کند. پس از بررسی حداقل 30 درصد از ویرایش ارائه شده توسط این کاربران، امکان یافتن حداقل یک مورد خرابکاری واقعی در روز بدون آن وجود داشت. نگاهی عمیق تر به نوع ویرایش های کاربر. هر دومین مورد از این موارد خرابکاری توسط سایر همکاران OSM ظرف یک یا دو روز بازگردانده شد. در برخی موارد دیگر، کاربران توسط OSM DWG مسدود شده‌اند یا از طریق ایمیل با کاربران تماس گرفته می‌شوند تا آگاهی خود را در مورد خطاهای ویرایش به پایگاه داده زنده افزایش دهند. به طور کلی، نتایج نشان داد که تشخیص موارد خرابکاری واقعی از مجموعه داده های شناسایی شده ما امکان پذیر است. با این حال، تجزیه و تحلیل همچنین نشان می دهد که ابزارهای بیشتری مورد نیاز است که کاربر را در تجزیه و تحلیل ویرایش اشتباه احتمالی در OSM به روشی ساده تر و راحت تر پشتیبانی می کند. یک راه حل ارائه یک صفحه وب یا برنامه کاربردی است که اطلاعات دقیقی در مورد برچسب و/یا تغییرات هندسی تاریخ یک شی ارائه می دهد، همانطور که Huggle [43 ] و تحلیل او از مقالات ویکی پدیا. با چنین برنامه یا سرویسی، اعتبارسنجی ویرایش های خرابکاری که توسط OSMPatrol شناسایی شده اند آسان تر خواهد بود .
در هفته آزمایش شده، حدود 85 درصد از ویرایش های خرابکاری شناسایی شده تنها توسط 1000 کاربر انجام شده است. این نشان می‌دهد که اهمیت استفاده و حفظ لیست سیاه و سفید کاربران معرفی‌شده ما قابل دست‌کم نیست. تعداد کمی از کاربران با موارد خرابکاری بر اساس تعداد زیادی از اشیاء حذف شده توسط این کاربران شناسایی شدند که توسط همین کاربر در گذشته ایجاد شده بودند. این موارد خاص ممکن است امکان تحقیقات آینده را در مورد نحوه جداسازی ویرایش‌های انجام شده روی داده‌های خود کاربر یا داده‌های ارائه‌شده توسط دیگران فراهم کند. OSMPatrol همچنین قادر به شناسایی تعداد زیادی حذف در فرانسه بود، جایی که بسیاری از کاربران فعال OSM در حال حاضر در حال پاکسازی واردات قبلی ساختمان ها به پایگاه داده هستند.
به طور کلی، OSMPatrol قادر به شناسایی انواع خرابکاری های انجام شده توسط کاربران جدید، واردات “غیرقانونی” و ویرایش های انبوه بود. با این حال، تشخیص انواع خرابکاری مثبت کاذب از موارد واقعی که توسط کاربرانی با سطح شهرت بالا یا توسط کاربرانی که فقط یک یا دو شی را حذف می‌کنند، انجام می‌شود، دشوار است.

6. بحث

هنگام طراحی پایه قوانین و در واقع اجرای نمونه اولیه، چند موضوع و ایده برای یک نمونه اولیه پیچیده تر آشکار شد. آن‌ها هنوز پیاده‌سازی نشده‌اند، زیرا ترکیب آن‌ها به قیمت ناتوانی در انجام تشخیص خرابکاری جزئی (به دلیل هزینه‌های محاسباتی بالا) است. با این وجود، آنها در این بخش مورد بحث قرار خواهند گرفت و شاید بعداً در سیستم گنجانده شوند.
با توجه به شهرت هر کاربر، سوال برانگیز بود که آیا (و چگونه) بازه زمانی عضویت پروژه (به عنوان مثال، زمانی که کاربر ثبت نام کرده است). آیا این پارامتر شاخصی برای خرابکاری است یا خیر؟ آیا تغییر کاربری که چهار سال است ثبت نام کرده احتمالا خرابکاری کمتری نسبت به تغییر کاربری که یک هفته پیش ثبت نام کرده است؟ ادغام خالص متعلق به پروژه هیچ دانش جدیدی ارائه نمی دهد، زیرا اغلب کاربران بدون ویرایش واقعی پایگاه داده ثبت نام می کنند. با این حال، پس از چند ماه (یا سال) ممکن است دوباره برگردند و اولین ویرایش خود را انجام دهند – آیا این اکنون به این معنی است که خرابکاری است یا نه؟ بنابراین، در نظر گرفتن ترکیبی از تعلق پروژه و فعالیت در جامعه (به اصطلاح نسبت فعالیت) می تواند به یک شاخص اضافی برای تشخیص خرابکاری منجر شود. با این حال اجرای واقعی این عامل در نمونه اولیه ارائه شده در اینجا محقق نشده است.
همانطور که در بالا توضیح داده شد، تغییرات عظیم در هندسه یک ویژگی، مانند جابجایی POI ده متر یا بیشتر، احتمالاً خرابکاری است. با این حال، با آگاهی از این امر به عنوان یک عامل شرور، می توان یک تغییر هندسی را به چندین تغییر کوچک تقسیم کرد، که احتمالاً شناسایی نمی شوند. به عنوان مثال، به جای اینکه یک POI 15 متری را به طور همزمان به مکان دیگری منتقل کند، یک کاربر می تواند POI را 15 بار در یک متر به مکان دیگری منتقل کند. حادثه اول به عنوان وندالیسم تشخیص داده می شود، در حالی که مورد دوم شناسایی نمی شود، بنابراین به عنوان یک تغییر مطمئن تعریف می شود. بنابراین، یک آشکارساز خرابکاری پیشرفته و پیچیده‌تر نیز باید تغییرات متعددی را برای یک شی در طول زمان در نظر بگیرد. اینها ممکن است از طریق مهرهای زمانی که برای یک شیء توسط همان کاربر به یکدیگر نزدیک هستند قابل تشخیص باشند.
یکی دیگر از شاخص های مشکوک برای خرابکاری، ارزیابی شماره نسخه یک ویژگی OSM است. هنگام ایجاد یک ویژگی جدید، شماره نسخه روی یک تنظیم می شود. نسخه با هر تغییر این شی مجزا (بدون توجه به تغییر واقعی) افزایش می یابد. اما، آیا تغییر روی یک شی با شماره نسخه بالا بیشتر یک نوع خرابکاری است تا تغییر روی یک شی با شماره نسخه پایین؟ وضعیت برعکس چطور؟ چند تحقیق نشان داد که به اصطلاح “اشیاء ویرایش شده به شدت” وجود دارد [ 44 ]] در OSM، اما معلوم نیست که آیا تغییرات روی آن اشیا بیشتر احتمال دارد خرابکاری باشد یا خیر. می توان استدلال کرد که هر چه تعداد نسخه بالاتر باشد، احتمال کمتری دارد که ویژگی در معرض خرابکاری قرار گیرد، زیرا ارزش نسخه بزرگتر همچنین به معنای بررسی بیشتر ویژگی بالقوه است. اما در مورد یک کاربر که چند بار یک شی را تغییر می دهد چطور؟ آیا این نیز نشان دهنده درستی شیء است؟ این عوامل نشان می دهد که بررسی هایی که صرفاً بر روی شماره نسخه ها تکیه می کنند، شاخص خوبی برای احتمال خرابکاری یک شی نیستند. با این وجود، ترکیب شماره نسخه و تعداد ویرایشگرهای متمایز یک شی احتمالاً نشانگر مناسبی است.
هنگام تعریف پایه قانون و طراحی نمونه اولیه، همچنین آشکار شد که تشخیص خرابکاری ارتباط نزدیکی با اعتبارسنجی داده ها (تا حدی) دارد. یک مثال برای یک شاخص بالقوه برای احتمال خرابکاری تغییر در OSM، در نظر گرفتن همسایگی یا اطراف یک شی تازه ایجاد یا ویرایش شده است. به عنوان مثال، تغییر یک جاده در یک منطقه مسکونی از مسکونی به اولیه به احتمال زیاد خرابکاری است (یا اصلاح ضروری اشتباه قبلی توسط یک کاربر بی تجربه). هنگامی که فقط خود تغییر را در نظر می گیریم، این نوع ویرایش ها شناسایی نمی شوند، در حالی که ادغام اشیاء در همسایگی احتمالاً توجیه بیشتری برای آشکارساز فراهم می کند. این واقعیت که همسایگی باید مورد توجه قرار گیرد، علاوه بر این، توسط قانون اول جغرافیایی توبلر نیز حمایت می شود.45 ]، با بیان این که «همه چیز به هر چیز دیگری مربوط است، اما چیزهای نزدیک بیشتر از چیزهای دور مرتبط هستند».
تغییر نام یک شی موجود یا افزودن نام به یک شی جدید نیز ممکن است حاوی خرابکاری باشد. با این حال تشخیص درست بین خرابکاری و اعتبارسنجی نام ها بسیار سخت (یا بالقوه غیرممکن) است. به عنوان مثال، گسترش مخفف یک نام به نام کامل آن (مثلاً تغییر خیابان به خیابان) خرابکاری نیست. به عنوان یک راه حل ممکن، مقایسه نام ها با فرهنگ لغت رایج اصطلاحات موجود ممکن است وضوح را ارائه دهد.
برخلاف موارد ذکر شده، برخی از جنبه های مربوط به خرابکاری، مانند آدرس IP، به دلیل از دست دادن داده ها (امکان جمع آوری آدرس IP یک مشارکت کننده OSM) در کلاینت (هنوز) قابل اجرا نیست. با این حال، داشتن چنین اطلاعاتی ممکن است یک شاخص خوب (اضافی) برای احتمال خرابکاری باشد. می توان بررسی کرد که آیا IP (و نقطه دسترسی) با ناحیه ای که تغییر در آن انجام شده است مناسب است یا خیر. به عنوان مثال، اگر یک کاربر خیابانی را در کشوری که صدها کیلومتر دورتر است تغییر دهد، این ممکن است بیشتر خرابکاری باشد تا تغییر نام یک خیابان در کنار نقطه دسترسی یک کاربر، مشابه آنچه توسط West و همکارانش توضیح داده شده است. [ 21] برای تشخیص خرابکاری ویکی پدیا. علاوه بر این، ذخیره آدرس IP کاربری که مرتکب خرابکاری شده است برای مسدود کردن کاربر از پروژه و جلوگیری از هر گونه خرابکاری در آینده می تواند مفید باشد.

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

در این مقاله، ما حوادث خرابکاری گذشته، پایگاه داده فعلی OSM و مشارکت‌های آن، و همچنین ابزارهای مربوط به شناسایی خرابکاری ویکی‌پدیا را بررسی کردیم. بر اساس نتایج جمع‌آوری‌شده، ما یک ابزار اولیه مبتنی بر قوانین جامع ایجاد کردیم که امکان تشخیص خودکار خرابکاری در OSM را فراهم می‌کند. می توان نتیجه گرفت که تشخیص خرابکاری با استفاده از روش شناسی مبتنی بر قانون (تا حدی) امکان پذیر است. در طول مرحله آزمایش در آگوست 2012، نمونه اولیه حدود هفت میلیون ویرایش را به عنوان خرابکاری احتمالی مشخص کرد. با ایجاد چندین فیلتر، توانستیم حداقل یک مورد خرابکاری واقعی در روز را مشخص کنیم. به طور کلی، خرابکاری شناسایی شده توسط همه انواع کاربران OSM و نه تنها توسط کاربران جدید یا کاربران با شهرت پایین انجام شده است.
با این حال، همانطور که در بخش قبل صحبت شد، محدودیت ها و محدودیت هایی وجود دارد. اگرچه می‌توان آن‌ها را حل کرد، اما احتمالاً به قیمت عملکرد آهسته تمام می‌شوند، بنابراین هدف اولیه شناسایی دقیقه‌ای احتمالاً نمی‌تواند محقق شود (حداقل در نمونه اولیه ارائه‌شده و پیکربندی سرور فعلی). علاوه بر این، اگرچه خرابکاری را می توان تشخیص داد، اما لازم به ذکر است که بررسی دستی صحت همچنان ارجح است.
همانطور که قبلاً توضیح داده شد، هدف تحقیق انجام شده اعتبار سنجی داده های OSM نیست، بلکه تشخیص خرابکاری است. با این حال، جدایی بین این دو حوزه همیشه روشن نیست. تمرکز بر روی تشخیص خرابکاری است، زیرا OSM (و مخصوصاً ویراستاران) قبلاً روش‌های مختلفی را برای تضمین کیفیت و اعتبار سنجی ترکیب کرده‌اند. به عنوان مثال، JOSM قبل از آپلود به کاربر اطلاع می دهد که اگر هندسه های متقاطع یا عناصر تکراری وجود داشته باشد. با این حال، ویراستاران فقط به کاربر اطلاع می دهند، اما از بارگذاری واقعی تغییرات خودداری نمی کنند.
اصل تشخیص خرابکاری در اجرای نمونه اولیه ما مشابه رویکرد اصلی یک فایروال است: تشخیص موارد بسیار زیاد را به تشخیص موارد بسیار کم خرابکاری ترجیح دهید. بنابراین، نمونه اولیه بیشتر از آنچه در واقعیت وجود دارد، موارد خرابکاری را شناسایی می کند. به این ترتیب، اطمینان حاصل می شود که اشتباهات کمتری وجود دارد، اما مثبت کاذب بیشتری نیز وجود دارد. با این حال، از آنجایی که سیستم فقط در مورد خرابکاری اطلاع می دهد (به جای اینکه در واقع جلوی خرابکاری را بگیرد)، این نسبتاً غیرانتقادی است.
برای کارهای آینده، تقویت API نمونه اولیه توسعه‌یافته مهم خواهد بود. با ارائه نتایج جمع آوری شده ( یعنی خرابکاری شناسایی شده) از طریق یک رابط کاملاً تعریف شده، سایر توسعه دهندگان برنامه می توانند از این نتایج برای اهداف خود استفاده کنند. یکی از برنامه های ممکن (و مطلوب) ابزاری است که کاربران را قادر می سازد تا به عنوان گشت در یک منطقه مشخص ثبت نام کنند. به این ترتیب، کاربر می‌تواند یک منطقه و/یا ویژگی‌های متمایز را تعریف کند و به محض اینکه OSMPatrol یک نوع خرابکاری را که مطابق با الگوی ترجیحی یک گشت است شناسایی کرد، از طریق آن مطلع می‌شود. پست الکترونیک. یکی دیگر از برنامه های کاربردی بالقوه، پلتفرمی است که به کاربران شناخته شده امکان می دهد ویرایش ها را به عنوان خرابکاری یا غیر خرابکاری برجسته کنند و یک لیست سفید مناسب برای OSMPatrol حفظ کنند..
به طور کلی، موضوع شناسایی و پیشگیری از خرابکاری نیز در جامعه OSM مورد بحث قرار می گیرد، به عنوان مثال، محدودیت API OSM. همانطور که قبلا ذکر شد، یک راه حل ممکن می تواند اجازه دادن به کاربران با تجربه برای بررسی محتوای ارسالی کاربران جدید و شاید بی تجربه باشد. این رویکرد قبلاً توسط پلتفرم Google MapMaker [ 29 ] پیاده سازی شده است. با این حال، در این مورد، این سوال باقی می ماند: آیا داوطلبان کافی در دسترس هستند که مایل به کار بر روی برخی از اعتبار سنجی داده های دستی در آینده باشند؟

منابع

  1. دیاز، ال. گرانل، سی. گولد، ام. Huerta, J. مدیریت اطلاعات تولید شده توسط کاربر در زیرساخت های سایبری جغرافیایی. ژنرال آینده. محاسبه کنید. سیستم 2011 ، 27 ، 304-314. [ Google Scholar ]
  2. Goodchild، MF Citizens به عنوان حسگر: دنیای جغرافیای داوطلبانه. ژئوژورنال 2007 ، 69 ، 211-221. [ Google Scholar ] [ CrossRef ]
  3. هیپک، سی. داده‌های جغرافیایی جمع‌سپاری. ISPRS J. Photogramm. 2010 ، 65 ، 550-557. [ Google Scholar ] [ CrossRef ]
  4. نیس، پ. زیلسترا، دی. Zipf، A. تکامل شبکه خیابانی نقشه های جمعیتی: نقشه خیابان باز در آلمان 2007-2011. اینترنت آینده 2012 ، 4 ، 1-21. [ Google Scholar ]
  5. گوتز، ام. استفاده از داده های جغرافیایی داخلی با منبع جمعی برای ایجاد یک برنامه وب مسیریابی داخلی سه بعدی. اینترنت آینده 2012 ، 4 ، 575-591. [ Google Scholar ] [ CrossRef ]
  6. مونی، پی. سان، اچ. کورکوران، پ. Yan, L. داده ها و اطلاعات مکانی تولید شده توسط شهروندان: خطرات و فرصت ها. در مجموعه مقالات کنفرانس بین المللی IEEE در زمینه اطلاعات و اطلاعات امنیتی، پکن، چین، 10-12 ژوئیه 2011.
  7. نیس، پ. Zipf، A. OpenRouteService.org سه بار “باز” ​​است: ترکیب OpenSource، OpenLS و OpenStreetMaps. در مجموعه مقالات شانزدهمین کنفرانس سالانه GIS Research UK GISRUK 2008، منچستر، انگلستان، 2 تا 4 آوریل 2008.
  8. بیش از، م. شیلینگ، آ. نوبائر، اس. Zipf، A. تولید مدل های شهر سه بعدی مبتنی بر وب از OpenStreetMap: وضعیت فعلی در آلمان. محاسبه کنید. محیط زیست سیستم شهری 2010 ، 34 ، 496-507. [ Google Scholar ] [ CrossRef ]
  9. OpenGeoData.org. Google IP خرابکاری OpenStreetMap . در دسترس آنلاین: http://opengeodata.org/google-ip-vandalizing-openstreetmap (دسترسی در 5 اوت 2012).
  10. ویکی پدیا، دایره المعارف آزاد. گروه ویژه خرابکاری ظریف در دسترس آنلاین: http://en.wikipedia.org/wiki/Wikipedia:Subtle_Vandalism_Taskforce (در 12 سپتامبر 2012 قابل دسترسی است).
  11. ویکی OpenStreetMap. گروه کاری داده OpenStreetMap . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Data_working_group (در 5 اوت 2012 قابل دسترسی است).
  12. ویکی OpenStreetMap. فهرست تماشای OpenStreetMap. در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/OWL_%28OpenStreetMap_Watch_List%29 (در 5 اوت 2012 قابل دسترسی است).
  13. ITO. OSM Mapper. در دسترس آنلاین: http://www.itoworld.com/static/openstreetmap_tools/osm_mapper.html (در 5 اوت 2012 قابل دسترسی است).
  14. ون دن برگ، اچ. کوتزی، اس. کوپر، AK تجزیه و تحلیل مشترک برای بهبود طراحی مخازن اطلاعات جغرافیایی داوطلبانه. در مجموعه مقالات AfricaGEO 2011، کیپ تاون، آفریقای جنوبی، 31 مه تا 2 ژوئن 2011.
  15. کامینها، سی. Furtado، V. مدل سازی گزارش های کاربر در Crowdmaps به عنوان یک شبکه پیچیده. در مجموعه مقالات بیست و یکمین کنفرانس بین المللی وب جهانی، لیون، فرانسه، 16 تا 20 آوریل 2012.
  16. براندو، سی. Bucher، B. کیفیت در محتوای فضایی تولید شده توسط کاربر: موضوعی از مشخصات. در مجموعه مقالات سیزدهمین کنفرانس بین المللی AGILE در علم اطلاعات جغرافیایی، گیماراس، پرتغال، 10-14 مه 2010.
  17. چانه، S.-C.; خیابان، WN; سرینیواسان، پ. آیشمن، دی. تشخیص خرابکاری ویکی‌پدیا با یادگیری فعال و مدل‌های زبان آماری. در مجموعه مقالات چهارمین کارگاه آموزشی اعتبار اطلاعات (WICOW ’10)، رالی، NC، ایالات متحده آمریکا، 27 آوریل 2010.
  18. Potthast، M. Crowdsourcing Corpus خرابکاری ویکی‌پدیا. در مجموعه مقالات سی و سومین کنفرانس بین المللی ACM SIGIR در مورد تحقیق و توسعه در بازیابی اطلاعات، ژنو، سوئیس، 19 تا 23 ژوئیه 2010.
  19. آدلر، بی. د آلفارو، ال. مولا ولاسکو، اس. روسو، پی. West, A. ویکی‌پدیا تشخیص خرابکاری: ترکیب زبان طبیعی، فراداده و ویژگی‌های شهرت. در زبان شناسی محاسباتی و پردازش هوشمند متن ; Springer: برلین، آلمان، 2011; جلد 6609، ص 277–288. [ Google Scholar ]
  20. مولا ولاسکو، SM ویکی‌پدیا تشخیص خرابکاری. در مجموعه مقالات بیستمین کنفرانس بین المللی همکار در وب جهانی (WWW ’11)، حیدرآباد، هند، 28 مارس تا 1 آوریل 2011.
  21. غرب، AG; کنان، اس. لی، آی. شناسایی خرابکاری ویکی‌پدیا از طریق تجزیه و تحلیل فضایی-زمانی فراداده تجدیدنظر؟ در مجموعه مقالات سومین کارگاه اروپایی در مورد امنیت سیستم (EUROSEC ’10)، پاریس، فرانسه، 13 آوریل 2010.
  22. OpenStreetMap.org. آمار OpenStreetMap. در دسترس آنلاین: http://www.openstreetmap.org/stats/data_stats.html (در 8 اوت 2012 قابل دسترسی است).
  23. نیس، پ. Zipf، A. تجزیه و تحلیل فعالیت مشارکت کننده یک پروژه داوطلبانه اطلاعات جغرافیایی – مورد OpenStreetMap. ISPRS Int. J. Geo-Inf. 2012 ، 1 ، 146-165. [ Google Scholar ]
  24. زیلسترا، دی. Hochmair، HH مطالعه مقایسه ای دسترسی عابر پیاده به ایستگاه های حمل و نقل با استفاده از داده های شبکه رایگان و اختصاصی. ترانسپ Res. ضبط 2011 ، 2217 ، 145-152. [ Google Scholar ] [ CrossRef ]
  25. لودویگ، آی. ووس، ا. Krause-Traudes، M. مقایسه شبکه های خیابانی Navteq و OSM در آلمان. Adv. Geoinf. علمی جهان در حال تغییر 2011 ، 1 ، 65-84. [ Google Scholar ] [ CrossRef ]
  26. گیرس، جی اف. Touya, G. ارزیابی کیفیت مجموعه داده OpenStreetMap فرانسه. ترانس. GIS 2010 ، 14 ، 435-459. [ Google Scholar ]
  27. Haklay, M. اطلاعات جغرافیایی داوطلبانه چقدر خوب است؟ مطالعه تطبیقی ​​مجموعه داده های نظرسنجی OpenStreetMap و مهمات. محیط زیست طرح. B 2010 , 37 , 682-703. [ Google Scholar ] [ CrossRef ]
  28. مونی، پی. کورکوران، پ. Ciepluch، B. پتانسیل استفاده از اطلاعات جغرافیایی داوطلبانه در برنامه های کاربردی محاسبات سلامت فراگیر. J. هوش محیطی. انسان. محاسبه کنید. 2012 . [ Google Scholar ] [ CrossRef ]
  29. نقشه ساز گوگل. سوالات متداول . در دسترس آنلاین: http://www.google.com/mapmaker/mapfiles/s/faq.html (در 12 سپتامبر 2012 قابل دسترسی است).
  30. ویکی OpenStreetMap. خرابکاری در ویکی OpenStreetMap . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Vandalism (در 8 اوت 2012 قابل دسترسی است).
  31. تیم بینگ Bing درگیر انجمن نقشه‌های باز می‌شود—وبلاگ نقشه‌های بینگ. در دسترس آنلاین: http://www.bing.com/community/site_blogs/b/maps/archive/2010/11/23/bing-engages-open-maps-community.aspx (در 27 سپتامبر 2012 قابل دسترسی است).
  32. OSMstats. آمار نقشه جهان ویکی رایگان . در دسترس آنلاین: http://osmstats.altogetherlost.com (در 11 اوت 2012 قابل دسترسی است).
  33. سیاره OpenStreetMap. شاخص از . در دسترس آنلاین: http://planet.openstreetmap.org (در 1 اوت 2012 قابل دسترسی است).
  34. ویکی OpenStreetMap. وندالیسموس زوایندرخت . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/File:Vandalismus_Zwijndrecht.gif (در 11 آگوست 2012 قابل دسترسی است).
  35. پوتاست، ام. استاین، بی. گرلینگ، آر. تشخیص وندالیسم خودکار در ویکی پدیا. در مجموعه مقالات پژوهش IR، سی امین کنفرانس اروپایی در زمینه پیشرفت در بازیابی اطلاعات (ECIR ’08)، گلاسکو، اسکاتلند، 30 مارس تا 3 آوریل 2008.
  36. OpenStreetMap.org. بلوک های کاربر OSM . در دسترس آنلاین: http://www.openstreetmap.org/user_blocks (در 1 اوت 2012 قابل دسترسی است).
  37. ویکی OpenStreetMap. واردات/کاتالوگ . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Import/Catalogue (در 20 اوت 2012 قابل دسترسی است).
  38. ویکی OpenStreetMap. ویرایش خودکار کد رفتار . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct (در 20 اوت 2012 قابل دسترسی است).
  39. کیتور، آ. Kraut، RE مهار خرد جمعیت در ویکی پدیا: کیفیت از طریق هماهنگی. در مجموعه مقالات کنفرانس ACM 2008 در مورد کار تعاونی با پشتیبانی رایانه، سن دیگو، کالیفرنیا، ایالات متحده آمریکا، 8 تا 12 نوامبر 2008.
  40. ویکی OpenStreetMap. ویژگی های نقشه OSM: خلاصه ای از برچسب های رایج برای عناصر اصلی که برای توصیف ویژگی های OSM استفاده می شود. در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Map_Features (در 13 اوت 2012 قابل دسترسی است).
  41. Neis, P. چگونه به OpenStreetMap کمک کردید؟ در دسترس آنلاین: http://hdyc.neis-one.org (در 1 اوت 2012 قابل دسترسی است).
  42. ویکی OpenStreetMap. اسمز . در دسترس آنلاین: http://wiki.openstreetmap.org/wiki/Osmosis (در 11 اوت 2012 قابل دسترسی است).
  43. ویکی پدیا، دایره المعارف آزاد. بغل کن . در دسترس آنلاین: http://en.wikipedia.org/wiki/Wikipedia:Huggle (در 24 سپتامبر 2012 قابل دسترسی است).
  44. مونی، پی. Corcoran, P. خصوصیات اشیاء به شدت ویرایش شده n Op en S TreetMap. اینترنت آینده 2012 ، 4 ، 285-305. [ Google Scholar ] [ CrossRef ]
  45. سوئی، اولین قانون جغرافیای دی. ان Assn. عامر Geogr. 2004 ، 94 ، 269-277. [ Google Scholar ] [ CrossRef ]

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

آموزش کاربردی ArcGISالهام ابراهیم زادهکاربرد جی ای اسکاربردهای GIs در زمین شناسی

بدون نظر

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

همواره حمایت دانشجویان عزیزمان همراه ما بوده و این سببب شده که گامی محکم به‌سوی ایجاد یک مرجع برای آموزش GIS برداریم. با این امید که بتوانیم قدردان حمایت شما بزرگواران باشیم.

  • خانه
  • آموزش
  • فیلم آموزشی
  • تماس با ما
  • درباره ما
  • وبلاگ
  • سمنان /خیابان کاشانی/ساختمان فناوری اطلاعات/پ 8
  • 09120049370