मैप पर बिंदु A से बिंदु B तक की दिशा में कौन से एल्गोरिदम निर्देश की गणना करते हैं?


543

मानचित्र प्रदाता (जैसे Google या याहू-मैप्स) कैसे दिशा-निर्देश सुझाते हैं?

मेरा मतलब है कि उनके पास वास्तविक रूप से किसी न किसी रूप में वास्तविक डेटा है, जिसमें निश्चित रूप से दूरियां शामिल हैं, लेकिन शायद ड्राइविंग गति, फुटपाथ की उपस्थिति, ट्रेन शेड्यूल आदि जैसी चीजें भी हैं, लेकिन मान लीजिए कि डेटा एक सरल प्रारूप में थे, एक बहुत बड़ा निर्देशित ग्राफ कहते हैं बढ़त भार के साथ दूरी को दर्शाता है। मैं एक मनमाने बिंदु से दूसरे बिंदु पर दिशाओं की त्वरित गणना करने में सक्षम होना चाहता हूं। कभी-कभी ये बिंदु एक साथ (एक शहर के भीतर) करीब होंगे, जबकि कभी-कभी वे दूर (क्रॉस-कंट्री) होंगे।

Dijkstra के एल्गोरिथ्म जैसे ग्राफ़ एल्गोरिदम काम नहीं करेंगे क्योंकि ग्राफ़ बहुत बड़ा है। सौभाग्य से, ए * जैसे हेयोरिस्टिक एल्गोरिदम शायद काम करेंगे। हालाँकि, हमारा डेटा बहुत संरचित है, और शायद किसी प्रकार का टियर दृष्टिकोण काम कर सकता है? (उदाहरण के लिए, कुछ "कुंजी" बिंदुओं के बीच पूर्व-निर्देशित दिशाओं को दूर, साथ ही साथ कुछ स्थानीय दिशाओं को संग्रहीत करें। फिर दो दूर बिंदुओं के लिए दिशा निर्देशों में एक प्रमुख बिंदुओं के लिए स्थानीय दिशाएं, एक अन्य प्रमुख बिंदु पर वैश्विक दिशाएं, और फिर स्थानीय होंगी। फिर से निर्देश।)

वास्तव में क्या एल्गोरिदम व्यवहार में उपयोग किया जाता है?

पुनश्च। यह सवाल ऑनलाइन मैपिंग दिशाओं में quirks खोजने से प्रेरित था। त्रिकोण असमानता के विपरीत, कभी-कभी Google मैप्स को लगता है कि XZ को अधिक समय लगता है और XYZ में एक मध्यवर्ती बिंदु का उपयोग करने की तुलना में अधिक दूर है । लेकिन हो सकता है कि उनके चलने के निर्देश दूसरे पैरामीटर के लिए भी अनुकूलित हों?

पी पी एस। यहां त्रिभुज असमानता का एक और उल्लंघन है जो मुझे (मुझे) सुझाव देता है कि वे किसी प्रकार का थकाऊ दृष्टिकोण का उपयोग करते हैं: XZ बनाम XYZ । पूर्व प्रमुख बोलवर्ड ड सेबस्टोपोल का उपयोग करने के लिए लगता है, भले ही यह रास्ते से थोड़ा बाहर हो।

संपादित करें : इन उदाहरणों में से कोई भी अब काम नहीं करता है, लेकिन दोनों ने मूल पोस्ट के समय किया था।


3
BTW, ए * एल्गोरिथ्म दिक्क्स्ट्रा के एल्गोरिथ्म का एक सामान्यीकरण है जो सबग्राफ के आकार में कटौती करता है जिसे खोजा जाना चाहिए, यदि अतिरिक्त जानकारी उपलब्ध है जो लक्ष्य के लिए "दूरी" पर कम-सीमा प्रदान करती है
मिच गेहूं

पुनः ए *: हाँ, वास्तव में। सौभाग्य से, हमारे मामले में, यह "अतिरिक्त जानकारी" सीधी-रेखा दूरी का उपयोग करके उदाहरण के लिए उपलब्ध है। जब मैं ऊपर "दिक्जस्त्र" कहता हूं, तो मेरा मतलब है कि वेनिला दिक्जस्त्र।
ए रेक्स

चलने की दिशा? दुनो कहीं और के बारे में, लेकिन यहां (हैम्पशायर, यूके) के आसपास, बिग जी के पास कोई पैदल यात्री डेटा नहीं है - यह मुझे पैदल चलने वालों की प्रवृत्ति के आसपास की सड़कों आदि के साथ जोड़ता है। एकमात्र ऐसी चीज है जो मार्ग के लिए समय का अनुमान बदल रही है :)
jTresidder

यदि ड्राइविंग या चलने के लिए दिशा-निर्देश हैं तो मुझे विशेष रूप से परवाह नहीं है। मैं सिर्फ यह जानना चाहता हूं कि वे कैसे काम करते हैं! मेरे पास चलने के लिंक होने का कारण यह है क्योंकि मैं पेरिस के चारों ओर घूमने और सभी 66 वालेस फव्वारे को देखने का एक तरीका बता रहा था। (उन मानचित्रों के समापन बिंदु वालेस फव्वारे होने चाहिए।)
ए रेक्स

