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

کلید واژه ها:

داده کاوی مکانی ; NLP geospatial ; ادغام داده های جغرافیایی ; پردازش جغرافیایی در مقیاس بزرگ ; ناوبری عابر پیاده ; دسترسی فیزیکی

1. مقدمه

دسترسی به عنوان یک اصل کلی از کنوانسیون ملل متحد در مورد حقوق افراد دارای معلولیت در نظر گرفته می شود و کشورهای عضو متعهد می شوند که در دسترس بودن و استفاده از فناوری های جدید مناسب برای افراد دارای معلولیت را ارتقا دهند. به طور خاص، فناوری‌های اطلاعات و ارتباطات می‌توانند برای کمک به مردم برای یافتن راه خود در شهرها و اجتناب از موانع و موانع دسترسی استفاده شوند. چندین مطالعه تحقیقاتی قبلاً بر تسهیل ناوبری برای افراد با توانایی‌های متنوع در شهرهای هوشمند متمرکز شده‌اند. مطالعه در مرجع [ 1] مروری بر ادبیات سیستماتیک برخی از مؤلفه‌های فناوری که بلوک‌های سازنده دسترسی هوشمند هستند و مقایسه فناوری‌های موجود و مطالعات موردی را ارائه می‌کند. اکثر راه حل های موجود یک دستیار مسیریابی مبتنی بر برنامه تلفن همراه را برای برنامه ریزی سفر درب به خانه در فضای باز با استفاده از داده های حس شده جزئی (عمدتاً مبتنی بر منبع تک) ارائه می دهند. با این حال، یک رویکرد جامع باید حسگرهای نرم‌افزار و سخت‌افزار را ترکیب کند تا به‌طور پویا و یکپارچه موانعی را که افراد با توانایی‌های متنوع را تحت تأثیر قرار می‌دهند شناسایی کند تا مسیرهای بدون مانع برای آنها ارائه شود. چنین سیستم اطلاعاتی مستلزم یکپارچه‌سازی داده‌هایی است که از منابع ناهمگونی مانند اطلاعات جغرافیایی، ابرهای نقطه LiDAR، حسگرهای سخت‌افزار، شبکه‌های اجتماعی و اطلاعات داوطلبانه کاربر به دست می‌آیند.
این مقاله بر پر کردن برخی از شکاف‌های شناسایی شده قبلی برای توسعه فناوری زیر تمرکز دارد که به هر شهر هوشمند امکان می‌دهد دستیارهای تحرک بدون مانع ایجاد کند که با محدودیت‌های خاص هر شهروند سازگار باشد. فناوری توسعه‌یافته اجازه ساخت لایه‌هایی از اطلاعات عناصر شهری را می‌دهد که بر تحرک کاربر در فضاهای عمومی با به دست آوردن دانش از منابع باز موجود در اینترنت، از حسگرهای ژئوماتیک (مانند حسگرهای LiDAR) و با استفاده از تکنیک‌های داده‌های سنجش جمعیت از حسگرهای سخت‌افزاری و نرم‌افزاری که توسط خود کاربران شهر تولید یا ضبط شده‌اند، به‌ویژه آن‌هایی که در دستگاه‌های موبایل یا پوشیدنی جاسازی شده‌اند که توسط شهروندان حمل می‌شوند (مانند شتاب‌سنج، ژیروسکوپ،
شکل 1چارچوب کلی این مقاله را نشان می دهد. سمت چپ منابع داده در نظر گرفته شده در مقاله را برمی شمارد. OpenStreetMap برای بازیابی اطلاعات جغرافیایی در مورد نقاط مورد علاقه (مثلاً مقصدها، فضاهای پارک معلولان) و شبکه پیاده رو استفاده می شود. یک جزء نرم افزاری توسعه یافته با استفاده از جاوا امکان اتوماسیون فرآیند جمع آوری داده ها را با استفاده از وظایف تعریف شده با استفاده از یک زبان اعلامی مبتنی بر JSON که وظایف برداشت و وظایف پردازش تعریف شده در SQL را ترکیب می کند، می دهد. ما الگوریتم یک کار پردازشی خاص را توصیف می کنیم که شبکه پیاده رو را از شبکه جاده OpenStreetMap می سازد. داده‌های LiDAR از مکان‌های انتخابی شهر با استفاده از دستگاه‌های تلفن همراه LiDAR گرفته می‌شود. ابرهای جمع‌آوری‌شده توسط یک مؤلفه پایتون پردازش می‌شوند که شبکه پیاده‌روی را که قبلاً ایجاد شده بود، اصلاح می‌کند (به عنوان مثال، بهبود گذرگاه های عابر پیاده) و موانع موجود در پیاده روها (یعنی رمپ ها و پله ها) را تشخیص می دهد. موانع شناسایی‌شده از داده‌های LiDAR به‌صورت ناهمزمان پردازش می‌شوند، زیرا تیم‌های نظرسنجی و دستگاه‌های موبایل LiDAR نمی‌توانند به‌طور دائم مستقر شوند. با این حال، اطلاعات داوطلبانه کاربر جمع‌آوری‌شده با استفاده از یک برنامه تلفن همراه توسعه‌یافته در جاوا برای دستگاه‌های Android به‌صورت همزمان و تقریباً هم‌زمان پردازش می‌شود. این نرم افزار مسائل مربوط به دسترسی را جمع آوری می کند که به صراحت توسط کاربران گزارش شده است و از حسگرهای موبایل دستگاه (یعنی ژیروسکوپ، مغناطیس سنج، شتاب سنج و حسگر گرانش) برای شناسایی و گزارش موانع با استفاده از یک شبکه عصبی کانولوشنال که با استفاده از مدل Keras پیاده سازی شده است، استفاده می کند. در نهایت، یک مؤلفه پایتون از API استریم توییتر برای انتخاب توییت‌های مرتبط با استفاده از کلمات کلیدی استفاده می‌کند. و سپس از اطلاعات توییت و تکنیک های پردازش زبان طبیعی برای استخراج مکان توییت و گزارش یک مانع استفاده می کند. تمام اطلاعات جمع‌آوری‌شده در یک مدل داده‌های دسترسی نشان داده می‌شود که شبکه عابر پیاده، مقصدها، مکان‌های پارک معلولان و موانع دسترسی را که بر شبکه تأثیر می‌گذارد، توصیف می‌کند. در نهایت، یک برنامه وب مترقی که با استفاده از Vue.js و یک باطن جاوا توسعه یافته است، به کاربر اجازه می دهد تا یک مسیر در دسترس شامل موانع احتمالی را محاسبه کند.
اولین مشارکت این مقاله، معماری یک سیستم اطلاعاتی برای ذخیره و تجزیه و تحلیل اطلاعات در یک پایگاه داده مکانی-زمانی است که تمام منابع داده های حس شده فوق را برای به دست آوردن فهرستی از عناصر موجود در محیط شهری و در دسترس شهروندان دارای معلولیت ادغام می کند. . سهم دوم مقاله، الگوریتم‌های خاصی برای ایجاد یک شبکه عابر پیاده از منابع داده باز و بهبود شبکه با استفاده از حسگرهای LiDAR، برای یافتن موانع دسترسی هم به صورت ناهمزمان (با استفاده از داده‌های LiDAR و یک رویکرد ژئوماتیک) و هم به صورت همزمان (با استفاده از داده‌های داوطلبانه کاربر از حسگرهای موبایل و رویکرد یادگیری ماشین)، و برای یافتن موانع گزارش شده توسط کاربر با استفاده از داده‌های توییتر و پردازش زبان طبیعی.
این مقاله به شرح زیر سازماندهی شده است – بخش 2 به ارائه کار مرتبط اختصاص دارد. معماری سیستم به طور کامل در بخش 3 ارائه شده است. بخش 4 جزئیات پیاده سازی را شرح می دهد. مطالعه موردی کاربرد سیستم ما در بخش 5 توضیح داده شده است . بخش 6 به جمع آوری نتایج اصلی این مقاله تحقیقاتی اختصاص دارد.

2. کارهای مرتبط

گرایش‌های اخیر در فناوری‌های اطلاعات و ارتباطات منجر به بسیاری از فن‌آوری‌های مختلف جمع‌آوری داده‌ها و منابع داده شده است که می‌توانند اطلاعات ارزشمندی را در اختیار یک سیستم اطلاعاتی قرار دهند که یک مسیر قابل دسترس را در یک شهر هوشمند محاسبه می‌کند. اطلاعات جغرافیایی داوطلبانه کاربر می تواند پایه و اساس سیستم را فراهم کند، در حالی که حسگرها و حسگرهای LiDAR در دستگاه های تلفن همراه می توانند اطلاعات دقیقی را برای مرزهای بیرونی و داخلی ارائه دهند. علاوه بر این، شبکه‌های اجتماعی منبع ارزشمندی برای جمع‌آوری اطلاعات بلادرنگ در مورد موانع دسترسی فراهم می‌کنند. این بخش کارهای مرتبط با این منابع داده را شرح می دهد.
جمع آوری داده ها در مورد دسترسی در سطح خیابان یک کار بسیار پیچیده است. حتی پروژه های بسیار دشواری وجود دارد که هدف آنها جمع آوری داده های دسترسی پیاده رو است [ 2 ، 3]، پوشش فعلی این ابزارها محدود است. OpenStreetMap (OSM) در هدف خود برای ایجاد و توزیع اطلاعات جغرافیایی برای جهان موفق بوده است. با این حال، OSM برای مسیریابی وسایل نقلیه (به عنوان مثال، خطوط مرکز جاده نشان داده می شوند، اما پیاده روها) و تجسم نقشه (یعنی گذرگاه های عابر پیاده به عنوان نقاط نشان داده می شوند) بسیار مغرضانه است. بنابراین، تا زمانی که پوشش منابع در دسترس عموم به اندازه کافی بالا نباشد، برای ساخت یک مدل داده دسترسی، لازم است فرآیندهای داده کاوی بر روی داده های موجود انجام شود و الگوریتم هایی برای ساخت شبکه های پیاده رو و گذرگاه عابر پیاده از داده های جمع آوری شده تعریف شود.
از آنجایی که دسترسی فیزیکی به هندسه محیط بستگی دارد، ابرهای نقطه ای منبع ارزشمندی از اطلاعات هستند، زیرا آنها به طور دقیق، به صورت سه بعدی و در بزرگی واقعی، محیطی را که توسط تجهیزات LiDAR به دست می آید، نشان می دهند. بسیاری از آثار بر روی تشخیص محدودیت به عنوان عناصر دسترسی تمرکز دارند [ 4 ، 5 ]. حاشیه ها به راحتی تشخیص داده می شوند، زیرا در بیشتر موارد، آنها عناصر عمودی هستند که دو سطح افقی (پیاده روها و جاده ها) را به هم متصل می کنند و دید مستقیمی از مسیر اسکنر لیزری موبایل دارند. اما محدودیت ها تنها عناصر زمینی مهم برای دسترسی فیزیکی نیستند. در مرجع [ 6]، عناصر زمین شهری تقسیم بندی شده و بر اساس ویژگی های هندسی و توپولوژیکی، در پیاده روها، جاده ها، حاشیه ها و پله ها (تقسیم بندی شده به بالابرها و نخ ها) طبقه بندی می شوند. روش های مختلفی برای تشخیص پله ها بر اساس هندسه آنها به عنوان مجموعه ای از سطوح افقی و عمودی وجود دارد. در نمایش پله ها به عنوان هیستوگرام، پله ها به عنوان دنباله ای از قله های منظم قابل شناسایی هستند [ 7 ]. مورفولوژی ریاضی اعمال شده برای ابرهای نقطه ای نیز برای تشخیص مراحل زمانی که یک مرحله به عنوان یک عنصر ساختاری استفاده می شود عمل می کند [ 8 ]. علاوه بر شناسایی عناصر، ارزیابی وضعیت و ابعاد آنها برای بررسی قابلیت دسترسی آنها ضروری است. در مرجع [ 9 ]، پیاده روها شناسایی شده و عرض آنها اندازه گیری می شود. در مرجع [10 ]، ویژگی های دیگری مانند شیب متقاطع، درجه و شیب رمپ حاشیه در پیاده روها و رمپ ها استخراج شده است. در مرجع [ 11 ]، فضای آزاد و بدون مانع باقی مانده توسط موانع در زمین قابل کشتیرانی برای پروفایل افراد بدون تحرک کم و افراد روی صندلی چرخدار محاسبه شده است.
همه روش‌های تشخیص زمانی کارایی خود را بهبود می‌بخشند که مکان احتمالی از قبل مشخص باشد. برخی از روش‌ها بر تشخیص پله‌ها و/یا رمپ ورودی‌های داخلی [ 12 ]، ورودی‌های ساختمان و تقاطع جاده-پیاده‌روها [ 13 ] و محیط‌های گذرگاه [ 14 ] متمرکز بودند. برخلاف سایر عناصر، تقاطع های گورخر در ابرهای نقطه ای به دلیل هندسه قابل تشخیص نیستند، بلکه به دلیل رنگ بازتابنده، که مقادیر اوج را در ویژگی شدت تولید می کند [ 15 ]. جایگزین دیگری برای جستجوی اشکال هندسی در ابر نقطه از طریق مدل سازی بدن انسان است. در نظر گرفتن بدن انسان چند وجهی [ 16 ] یا مدلی با 41 درجه آزادی [ 17 ]] می تواند توسط محیط حرکت کند تا موانع، پله ها، شیب زمین و دید علائم را تشخیص دهد. به روشی مشابه بدن انسان، برخی از روبات‌های انسان‌نما که برای بالا رفتن از پله‌ها طراحی شده‌اند، حسگرها و نرم‌افزارهای ثبت داده‌های سه بعدی را برای تشخیص پله‌ها و محاسبه حرکت لازم برای بالا رفتن از پله‌ها ادغام می‌کنند [ 18 ، 19 ].
استفاده از حسگرها در دستگاه‌های تلفن همراه انقلابی را در زمینه‌های مختلف مانند سنجش محیطی، سلامت، تشخیص فعالیت یا برنامه‌های اجتماعی ایجاد می‌کند [ 20 ]. داده‌های شتاب‌سنجی همراه با مکان سیار که در رفت‌وآمدهای شهری اعمال می‌شود، امکان تشخیص و موقعیت‌یابی رویدادهایی مانند سقوط [ 21 ] و مشکل در راه رفتن را فراهم می‌کند . حسگرهای نور امکان تشخیص مناطقی با نور کافی در شب را فراهم می کنند. میکروفون اجازه می دهد تا از مکان هایی با سطح نویز بالا عکس بگیرید. با وجود پتانسیل زیربنایی، تا به امروز، بیشتر کارها بر روی استفاده از حسگرهای پوشیدنی و پوشیدنی برای تشخیص کاربر محور مبتنی بر تشخیص فعالیت (به ویژه آنهایی که شامل حرکات دوره ای در طول زمان هستند) بوده است [ 23 ]]. تشخیص فعالیت گاهی منجر به شناسایی محیطی می شود که این فعالیت ها در آن انجام می شود (به عنوان مثال، بالا رفتن از پله ها مستلزم تشخیص و شمارش تعداد پله ها و همچنین سهولت یا دشواری بالا رفتن از آنها برای کاربر است). با این حال، پتانسیلی که ترکیب اطلاعات گرفته شده توسط حسگرهای مختلف در دستگاه های تلفن همراه برای تشخیص عناصر شهری با تأثیر بر تحرک فرض می کند، هنوز در بسیاری از موارد قابل بررسی است. از سوی دیگر، سنسورهای موبایل (یا حسگرهای معادل آن در دستگاه‌های پوشیدنی مانند ساعت‌ها یا دستبندهای هوشمند) نه تنها امکان تشخیص عناصر شهری را فراهم می‌کنند، بلکه هزینه عبور از این عناصر شهری را از نظر فیزیکی و ذهنی نیز برای کاربر تعیین می‌کنند. بار [ 24]. برخی از مزایای سیستم‌های تشخیص مبتنی بر سنجش جمعیت با استفاده از حسگرهای چند کاربر تلفن همراه را می‌توان در مرجع [ 25 ] مشاهده کرد، که امکان به‌روزرسانی مداوم عناصر حس‌شده با تأخیرهای تشخیص کوچک را فراهم می‌کند.
چندین اثر تحقیقاتی را می توان در حالت پیشرفته یافت که از داده های استخراج شده از شبکه های اجتماعی برای شناسایی رویدادهای زمان واقعی استفاده می کنند. یکی از اولین و محبوب‌ترین نمونه‌ها، کار ساکاکی و همکاران است. [ 26 ]. نویسندگان سیستمی را توسعه دادند که داده های توییتر را از کاربران ژاپنی توییتر جمع آوری می کرد. آنها توانستند 96 درصد از زمین لرزه های گزارش شده توسط آژانس هواشناسی ژاپن را شناسایی کنند. در بسیاری از موارد سامانه آنها قبل از انتشار توسط آگهی های سازمان هواشناسی می توانست زلزله ها را گزارش کند.
در زمینه شهرهای هوشمند، می‌توان آثار متعددی را پیدا کرد که از داده‌های توییتر برای شناسایی رویدادها استفاده می‌کنند. Metro Averías [ 27 ] سیستمی است که شکایات کاربران توییتر را در مورد مترو مادرید، سیستم حمل و نقل زیرزمینی مادرید جمع آوری می کند. علاوه بر این، این سیستم گزارش هایی را در مورد بیشترین شکایات در هر خط منتشر می کند و در مورد خرابی های احتمالی در حساب توییتر @metroaverias هشدار می دهد. آثار متعددی را می‌توان در حالت پیشرفته یافت که سیستم‌هایی را توسعه می‌دهند که داده‌ها را از شبکه‌های اجتماعی استخراج می‌کنند تا رویدادهای ترافیکی مانند تصادفات یا ترافیک را شناسایی کنند. از آن جمله می توان به آثار آناستازی و همکاران اشاره کرد. [ 28 ] و کومار و همکاران. [ 29 ]. در نهایت، Wanichayapong و همکاران. [ 30] سیستمی را توسعه داد که داده‌های توییتر را برای تشخیص رویدادهای ترافیکی، اما خطرات انسداد و شرایط جاده استخراج می‌کند. آنها کار خود را بر روی تشخیص رویدادهای حمل و نقل در جاده ها و بزرگراه ها متمرکز می کنند. آنها از یک فرهنگ لغت با مکان ها و افعال نوشته شده به زبان تایلندی استفاده می کنند، جایی که مکان ها نام های مربوط به جاده ها و عناصر آنها و افعال اصطلاحات مربوط به مشکلات ترافیکی هستند. سپس توییت‌هایی را جمع‌آوری کردند که حاوی حداقل یک اصطلاح از فرهنگ لغت Places و اصطلاح دیگری از فرهنگ لغت افعال بود و توییت‌هایی را که حاوی عبارات ناسزا یا رکیک بودند فیلتر کردند.

