8

मेरे पास कुछ कोड है जो मैं एपीआई v2 से v3 तक पोर्टिंग कर रहा हूं। पुराने कोड में हमारे पास एक सटीकता क्षेत्र था जो एक्सएमएल में वापस आया (नाम के बारे में सुनिश्चित नहीं है, लेकिन यह आत्मविश्वास के स्तर का प्रतिनिधित्व करता है)। नई एपीआई में, मुझे ऐसा कोई क्षेत्र नहीं दिख रहा है।क्या v3 Google मानचित्र जियोकोडिंग API में कोई फ़ील्ड है जो सटीकता का प्रतिनिधित्व करता है?

यदि मैं खोज क्षेत्र में "ओरेगन, यूएसए" डालता हूं तो मुझे 5 मैच मिलते हैं। पहले 2 "ओरेगन, यूएसए" और "ओरेगन, ओएच, यूएसए" हैं। दोनों में "partial_match" = झूठा है। यह सही प्रतीत नहीं होता है, कोई आंशिक लगता है और कोई नहीं करता है। इसके अलावा, वे दोनों एक ही "location_type" (APPROXIMATE) के साथ वापस आ रहे हैं। वास्तव में, सभी मैच आंशिक रूप से दिखाए जा रहे हैं और समान स्थान प्रकार हैं।

मेरा सवाल है, नतीजे के किसी भी क्षेत्र में परिणाम के सटीकता में किसी प्रकार का आत्मविश्वास व्यक्त करते हैं? मेरे नमूने में यह वास्तव में लगता है कि एक परिणाम किसी अन्य की तुलना में अधिक सटीक है - इतना है कि इनपुट स्ट्रिंग वास्तव में QuickAddress फ़ील्ड से मेल खाती है जो वापस आती है।

उत्तर

11

दो सप्ताह, कोई जवाब नहीं, तो यह मेरा समाधान है।

एपीआई या तो ROOFTOP, GEOMETRIC_CENTER, RANGE_INTERPOLATED या APPROXIMATE वापस आ जाएगी।

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

+0

बहुत चालाक। उस बारे में सोचा नहीं होगा। मैंने अपने "गैर छत" पते के साथ कुछ परीक्षण किया और एक बड़ी श्रृंखला पाई। हमारे पास चार ब्रेकडाउन, रूफटॉप, स्ट्रीट (यानी ब्लॉक, या ज़िप + 4), ज़िप + 2 और ज़िप हैं। Google गैर-रूफटॉप स्थान-प्रकारों में से प्रत्येक के लिए मैंने शुद्धता का और विश्लेषण करने के लिए तर्क बनाया है क्योंकि कभी-कभी APPROXIMATE ज़िप + 4 (जो, शहरी क्षेत्रों में सामान्य रूप से रूफटॉप के करीब है) की तरह समाप्त होता है और RANGE_INTERPOLATED ज़िप की तरह अधिक है, यानी विशाल। –

+0

मैंने देखा कि एक और बात यह थी कि कभी-कभी Google सड़क के पते के साथ रूफटॉप देता है लेकिन सूट/यूनिट/एपीटी/जो कुछ भी जोड़ता है ... इसे सक्रिय करने के लिए स्विच किया जाता है, भले ही लेट/लॉन वही रहता है। यह वह जगह है जहां आपका विचार आसान था। उप-इकाई जोड़ने के दौरान अन्य बार केवल सड़क का पता APPROXIMATE इसे ROOFTOP पर स्विच करता है। मैंने पहले और अधिक देखा, यानी अधिक डेटा, कम "आत्मविश्वास"। मैं पहले उप-इकाई के बिना कोशिश करने के लिए तर्क में निर्माण करने की सोच रहा हूं और यदि ROOFTOP उप-इकाई के साथ प्रयास नहीं करता है। यदि अभी भी रूफटॉप नहीं है, तो बाध्यकारी बक्से की तुलना करें और छोटे का उपयोग करें। –

+0

@ एंड्रयूएस धन्यवाद, मुझे लगता है कि मैं इंटरनेट के इस विशेष कोने में एकमात्र ऐसा था - मुझे याद नहीं आया कि Google समूह पर कभी जवाब नहीं मिला ... – jcollum

2

मैं इस उपयोगी होता है जब अद्यतन करने विरासत V2 कोड एक 0 से 9 तक स्कोर
// हैक 0-9 के रूप में जियोकोड स्कोर 0-9 जियोकोड स्कोर को LOCATION_TYPE (स्ट्रिंग) कन्वर्ट करने के लिए v3 में मौजूद नहीं है पर निर्भर पाया है एपीआई

function get_numeric_score(results) { 
switch(results[0].geometry.location_type){ 
     case "ROOFTOP": 
      return 9; 
     break; 

     case "RANGE_INTERPOLATED": 
      return 7; 
     break; 

     case "GEOMETRIC_CENTER": 
      return = 6; 
     break; 

     case "APPROXIMATE": 
      return 4; 
     break; 

     default: 
      return 0; 

    } 
} 
संबंधित मुद्दे