OpenStreetMap परियोजना की डेटा संरचना, स्कर्ट सेवा के तहत एक नज़र रखना

प्रस्तावना

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

सामान्य तौर पर, संपूर्ण डेटा संरचना को निम्न आकृति में योजनाबद्ध रूप से दर्शाया जा सकता है:

चित्रा 1. OpenStreetMap डेटा संरचना।

सभी डेटा को तीन मुख्य समूहों में विभाजित किया जा सकता है:

1. डेटा प्रकार जो ऑब्जेक्ट को एक पदानुक्रमित कनेक्शन के रूप में वर्णित करते हैं, एक प्रकार की स्थानिक इकाई के रूप में जिसका अपना अंतिम परिणाम होता है - ऑब्जेक्ट के सभी भागों के ज्ञात निर्देशांक;
2. सूचना भाग एक वस्तु की वर्णनात्मक विशेषता है जिसका वस्तु के स्थानिक भौगोलिक संरचना से सीधा संबंध नहीं है (इसका नाम, भौतिक, तार्किक और अन्य गुण);
3. डेटा सेट के रूप में सूचना के भंडारण और प्रसंस्करण की प्रक्रिया को व्यवस्थित करने के लिए आवश्यक वस्तु की सेवा विशेषताएँ, जैसे कि एक अद्वितीय पहचानकर्ता, डेटाबेस में ऑब्जेक्ट की स्थिति, समय डेटाबेस में अंतिम बार संपादित किया गया था, आदि।

मैं वस्तुओं की सेवा विशेषताओं पर ध्यान केंद्रित नहीं करूंगा, मैं केवल यह नोट करूंगा कि वे OSM में किसी स्वतंत्र वस्तु के पास हैं और प्रोजेक्ट API का विशिष्ट संस्करण उनकी विशेषताओं और कुछ विशेषताओं के बंधन को निर्धारित करता है। वर्तमान में, यह संस्करण 0.6 एपीआई है।

भाग 1. OpenStreetMap में भौगोलिक डेटा के बुनियादी प्रकार

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

पहला प्रकार: एक बिंदु (नोड) एक न्यूनतम डेटा सेट है जिसमें निर्देशांक की एक जोड़ी के बारे में जानकारी होती है: अक्षांश, देशांतर (अक्षांश, लोन) और एक पदानुक्रमित मॉडल में आधार है। यह एकमात्र डेटा प्रकार है जो भौगोलिक जानकारी को स्वयं संग्रहीत करता है - निर्देशांक, अक्षांश और देशांतर के रूप में। OSM डेटा मॉडल WGS84 प्रक्षेपण के भीतर दो-आयामी डेटा पर विशेष रूप से संचालित होता है। भविष्य में, हम मान लेंगे कि निर्देशांक बिंदु वस्तु का सूचना घटक नहीं है, बल्कि इसकी संरचना का एक अभिन्न अंग है। XML संकेतन में, इस प्रकार की एक वस्तु इस तरह दिखाई देगी:

  <नोड आईडी = '19 'अक्षांश = '58 .888047127548994' लोन = '49 ।747870758186764 '/> 

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

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

लाइन प्रकार की एक वस्तु का सही XML संकेतन सभी आवश्यक बिंदुओं का वर्णन करने के लिए होगा, इसके बाद लाइन खुद होगी, जो इसके सभी बिंदुओं को सूचीबद्ध करती है। सबसे सरल संस्करण में, यह इस तरह दिखेगा:

  <नोड आईडी = '23 'अक्षांश = '58 .875047918145675' लोन = '49 = .785240674006126 '/>
 <नोड आईडी = '22 'अक्षांश = '58 .86687448573524' लोन = '49 ।737090974777324 '/>

 <राह आईडी = '24 '>
   <एन डी रेफ = '22 '/>
   <एन डी रेफ = '23 '/>
 </ रास्ता> 

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

यदि हम मौजूदा बिंदुओं 19 और 23 से एक और रेखा बनाना चाहते हैं, तो हम इसका वर्णन इस तरह करेंगे:

  <राह आईडी = '48 '>
   <nd ref = '19 '/>
   <एन डी रेफ = '23 '/>
 </ रास्ता> 

हमारे मामले में, अंक 19 और 23 पहले से ही ऊपर वर्णित हैं, और बिंदु 23 दो लाइनों 24 और 48 का हिस्सा बन गया और उनके लिए सामान्य हो गया।

