خلاصه

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

کلید واژه ها:

GIS _ Geohash ; کاشی وکتور ; جزوه

1. معرفی

برنامه های کاربردی مبتنی بر اطلاعات جغرافیایی مانند خدمات ناوبری، و خدمات تاکسی الکترونیکی، راحتی زیادی را به زندگی روزمره ارائه می دهند و به افزایش محبوبیت دستگاه های تلفن همراه شخصی کمک می کنند [ 1 ، 2 ]. برای دستیابی به تجربه کاربری بهتر، باید سرعت دسترسی را افزایش داد و در عین حال جلوه های بصری را تضمین کرد (یعنی حفظ اطلاعات قابل توجه).
روش موجود برای یافتن بهترین تعادل بین “سرعت دسترسی” و “اثر بصری” کاهش انتقال داده و بهبود کارایی شاخص با تقسیم، نمایه سازی و فشرده سازی داده های نقشه در مقیاس بزرگ است. اول، عناصر داده‌ای که توسط بیشتر ادبیات منتقل می‌شوند، داده‌های نقشه برداری هستند که مختصات طول و عرض جغرافیایی را حمل می‌کنند [ 2 ، 3 ]. اگر بتوان از کاراکترهای یک بعدی برای نشان دادن مقادیر طول و عرض جغرافیایی استفاده کرد، این یک راه عملی برای کاهش میزان انتقال داده و بهبود کارایی پرس و جو است. دوم، برای اکثر نقشه‌های کاشی، نمایه‌سازی فضایی شبکه‌ای به عنوان یک راه مؤثر برای بهبود دسترسی به داده‌های عظیم در نظر گرفته می‌شود. با این حال، نمایه سازی فضایی شبکه ای از یک پرس و جو سه فیلد استفاده می کند، که آن را در مورد داده های عظیم ناکارآمد می کند [ 4 ]]. سوم، فشرده سازی داده ها باید اطمینان حاصل کند که داده های فشرده شده به طور قابل توجهی جلوه های بصری را خراب نمی کند. روش کوانتیزاسیون داده ها را با کاهش تعداد بیت ها و دقت مختصات با ارزش واقعی فشرده می کند [ 5 ]، که می تواند رابطه توپولوژیکی اشیاء را حفظ کند. با این حال، نحوه انتخاب یک مقیاس کوانتیزاسیون داده معقول مشکلی است که باید هنگام تحقق جلوه های بصری خوب حل شود.
راه حل ما استفاده از کاراکترهای یک بعدی برای نشان دادن مختصات طول و عرض جغرافیایی و بهبود کارایی پرس و جو و دستیابی به فشرده سازی داده ها بدون کاهش قابل توجه جلوه های بصری است. Geohash نیازهای ما را با ویژگی های تک بعدی، راحتی پرس و جو و فشرده سازی داده ها برآورده می کند [ 6 ]. استفاده از Geohash در کاشی های نقشه چالش های زیر را ارائه می کند. چالش 1: استفاده از نمایش های یک بعدی کاراکترها برای طول و عرض جغرافیایی از نظر طرح ریزی نقشه، کار بی اهمیتی نیست. در حال حاضر، نقشه های اصلی جهان، مانند نقشه های گوگل [ 7 ] و نقشه های بینگ مایکروسافت [ 8 ]]، از روش طرح ریزی وب مرکاتور استفاده کنید. این روش حالت طرح ریزی استوانه ای محور مثبت ایزومتریک را اتخاذ می کند و زمین را به عنوان یک کره شبیه سازی می کند که یکی از پرکاربردترین پیش بینی های نقشه وب است [ 9 ]]. با این وجود، این روش های طرح ریزی برای طول و عرض جغرافیایی طراحی شده اند. اگر از کاراکترهای یک بعدی غیر طول و عرض جغرافیایی برای نشان دادن موقعیت مختصات جغرافیایی استفاده شود، نمی توان از این نوع روش استفاده کرد. این مشکل را می توان با یافتن یک روش محاسبه مستقیم بین مختصات یک بعدی و مختصات پیکسل حل کرد. چالش 2: یکپارچه کردن کدگذاری کاشی و هماهنگ کردن نمایش دشوار است. تاکنون نه Google Maps و نه Bing Maps به وحدت کدگذاری کاشی و نمایش مختصات دست پیدا نکرده اند. چالش 3: رویکردهای جدیدی برای دستیابی به پارتیشن بندی داده ها و فشرده سازی داده ها مورد نیاز است. تحقیقات ما در تلاش است تا با هر 3 چالش مقابله کند.
برای بهبود سرعت دسترسی به نقشه برداری و حصول اطمینان از جلوه بصری، این مقاله یک روش جدید نمایش داده های جغرافیایی مبتنی بر Geohash به نام GeohashTile را پیشنهاد می کند که از سیستم رمزگذاری Geohash برای بهبود عملکرد پارتیشن بندی، نمایه سازی و فشرده سازی داده ها استفاده می کند. برای غلبه بر سه چالش ذکر شده در بالا، GeohashTile ما از کاراکترهای یک بعدی Geohash برای پارتیشن بندی و فهرست بندی داده های جغرافیایی در مقیاس بزرگ استفاده می کند. داده های فرمت GeoJSON که توسط Geohash با طول های مختلف رمزگذاری شده اند برای دستیابی به فشرده سازی داده ها استفاده می شوند. روش رمزگذاری Geohash همچنین کدگذاری کاشی و نمایش مختصات را یکسان می کند. ما از روش طرح ریزی موقعیت نسبی برای تحقق تبدیل مستقیم بین مختصات Geohash و صفحه نمایش پیکسل استفاده می کنیم. علاوه بر این، GeohashTile آماده سازی داده های Geohash توسط سرور را نیز در نظر می گیرد.
مشارکت های این اثر به شرح زیر خلاصه می شود:
  • ما یک ساختار داده جغرافیایی برداری بر اساس معماری Geohash به نام GeohashTile طراحی می کنیم که می تواند از پارتیشن بندی کارآمد Geohash و نمایه سازی یک بعدی داده های جغرافیایی برداری برای پرس و جوی آسان استفاده کند.
  • ما از Geohash برای یکسان سازی نمایش مختصات جغرافیایی و رمزگذاری کاشی نقشه، و سازماندهی و ذخیره داده های جغرافیایی برداری با جزئیات و جزئیات مختلف استفاده می کنیم تا زمان پاسخ و انتقال داده های شبکه را کاهش دهیم. با استفاده از طرح ریزی موقعیت نسبی، ما متوجه تبدیل مستقیم مختصات Geohash و صفحه نمایش پیکسل می شویم که محاسبه آن را آسان می کند. همچنین برای کاهش مقدار محاسبات از روش ذخیره سازی نتایج میانی استفاده می کنیم.
  • ما سیستم GeohashTile را بیشتر پیاده سازی می کنیم و آن را با آزمایش های گسترده ارزیابی می کنیم. نتایج نشان می‌دهد که سیستم GeohashTile سرویس کاشی برداری کارآمد را به روشی راحت و کاربرپسند ارائه می‌دهد، که همچنین نشان می‌دهد که سیستم GeohashTile از نظر مقدار انتقال داده و زمان بارگذاری بهتر از سیستم GeoTile عمل می‌کند.
بقیه مقاله به شرح زیر سازماندهی شده است. پیشینه و آثار مرتبط در  بخش 2 بررسی شده است. بخش 3 ایده اصلی چارچوب GeohashTile و پیکربندی سرور را ارائه می دهد. پیکربندی کلاینت شامل فرآیند محاسبه GeohashTile، فرآیند درخواست داده نقشه GeoServer، فرآیند پیش‌بینی داده نقشه Geohash و فرآیند ذخیره‌سازی نتایج میانی در  بخش 4 بررسی می‌شود . بخش 5 عملکرد GeohashTile را با مقایسه آن با کارهای پیشرفته ارزیابی و تجزیه و تحلیل می کند. بخش 6 مقاله ما را با موضوعات بالقوه برای کاوش بیشتر به پایان می رساند.

2. پیشینه و کارهای مرتبط

در این بخش، نقشه برداری و روش های شاخص فضایی درگیر در کاربرد دسترسی سرویس گیرنده وب به داده های نقشه را بررسی و مورد بحث قرار می دهیم. سپس روش رمزگذاری Geohash و GeoServer و Leaflet مورد استفاده توسط سیستم GeohashTile و همچنین مقایسه کارهای مرتبط را معرفی می کنیم.

2.1. نقشه برداری

نقشه‌های داده برداری در حال ظهور هستند زیرا کاربران تلفن همراه خدمات نقشه‌برداری تعاملی و آموزنده بیشتری را می‌طلبند. داده های برداری می توانند ویژگی ها را به درستی در رنگ های مختلف در تمام وضوح ها ارائه و متمایز کنند [ 10 ]. Web Map Tile Service (WMTS) [ 11 ] می تواند برای حل مشکلات توزیع ناهموار و تأخیر طولانی انتقال داده های برداری استفاده شود، که همچنین استاندارد خدمات نقشه برای خدمات نقشه وب (WMS) [ 12 ] است.] و تکنولوژی هرمی. در چارچوب WMTS، نقشه ها به تصاویری به نام کاشی تقسیم می شوند که با توجه به منطقه درخواستی، می توان آنها را به مشتری منتقل کرد. کاشی ها با استفاده از مختصات مربوطه خود در سمت مشتری دوباره مونتاژ می شوند. رمزگذاری داده های برداری نیز یک عامل حیاتی است که بر عملکرد انتقال و قابلیت استفاده مجدد آن تأثیر می گذارد. XML و JSON دو روش رمزگذاری داده برداری هستند که معمولاً در برنامه های کاربردی وب استفاده می شوند [ 13 ]. XML (Extensible Markup Language) [ 14 ] یک زبان نشانه گذاری است که به عنوان استاندارد برای تبادل اطلاعات اینترنتی استفاده می شود. معنایی و توسعه پذیری خوبی دارد و می تواند داده ها را به طور انعطاف پذیر نشان دهد و سازماندهی کند. GML (زبان نشانه گذاری جغرافیایی) [ 15 ] و KML (زبان نشانه گذاری سوراخ کلید) [ 16 ]] دو روش رمزگذاری مبتنی بر XML هستند. حالت KML مختصرتر است، در حالی که GML عملکردهای پیشرفته ای را برای توصیف نقشه های پیچیده ارائه می دهد. از آنجایی که XML از یک دستور زبان سنگین استفاده می کند، اندازه KML و GML معمولاً بزرگتر و پیچیده تر هستند که برای انتقال داده ها در اینترنت مفید نیستند [ 17 ]. JSON (JavaScript Object Notation) یک فرمت نمایش داده سبک وزن است که خواندن و نوشتن آن آسان است و به سرعت و کارآمد قابل حل است. GeoJSON [ 18] یک فرمت استاندارد باز برای رمزگذاری ساختارهای داده های جغرافیایی مختلف است که می تواند برای نشان دادن ویژگی های جغرافیایی ساده مانند هندسه، ویژگی یا FeatureCollection و ویژگی های آنها استفاده شود. در مقایسه با GML و KML، GeoJSON می‌تواند توسط کامپیوتر راحت‌تر و سریع‌تر تجزیه شود و می‌تواند ساختارهای داده پیچیده را با خوانایی خوب توصیف کند [ 19 ]. GeoJSON به عنوان یک روش رمزگذاری داده سبک وزن برای انتقال داده بین دستگاه های تلفن همراه مناسب است [ 20 ]. TopoJSON توسعه GeoJSON برای کدگذاری توپولوژی [ 21]. قوس هدایت شده TopoJSON فقط یک بار ثبت می شود و مختصات جغرافیایی به جای اعداد ممیز شناور به عنوان اعداد صحیح استفاده می شود. بنابراین، در مقایسه با GeoJSON، TopoJSON افزونگی را حذف می‌کند، اما استقلال شی اصلی را از بین می‌برد و مختصات برای استفاده نیاز به رمزگشایی دارند، که برای تجزیه و تحلیل داده‌ها و اشتراک‌گذاری مناسب نیست [ 2 ].
برای داده های نقشه برداری، فناوری هرمی هنوز یک روش سازماندهی موثر است که نقشه کاشی برداری نامیده می شود. با توجه به عملکرد انتقال، خوانایی و تحلیل آسان روش رمزگذاری، GeoJSON را به عنوان روش رمزگذاری داده های برداری برای دستگاه های تلفن همراه انتخاب کردیم.

2.2. فناوری شاخص فضایی