इस सवाल पर इनाम अधिक और बेहतर उत्तरों को प्रोत्साहित करना है, खासकर उन लोगों से जो प्रमुख प्रदाताओं में से एक पर काम करते हैं। डेटा स्ट्रक्चर्स, एल्गोरिदम, कितना प्री-कम्यूटेड है, आदि के बारे में टिप्पणियाँ, सभी की सराहना की जाती है।
ए। रेक्स

जवाबों:


526

किसी ऐसे व्यक्ति के रूप में बोलना, जिसने 18 महीने तक एक मैपिंग कंपनी में काम किया, जिसमें राउटिंग एल्गोरिदम पर काम करना शामिल था ... हाँ, दिज्क्स्ट्रा का काम कुछ संशोधनों के साथ है:

  • दीजकस्ट्रा के एक बार स्रोत से गंतव्य तक पहुंचने के बजाय , आप प्रत्येक छोर पर शुरू करते हैं, और दोनों पक्षों का विस्तार तब तक करते हैं जब तक कि वे बीच में नहीं मिलते। इससे लगभग आधा काम (2 * pi * (r / 2) ^ 2 बनाम pi * r ^ 2) समाप्त हो जाता है।
  • अपने स्रोत और गंतव्य के बीच हर शहर के बैक-गलियों की खोज से बचने के लिए, आपके पास मानचित्र डेटा की कई परतें हो सकती हैं: एक 'हाईवे' परत जिसमें केवल राजमार्ग होते हैं, एक 'माध्यमिक' परत जिसमें केवल माध्यमिक सड़कें होती हैं, और आगे। फिर, आप अधिक विस्तृत परतों के केवल छोटे वर्गों का पता लगाते हैं, जो आवश्यक रूप से विस्तारित होते हैं। जाहिर है यह विवरण बहुत विस्तार से निकलता है, लेकिन आपको यह विचार मिलता है।

उन लाइनों के साथ संशोधनों के साथ, आप बहुत ही उचित समय सीमा में क्रॉस-कंट्री रूटिंग भी कर सकते हैं।


29
कोई है जो वास्तविक दुनिया में इस पर काम किया, भयानक! क्या आपके पास कोई विचार है कि इसे पूर्व-निर्धारित करना कितना संभव है, जैसा कि Google के लेख में एक अन्य टिप्पणी में बताया गया है?
ए। रेक्स

10
हमने उस प्रकृति का कोई पूर्वप्रकरण नहीं किया, लेकिन यह निश्चित रूप से एक दिलचस्प अनुकूलन की तरह लगता है।
निक जॉनसन

29
"यह केवल एक समाधान का उत्पादन करने की गारंटी है, जरूरी नहीं कि सबसे कुशल एक" यह असत्य है; जब तक प्रयोग किया गया हेयूरिबल स्वीकार्य है, तब तक A * एल्गोरिथम कम से कम लागत वाला रास्ता तैयार करता है। प्रशंसनीय का मतलब है कि लागत कभी भी अधिक अनुमानित नहीं है, लेकिन इसे कम करके आंका जा सकता है (लेकिन खराब अनुमान एल्गोरिथ्म को धीमा कर देगा)। पूर्व-प्रसंस्करण से डेटा का उपयोग करने से बेहतर स्वीकार्य हेयुरिस्टिक बनाने में मदद मिलती है, और इसलिए ए * काम तेजी से होता है।
a1kmm

6
दरअसल, आगे के विचार पर, आप पूरी तरह से सही हैं। आप इसका उपयोग करने के लिए एक मौजूदा एल्गोरिथ्म को बढ़ा सकते हैं बस लक्ष्य नोड के बीच ग्रेट सर्कल दूरी को जोड़कर और किनारे की लागत का मूल्यांकन किया जा रहा है। मुझे यकीन नहीं है कि अगर हमारे एल्गोरिथ्म ने ऐसा किया है - लेकिन यह एक बहुत ही समझदार अनुकूलन है।
निक जॉनसन

11
ए *, सबसे खराब स्थिति में (एक ऐसा अनुमान जो कहता है कि सभी रास्ते बराबर हैं), बिल्कुल Djikstra के बराबर है।
२०:३२ पर टोरेक

111

यह प्रश्न पिछले वर्षों में अनुसंधान का एक सक्रिय क्षेत्र रहा है। मुख्य विचार एक बार ग्राफ पर प्रीप्रोसेसिंग करना है , ताकि सभी निम्नलिखित प्रश्नों को तेज किया जा सके । इस अतिरिक्त जानकारी के साथ यात्रा करने वालों की गणना बहुत तेजी से की जा सकती है। फिर भी, दिक्जस्ट्रा का एल्गोरिथम सभी ऑप्टिमाइज़ेशन का आधार है।

