आरंभ करने से पहले

इस दस्तावेज़ में, डेटासेट के साथ काम करने के लिए ज़रूरी शर्तें, सबसे सही तरीके, और आम तौर पर होने वाली गड़बड़ियों के बारे में बताया गया है.

ज़रूरी शर्तें

डेटासेट बनाते समय:

• आपके Google Cloud प्रोजेक्ट में, डिसप्ले नेम यूनीक होने चाहिए.
• डिसप्ले नेम 64 बाइट से कम होने चाहिए. ऐसा इसलिए, क्योंकि ये वर्ण UTF-8 में दिखाए जाते हैं. कुछ भाषाओं में, हर वर्ण को कई बाइट से दिखाया जा सकता है.
• ब्यौरे 1,000 बाइट से कम होने चाहिए.

डेटा अपलोड करते समय:

• CSV, GeoJSON, और KML फ़ाइल टाइप का इस्तेमाल किया जा सकता है.
• फ़ाइल का साइज़ 500 एमबी से ज़्यादा नहीं होना चाहिए.
• एट्रिब्यूट कॉलम के नाम, "?_" स्ट्रिंग से शुरू नहीं हो सकते.
• थ्री-डाइमेंशन वाली ज्यामिति का इस्तेमाल नहीं किया जा सकता. इसमें डब्ल्यूकेटी फ़ॉर्मैट में "Z" सफ़िक्स और GeoJSON फ़ॉर्मैट में ऊंचाई का निर्देशांक शामिल है.

ध्यान दें: डेटा फ़ाइल के साइज़ के आधार पर, अपलोड होने में कुछ मिनट या घंटे भी लग सकते हैं. अगर अपलोड करने में कोई गड़बड़ी होती है, तो आपको गड़बड़ी का मैसेज मिलेगा. डेटासेट को तब तक मिटाने की कोशिश न करें, जब तक कि अपलोड की प्रोसेस पूरी होने का जवाब न मिल जाए.

ध्यान दें: Maps Datasets API का इस्तेमाल करके अपलोड किए गए डेटा से बनाए गए मैप टाइल, ज़ूम करने के कम लेवल पर ज़्यादा या जटिल डेटा को छोड़ सकते हैं या उसे आसान बना सकते हैं. उदाहरण के लिए, जब कोई उपयोगकर्ता किसी राज्य या देश को ज़ूम आउट करता है (जैसे, ज़ूम करने का लेवल 5 से 12), तो टाइल किया गया डेटा, किसी शहर या आस-पास के इलाके को ज़ूम इन करने पर दिखने वाले डेटा से अलग दिख सकता है (जैसे, ज़ूम करने का लेवल 13 से 18). ऐसा इसलिए होता है, ताकि टाइल को स्लिम और बेहतर परफ़ॉर्मेंस वाला बनाया जा सके. इसके लिए, मैप रेंडरर के साथ टाइल का इस्तेमाल किया जाता है.

सलाह: अगर आपकी डेटा फ़ाइल बड़ी है और उसमें कई ऐसे एट्रिब्यूट हैं जिनकी आपको स्टाइलिंग के लिए ज़रूरत नहीं है, तो फ़ाइल में बदलाव करके उन एट्रिब्यूट को हटा दें. इससे रेंडरिंग की परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जा सकेगा. एट्रिब्यूट की संख्या कम करने से, मैप की टाइल का साइज़ कम हो जाता है. इससे रेंडरिंग की परफ़ॉर्मेंस बेहतर होती है.

डेटा तैयार करने के सबसे सही तरीके

अगर आपका सोर्स डेटा जटिल या बड़ा है, जैसे कि डेंस पॉइंट, लंबी लाइनस्ट्रिंग या पॉलीगॉन (अक्सर 50 एमबी से बड़ी सोर्स फ़ाइलें इस कैटगरी में आती हैं), तो विज़ुअल मैप में बेहतर परफ़ॉर्मेंस पाने के लिए, अपलोड करने से पहले अपने डेटा को आसान बनाएं.

डेटा तैयार करने के लिए, यहां कुछ सबसे सही तरीके दिए गए हैं:

