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

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

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

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

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

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

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

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

अगर आपका सोर्स डेटा जटिल या बड़ा है, जैसे कि घने पॉइंट, लंबी लाइनस्ट्रिंग या पॉलीगॉन (अक्सर 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 के बारे में ज़्यादा जानकारी के लिए, RFC 7946 के मुताबिक देखें.

KML से जुड़ी ज़रूरी शर्तें

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

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

CSV फ़ाइल से जुड़ी ज़रूरी शर्तें

CSV फ़ाइलों के लिए, प्राथमिकता के क्रम में कॉलम के ये नाम इस्तेमाल किए जा सकते हैं:

  • latitude, longitude
  • lat, long
  • x, y
  • wkt (वेल-नोन टेक्स्ट)
  • 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 हेडर में अलग-अलग कोऑर्डिनेट सिस्टम का इस्तेमाल करते हैं. अगर गलत यूनिट का इस्तेमाल किया जाता है, तो हो सकता है कि डेटासेट इंपोर्ट हो जाए. हालांकि, रेंडर किए गए डेटा में, डेटासेट पॉइंट ऐसी जगहों पर दिख सकते हैं जहां उन्हें नहीं दिखना चाहिए.