अर्चिनिड ने श्रेणीबद्ध जानकारी के आधार पर द्विदिश खोज और एज प्रूनिंग के उपयोग का वर्णन किया। ये स्पीडअप तकनीक काफी अच्छी तरह से काम करती है, लेकिन सबसे हालिया एल्गोरिदम इन तकनीकों को हर तरह से बेहतर बनाते हैं। वर्तमान एल्गोरिदम के साथ एक महाद्वीपीय सड़क नेटवर्क पर एक मिलीसेकंड की तुलना में काफी कम समय में सबसे छोटे रास्तों की गणना की जा सकती है । दिज्क्स्ट्रा के अनमॉडिफाइड एल्गोरिथ्म के तेजी से कार्यान्वयन के लिए लगभग 10 सेकंड की आवश्यकता होती है ।

लेख इंजीनियरिंग फास्ट रूट प्लानिंग एल्गोरिदम उस क्षेत्र में अनुसंधान की प्रगति का अवलोकन देता है। अधिक जानकारी के लिए उस कागज के संदर्भ देखें।

सबसे तेज़ ज्ञात एल्गोरिदम डेटा में सड़क की श्रेणीबद्ध स्थिति के बारे में जानकारी का उपयोग नहीं करते हैं, अर्थात यदि यह एक राजमार्ग या स्थानीय सड़क है। इसके बजाय, वे पूर्व नियोजन चरण में खुद की पदानुक्रम की गणना करते हैं जो रूट प्लानिंग को गति देने के लिए अनुकूलित होती है। फिर इस प्री-कॉम्पीपेशन का उपयोग खोज को prune करने के लिए किया जा सकता है: स्टार्ट और डेस्टिनेशन की धीमी सड़कों से दूर, दिक्जस्ट्रा के एल्गोरिथम के दौरान विचार करने की आवश्यकता नहीं है। लाभ बहुत अच्छा प्रदर्शन कर रहे हैं और परिणाम के लिए एक शुद्धता की गारंटी है।

पहले अनुकूलित मार्ग नियोजन एल्गोरिदम केवल स्थैतिक सड़क नेटवर्क से निपटते हैं, इसका मतलब है कि ग्राफ में एक बढ़त का एक निश्चित मूल्य है। व्यवहार में यह सच नहीं है, क्योंकि हम ट्रैफिक जाम या वाहन पर निर्भर प्रतिबंध जैसी गतिशील जानकारी को ध्यान में रखना चाहते हैं। नवीनतम एल्गोरिदम भी ऐसे मुद्दों से निपट सकते हैं, लेकिन अभी भी हल करने के लिए समस्याएं हैं और अनुसंधान चल रहा है।

यदि आपको टीएसपी के लिए एक समाधान की गणना करने के लिए सबसे छोटी पथ दूरी की आवश्यकता है , तो आप शायद उन मेट्रिसेस में रुचि रखते हैं जिनमें आपके स्रोतों और गंतव्यों के बीच सभी दूरी शामिल हैं। इसके लिए आप हाईवे पदानुक्रमों का उपयोग करते हुए कई-से-कई लघु पथों की गणना करने पर विचार कर सकते हैं । ध्यान दें, कि पिछले 2 वर्षों में नए तरीकों से इसमें सुधार हुआ है।


1
ज्ञानवर्धक, वास्तव में। आपके द्वारा बताए गए नए दृष्टिकोण क्या हैं?
टॉमस पाजोंक

1
विशेष रूप से संकुचन पदानुक्रम में। आप इसके बारे में और जानकारी यहाँ पा सकते हैं: algo2.iti.kit.edu/routeplanning.php । इसके बारे में एक Google टेक बात भी है: youtube.com/watch?v=-0ErpE8tQbw
सेबस्टियनके

19

बस त्रिकोण असमानता के उल्लंघन को संबोधित करते हुए, उम्मीद है कि वे जिस अतिरिक्त कारक के लिए अनुकूलन कर रहे हैं वह सामान्य ज्ञान है। आप जरूरी नहीं कि सबसे छोटा या सबसे तेज़ मार्ग चाहते हैं, क्योंकि इससे अराजकता हो सकती है और विनाश हो सकता है । यदि आप चाहते हैं कि आपकी दिशाएँ उन प्रमुख मार्गों को पसंद करें जो ट्रक-फ्रेंडली हों और उन्हें नीचे भेजे गए प्रत्येक सत्-नव-चालक का सामना कर सकें, तो आप त्रिकोण असमानता [1] को शीघ्रता से समाप्त कर सकते हैं।

यदि X और Z के बीच Y एक संकीर्ण आवासीय सड़क है, तो आप शायद केवल Y के माध्यम से शॉर्टकट का उपयोग करना चाहते हैं यदि उपयोगकर्ता XZZ के लिए स्पष्ट रूप से पूछता है। यदि वे एक्सजेड के लिए पूछते हैं, तो उन्हें प्रमुख सड़कों पर रहना चाहिए, भले ही यह थोड़ा आगे हो और थोड़ा लंबा हो। यह ब्रैस के विरोधाभास के समान है - यदि हर कोई सबसे छोटा, सबसे तेज़ मार्ग लेने की कोशिश करता है, तो परिणामी भीड़ का मतलब है कि यह किसी के लिए सबसे तेज़ मार्ग नहीं है। यहाँ से हम ग्राफ सिद्धांत से खेल सिद्धांत में भटकते हैं।