3. معماری سیستم

شکل 2 معماری FlatCity را نشان می دهد ، سیستمی که ما برای ایجاد یک دستیار تحرک ایجاد کرده ایم که اطلاعات را از چندین منبع داده ناهمگن یکپارچه می کند. شکل سه جزء اصلی سیستم را نشان می دهد. مولفه سمت چپ بالا (یعنی  Ingestion ) مؤلفه جذب داده را نشان می دهد که مسئول جمع آوری داده ها از چندین منبع برای ساخت مدل دسترسی شهر است. اطلاعات جمع‌آوری‌شده و پردازش‌شده در مؤلفه مدل داده‌های دسترسی که در پایین شکل نشان داده شده است، ذخیره می‌شود. در نهایت، مولفه بالا سمت راست که نشان دهنده برنامه هایی است که برای محاسبه دسترسی ترین مسیرها به کاربران سیستم ارائه می شود.
شکل 3 یک نمودار جزء UML از معماری زیرسیستم بلع Flatcity را نشان می دهد. این یک معماری لایه ای با چهار لایه است. لایه بالایی ( منابع داده ) شامل چهار منبع داده ای است که در حال حاضر در Flatcity در نظر گرفته می شوند: OpenStreetMap، تیم های نقشه برداری با استفاده از اسکنرهای موبایل LiDAR، کاربران شهر هوشمند ارائه اطلاعات داوطلبانه از نظر جمعیت و توییتر. لایه دوم ( گردآورنده داده) متشکل از اجزایی است که وظیفه جمع آوری اطلاعات از منابع داده و ارسال آن به back-end را بر عهده دارند. این لایه استقلال سیستم را از منابع داده فراهم می کند به طوری که امکان اصلاح آنها بدون تغییر در سیستم دریافت وجود دارد. علاوه بر این، از آنجایی که در اجزای مستقل کوچک سازماندهی شده است، می توان آنها را به روشی ساده تر در زیرساخت های محاسبات ابری توزیع کرد. لایه سوم ( مصرف داده ها ) مؤلفه ای است که نقاط پایانی REST را برای دریافت اطلاعات از منابع داده ارائه می دهد و آن را در مدل داده ذخیره می کند. به نوبه خود به عنوان مجموعه ای از خدمات مستقل ( شبکه API ، Accessibility API ، Obstacle API ، Issue API ) ساختار یافته است.و Social API ، که به عنوان اجزاء در شکل نشان داده نشده است) برای پشتیبانی از تعادل بار. لایه پایینی مدل داده دسترسی Flatcity است که در پایگاه داده PostgreSQL ذخیره شده است.
اولین منبع داده ای که در Flatcity در نظر می گیریم OpenStreetMap است. مؤلفه OSM Harvester وظیفه بازیابی تمام اطلاعات مربوط به دسترسی را برای کل منطقه مورد علاقه (معمولاً کل شهر) و پردازش آن برای ایجاد شبکه خیابانی و جمع آوری مکان های پارکینگ کم تحرک، مقصدها و پردازش می کند. ورودی های کم تحرک آنها اطلاعات جمع‌آوری‌شده از OpenStreetMap به‌عنوان اطلاعات پایه برای Flatcity استفاده می‌شود که پس از آن با اطلاعات جمع‌آوری‌شده از سایر منابع داده پالایش می‌شود. برداشت کننده OSMکامپوننت باید با این مشکل مقابله کند که داده‌های OpenStreetMap برای نشان دادن جاده‌ها طراحی شده‌اند، اما پیاده‌روها، گذرگاه‌های عابر پیاده و سایر زیرساخت‌های شهر برای عابران پیاده و نه برای وسایل نقلیه طراحی شده‌اند. بنابراین،  مؤلفه OSM Harvester باید یک شبکه پیاده رو با استفاده از اطلاعات جمع آوری شده از OpenStreetMap بسازد. این فرآیند با جزئیات بیشتر در بخش 4.1 توضیح داده شده است .
منبع داده دوم یک تیم نقشه برداری است که از LiDAR موبایل برای کشف موانع دسترسی استفاده می کند. یک تیم مجهز به یک اسکنر لیزری سیار در مناطق خاص مورد علاقه رانندگی یا راه می‌روند و یک ابر نقطه را جمع‌آوری می‌کنند. ابر نقطه توسط مولفه پردازنده LiDAR پردازش می شود و اطلاعات دقیق در مورد دسترسی (یعنی رمپ ها، پله ها و گذرگاه های عابر پیاده) جمع آوری می شود. اطلاعات جمع‌آوری‌شده توسط این مؤلفه می‌تواند برای بهبود اطلاعات پایه جمع‌آوری‌شده از OpenStreetMap در مناطقی از شهر که داده‌های OpenStreetMap ضعیف است یا در مناطقی از شهر که علاقه خاصی به دسترسی وجود دارد (مانند بیمارستان‌ها یا سایر ساختمان‌های عمومی) استفاده شود. ). اطلاعات ارائه شده توسط پردازنده LiDARمؤلفه در back-end انتقال بسیار دقیق تر از اطلاعات جمع آوری شده از OpenStreetMap است. بنابراین، بک‌اند بلع باید یک فرآیند ترکیبی را انجام دهد تا اطلاعات OSM درشت دانه را با داده‌های LiDAR ریز دانه یکپارچه کند. فرآیندهای تشخیص و ادغام در  بخش 4.2 توضیح داده شده است.
سومین منبع داده یک اپلیکیشن موبایل برای کاربران شهر هوشمند است. دو نوع مختلف از اطلاعات داوطلبانه کاربر قابل بازیابی است. ابتدا می توان از سنسورهای موبایل دستگاه برای شناسایی و گزارش موانع استفاده کرد. دوم، کاربران ممکن است به صراحت مشکلات دسترسی را گزارش کنند. برنامه تلفن همراه اطلاعات را جمع آوری می کند و آن را به پشتیبان انتقال می فرستد. این اطلاعات می تواند برای ارائه جزئیات بیشتر در مورد داده های OpenStreetMap در مناطقی که اطلاعات LiDAR قابل جمع آوری نیست (مثلاً مناطق خصوصی) یا در مناطقی که به دلیل هزینه بازیابی اطلاعات نمی توانند با اطلاعات LiDAR پوشش داده شوند، استفاده شود. همچنین، به دلیل محدودیت‌های هزینه، اپلیکیشن موبایل می‌تواند به به روز نگه داشتن اطلاعات مربوط به موانع کمک کند (ما انتظار داریم در یک سناریوی واقعی استفاده از دستگاه‌های LiDAR به صورت پراکنده مورد استفاده قرار گیرد).بخش 4.3 .
چهارمین منبع داده، مشکلات دسترسی گزارش شده در توییتر است. یک حسگر نرم‌افزار (به نام T-Hoarder ) برای فیلتر کردن API استریم توییتر با استفاده از کلمات کلیدی مرتبط استفاده می‌شود. برای هر توییتی که دریافت می‌شود، T-Hoarder موقعیت جغرافیایی توییت را استخراج می‌کند (خواه به این دلیل که توسط کاربر ارائه شده است یا از متن استخراج شده است). سپس، T-Hoarder مشکل را به بک‌اند مصرف Flatcity گزارش می‌کند. جزء با جزئیات بیشتر در بخش 4.4 توضیح داده شده است .
شکل 4 مدل داده ای را نشان می دهد که توسط جزء Accessibility Data Model مدیریت می شود. کلاس های Edge و Node در بالای مدل داده، نمودار شبکه زیرساخت عابر پیاده شهر را نشان می دهند. هر لبه دارای دو ویژگی است که نشان دهنده هزینه سفر لبه در هر دو جهت است (یعنی  normal_cost و reverse_cost ). همچنین دارای یک ویژگی است که سطح دسترسی لبه را نشان می دهد (یعنی  دسترسی). مقدار 1 در این ویژگی نشان می دهد که هر کسی می تواند از لبه عبور کند. از طرف دیگر، مقدار 0 نشان می دهد که یک یال با موانع است که فقط توسط یک فرد غیر معلول می تواند عبور کند. مقادیر بین 0 و 1 را می توان برای نشان دادن سطوح مختلف موانع در لبه استفاده کرد. در نهایت، کلاس Edge نیز دارای یک ویژگی است که نشان دهنده مسیر جغرافیایی لبه است (یعنی  مسیر ).
کلاس Accessibility Barrier در سمت چپ مدل داده، موانعی را نشان می دهد که توسط اپلیکیشن موبایل برای کاربران شهر هوشمند و حسگر نرم افزار توییتر شناسایی می شوند. کلاس دارای یک ویژگی برای نشان دادن تاریخی است که در آن شناسایی رخ داده است (یعنی  date_detected ) تا موانعی را که ممکن است منسوخ شده اند نادیده بگیرد. این کلاس همچنین می‌تواند موقعیت جغرافیایی مانع (یعنی  مکان ) را با استفاده از نوع داده‌های Geometry عمومی نشان دهد تا نه تنها از نقاط، بلکه از خطوط و سطوح نیز استفاده شود. در نهایت، قابلیت اطمینان ویژگی نشان دهنده اطمینان از تشخیص برای اطلاع کاربر از احتمال واقعی بودن موانع است. کلاسموانع دسترس‌پذیری به دو دسته اختصاص داده شده است تا هر یک از انواع موانعی که در حال حاضر توسط FlatCity پشتیبانی می‌شوند را نشان دهد: موانعی که از توییت‌ها شناسایی می‌شوند و مواردی که با استفاده از برنامه تلفن همراه شناسایی می‌شوند. کلاس توییت شامل نوع تشخیص مورد استفاده برای استخراج موقعیت جغرافیایی توییت است (یعنی موقعیت جغرافیایی، ارجاع جغرافیایی یا استخراج با استفاده از پردازش زبان طبیعی؛ جزئیات بیشتر را می‌توانید در  بخش 4.4 بیابید )، آدرس شناسایی‌شده و URL توییت. کلاس Mobile-Detected فقط شامل نوع عنصر شناسایی شده است. کلاس Accessibility Barrier به لبه های شبکه که تحت تأثیر مانع قرار می گیرند مرتبط است. ارتباط کلیشه ای به عنوان «فضایی» است.نشان می دهد که لبه های تحت تأثیر هر مانع را می توان با استفاده از یک پرس و جو فضایی شامل اطلاعات جغرافیایی در هر دو کلاس شناسایی کرد.
کلاس هایی که نشان دهنده مکان های احتمالی است که کاربر می تواند به عنوان مقصد مسیر نشان دهد در سمت راست مدل داده نشان داده شده است. از یک طرف،  کلاس پارکینگ معلولین نشان دهنده مکان های پارکینگ کم تحرک موجود در شهر است. ظرفیت مشخصه می تواند برای نشان دادن اینکه بیش از یک مکان پارکینگ در یک مکان واحد وجود دارد استفاده شود. از طرف دیگر، کلاس Destination نقاط مورد علاقه احتمالی را نشان می دهد که می توانند به عنوان نقطه پایانی یک مسیر استفاده شوند. این کلاس شامل ویژگی هایی برای نشان دادن نام مقصد، نوع مقصد و موقعیت جغرافیایی است. علاوه بر این، هر مقصد شامل مجموعه‌ای از ورودی‌ها است (که توسط ورودی نشان داده می‌شودکلاس). این اجازه می دهد تا مقاصدی که ساختمان های بزرگ با ورودی های متعدد هستند به اندازه کافی نشان داده شوند. علاوه بر این، هر ورودی شامل ویژگی دسترسی با همان معنایی است که برای لبه ها توضیح داده شد. بنابراین، دشواری استفاده از هر ورودی خاص از یک ساختمان بزرگ را می توان توصیف کرد.
شکل 5 معماری برنامه هایی را نشان می دهد که می توانند توسط کاربران شهر هوشمند برای محاسبه مسیرهای قابل دسترسی استفاده شوند. هر دو برنامه از مدل داده های دسترسی از طریق یک نقطه پایانی REST استفاده می کنند که در Accessibility Back-end پیاده سازی شده استجزء. دو برنامه مختلف ارائه شده است – یک برنامه وب و یک برنامه تلفن همراه. هر دو برنامه کاربردی برای یافتن مسیری از مبدأ معین به مقصد (انتخاب شده از مقصدهای نشان داده شده در مدل داده یا کلیک کردن بر روی نقشه) ارائه می کنند. در حالت کلی، مسیر در سه بخش محاسبه می‌شود: از مبدا تا محل خودروی کاربر، از خودرو تا نزدیک‌ترین مکان پارکینگ کم‌حرکت به مقصد، و از محل پارک تا ورودی مقصد. انتظار می رود کاربر در بخش اول و سوم راه برود و بنابراین مسیرها با استفاده از مدل داده دسترسی محاسبه می شوند . انتظار می‌رود که بخش میانی با خودرو و در نتیجه Accessibility Back-end انجام شودمحاسبات این بخش را به یک ارائه‌دهنده مسیر خارجی (به عنوان مثال GraphHopper ( https://www.graphhopper.com/ )، دستگاه مسیریابی منبع باز ( https://project-osrm.org/ )، یا Google Directions API واگذار می‌کند. ). برای اینکه برنامه بتواند مسیر را در این سه بخش محاسبه کند، قابلیت به خاطر سپردن مکانی را که خودرو در آن پارک شده است را فراهم می کند. علاوه بر این، کاربر همچنین می‌تواند مکان منزل خود را ذخیره کند تا از آن به عنوان مبدا یا مقصد مسیر استفاده کند.

4. اجرا

4.1. استخراج اطلاعات از OpenStreetMap

4.1.1. اتوماسیون فرآیند جمع آوری داده ها

مؤلفه OSM Harvester به گونه ای طراحی شده است که امکان خودکارسازی فرآیند جمع آوری داده های OpenSteetMap را فراهم کند. این امکان تعریف وظایف برداشت را فراهم می کند که مدل مفهومی آن در شکل 6 نشان داده شده است . هر وظیفه از سه عنصر تشکیل شده است. اولین مورد، پیکربندی وظیفه است که شامل اطلاعات اتصال به پایگاه داده هدف، طرح واره هدف که داده ها باید در آن کپی شوند و اقدامی که باید انجام شود، است. عمل می تواند یکی از موارد زیر باشد:
  • ایجاد کنید. قبل از وارد کردن داده های OSM، طرح را از ابتدا ایجاد می کند.
  • به روز رسانی . قبل از وارد کردن داده های OSM جدید، همه داده ها را از طرح حذف می کند.
  • ضمیمه _ داده های OSM جدید را به موجود در طرحواره اضافه می کند.
  • واردات . اسکریپت های وارداتی را بدون جمع آوری داده ها از OSM اجرا می کند.
دومین عنصر کار، تعریف برداشت است . در حال حاضر شامل کادر محدود کننده منطقه مورد نظر است، اما ما قصد داریم در آینده فیلترهایی را اضافه کنیم. ما از Overpass API ( https://overpass-api.de/ ) برای استخراج داده های OSM و اسمز ( https://github.com/openstreetmap/osmosis ) برای تجزیه و وارد کردن داده های OSM به پایگاه داده استفاده می کنیم. سومین عنصر وظیفه مجموعه ای از اسکریپت های وارداتی استکه باید پس از جمع آوری داده ها اجرا شود. ما در حال حاضر از اسکریپت های SQL پشتیبانی می کنیم، اما قصد داریم در آینده از سایر زبان های برنامه نویسی نیز پشتیبانی کنیم. فرآیندی که شبکه را می سازد که در بخش بعدی توضیح داده شد به عنوان یک اسکریپت SQL پیاده سازی می شود. فهرست 1 نمونه ای از اسکریپت OSM Harverster را نشان می دهد که بانک ها، داروخانه ها و سوپرمارکت ها را به جدول مقصد وارد می کند.
جدول
فهرست 1: نمونه ای از اسکریپت OSM Harverster .
4.1.2. ساخت شبکه
OpenStreetMap برای توصیف زیرساخت جاده ها برای وسایل نقلیه طراحی شده است. می توان پیاده روها را توصیف کرد، اما تنها حدود 1.8 میلیون بخش پیاده رو (1،805،845 بخش تا 5 نوامبر 2020 همانطور که در https://wiki.openstreetmap.org/wiki/Key:sidewalk ) در پایگاه داده OpenStreetMap در مقایسه وجود دارد. به بیش از 170 میلیون بخش جاده (170,086,925 بخش تا 5 نوامبر 2020 همانطور که در https://wiki.openstreetmap.org/wiki/Key:highway مشاهده شده است). علاوه بر این، گذرگاه‌های عابر پیاده در OpenStreetMap به‌عنوان نقاطی در بخش جاده به‌جای خطوط بین پیاده‌روها برچسب‌گذاری می‌شوند (3,069,077 نقطه در مقایسه با 822,689 خط تا 5 نوامبر 2020 همانطور که در https://wiki.openstreetmap.org/wiki/Key:crossing مشاهده می‌شود.). از این رو، برای ساخت شبکه ای که بتوان از آن برای محاسبه مسیرهای قابل دسترسی استفاده کرد، الگوریتمی را برای ساخت شبکه پیاده روها و گذرگاه های عابر پیاده طراحی کرده ایم.
الگوریتمی که ما طراحی کرده ایم ابتدا شبکه ای از پیاده روها را ایجاد می کند و سپس گذرگاه های عابر پیاده را بین پیاده روها ایجاد می کند. برای ساخت شبکه پیاده روها سه مورد را در نظر می گیریم:
  • بخش‌های جاده‌ای که به‌عنوان مراحل در OpenStreetMap برچسب‌گذاری شده‌اند، مستقیماً با مقدار دسترس‌پذیری تنظیم شده روی 0 گنجانده شده‌اند (یعنی فقط برای افراد غیرمعلول قابل استفاده هستند).
  • بخش‌های جاده‌ای که به‌عنوان پیاده‌رو، عابر پیاده، مسیر، یا مسیر در OpenStreetMap برچسب‌گذاری شده‌اند ، مستقیماً با مقدار دسترس‌پذیری تنظیم شده روی 1 گنجانده شده‌اند (یعنی فقط برای افراد غیرمعلول قابل استفاده هستند). به عنوان کار آینده، ما قصد داریم تا تجزیه و تحلیلی از امداد را برای یافتن رمپ های دشوار انجام دهیم.
  • ما یک بافر 4 متری در هر طرف از تمام بخش‌های جاده‌ای که در OpenStreetMap به عنوان بزرگراه برچسب‌گذاری نشده‌اند، می‌سازیم. سپس تمام بافرهای جاده را جمع آوری می کنیم تا هندسه سطح سنگفرش را بسازیم و مرز منطقه سنگفرش را به عنوان پیاده رو استخراج می کنیم. شکل 7 نمونه ای از این فرآیند را نشان می دهد. خطوط آبی تیره نشان دهنده بخش های جاده استخراج شده از OpenStreetMap است. سطوح آبی روشن نمایانگر منطقه سنگفرش شده است که با استفاده از یک بافر 4 متری در اطراف جاده ها ساخته شده است. خطوط سیاه نشان دهنده پیاده روها هستند که به عنوان مرز مناطق سنگفرش محاسبه شده اند. از این رو، ما فرض می کنیم که در هر طرف هر جاده یک پیاده رو وجود دارد که محدود به عابران پیاده نیست.
این الگوریتم فرض می کند که یک پیاده رو در دو طرف جاده وجود دارد. تأیید اینکه آیا این فقط با استفاده از داده های OpenStreetMap برقرار است یا خیر غیرممکن است. با این حال، می توان آن را با استفاده از داده های LiDAR تأیید کرد و پیاده روهایی را که وجود ندارند حذف کرد.
برای افزودن گذرگاه های عابر پیاده به شبکه، ابتدا از هر تقاطع تا هر قسمت پیاده رو که نزدیکتر از 8 متر است یک خط مستقیم ایجاد می کنیم. این یک الگوی ستاره مانند از هر گذرگاه تا پیاده رو ایجاد می کند. سپس تمام پاره های خطی را که پاره خط دیگری کوتاهتر و با اختلاف جهت کمتر از 45 درجه دارند حذف می کنیم. بخش های خط باقی مانده گذرگاه عابر پیاده در نظر گرفته می شود. شکل 8نمونه ای از این فرآیند را نشان می دهد. نقاط آبی تیره روشن گذرگاه های استخراج شده از OpenStreetMap را نشان می دهد. خطوط آبی روشن نشان دهنده الگوی ستاره مانند ایجاد شده از هر تقاطع به هر بخش پیاده رو نزدیکتر از 8 متر است. در نهایت، خطوط سبز نشان دهنده گذرگاه های عابر پیاده است که پس از حذف بخش های خط باقی مانده اند. نتیجه یک شبکه ساده تر از گذرگاه های عابر پیاده است که محاسبات مسیر را کارآمدتر می کند، حتی اگر هنوز گذرگاه های عابر پیاده اضافی وجود دارد که واقعی نیستند.

4.2. تشخیص شبکه و موانع از داده های LiDAR

4.2.1. تشخیص

عناصر تشکیل دهنده زمین شهری به طور خودکار با روش ارائه شده در مرجع [ 13 ] تقسیم و طبقه بندی می شوند]. داده های ورودی یک ابر نقطه ای از یک خیابان شهری با یک خط نما است. ابتدا، ناحیه نزدیک صفحه زمین ابر نقطه ای به عنوان منطقه مورد نظر (ROI) تعیین می شود و بر اساس الگوریتم RANSAC شناسایی می شود. سپس نرمال های سطح هر نقطه نسبت به نزدیکترین همسایه های آن محاسبه می شود تا شیب هر نقطه مشخص شود. نقاط عمودی برای محاسبه ارتفاع عناصر عمودی و تشخیص پله ها و حاشیه ها که ارتفاع آنها کمتر از h است، شطرنجی می شوند. در نهایت، با توجه به تمایل هر نقطه و روابط توپولوژیکی با سایر عناصر زمین، نقاط زمین به جاده ها، حاشیه ها یا رمپ ها، پیاده روها و پله ها یا رمپ ها تقسیم بندی و طبقه بندی می شوند.
تشخیص خطوط عابر پیاده، به عنوان عنصر اصلی دیگر در مسیریابی عابر پیاده در امتداد پیاده روها، بر اساس روش ارائه شده در مرجع [ 15 ] است. نقاط مربوط به عابر پیاده به دلیل ویژگی شدت قابل تشخیص هستند، زیرا رنگ بازتابنده پیک های شدت ایجاد می کند. هنگامی که نقاط با شدت بالا تشخیص داده می شوند، یک جعبه مرزی ایجاد می شود که کل خط عابر پیاده را به عنوان یک عنصر واحد گروه بندی می کند.
4.2.2. مدل سازی
فرآیند مدل‌سازی هر عنصر زمین از روش پیشنهادی در مرجع [ 31 ] اصلاح شده است: مدل‌سازی هر عنصر به طور جداگانه و بر اساس اندازه آن. پیاده روها بر اساس طول آنها مدل‌سازی می‌شوند و هر گره جدا شده برای ایجاد یک نقشه عابر پیاده مدل‌سازی می‌شوند. تعداد گره های هر بخش پیاده رو از تقسیم طول هر بخش بر d به دست می آید. سپس، الگوریتم k-means برای گروه نقاط پیاده رو نقاط اطراف هر گره آینده اعمال می شود. هر گره در مرکز هندسی هر گروه از نقاط قرار دارد. در نهایت، هنگامی که گره های پیاده رو قرار گرفتند، لبه های بین گره های پیاده رو بر اساس جستجوی گره های دیگر در فاصله d برآورد می شوند.
رمپ ها و پله های ورودی ساختمان به صورت یک گره واقع در مرکز هندسی هر عنصر مدل سازی شده اند. پس از آن، هر رمپ یا گره پله ای به نزدیکترین گره پیاده رو متصل می شود. خطوط عابر پیاده به صورت یک گره در مرکز هندسی مدل شده و به نزدیکترین گره پیاده رو متصل می شوند. اگر لبه ای که خط عابر پیاده را به پیاده رو متصل می کند از مجموعه ای از نقاط متعلق به حاشیه یا رمپ های حاشیه عبور کند، لبه با دو لبه جایگزین می شود و یک گره میانی (کلاس پله یا سطح شیب دار در صورت لزوم) ایجاد می شود که به پیاده رو متصل می شود. و گره های عابر پیاده. حاشیه‌ها و جاده‌ها مدل‌سازی نشده‌اند، زیرا عناصر ناوبری عابر پیاده نیستند. به این ترتیب نقشه عابر پیاده بر اساس پیاده روها با اطلاعات دسترسی در ورودی ساختمان ها و گذرگاه ها تولید می شود.
4.2.3. ادغام مدل LiDAR در مدل OSM
با توجه به نقشه پیاده رو و گذرگاه به دست آمده از OSM، و نقشه دقیق تر تولید شده از داده های LiDAR در بخش های فرعی قبلی، هدف از این فرآیند ادغام نقشه LiDAR در OSM، جایگزینی لبه های متناظر نقشه OSM است. در نقشه OSM، پیاده روها به عنوان خطوط و معابر به عنوان چند خط تعریف شده اند. فرآیند یکپارچه سازی روسازی ها و ورودی ها در شکل 9 نشان داده شده است. ابتدا، یک بافر B در اطراف عناصر پیاده رو نقشه LiDAR ایجاد می شود تا لبه های نقشه OSM را که باید جایگزین شوند، جستجو کند. لبه ها یا گره های ورودی ساختمان برای تولید بافر استفاده نمی شود. خطوط نقشه OSM که باید جایگزین شوند خطوطی هستند که با بافر B قطع می شوند. گره های اتصال Cn نقشه OSM با نقشه LiDAR به عنوان نقطه پایانی خط OSM شناسایی می شوند که از مرز B عبور می کند و خارج از خط است. بافر B. از نقاط Cn، نزدیکترین گره های Ln در نقشه LiDAR جستجو می شوند. سپس خطوط جدیدی تولید می‌شوند که نقاط ابتدایی و انتهایی آن‌ها با Cn و Ln تعریف می‌شوند و جایگزین خطوط عبوری از مرز B می‌شوند. در صورت عدم شناسایی پیاده‌رو در ابر نقطه، خطوط مربوطه از نقشه OSM حذف می‌شوند.
این روش برای ادغام گذرگاه عابر پیاده مشابه است. با توجه به داده‌های ورودی، ابر نقطه‌ای از یک خط نما، در مدل LiDAR، تنها نیمی از گذرگاه‌ها نشان داده می‌شوند که توسط نقطه مرکزی و ارتباط با نزدیک‌ترین پیاده‌روها از طریق یک حاشیه یا گره‌های سطح شیبدار تعریف می‌شوند. یک بافر در اطراف عناصر عابر پیاده که از داده‌های LiDAR مدل‌سازی شده‌اند، تولید می‌شود تا چند خطوط متقاطع OSM را شناسایی کند. پلی لاین OSM با خطی جایگزین می‌شود که با این موارد تعریف می‌شود: (1) گره عابر پیاده (یا سطح شیبدار) اتصال خط عابر پیاده با مدل پیاده‌رو LiDAR و (2) گره اتصال گذرگاه OSM به پیاده‌رو OSM جلو. این نقطه با جستجوی دورترین نقطه از خط عابر پیاده OSM به اتصال پیاده رو LiDAR شناسایی می شود.

4.3. تشخیص موانع تحرک با استفاده از حسگرهای سخت افزاری در دستگاه های تلفن همراه

4.3.1. برنامه موبایل برای ضبط داده ها

به منظور دسترسی به داده های سخت افزاری شهروندان سیار در یک شهر هوشمند و تبدیل داده های حس شده به دانش در مورد موانع فیزیکی پرداخت و تأثیر بر تحرک انسان، یک برنامه اندرویدی که امکان ضبط و پردازش داده های حسگر را فراهم می کند، به طور کامل توسعه داده شده است. آموزش دیده. این نرم افزار از یک مدل یادگیری عمیق شبکه عصبی کانولوشن (CNN) استفاده می کند که از نمونه داده های حسگرهای سخت افزاری آموزش دیده و نمونه های جدید را به منظور استخراج اطلاعات مفید در مورد وجود موانع فیزیکی طبقه بندی می کند.
حسگرهای سخت افزاری مورد استفاده برای گرفتن داده ها برای تغذیه CNN عبارتند از:
  • ژیروسکوپ.
  • مغناطیس سنج.
  • شتاب سنج.
  • سنسور جاذبه
حسگرهای سخت افزاری جریان های پیوسته ای از داده ها را تولید می کنند. به منظور تغذیه CNN، از یک طرح پنجره متحرک استفاده شده است. همپوشانی 50% برای تشخیص بهتر اشیایی که ممکن است با پنجره‌های زمانی هماهنگ نباشند استفاده شده است.
داده های حسگر به منظور کاهش نویز با استفاده از فیلتر پایین گذر Butterworth مرتبه چهارم پیش پردازش شده است. سپس یک فرآیند عادی سازی برای دستیابی به همگرایی سریعتر در آموزش CNN با کم کردن مقدار میانگین داده های حسگر در پنجره زمانی و تقسیم هر نمونه بر انحراف استاندارد اعمال می شود.
4.3.2. حالت های عملکرد اپلیکیشن موبایل
برنامه تلفن همراه به 2 حالت اصلی عملکرد تقسیم می شود: حالت ضبط و حالت تشخیص. حالت ضبط امکان ضبط داده‌های حسگر را در یک فایل csv. محلی و انتقال داده‌ها به یک سرور مرکزی که مسئول آموزش یک مدل یادگیری ماشینی مبتنی بر یادگیری عمیق است، می‌دهد. حالت ضبط، هر کاربر شرکت کننده در داده های آموزشی را راهنمایی می کند تا از یک سری از پیش تعریف شده از مناطق حاوی موانع فیزیکی عبور کند و بخش های داده را ثبت و برچسب گذاری کند. هنگامی که یک مدل معتبر با ترکیب داده های چندین کاربر به منظور ایجاد مدلی که می تواند با کاربران جدید سازگار شود، آموزش داده شد، مدل برای حالت تشخیص به برنامه تلفن همراه منتقل می شود. در این حالت،
4.3.3. مدل شبکه عصبی کانولوشنال
شبکه عصبی کانولوشن از لایه های زیر تشکیل شده است:
  • لایه کانولوشن یک بعدی با 64 فیلتر، اندازه فیلتر = 8 و عملکرد فعال سازی relu.
  • MaxPooling سایز 4.
  • لایه کانولوشن یک بعدی با 128 فیلتر، اندازه فیلتر = 32 و عملکرد فعال سازی relu.
  • MaxPooling سایز 2.
  • لایه متراکم از 64 نورون، عملکرد فعال سازی relu.
  • لایه متراکم از 64 نورون، عملکرد فعال سازی relu.
  • 0.25 ترک تحصیل
  • لایه متراکم از n نورون و عملکرد فعال سازی softmax (تعداد موانع برای آموزش و شناسایی توسط مدل).
ورودی هر سنسور به پنجره های 5 ثانیه ای تقسیم می شود و 50 درصد همپوشانی بین پنجره های متوالی استفاده می شود. جدول 1 جزئیات مدل Keras ( https://keras.io/ ) ایجاد شده برای پیاده سازی معماری CNN را نشان می دهد.
مدل با استفاده از پارامترهای زیر آموزش داده شده است:
  • اندازه دسته = 32
  • تعداد دوره ها = 100
  • بهینه ساز = آدم
این مدل توانست موانعی را با دقت 0.93 بر روی داده های اعتبار سنجی پیدا کند.
4.3.4. آموزش مدل و انتقال
داده های آموزشی از کاربران شرکت کننده برای آموزش یک مدل مبتنی بر CNN به یک سرور مرکزی ارسال می شود. هر کلاس شامل چندین نمونه از داده های حسگر سخت افزاری از کاربران مختلف است که از یک نوع مانع خاص عبور می کنند. هنگامی که یک مجموعه آموزشی بزرگ با چندین کلاس جمع آوری شد، یک نوت بوک در پایتون برای تولید مدل های یادگیری ماشینی مبتنی بر CNN ایجاد شده است که امکان طبقه بندی اطلاعات از حسگرهای سخت افزاری را به موانع فیزیکی مانند پله ها و شیب ها فراهم می کند. کتابخانه Tensorflow برای پیاده سازی مدل یادگیری ماشینی مبتنی بر CNN استفاده شده است زیرا می تواند به یک مدل Tensorflow Lite تبدیل شود که می تواند توسط برنامه تلفن همراه استفاده شود. هنگامی که مدل تولید شد، فقط باید آن را به برنامه تلفن همراه ارسال کرد تا از آن در حالت تشخیص استفاده شود.
شکل 10 برنامه موبایل را در حالت تشخیص نشان می دهد که موانع شناسایی شده را بر روی نقشه نشان می دهد.
4.3.5. ادغام با سیستم FLATCity
موانع فیزیکی شناسایی شده هنگام استفاده از برنامه تلفن همراه در حالت تشخیص به سیستم مرکزی FLATCity ارسال می شود که از آنها برای محاسبات مسیر قابل دسترسی استفاده می کند. شبکه CNN احتمالی را به هر قطعه داده اختصاص می دهد که احتمال مطابقت قطعه داده با هر یک از موانع هدف را تخمین می زند. اگر یکی از احتمالات تخمین زده شده بالاتر از آستانه منطبق باشد، یک شی JSON ایجاد می شود تا حاوی اطلاعات شناسایی شده باشد و با استفاده از یک REST API ( https://flatcity.lbd.org.es/backend/api ) به سرورهای مرکزی FLATCity ارسال شود. /entities/ Elements). اطلاعات ارسال شده، نوع عنصر شناسایی شده، تاریخ و زمان، مختصات GPS عنصر شناسایی شده و احتمال اختصاص داده شده توسط لایه خروجی در شبکه CNN (عملکرد softmax) را نشان می دهد. نمونه ای از یک پلکان خاص که در ویگو (اسپانیا) شناسایی شده است:
  • {“فعالیت”: “Escaleras”,
  • “تاریخ”: “2020-10-22T09:39:27.153687”,
  • “مکان”: {“نوع”: “نقطه”، “مختصات”: [42.232464, -8.729529]}،
  • “احتمال”: 0.95}

4.4. تشخیص موانع تحرک با استفاده از داده های توییتر

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

4.4.1. ضبط داده ها

این مرحله اولیه زیرسیستم توییتر است. این مسئول تشخیص توییت های مربوط به موانع یا مشکلات حرکتی است. این کار با کمک ابزار T-Hoarder توسعه یافته توسط Congosto و همکاران انجام می شود. [ 33 ]. جمع‌آوری داده‌ها با استفاده از پرسش‌هایی انجام می‌شود که دو نوع اصطلاح را ترکیب می‌کنند: اصطلاحاتی که عناصر شهری را نشان می‌دهند (مثلاً: “acera” (روسازی)، “paso de cebra” (گذرگاه عابر پیاده)، و غیره) عباراتی که وضعیت یک عنصر شهری را توصیف می‌کنند. (مثلاً: “مال استادو” (وضعیت بد)، “استروچو” (باریک) و غیره). هر توییت ضبط شده باید حداقل یک عبارت از هر یک از این دو نوع داشته باشد. رویکرد مشابهی در کار Wanichayapong و همکاران استفاده شده است. [ 30 ].
4.4.2. پیش پردازش توییت
این مرحله وظیفه حذف توییت هایی را بر عهده دارد که به زبان اسپانیایی نوشته نشده اند یا ریتوییت یا نقل قول هستند. همچنین، نمادهایی مانند هشتگ ها، شکلک ها و URL ها را از توییت حذف می کند.
4.4.3. آشکارساز مکان
دو مکانیسم در برنامه توییتر برای مرتبط کردن یک موقعیت به یک توییت وجود دارد: ارجاع جغرافیایی و موقعیت جغرافیایی. ارجاع جغرافیایی یک مکان منحصر به فرد است که به صورت دستی توسط کاربر از مجموعه ای از مکان های از پیش تعریف شده معروف به مکان های توییتر انتخاب می شود (به https://blog.twitter.com/official/en_us/a/2010/twitter-places-more-context- مراجعه کنید. for-your-tweets.html (بازدید شده در 2020/08/24).). موقعیت جغرافیایی از مختصات GPS مکانی که توییت نوشته شده است تشکیل شده است.
متأسفانه، به خوبی شناخته شده است که اکثر توییت‌ها بدون اطلاعات مکان هستند (به ویژه، بیش از 98٪ توییت‌هایی که در آزمایش‌های انجام‌شده برای آزمایش این ابزار ثبت کردیم، بدون اطلاعات مکان هستند). از آنجایی که محل مشکل تحرک بخش مهمی از سیستم است، ما دو مکانیسمی که قبلا ذکر شد (در صورت وجود) با الگوریتمی ترکیب کردیم که اطلاعات مکان را از متن توییت استخراج می‌کند. الگوریتم ما بر اساس استخراج موجودات نام‌گذاری‌شده از متن توییت و سپس انجام جستجوی مکان‌یابی خیابان و شهر ذکر شده در توییت با استفاده از پایگاه‌داده‌ای با اطلاعات جغرافیایی اسپانیا به‌دست‌آمده از موسسه ملی آمار اسپانیا (INE) است.
4.4.4. آشکارساز اعتبار
برخی از توییت‌های ثبت شده توسط ابزار T-Hoarder مشکلات تحرک را گزارش نمی‌کنند، حتی اگر حاوی هر دو عبارتی باشند که نشان‌دهنده عناصر شهری و اصطلاحاتی باشند که وضعیت یک عنصر شهری را نشان می‌دهند. در مرحله آخر، یک طبقه‌بندی کننده اجرا می‌شود تا توییت‌هایی را که مشکلات تحرک را گزارش نمی‌کنند کنار بگذارد. طبقه‌بندی‌کننده باید با مجموعه‌ای از توییت‌های حاشیه‌نویسی دستی آموزش داده شود (در آزمایش‌های خود ما از مجموعه‌ای از ۵۶۰ توییت استفاده کرده‌ایم که ۲۳۴ توییت به‌صورت دستی به‌عنوان مرتبط و بقیه به‌عنوان غیرمرتبط حاشیه‌نویسی شدند). برای کار طبقه بندی، هر توییت با بردار ویژگی ها نشان داده می شود. برخی از این ویژگی ها به صورت دستی انتخاب شده اند (تعداد کلمات، فاصله بین اصطلاح عنصر شهری و شرط شرط، تعداد افعال بین اصطلاح عنصر شهری و اصطلاح شرط و غیره)34 ].
4.4.5. ادغام آشکارساز توییتر در سیستم FLATCity
برای برنامه ریزی مسیر، دانستن محل دقیق مانع تحرک بسیار مهم است. بنابراین، تنها اطلاعات استخراج شده از توییت ها با اطلاعات موقعیت جغرافیایی ضمیمه شده برای افزودن اطلاعات به یک نقطه خاص در شبکه استفاده می شود. توییت‌های باقی‌مانده به‌عنوان هشدارهایی استفاده می‌شوند که می‌توانند برای کاوش بیشتر مناطق خاص با هر یک از تکنیک‌های دیگر موجود در سیستم FLATCity (LiDAR و حسگرهای موبایل) استفاده شوند.

5. مطالعه موردی

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

برای اثبات دوام FlatCity، ما یک مطالعه موردی را طراحی کردیم که شامل مجموعه داده‌های واقعی و محاسبه مسیرهای قابل دسترس در یک شهر است. برای مطالعه موردی، شهر ویگو (اسپانیا) را انتخاب کردیم زیرا شهری بزرگ است (295364 نفر در شهرداری و 480525 نفر در منطقه شهری در سال 2019). علاوه بر این، شهر بدوی در تراس های مونت دو کاسترو واقع شده است، که باعث می شود شهر در رمپ ها و پله ها فراوان باشد تا از ناهمواری ها جلوگیری کند.
مطالعه موردی خاص بر فردی متمرکز است که در Av. das Camelias 2 ( https://www.openstreetmap.org/#map=19/42.23392/-8.72876 ) و چه کسی باید به یک دفتر بانک واقع در Av. da Florida 35 ( https://www.openstreetmap.org/#map=19/42.21870/-8.73563 ). از این رو، بلوک های شهری Av. das Camelias 50 and Av. da Florida 35 بلوک‌های هدفی در نظر گرفته می‌شوند که با استفاده از LiDAR و برنامه تلفن همراه برای شناسایی موانع دسترسی تجزیه و تحلیل می‌شوند.

5.2. جمع آوری داده ها

ما داده‌ها را از OpenStreetmap در 19 اکتبر 2020 جمع‌آوری کردیم. شکل 11 محدوده مطالعه تعریف شده توسط کادر محدود را نشان می‌دهد. ((-8.76857،42.20148)،(-8.62275،42.26849)). جدول 2 تعداد عناصر هر نوع وارد شده از OpenStreetMap را نشان می دهد. ما تصمیم گرفتیم سه نوع مقصد را وارد کنیم: بانک، داروخانه و سوپرمارکت. مکان‌های پارکینگ کاهش‌یافته در OpenStreetMap در دسترس نبودند، از این رو تصمیم گرفتیم قبل از دانلود با مؤلفه OSM Harvester ، آنها را با استفاده از اطلاعات پورتال داده باز شورای شهر ویگو وارد کنیم.
داده های LiDAR با یک Lynx Mobile Mapper [ 35 ] به دست آمد. ابرهای نقطه ای Av. دا فلوریدا حاوی 7.6 و 18 میلیون نقطه و ابرهای نقطه ای از Av. das Camelias شامل 5 و 9.5 میلیون امتیاز بود. میانگین تراکم نقطه ای پیاده روها 2000 نقطه در هر متر مربع با تغییرات دقیق به دلیل فاصله تا MLS و انسداد است. روش استخراج اطلاعات از داده های LiDAR فوق به دو پارامتر اصلی بستگی دارد. حداکثر ارتفاع پله ها و حاشیه های h بر اساس محیط ساخته شده با در نظر گرفتن ارتفاع قابل قبولی برای صعود یک نفر به 25 سانتی متر محدود شد. جدایی بین گره های پیاده رو در d = 5 متر ایجاد شد، که یک راه حل مصالحه بین دقت به دست آمده از OSM و کار مرجع [ 31 ] ارائه می کند.].
جدول 3 لبه هایی را نشان می دهد که نمودار را در شبکه راهپیمایی تشکیل می دهند. ستون دوم عناصر موجود در شبکه (یعنی لبه های قابل پیاده روی و گذرگاه های عابر پیاده) را پس از اجرای فرآیند توضیح داده شده در بخش 4.1 توصیف می کند. ستون سوم و چهارم عناصری را که پس از پردازش داده‌های LiDAR پیدا شده‌اند و عناصر جمع‌آوری‌شده از OpenStreetMap را توصیف می‌کنند که به ترتیب باید حذف شوند. در نهایت، ستون پنجم مقدار نهایی عناصر هر نوع در شبکه را شرح می دهد.
برنامه تلفن همراه برای شناسایی موانع تحرک در بلوک های شهری که قبلاً به عنوان منطقه دقیق مورد علاقه در نظر گرفته می شد، استفاده شد. چهار بخش مختلف پیاده روی، به طول حدود 100 متر، ثبت شد. هشت عنصر اضافی از نوع پله شناسایی و در مدل داده های دسترسی به عنوان موانع تحرک احتمالی گنجانده شد.
در نهایت، مؤلفه T-Hoarder از 24 جولای 2020 تا 4 نوامبر 2020 فعال باقی ماند. در این مدت، 622 توییت مرتبط (یعنی توییت هایی که موانع تحرک در اسپانیا را توصیف می کنند) ثبت کرد. جدول 4 انواع مختلف توییت هایی را که ثبت شده اند را توضیح می دهد. متأسفانه، تنها هفت توئیت ثبت شده در شهر ویگو قرار داشت و هیچ یک از آنها در منطقه دقیق مطالعه قرار نداشتند. این مورد انتظار بود زیرا این یک تصادف بزرگ بود که یک مشکل حرکتی در طول دوره مطالعه اتفاق افتاد و کسی در مورد آن توییت کرد. از این رو، ما تصمیم گرفتیم که یازده توییت را در منطقه مطالعه دقیق بفرستیم تا تأیید کنیم که آنها ضبط و نمایش داده شده اند.

5.3. محاسبه مسیر

برای شروع آزمایش، کاربران با استفاده از یک ابزار خاص مبتنی بر نقشه، مکان خانه های خود را در نمایه خود و مکانی که خودروهای خود را در آن پارک کرده اند ذخیره می کنند. سپس از پنل نشان داده شده در شکل 12 استفاده می کنند. در پنل، کاربر با کلیک بر روی نقشه یا انتخاب از لیست پیشنهاد، مبدا و مقصد را مشخص می کند. از دکمه هوم می توان برای نشان دادن اینکه مسیر باید در محل خانه شروع یا متوقف شود استفاده شود . اولین چک باکس بین مبدا و مقصد می تواند برای نشان دادن اینکه آیا مسیر از خودروی کاربر شروع می شود یا نه (یعنی چک باکس Walk to my car ) استفاده شود.بدون علامت رها می شود) یا کاربر باید ابتدا به محلی که ماشین پارک شده است برود. چک باکس دوم را می توان برای تعیین مکان پارکینگ کم تحرک نزدیک به مقصد و اضافه کردن یک بخش پیاده روی اضافی از پارکینگ تا مقصد استفاده کرد، یا اینکه آیا کاربر سعی می کند پس از رسیدن به مقصد، یک مکان پارک پیدا کند. علاوه بر این، کاربر می تواند با انتخاب نماد پیاده روی در بالای پانل نشان دهد که تمام مسیر پیاده روی انجام می شود . هنگامی که مسیر محاسبه می شود، همانطور که در شکل 13 نشان داده شده است، در نقشه نمایش داده می شود . بخش های پیاده روی با رنگ آبی و بخش های رانندگی با رنگ سبز نشان داده شده اند.
شکل 14 جزئیات بیشتر مسیر نشان داده شده در شکل 13 را نشان می دهد . شکل 14 الف شروع مسیر را نشان می دهد که کاربر از خانه تا محلی که ماشین در آن پارک شده بود (به رنگ آبی) با استفاده از گذرگاه های عابر پیاده برای تغییر سمت جاده استفاده می کند. شکل 14 ب انتهای مسیر را نشان می دهد. بخش پیاده‌روی مسیر بسیار طولانی است زیرا گذرگاه عابر پیاده نزدیک به پارکینگ کم‌تحرکی که ماشین باید در آن پارک شود در داده‌های OpenStreetMap وجود ندارد (مانند بسیاری دیگر).
شکل 15 موانعی را نشان می دهد که در قسمت اول مسیر به Av. دا فلوریدا 35 . لیست موانعی که می توانند بر مسیر تاثیر بگذارند در سمت چپ نقشه با استفاده از کد رنگی برای نشان دادن قابلیت اطمینان مانع نشان داده شده است. این سه توییت ایجاد شده توسط اپلیکیشن موبایل و دو مانع شناسایی شده را نشان می دهد. جزئیات بیشتر مانع را می توان نشان داد (به عنوان مثال، توییت اصلی).

5.4. بحث

مطالعه موردی که ما طراحی و اجرا کرده‌ایم به ما این امکان را می‌دهد که دوام FlatCity را آزمایش کنیم. ما تأیید کرده‌ایم که OpenStreetMap برای انجام محاسبات مسیر برای افرادی که در حال پیاده‌روی هستند طراحی نشده است زیرا هیچ داده‌ای مربوط به شبکه پیاده‌رو وجود ندارد. علاوه بر این، OpenStreetMap توصیه می‌کند که گذرگاه‌های عابر پیاده را به‌عنوان نقاطی در شبکه جاده‌ها بدون اتصال بخش‌های پیاده‌رو معرفی کنید، بنابراین گذرگاه‌های عابر پیاده در OpenStreetMap نمی‌توانند برای مسیریابی استفاده شوند. در نهایت، اگر چه مقدار اطلاعات موجود قابل توجه است، اما هنوز کامل نیست. در مورد ما، ما مجبور شدیم فضاهای پارک غیرفعال ارائه شده توسط شورای شهر ویگو در پورتال داده باز آن را به OpenStreetMap اضافه کنیم ( https://datos-ckan.vigo.org/dataset/parking-discapacitados). به عنوان یک جنبه مثبت OpenStreetMap، باید تاکید کنیم که ماهیت باز آن اجازه می دهد تا ویژگی های جدید را پیشنهاد داده و کیفیت داده ها را به راحتی بهبود بخشد.
اسکن بخش های شهر با یک اسکنر موبایل LiDAR بسیار ارزشمند است. روشی موثر برای بهبود شبکه پیاده روها و همچنین تشخیص گذرگاه های عابر پیاده و موانع موجود در پیاده رو می باشد. علاوه بر این، ابرهای نقطه ای امکان تشخیص سایر عناصر شبکه راه را فراهم می کنند [ 36 ، 37 ]. با این حال، هزینه تجهیزات و تلاش برای اعمال آن در کل شهر هنوز بالا است و از این رو می توان در ابتدا در مناطق انتخاب شده با علاقه بیشتر (مثلاً به دلیل تردد بیشتر مردم) از آن استفاده کرد.
بازیابی موانع با استفاده از اطلاعات داوطلبانه کاربر و یک برنامه تلفن همراه برای شناسایی موانع فیزیکی بسیار ارزشمند است. به طور مشابه، شناسایی موانع تحرک با استفاده از داده‌های توییتر نیز ارزشمند بوده است، حتی اگر تعداد توییت‌های جغرافیایی و جغرافیایی در مقایسه با تعداد توییت‌های ثبت‌شده (کمتر از 10٪) بسیار کم باشد. دلیل آن این است که توییتر تصمیم گرفته است که هیچ علاقه‌ای به توییت‌های دقیقی ندارد و دیگر امکان ایجاد چنین توییت‌هایی وجود ندارد و باید از یک برنامه مشتری متفاوت استفاده شود. با این حال، می توان پیش بینی کرد که ادغام یک کلاینت توییتر که توییت های جغرافیایی را در برنامه تلفن همراه یک شهر هوشمند تولید می کند، می تواند دو هدف را دنبال کند: از یک سو، کاربران موانع را بیشتر گزارش می دهند.
ما سعی کرده ایم نتایج سیستم خود را با برنامه های موجود مقایسه کنیم. ما هیچ برنامه‌ای پیدا نکردیم که بتواند مسیرهای قابل دسترس را در یک شهر محاسبه کند. Wheelmap.org ( https://wheelmap.org/ ) نقشه‌ای است برای یافتن مکان‌های قابل دسترسی برای صندلی چرخدار با علامت‌گذاری مکان‌های عمومی با سطح دسترسی (یعنی به طور کامل، جزئی و غیرقابل دسترس). همچنین دارای یک اپلیکیشن موبایل برای مرور و استفاده از اطلاعات است. با این حال، اطلاعات مربوط به پیاده روها را ثبت نمی کند و عملکرد مسیریابی و یا اطلاعاتی در مورد موانع در خیابان ارائه نمی دهد. نقشه های گوگل ( https://maps.google.com/) اطلاعات مربوط به دسترسی به ایستگاه ها و مسیرهای حمل و نقل عمومی و همچنین مکان های عمومی را ثبت می کند. اما محاسبات مسیر عابر پیاده از شبکه جاده استفاده می کند و اطلاعاتی در مورد پیاده روها ندارد.

6. نتیجه گیری

عناصر زیرساختی و موانع مختلف در خیابان ها به روش های خاصی بر تحرک مردم در شهرهای هوشمند تأثیر می گذارد. این مقاله یک معماری جدید برای ایجاد یک سیستم اطلاعاتی ارائه می‌کند که اطلاعات را از بسیاری از منابع داده ناهمگن جمع‌آوری می‌کند، اطلاعات را در مدلی از زیرساخت شهر ادغام می‌کند و مسیرهای محاسبه‌شده برای هر فردی که می‌خواهد در داخل یک شهر هوشمند حرکت کند، پیاده‌روی یا پیاده‌روی یا پیاده‌روی، محاسبه می‌کند. با ماشین. این معماری مبتنی بر رویکرد چند سنسوری برای جمع‌آوری داده‌های جامع، رابط‌های کاربری آسان و ذخیره‌سازی و پردازش داده‌ها است. معماری پیشنهادی از داده‌های باز موجود (از منابعی مانند OpenStreetMap) با اطلاعات جمع‌آوری‌شده (از برنامه‌های تلفن همراه و توییتر) استفاده می‌کند و از منابع داده موقت اضافی (بر اساس LiDAR) برای ایجاد نقشه‌های تحرک شهری استفاده می‌کند که کاربر مسیرها را از آن‌ها تطبیق داده است. را می توان محاسبه کرد. این نقشه‌های تحرک نه تنها شامل اطلاعاتی درباره موانع مختلف شناسایی‌شده است، بلکه تخمینی درباره شدت تأثیر آنها بر تحرک افراد مختلف تحت تأثیر محدودیت‌های حرکتی را نیز ارائه می‌کند. برخی از منابع داده ماهیت ناهمزمان دارند (یعنی OpenStreetMap و LiDAR) در حالی که برخی دیگر همزمان هستند (یعنی داده های حسگر داوطلبانه کاربر و مشکلات گزارش شده با برنامه تلفن همراه، و توییت های استخراج شده از API استریم توییتر). بنابراین یک مدل داده دسترسی ساخته می شود که هر دو جنبه ایستا و پویا تحرک شهری را به تصویر می کشد. این مقاله همچنین یک مطالعه موردی ارائه کرده است که در آن معماری پیشنهادی تایید شده است و نتایج امیدوارکننده‌ای را برای مفهوم آینده توصیه‌های مسیر شخصی نشان می‌دهد.
معماری و فرآیندهای سیستم اطلاعاتی، که در مقاله توضیح داده شد، به زمینه‌های داده‌کاوی مکانی (به عنوان مثال، ساختن شبکه‌ای از زیرساخت‌های عابر پیاده از اطلاعات OpenStreetMap)، پردازش مکانی در مقیاس بزرگ (به عنوان مثال، استخراج رمپ، مراحل، و گذرگاه‌های عابر پیاده از داده‌های LiDAR حساس به موبایل)، تلفیق داده‌های جغرافیایی (به عنوان مثال، ادغام اطلاعات جمع‌آوری‌شده از OpenStreetMap با اطلاعات به‌دست‌آمده از داده‌های LiDAR)، و NLP جغرافیایی (به عنوان مثال، تشخیص مشکلات دسترسی با حسگرهای نرم‌افزاری در شبکه‌های اجتماعی مانند توییتر).
این کار خطوط جدید و جالبی از کارهای آینده را باز می کند. از یک طرف، منابع داده باز اضافی فراتر از OpenStreetMap باید در فرآیند تلفیق در نظر گرفته شوند (به عنوان مثال، اطلاعاتی که wheelmap.org ( https://wheelmap.org/) در OpenStreetMap جزئیات مربوط به دسترسی داخلی مقصدها یا اطلاعات داده باز ارائه شده توسط شهرها را ذخیره می کند. از سوی دیگر، اطلاعات اضافی را می توان از ابرهای نقطه LiDAR یا اطلاعات حساس به جمعیت (به عنوان مثال، شیب رمپ ها، مواد روسازی) به دست آورد. به طور مشابه، شبکه‌های اجتماعی اضافی را می‌توان برای به دست آوردن اطلاعات بیشتر حس کرد، حتی اگر روند فعلی صاحبان آنها محدود کردن دسترسی آزاد به اطلاعات است. علاوه بر این، منابع داده همزمان اضافی باید در نظر گرفته شود تا جنبه‌های زمان واقعی یا تقریباً بی‌درنگ تحرک را با دقت بیشتری به تصویر بکشد (به عنوان مثال، یک پیاده‌رو که در حال تعمیر است). به عنوان مثال، خدمه تعمیرات شهر می توانند از برنامه تلفن همراه شرح داده شده در بخش 4.3 استفاده کنندبرای ارائه اطلاعات اضافی در مورد موانع و مسائل دسترسی. در نهایت، امکان استفاده از اطلاعات یک منبع (به عنوان مثال، توییتر) برای تنظیم حساسیت از منبع دیگر (به عنوان مثال، OpenStreetMap) نیز باید بررسی شود.

منابع

  1. Panta، YR; اعظم، س. شانموگام، بی. بله، KC; جونکمن، ام. دی بوئر، اف. Alazab, M. بهبود دسترسی برای افراد دارای نقص حرکت در شهر هوشمند با استفاده از Crowdsourcing. در مجموعه مقالات کنفرانس امنیت سایبری و قانون سایبری 2019 (CCC)، ملبورن، استرالیا، 8 تا 9 مه 2019؛ ص 47-55. [ Google Scholar ]
  2. سها، م. ساگستاد، م. مدالی، HT; زنگ، ا. هلند، آر. بوئر، اس. داش، ا. چن، اس. لی، ا. هارا، ک. و همکاران پیاده‌روی پروژه: یک ابزار جمع‌سپاری مبتنی بر وب برای جمع‌آوری داده‌های دسترسی پیاده‌رو در مقیاس. در مجموعه مقالات کنفرانس CHI 2019 در مورد عوامل انسانی در سیستم‌های محاسباتی، گلاسکو، بریتانیا، 4 تا 9 مه 2019؛ صص 1-14. [ Google Scholar ]
  3. دینگ، سی. والد، ام. ویلز، جی. بررسی داده های دسترسی باز. در مجموعه مقالات یازدهمین کنفرانس وب برای همه، سئول، کره، 7 تا 11 آوریل 2014. صص 1-4. [ Google Scholar ]
  4. سلیمانوف، تی. کونزه، ال. نیومن، پی. استنتاج آنلاین و تشخیص محدودیت ها در صحنه های نیمه بسته با LIDAR پراکنده. در مجموعه مقالات کنفرانس سیستم های حمل و نقل هوشمند IEEE 2019 (ITSC)، اوکلند، نیوزیلند، 27 تا 30 اکتبر 2019؛ صص 2693–2700. [ Google Scholar ]
  5. سرنا، ا. مارکوتگی، ب. تشخیص دسترسی شهری از داده‌های اسکن لیزری سیار. ISPRS J. Photogramm. از راه دور. Sens. 2013 , 84 , 23-32. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  6. بالادو، ج. دیاز-ویلارینو، ال. آریاس، پ. González-Jorge, H. طبقه بندی خودکار عناصر زمین شهری از داده های اسکن لیزری متحرک. خودکار ساخت و ساز 2018 ، 86 ، 226-239. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  7. یانگ، اف. لیانگ، ی. لی، دی. سو، اف. زو، اچ. زو، ایکس. Li, L. تشخیص اتصال فضایی از نقطه ابر برای بازسازی پله . گزارش فنی؛ EasyChair: منچستر، بریتانیا، 2019. [ Google Scholar ]
  8. بالادو، ج. ون اوستروم، پی. دیاز-ویلارینو، ال. Meijers، M. مورفولوژی ریاضی به طور مستقیم به داده های ابر نقطه اعمال می شود. ISPRS J. Photogramm. از راه دور. Sens. 2020 , 168 , 208–220. [ Google Scholar ] [ CrossRef ]
  9. هو، کیو. Ai, C. یک روش موجودی پیاده‌رو در سطح شبکه با استفاده از LiDAR موبایل و یادگیری عمیق. ترانسپ Res. قسمت C Emerg. تکنولوژی 2020 , 119 , 102772. [ Google Scholar ] [ CrossRef ]
  10. آی، سی. Tsai, Y. روش ارزیابی خودکار پیاده‌رو برای آمریکایی‌های دارای معلولیت مطابق با عمل با استفاده از لیدار متحرک سه‌بعدی. ترانسپ Res. ضبط 2016 ، 2542 ، 25-32. [ Google Scholar ] [ CrossRef ]
  11. بالادو، ج. دیاز-ویلارینو، ال. آریاس، پ. لورنزو، اچ. ابرهای نقطه ای برای مسیریابی مستقیم عابر پیاده در محیط های شهری. ISPRS J. Photogramm. از راه دور. Sens. 2019 , 148 , 184–196. [ Google Scholar ] [ CrossRef ]
  12. اشمیت ویلکن، جی. Plümer, L. بازسازی مبتنی بر مدل و طبقه بندی قطعات نما در ابرهای نقطه سه بعدی. بین المللی قوس. فتوگرام از راه دور. حس اسپات. Inf. علمی 2010 ، 38 ، 269-274. [ Google Scholar ]
  13. بالادو، ج. دیاز-ویلارینو، ال. آریاس، پ. Garrido، I. ابرها را به تشخیص دسترسی داخلی/خارجی اشاره کنید. ISPRS Ann. فتوگرام از راه دور. حس اسپات. Inf. علمی 2017 ، 4 ، 287-293. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  14. سویلان، ام. ریویرو، بی. سانچز-رودریگز، آ. آریاس، ص. ارزیابی ایمنی در محیط های عبور عابر پیاده با استفاده از داده های MLS. اسید. مقعدی قبلی 2018 ، 111 ، 328-337. [ Google Scholar ] [ CrossRef ]
  15. سویلان، ام. ریویرو، بی. مارتینز-سانچز، جی. آریاس، ص. تقسیم بندی و طبقه بندی خط کشی های جاده با استفاده از داده های MLS. ISPRS J. Photogramm. از راه دور. Sens. 2017 , 123 , 94-103. [ Google Scholar ] [ CrossRef ]
  16. دیاز ویلارینو، ال. بوگوسلاوسکی، پ. خوشلحم، ک. لورنزو، اچ. مهجوبی، ل. ناوبری داخلی از ابرهای نقطه: مدل سازی سه بعدی و تشخیص موانع. ISPRS Int. قوس. فتوگرام از راه دور. حس اسپات. Inf. علمی 2016 ، XLI-B4 ، 275–281. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  17. مارویاما، تی. کنایی، س. تادا، ام. ارزیابی سهولت راهیابی مبتنی بر شبیه سازی با استفاده از مدل های دیجیتال انسان و محیط آنچنان که هست. ISPRS Int. J. Geo-Inf. 2017 ، 6 ، 267. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  18. اسوالد، اس. گاتمن، جی اس. هورنونگ، آ. Bennewitz، M. از ابرهای نقطه سه بعدی تا بالا رفتن از پله ها: مقایسه رویکردهای تقسیم بندی هواپیما برای انسان نماها. در مجموعه مقالات یازدهمین کنفرانس بین المللی IEEE-RAS در سال 2011 در مورد ربات های انسان نما، بلد، اسلوونی، 26-28 اکتبر 2011. ص 93-98. [ Google Scholar ]
  19. لو، آرسی هسیائو، ام. Liu، CW Multisensor یکپارچه تشخیص پله و سیستم اندازه گیری پارامترها برای روبات های پله نوردی پویا. در مجموعه مقالات کنفرانس بین المللی IEEE 2013 در علوم و مهندسی اتوماسیون (CASE)، مدیسون، WI، ایالات متحده آمریکا، 17-20 اوت 2013. صص 318-323. [ Google Scholar ]
  20. کاپونی، ا. فیاندرینو، سی. کانتارچی، بی. فوشینی، ال. کلیازویچ، دی. Bouvry, P. نظرسنجی در مورد سیستم های crowdsensing موبایل: چالش ها، راه حل ها و فرصت ها. IEEE Commun. Surv. معلم خصوصی 2019 ، 21 ، 2419–2465. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  21. کاسیلاری، ای. آلوارز-مارکو، ام. گارسیا-لاگوس، F. مطالعه استفاده از اندازه‌گیری‌های ژیروسکوپ در سیستم‌های تشخیص سقوط پوشیدنی. Symmetry 2020 , 12 , 649. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  22. دب، اس. یانگ، یو. چوآ، MCH; شناسایی Tian، J. Gait با استفاده از یک معیار تشابه جدید با زمان تاب بر اساس سیگنال‌های اینرسی گوشی‌های هوشمند. J. محیط. هوشمند اومانیز. محاسبه کنید. 2020 ، 11 ، 4041-4053. [ Google Scholar ] [ CrossRef ]
  23. لارا، OD; لابرادور، MA نظرسنجی در مورد تشخیص فعالیت های انسانی با استفاده از حسگرهای پوشیدنی. IEEE Commun. Surv. معلم خصوصی 2012 ، 15 ، 1192-1209. [ Google Scholar ] [ CrossRef ]
  24. برودی، MA; Coppens، MJ; لرد، اس آر؛ لاول، NH; Gschwind، YJ; ردموند، اس جی; دل روزاریو، مگابایت؛ وانگ، ک. استورنیکس، دی.ال. پرشینی، م. و همکاران نظارت بر دستگاه آویز پوشیدنی با استفاده از روش‌های جدید مبتنی بر موجک نشان می‌دهد که زندگی روزمره و راه رفتن‌های آزمایشگاهی متفاوت است. Med Biol. مهندس محاسبه کنید. 2016 ، 54 ، 663-674. [ Google Scholar ] [ CrossRef ]
  25. هو، اس. سو، ال. لیو، اچ. وانگ، اچ. عبدالظاهر، TF Smartroad: سنجش جمعیت مبتنی بر گوشی های هوشمند برای تشخیص و شناسایی تنظیم کننده ترافیک. ACM Trans. Sens. Networks (TOSN) 2015 ، 11 ، 1-27. [ Google Scholar ] [ CrossRef ]
  26. ساکاکی، ت. اوکازاکی، م. Matsuo, Y. زلزله کاربران توییتر را می لرزاند: تشخیص رویداد در زمان واقعی توسط حسگرهای اجتماعی. در مجموعه مقالات نوزدهمین کنفرانس بین المللی وب جهانی، رالی نورث، کالیفرنیا، ایالات متحده آمریکا، 26 تا 30 آوریل 2010; صص 851-860. [ Google Scholar ]
  27. کنگوستو، ام. فوئنتس-لورنزو، دی. Sánchez-Fernández، L. میکروبلاگرها به عنوان حسگرهایی برای خرابی حمل و نقل عمومی. محاسبات اینترنتی IEEE. 2015 ، 19 ، 18-25. [ Google Scholar ] [ CrossRef ]
  28. آناستازی، جی. آنتونلی، م. بچینی، ع. برینزا، اس. D’Andrea، E. دی گوگلیلمو، دی. دوکانژ، پی. لازرینی، بی. مارسلونی، اف. Segatori، A. حس شهری و اجتماعی برای تحرک پایدار در شهرهای هوشمند. در مجموعه مقالات اینترنت پایدار و فناوری اطلاعات و ارتباطات در سال 2013 برای پایداری (SustainIT)، پالرمو، ایتالیا، 30 تا 31 اکتبر 2013. صص 1-4. [ Google Scholar ]
  29. کومار، ا. جیانگ، م. Fang, Y. کجا نروید؟ تشخیص خطرات جاده با استفاده از توییتر در مجموعه مقالات سی و هفتمین کنفرانس بین المللی ACM SIGIR در مورد تحقیق و توسعه در بازیابی اطلاعات، ساحل طلایی، استرالیا، 6 تا 11 ژوئیه 2014. ص 1223-1226. [ Google Scholar ]
  30. وانیچایاپونگ، ن. پروتیپونیاسکول، دبلیو. Pattara-Atikom، W. Chaovalit، P. استخراج و طبقه بندی اطلاعات ترافیک مبتنی بر اجتماعی. در مجموعه مقالات یازدهمین کنفرانس بین المللی 2011 در مورد ارتباطات راه دور ITS، سن پترزبورگ، روسیه، 23 تا 25 اوت 2011; صص 107-112. [ Google Scholar ]
  31. لوپز پازوس، جی. بالادو فریاس، جی. دیاز ویلارینو، ال. آریاس سانچز، پ. Scaioni، M. مسیریابی عابر پیاده در محیط های شهری: نتایج اولیه. In Proceedings of the Geospace 2017، کیف، اوکرانیا، 4 تا 6 دسامبر 2017. [ Google Scholar ]
  32. سانچز-آویلا، م. مورینو-گارسیا، MA; فیستئوس، ج.ا. سانچز-فرناندز، L. تشخیص موانع تحرک در شهر هوشمند با استفاده از توییتر. دسترسی IEEE 2020 ، 8 ، 168429–168438. [ Google Scholar ] [ CrossRef ]
  33. کنگوستو، ام. باسانتاوال، پی. Sanchez-Fernandez, L. T-Hoarder: چارچوبی برای پردازش جریان های داده توییتر. J. Netw. محاسبه کنید. Appl. 2017 ، 83 ، 28-39. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  34. میلن، دی. Witten, IH یک ابزار منبع باز برای استخراج ویکی پدیا. آرتیف. هوشمند 2013 ، 194 ، 222-239. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  35. پوئنته، آی. گونزالس-خورخه، اچ. مارتینز-سانچز، جی. آریاس، ص. بررسی فناوری های نقشه برداری و نقشه برداری موبایل. اندازه گیری 2013 ، 46 ، 2127-2145. [ Google Scholar ] [ CrossRef ]
  36. هولگادو بارکو، آ. ریویرو، بی. گونزالس-آگیلرا، دی. آریاس، ص. موجودی خودکار مقاطع راه از سیستم اسکن لیزری سیار. محاسبه کنید. کمک مدنی زیرساخت. مهندس 2017 ، 32 ، 3-17. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  37. بالادو، ج. گونزالس، ای. آریاس، پ. کاسترو، دی. رویکرد جدید به فهرست خودکار علائم ترافیکی بر اساس داده های سیستم نقشه برداری تلفن همراه و یادگیری عمیق. Remote Sens. 2020 , 12 , 442. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Ijgi 10 00007 g001 550
شکل 1. چارچوب کلی این مقاله.
Ijgi 10 00007 g002 550
شکل 2. معماری سیستم FlatCity.
Ijgi 10 00007 g003 550
شکل 3. معماری جذب.
Ijgi 10 00007 g004 550
شکل 4. مدل داده.
Ijgi 10 00007 g005 550
شکل 5. معماری برنامه.
Ijgi 10 00007 g006 550
شکل 6. مدل مفهومی یک کار OSM Harverster .
Ijgi 10 00007 g007 550
شکل 7. ساخت شبکه ای از پیاده روها از جاده های OpenStreetMap (OSM).
Ijgi 10 00007 g008 550
شکل 8. ساخت گذرگاه های عابر پیاده از گذرگاه های OSM.
Ijgi 10 00007 g009 550
شکل 9. ادغام داده های LiDAR در مدل: ( الف ) نقشه به دست آمده با استفاده از LiDAR (سبز) و از OSM (سیاه)، ( ب ) تولید بافر و تشخیص نقاط اتصال، ( ج ) تولید خطوط اتصال بین هر دو نقشه
Ijgi 10 00007 g010 550
شکل 10. موانع شناسایی شده.
Ijgi 10 00007 g011 550
شکل 11. منطقه مورد مطالعه.
Ijgi 10 00007 g012 550
شکل 12. پیکربندی مسیر از خانه کاربر به یک دفتر بانک در Av. دا فلوریدا 35 .
Ijgi 10 00007 g013 550
شکل 13. مسیر کامل از خانه کاربر تا دفتر بانک در Av. دا فلوریدا 35 .
Ijgi 10 00007 g014 550
شکل 14. جزئیات مسیر نشان داده شده در شکل 13 .
Ijgi 10 00007 g015 550
شکل 15. موانع در قسمت اول مسیر به Av. دا فلوریدا 35 .

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

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

بدون دیدگاه

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