कैसे मैंने ड्राइवरों के लिए एक मानचित्र खोज को ठीक करने की कोशिश की। भाग २

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

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

पहले भाग में, मैंने इस सरल विचार से काम करने वाले समाधान तक अपना रास्ता बताया, और फिर मैं यह वर्णन करूँगा कि मैंने इस समाधान को कैसे खींच लिया।

अपना समय बचाने के लिए, मैं पिछले भाग की संक्षिप्त जानकारी के साथ शुरुआत करूँगा: वहाँ मैं लिखता हूँ कि मैंने खोज के बजाय गति में स्कैनिंग का उपयोग करने का निर्णय लिया, और अनुप्रयोग इंटरफ़ेस को यथासंभव सरल बनाया गया। ड्राइवर के लिए एक बेतुका प्रवेश लाइन के बजाय, उसने कई बड़े बटन जोड़े, जो सड़क पर काम कर सकते हैं: गैस स्टेशन, चार्जिंग, एटीएम, पार्किंग, फार्मेसी। एक नक्शे के बजाय, मैंने एक सूची बनाई, और जब मैं एक परिणाम का चयन करता हूं, तो Apple / Google मानचित्र के माध्यम से नेविगेशन खुल जाता है। आवेदन के लिए, मैंने फ़्लटर का उपयोग करने का फैसला किया (उसी समय मुझे पता चला कि यह किस तरह का जानवर है), मैंने ओपनचिटपर्स से डेटा लिया। मैंने अपनी कहानी इस तथ्य पर समाप्त की कि कम या ज्यादा संत प्रोटोटाइप तैयार था।

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

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

प्रौद्योगिकी के

सामान्य वास्तुकला

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

1. एपीआई सर्वर (पायथन) - मुख्य सर्वर-बिछाने, हम इसे चालू करते हैं। बहुत सारे तर्क नहीं हैं, मुख्य रूप से आउटपुट के लिए परिणाम। संसाधनों के लिहाज से सबसे किफायती।
2. इलास्टिक सर्वर (जावा) - इलास्टिसर्च और फोटॉन (ओपन सोर्स जियोकोड) इस पर कताई कर रहे हैं। वे उसी इंडेक्स का उपयोग करते हैं जिसमें पूरे ग्रह को OpenStreetMap से आयात किया जाता है। सर्वर फ़ंक्शन: लैंडफिल और जियोकोडर द्वारा स्थानों की खोज करें। इसकी प्रकृति से, लोचदार बहुत तेज और हल्का है, इसलिए सर्वर भी बहुत चिकना नहीं है।
   
3. एक जियो सर्वर (नोड) सभी में सबसे कठिन है। ओपन सोर्स रूटिंग मशीन के आधार पर, मैंने एक छोटा सा एपी लिखा था, और इसके कार्यों में सभी भौगोलिक गणनाएं शामिल हैं: मार्ग बिछाने, आइसोक्रेट्स की गणना, और टाइलें उत्पन्न करना। प्रत्येक व्यक्तिगत ऑपरेशन बहुत संसाधन नहीं है, लेकिन किसी भी खोज के लिए उनमें से दर्जनों की आवश्यकता होती है, और यह एक अड़चन बन जाता है। फिलहाल, इस सर्वर पर 16 जीबी रैम और सामान्य तौर पर, सब कुछ एक स्प्लिट सेकंड में काम करता है - टाइल्स को छोड़कर। जब कतार में उनमें से बहुत सारे होते हैं, तो आप कुछ सेकंड में कार्ड के साथ चित्रों की प्रतीक्षा कर सकते हैं। सौभाग्य से, वे ग्राहक पर अतुल्यकालिक रूप से दिखाई देते हैं, और यह समग्र चित्र (मुझे आशा है) को बहुत खराब नहीं करता है।
   

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



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

गतिशील isochron