[१] वास्तव में, किसी भी आशा से उत्पन्न होने वाली दूरियां गणितीय अर्थों में एक दूरी का कार्य होगा जब आप एकतरफा सड़कों की अनुमति देते हैं और समरूपता की आवश्यकता को खो देते हैं। त्रिभुज असमानता खोना भी घाव में नमक रगड़ना है।


14

यहाँ दुनिया के सबसे तेज़ रूटिंग एल्गोरिदम की तुलना और शुद्धता के लिए सिद्ध किया गया है:

http://algo2.iti.uka.de/schultes/hwy/schultes_diss.pdf

यहाँ इस विषय पर एक Google टेक बात है:

http://www.youtube.com/watch?v=-0ErpE8tQbw

यहाँ राजमार्ग-पदानुक्रम एल्गोरिथ्म का कार्यान्वयन है जैसा कि विद्वानों द्वारा चर्चा की गई है (वर्तमान में केवल बर्लिन में, मैं इंटरफ़ेस लिख रहा हूं और एक मोबाइल संस्करण भी विकसित किया जा रहा है):

http://tom.mapsforge.org/


9

मैंने पहले Google या Microsoft या Yahoo मैप्स पर काम नहीं किया है, इसलिए मैं आपको नहीं बता सकता कि वे कैसे काम करते हैं।

हालांकि, मैंने एक ऊर्जा कंपनी के लिए एक कस्टम सप्लाई चेन ऑप्टिमाइज़ेशन सिस्टम आर्किटेक्ट किया, जिसमें ट्रकों के अपने बेड़े के लिए एक शेड्यूलिंग और रूटिंग एप्लिकेशन शामिल था। हालाँकि, रूटिंग पर हमारा मानदंड कहीं अधिक व्यवसाय-विशिष्ट है जहाँ निर्माण या ट्रैफ़िक धीमा है या लेन बंद है।

हमने एसीओ (एंट कॉलोनी ऑप्टिमाइज़ेशन) नामक एक तकनीक नियोजित की और ट्रकों को रूट किया। यह तकनीक एक AI तकनीक है जो रूटिंग समस्याओं को हल करने के लिए ट्रैवलिंग सेल्समैन समस्या पर लागू की गई थी। ACO के साथ चाल रूटिंग के ज्ञात तथ्यों के आधार पर एक त्रुटि गणना का निर्माण करना है ताकि ग्राफ़ को हल करने वाला मॉडल जानता हो कि कब छोड़ना है (जब त्रुटि काफी छोटी है)।

आप इस तकनीक पर और अधिक जानकारी प्राप्त करने के लिए ACO या TSP को गूगल कर सकते हैं। मैंने हालांकि इसके लिए किसी भी ओपन-सोर्स AI टूल का उपयोग नहीं किया है, इसलिए मैं एक सुझाव नहीं दे सकता (हालांकि मैंने सुना है कि SWARM बहुत व्यापक था)।


4
रूटिंग! = tsp। tsp में आप सभी दूरियों को जानते हैं और आप स्टॉप ऑर्डर को ऑप्टिमाइज़ करते हैं - यह पॉइंट टू पॉइंट एलगो नहीं है।
करुसेल

8

Dijkstra के एल्गोरिथ्म जैसे ग्राफ़ एल्गोरिदम काम नहीं करेंगे क्योंकि ग्राफ़ बहुत बड़ा है।

यह तर्क आवश्यक रूप से पकड़ में नहीं आता है क्योंकि दिज्कस्ट्रा आमतौर पर पूर्ण ग्राफ़ को नहीं देखेगा, बल्कि सिर्फ एक बहुत छोटा सा उपसमुच्चय होगा (बेहतर रूप से ग्राफ को, इस उपसमुच्चय को बेहतर बनाया गया है)।

दिज्क्स्ट्रा वास्तव में अच्छी तरह से व्यवहार किए गए रेखांकन के लिए अच्छा प्रदर्शन कर सकता है। दूसरी ओर, सावधान पैरामीरिजेशन ए * हमेशा अच्छा, या बेहतर प्रदर्शन करेगा। क्या आपने पहले ही कोशिश की है कि यह आपके डेटा पर कैसा प्रदर्शन करेगा?

उस ने कहा, मुझे अन्य लोगों के अनुभवों के बारे में सुनने में भी बहुत दिलचस्पी होगी। बेशक, Google मानचित्र की खोज जैसे प्रमुख उदाहरण विशेष रूप से दिलचस्प हैं। मैं एक प्रत्यक्ष पड़ोसी पड़ोसी की तरह कुछ कल्पना कर सकता था।