فناوری شاخص فضایی، فناوری کلیدی برای بهبود کارایی پرس و جوی عظیم داده های مکانی است. استفاده از یک شاخص فضایی برای مدیریت و نگهداری هرم کاشی ارزش کاربردی مهمی دارد و عملکرد آن به طور مستقیم بر عملکرد کلی خدمات شبکه اطلاعات جغرافیایی تأثیر می گذارد. شاخص شبکه و شاخص چهاردرختی روش‌های نمایه‌سازی فضایی پرکاربرد در مدل هرم کاشی هستند [ 22 ، 23 ، 24 ].
شاخص شبکه یک آرایش شبکه مستطیلی است که خطوط جغرافیایی را بر اساس سطح تفکیک مشخصی تقسیم می کند [ 4 ]. روش شاخص شبکه ای مستلزم آن است که هنگام پرس و جو از هر کاشی در هرم، فقط باید سه مقدار را که X ، Y و Z به ترتیب نشان دهنده ردیف ها، مختصات ستون ها و سطوح مقیاس بندی هستند، به صورت پیوسته جستجو کرد. گرید ایندکس یکی از قدیمی ترین روش های نمایه سازی است و شکل ساده ای دارد. با این حال، پرس و جو سه فیلد نیز آن را در مورد داده های عظیم ناکارآمد می کند.
شاخص چهار درختی مبتنی بر هرم به نام هر یک از گره های داخلی آن با چهار گره فرعی نامگذاری شده است که یک روش نمایه سازی رایج برای نقشه های آنلاین با وضوح چندگانه است. روش نمایه سازی مزایای کدگذاری ساده و پیاده سازی آسان را دارد و توسط اکثر ارائه دهندگان خدمات نقشه شبکه بزرگ از جمله Google Maps [ 7 ] و Microsoft Bing Maps [ 8 ] اتخاذ شده است. Google Maps به همان روشی که فهرست گرید ایندکس می شود، فهرست می شود. سه زمینه از (ایکس،y،z)برای نشان دادن مقادیر شاخص کاشی استفاده می شود. بنابراین، این مشکل نیز وجود دارد که کوئری داده انبوه ناکارآمد است. نقشه های بینگ از دو فیلد استفاده می کند (z،qتوآدکهyس)برای نشان دادن مقدار شاخص کاشی، که در آن کلیدهای چهارگانه، به نام کلیدهای چهار درختی، شاخص و ذخیره سازی را با ترکیب بلوک دو بعدی بهینه می کنند. ایکسYبا ترکیب متقاطع بیتی به یک رشته تک بعدی تبدیل می شود. وان و همکاران [ 25 ] از روش‌های پرس و جوی کاشی دو سطحی، یعنی یک محدوده نقشه برداری بزرگ (شبکه نقشه جهانی) و حوزه فرعی استفاده می‌کند. شاخص چهار درختی در هر دو پرس و جو دو سطحی برای بهبود کارایی شاخص استفاده شد، اما کار گسترش منطقه کاشی را افزایش داد.
روش شاخص Geohash یک بلوک در لایه M را به n بلوک در لایه تقسیم می کندم+1، بنابراین آن نیز یک روش شاخص چهار درختی است. در مقایسه با ساختار شاخص رایج، Geohash هیچ ساختار بازگشتی ندارد، بنابراین شاخص فضایی تنها یک سطح دارد و به روز رسانی های پویا را کمتر پیچیده می کند [ 22 ]. در حال حاضر، Geohash به طور گسترده ای برای پردازش داده های مکانی با شاخص تک بعدی استفاده شده است [ 6 ، 22 ، 26 ، 27 ].

2.3. رمزگذاری Geohash

رمزگذاری Geohash طول و عرض جغرافیایی را به ترتیب به مجموعه‌ای از رشته‌های باینری تبدیل می‌کند و سپس این دو مجموعه از رشته‌ها را بیت به بیت برای تولید مجموعه جدیدی از رشته‌های باینری عبور می‌دهد. دنباله مربوط به ارقام زوج در رشته های باینری، دنباله طول جغرافیایی است و دنباله مربوط به ارقام فرد، دنباله عرض جغرافیایی است. رشته جدید به اعشار تبدیل شده و مطابق با base32 کدگذاری می شود (یعنی محدوده مقادیر 32 کاراکتر از عدد 0-9 و حرف b – z (به استثنای a , i , l , o )) است که می توان از آن استفاده کرد. برای نشان دادن آرایه های دو بعدی با آرایه های یک بعدی [ 22]. هنگامی که Geohash برای اولین بار یک نقشه را تقسیم می کند، طول جغرافیایی به 8 بخش تقسیم می شود (23=8)، و عرض جغرافیایی به 4 بخش تقسیم می شود (22=4)، که 32 را تشکیل می دهد (8×4)مناطق پس از آن، هر منطقه به طور متناوب به تقسیم می شود 4×8یا 8×4مناطق با توجه به تغییر متناوب بیت های برابری، که با توجه به منحنی مرتبه Z نمایه می شوند [ 27 ]. فرآیند تقسیم Geohash در  شکل 1 نشان داده شده است .
در مقایسه با روش رمزگذاری Google Maps، Geohash کوئری های فضایی دو بعدی را به تطبیق رشته های یک بعدی تبدیل می کند. با این مزیت، Geohash می تواند به پرس و جو سریع با پیچیدگی زمانی دست یابد O(1)[ 22 ]. در مقایسه با روش رمزگذاری نقشه های بینگ، رمزگذاری Geohash همچنین از رمزگذاری طول و عرض جغرافیایی برای عبور بیت و ادغام در یک ذخیره سازی توالی استفاده می کند. تفاوت این است که Geohash از روش رمزگذاری Base32 استفاده می کند، یعنی 32 زیر دنباله مختلف تحت یک پیشوند وجود دارد، در حالی که روش رمزگذاری Bing Maps Base4 است، یعنی تنها 4 زیر دنباله مختلف زیر یک پیشوند وجود دارد، بنابراین Geohash پرس و جو راحت تر است. ادبیات [ 22] همچنین نشان می دهد که الگوریتم نمایه سازی فضایی مبتنی بر Geohash دارای قابلیت پرس و جو با کارایی بالا برای داده های جغرافیایی عظیم است. در حال حاضر، محصولات اصلی نقشه، مانند نقشه های گوگل و بینگ مپ، نمایش طول و عرض جغرافیایی موقعیت های مختصات داده های جغرافیایی را اتخاذ می کنند، در حالی که شاخص روش دیگری را اتخاذ می کند. با توجه به طول رمزگذاری مختلف، Geohash می تواند محدوده شاخص و مختصات کاشی ها را به طور همزمان نشان دهد، که می تواند رمزگذاری یکپارچه را تحقق بخشد.

2.4. GeoServer و Leaflet

GeoServer [ 28 ] به عنوان یک سرور webGIS که به طور گسترده مورد استفاده قرار می گیرد، عملکردهای ایجاد، ذخیره، مدیریت و استفاده از داده های جغرافیایی را دارد که می تواند به راحتی و به سرعت خدمات اطلاعات جغرافیایی را ایجاد کند و به اشتراک گذاری سریع اطلاعات جغرافیایی مکانی بین کاربران را تحقق بخشد. GeoServer یک سرور شبکه اطلاعات جغرافیایی منبع باز است که بر اساس جاوا توسعه یافته است. این بر اساس قابلیت همکاری توسعه یافته است و از هر منبع داده ای با استفاده از فرمت استاندارد باز پشتیبانی می کند. این استاندارد با OGC (کنسرسیوم فضایی باز)، WFS (سرویس ویژگی های وب) و WCS (سرویس پوشش وب) مطابقت دارد و WMS (سرویس نقشه وب) سازگار با کارایی بالا را ارائه می دهد.
GeoServer یک سرور بالغ‌تر از ncWMS [ 29 ] است، با مستندات بهتر، که به کاربران اجازه می‌دهد به راحتی فرمت خروجی سرویس ویژگی وب را تغییر دهند (که توسط ویژگی هویت استفاده می‌شود)، و ویژگی‌های اضافی برای لایه برداری، مانند CQL فراهم می‌کند. فیلتر کردن (Contextual Query Language) یا امکان درخواست داده در قالب JSON [ 30 ]. به این دلایل، ما GeoServer را برای ارائه داده های GeoJSON کدگذاری شده توسط Geohash انتخاب کردیم.
Leaflet [ 31 ] یکی از کتابخانه های منبع باز جاوا اسکریپت برای نقشه است که یک نرم افزار منبع باز پرکاربرد در پروژه توسعه WebGIS در سمت B/S است. توسعه دهندگان می توانند بر اساس رابط ارائه شده توسط کتابخانه توسعه و گسترش دهند و فراخوانی خدمات اطلاعات جغرافیایی و عملیات اساسی داده های نقشه را درک کنند [ 32 ].
پلاگین های منبع باز کتابخانه قدرتمند Leaflet شامل تمام جنبه های برنامه های کاربردی نقشه، از جمله خدمات نقشه، ارائه داده ها، فرمت داده ها، رمزگذاری جغرافیایی، جستجوی مسیر، کنترل نقشه و تعامل و غیره است و همچنین از اجرای کنترل های سفارشی پشتیبانی می کند. این کنترل ها عملکردهای Leaflet [ 33 ] را غنی می کنند. این مقاله بر اساس جزوه کتابخانه WebGIS سبک وزن برای تکمیل عملکرد است.

2.5. مقایسه کارهای مرتبط

برای ارائه دیدگاه روشنی در مورد روش‌های مختلف برای نمایش داده‌های جغرافیایی برداری در ادبیات، آنها را از پنج جنبه نمایش مختصات، روش نمایه‌سازی، روش طرح‌ریزی، ذخیره‌سازی نتایج میانی و دامنه کاربرد مقایسه می‌کنیم. کش کردن نتیجه میانی به حافظه پنهان نمایش موقعیت نسبی اشاره دارد که در  بخش 4 به تفصیل توضیح داده شده است . ما چندین روش نمایش داده های جغرافیایی بردار جدید و معرف را برای مقایسه انتخاب می کنیم و نتایج مقایسه در  جدول 1 نشان داده شده است. از نظر نمایش مختصات، تقریباً همه آنها با طول و عرض جغرافیایی نشان داده می شوند. از نظر روش های نمایه سازی، به جز حالت شاخص معکوس که توسط زوهر و همکاران اتخاذ شده است. [ 9]، تمام متدهای دیگر به حالت چهار درختی تعلق دارند. با این حال، با توجه به روش‌های رمزگذاری مختلف، انواع مختلفی از حالت‌های چهاردرختی وجود دارد: از منظر روش طرح ریزی، به جز روشی که به صراحت در مقاله ذکر نشده است، بقیه از طرح‌بندی وب Mercator استفاده می‌کنند. تا آنجایی که به کش کردن نتایج میانی مربوط می شود، از آنجایی که هیچ روش طرح ریزی موقعیت نسبی در این روش ها استفاده نمی شود، هیچ تابعی شامل ذخیره سازی نتیجه میانی موقعیت نسبی وجود ندارد. از دامنه کاربرد، به جز زوهر و همکاران. که فقط برای داده های چند ضلعی قابل استفاده است و راموس و همکاران. [ 24 ]، که فقط برای داده های خطوط چند ضلعی قابل استفاده است، روش های دیگر برای همه داده های نقشه برداری پایه اعمال می شود.
سیستم GeohashTile ما از GeoServer برای راه‌اندازی محیط داده سرور استفاده می‌کند و داده‌های GeoJSON را ارائه می‌کند که توسط Geohash فهرست‌بندی و کدگذاری می‌شوند. ما از Leaflet به عنوان مبنایی برای ارائه داده های مشتری برای پیاده سازی محاسبه GeohashTile و پیش بینی داده های نقشه Geohash استفاده می کنیم. همانطور که در  بخش 1 بحث شد ، چالش های زیادی برای دستیابی به این اهداف وجود دارد. در ادامه معماری سیستم GeohashTile را به تفصیل توضیح خواهیم داد.

3. معماری سیستم GeohashTile و طراحی سمت سرور

در این بخش، ما بر روی دسترسی به داده های نقشه با استفاده از دستگاه های تلفن همراه در سیستم GeohashTile تمرکز می کنیم و ساختار کلی GeohashTile و پیکربندی سرویس داده سرور را توضیح می دهیم.

3.1. نمای کلی معماری