हमारी रेखाएँ २४ और ४ follows रेखांकन को मर्केटर के प्रक्षेपण में निम्नानुसार दर्शा सकती हैं:


आंकड़ा 2. दो लाइनें

आकृति में कैप्शन वस्तुओं की आईडी हैं: बिंदुओं पर लाल, लाइनों पर काला; तीर रेखा की दिशा को इंगित करता है, अर्थात दोनों लाइनें बिंदु 23 पर समाप्त होती हैं।

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

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

  <संबंध आईडी = '31 '>
   <सदस्य प्रकार = 'रास्ता' रेफ = '24 '/>
   <सदस्य प्रकार = 'नोड' रेफरी = '19 '/>
 </ संबंध> 

यह एक काल्पनिक अमूर्त संबंध है जो बताता है कि इसमें दो वस्तुएं (संबंध के सदस्य) - बिंदु 24 और पंक्ति 19 शामिल हैं और अब कोई अन्य जानकारी नहीं लेती है। वास्तविक मामले में, रिश्ते में संबंध वस्तु के टैग (सूचना घटक) के रूप में निर्दिष्ट प्रकार होना चाहिए, और रिश्ते के सदस्यों को वस्तुओं के लिंक में भूमिकाएं होनी चाहिए।

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

  <नोड आईडी = '1218' अक्षांश = '58 ।870941122729505 'लोन = '49 ।7580210197295555' />
 <नोड आईडी = '1216' अक्षांश = '58 ।8704000725183 'लोन = '34.74703196841415' />
 <नोड आईडी = '1215' लेट = '58 .879055860772034 'लोन = '34 ।74964840920353' />
 <नोड आईडी = '1209' लैट = '58 .86471853452049 'लोन = '49.78052242410518245' />
 <नोड आईडी = '1207' लेट = '58 .863365649894774 'लोन = '34 ।72453057762546' />
 <नोड आईडी = '1206' अक्षांश = '58 .892035483174 'लोन = '49 = .74755525657201' />
 <राह आईडी = '1217'>
   <nd ref = '1215' />
   <nd ref = '1216' />
   <nd ref = '1218' />
   <nd ref = '1215' />
 </ रास्ता>
 <राह आईडी = '1208'>
   <nd ref = '1206' />
   <nd Ref = '1207' />
   <nd Ref = '1209' />
   <nd ref = '1206' />
 </ रास्ता>
 <संबंध आईडी = '1221'>
   <सदस्य प्रकार = 'रास्ता' रेफ = '1208' भूमिका = 'बाहरी' />
   <सदस्य प्रकार = 'रास्ता' रेफ = '1217' भूमिका = 'आंतरिक' />
   <tag k = 'type' v = 'multipolygon' />
 </ संबंध> 

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


चित्रा 3. मल्टीपोलीगॉन

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

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

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

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

भाग 2. वस्तुओं की सूचना योजना

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

  <राह आईडी = '24 '>
   <एन डी रेफ = '22 '/>
   <एन डी रेफ = '23 '/>
   <टैग k = 'राजमार्ग' v = 'प्राथमिक' />
 </ रास्ता> 

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

यदि हम पहले भाग से अपनी दो पंक्तियों 24 और 48 के सूचनात्मक विवरण का विस्तार करते हैं, तो हम कुछ ऐसा प्राप्त कर सकते हैं:

  <नोड आईडी = '23 'lat = '58 .87753645355202' lon = '49 ।79290110146539 '>
   <टैग k = 'राजमार्ग' v = 'traffic_signals' />
 </ नोड>
 <नोड आईडी = '22 'अक्षांश = '58 .87456113991739' लोन = '49 = .73690926857261 '/>
 <नोड आईडी = '19 'lat = '58 .89362576054878' lon = '49 ।7492065402827 '/>
 <राह आईडी = '48 '>
   <nd ref = '19 '/>
   <एन डी रेफ = '23 '/>
   <टैग k = 'तटबंध' v = 'हां' />
   <टैग k = 'राजमार्ग' v = 'माध्यमिक' />
   <tag k = 'incline' v = 'up' />
   <टैग k = 'लेन' v = '2' />
   <tag k = 'maxspeed' v = '60 '/>
   <टैग k = 'नाम' v = 'पॉज़र्स्की स्ट्रीट' />
 </ रास्ता>
 <राह आईडी = '24 '>
   <एन डी रेफ = '22 '/>
   <एन डी रेफ = '23 '/>
   <टैग k = 'राजमार्ग' v = 'प्राथमिक' />
   <टैग k = 'लेन' v = '6' />
   <tag k = 'lit' v = 'yes' />
   <टैग k = 'नाम' v = 'मिनिन एवेन्यू' />
   <tag k = 'oneway' v = 'yes' />
   <टैग k = 'Ref' v = 'M84' />
 </ रास्ता> 