2
मान लीजिए कि आप बिंदु A से B तक दिशा-निर्देश प्राप्त करने की कोशिश कर रहे हैं, जिसके लिए इष्टतम दूरी d है। डेज्स्ट्रा का एल्गोरिदम बहुत कम से कम, ए। डी। से एक बिंदु पर सभी बिंदुओं की जांच करेगा। N'est-ce pas?
ए। रेक्स

2
हाँ यही है। जो मैं प्राप्त करना चाहता था वह यह है कि ए * का उपयोग इसके बजाय किया जा सकता है और यह हमेशा एक इष्टतम समाधान पाता है (भले ही यह एक हेयुरिस्टिक का उपयोग करता है)!
कोनराड रुडोल्फ

हां बिल्कुल। अपनी मूल पोस्ट लिखने के बाद, मैंने "हेयुरिस्टिक" शब्द के बारे में सोचा जिसका मैंने उपयोग किया था। यह यहाँ थोड़ा गलत है, क्योंकि यह एक इष्टतम समाधान पाता है।
ए रेक्स

2
खैर, बात यह है कि एक * है का उपयोग करता है (के रूप में करने का विरोध किया एक अनुमानी जा रहा है एक) अगले कदम का निर्धारण करने के। यह एक निर्णय वास्तव में उप-अनुकूल हो सकता है। लेकिन यह केवल रनटाइम को प्रभावित करता है, परिणाम को नहीं, क्योंकि यह केवल यह निर्धारित करता है कि डिजस्ट्ररा की तुलना में यह कितना बेहतर है।
कोनराड रुडोल्फ

8

स्टेटिक रोड नेटवर्क के लिए क्वेरी बार के संदर्भ में कला की वर्तमान स्थिति अब्राहम एट अल द्वारा प्रस्तावित हब लेबलिंग एल्गोरिदम है। http://link.springer.com/chapter/10.1007/978-3-642-20662-7_20 । क्षेत्र के माध्यम से और उत्कृष्ट रूप से लिखित सर्वेक्षण हाल ही में एक Microsoft तकनीकी रिपोर्ट http://research.microsoft.com/pubs/207102/MSR-TR-2014-4.pdf के रूप में प्रकाशित किया गया था ।

लघु संस्करण है ...

हब लेबलिंग एल्गोरिथ्म स्थैतिक सड़क नेटवर्क के लिए सबसे तेज क्वेरी प्रदान करता है, लेकिन चलाने के लिए बड़ी मात्रा में रैम (18 GiB) की आवश्यकता होती है।

ट्रांजिट नोड रूटिंग थोड़ा धीमा है, हालांकि, इसके लिए केवल लगभग 2 गिबी मेमोरी की आवश्यकता होती है और इसमें जल्दी प्रीप्रोसेसिंग समय होता है।

संकुचन पदानुक्रम त्वरित प्रीप्रोसेसिंग समय, कम स्थान आवश्यकताओं (0.4 GiB) और तेज़ क्वेरी समय के बीच एक अच्छा व्यापार प्रदान करते हैं।

कोई भी एल्गोरिथम पूरी तरह से हावी नहीं है ...

पीटर सैंडर्स द्वारा की गई Google की यह तकनीकी रुचि हो सकती है

https://www.youtube.com/watch?v=-0ErpE8tQbw

इसके अलावा एंड्रयू गोल्डबर्ग ने यह बात कही

https://www.youtube.com/watch?v=WPrkc78XLhw

संकुचन पदानुक्रमों का एक खुला स्रोत कार्यान्वयन पीटर सैंडर्स अनुसंधान समूह की वेबसाइट पर केआईटी से उपलब्ध है। http://algo2.iti.kit.edu/english/routeplanning.php

Microsoft द्वारा CRP एल्गोरिथ्म के उपयोग पर एक आसानी से सुलभ ब्लॉग पोस्ट भी ... http://blogs.bing.com/maps/2012/01/05/bing-maps-new-rout-engine/


7

मैं फ़्लॉइड वॉरशॉल के एल्गोरिथ्म को न देखने के लिए थोड़ा आश्चर्यचकित हूं यहां उल्लेखित । यह एल्गोरिथम डीजकस्ट्रा की तरह काम करता है। इसकी एक बहुत अच्छी विशेषता यह भी है कि यह आपको तब तक गणना करने की अनुमति देता है जब तक आप अधिक मध्यवर्ती कोने की अनुमति देना जारी रखना चाहते हैं। तो यह स्वाभाविक रूप से उन मार्गों को ढूंढ लेगा जो अंतरराज्यीय या राजमार्गों का काफी तेज़ी से उपयोग करते हैं।


6

मैंने इसे कई बार किया है, वास्तव में, कई अलग-अलग तरीकों की कोशिश कर रहा हूं। नक्शे के आकार (भौगोलिक) के आधार पर, आप हेवेरीन फ़ंक्शन को एक अनुमान के रूप में उपयोग करने पर विचार करना चाह सकते हैं।