1. सुविधा की प्रॉपर्टी को छोटा करें. सिर्फ़ उन सुविधाओं की प्रॉपर्टी रखें जिनकी ज़रूरत मैप को स्टाइल करने के लिए है. उदाहरण के लिए, "id" और "category". यूनीक आइडेंटिफ़ायर कुंजी पर डेटा-ड्रिवन स्टाइल का इस्तेमाल करके, क्लाइंट ऐप्लिकेशन में किसी सुविधा में अतिरिक्त प्रॉपर्टी जोड़ी जा सकती हैं. उदाहरण के लिए, डेटा-ड्रिवन स्टाइलिंग की मदद से, रीयल टाइम में अपना डेटा देखना लेख पढ़ें.
2. जहां तक हो सके, प्रॉपर्टी ऑब्जेक्ट के लिए सिंपल डेटा टाइप का इस्तेमाल करें. जैसे, इंटीजर. इससे टाइल का साइज़ कम होता है और मैप की परफ़ॉर्मेंस बेहतर होती है.
3. फ़ाइल अपलोड करने से पहले, जटिल ज्यामिति को आसान बनाएं. इसके लिए, अपनी पसंद के किसी जियोस्पेशल टूल का इस्तेमाल किया जा सकता है. जैसे, ओपन सोर्स Mapshaper.org यूटिलिटी. इसके अलावा, BigQuery में ST_Simplify का इस्तेमाल करके, जटिल पॉलीगॉन ज्यामिति को आसान बनाया जा सकता है.
4. फ़ाइल अपलोड करने से पहले, बहुत ज़्यादा डेंस पॉइंट को क्लस्टर करें. इसके लिए, अपनी पसंद के किसी जियोस्पेशल टूल का इस्तेमाल किया जा सकता है. जैसे, ओपन सोर्स turf.js क्लस्टर फ़ंक्शन. इसके अलावा, BigQuery में ST_CLUSTERDBSCAN का इस्तेमाल करके, डेंस पॉइंट जियोमेट्री पर भी ऐसा किया जा सकता है.

डेटासेट इस्तेमाल करने के सबसे सही तरीकों के बारे में ज़्यादा जानने के लिए, डेटासेट और BigQuery की मदद से अपना डेटा विज़ुअलाइज़ करना लेख पढ़ें.

GeoJSON की ज़रूरी शर्तें

Maps Datasets API, मौजूदा GeoJSON स्पेसिफ़िकेशन के साथ काम करता है. Maps Datasets API, ऐसी GeoJSON फ़ाइलों के साथ भी काम करता है जिनमें इनमें से कोई भी ऑब्जेक्ट टाइप शामिल हो:

• ज्यामिति ऑब्जेक्ट. ज्यामिति ऑब्जेक्ट, एक स्पेशल शेप होता है. इसे पॉइंट, लाइन, और पॉलीगॉन के यूनियन के तौर पर दिखाया जाता है. इसमें वैकल्पिक होल भी होते हैं.
• फ़ीचर ऑब्जेक्ट. किसी फ़ीचर ऑब्जेक्ट में, ज्यामिति के साथ-साथ नाम/वैल्यू के अतिरिक्त जोड़े शामिल होते हैं. इनका मतलब, ऐप्लिकेशन के हिसाब से होता है.
• फ़ीचर कलेक्शन. फ़ीचर कलेक्शन, फ़ीचर ऑब्जेक्ट का एक सेट होता है.

Maps Datasets API, ऐसी GeoJSON फ़ाइलों के साथ काम नहीं करता जिनमें WGS84 के अलावा, किसी अन्य कोऑर्डिनेट रेफ़रंस सिस्टम (सीआरएस) में डेटा मौजूद हो.

GeoJSON के बारे में ज़्यादा जानकारी के लिए, आरएफ़सी 7946 के मुताबिक देखें.

KML फ़ाइल के लिए ज़रूरी शर्तें

Maps Datasets API के लिए ये ज़रूरी शर्तें हैं:

• सभी यूआरएल, फ़ाइल के लिए लोकल (या रिलेटिव) होने चाहिए.
• पॉइंट, लाइन, और पॉलीगॉन ज्यामिति का इस्तेमाल किया जा सकता है.
• सभी डेटा एट्रिब्यूट को स्ट्रिंग माना जाता है.

KML की ये सुविधाएं काम नहीं करतीं:

• फ़ाइल के बाहर तय किए गए आइकॉन या <styleUrl>.
• नेटवर्क लिंक, जैसे कि <NetworkLink>
• ग्राउंड ओवरले, जैसे कि <GroundOverlay>
• 3D ज्यामिति या ऊंचाई से जुड़े कोई भी टैग, जैसे कि <altitudeMode>
• कैमरे की खास जानकारी, जैसे कि <LookAt>
• KML फ़ाइल में तय की गई स्टाइल.