लाइन 48 "पॉशर्स्की स्ट्रीट" बन गई, जिसकी गति सीमा 60 किमी / घंटा है, गलियों की संख्या दो के बराबर है, जो कि बिंदु 19 से बिंदु 23 की दिशा में एक सकारात्मक ढाल है, जो एक माध्यमिक सड़क है और जमीनी स्तर के सापेक्ष तटबंध के लिए ऊंचा है। और लाइन 24 मुख्य ट्रैफ़िक है (द्वितीयक से अधिक वर्ग के साथ) 6 ट्रैफ़िक लेन के साथ, जिसमें स्थिर प्रकाश व्यवस्था है और पॉइंट 22 से पॉइंट 23 की दिशा में एकतरफ़ा ट्रैफ़िक की अनुमति है, जिसे "मिनिना एवेन्यू" कहा जाता है और यह संघीय राजमार्ग 984 का हिस्सा है। दोनों सड़कों पर एक सामान्य बिंदु 23 है, जो एक ट्रैफिक लाइट के साथ एक चौराहा है।

वर्तमान टैगिंग समझौतों के बारे में विस्तार से वर्णन करना एक लेख का कार्य नहीं है; इसके लिए अपनाए गए समझौतों को ठीक करने के लिए एक अलग मसौदा विकि-प्रलेखन है [1] । आइए हम केवल टैगिंग के मूल सिद्धांतों पर ध्यान दें।

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

भाग 3. ज्यामितीय आदिम

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

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

तो, बुनियादी ज्यामितीय आदिम क्या बनते हैं।

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

लाइन सुविधाएँ

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

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

प्रकार:


चित्रा 4. पॉलीलाइन = रास्ता (नोड 1, नोड 2, नोड 3, नोड 4)


आंकड़ा 5. पॉलीलाइन = संबंध (वे 1 (नोड 1, नोड 2), वे 2 (नोड 2, नोड 3), वे 3 (नोड 3, नोड 4))


आंकड़ा 6. पॉलीलाइन = संबंध 2 (रास्ता 1 (नोड 1, नोड 2), संबंध 1 (रास्ता 2 (नोड 2, नोड 3) , वे 3 (नोड 3, नोड 4)))

क्षेत्र की वस्तुएं

एक बहुभुज (बहुभुज)एक बंद पॉलीलाइन है जिसमें अंतिम बिंदु पहले के साथ मेल खाता है। डेटा प्रकारों में, OSM एक तरह से ऑब्जेक्ट से कई (तीन या अधिक) नोड ऑब्जेक्ट के साथ मेल खाता है, और जिस तरह से ऑब्जेक्ट मेंबर्स की संख्या हमेशा एक से अधिक होती है, क्योंकि पहला नोड ऑब्जेक्ट दो बार दोहराया जाता है: शुरुआत में और सूची के अंत में। इसके अलावा, बहुभुज को संबंध के रूप में इकट्ठा किया जा सकता है, जिस तरह से श्रृंखला में शामिल किया जाता है, एक संयुक्त रूप से बंद लूप बनाता है, अर्थात। प्रत्येक तरह से वस्तु की शुरुआत एक दूसरे तरीके की वस्तु के अंत से मेल खाती है। रास्ते में बहुभुज के विपरीत, संबंध में बहुभुज पहले से गणना में अंतिम वस्तु की नकल नहीं करता है, क्योंकि जिस तरह से यह इस तथ्य के कारण आवश्यक है कि यह नोड वस्तुओं को संदर्भित करता है और केवल नोड की नकल करने के तथ्य के रूप में सदस्यों की सूची का पहला और अंतिम तत्व है यह एक बंद बहुभुज है, और एक बहुभुज की रैखिक वस्तु नहीं है।एक बहुभुज में एक संबंध के रूप में इकट्ठा किया जाता है, अंतिम सम्मिलित वस्तु के अंतिम नोड ऑब्जेक्ट जिस तरह से होता है या जिस तरह से संबंध होता है वह पहले शामिल किए गए तरीके के पहले नोड ऑब्जेक्ट से मेल खाता है।

