اوسینت جت · خواندن شواهد نقشه

تاریخچه OpenStreetMap در اوسینت؛ مکان عوض شده یا فقط نقشه؟

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

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

از روی نقشه به رکورد همان عارضه برسید

نقشه رنگی، نمایش داده‌هاست. با ابزار پرس‌وجوی عوارض یا نمایش داده‌های OpenStreetMap، رکورد چیزی را که بررسی می‌کنید پیدا کنید. نوع عارضه و پیوند کاملش را نگه دارید. node یک نقطه است، way از دنباله‌ای مرتب از نقطه‌ها ساخته می‌شود و relation چند عنصر را برای یک منظور مشخص کنار هم قرار می‌دهد. مرجع عناصر OSM این ساختار را توضیح می‌دهد.

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

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

پیش از خواندن تاریخ، خود تفاوت را پیدا کنید

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

اطلاعات توصیفی در «تگ»ها ثبت می‌شوند؛ مثلاً نام یا وضعیت دسترسی. هندسه به شکل و موقعیت مربوط است. تغییر یک relation هم ممکن است فقط عضویت عناصر را عوض کرده باشد. اول تفاوت دقیق را یادداشت کنید، بعد توضیح و منبع مجموعه تغییرات را بخوانید. توضیح ویرایش‌کننده به فهم کار کمک می‌کند، ولی تأیید مستقل درستی آن نیست.

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

کدام تاریخ را دارید می‌خوانید؟

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

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

تمرین آلاچیقی که ظاهراً سه بار عوض شده

مثال ساختگی برای تمرین خواندن رکورد. این آلاچیق و تاریخ‌ها به عارضه واقعی در نقشه یا بازدید میدانی ما مربوط نیستند.

• نسخه ۷، دهم مه: غلط املایی نام آلاچیق اصلاح می‌شود. موقعیت ثابت می‌ماند.
• نسخه ۸، دوم ژوئن: پیوند وب‌سایت اضافه می‌شود. نام و هندسه تغییر نمی‌کنند.
• نسخه ۹، هجدهم ژوئن: نقطه عارضه کمی به شرق می‌رود. در توضیح نوشته شده «تنظیم نقطه روی مرکز ساختمان» و منبع، تصویر هوایی معرفی شده است.

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

حالا یک نقطه جدا برای ورودی شرقی اضافه کنید که تاریخش بیستم ژوئن است. فعلاً می‌دانیم ورودی در آن نسخه ثبت شده؛ زمان قابل استفاده شدنش هنوز روشن نیست. اگر سؤال این باشد که «در ماه مه می‌شد از شرق وارد شد؟»، یک اطلاعیه تاریخ‌دار برای بازدیدکننده‌ها یا عکس عمومی با تاریخ مناسب، بیشتر به حل مسئله کمک می‌کند.

پیش از ادامه، نتیجه را برای خودتان در دو جمله بنویسید. نمونه پاسخ دقیق: «نسخه‌های بررسی‌شده، اصلاح اطلاعات نقشه و افزودن رکورد ورودی را نشان می‌دهند. دسترسی از ورودی شرقی در ماه مه با این شواهد مشخص نمی‌شود.» بررسی بعدی باید همان واقعیت تاریخیِ نامعلوم را روشن کند؛ چند ویرایش تازه و بی‌ربط کمکی به آن نمی‌کند.

ناپدید شدن نقطه، الزاماً ناپدید شدن مکان نیست

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

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

اگر از یک عکس شروع کرده‌اید و هنوز عارضه را نمی‌شناسید، ابتدا با روش مکان‌یابی تصویر فرضیه مکانی بسازید. اگر موضوع نشانی شرکت است، راهنمای تفکیک نقش نشانی کمک می‌کند مکان ساختمان را با استقرار واقعی کسب‌وکار اشتباه نگیرید.

ردی بگذارید که نفر بعد بتواند دنبالش کند

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

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