سیستم GeohashTile از دو بخش تشکیل شده است: سمت سرور و سمت مشتری. سمت سرور سرویس داده های جغرافیایی برداری را ارائه می دهد و سمت مشتری نمایش داده های جغرافیایی برداری Geohash را تکمیل می کند، از جمله فرآیند محاسبه GeohashTile، فرآیند درخواست داده های نقشه سرور، فرآیند طرح ریزی داده های نقشه Geohash و فرآیند ذخیره سازی نتایج میانی. . شکل 2  چارچوب عملکردی سیستم GeohashTile را نشان می دهد.
کار سرور به دو بخش تقسیم می شود: تبدیل داده های جغرافیایی برداری Geohash و سرویس داده های جغرافیایی برداری Geohash. تبدیل داده مسئول تبدیل مختصات طول و عرض جغرافیایی مجموعه داده های GeoJSON اصلی به داده های قالب GeoJSON رمزگذاری شده Geohash با طول مشخص مربوط به سطح بزرگنمایی و سازماندهی مجدد داده ها به داده های فرمت GeoJSON برای دسترسی مشتری است، که همچنین تعریف می کند. رابط دسترسی به داده و تنظیم دقیق داده ها. پس از دریافت درخواست HTTP ارسال شده توسط مشتری، بخش سرویس داده فیلدها را تجزیه می کند، داده های GeoJSON رمزگذاری شده Geohash مربوطه را پرس و جو می کند و آن را از طریق پاسخ HTTP به مشتری باز می گرداند، جایی که سرویس داده های جغرافیایی برداری رمزگذاری شده Geohash توسط یک GeoServer ارائه می شود. وب سرور مبتنی بر به عنوان یک سرور نقشه معمولی،34 ] به داده های کاشی برای استفاده توسط سرویس گیرندگان وب. سرور نقشه مبتنی بر GeoServer از چهار ماژول اصلی تشکیل شده است، یعنی سرور HTTP Apache، سیستم کش، وب سرور مبتنی بر GeoServer و ماژول ذخیره سازی داده مبتنی بر PostgreSQL. برای تنظیمات خاص، لطفاً به ادبیات [ 2 ] مراجعه کنید.
کار طرف مشتری به شرح زیر است. در فرآیند محاسبه GeohashTile، اولین مرحله محاسبه اندازه GeohashTile مربوط به سطح زوم z است که به نام (gس_ایکس،gس_y). مرحله دوم محاسبه تعداد GeohashTile است که محدوده صفحه را پوشش می دهد، نامگذاری شده است (gتی_ایکس،gتی_y). علاوه بر این، مرحله سوم محاسبه همسایه GeohashTile از مرکز GeohashTile است تا صف GeohashTile به دست آید، همزمان دو صف که از موقعیت نقطه مرکزی و نقطه مرکزی پیکسل نسبی هر قطعه تشکیل می شود محاسبه می شود که به آنها می گویند. gج_qتوهتوهو  gجپ_qتوهتوه. در فرآیند درخواست داده های نقشه از سرور، قبل از ارسال درخواست، ابتدا باید ادغام درخواست تکمیل شود. سپس مشتری ایندکس GeohashTile را ارسال می کند جیهoساعتآسساعت_منnدهایکسو زوم سطح z از طریق درخواست HTTP برای درخواست داده های نقشه، و در نهایت داده های GeoJSON که توسط سرور برگردانده شده است را دریافت می کند. فرآیند طرح ریزی موقعیت نسبی ابتدا لیست فاصله نسبی پیکسل را محاسبه می کند جoorد_دمنس_لمنستیاز لیست مختصات جیهoساعتآسساعت_لمنستیاز اشیاء هندسی در هر GeohashTile به صف نقطه مرکزی gج_qتوهتوه، و سپس موقعیت مختصات صفحه را محاسبه می کند پoمنnتی_لمنستیبه صف نقطه مرکز پیکسل نسبی gجپ_qتوهتوه. فرآیند ذخیره سازی نتایج میانی برای ذخیره نتایج محاسبه موقعیت نسبی و کاهش مقدار محاسبات تکراری است. از طریق چهار مرحله فوق، ما یک تبدیل مستقیم بین مختصات Geohash و صفحه نمایش را بر روی مشتری پیاده سازی کرده ایم. شایان ذکر است که سه مرحله اول فقط باید در حین مقداردهی اولیه محاسبه شوند، که نیازی به محاسبه مکرر در هنگام کشیدن در محدوده کوچک نیست.

3.2. طراحی سمت سرور

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

3.2.1. تبدیل مختصات Geohash و پیکربندی رابط

سرور باید داده های نقشه GeoJSON را بر اساس نام GeohashTile و سطح زوم z درخواست شده توسط سرویس گیرنده وب برگرداند. شکل 3 مقایسه ای از فرآیند داده تهیه GeoJSON اصلی و داده GeoJSON رمزگذاری شده Geohash توسط سرور است. ما عمدتاً تبدیل مختصات Geohash و پیکربندی رابط دسترسی به داده، از جمله تبدیل نام GeohashTile و رمزگذاری طول و عرض جغرافیایی شیء هندسی را تکمیل کردیم. در آینده، تمام نمایش های موقعیتی داده های نقشه برداری روی سرور را می توان به Geohash تبدیل کرد، به طوری که Geohash به طور کامل به عنوان نمایش منحصر به فرد مختصات استفاده می شود.
فرآیند آماده سازی داده های GeoJSON در سمت سرور:
  • پرس و جو داده های کاشی. همانطور که در مرحله ② شکل 3 نشان داده شده است ، سرور عملکرد ذخیره سازی سیستم فایل را فراهم می کند، به عنوان مثال، تمام داده های کاشی پرس و جو ذخیره می شوند. در مقایسه با پرس و جو از سه فیلد x ، y ، z ( x ، y نشان دهنده رمزگذاری کاشی و z نشان دهنده سطح بزرگنمایی است) در پردازش داده های GeoJSON اصلی، پردازش داده های GeoJSON رمزگذاری شده Geohash فقط به پرس و جو نیاز دارد. دو زمینه از gهoساعتآسساعتو z ، و بنابراین کارایی پرس و جو افزایش می یابد.
  • تبدیل نام کاشی همانطور که در مرحله ④ شکل 3 نشان داده شده است ، هر دو GeoTile و GeohashTile باید فیلد درخواستی به دست آمده از مشتری، یعنی نام کاشی، را به یک جفت نقطه طول و عرض جغرافیایی رمزگشایی کنند. (لong1،لong2،لآتی1،لآتی2)نشان دهنده ناحیه مستطیلی که کاشی در هنگام ورود به مرحله درخواست داده سرور قرار دارد. دو مورد از تبدیل نام GeohashTile با توجه به وجود درخواست ادغام شده برای GeohashTile وجود دارد: یکی این است که وقتی ادغام وجود ندارد، مشتری هر بار یک GeohashTile درخواست می کند و فرآیند تبدیل نام به فرآیند رمزگشایی در  بخش 2.3 اشاره دارد . مورد دیگر این است که وقتی درخواست ادغام می شود، هر بار که مشتری درخواست را تحویل می دهد، دو رشته Geohash در گوشه سمت چپ بالا و گوشه سمت راست پایین ناحیه درخواست وجود دارد. این فرآیند رمزگشایی در  بخش 4.2 توضیح داده خواهد شد .
  • به دست آوردن داده های نقشه طول و عرض جغرافیایی. همانطور که در مرحله ⑤ شکل 3 نشان داده شده است، می‌توانیم جسم هندسی را که با طول و عرض جغرافیایی در ناحیه مستطیلی نشان داده شده است، بدست آوریم. در این مرحله دو روش جمع آوری داده ها یکسان هستند. از آنجایی که نقشه برداری ذخیره شده در سرور همچنان از طول و عرض جغرافیایی برای نشان دادن مکان اجسام هندسی استفاده می کند، لازم است نقشه طول و عرض جغرافیایی قبل از تبدیل بعدی به دست آید. مانند اکثر نیازهای خدمات نقشه آنلاین، سیستم ما نیز از ایده LoD (سطح جزئیات) پیروی می کند. با افزایش سطح زوم، اشیاء هندسی دانه‌دار بیشتری در کاشی وجود دارد. قوانین به GeoTile اشاره دارد. به عنوان مثال، اشیاء هندسی با دسته به عنوان بزرگراه و نوع به عنوان اصلی زمانی نمایش داده می شوند که سطح بزرگنمایی 13 تا 17 باشد. در حالی که اشیاء هندسی با دسته به عنوان رفاه و نوع به عنوان بیمارستان فقط در سطح زوم 15-17 ظاهر می شوند.
  • تبدیل مختصات شیء هندسی. همانطور که در مرحله ⑥ از شکل 3 نشان داده شده است ، این مرحله برای GeohashTile منحصر به فرد است. مختصات طول و عرض جغرافیایی بدست آمده از جسم هندسی (مثلاً  (لon1،لآتی1)،(لon2،لآتی2)،⋯) در مختصات Geohash کدگذاری می شوند (به عنوان مثال، gهoساعتآسساعت1،gهoساعتآسساعت2،⋯) با توجه به فرآیند رمزگذاری معرفی شده در  بخش 2.3 .
  • سازماندهی در قالب GeoJSON. همانطور که در مرحله ⑦ شکل 3 نشان داده شده است، هدف بازگرداندن داده های GeoJSON کدگذاری شده توسط طول و عرض جغرافیایی یا Geohash به مشتری است. شکل 4 مجموعه ای از اشیاء GeoJSON را نشان می دهد که توسط Geohash کدگذاری شده اند. در مقایسه با دریافت مستقیم داده‌های GeoJSON اصلی، زمانی که سرور GeoJSON کدگذاری شده توسط Geohash را ارائه می‌کند، فرآیند تبدیل مختصات طول و عرض جغرافیایی اجسام هندسی به Geohash اضافه می‌شود. از آنجایی که این فرآیند تنها یک بار در هنگام درخواست داده برای اولین بار اجرا می شود، دسترسی بعدی مستقیماً از حافظه پنهان بدون سربار محاسباتی بیش از حد خوانده می شود.
پیکربندی رابط دسترسی به داده:
GeoServer روشی برای انتشار کاشی های برداری ارائه می دهد اما روشی برای انتشار GeohashTile ارائه نمی دهد. برای دستیابی به نیاز دسترسی به داده‌های GeoJSON کدگذاری‌شده توسط Geohash از طریق URL، آپاچی همچنین باید یک رابطه نقشه‌برداری جدید از داده‌های GeohashTile اضافه کند و Geohash را به عنوان h علامت‌گذاری کند. با افزودن یک رابطه نقشه برداری جدید، سرویس گیرنده وب می تواند به داده های GeoJSON کدگذاری شده توسط Geohash دسترسی داشته باشد. فرمت دسترسی آن “ ⋯/ساعت/z/gهoساعتآسساعتتیمنله“، جایی که z نشان دهنده سطح بزرگنمایی نقشه است.
3.2.2. تنظیم دقیق داده ها

Geohash بسته به طول رمزگذاری می تواند پوشش های مختلفی را نشان دهد. به طور مشابه، ما همچنین می‌توانیم طول‌های مختلف رمزگذاری Geohash را با توجه به سطح بزرگ‌نمایی نقشه انتخاب کنیم تا به دانه‌بندی متفاوت اجسام هندسی، یعنی تنظیمات دقیق داده، دست یابیم. بنابراین، مقدار ذخیره سازی داده ها کاهش می یابد در حالی که دقت مختصات صفحه-پیکسل داده های نقشه کاهش نمی یابد. معادله محاسبه گستره طول و عرض جغرافیایی پوشش ژئوهش می تواند روش رمزگذاری ژئوهش را با گرفتن یک چهارم یا هشتم محدوده طول و عرض جغرافیایی به طور متناوب با روش محاسبه سطح زوم و محدوده پوشش کاشی در [ 34 ] ترکیب کند، همانطور که نشان داده شده است. در معادله ( 1 )، جایی که iطول رمزگذاری Geohash است. مقادیر طول و عرض جغرافیایی شی هندسی

لonمن=45درجهمن=1لonمن-1/4من=2ک،ک≥1لonمن-1/8من=2ک+1،ک≥1لآتیمن=45درجهمن=1لآتیمن-1/8من=2ک،ک≥1لآتیمن-1/4من=2ک+1،ک≥1

مختصات در OpenStreetMap به 7 رقم اعشار می رسد. با توجه به رابطه ( 1 )، زمانی که طول رمزگذاری Geohash 14 بایت باشد، محدوده طول و عرض جغرافیایی که نشان دهنده آن است. 0.00000001∘ ×  0.000000005∘. بنابراین، ما Geohash 14 بایتی را برای رمزگذاری مختصات شی هندسی با بالاترین دقت انتخاب کردیم. جدول 2 نتایج آماری مقادیر طول و عرض جغرافیایی شی هندسی را در OSM و مقادیر طول و عرض جغرافیایی رمزگشایی 14 بایتی Geohash را نشان می دهد که همگی 7 رقم اعشار حفظ می شوند. محدوده طول و عرض جغرافیایی در چهار منطقه سنگاپور، هاینان، پکن و هیلونگجیانگ انتخاب شده است. جدول 2نشان می دهد که دقت طول و عرض جغرافیایی پس از رمزگشایی Geohash تحت این شرایط 100٪ است. لطفاً توجه داشته باشید که در اینجا نتایج فشرده سازی داده های Geohash با بالاترین طول و عرض جغرافیایی به دست می آید. در بخش بعدی، فشرده سازی داده ها را تحت شرایط مختلف دقت در ارتباط با محاسبه GeohashTile بررسی خواهیم کرد.