सबसे अच्छा समाधान जो मैंने बनाया है वह एक * एक सीधी रेखा दूरी के साथ एक heuristic फ़ंक्शन के रूप में उपयोग कर रहा था। लेकिन फिर आपको मानचित्र पर प्रत्येक बिंदु (चौराहे या शीर्ष) के लिए किसी प्रकार के निर्देशांक की आवश्यकता होती है। आप यकृत समारोह के लिए अलग-अलग भार भी आज़मा सकते हैं, अर्थात

f(n) = k*h(n) + g(n)

जहाँ k कुछ 0 से अधिक स्थिर है।


4

संभवतः प्रमुख स्थानों और स्तरित नक्शों के बीच पूर्व-संकलित मार्गों पर उत्तर के समान है, लेकिन मेरी समझ यह है कि खेलों में, A * को गति देने के लिए, आपके पास एक ऐसा मानचित्र है जो मैक्रो नेविगेशन के लिए बहुत मोटे है, और एक महीन-बारीक मानचित्र के लिए मैक्रो दिशाओं की सीमा के लिए नेविगेशन। इसलिए आपके पास गणना करने के लिए 2 छोटे रास्ते हैं, और इसलिए आपका खोज स्थान केवल गंतव्य के लिए एक पथ करने की तुलना में बहुत छोटा है। और यदि आप इसे बहुत अधिक करने के व्यवसाय में हैं, तो आपके पास एक पथ के लिए एक खोज के बजाय पूर्व-संगणित डेटा के लिए खोज का एक बहुत कुछ है, इसलिए पूर्व-संगणित डेटा का एक बहुत कुछ होगा।


3

यह मेरी ओर से शुद्ध अटकलें हैं, लेकिन मुझे लगता है कि वे खोज मानचित्र को संकीर्ण करने के लिए निर्देशित मानचित्र को ओवरलेइंग करते हुए एक प्रभाव मानचित्र डेटा संरचना का उपयोग कर सकते हैं। यह खोज एल्गोरिथ्म को वांछित यात्रा लंबा होने पर प्रमुख मार्गों के लिए मार्ग को निर्देशित करने की अनुमति देगा।

यह देखते हुए कि यह एक Google ऐप है, यह मान लेना भी उचित है कि बहुत सारा जादू व्यापक कैशिंग के माध्यम से किया जाता है। :) अगर मैं एक सामान्य लुक-अप द्वारा जवाब दिए जाने वाले अनुरोधों के शीर्ष 5% सबसे आम Google मानचित्र मार्ग अनुरोधों को कैंक करता हूं, तो एक बड़े चंक (20%! 50%?) के लिए अनुमति दी जाती है।


क्या आपके पास "एक प्रभाव मानचित्र डेटा संरचना" के लिए एक अच्छा संदर्भ है? धन्यवाद!
ए। रेक्स

3

इस पर मेरे कुछ और विचार थे:

1) याद रखें कि नक्शे एक भौतिक संगठन का प्रतिनिधित्व करते हैं। हर चौराहे का अक्षांश / देशांतर स्टोर करें। आपको अपने लक्ष्य की दिशा में झूठ बोलने वाले बिंदुओं से आगे की जाँच करने की आवश्यकता नहीं है। यदि आप स्वयं को अवरुद्ध पाते हैं तो ही आपको इससे आगे जाने की आवश्यकता है। यदि आप बेहतर कनेक्शन के ओवरले को स्टोर करते हैं, तो आप इसे और भी अधिक सीमित कर सकते हैं - आप सामान्य रूप से उन लोगों में से एक के रूप में कभी नहीं जाएंगे जो आपके अंतिम गंतव्य से दूर जाते हैं।

2) सीमित कनेक्टिविटी द्वारा परिभाषित क्षेत्रों के पूरे समूह में दुनिया को विभाजित करें, जोनों के बीच सभी कनेक्टिविटी बिंदुओं को परिभाषित करें। जोनों के लिए अपने स्रोत और लक्ष्य क्या हैं, अपने स्थान से प्रत्येक कनेक्शन बिंदु के लिए अपने स्थान से प्रारंभ और अंत क्षेत्र मार्ग के लिए, कनेक्शन बिंदुओं के बीच बस नक्शे के बीच क्षेत्रों के लिए खोजें। (मुझे संदेह है कि बहुत बाद में पहले से गणना की गई है।)

ध्यान दें कि क्षेत्र एक महानगरीय क्षेत्र से छोटे हो सकते हैं। भूभाग वाले कोई भी शहर जो इसे विभाजित करते हैं (कहते हैं, एक नदी) कई क्षेत्र होंगे।


3

मैं उपयोग किए जाने वाले अनुमानों के बारे में बहुत उत्सुक था, जब थोड़ी देर पहले हमें सांता रोजा के पास एक ही शुरुआती स्थान से मार्ग मिला, योसेमाइट नेशनल पार्क में दो अलग-अलग कैंपग्राउंड में। इन अलग-अलग गंतव्यों ने इस तथ्य के बावजूद काफी अलग मार्गों का निर्माण किया (I-580 या CA-12) इस तथ्य के बावजूद कि दोनों मार्ग अंत में कुछ मील की दूरी पर फिर से मोड़ने से पहले अंतिम 100 मील (CA-120 के साथ) में परिवर्तित हो गए। यह काफी रिपीटेबल था। दोनों मार्गों की दूरी लगभग 100 मील के अलावा 50 मील तक थी, लेकिन दूरियां / समय एक दूसरे के काफी करीब थे जैसा कि आप उम्मीद करेंगे।

