स्टोरेज, विज़ुअलाइज़ेशन और एनालिसिस के लिए सबसे अच्छे मॉडल जीपीएस ट्रैक कैसे करें?

Question

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

मुझे आश्चर्य है कि ट्रैकपॉइंट के संबंध में सबसे अधिक वैचारिक रूप से मजबूत डेटा मॉडल क्या होना चाहिए, और यहां कुछ "उम्मीदवार" हैं:

1. ट्रैकप्वाइंट के दृश्यों को ट्रैक मानते हुए:

   1.1। ट्रैक को "2 डी" माना जाता है, क्योंकि मानचित्र अनुमान 2 डी हैं। ट्रैकप्वाइंट में ऊंचाई हो सकती है या नहीं, टाइमस्टैम्प हो सकता है या नहीं। ऊंचाई और टाइमस्टैम्प "एक्स्ट्रा", "वैकल्पिक" माना जाता है। स्थलीय अनुप्रयोगों के लिए, उत्थापन लैट / लोन (डीईएम के माध्यम से प्राप्य) का एक सीधा कार्य है;

   1.2। भौगोलिक स्थान के बाद से ट्रैक को "3 डी" माना जाता है, वास्तव में 3 डी है, और रिसीवर का प्रक्षेपवक्र 3 डी है (2 डी प्रोजेक्शन इस प्रकार डेटा में कमी का एक रूप है)। टाइमस्टैम्प मौजूद हो या न हो (ट्रैक हाथ से खींचा जा सकता था)।

   1.3। ट्रैक को "4 डी" (3 स्थानिक + समय) माना जाता है। इस प्रकार, एक हाथ से खींचा गया नक्शा एक विशेष मामला है जहां ऊंचाई और टाइमस्टैम्प nullमौजूद हैं या अन्यथा मौजूद नहीं हैं, लेकिन ट्रैकपॉइंट गुण हमेशा "वहां" होते हैं।

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

अगर मुझे सही समझ में आता है, GPX प्रारूप 1.1 को गोद लेता है। KML 1.2 को अपनाता है। (टाइमस्टैम्प के लिए कोई समर्थन नहीं), और स्ट्रवा एपीआई 2. (JSON प्रारूप में) को गोद लेती है, लेकिन अंत में ये क्रमबद्धता और भंडारण के लिए केवल FILE प्रारूप हैं, जरूरी नहीं कि मॉडलिंग, कम्प्यूटेशनल प्रतिनिधित्व और नंबरक्रंचिंग के लिए।

क्या कोई ऐसा रूप है, जो वस्तु-प्रधान अर्थ में, और क्यों है? (मेरा मानना ​​है कि मजबूत टाइपिंग और समझदार मॉडलिंग कम से कम संचालन से बचती है, जिसका कोई मतलब नहीं है)।

संपादित करें: कुछ "पेचीदा" अतिरिक्त प्रश्न:

• क्या एक हाथ से तैयार ट्रैक एक ही चीज़ है जो डिवाइस-रिकॉर्डेड ट्रैकलॉग है? क्या वे विभिन्न डेटा प्रकारों के होने चाहिए?
• क्या इसे "सही" माना जाना चाहिए कि KML शून्य के रूप में ऊँचाई को संग्रहीत करता है? शून्य एक ऊँचाई है, और यदि आप उस ऊँचाई को नहीं जानते हैं जो आपको इसके लिए एक संख्यात्मक शून्य आवंटित नहीं करना चाहिए, है ना?
• क्या यह मायने रखता है कि ऊंचाई वाले ट्रैक में, यदि ऊंचाई DEM डेटा ("ऑफ़लाइन") या GPS डेटा या बैरोमीटर डेटा ("फ़ील्ड में") से निकाली गई है? क्या इसे ट्रैक ऑब्जेक्ट में चिह्नित किया जाना चाहिए? अलग-अलग ट्रैकपॉइंट गुणों से बचा? अवहेलना करना? वे अलग संग्रह डेटाटिप्स होना चाहिए?
• यदि मैं एक मैप एडिटर में डिवाइस-रिकॉर्डेड ट्रैक को एडिट करता हूं (पॉइंट्स को जोड़ना, हिलाना और हटाना), या अलग-अलग तारीखों से ट्रैक को जोड़ता है, तो ट्रैकप्वाइंट में टाइमस्टैम्प को कैसे संभाला जाना चाहिए? क्या उन्हें अशक्त करने के लिए "रीसेट" किया जाना चाहिए? क्या पूर्व से अलग प्रकार का कोई ऑब्जेक्ट (ट्रैकपॉइंट कलेक्शन) बनाया जाना चाहिए?

Comments

3. ट्रैक एक्स, वाई, जेड, एम [] और समय विशेषताओं के साथ अंकों का एक संग्रह है। कैप्चर किए गए प्रत्येक बिंदु के लिए इन 5 मानों वाली एक CSV फ़ाइल एक मजबूत डेटा मॉडल के लिए पर्याप्त से अधिक है। आप की तरह फैंसी चीजों की जरूरत है <>और {}मदद करने के लिए आप अपने डेटा को व्यवस्थित - और मेटा डेटा - आप गलत कर रहे हैं।

— नगिटेच