संबंध के रूप में वर्णित बहुभुज के मामले में, संबंध वस्तु पर टाइप = मल्टिपोलीगॉन टैग को स्वयं इंगित किया जाना चाहिए। इस प्रकार, हम निर्धारित करते हैं कि हम एक क्षेत्र ज्यामितीय के बारे में बात कर रहे हैं, न कि एक रैखिक वस्तु।

बहुभुज के प्रकार:


चित्रा 7. बहुभुज = रास्ता (नोड 1, नोड 2, नोड 4, नोड 1)


चित्रा 8. बहुभुज = संबंध (वे 1, नोड 2, नोड 3), रास्ता 2 (नोड 3, नोड 4), रास्ता 3 (नोड 4, नोड 1)


चित्र 9. बहुभुज = संबंध 3 (संबंध 1 (रास्ता 1, नोड 2, नोड 3), वे 2 (नोड 3, नोड 4), वे 3 (नोड 4, नोड 5), वे 4 (नोड 5, नोड 6, नोड 7)), संबंध 2 (वे 5 (नोड 7, नोड 8) , रास्ता 6 (नोड 8, नोड 1)))

यौगिक वस्तुएँ

समग्र वस्तुएं ऐसी वस्तुएं हैं जिन्हें एक आदिम तरीके से वर्णित नहीं किया जा सकता है, वे हमेशा प्रकार = मल्टीप्लगॉन के साथ संबंधित वस्तुओं के आधार पर बनाई जाती हैं। संबंध के रूप में वर्णित बहुभुज और पॉलीलाइन को हमेशा एक तरह से ऑब्जेक्ट को सरल बनाया जा सकता है, जबकि सबसे सरलीकृत मामले में एक कंपाउंड ऑब्जेक्ट कम से कम दो तरह से ऑब्जेक्ट देता है। उदाहरण के लिए, यह एक क्षेत्र आकार (बहुभुज) है जिसमें से एक और आकार गणितीय रूप से घटाया जाता है (छोटे बहुभुज)। मल्टीप्लगॉन का एक उदाहरण, जो एक समग्र वस्तु है, जिसमें एक दृष्टांत के साथ पहले भाग में , संबंधित वस्तुओं के विवरण में दिया गया था ।

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

एक मल्टीप्लायगन में एक भूमिका वाली सभी वस्तुओं को एक या एक से अधिक बंद आकृति में इकट्ठा किया जाना चाहिए जो सीमाओं पर प्रतिच्छेद नहीं करते हैं।

संबंध के रूप में वर्णित ग्राफिक आदिम का उपयोग करने के लिए सीमाएं और सम्मेलनों

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

1. संबंध द्वारा वर्णित सभी क्षेत्र वस्तुएं मल्टीप्लगॉन हैं, अर्थात। टाइप करें = मल्टीप्लिओगन और बाहरी के लिए एक अनिवार्य भूमिका संकेत। आंतरिक सदस्य, अर्थात् 8 और 9 के आंकड़ों में बहुभुज हमेशा केवल बहुभुज होते हैं;
2. , relation : type=boundary type=route , relation ; 5 6 , , relation, ;
3. relation, type = multipolygon|boundary|route — , - , .

भाग 4. इसे बेहतर बनाने के लिए क्या करें?

अब तक मैंने मौजूदा OSM डेटा संरचना का वर्णन किया है, जिसके अनुसार वास्तविकता में कौन सा सिद्धांत काम करेगा या कार्यान्वित नहीं होगा। अब मैं ओएसएम डेटा प्रारूप की सबसे महत्वपूर्ण संरचनात्मक समस्या को तैयार करने की कोशिश करूंगा और इसे ठीक करने के लिए क्या किया जाना चाहिए।

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

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

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

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

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

मुझे उम्मीद है कि पढ़ने के बाद आपको OpenStreetMap परियोजना में डेटा संरचना का एक विचार है।

[१] - OSM में वस्तुओं को टैग करने के लिए मूल नियम, मूल: http://wiki.openstreetmap.org/wiki/Map_Features और अनुवाद: http://wiki.openstreetmap.org/wiki/RU:Map_Features