यूनिवर्सल NMEA 0183 पार्सर / सी # में फॉर्मेट (+ जावा पर पोर्ट)

उपसर्ग

कोई फर्क नहीं पड़ता कि यह कितना सही लग सकता है, लेकिन एक तैयार समाधान की तलाश है जो (मेरी राय में) NMEA संदेशों के साथ काम करने में पूरी तरह से समर्थन कर सकता है, मुझे यह नहीं मिला।

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

कहानी

मुझे क्षमा करें, जो लोग जानकार हैं, लेकिन स्पष्टता के लिए, मैं फिर भी संक्षेप में घटना के भौतिकी का वर्णन करूंगा।
तो, NMEA मानक का संदेश, मानक में ही "वाक्य" कहलाता है, जो इन "वाक्यों" "बोलता है" - "बात करने वाला" है। उदाहरण के लिए, NMEA के भीतर एक GPS एप्लिकेशन में पहचानकर्ता "GP" है, और चेबर्लिन का हमारा उत्तर "GL" है।

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



वास्तव में, मानक 34 प्रकार के उपकरणों का वर्णन करता है जो बात करने वालों के रूप में कार्य करते हैं, लगभग 74 प्रकार के संदेश (वाक्य), एक मालिकाना कोड (Talker: P) का उपयोग करने की संभावना - डिवाइस निर्माता के विवेक पर अपने स्वयं के आदेश। और इस पूरे किचन को एक ही नामस्थान के नीचे रखना और न रखना शर्म की बात होगी!

सामान्य तौर पर, मैंने वांछित परिणाम से शुरुआत की। परिणामस्वरूप, कार्य सेट किया गया था ताकि निम्न कोड काम करे:

NMEASentence parsedSentence = NMEAParser.Parse(sourceString); 

और अधिक:

 string NMEASentenceString = NMEAParser.Build(parsedSentence); 

और ताकि NMEASentence के अंदर कुछ इस तरह दिखता है:

 public sealed class NMEASentence { public TalkerIdentifiers TalkerID; public SentenceIdentifiers SentenceID; public object[] parameters; } 

वैसे, NMEA वाक्य के सामान्य रूप में यह है:

$ <talker ID> <entence ID,> [पैरामीटर 1], [पैरामीटर 2], ... [<* चेकसम>] <CR> <LF>

यह एक ASCII स्ट्रिंग है जो 82 वर्णों से अधिक नहीं है, शुरुआत में और अंत में "$" है। इस तरह के एक स्ट्रिंग को भागों में छांटने में कोई कठिनाई नहीं है - सब कुछ सरल स्ट्रिंग के साथ किया जाता है ।plit () ;, समस्या यह है कि विशिष्ट अभिव्यक्तियों को कैसे जांचें और पार्स करें।
मानक कई बुनियादी प्रकार के डेटा का वर्णन करता है, मानक के लिए प्रलेखन में वे निम्नानुसार इंगित किए जाते हैं:

"X" संपूर्ण है
"Xx" - वास्तविक
"सी - सी" एक स्ट्रिंग है
ह - हेक्साडेसिमल
"Llll.ll" - अक्षांश
"ययय्य.य्य" - देशांतर
"हैम्ससेस्" - समय
"Ddmmyy" - तारीख
"ए" एक प्रतीक है

अभी भी एक जादुई स्ट्रिंग है "...", जिसका अर्थ है कि बाद के सभी संदेश पैरामीटर पिछले एक के समान प्रकार के हैं।

पार्सिंग को लागू करने के लिए, विभिन्न विकल्पों पर विचार किया गया था, प्रत्येक कमांड को कुछ मूल से विरासत में लेने और प्रत्येक कमांड के तर्क को अलग-अलग लागू करने के लिए, प्रत्येक पैरामीटर को हेयुरिस्टली पार्स करने के लिए।

समाधान सतह पर निकला: एंटीपैर्टन मैजिक स्ट्रिंग्स लागू करें!