4. نمایش داده های مشتری

سمت سرور برای داده ها آماده است و برای تکمیل کار نمایش نیاز به همکاری سمت مشتری دارد. در این بخش، نشان خواهیم داد که چگونه مشتری می تواند فرآیند نمایش داده های جغرافیایی برداری Geohash را تکمیل کند، همانطور که در  شکل 5 نشان داده شده است.، شامل چهار بخش. (1) فرآیند محاسبه GeohashTile شامل سه مرحله است: محاسبه اندازه یک قطعه GeohashTile، محاسبه تعداد GeohashTile در مشتری و محاسبه تمام رمزگذاری GeohashTile در مشتری. (2) فرآیند ادغام درخواست های داده های نقشه ارسال شده به سرور، به طور خاص، ما می توانیم از الگوریتم ادغام درخواست GeohashTile برای تحقق بخشیدن به ادغام درخواست های ارسالی استفاده کنیم. (3) فرآیند طرح ریزی موقعیت نسبی شامل فشرده سازی داده ها، محاسبه فاصله پیکسل و محاسبه مختصات صفحه نمایش در سه مرحله است. (4) فرآیند ذخیره‌سازی نتیجه میانی، فرآیند کاهش محاسبات مکرر با ذخیره کردن فاصله پیکسل کاشی و فاصله پیکسل مختصات در دو محاسبه موقعیت نسبی است. در ادامه به ترتیب به معرفی این چهار قسمت می پردازیم.

4.1. فرآیند محاسبه GeohashTile

فرآیند محاسبه GeohashTile فرآیند محاسبه تعداد GeohashTile تحت پوشش در محدوده صفحه و دنباله GeohashTile طول رمزگذاری متناظر با موقعیت مرکز داده شده است. جهnتیهr_gهoساعتآسساعت، سطح زوم z و اندازه صفحه نمایش مشتری جلمنهnتیاسمنzه.

4.1.1. محاسبه اندازه یک قطعه GeohashTile

همانطور که در مرحله ① در  شکل 5 نشان داده شده است. در سیستم GeoTile، شاخص کاشی از اصل چهار درخت پیروی می کند. در هر سطح بزرگ‌نمایی، از معادله ( 2 ) برای محاسبه تعداد کدگذاری کاشی در  جهت‌های محور x و  y مختصات کاشی استفاده می‌شود، جایی که z سطح بزرگ‌نمایی است.

nتومتر_ایکس=2zz≥1nتومتر_y=2zz≥1

یک بایت از رمزگذاری Geohash یک تقسیم را نشان می دهد و یک منطقه به طور متناوب به تقسیم می شود 4×8یا 8×4مناطق فرعی با توجه به تناوب بایت های فرد و زوج رمزگذاری. معادله محاسبه برای تعداد رمزگذاری GeohashTile در جهت محور x و y مختصات کاشی پس از هر تقسیم، معادله ( 3 ) است، که در آن l طول رمزگذاری Geohash است.

nتومتر_g_ایکس=8(ل+1)/2×4ل/2ل≥1nتومتر_g_y=8ل/2×4(ل+1)/2ل≥1

هنگامی که تقسیم ژئوهش با سطح زوم در سیستم GeoTile مرتبط است، باید از این اصل پیروی کرد که یک کاشی می تواند یک کاشی ژئوهش کامل را بپوشاند (پوشاندن تنها بخشی از یک کاشی ژئوهش مجاز نیست) و آن را بپوشاند. با کوتاه ترین طول رمزگذاری Geohash برای کاهش ذخیره سازی. بنابراین، معادلات ( 2 ) و ( 3 ) را ترکیب می کنیم تا رابطه ( 4 ) رابطه بین طول رمزگذاری Geohash l و سطح زوم z را به دست آوریم و نتیجه محاسبه l کوچکترین عدد صحیح را می گیرد.

8(ل+1)/2×4ل/2≥2zل≥1،z≥18ل/2×4(ل+1)/2≥2zل≥1،z≥1

صرف نظر از Google Map، Bing Map، یا سایر سیستم های نمایش اطلاعات جغرافیایی، کاشی های هر لایه اندازه پیکسل ثابتی دارند (متداول ترین اندازه پیکسل کاشی 256×256). همانطور که از مطالب بالا مشخص است، اندازه کاشی هر لایه Geohash یکسان است و اندازه کاشی بین هر سطح به طور منظم با قوانین تقسیم تغییر می کند. با توجه به اندازه تقسیم ناسازگار جهت x و y ، کاشی Geohash بیشتر مستطیل شکل است. برای تقریبی GeohashTile به اندازه پیکسل مربع از 256×256در هر سطح و تسهیل محاسبه، اندازه پیکسل GeohashTile در سطح زوم 0 تنظیم می شود.  512×512. همراه با نتایج محاسباتی معادله ( 4 )، اندازه GeohashTile تحت سطح زوم مربوطه z را می توان با معادله ( 5 ) محاسبه کرد. در معادله ( 5 )، z سطح زوم، و l طول رمزگذاری Geohash است. از آنجایی که قوانین تقسیم Geohash در جهات x و y ناسازگار هستند، برای تکمیل محاسبه به دو معادله مختلف نیاز است.

gس_ایکس=(512×2z)/(4ل/2×8(ل+1)/2)z≥1،ل≥1gس_y=(512×2z)/(4(ل+1)/2×8ل/2)z≥1،ل≥1

جدول 3 اندازه پیکسل GeohashTile را نشان می دهد که با معادله ( 5 ) محاسبه شده است، جایی که سطح بزرگنمایی 1-18 است. علاوه بر توانایی محاسبه اندازه پیکسل GeohashTile با طول های مختلف رمزگذاری، از معادله ( 5 ) برای محاسبه مختصات صفحه-پیکسل تبدیل نقطه مختصات Geohash نیز استفاده می شود.
4.1.2. محاسبه تعداد GeohashTile در مشتری

پس از به دست آوردن اندازه GeohashTile در سطح بزرگنمایی مربوطه، تعداد GeohashTile پوشش داده شده در صفحه را می توان با ترکیب اندازه پیکسل مشتری محاسبه کرد تا برای به دست آوردن داده های نقشه مربوطه از سرور آماده شود (همانطور که در مرحله ② نشان داده شده است.  شکل 5 ). معادله ( 6 ) معادله ای برای محاسبه تعداد رمزگذاری GeohashTile در  جهت های محور x و محور  Y مختصات کاشی است، که در آن سمنzه.ایکس، سمنzه.yاندازه پیکسل های صفحه مشتری هستند.

gتی_ایکس=⌈سمنzه.ایکس/gس_ایکس⌉gتی_y=⌈سمنzه.y/gس_y⌉

برای اطمینان از اینکه پوشش صفحه توسط GeohashTile پوشانده شده است، نتیجه محاسبه گرد می شود. به همین دلیل است که پوشش GeohashTile نشان داده شده در  شکل 5 فراتر از صفحه نمایش است.
4.1.3. محاسبه تمام رمزگذاری GeohashTile در مشتری

برای دریافت داده های نقشه مربوطه از سرور، باید تمام رمزگذاری GeohashTile را در پوشش صفحه محاسبه کنیم (همانطور که در مرحله ③ در  شکل 5 نشان داده شده است ). از آنجایی که رمزگذاری GeohashTile نقطه مرکزی داده شده است، با شروع از اطراف نقطه مرکزی، می توانیم همسایه GeohashTile را محاسبه کنیم. جهnتیهr_gهoساعتآسساعتتیمنله. طبق الگوریتم جستجوی همسایه Geohash، جستجوی همسایه را می توان به دو گروه همسایه چپ و راست و همسایه های بالا و پایین تقسیم کرد. شروع از  جهnتیهr_gهoساعتآسساعتتیمنلهموقعیت، gتی_ایکسهمسایه چپ و راست غیر تکراری gجسجستجو می شوند و سپس gتی_yهمسایه های بالا و پایین غیر تکراری GeohashTile در  gجسهمچنین جستجو می شوند، با تمام داده های همسایه ذخیره شده در  gهoساعتآسساعتتیمنله_qتوهتوه. برای تسهیل در محاسبه بعدی موقعیت پیکسل-صفحه نمایش هر مختصات Geohash در GeohashTile، لازم است به طور همزمان موقعیت نقطه مرکزی محاسبه شود. gجو نقطه مرکزی پیکسل نسبی gجپاز هر GeohashTile. فرآیند جستجوی تمامی رمزگذاری های GeohashTile در کلاینت با روش همسایه در الگوریتم 1 نشان داده شده است. هنگام جستجوی همسایگان، باید با آخرین بایت رمزگذاری Geohash شروع کنیم. با استفاده از شکل 1 به عنوان مثال، اگر رمزگذاری فعلی، مقدار مرزی جهت مورد جستجو نباشد، مستقیماً جستجو می شود. اگر رمزگذاری فعلی مقدار مرزی جهتی باشد که باید جستجو شود، برعکس جستجو خواهد شد. در فرآیند جستجو، همسایه‌های چپ و راست و همسایه‌های بالا و پایین به طور همزمان انجام می‌شوند که زمان محاسبه را کوتاه می‌کند و کارایی پرس و جو را بهبود می‌بخشد.

الگوریتم 1 الگوریتم جستجوی همسایه GeohashTile
نیاز:
center_geohashtile, جهnتیهrتیمنله;
1:
تعداد رمزگذاری GeohashTile در جهت x ، gتی_ایکس;
2:
تعداد رمزگذاری GeohashTile در جهت y ، gتی_y;
اطمینان حاصل شود:
gهoساعتآسساعتتیمنله_qتوهتوهمرتب شده توسط مکان پوشش GeohashTile.
3:
4:
تابع fqinj_tile_queue ( جهnتیهrتیمنله،gتی_ایکس،gتی_y)
5:
       تیمترپمن=(gتی_y-1)/2،تیمترپj=(gتی_ایکس-1)/2;
6:
      l  = طول جهnتیهrتیمنلهرمزگذاری؛
7:
       gهoساعتآسساعتتیمنله_qتوهتوه[تیمترپمن][تیمترپj]=جهnتیهrتیمنله;//ابتدا GeohashTile مرکزی را ذخیره کنید
8:
       تیمترپل=جهnتیهrتیمنله،تیمترپr=جهnتیهrتیمنله;
9:
      //همسایگان چپ و راست مرکز GeohashTile را بیابید
10:
     برای j=1;j≤تیمترپj;j++ انجام دادن
11:
            تیمترپل= همسایه_محدود (تیمترپل،ل،لهfتی);
12:
            تیمترپr= همسایه_محدود( تیمترپr،ل،rمنgساعتتی)
13:
           geohashtile_queue [تیمترپمن][تیمترپj-j]=تیمترپل;
14:
           geohashtile_queue [تیمترپمن][تیمترپj+j]=تیمترپr;
15:
      پایان برای
16:
      //همسایه های بالا و پایین GeohashTiles ردیف وسط را بیابید
17:
      برای j=0;j≤تیمترپj;j++ انجام دادن
18:
            تیمترپتی=تیمترپب= geohashtile_queue [تیمترپمن][j];
19:
           برای من=1;من<=تیمترپمن;من++ انجام دادن
20:
                  تیمترپتی= همسایه_محدود( تیمترپتی،ل،تیoپ)
21:
                  تیمترپب= همسایه_محدود( تیمترپب،ل،بتوتیتیoمتر)
22:
                 geohashtile_queue [تیمترپمن-من][j]=تیمترپتی;
23:
                 geohashtile_queue [تیمترپمن+من][j]=تیمترپب;
24:
           پایان برای
25:
      پایان برای
26:
عملکرد پایانی
27:
// رمزگذاری همسایه را در جهت مشخص شده بیابید
28:
تابع fqinj_bound ( جتوrتیمنله،ل،جتوr_د)
29:
      اگر l ام بایت از جتوrتیمنلههست  جتوr_دسپس مقید شده است
30:
            جتوrتیمنله = اولین ل-2بایت از جتوrتیمنله+  جتوr_دهمسایه از  ل-1بایت هفتم از جتوrتیمنله+  جتوr_دهمسایه آخرین بایت از جتوrتیمنلهجستجو به ترتیب معکوس؛
31:
      دیگر
32:
            جتوrتیمنله =  جتوr_دهمسایه از جتوrتیمنله;
33:
      پایان اگر
34:
عملکرد پایانی

4.2. فرآیند ادغام درخواست‌های داده نقشه ارسال شده به سرور