लंबे समय तक, मेरे लिए प्रमुख समस्याओं में से एक परिणाम का विषम घनत्व था। कारण काफी समझ में आता है - यह सड़क नेटवर्क का विषम घनत्व है और इस पर इमारतें हैं। 5 मिनट के दायरे में एक मध्यम आकार के शहर में 2-3 एटीएम हो सकते हैं, और अब हम महानगर के केंद्र में जाएंगे - और 5 मिनट के लिए 20 और 30 परिणाम हो सकते हैं। अंत में, हम ग्रामीण इलाकों में कूदते हैं और लगभग गारंटी 0 परिणामों का निरीक्षण करते हैं जब तक कि हम शहर के करीब नहीं पहुंचते और खोज त्रिज्या कुछ पकड़ लेती है।

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

जब एक समाधान पाया गया, तो यह बहुत सरल निकला। विपरीत से जाने और उपयोगकर्ता को खोज त्रिज्या का चयन करने के बजाय, हम इस त्रिज्या को स्वचालित बना सकते हैं। तर्क वास्तव में प्राथमिक है:

1. आप परिणामों पर सीमा निर्धारित करते हैं - उदाहरण के लिए, कम से कम 1 और 20 से अधिक नहीं - और 10 मिनट से शुरू करें
   
2. जगह-जगह खोज करें। अब तक, हमें उन्हें दिशा-निर्देश प्राप्त करने की आवश्यकता नहीं है, इसलिए हमें लोचदार में बहुभुज द्वारा आइसोक्रोन और फ़िल्टर की गणना करने की आवश्यकता है - दोनों ऑपरेशन बहुत सस्ते हैं
   
3. यदि परिणामों की संख्या सीमाओं से एक दिशा में बाहर निकलती है (हमारे मामले में 0 या 20+), तो समय को 2 से विभाजित करें और फिर से खोज करें। यदि यह सीमा में शामिल है, तो पहले से ही हम मार्गों का निर्माण करते हैं, समय के अनुसार क्रमबद्ध करते हैं, आदि।
   

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

वास्तव में, एक व्यक्ति 5-6 पदों से नीचे की सूची को स्क्रॉल करने की संभावना नहीं है, इसलिए 95% परिदृश्यों में डायनामिक आइसोक्रोन ने समस्या को हल किया। हमने बाधाओं को हटा दिया - परिणामों की अप्रत्याशित मात्रा - और लगभग किसी भी अनुरोध के लिए भौगोलिक सर्वर पर लोड बनाया। इसे देखना बहुत आसान है:

पुराना तरीका: 10 मिनट के दायरे और 30 परिणाम लें
परिणाम: मार्गों के लिए isochron + 30 अनुरोधों के लिए 1 अनुरोध = 31

नया तरीका: चेक करें, 30 परिणाम कई हैं, त्रिज्या को आधे में विभाजित करें, अब हमें 10 परिणाम मिलते हैं
परिणाम: मार्गों के लिए isochrone + 10 अनुरोधों के लिए 2 अनुरोध = 12

नया नक्शा तर्क

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

पहली चीज जो मैंने करने का फैसला किया, वह था कम्पास का उपयोग करके वास्तविक समय में मानचित्रों को तैनात करना। स्पंदन में, यह सूक्ष्म तर्क द्वारा वर्णित किया गया था और बहुत तेज़ी से काम किया था, हालांकि, 10+ परिणामों के साथ जो लगातार स्पिन करता है, प्रदर्शन नाली करना शुरू कर दिया। इसके अलावा, यह बिल्कुल बीमार लग रहा था: वास्तव में, स्थिर चित्र कताई कर रहे थे, और यह सवारी के दौरान अधिक भ्रामक था, क्योंकि यह किसी भी तरह से मदद करता था।

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

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



