KML को CSV में बदलें

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

ऐसी फ़ाइल के लिए CSV ज़्यादा ईमानदार कंटेनर है। हर प्लेसमार्क नाम और निर्देशांक की पंक्ति बनता है, जो geocoder, route optimiser, CRM इम्पोर्ट या `GROUP BY` असल में इस्तेमाल करता है। जो कुछ इसे ड्रॉइंग बनाता था वह पीछे छूट जाता है, और यह जान-बूझकर छूटा है, सीमा नहीं — आइकन URL का कॉलम किसी काम नहीं आता, और HTML विवरण बैलून के लिए कोई कॉलम आकार बचता ही नहीं।

KML निर्देशांक `longitude,latitude,altitude` के तौर पर एक ही स्पेस-अलग स्ट्रिंग में लिखता है। इस परिवार के लगभग हर और फ़ॉर्मेट, GPX और TCX समेत, पहले latitude रखता है, और यह उलटफेर सबसे आम वजह है जिससे KML बदलाव ग़लत होता है: जोड़ा घूम जाता है, तो 13.4, 52.5 पर बर्लिन 52.5, 13.4 बनकर अरब सागर में पहुँच जाता है।

यह बदलाव उन्हें वापस बदल देता है, तो CSV कॉलम `latitude` फिर `longitude` में होते हैं। इसे भरोसा करने की बजाय जाँचना ठीक है, और एक सेकंड की जाँच है: पश्चिमी यूरोप के लिए latitude क़रीब 36 से 71 और longitude क़रीब −10 से 30 चलता है, तो अगर पहला निर्देशांक कॉलम छोटा है और दूसरा बड़ा, कहीं ऊपर उन्हें फिर से घुमा दिया गया है।

KML नेस्ट करता है। `<Document>` में `<Folder>` एलिमेंट होते हैं, जिनमें और फ़ोल्डर और आख़िर में `<Placemark>` एलिमेंट geometry के साथ। Reader उस पेड़ को पूरा घूमता है, सिर्फ़ एक स्तर नीचे झाँकता नहीं, क्योंकि मैपिंग टूल से एक्सपोर्ट हुई KML अक्सर अपने प्लेसमार्क तीन स्तर नीचे रखती है।

यह घुमाई फ़ोल्डर बनावट नहीं रखती। `Sites / Phase 2 / Confirmed` में पड़ा पिन ऊपरी स्तर वाले से अलग नहीं दिखने वाली पंक्ति बनता है, क्योंकि CSV में सिर्फ़ एक `name` कॉलम है और वह प्लेसमार्क का है। अगर समूहीकरण ही जानकारी है, तो बदलने से पहले उसे प्लेसमार्क नामों में लिखना होगा।

जिस Placemark में `<Point>` है वह एक `waypoint` पंक्ति बनता है। जिसमें `<LineString>` है वह `track` की एक क्रम पंक्तियाँ बनाता है, हर वर्टेक्स के लिए एक, सब उसी प्लेसमार्क नाम के साथ। ये दोनों घूम रही ज़्यादातर KML को ढँकते हैं और दोनों अपने नाम सलामत लेकर आते हैं।

दो चीज़ें कुछ नहीं देतीं, और दोनों बदलने से पहले जानने लायक़ हैं। `<Polygon>` — कोई छायांकित इलाक़ा, संपत्ति की सीमा, सेवा क्षेत्र — अपनी रूपरेखा नेस्टेड बाउंड्री एलिमेंट में रखता है जिसमें यह पार्सर नहीं उतरता, तो इलाक़ा कोई पंक्ति नहीं देता। एक प्लेसमार्क में कई लाइनें लपेटने वाला `<MultiGeometry>` भी उसी वजह से छोड़ दिया जाता है।

LineString एक आकार है जिसमें कब का कोई भान नहीं। अगर KML GPS एक्सपोर्ट से आई है, ड्रॉइंग से नहीं, तो शायद इसमें `gx:Track` हो, Google का विस्तार जो `<when>` टाइमस्टैम्प और `<coord>` पोज़िशन की समानांतर सूची रखता है। Reader इसे लाइन मानकर नहीं, अलग मामले की तरह संभालता है, और टाइमस्टैम्प `time` कॉलम में जाते हैं।