پس از دریافت دنباله GeohashTile مورد نیاز در زیربخش قبلی، مشتری درخواست را ادغام می کند و شروع به ارسال یک درخواست HTTP به سرور برای درخواست داده های اطلاعات جغرافیایی در قالب GeoJSON می کند. فرآیند درخواست در  بخش 3.2.1 ، آماده سازی داده های سرور توضیح داده شده است (همانطور که در مرحله ④ در  شکل 5 نشان داده شده است ). این بخش فرعی بر فرآیند ادغام درخواست تمرکز دارد. از آنجایی که هر بایت افزایش در رمزگذاری GeohashTile منطقه را به 32 منطقه کوچک تقسیم می کند، در یک سطح تعداد زیادی ناحیه وجود دارد. هرچه تعداد کاشی ها در همان سطح بیشتر باشد، هنگام درخواست داده، داده های اضافی بیشتری تولید می شود. به عنوان مثال، 35 GeohashTile باید در یک درخواست از مشتری درخواست شود، و ترتیب کاشی کاری این GeohashTiles در مشتری نشان داده شده است. جدول 4 .

برای کاهش تعداد درخواست‌های داده و افزونگی داده‌ها، یک فرآیند ادغام درخواست قبل از درخواست GeohashTile اضافه می‌شود. الگوریتم ادغام درخواست در الگوریتم 2 نشان داده شده است.

الگوریتم 2 الگوریتم ادغام درخواست GeohashTile
نیاز:
geohashtile_queue ،gتی_qتوهتوه; //صف GeohashTile در الگوریتم 1 به دست آمده است
اطمینان حاصل شود:
new_queue
1:
تابع merge_request ( gتی_qتوهتوه)
2:
       منلهn = ردیف های gتی_qتوهتوه، jلهn = ستون های gتی_qتوهتوه;
3:
      //محاسبه ادغام زمانی شروع می شود که طول رمزگذاری 2 باشد
4:
      اگر طول gتی_qتوهتوه[0][0]>1 سپس
5:
            اگر منلهn×jلهn>10 سپس
6:
                 //تعداد بیشتر سطر و ستون را به دو مجموعه تقسیم کنید
7:
                 اگر منلهn>jلهn سپس
8:
                        ستوبمن=منلهn/2، ستوبj=jلهn;
9:
                       // GeohashTiles بالا سمت چپ و پایین سمت راست دو مجموعه را برای ادغام پرس و جو کنید
10:
                        من3=ستوبمن×2-1،j3=ستوبj-1;
11:
                       // GeohashTiles ادغام نشده را ذخیره کنید
12:
                       برای j=0;j<jلهn;j++ انجام دادن
13:
                             new_queue [j+1]= gt_queue [منلهn-1][j];
14:
                       پایان برای
15:
                 دیگر
16:
                        ستوبمن=منلهn، ستوnj=jلهn/2;
17:
                        من3=ستوبمن-1،j3=ستوبj×2-1;
18:
                       برای من=0;من<منلهn;من++ انجام دادن
19:
                             new_queue [من+1]= gt_queue [من][jلهn-1];
20:
                       پایان برای
21:
                 پایان اگر
22:
                 //دو رمزگذاری GeohashTiles ادغام شده را ذخیره کنید
23:
                 new_queue[0] = gt_queue [0][0]+gt_queue [ستوبمن-1][ستوبj-1];
24:
                 new_queue[1] = gt_queue [ستوبمن][0]+gt_queue [من3][j3];
25:
            پایان اگر
26:
      پایان اگر