मैं सिर्फ एक अच्छे पुराने CSV से सहमत हूँ, यह सब कुछ दर्शाता है जो GPS रिकॉर्डिंग कर रहा है। लेकिन, जीपीएस उपकरणों के लिए GPX प्रारूप बहुत आम है। यह लिंक कुछ के लायक हो सकता है क्योंकि GPS और KML दोनों XML डेटा फॉर्मेट हैं। stackoverflow.com/questions/1820129/…

— पीट

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

— नागटेक

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

— हेलटनबीकर

OO के संदर्भ में, मैंने एक रेखा वर्ग का उपयोग किया है जो अंक (lat, lng, ele, time, speed, असर, आदि) को पकड़ सकता है। और, वहाँ से रूट जो कि हाथ से खींचे गए या इच्छित "ट्रैक्स" का प्रतिनिधित्व करते हैं और ट्रैक्स जो समय / गति डेटा के साथ वास्तविक ट्रैक का प्रतिनिधित्व करते हैं। वैचारिक रूप से मुझे लगता है कि वे अलग हैं (हाथ खींचा या एक कार्टोग्राफर द्वारा आपूर्ति की गई है, या इस तरह, बनाम एक वास्तविक ट्रैक)। शब्द सिर्फ शब्दार्थ हैं, निश्चित हैं, लेकिन वास्तविक प्रकारों का उपयोग करना मददगार रहा है (केवल इसे "ट्रैक" के रूप में एक साथ मिलाने के बजाय)। इसके अलावा, जब यह क्रमांकन प्रारूपों की बात आती है, तो मैं GeoJSON पर विचार करूंगा: en.wikipedia.org/wiki/GeoJSON ।

— चार्ली कॉलिन्स 14

Answer 1

मुझे नहीं लगता कि इस सवाल का वास्तव में निश्चित रूप से उत्तर दिया जा सकता है क्योंकि इस के करीब आने के कई तरीके हैं।

हालाँकि, ये विचार प्रासंगिक हो सकते हैं:

डेटा संग्रहण अपेक्षाकृत महत्वहीन है। डेटाबेस, JSON, KML, आदि जो भी तंत्र आप उपयोग करते हैं, वह अभी भी "फ्लैट भंडारण" है।

आपके द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर में क्या महत्वपूर्ण है और आप सॉफ़्टवेयर में डेटा का प्रतिनिधित्व कैसे करते हैं ताकि आप अपने मॉडलिंग का संचालन कर सकें।

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

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

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

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

यदि ऊंचाई ज्ञात नहीं है, तो यह ज्ञात नहीं है, इसलिए इसे शून्य नहीं होना चाहिए। यह भी नकारात्मक नहीं होना चाहिए, क्योंकि नकारात्मक उन्नयन मान्य ऊंचाई भी हैं। (नीचे समुद्र तल घाटी, खदान गड्ढे आदि में)

हाँ, DEMS उपलब्ध हैं, हाँ आप उनसे निकाल सकते हैं। क्या इतना सटीक होगा? जब तक सटीकता एक मुद्दा नहीं है, तब तक। जीपीएस या बैरोमीटर प्रदान की गई ऊंचाई आपके द्वारा प्राप्त की जाने वाली सर्वश्रेष्ठ होगी।

तो कोशिश करें और आपको एक जवाब दें जो करीब जाता है:

डेटा को अपने पसंद के किसी भी फ़्लैट में स्टोर करें, लेकिन मैं सुझाऊँगा, PostGIS विथ पोस्टग्रैस एक अच्छा विकल्प है, यह 3D अच्छी तरह से हैंडल करता है। तब आप अपने डेटा में हेरफेर / मॉडल करने के लिए PostGIS में व्यापक स्थानिक कार्यों का उपयोग कर सकते हैं।

यदि आप अपने द्वारा विकसित किसी कस्टम प्रोग्राम का उपयोग करते हैं, तो सरणियों के बजाय ऑब्जेक्ट ओरिएंटेड दृष्टिकोण का उपयोग करें। यदि आप सरणियों का उपयोग करते हैं, तो आप एक डेटाबेस का भी उपयोग कर सकते हैं।

Comments

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

— हेलटोनबीकर

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

— बारीकियों का

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

— हेल्टनबिकर 19

Answer 2

जैसा कि पहले से ही एक और जवाब में बताया गया है, कई अलग-अलग दृष्टिकोण हैं। चूंकि मैंने "वैचारिक रूप से मजबूत डेटा मॉडल" के लिए पूछा था, बहुत शोध के बाद मुझे ज्ञान के दो महान निकाय मिले जो "चलती वस्तुओं" की अवधारणा के लिए दो बिल्कुल अलग दृष्टिकोण प्रदान करते हैं, और बहुत सारे ओवरलैप हैं (एक अच्छे अर्थ में):

1. स्प्रिंगर वर्लग द्वारा प्रकाशित गेन्नेडी और नतालिया एंड्रीन्को की पुस्तकें, उदाहरण के लिए मूवमेंट के उत्कृष्ट विज़ुअल एनालिटिक्स (एक ही प्रकाशक से अन्य)। अत्यधिक सिफारिशित।
2. ISO / OGC (ISO 191xx मानदंड) का सार विनिर्देश (वैचारिक स्कीमा), विशेष रूप से ISO 19107 (स्थानिक स्कीमा), 19108 (टेम्पोरल स्कीमा), 19111 (निर्देशांक द्वारा स्थानिक संदर्भ), 19141 (चलती सुविधाएँ) और 19148 (रेखीय संदर्भ)