काश मैं इसे पुन: पेश नहीं कर सकता - एल्गोरिदम बदल गया होगा। लेकिन यह मुझे एल्गोरिथ्म के बारे में उत्सुक था। सभी मैं अनुमान लगा सकता हूं कि कुछ दिशात्मक छंटाई हुई थी जो कि गंतव्य के बीच के छोटे कोणीय अंतर के प्रति अति संवेदनशील थी, जैसा कि दूर से देखा गया था, या अंतिम गंतव्य की पसंद के आधार पर अलग-अलग पूर्वनिर्मित खंड थे।


3

ग्रेफॉपर की बात हो रही हैOpenStreetMap पर आधारित एक फास्ट ओपन सोर्स रूट प्लानर , मैंने थोड़ा साहित्य पढ़ा है और कुछ तरीकों को लागू किया है। सबसे सरल समाधान एक दिक्जस्त्र है और एक साधारण सुधार एक द्विदिश दजक्स्ट्रा है जो केवल नोड्स के आधे हिस्से की खोज करता है। द्विदिशीय दिज्क्स्त्र के साथ पूरे जर्मनी में एक मार्ग पहले से ही 1sec (कार मोड के लिए) लेता है, सी में यह शायद केवल 0.5 या तो होगा;)

मैंने द्विदिश Dijkstra के साथ एक वास्तविक पथ खोज का एक एनिमेटेड जिफ़ बनाया है । इसके अलावा कुछ और भी विचार हैं , जैसे दिज्कस्त्र को तेजी से ए * करना, जो कि "लक्ष्य-उन्मुख दिज्कस्त्र" है। इसके अलावा, मैं इसके लिए एक GIF-एनीमेशन बना रहा हूँ ।

लेकिन इसे (बहुत) तेजी से कैसे करें?

समस्या यह है कि एक पथ खोज के लिए स्थानों के बीच सभी नोड्स का पता लगाया जाना है और यह वास्तव में महंगा है क्योंकि जर्मनी में पहले से ही कई लाखों हैं। लेकिन डीजकस्ट्रा आदि का एक अतिरिक्त दर्द बिंदु यह है कि इस तरह की खोजों में बहुत सारी रैम का उपयोग होता है।

ह्यूरिस्टिक सॉल्यूशंस हैं, लेकिन सटीक सॉल्यूशंस भी हैं जो ग्राफिकल (रोड नेटवर्क) को पदानुक्रमित परतों में व्यवस्थित करते हैं, दोनों में प्रोएंड और प्रो मुख्य रूप से गति और रैम समस्या को हल करते हैं। मैंने उनमें से कुछ को इस उत्तर में सूचीबद्ध किया है ।

ग्राफहॉपर के लिए मैंने संकुचन पदानुक्रम का उपयोग करने का फैसला किया क्योंकि यह लागू करने के लिए सापेक्ष 'आसान' है और ग्राफ की तैयारी के लिए उम्र नहीं लेता है। यह अभी भी बहुत तेजी से प्रतिक्रिया समय में परिणाम देता है जैसे आप हमारे ऑनलाइन उदाहरण ग्राफहॉपर मैप्स पर परीक्षण कर सकते हैं । उदाहरण के लिए दक्षिण अफ्रीका से पूर्वी चीन तक जो 23000 किमी की दूरी तय करता है और लगभग 14 दिन कार चलाने का समय होता है और सर्वर पर केवल ~ 0.1 का समय लगता है।


लक्ष्य-निर्देशित खोज करने के लिए लैंडमार्क का उपयोग करते हुए द्विदिश Dijkstra, द्विदिश Dijkstra की तुलना में अधिक कुशल है। Www14.informatik.tu-muenchen.de/lehre/2010SS/sarntal/… देखें, हालांकि यह पेपर संभावित फ़ंक्शन की गणना करने के लिए पर्याप्त विस्तृत नहीं है, जो थोड़ा मुश्किल है, या स्थलों का चयन करें।
पॉल चेर्नोच

2

मैंने कुछ वर्षों के लिए रूटिंग पर काम किया है, हाल ही में मेरे ग्राहकों की आवश्यकताओं के अनुसार गतिविधि के फटने के साथ, और मैंने पाया है कि ए * आसानी से काफी तेज है; वास्तव में अनुकूलन या अधिक जटिल एल्गोरिदम देखने की कोई आवश्यकता नहीं है। एक विशाल ग्राफ पर रूटिंग एक समस्या नहीं है।