27:
عملکرد پایانی
الگوریتم ادغام درخواست از برچسب گذاری رئوس برای ادغام کاشی های کوچک با عدد بزرگتر یا مساوی 10 تحت همان تقسیم استفاده می کند. تعداد بیشتر سطر یا ستون را در قسمت تقسیم می کنیم  gهoساعتآسساعتتیمنله_qتوهتوهبه دو مجموعه از دنباله‌هایی که باید ادغام شوند، و دو GeohashTile را در گوشه بالا سمت چپ و پایین سمت راست محدوده تقسیم‌شده ترکیب کنید تا محدوده ادغام شده را نشان دهد، بنابراین تعداد درخواست‌های داده را کاهش می‌دهد. همانطور که در مثال جدول 4 ، طبق قوانین الگوریتم 2، هر مجموعه از مناطق برابر است با 5×3پس از ادغام، یعنی اولین ترکیب به صورت کدگذاری می شود  ”wrهکg”در گوشه بالا سمت چپ و  ”wrه7v”در گوشه پایین سمت راست با 15 GeohashTiles (یعنی قسمت قرمز در جدول)، و رمزگذاری ترکیبی ”wrهکgwrه7v”. در ترکیب دوم، گوشه سمت چپ بالا به صورت کدگذاری می شود  ”wrهکy”و گوشه سمت راست پایین به صورت کدگذاری شده است  ”wrههب”با 15 GeohashTiles (یعنی قسمت آبی در جدول)، و رمزگذاری ترکیبی ”wrهکywrههب”. پس از ادغام، فقط باید GeohashTiles ادغام شده را درخواست کنید که به عنوان کدگذاری شده اند  ”wrهکgwrه7v”و  ”wrهکywrههب”و 5 GeohashTile باقی مانده ادغام نشده. هنگامی که سرور یک رمزگذاری به طول l دریافت می کند”wrهسه”در  جدول 4 )، درخواست داده GeohashTile معمولی را نشان می دهد. با این حال، زمانی که طول رمزگذاری است 2ل(مانند ”wrهکgwrه7v”در  جدول 4 ، نشان می دهد که یک درخواست ادغام شده است، و سپس درخواست به دو قسمت با طول مساوی برای درخواست های داده بعدی تجزیه می شود. شایان ذکر است که داده های درخواست ادغام شده، مقدار داده را افزایش یا حتی کاهش نمی دهد، که در تجزیه و تحلیل تجربی بخش 5 به تفصیل مورد تجزیه و تحلیل قرار خواهد گرفت .

4.3. فرآیند طرح ریزی موقعیت نسبی

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

4.3.1. متراکم سازی داده ها

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

بنابراین لازم است که معادله ( 8 ) برای محاسبه طول رمزگذاری ژئوهش در کل محدوده عرض جغرافیایی مناسب باشد. با توجه به معادله ( 8 )، زمانی که سطح زوم 1 باشد، کوتاه ترین طول رمزگذاری ژئوهش 4 است، بنابراین در محاسبه دقیق فقط فاصله و رابطه دقت کدگذاری 4 بایت اول در نظر گرفته می شود.

gس_ایکس×gس_y≤1

ل≥⌈(4×z+31)/10⌉

در اینجا دو تعریف برای کمک به توضیح داریم.

تعریف  1.

فاصله رمزگذاری (d). فاصله بین رمزگذاری بایت مشخص شده Geohash و رمزگذاری استوایی همان ستون.

تعریف  2.

وضوح ژئوهاش فاصله پیکسل هنگام رمزگذاری فاصله بایت مشخص شده Geohash 1 است.

به عنوان مثال، هنگام محاسبه فاصله رمزگذاری از ”wایکس4ه”، رمزگذاری استوایی ستونی که اولین بایت در آن قرار دارد ”w”، بنابراین د10 است و وضوح Geohash این بایت 1 است. رمزگذاری استوایی ستون در بایت دوم است. ”8″، بنابراین د27 است و وضوح Geohash در این بایت 1/8 است. رمزگذاری استوایی ستونی که بایت سوم در آن قرار دارد ”4″، بنابراین د30 است و وضوح Geohash در این بایت است (1/4)×(1/8). رمزگذاری استوایی ستونی که بایت چهارم در آن قرار دارد ”8″، بنابراین د43 است و وضوح Geohash در این بایت است (1/4)×(1/8)2. با توجه به قوانین رمزگذاری Geohash نشان داده شده در  شکل 1 ، فاصله رمزگذاری را می توان با جستجوی جدول به سرعت به دست آورد. معادله ( 9 ) معادله محاسبه طول رمزگذاری است. در  بخش 5 ، نتایج محاسبه شده و اندازه گیری شده به تفصیل تجزیه و تحلیل خواهد شد.

ل≥⌈(4×z+31)/10+∑من=14(دمن×(1/4)(من-1)/2×(1/8)من/2)⌉

4.3.2. محاسبه فاصله پیکسل

GeoJSON به دست آمده در بخش قبل شامل یک سری Geohash کدگذاری شده است جیهoساعتآسساعت_لمنستیکه مختصات اجسام هندسی، یعنی نقاط هدف را نشان می دهد. اولین گام در اجرای طرح ریزی، محاسبه فاصله نسبی پیکسل است دمنستیآnجه_لمنستیاز این نقاط هدف به نقطه مرکزی. دو محاسبه فاصله نسبی وجود دارد (همانطور که در مرحله ⑥ در  شکل 5 نشان داده شده است ). اولین مورد فاصله پیکسل کاشی است که فاصله نسبی پیکسل است تیمنله_دمنساز نقطه مرکزی GeohashTile تا نقطه مرکزی واقعی. دوم فاصله پیکسل مختصات است جoorد_دمنس، که فاصله نسبی پیکسل از نقطه مختصات جسم هندسی تا نقطه مرکزی GeohashTile است. الگوریتم 3 الگوریتم محاسبه فاصله پیکسلی از نقطه هدف تا نقطه مرکزی است که برای دو محاسبه فوق قابل استفاده است. جایی که جتوrgهدف فعلی Geohash است که باید محاسبه شود، یک بایت در یک زمان، از بالا به پایین محاسبه می شود. از آنجایی که تقسیم Geohash به طور متناوب توسط 8×4و  4×8، ترتیب موقعیت دو همسایه متفاوت است. g_rآل_پoساز یک آرایه دو بعدی برای نشان دادن موقعیت نسبی Geohash استفاده می کند. موقعیت شخصیت فعلی i Geohash نشان دهنده  من-تیساعتتقسیم، و نوع تقسیم تیyپه_منnدهایکسبا محاسبه برابری i به دست می آید . سپس ستونی را که مقدار هدف در آن قرار دارد جستجو می کنیم تا بفهمیم که در حال حاضر از کدام مجموعه مقادیر برای تکمیل محاسبه استفاده می شود. جآل_ایکس، جآل_yفاصله نسبی کاراکتر فعلی از نقطه مرکزی را به ترتیب ثبت کنید. در سطوح مختلف بزرگنمایی، فاصله پیکسل در جهت x و y که توسط هر بایت رمزگذاری Geohash نشان داده شده است را می توان با جایگزین کردن نتیجه محاسبه شده طول رمزگذاری در معادله ( 9 ) به معادله ( 5 ) محاسبه کرد. از آنجایی که فاصله پیکسل را می توان پس از یک بار محاسبه مجدد استفاده کرد، نتیجه محاسبه را می توان در یک آرایه ذخیره کرد و فقط آرایه باید بعداً پرس و جو شود. پد.ایکسو  پد.yبه ترتیب فاصله پیکسلی بین داده های رمزگذاری فعلی Geohash و نقطه مرکزی را ثبت کنید.

الگوریتم 3 الگوریتم محاسبه فاصله پیکسل
نیاز:
ژئوهش فعلی جتوrg;//نقطه هدف فعلی Geohash محاسبه شود
1:
مرکز فعلی جج;//نقطه مرکزی فعلی
اطمینان حاصل شود:
فاصله پیکسلی پد
2:
تابع target_pixel_distance ( جتوrg)
3:
       منلهn = طول جتوrg;
4:
       من=0;//موقعیت فعلی از جتوrg
5:
      برای هر من در  جتوrgلهn انجام دادن
6:
             تیg= i -امین داده از جتوrg;
7:
             تیyپه_منnدهایکس= باقی مانده از (من+1)∖2;//انتخاب حالت رمزگذاری، 8×4یا 4×8
8:
             من=من+1;// به بایت بعدی اشاره می کنمجتوrg
9:
             j=0;//موقعیت فعلی از g_rآل_پoس
10:
             jلهn= طول  تیyپه_منnدهایکسخط در  g_rآل_پoس;
11:
            برای انجام هر j در  jلهn
12:
                 اگر تیgکه در  g_rآل_پoس[من][j] سپس
13:
                       cal_x=شماره سریال تیgکه در  g_rآل_پoس[من][j];
14:
                        جآل_y=j;
15:
                       زنگ تفريح؛
16:
                 پایان اگر
17:
                  j=j+1;
18:
            پایان برای
19:
            //تفاوت موقعیت نسبی
20:
            cal_x= x از ججموقعیت نسبی- جآل_ایکس;
21:
             جآل_y= y از ججموقعیت نسبی- جآل_y;
22:
            //تفاوت نسبی پیکسل
23:
             پد.ایکس=پد.ایکس+جآل_ایکس×ایکس-فاصله پیکسل جهت نشان داده شده توسط رمزگذاری فعلی.
24:
             پد.y=پد.y+جآل_y×y-فاصله پیکسل جهت نشان داده شده توسط رمزگذاری فعلی.
25:
      پایان برای
26:
عملکرد پایانی
4.3.3. محاسبه مختصات صفحه نمایش

محاسبه مختصات صفحه آخرین مرحله برای نشان دادن نقاط هدف رمزگذاری شده Geohash روی صفحه است (همانطور که در مرحله ⑦ در شکل 5 نشان داده شده است ). موقعیت نسبی پیکسل از نقطه هدف تا نقطه مرکزی قبلاً بدست آمده است. در اینجا، ما فقط باید موقعیت نسبی پیکسل را به موقعیت پیکسل واقعی تبدیل کنیم، یعنی موقعیت مختصات صفحه را محاسبه کنیم. پoمنnتی_لمنستیفاصله نسبی پیکسل دمنستیآnجه_لمنستیبا توجه به نقطه مرکزی صف پیکسل gجپ_qتوهتوه. معادله ( 10 ) معادله محاسبه موقعیت پیکسل واقعی نقطه هدف است که در آن جg_جهnتیهrموقعیت پیکسل نقطه مرکزی واقعی صفحه مشتری است.

تیپ.ایکس=جg_جهnتیهr[0]+تیمنله_دمنس.ایکس+جoorد_دمنس.ایکس;تیپ.y=جg_جهnتیهr[1]+تیمنله_دمنس.y+جoorد_دمنس.y;

4.4. فرآیند ذخیره سازی نتایج متوسط

از آنجایی که GeohashTile از روش نمایش موقعیت نسبی استفاده می کند، موقعیت تمام کاشی ها و موقعیت اجسام هندسی در موقعیت های نسبی ثبت می شود. با ذخیره کردن نتایج محاسبات میانی، می توان کارایی محاسبه و رندر را بهبود بخشید. طبق محاسبات قبلی فاصله پیکسل کاشی تیمنله_دمنسو فاصله پیکسل مختصات جoorد_دمنسدر دو موقعیت نسبی، محاسبات را می توان به عنوان نتایج میانی در کش ذخیره کرد (همانطور که در مرحله ⑧ در شکل 5 نشان داده شده است ).
فرآیند ذخیره سازی نتایج میانی شامل دو بخش است: قبل و بعد از انجام پانینگ موقعیت نقشه در سمت مشتری. قبل از حرکت در موقعیت نقشه، فاصله پیکسل کاشی تیمنله_دمنسو فاصله پیکسل مختصات جoorد_دمنسباید ثبت شود پس از بررسی موقعیت نقشه، لازم است دوباره محاسبه شود تیمنله_دمنس، و همچنین محاسبه کنید جoorد_دمنساز کاشی های جدید اضافه شده
شکل 6 یک نمودار شماتیک از ترجمه موقعیت مشتری است که در آن gتی1– gتی46اعداد GeohashTile هستند و سی1، سی2، و سی3نشان دهنده موقعیت نقطه مرکزی حرکات سه برابر موقعیت مشتری است. با در نظر گرفتن شکل 6 به عنوان مثال، مراحل ذخیره سازی نتایج میانی را به صورت زیر خلاصه می کنیم:
استیهپ1:محاسبه دقت مختصات Geohash. همانطور که در شکل 5 نشان داده شده است ، یک لیست فاصله پیکسل کاشی تیمنله_دمنس_لمنستیو یک لیست فاصله پیکسل مختصات جoorد_دمنس_لمنستیتاسیس می شوند. هنگامی که مشتری برای اولین بار GeohashTile را بارگیری می کند، نتیجه محاسبه در لیست مربوطه ذخیره می شود. شکل 6 موقعیت مختصات نقطه مرکزی را ثبت می کند سی1، و تیمنله_دمنس_لمنستیاز نقطه مرکزی gتی1– gتی9پوشش مشتری به C1، و همچنین جoorد_دمنس_لمنستیمختصات هر جسم هندسی در کاشی تا نقطه مرکزی کاشی.
استیهپ2:هنگامی که پان موقعیت نقشه در سمت مشتری رخ می دهد، اگر کاشی جدیدی اضافه نشود، محاسبه آن ضروری نیست جoorد_دمنسبارها و بارها، اما فقط موقعیت نسبی تیمنله_دمنسنیاز به محاسبه دارد در شکل 6 ، پس از اولین ترجمه، موقعیت نقطه مرکزی است سی2. در این زمان، سی2و نقطه مرکزی سی1قبل از ترجمه در همان GeohashTile هستند و کاشی‌های پوشاننده مشتری هنوز هستند gتی1– gتی9بدون کاشی جدید اضافه شده است. بنابراین، ما فقط باید فاصله پیکسلی را محاسبه کنیم سی2و سی1، دمنس_ج2_ج1، و سپس جدید را محاسبه کنید تیمنله_دمنس_nهw=تیمنله_دمنس+دمنس_ج2_ج1.
استیهپ3:هنگامی که موقعیت نقشه کلاینت جابجا می شود، اگر کاشی های جدید اضافه شوند، موقعیت های نسبی از تیمنله_دمنسو جoorد_دمنسباید دوباره محاسبه شود، در حالی که موقعیت های نسبی کاشی های اصلی فقط باید دوباره محاسبه شود تیمنله_دمنس، که محاسبه تکراری را بسیار کاهش می دهد. در شکل 6 ، پس از پانینگ دوم، موقعیت نقطه مرکزی است سی3. gتی2،gتی5،gتی6،gتی7،gتی8از کاشی اصلی پوشاننده مشتری حذف می شوند و gتی25،gتی28،gتی32،gتی37،gتی46اضافه می شوند. اکنون باید فاصله پیکسل ها را محاسبه کنیم دمنس_ج3_ج2از سی3و سی2. برای کاشی های اصلی، فقط باید به روز رسانی کنیم تیمنله_دمنس_nهw=تیمنله_دمنس+دمنس_ج3_ج2; و کاشی های تازه اضافه شده نیاز به محاسبه مجدد دارند تیمنله_دمنسو جoorد_دمنسارزش های.
استیهپ4:هنگامی که نقشه روی مشتری بزرگنمایی می شود، محتویات لیست پاک می شود و نتایج محاسبات جدید ثبت می شود.
استیهپ5:برای مکان یابی سریع لیست کاشی ها به عنوان جابجایی موقعیت نقشه مشتری، همچنین باید کاشی را در جایی که نقطه مرکزی قرار دارد ذخیره کنیم. هنگامی که نقشه توسط Leaflet بارگذاری می شود، پارامترهایی که باید مقداردهی اولیه شوند مختصات نقطه مرکزی و سطح بزرگنمایی هستند. پس از ارائه Geohash نقطه مرکزی، در ترکیب با سطح زوم، چند بایت اول رمزگذاری به عنوان رمزگذاری کاشی در نظر گرفته می شود. تعداد تغییرات کاشی مرکزی در هر بار پانینگ مشتری بسیار کمتر از تعداد تغییرات مختصات نقطه مرکزی است، بنابراین می تواند میزان محاسبه را بیشتر کاهش دهد.

5. آزمایش ها و ارزیابی

برای ارزیابی اثربخشی GeohashTile پیشنهادی، آن را با داده‌های واقعی از OpenStreetMap ارزیابی می‌کنیم. در این بخش ابتدا محیط آزمایشی و مجموعه داده را معرفی می کنیم. سپس GeohashTile و کاشی های پیشرفته طول و عرض جغرافیایی GeoTile [ 2 ] را که بر اساس Leaflet نیز ساخته شده است، مقایسه و تجزیه و تحلیل می کنیم.

5.1. راه اندازی آزمایشی و مجموعه داده

محیط آزمایشی ما شامل محیط سرور (GeoServer) و محیط سرویس گیرنده است. محیط فیزیکی ساخته شده توسط GeoServer یک ماشین مجازی با پردازنده 2 هسته ای Intel (R) Xeon (R) e5-26200 @ 2.00 گیگاهرتز و حافظه 2 گیگابایتی است. این معماری مبتنی بر سیستم عامل اوبونتو 14.04 و مجموعه ای از بسته های نرم افزاری منبع باز است. این سرور Apache HTTP و وب سرور را برای تحقق عملکردهای سرور ترکیب می کند. محیط کلاینت یک لپ تاپ با سیستم عامل ویندوز 7 64 بیتی، پردازنده Intel Core i5-4690K 3.5 گیگاهرتز و حافظه 8 گیگابایتی است که از مرورگر گوگل کروم برای نمایش نقشه Leaflet استفاده می کند. تمام داده های اصلی جغرافیایی از OpenStreetMap می آیند. در اینجا ما چهار منطقه با توزیع های مختلف عرض جغرافیایی در سنگاپور، هاینان، پکن و هیلونگجیانگ را برای تجزیه و تحلیل عملکرد انتخاب می کنیم.
Leaflet [ 31 ] کتابخانه منبع باز اصلی جاوا اسکریپت برای نقشه های تعاملی تلفن همراه است. فایل JS آن تنها حدود 38 کیلوبایت است و تمام ویژگی های نقشه برداری که اکثر توسعه دهندگان به آن نیاز دارند را دارد. این جزوه به دلیل ویژگی های عالی تعاملی تلفن همراه و مزایای سبک وزن آن به طور گسترده مورد استفاده قرار می گیرد. بنابراین، هنگامی که روش پیشنهادی را تحلیل می‌کنیم، سیستم نمایش نقشه برداری Geohash بر اساس Leaflet (یعنی GeohashTile) را با سیستم نمایش کاشی طول و عرض جغرافیایی یکسان بر اساس Leaflet (یعنی GeoTile) مقایسه می‌کنیم.

5.2. تجزیه و تحلیل عملکرد

در این بخش، سیستم نمونه اولیه GeohashTile را پیاده سازی می کنیم و آزمایش هایی را از منظرهای متعدد انجام می دهیم. ما طول و دقت رمزگذاری Geohash را در سطوح مختلف زوم تجزیه و تحلیل و محاسبه می‌کنیم. در همان زمان، ما به طور کمی مقدار داده های ارسال شده توسط مشتری را هنگام بارگیری داده های GeoTile، GeohashTile بدون ادغام (به طور خلاصه GeohashTileNoMerging)، GeohashTile کاملا بهینه شده (به طور خلاصه GeohashTileFull) ارائه شده توسط GeoServer و همچنین زمان بارگذاری GeoTile، GeohashTile بدون کش نتیجه میانی (به اختصار GeohashTileNoCahcing) و GeohashTileFull.

5.2.1. طول و دقت رمزگذاری Geohash

نحوه محاسبه دقت مختصات Geohash در بخش 3.2.2 معرفی شده است. در این بخش، نتایج محاسباتی معادله ( 9 ) را تحلیل خواهیم کرد. شکل 7 نتایج طول رمزگذاری ژئوهش و سطح زوم محاسبه شده با استفاده از معادله ( 9 ) را نشان می دهد. از آنجایی که هر چه به قطب ها نزدیک تر باشد، ناحیه نشان داده شده توسط Geohash با طول رمزگذاری یکسان بزرگتر است. برای راحتی محاسبه، طول جغرافیایی یکسان و مقادیر مختلف عرض جغرافیایی در اینجا استفاده می شود. شکل 7 نتیجه انتخاب طول رمزگذاری Geohash از 5 مجموعه مناطق طول و عرض جغرافیایی را با طول جغرافیایی نشان می دهد. 0∘، و محدوده عرض جغرافیایی 0– 90∘با 20∘فاصله زمانی که سطح زوم 1-18 است. همانطور که از شکل 7 مشاهده می شود، با افزایش سطح زوم، طول رمزگذاری Geohash افزایش می یابد. در همان سطح زوم، دقت Geohash کمتری در نزدیکی استوا نسبت به نزدیکی قطب ها مورد نیاز است. تحت همان نیاز دقت، طول رمزگذاری Geohash با افزایش عرض جغرافیایی افزایش می‌یابد. دلایل به شرح زیر است: (1) همان Geohash به جای همان منطقه، همان محدوده طول و عرض جغرافیایی را پوشش می دهد. در عرض های جغرافیایی مختلف، مساحت واقعی تحت پوشش ژئوهاش با همان طول متفاوت است، با یک منطقه بزرگ در نزدیکی استوا و یک منطقه کوچک در نزدیکی قطب ها. (2) از نظر طول و عرض جغرافیایی، فاصله مختصات صفحه بین خط استوا کوتاه و فاصله بین قطب ها در محدوده دو مجموعه از نقاط مختصات صفحه با عرض های جغرافیایی مختلف و فاصله طولی یکسان است. برعکس، وقتی مساحت واقعی یکسان است، طول رمزگذاری ژئوهش مربوطه در نزدیکی استوا از طول نزدیک قطب ها کوتاه تر است. (3) مانند GeoTile، هر قطعه از GeohashTile اندازه پیکسلی را مشخص می‌کند که هنگام ایجاد نمایش صفحه نمایش داده می‌شود، مانند یک قطعه GeohashTile 512×512پیکسل‌ها در سطح 0. هنگامی که پیکسل‌های یک قطعه GeohashTile ثابت است، هر چه ناحیه نشان‌دهنده آن کوچک‌تر باشد، دقت لازم برای نمایش دقیق‌تر موقعیت بالاتر خواهد بود.
ما همچنین نتایج آماری واقعی طول رمزگذاری Geohash را بین محدوده آماری واقعی و عرض جغرافیایی متناظر در چهار منطقه سنگاپور، هاینان، پکن و هیلونگجیانگ در زمانی که سطح زوم 1-18 است، در شکل 8 مقایسه می‌کنیم. نتیجه آماری در اینجا نتیجه مقایسه با موقعیت مختصات صفحه نمایش رمزگذاری Geohash 14 بایتی با بالاترین دقت است. محدوده عرض جغرافیایی چهار منطقه از بین انتخاب شده است 10∘،20∘،40∘، و 50∘مطابق با محدوده محاسبه همانطور که از شکل 8 مشاهده می شود ، نتایج آزمایش واقعی با نتایج محاسباتی محدوده عرض جغرافیایی مربوطه مطابقت دارد. بنابراین، هنگامی که از ژئوهش برای نشان دادن موقعیت مختصات اجسام هندسی روی نقشه استفاده می شود، لازم نیست از طول 14 بایت استفاده شود، بلکه باید طول مناسب را با توجه به موقعیت جغرافیایی و سطح زوم انتخاب کرد، که نشان می دهد ژئوهش می تواند نمایش داده های چند دانه ای و فشرده سازی داده ها بدون از دست دادن جلوه نمایش را درک کنید. با توجه به نتایج آزمایش ما، حداکثر 12 بایت Geohash برای برآورده کردن تمام الزامات دقت آزمایشی مورد نیاز است.
5.2.2. مقدار انتقال داده
اولین معیار ارزیابی میزان انتقال داده است زیرا تأثیر مستقیمی بر زمان بارگذاری دارد. داده های شمارش شده GeohashTile در اینجا داده های Geohash با طول رمزگذاری مطابق با بالاترین نیازهای دقت نشان داده شده در شکل 7 است. تعداد کاشی هایی که باید در همان محدوده صفحه نمایش مشتری بارگذاری شوند نیز عامل مهمی بر زمان بارگذاری است. اگرچه انتقال یک کاشی با مقدار کمی داده از نظر زمانی کوتاهتر از کاشی با مقدار زیاد داده است، اگر تقسیم کاشی در همان محدوده نمایش خیلی کوچک باشد، تعداد کاشی های ارسال شده به طور قابل توجهی افزایش می یابد. با توجه به افزایش انتقال داده های مکرر، زمان بارگذاری نیز به شدت تحت تاثیر قرار خواهد گرفت. با توجه به الگوریتم ادغام درخواست توضیح داده شده دربخش 3.2.2 ، GeohashTile کاشی های درخواستی را قبل از ارسال به سرور ادغام می کند. اینکه آیا ادغام GeohashTile منجر به افزایش زیادی در مقدار داده های درخواستی می شود یا خیر، یک شاخص مهم برای قضاوت در مورد منطقی بودن ادغام است.
شکل 9 مقایسه مقدار انتقال داده را هنگامی که چهار منطقه سنگاپور، هاینان، پکن و هیلونگجیانگ به ترتیب با GeoTile، GeohashTileNoMerging و GeohashTileFull بارگذاری می شوند نشان می دهد که سطح بزرگنمایی بین 1 تا 18 متغیر است. داده های نقشه برداری منتقل شده توسط GeoTile از طول و عرض جغرافیایی برای نمایش مختصات شیء هندسی استفاده می کند و طول و عرض جغرافیایی 7 رقم اعشار را حفظ می کند. داده های نقشه برداری منتقل شده توسط GeohashTile از Geohash برای نشان دادن مختصات شی هندسی استفاده می کند و طول را با بالاترین دقت مطابق با طول رمزگذاری که در بخش قبل توضیح داده شد حفظ می کند.
همانطور که از شکل 9 مشاهده می شود ، روند تغییرات مقدار داده GeohashTile و GeoTile اساساً در سطوح مختلف زوم و مناطق جغرافیایی یکسان است. علاوه بر این، هنگام ذخیره داده‌های شی هندسی در محدوده پوشش یکسان، مقدار داده GeohashTile به طور متوسط ​​47.3% کمتر از GeoTile است که نشان می‌دهد GeohashTile نسبت به GeoTile از نظر مقدار داده مزیت زیادی دارد. شکل 9a افزایش قابل توجهی در مقدار داده را هنگامی که سطح بزرگنمایی 13 است نشان می دهد، در حالی که سه آمار دیگر کاهش قابل توجهی را در مقدار داده نشان می دهند. دلیل این امر این است که مقدار داده ها به تعداد اجسام هندسی موجود در منطقه مربوط می شود و هر چه توضیحات دقیق تر باشد، حجم داده ها در منطقه بیشتر می شود. GeohashTile زمانی که سطح زوم 3 و 6 باشد داده های اضافی زیادی دارد و پس از ادغام، داده های بیشتری در خارج از منطقه وجود دارد. علاوه بر این، حجم داده های بیشتری نسبت به GeoTile وجود خواهد داشت. هنگامی که مقدار داده های اضافی از مقدار فشرده سازی داده ها بیشتر شود، وضعیت در شکل 9 ب رخ می دهد.
برای GeohashTileFull، مقدار داده پس از ادغام به طور قابل توجهی افزایش نیافته است. در واقع، در بیشتر موارد، حجم داده ها کاهش یافته است. دلیل آن این است که وقتی سرور داده های نقشه برداری GeohashTile را ارائه می دهد، بر اساس موقعیت مختصات شی هندسی تقسیم می شود. تا زمانی که مختصات شی هندسی در محدوده GeohashTile باشد، شی در داده های GeoJSON مربوطه گنجانده می شود، به طوری که همان شی می تواند در چندین GeoJSON قرار گیرد، یعنی داده های اضافی وجود داشته باشد. پس از ادغام درخواست ها، اشیاء هندسی که در ابتدا در چندین GeohashTile وجود داشتند، اکنون فقط یک بار ظاهر می شوند، بنابراین مقدار داده کاهش می یابد. اگرچه در اینجا مقدار داده کاهش می یابد،
با توجه به قوانین محاسبه محدوده Geohash توضیح داده شده در بخش 4.1.1 ، پوشش یک کاشی زمانی که سطح زوم 3، 8، 13 و 18 باشد، کوچکترین است، یعنی تعداد بلوک های Geohash که باید به همان اندازه تقسیم شوند. محدوده بزرگترین است، و داده های افزونگی تولید شده در این زمان نیز بزرگترین است، که موقعیت اوج GeohashTileNoMerging در این ارقام است. پس از ادغام، تعداد بلوک‌های تقسیم شده کاهش می‌یابد و مقدار داده‌های اضافی کاهش می‌یابد، بنابراین تغییر GeohashTileFull متمایل به صاف است.
5.2.3. زمان بارگذاری
زمان بارگذاری داده های نقشه یک شاخص مهم برای اندازه گیری روش نمایش نقشه است. زمان بارگذاری زمانی است که مشتری وب شروع به درخواست داده های کاشی می کند تا تمام داده های درخواستی که روی صفحه نمایش داده می شوند. در سیستم ما، سه عامل بر زمان بارگذاری تأثیر می‌گذارند: میزان داده، نحوه نمایش و اینکه آیا حافظه پنهان نتیجه میانی وجود دارد یا خیر.
شکل 10 مقایسه زمان بارگذاری GeoTile، GeohashTileNoCahcing و GeohashTileFull را برای چهار منطقه سنگاپور، هاینان، پکن و هیلونگجیانگ در زمانی که سطح زوم 1-18 است نشان می دهد. همانطور که از شکل 10 مشاهده می شود :
(1) هنگامی که سطح زوم 1 تا 18 باشد، زمان بارگذاری GeohashTileFull به طور متوسط ​​30.2٪ در مقایسه با GeoTile در همان محدوده چهار منطقه کاهش می یابد، که نشان می دهد GeohashTileFull مزیت قابل توجهی نسبت به GeoTile در زمان بارگذاری دارد. . با افزایش سطح زوم و مقدار داده، زمان بارگذاری GeoTile و GeohashTileFull روند افزایشی یکسانی دارد. در برخی از سطوح زوم، مانند سطح 11، زمان بارگذاری GeohashTileFull به طور متوسط ​​50٪ کمتر از GeoTile است. با نگاهی دقیق تر به این سطح مشخص می شود که تعداد کاشی های بارگذاری شده توسط GeohashTileFull پس از ادغام درخواست دقیقاً 1 است و مقدار داده ها کمتر از قبل از ادغام درخواست است، بنابراین زمان بارگذاری بسیار کاهش می یابد. در برخی موارد، به عنوان مثال، زمانی که سطح زوم در هاینان 6 است، GeohashTileFull زمان بارگذاری کمی بالاتر از GeoTile دارد. این به این دلیل است که اگرچه GeohashTile درخواستی الزامات ادغام را برآورده می‌کند، اما داده‌های بیشتری از چندین منطقه Geohash پس از ادغام اضافه می‌شوند و در نتیجه زمان بارگذاری افزایش می‌یابد. یکی دیگر از دلایل کوتاه‌تر بودن زمان بارگذاری GeohashTileFull، مزیت پروجکشن است. GeoTile از طرح ریزی Mercator استفاده می کند، در حالی که GeohashTile از روش طرح ریزی موقعیت نسبی برای آسان کردن محاسبات استفاده می کند.
(2) با مقایسه زمان بارگذاری GeohashTileNoCahcing و GeohashTileFull، می توان مشاهده کرد که زمان بارگذاری GeohashTileFull 14.1٪ کمتر از GeohashTileNoCahcing است، که نشان می دهد کش نتیجه میانی به طور قابل توجهی زمان بارگذاری را بهبود بخشیده است. در برخی موارد، به دلیل بازه ترجمه بزرگ و سرعت کم تکرار کاشی در آزمایش، زمان بارگذاری این دو یکسان است، مانند زمانی که سطح بزرگنمایی 1 و 2 است. آزمایش‌های بعد از سطح زوم 6 نشان می‌دهند که زمان بارگذاری هنگامی که یک کش نتیجه میانی وجود دارد، با نرخ استفاده مجدد کاشی تغییر می کند. این نشان می‌دهد که تأثیر حافظه پنهان نتیجه میانی بر زمان بارگذاری مستقیماً با نرخ استفاده مجدد از نتایج ذخیره شده مرتبط است. هر چه میزان استفاده مجدد بیشتر باشد، تعداد محاسبات تکراری کمتر می شود و زمان بارگذاری بیشتر کاهش می یابد.

6. نتیجه گیری

در این مقاله، با انگیزه پارتیشن داده‌ها و فشرده‌سازی همزمان داده‌ها، و با شروع با هدف کاهش انتقال داده‌ها، بهبود کارایی شاخص و کاهش زمان بارگذاری، ساختار داده‌های جغرافیایی برداری بر اساس Geohash و یک سیستم GeohashTile که داده‌های نقشه را یکسان می‌کند، مورد مطالعه قرار دادیم. نمایه سازی و کدگذاری مختصات هندسی پیاده سازی شده است. سیستم GeohashTile در حالی که زمان انتظار کاربر را کاهش می دهد، بر روی جلوه نمایش تأثیر نمی گذارد. این باعث می شود برنامه میزان انتقال داده و زمان بارگذاری را کاهش دهد. همچنین یک سرویس داده برداری جدید را ارائه می دهد که از رمزگذاری Geohash پشتیبانی می کند. نتایج آزمایش نشان داد که از نظر کاهش مقدار داده ها، به دلیل ذخیره فشرده سازی طول و عرض جغرافیایی Geohash، ذخیره سازی داده های نقشه دانه بندی متفاوت در سطوح مختلف و دسترسی به ادغام داده ها، GeohashTile به طور متوسط ​​43.7٪ بهتر از GeoTile عمل می کند. زمان بارگذاری GeohashTile در سرویس گیرنده وب نیز 30.2٪ کمتر از GeoTile است، زیرا موقعیت نسبی آن و ذخیره نتایج میانی در حافظه پنهان است.
با این حال، محدودیت هایی در مطالعه ما وجود دارد. در چارچوب Geohash، زمانی که دو نقطه در یک محدوده کوچک قرار دارند، فاصله کروی بین دو نقطه را می توان به فاصله صفحه دو نقطه تقریب زد و محاسبه را می توان تنها برای داشتن مختصات Geohash تکمیل کرد. با این حال، هنگام محاسبه فاصله کروی بین دو نقطه در یک محدوده بزرگ، این محاسبه تقریبی دارای خطای زیادی است و برای محاسبه دقیق فاصله کروی دو نقطه باید به مختصات طول و عرض جغرافیایی تبدیل شود.
اگرچه افکت نمایش تنها هدف پلتفرم داده های جغرافیایی برداری نیست، جلوه نمایش خوب پیش فرض و اساس همه عملکردهای پردازش داده است. در این مقاله فقط به رندر و نمایش نقشه در مختصات Geohash می پردازیم اما محاسبه هندسه کروی در آن را مطرح نمی کنیم. مطالعه محاسبه هندسه کروی در مختصات Geohash، مانند فاصله نقطه به نقطه و فاصله نقطه به خط، کار جالبی در آینده خواهد بود. یکی دیگر از کارهای جالب آینده، اصلاح بیشتر پارامترهای تبدیل affine است. با توجه به طول و عرض جغرافیایی، پارامترهای تبدیل افین باید در مناطق مختلف اصلاح شود که می تواند انحراف بین قطب شمال و جنوب را کاهش دهد. سومین جهتی که ارزش بررسی دارد، بهبود عملکرد سرور است.

منابع

  1. دیویس، ن. راینا، جی. Jagannathan، K. پیش بینی تقاضای تاکسی: یک استراتژی Tessellation مبتنی بر HEDGE برای بهبود دقت. IEEE Trans. هوشمند ترانسپ سیستم 2018 ، 19 ، 3686–3697. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  2. لی، سی. لو، اچ. شیانگ، ی. لیو، ز. یانگ، دبلیو. لیو، آر. نزدیک‌تر کردن داده‌های مکانی به کاربران موبایل: رویکرد ذخیره‌سازی مبتنی بر کاشی‌های برداری برای سناریوهای چند هاپ بی‌سیم. اوباش Inf. سیستم 2018 , 2018 , 5186495. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  3. یانگ، CP; وانگ، DWS؛ یانگ، آر. کافاتوس، م. لی، کیو. تکنیک های بهبود عملکرد در GIS مبتنی بر وب. بین المللی جی. جئوگر. Inf. علمی 2005 ، 19 ، 319-342. [ Google Scholar ] [ CrossRef ]
  4. Sagan, H. Space-Filling Curves ; Springer: نیویورک، نیویورک، ایالات متحده آمریکا، 1994. [ Google Scholar ]
  5. OpenLayers 3 Vector Rendering with Topology Simplification. سایت اینترنتی. 2014. در دسترس آنلاین: https://boundlessgeo.com/2014/03/openlayers-vector-rendering/ (در 21 سپتامبر 2017 قابل دسترسی است).
  6. Keying Huang، GL; وانگ، جی. استراتژی بازیابی سریع برای فراداده های سنجش از راه دور عظیم بر اساس کدگذاری GeoHash. سنسور از راه دور Lett. 2019 ، 10 ، 111-119. [ Google Scholar ] [ CrossRef ]
  7. گوگل. نقشه گوگل—مشخصات کاشی و مختصات. سایت اینترنتی. در دسترس آنلاین: https://developers.google.com/maps/documentation/javascript/maptypes (در 20 مه 2020 قابل دسترسی است).
  8. مایکروسافت. سیستم کاشی نقشه بینگ سایت اینترنتی. در دسترس آنلاین: https://docs.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system (در 29 ژوئن 2020 قابل دسترسی است).
  9. زوهر، ف. سنر، I. تجسم مبتنی بر وب داده های برداری بزرگ جغرافیایی. در علم اطلاعات جغرافیایی ; Springer: Cham، سوئیس، 2019; صص 59-74. [ Google Scholar ]
  10. ژو، ام. چن، جی. Gong, J. مدل داده های برداری مبتنی بر کره مجازی: مدل کاشی برداری چهارگوش کواترنر. بین المللی جی دیجیت. زمین 2016 ، 9 ، 230-251. [ Google Scholar ] [ CrossRef ]
  11. مارتین، آر جی. فرناندز، JPDC; پرز، EV; پرز، MJV; سانتوس، LMR یک مدل رگرسیون OLS برای واکشی اولیه کاشی آگاه از زمینه در یک کش نقشه وب. بین المللی جی. جئوگر. Inf. علمی 2013 ، 27 ، 614-632. [ Google Scholar ] [ CrossRef ]
  12. Wenjuecandidate، J. پیاده سازی خدمات نقشه وب OGC بر اساس وب سرویس. ژئو اسپات. Inf. علمی 2004 ، 7 ، 148-152. [ Google Scholar ]
  13. Guanhua، W. بهبود انتقال داده در برنامه های کاربردی وب از طریق ترجمه بین XML و JSON. در مجموعه مقالات سومین کنفرانس بین المللی ارتباطات و محاسبات سیار در سال 2011، چینگدائو، چین، 18 تا 20 آوریل 2011. ص 182-185. [ Google Scholar ]
  14. بری، تی. پائولی، جی. Sperbergmcqueen، CM Extensible Markup Language (XML). وب جهانی 1997 ، 2 ، 27-66. [ Google Scholar ]
  15. Lake, R. کاربرد زبان نشانه گذاری جغرافیا (GML) در علوم زمین شناسی. محاسبه کنید. Geosci. 2005 ، 31 ، 1081-1094. [ Google Scholar ] [ CrossRef ]
  16. نولان، دی. زبان نشانه گذاری Lang، DT Keyhole ; Springer: نیویورک، نیویورک، ایالات متحده آمریکا، 2014; صص 581-618. [ Google Scholar ]
  17. اشتاینیگر، اس. هانتر، ساختار داده AJS: داده های فضایی در وب . John Wiley & Sons, Ltd.: Hoboken, NJ, USA, 2017. [ Google Scholar ]
  18. GeoJSON. سایت اینترنتی. در دسترس آنلاین: https://geojson.org/geojson-spec.html (در 29 ژوئن 2020 قابل دسترسی است).
  19. لی، دبلیو. آهنگ، م. ژو، بی. کائو، ک. گائو، اس. تکنیک های بهبود عملکرد برای خدمات وب جغرافیایی در یک محیط زیرساخت سایبری – مطالعه موردی با یک پورتال مدیریت بلایا. محاسبه کنید. محیط زیست سیستم شهری 2015 ، 54 ، 314-325. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  20. لی، ال. هو، دبلیو. زو، اچ. لی، ی. ژانگ، اچ. مدل داده‌های برداری کاشی‌شده برای ویژگی‌های جغرافیایی نقشه‌های نمادین. PLoS ONE 2017 , 12 , e0176387. [ Google Scholar ]
  21. TopoJSON. سایت اینترنتی. در دسترس آنلاین: https://github.com/topojson/topojson-specification (در 25 مه 2020 قابل دسترسی است).
  22. لیو، جی. لی، اچ. یونگ، جی. هائو، ی. Dan, J. یک شاخص مبتنی بر geohash برای مدیریت داده های مکانی در حافظه توزیع شده. در مجموعه مقالات کنفرانس بین المللی ژئوانفورماتیک، کائوسیونگ، تایوان، 25 تا 27 ژوئن 2014. [ Google Scholar ]
  23. نی، ی. ژو، دبلیو. ژیان، S. شاخص فضایی برای خدمات نقشه کاشی بر اساس منحنی Z. J. نمودار تصویر. 2012 ، 2 ، 286-292. (به زبان چینی) [ Google Scholar ]
  24. راموس، JAS؛ اسپرانا، سی. Clua, EWG یک مرورگر نقشه برداری پیش رونده برای وب. جی. براز. محاسبه کنید. Soc. 2009 ، 15 ، 35-48. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  25. وان، ال. هوانگ، ز. Peng, X. یک رویکرد مدیریت کاشی نقشه برداری موثر مبتنی بر NoSQL. ISPRS Int. J. Geo-Inf. 2016 ، 5 ، 215. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  26. ژانگ، جی. یانگ، سی. یانگ، کیو. لین، ی. Zhang, Y. HGeoHashBase: یک مدل ذخیره سازی بهینه از اشیاء فضایی برای خدمات مبتنی بر مکان. جلو. محاسبه کنید. علمی چین 2018 ، 14 ، 208-218. [ Google Scholar ] [ CrossRef ]
  27. ژو، ی. د، اس. وانگ، دبلیو. موسنر، ک. پالانیسوامی، M. نمایه سازی فضایی برای جستجوی داده ها در محیط های حسگر موبایل. Sensors 2017 ، 17 ، 1427. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  28. Deoliveira, J. GeoServer: Uniting GeoWeb و زیرساخت های داده های مکانی. در مجموعه مقالات دهمین کنفرانس بین المللی زیرساخت داده های مکانی، پکن، چین، 25 تا 29 فوریه 2008. [ Google Scholar ]
  29. دمنده، JD; جمل، آل. گریفیث، جی اچ. هاینز، ک. سانتوخی، ا. Yang, X. یک سرویس نقشه وب برای تجسم داده های محیطی شبکه بندی شده چند بعدی. محیط زیست مدل. نرم افزار 2013 ، 47 ، 218-224. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  30. زاوالا-رومرو، او. احمد، ع. Chassignet، EP; زاوالا-هیدالگو، جی. فرناندز اگیارته، آ. Meyer-Baese, A. یک برنامه تحت وب جاوا منبع باز برای ساخت سایت های GIS وب مستقل. محیط زیست مدل. نرم افزار 2014 ، 62 ، 210-220. [ Google Scholar ] [ CrossRef ]
  31. جزوه-یک کتابخانه جاوا اسکریپت منبع باز برای نقشه های تعاملی سازگار با موبایل. سایت اینترنتی. در دسترس آنلاین: https://leafletjs.com/ (در 29 ژوئن 2020 قابل دسترسی است).
  32. ادلر، دی. Vetter، M. سادگی نقشه‌نگاری وب سمعی و بصری مدرن: نمونه‌ای با برگه کتابخانه جاوا اسکریپت منبع باز.js. KN J. Cartogr. Geogr. Inf. 2019 ، 69 ، 51–62. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  33. برامبیلا، جی. آمورتی، ام. Zanichelli، F. Adgt.js: چارچوب برنامه کاربردی وب برای خدمات مبتنی بر مکان همتا به همتا. در کنفرانس اروپایی پردازش موازی ; Springer: Cham، Switzerland، 2016. [ Google Scholar ]
  34. هاکلی، م. Weber, P. OpenStreetMap: نقشه های خیابانی توسط کاربر. محاسبات فراگیر IEEE 2008 ، 7 ، 12-18. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Ijgi 09 00418 g001 550
شکل 1. نمودار شماتیک تقسیم Geohash و شاخص منحنی Z [ 27 ].
Ijgi 09 00418 g002 550
شکل 2. چارچوب عملکردی سیستم GeohashTile.
Ijgi 09 00418 g003 550
شکل 3. مقایسه فرآیند داده آماده سازی GeoJSON اصلی و GeoJSON رمزگذاری شده توسط سرور.
Ijgi 09 00418 g004 550
شکل 4. یک نمودار نمونه از شی GeoJSON رمزگذاری شده Geohash.
Ijgi 09 00418 g005 550
شکل 5. روند نمایش نقشه برداری Geohash از مشتری.
Ijgi 09 00418 g006 550
شکل 6. نمودار شماتیک متحرک مکان مشتری.
Ijgi 09 00418 g007 550
شکل 7. نمودار طول رمزگذاری Geohash و آمار دقیق مختصات صفحه نمایش.
Ijgi 09 00418 g008a 550 Ijgi 09 00418 g008b 550
شکل 8. مقایسه نتایج اندازه گیری و محاسبه شده از دقت رمزگذاری Geohash: ( الف ) سنگاپور. ( ب ) هاینان؛ ج ) پکن؛ ( د ) هیلونگجیانگ.
Ijgi 09 00418 g009 550
شکل 9. نمودارهای مقایسه میزان انتقال داده در میان GeoTile، GeohashTileNoMerging و GeohashTileFull: ( الف ) سنگاپور. ( ب ) هاینان؛ ( ج ) پکن؛ ( د ) هیلونگجیانگ.
Ijgi 09 00418 g010 550
شکل 10. نمودارهای مقایسه زمان بارگذاری بین GeoTile، GeohashTileNoCahcing و GeohashTileFull: ( الف ) سنگاپور. ( ب ) هاینان؛ ( ج ) پکن؛ ( د ) هیلونگجیانگ.

مقالات داخلی و بین المللی

مطالب مرتبط ...

بدون دیدگاه

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