यह पहचानने का तरीक़ा है कि `time` कॉलम भरा है या नहीं। अगर हर सेल ख़ाली है, तो स्रोत में LineString थीं, और कोई भी कन्वर्टर वह समय वापस नहीं ला सकता जो फ़ाइल ने कभी सहेजा ही नहीं।

KML निर्देशांक का तीसरा मान मीटर में ऊँचाई है, और बदलाव इसे मौजूद होने पर `elevation` कॉलम में लिख देता है। यह `<altitudeMode>` नहीं देखता, जो बताता है ऊँचाई को कैसे समझा जाए — ज़मीन से चिपकी, उसके सापेक्ष, या पूर्ण।

यह इसलिए मायने रखता है क्योंकि Google Earth का डिफ़ॉल्ट `clampToGround` है, जिसमें ऊँचाई का मान पूरी तरह अनदेखा होता है और अक्सर `0` लिखा जाता है। पहाड़ी इलाक़े पर हाथ से बनाई KML में `elevation` कॉलम शून्य से भरा हो सकता है जिसका मतलब है "सतह पर", "समुद्र तल पर" नहीं।

नतीजा हर `waypoint` पंक्ति को हर `track` पंक्ति से पहले रखता है, चाहे दस्तावेज़ में क्रम कुछ भी रहा हो। यह आम हालत के लिए सहूलियत है: पिन वाली KML ऐसी फ़ाइल बनती है जिसकी सब पंक्तियाँ waypoint हैं, और पिन प्लस खींचा रास्ता मिलाकर बनी KML आपको पिन ऊपर देती है।

क़ीमत यह है कि दोनों तरह में दस्तावेज़ का क्रम नहीं बचता। अगर KML में सुविधाओं का क्रम कुछ मायने रखता था — जिस क्रम में सर्वे ने साइट देखीं, मसलन — वह क्रम प्लेसमार्क नाम या `time` कॉलम से आना चाहिए, पंक्ति संख्या से नहीं।

प्लेसमार्क नाम वह फ़ील्ड है जो किसी सादे CSV को सबसे आसानी से तोड़ सकता है, क्योंकि यह किसी इंसान का लिखा मुक्त टेक्स्ट है। `Warehouse 3, Rear Entrance` में डिलीमीटर है, और नाम के तौर पर इस्तेमाल पता उससे कई रखता है। Writer कॉमा, उद्धरण चिह्न या नई लाइन वाले किसी भी मान को quote करता है और भीतरी उद्धरण चिह्न दोहराता है, जो RFC 4180 माँगता है।

निर्देशांक को कभी quoting नहीं चाहिए, तो फ़ाइल टेक्स्ट एडिटर में भी पढ़ने लायक़ रहती है। नतीजे को आँख से जाँचते समय quote किए नाम देखने लायक़ पंक्तियाँ हैं।

KML किसी Placemark पर `<address>` एलिमेंट तय करता है, और Google Earth उसे तब भरता है जब पिन किसी जगह खोजकर बनाया गया, गोले पर क्लिक करके नहीं। यह यहाँ पढ़ा नहीं जाता, तो नतीजे में नाम और निर्देशांक होते हैं, डाक पते जैसा कुछ नहीं, भले स्रोत दस्तावेज़ में हो।

ज़्यादातर गंतव्य के लिए यह नुक़सान नहीं, क्योंकि latitude और longitude किसी सड़क वाली लाइन से मज़बूत कुंजी है और हर routing, mapping और geocoding सेवा उसे सीधे स्वीकार करती है। जहाँ पता सच में चाहिए — कोई मेलिंग रन, डिलीवरी मैनिफ़ेस्ट — वहाँ निर्देशांक के ख़िलाफ़ reverse-geocoding क़दम से लेना होगा।

बदलाव पूरी तरह इसी ब्राउज़र टैब में चलता है — KML पढ़ी, घुमाई और दोबारा लिखी जाती है स्थानीय तौर पर, और कोई रिक्वेस्ट उसे कहीं नहीं ले जाती। न कोई अकाउंट, न कतार, न पढ़ने लायक़ रिटेंशन नीति, क्योंकि सर्वर पर रखने को कुछ है ही नहीं।

परवाह करने की वजह यह है कि प्लेसमार्क सूची अक्सर क्या होती है। पिन वाली KML अक्सर ग्राहक सूची, डिलीवरी पते, मरीज़ या क्लाइंट साइट, या ऐसी संपत्तियों की जगहें होती हैं जिन्हें कोई प्रकाशित नहीं करना चाहेगा।