लेकिन गति पूरे रूटिंग नेटवर्क के होने पर निर्भर करती है, जिसका अर्थ है कि मैमोरी में क्रमशः रूट सेगमेंट और जंक्शनों का प्रतिनिधित्व करने वाले आर्क्स और नोड्स का निर्देशित ग्राफ। ओवरहेड मुख्य समय इस नेटवर्क को बनाने में लिया गया समय है। विंडोज चलाने वाले एक साधारण लैपटॉप पर आधारित कुछ मोटे आंकड़े, और पूरे स्पेन में रूटिंग: नेटवर्क बनाने में लगने वाला समय: 10-15 सेकंड; एक मार्ग की गणना करने में लगने वाला समय: मापने के लिए बहुत कम।

दूसरी महत्वपूर्ण बात यह है कि आप जितनी चाहें उतनी रूटिंग गणनाओं के लिए नेटवर्क का फिर से उपयोग करने में सक्षम हों। यदि आपके एल्गोरिथ्म ने सबसे अच्छा मार्ग (वर्तमान नोड के लिए कुल लागत, और इसके लिए सबसे अच्छा चाप) रिकॉर्ड करने के लिए नोड्स को किसी तरह से चिह्नित किया है - जैसा कि ए * में है - आपको इस पुरानी जानकारी को रीसेट या साफ़ करना होगा। सैकड़ों हजारों नोड्स के माध्यम से जाने के बजाय, एक पीढ़ी संख्या प्रणाली का उपयोग करना आसान है। प्रत्येक नोड को उसके डेटा की पीढ़ी संख्या के साथ चिह्नित करें; जब आप एक नए मार्ग की गणना करते हैं तो पीढ़ी संख्या में वृद्धि; पुरानी पीढ़ी की संख्या के साथ कोई भी नोड बासी है और इसकी जानकारी को अनदेखा किया जा सकता है।


1

मैं देख रहा हूँ कि ओपी के नक्शे में क्या है:

निर्दिष्ट बिंदु के साथ मार्ग को देखें: मार्ग सीधा नहीं होने के कारण मार्ग थोड़ा पीछे की ओर जाता है।

यदि उनका एल्गोरिथ्म पीछे नहीं हटेगा तो यह छोटे मार्ग को नहीं देखेगा।


दिलचस्प विचार। मैंने अपने पीपीएस में ओपी में एक और उल्लंघन जोड़ा है। कृपया देखें और देखें कि क्या आप वहां स्पष्टीकरण देख सकते हैं।
ए। रेक्स

ज़ूम रास्ता बिंदु A पर नीचे - एक क्लिक अधिकतम से। ध्यान दें कि तीन-बिंदु मार्ग पश्चिम, दक्षिण, पूर्व में कैसे जाता है। मुझे लगता है कि हम एक ऐसे एल्गोरिथ्म को देख रहे हैं जो तब तक पीछे हटना पसंद नहीं करता जब तक कि उसे चोकपॉइंट से गुजरना जरूरी न हो।
लोरेन Pechtel

मेरे पीपीएस उदाहरण में, शुरुआती पते को "10 एवेन्यू डे फ्लैंड्रे, 75019 पेरिस" में बदलें। यह उस छोटे बैकट्रैक को हटा देता है जिसके बारे में आप बात कर रहे हैं लेकिन समस्या अभी भी है। मुझे लगता है कि मुख्य मुद्दा यह है कि यह वास्तव में उस मुख्य Blvd पर रहना चाहता है ...
ए रेक्स

1
मुझे लगता है कि मैंने इसे इस मामले में पाया: क्या वे कार से हैं और समय समझ में आता है। यह संभवत: बड़ी सड़क को तेजी से देखता है और चलने का मार्ग इसे गला नहीं देता है।
लोरेन Pechtel

1
पुनश्च: प्रारंभिक समस्या भी इस मानक से समझ में आती है, यह बैकट्रैक नहीं हो सकता है जो इसका कारण बना।
लोरेन Pechtel

0

एक ऑल-जोड़े सबसे छोटा पथ एल्गोरिथम एक ग्राफ़ में सभी कोने के बीच सबसे छोटे पथ की गणना करेगा। यह रास्तों को गणना करने की बजाय पूर्व-गणना करने की अनुमति देगा, जब कोई स्रोत और गंतव्य के बीच सबसे छोटा रास्ता खोजना चाहता है। फ्लोयड-वारशाल एल्गोरिथ्म एक सब-जोड़े सबसे छोटा पथ एल्गोरिथम है।


-4

मानचित्र कभी भी पूरे मानचित्र को ध्यान में नहीं रखते हैं। मेरा अनुमान है: - 1. आपके स्थान के अनुसार, वे किसी स्थान और उस स्थान के स्थलों को लोड करते हैं। 2. जब आप गंतव्य खोजते हैं, तो जब वे मानचित्र के दूसरे भाग को लोड करते हैं और दो स्थानों से एक ग्राफ बनाते हैं और फिर सबसे छोटा पथ एल्गोरिदम लागू करते हैं।

इसके अलावा, एक महत्वपूर्ण तकनीक डायनेमिक प्रोग्रामिंग है, जिस पर मुझे संदेह है कि इसका उपयोग सबसे छोटे रास्तों की गणना में किया जाता है। आप इसका भी उल्लेख कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.