चूंकि सभी दस्तावेज़ इस रूप में संदेशों के प्रारूप का वर्णन करते हैं:

$ GPRMA, A, llll.ll, a, yyyyy.yy, a, xx, xx, xx, xx, xx, एक <CR> <LF>

इसलिए उन्हें कोड में संग्रहीत किया जाए - एक ही समय में नए संदेशों के लिए समर्थन जोड़ना बेहद सरल है:
1) मैनुअल से विवरण की प्रतिलिपि बनाएँ
2) कोड में डालें
३) ???
4) लाभ

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

 public enum SentencesIdentifiers { AAM, ALM, APA, ... } 

और अर्थ, मैनुअल से वांछित "जादू लाइन"। यह इस तरह दिखता है:

 public static Dictionary<SentenceIdentifiers, string> SentencesFormats = new Dictionary<SentenceIdentifiers, string>() { { SentenceIdentifiers.AAM, "A,A,xx,N,c--c" }, { SentenceIdentifiers.ALM, "xx,xx,xx,xx,hh,hhhh,hh,hhhh,hhhhhh,hhhhhh,hhhhhh,hhhhhh,hhh,hhh" }, { SentenceIdentifiers.APB, "A,A,xx,a,N,A,A,xx,a,c--c,xx,a,xx,a" }, ... 

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

 private static object ParseToken(string token, string formatter) { ??? } 

पूरे सिस्टम का सबसे अजीब हिस्सा, सभी कानूनों और वर्णमालाओं द्वारा, इन तीन सवालों के तहत, कुछ प्रकार के लंबे स्विच के रूप में तय होगा:

 switch (formatter) { case "xx": { return double.Parse(token, CultureInfo.Invariant); } ... default: return token; //    ,  ,     } 

इस अड़चन पर, सिस्टम का सारा लचीलापन खो जाएगा, जो अच्छा नहीं है, इसलिए ऐसा करना सबसे अच्छा है:

 return parsers[format](token); 

नाम के तहत पार्सर्स सिर्फ चीनी ही छुपा रहा है:

 private static Dictionary<string, Func<string,object>> parsers = new Dictionary<string, Func<string,object>>() { { "x", x => int.Parse(x) }, ... { "hh", x => Convert.ToByte(x, 16) }, ... { "xx", x => double.Parse(x, CultureInfo.InvariantCulture) }, { "c--c", x => x }, { "llll.ll", x => ParseLatitude(x) }, { "yyyyy.yy", x => ParseLongitude(x) }, { "hhmmss.ss", x => ParseCommonTime(x) }, { "ddmmyy", x => ParseCommonDate(x) }, ... }; 

जैसा कि आप देख सकते हैं, यह एक शब्दकोश है, जहां कुंजी एक प्रारूपण स्ट्रिंग है, और मान एक फ़ंक्शन है जो पैरामीटर स्ट्रिंग को ऑब्जेक्ट में बदल देता है।

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

उपरोक्त परिदृश्य से मामूली विचलन के साथ स्थिति स्वामित्व संदेशों के साथ समान है।

पोस्टफ़िक्स

ऊपर वर्णित विचार पूरी तरह से NMEAParser लाइब्रेरी में लागू किए गए थे।
निर्माता कोड की एक पूरी सूची, 222 एंकर पॉइंट (डेटा, डीओपी) की एक सूची भी है।

मैं विषय के लिए पुस्तकालय स्रोत कोड के साथ एक संग्रह संलग्न करना चाहूंगा, लेकिन चूंकि ऐसा कोई अवसर नहीं है, मुझे अपने स्वयं के पीआर के लिए नहीं, कोडप्रोजेक्ट पर अपने स्वयं के लेख के लिए एक लिंक को माफ कर दें - लेकिन मैंने लोगों के लिए कोशिश की कि काम बर्बाद नहीं हुआ।

मुझे आलोचना, इच्छाओं और सुझावों को सुनकर खुशी होगी।

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
अद्यतन: जावा पोर्ट निर्दिष्ट CodeProject लिंक में दिखाई देता है