CSV फ़ाइल के लिए ज़रूरी शर्तें

CSV फ़ाइलों के लिए, कॉलम के नाम प्राथमिकता के क्रम में नीचे दिए गए हैं:

• latitude, longitude
• lat, long
• x, y
• wkt (Well-Known Text)
• address, city, state, zip
• address
• एक ही कॉलम में पते की पूरी जानकारी, जैसे कि 1600 Amphitheatre Parkway Mountain View, CA 94043

उदाहरण के लिए, आपकी फ़ाइल में x, y, और wkt नाम के कॉलम मौजूद हैं. x और y को ज़्यादा प्राथमिकता दी जाती है. ऐसा ऊपर दी गई सूची में, इस्तेमाल किए जा सकने वाले कॉलम के नामों के क्रम के हिसाब से तय किया जाता है. इसलिए, x और y कॉलम में मौजूद वैल्यू का इस्तेमाल किया जाता है और wkt कॉलम को अनदेखा कर दिया जाता है.

इसके अलावा:

• हर कॉलम का नाम, सिर्फ़ एक कॉलम से जुड़ा होना चाहिए. इसका मतलब है कि आपके पास xy नाम का ऐसा कॉलम नहीं हो सकता जिसमें x और y, दोनों निर्देशांकों का डेटा हो. X और Y निर्देशांक अलग-अलग कॉलम में होने चाहिए.
• कॉलम के नाम केस-इनसेंसिटिव होते हैं.
• कॉलम के नामों का क्रम मायने नहीं रखता. उदाहरण के लिए, अगर आपकी CSV फ़ाइल में lat और long कॉलम हैं, तो वे किसी भी क्रम में हो सकते हैं.

डेटा अपलोड करने से जुड़ी गड़बड़ियां ठीक करना

डेटासेट में डेटा अपलोड करते समय, आपको इस सेक्शन में बताई गई सामान्य गड़बड़ियों में से कोई एक गड़बड़ी दिख सकती है.

GeoJSON से जुड़ी गड़बड़ियां

GeoJSON से जुड़ी आम गड़बड़ियां:

• type फ़ील्ड मौजूद नहीं है या type कोई स्ट्रिंग नहीं है. अपलोड की गई GeoJSON डेटा फ़ाइल में, हर Feature ऑब्जेक्ट और Geometry ऑब्जेक्ट की परिभाषा के हिस्से के तौर पर, type नाम का एक स्ट्रिंग फ़ील्ड होना चाहिए.

KML से जुड़ी गड़बड़ियां

KML फ़ाइल में आम तौर पर होने वाली गड़बड़ियां:

• डेटा फ़ाइल में, ऊपर बताई गई KML की ऐसी कोई भी सुविधा नहीं होनी चाहिए जो काम नहीं करती. ऐसा न होने पर, डेटा इंपोर्ट नहीं हो पाएगा.

CSV फ़ाइल में गड़बड़ियां

CSV फ़ाइल में आम तौर पर होने वाली गड़बड़ियां:

• कुछ पंक्तियों में, ज्यामिति कॉलम के लिए वैल्यू मौजूद नहीं हैं. CSV फ़ाइल की सभी पंक्तियों में, ज्यामिति कॉलम के लिए वैल्यू मौजूद होनी चाहिए. ज्यामिति कॉलम में ये शामिल हैं:
  • latitude, longitude
  • lat, long
  • x, y
  • wkt
  • address, city, state, zip
  • address
  • एक ही कॉलम में पते की पूरी जानकारी, जैसे कि 1600 Amphitheatre Parkway Mountain View, CA 94043
  ध्यान दें: इस गड़बड़ी के बारे में अक्सर इस तरह के मैसेज से बताया जाता है, "' ' को डबल में नहीं बदला जा सका" या "इनपुट को भौगोलिक जानकारी में पार्स नहीं किया जा सका.: जियोग्राफ़ी की वैल्यू मौजूद नहीं है".
• अगर x और y आपके ज्यामिति कॉलम हैं, तो पक्का करें कि इकाइयां देशांतर और अक्षांश हों. कुछ सार्वजनिक डेटासेट, हेडर x और y के तहत अलग-अलग कोऑर्डिनेट सिस्टम का इस्तेमाल करते हैं. अगर गलत यूनिट का इस्तेमाल किया जाता है, तो हो सकता है कि डेटासेट इंपोर्ट हो जाए. हालांकि, रेंडर किया गया डेटा, डेटासेट के पॉइंट को अनचाही जगहों पर दिखा सकता है.