ऊपर दिए गए चित्र में, मैंने मोटे तौर पर अपना समाधान दिया। नतीजतन, यह संसाधनों के मामले में बहुत महंगा नहीं निकला और 99% परिदृश्यों को कवर करता है (मुझे लगता है कि कीड़े डंडे के पास कहीं चढ़ेंगे)। सामान्य तौर पर, भू-गणना सर्वर अभी भी परियोजना का सबसे संसाधन-गहन हिस्सा है, लेकिन अब सौंदर्यशास्त्र के अलावा, इसके रूट कार्ड भी बहुत व्यावहारिक हैं। यहां तक ​​कि मैंने इन कार्डों का विशेष रूप से उपयोग करने के लिए जगह पाने की कोशिश की, न कि नेविगेशन सहित। और पहुंचे भी।

डेटा की गुणवत्ता

मैंने अपने सभी डेटा को OpenStreetMap से अलग-अलग तरीकों से लिया। जैसा कि आप जानते हैं, यह संसाधन 100% गैर-लाभकारी है और एक सामूहिक दिमाग द्वारा समर्थित है। यह एक प्लस है (यह मुफ़्त है और एक स्पष्ट संरचना के साथ), यह एक शून्य भी है - डेटा बहुत विषम है।

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

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

एक ही टैग के कई पर्यायवाची और रूपांतर हैं -> हम उपनाम उपनामों का वर्णन करते हैं (जैसे पार्किंग, पार्किंग_स्पेस, पार्किंग_आंतर, आदि)।

एक ही प्रकार और समान निर्देशांक वाले कई स्थान हैं:

• यदि सभी का कोई नाम नहीं है -> स्थान का प्रकार नाम बन जाता है
• केवल एक का नाम है -> इसे लें
• सभी का एक नाम है और वे अलग हैं -> अंतिम नाम कालानुक्रमिक रूप से लेते हैं

एक ही प्रकार और लगभग समान निर्देशांक वाले कई स्थान हैं:

• अगर सभी का कोई नाम नहीं है -> सबसे अधिक संभावना डुप्लिकेट है, तो हम जटिल नहीं होंगे। औसत निर्देशांक के साथ एक बिंदु में विलय करें, जिसमें स्थान का प्रकार नाम बन जाता है। एक आदमी आएगा और समझेगा
• केवल एक का नाम है -> एक ही बात, केवल अब हमारे पास पहले से ही एक नाम है
• सभी का एक नाम है और वे अलग हैं -> लेकिन यह एक क्लस्टर है

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

इंटरफ़ेस और डिजाइन

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

कलर पैलेट

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

"रास्ते में" और "आप पास हैं"

ड्राइवर के आंदोलन की दिशा निर्धारित करने वाले तर्क के सामने आने के बाद, मार्गों को "रास्ते में" और बाकी हिस्सों में विभाजित करना संभव हो गया। जैसा कि मैंने पहले ही कहा था, यह निर्धारित स्थान के पहले खंड से निर्धारित होता है: क्या यह चालक के मार्ग के अंतिम खंड के साथ मेल खाता है। यदि हां, तो हम पहले से ही इस जगह पर जा रहे हैं। फिर सवाल उठता है कि इसे इंटरफ़ेस में कैसे दिखाया जाए। ऊपर वर्णित नक्शे में परिवर्तन के अलावा, यह विचार अंग्रेजी में "रास्ते में" प्लेट (या "एन मार्ग" पर आया था - ऐसा लगता है कि उनका मतलब वही है)। मैं एक और परिदृश्य के लिए उसी मरने का पुन: उपयोग करता हूं: जब मिली हुई जगह की दूरी 25 मीटर से कम हो। फिर यह दिशा पाने के लिए कोई मतलब नहीं है, मैं नक्शा छिपाता हूं और लिखता हूं कि आप पहले से ही करीब हैं ("आप पास हैं" / "चारों ओर देखो")।

सामुदायिक कार्ड

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

स्थानीयकरण

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



लेकिन तकनीकी पक्ष पर यह इतना सहज नहीं था। — Intl_translation , … . , . , (!) - , … , , .

, , — - . , , .

, , . , -, — . , . , . .

- support androidx: - , , . , — . : . , , .

, , :

. - — . , №2:

• (, )
• ,
• , (, -)
• ( — - , )

Android Auto Apple CarPlay. , .

, .