การสร้างความสามารถในการตรวจสอบตําแหน่งโดยใช้ Google Maps Platform

วัตถุประสงค์

คุณมักต้องการตรวจสอบสถานที่ตั้งของสถานที่ Google Maps Platform มีบริการต่างๆ ที่ช่วยคุณใน Use Case นี้ได้ เอกสารนี้จะช่วยคุณเลือกระหว่างบริการตรวจสอบสถานที่ตั้งหลัก 2 รายการ ได้แก่ Address Validation API และ Geocoding API

Address Validation API เป็นบริการจาก Google Maps Platform ที่ช่วยลูกค้าตรวจสอบว่าที่อยู่ถูกต้องหรือไม่

การเข้ารหัสพิกัดภูมิศาสตร์ ด้วย Geocoding API คือกระบวนการแปลงที่อยู่เป็นพิกัดทางภูมิศาสตร์ ซึ่งคุณสามารถใช้เพื่อวางมาร์กเกอร์บนแผนที่หรือตำแหน่งบนแผนที่

ดูภาพรวมระดับสูงของความแตกต่างระหว่าง Address Validation API และ Geocoding API ได้ที่นี่ ที่นี่

ลองเลย: ไปที่คอนโซล Google Cloud แล้วเปิดใช้ Address Validation API และ Places API

กรณีที่ควรเลือก Address Validation API แทน Geocoding API

หมายเหตุเกี่ยวกับโฟลว์ชาร์ตด้านบน

• Use Case การโต้ตอบกับผู้ใช้หมายถึงกรณีที่ผู้ใช้มีส่วนร่วมในการโต้ตอบกับผลลัพธ์
• Places Autocomplete เป็น JavaScript API จึงเหมาะสำหรับการผสานรวมกับอินเทอร์เฟซผู้ใช้
• คุณอาจทราบปัญหาด้านคุณภาพของข้อมูลในที่อยู่ที่คุณมีอยู่ ดังนั้น แม้ว่าคุณจะต้องการเพียงรหัสพิกัดภูมิศาสตร์ แต่เราขอแนะนำให้เรียกใช้ที่อยู่เหล่านั้นผ่าน Address Validation API เพื่อแก้ไขชุดข้อมูล

มีหลายกรณีที่คุณอาจเลือกใช้ผลิตภัณฑ์หนึ่งแทนอีกผลิตภัณฑ์หนึ่งตามแผนผังการตัดสินใจด้านบน แต่ในบางกรณี คุณอาจต้องใช้ผลิตภัณฑ์ทั้ง 2 รายการเพื่อให้บรรลุเป้าหมาย

คุณอาจเลือกใช้ Address Validation API แทน Geocoding API ในกรณีต่อไปนี้

• มีโอกาสสูงที่ข้อมูลจะมีปัญหาหรือการได้รับที่อยู่ไม่ถูกต้องจะส่งผลเสียต่อการทำงานในภายหลัง เนื่องจาก Address Validation API ให้ข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่อินพุตไม่ได้รับผลลัพธ์ที่มีความแม่นยำสูง
• คุณต้องแก้ไขอินพุตของผู้ใช้ (เช่น การสะกดผิดหรือฟิลด์ที่ขาดหายไป) ซึ่งจะเพิ่มโอกาสที่จะได้ผลลัพธ์ที่ถูกต้อง
• ภูมิภาคเป้าหมายแสดงข้อมูลเมตาเพิ่มเติมจาก Address Validation API เมื่อเทียบกับ Geocoding API เช่น การแยกประเภทประเภทอาคารเป็นที่อยู่อาศัยเทียบกับเชิงพาณิชย์

คุณอาจเลือกใช้ Geocoding API แทน Address Validation API ในกรณีต่อไปนี้

• เป้าหมายหลักของคุณคือการดึงข้อมูลสถานที่ตั้งของที่อยู่ และความแม่นยำของที่อยู่แต่ละรายการอาจไม่สำคัญ
  • เช่น คุณอาจต้องการสร้างฮีตแมปจากชุดข้อมูลขนาดใหญ่
• คุณต้องใช้รายละเอียดปลายทางเฉพาะเจาะจง เช่น ทางเข้าอาคาร โครงร่างอาคาร หรือจุดนำทางสำหรับการรับและส่ง (พร้อมใช้งานกับเมธอด SearchDestinations ใน Geocoding API v4)
• คุณต้องการโซลูชันระดับโลกและ Address Validation API ไม่พร้อมให้บริการในภูมิภาคเป้าหมายทั้งหมด

ตัวอย่างต่อไปนี้แสดงความสามารถของ Address Validation API เมื่อเทียบกับ Geocoding API

ตัวอย่างที่อยู่ไม่ถูกต้อง

1 Fake St, Mountain View, CA 94043, USA

Address Validation API จะแยกอินพุตนี้ออกเป็นคอมโพเนนต์ที่อยู่ที่แยกกัน (ถนน เมือง รัฐ ฯลฯ) นอกจากนี้ยังให้ข้อมูลโดยละเอียดเกี่ยวกับสาเหตุที่ที่อยู่ไม่ถูกต้องลงไปจนถึงระดับ PREMISE ได้ด้วย

Fake St ไม่มีอยู่ใน Mountain View, CA และ Address Validation API จะแสดงข้อมูลดังกล่าวในรายละเอียดระดับคอมโพเนนต์ที่แสดงผล

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

พร็อพเพอร์ตี้ที่สำคัญที่ต้องตรวจสอบในกรณีนี้คือ confirmationLevel การแสดงผล UNCONFIRMED_BUT_PLAUSIBLE สำหรับ Fake St หมายความว่า API ได้พิจารณาแล้วว่าถนนอาจมีชื่อดังกล่าวได้ แต่ไม่สามารถจับคู่กับข้อมูลที่อยู่ที่รองรับได้

การใช้ผลลัพธ์ API เป็นข้อมูล คุณสามารถอนุมานได้ว่าคอมโพเนนต์ถนนของอินพุตนี้ (Fake St) เป็นสาเหตุ

เมื่อใช้ที่อยู่เดียวกันกับ Geocoding API ระบบจะจับคู่ "California" ได้ดังที่เห็นในภาพหน้าจอจากเครื่องมือเข้ารหัสพิกัดภูมิศาสตร์ ซึ่งคุณลองใช้ได้ที่นี่ ที่นี่:

อย่างไรก็ตาม ผลลัพธ์จะเป็นรหัสพิกัดภูมิศาสตร์ของทั้งรัฐ โดยมีข้อมูลน้อยมากเกี่ยวกับคอมโพเนนต์ใดในอินพุตที่อาจมีปัญหา

ตัวอย่างการสะกดผิด

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

ที่อยู่ด้านบนมีการสะกดผิด 2 แห่ง ได้แก่ ชื่อถนนและย่าน

ทั้ง Address Validation API และ Geocoding API สามารถแก้ไขข้อผิดพลาดเหล่านี้และแสดงผลลัพธ์เป็น 76 Buckingham Palace Road, London, SW1W 9TQ ได้ อย่างไรก็ตาม Address Validation API สามารถให้ข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการได้

ดูคอมโพเนนต์ที่อยู่ที่สะกดผิดในอินพุต

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Address Validation API จะแสดงแฟล็กเพื่อระบุว่ามีการแก้ไขฟิลด์แล้ว คุณสามารถใช้ตรรกะทางธุรกิจกับแฟล็กนี้เพื่อตรวจสอบการแก้ไขกับผู้ให้บริการข้อมูลอีกครั้ง เช่น ลูกค้าในการชำระเงินอีคอมเมิร์ซ

ตัวอย่างข้อมูลที่ขาดหายไปและการสะกดผิด

Bollschestraße 86, 12587, DE

ที่อยู่ด้านบนมีการสะกดผิดในชื่อถนนและไม่มีเมือง (ย่าน) เบอร์ลิน

Address Validation API สามารถแก้ไขข้อผิดพลาดทั้ง 2 รายการนี้และแสดงผลรหัสพิกัดภูมิศาสตร์ระดับ PREMISE รวมถึงที่อยู่ที่ได้รับการยืนยันแล้วถึงระดับ PREMISE

Bölschestraße 86, 12587 Berlin, DE

Geocoding API ไม่สามารถแก้ไขข้อผิดพลาดของอินพุตในกรณีนี้ได้สำเร็จและแสดงผลลัพธ์เป็น ZERO_RESULTS

ตัวอย่างข้อมูลเมตาของที่อยู่เพิ่มเติม

111 8th Avenue Ste 123, New York, NY 10011-5201, US

ที่อยู่นี้ถูกต้อง ยกเว้นหมายเลขยูนิต (Ste 123) ซึ่งไม่มีอยู่ในอาคาร

Address Validation API สามารถตรวจสอบที่อยู่ถึงระดับ PREMISE (111 8th Ave) และแสดงข้อมูลเมตาบางอย่างเกี่ยวกับพร็อพเพอร์ตี้ รวมถึงข้อมูลว่าเป็นอาคาร

เชิงพาณิชย์

"business": true

นอกจากนี้ ค่า dpvConfirmation ที่แสดงผลเป็นส่วนหนึ่งของ uspsData ในการตอบกลับคือ S

"dpvConfirmation": "S"

ค่า dpvConfirmation เป็น S แสดงว่าที่อยู่ได้รับการยืนยันถึงระดับ PREMISE แต่หมายเลขยูนิตที่ระบุในอินพุตไม่ได้เชื่อมโยงกับที่อยู่นั้น

Geocoding API ไม่สามารถให้ข้อมูลนี้ได้

ทำความเข้าใจการตอบกลับของ Geocoding API

ภาพรวม

หากคุณใช้ Geocoding API ผลลัพธ์รหัสพิกัดภูมิศาสตร์จะมีการบอกใบ้ต่างๆ ในการตอบกลับ ซึ่งสามารถใช้เพื่อทำความเข้าใจรายละเอียดของที่อยู่ที่ระบุได้

Geocoding API ทำงานโดยการแยกคอมโพเนนต์ที่อยู่ในลำดับชั้น

**ตัวอย่างเช่น 123 Example Street, Chicago, 60007, USA จะแยกตามลำดับต่อไปนี้

/ Example Street/ Chicago/ 60007/ USA จะได้รับการประเมินตามลำดับนั้น การจับคู่แรกในกรณีนี้คือ Chicago และโดยเฉพาะเจาะจงคือรหัสไปรษณีย์ 60007 ดังนั้น ระบบจึงแสดงผล Place_id ต่อไปนี้สำหรับรหัสไปรษณีย์นั้น

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Geocode API มีข้อมูลต่อไปนี้ในการตอบกลับ

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Geocoding API สามารถยืนยันประเภทสถานที่ตั้งของที่อยู่นี้ได้ ดูรายการที่อยู่ที่แสดงผลโดย Geocoding API ได้typesที่นี่

หากไม่มีการแยกคอมโพเนนต์ใดๆ ของอินพุต API จะแสดงผลดังนี้

{
   "results": [],
   "status": "ZERO_RESULTS"
}

การส่งคำขอด้วยที่อยู่ถนนเท่านั้นโดยไม่มีหมายเลขบ้านจะแสดงผลลัพธ์ในรูปแบบต่อไปนี้

"types": [
  "route"
]

ซึ่งหมายความว่า Geocoding API ไม่พบหรือจับคู่หมายเลขถนน

หมายเหตุ: หากต้องการทราบว่าที่อยู่มีอยู่หรือไม่ ให้ตรวจสอบว่ามีการตั้งค่าพารามิเตอร์ใดๆ (เช่น types, partial_match, results, status) ใน การตอบกลับของ Geocoding API หรือไม่ การดำเนินการนี้จะค่อยๆ เพิ่มระดับความเชื่อมั่นว่าที่อยู่อาจมีอยู่ แต่จะไม่ทำให้แม่นยำ 100% นี่คือเหตุผลที่เราต้องใช้ Address Validation API

คุณสามารถใช้เทคนิคด้านบนเพื่อเพิ่มความเชื่อมั่นในความแม่นยำของที่อยู่จากการตอบกลับของ Geocoding API เพียงอย่างเดียว อย่างไรก็ตาม Geocoding API จะไม่แสดงผลข้อมูลที่แน่นอนเพื่อระบุความแม่นยำของผลลัพธ์ ซึ่งแตกต่างจากผลลัพธ์ของ Address Validation API

ประเภทสถานที่ตั้ง

หากต้องการทำความเข้าใจส่วนนี้อย่างถูกต้อง คุณต้องทำความเข้าใจประเภทสถานที่ตั้งต่างๆ ที่อาจแสดงผลจากการตอบกลับของ Geocoding API response:

• ROOFTOP แสดงว่าผลลัพธ์ที่แสดงผลเป็นรหัสพิกัดภูมิศาสตร์ที่แม่นยำซึ่งเรามีข้อมูลสถานที่ตั้งที่แม่นยำถึงระดับที่อยู่ถนน
• RANGE_INTERPOLATED แสดงว่าผลลัพธ์ที่แสดงผลเป็นการประมาณ (โดยปกติจะอยู่บนถนน) ที่ประมาณขึ้นระหว่างจุดที่แม่นยำ 2 จุด (เช่น ทางแยก) โดยทั่วไปแล้ว ระบบจะแสดงผลลัพธ์ที่ประมาณขึ้นเมื่อไม่มีรหัสพิกัดภูมิศาสตร์ระดับ ROOFTOP สำหรับที่อยู่ถนน
• GEOMETRIC_CENTER แสดงว่าผลลัพธ์ที่แสดงผลคือจุดกึ่งกลางทางเรขาคณิตของผลลัพธ์ เช่น เส้นหลายเหลี่ยม (เช่น ถนน) หรือรูปหลายเหลี่ยม (ภูมิภาค)
• APPROXIMATE แสดงว่าผลลัพธ์ที่แสดงผลไม่ใช่ผลลัพธ์ใดๆ ข้างต้น

หาก Geocoding API แสดงผล location_type เป็น ROOFTOP หรือ RANGE_INTERPOLATED ก็ไม่ได้หมายความว่าที่อยู่นั้นมีอยู่ ในทำนองเดียวกัน หาก Geocoding API แสดงผลโดยตั้งค่าแฟล็ก partial_match เป็น true ก็อาจยังเป็นผลลัพธ์ที่ถูกต้องสำหรับคุณ

การจับคู่ที่ไม่ถูกต้องประเภทนี้เป็นปัญหาที่แก้ไขได้ยากมากด้วย Geocoding API อย่างน้อยที่สุด คุณอาจพิจารณาใช้การตรวจสอบการประมวลผลภายหลังขั้นพื้นฐานบางอย่างกับประเทศและย่านของคำขอ / การตอบกลับ หรือจะให้ดีกว่านั้น ให้ลองเปรียบเทียบที่อยู่ถนนจริงเพื่อดูการสะกดผิดและ/หรือที่อยู่ที่ไม่สมบูรณ์

หมายเหตุ: หากตัดสินใจใช้ Geocoding API เราขอแนะนำให้คุณตรวจสอบคุณภาพของข้อมูลระหว่างคำขอเริ่มต้นกับการตอบกลับของ Geocoding API เป็นประจำ

การจับคู่บางส่วนและการจับคู่ที่ไม่ถูกต้อง

หากที่อยู่เป็นการจับคู่บางส่วน หมายความว่า Geocoding API ไม่สามารถระบุที่อยู่ได้อย่างแม่นยำ การตอบกลับจะมีข้อมูลต่อไปนี้

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

สิ่งที่สำคัญยิ่งกว่าประเภทสถานที่ตั้งด้านบนคือการพิจารณาว่าเมื่อใดที่ partial_match = true is ในการตอบกลับ partial_match แสดงว่า Geocoding API ไม่ได้แสดงผลการจับคู่ที่แน่นอนสำหรับคำขอเดิม แม้ว่าจะจับคู่ที่อยู่ที่ขอได้บางส่วนก็ตาม

คุณอาจต้องการตรวจสอบคำขอเดิมเพื่อดูที่อยู่ที่ไม่สมบูรณ์ การจับคู่บางส่วนมักเกิดขึ้นกับที่อยู่ถนนที่ไม่มีอยู่ในย่านที่ระบุในคำขอ นอกจากนี้ ระบบยังอาจแสดงผลการจับคู่บางส่วนเมื่อคำขอตรงกับสถานที่ตั้ง 2 แห่งขึ้นไปในย่านเดียวกัน

ตัวอย่างเช่น "21 Henr St, Bristol, UK" จะแสดงผลการจับคู่บางส่วนสำหรับทั้ง Henry Street และ Henrietta Street โปรดทราบว่าหากคำขอมีคอมโพเนนต์ที่อยู่ที่สะกดผิด Geocoding API อาจแนะนำที่อยู่อื่น ระบบจะไม่ทำเครื่องหมายคำแนะนำที่ทริกเกอร์ด้วยวิธีนี้เป็นการจับคู่บางส่วน

ที่อยู่สังเคราะห์

Geocoding API อาจแสดงผลสถานที่ตั้งสำหรับที่อยู่ "สังเคราะห์" ที่ไม่มีอยู่ในฐานข้อมูลของ Google เป็นสถานที่ตั้งที่แม่นยำ

ในสถานการณ์ดังกล่าว ออบเจ็กต์การตอบกลับมักจะมี Place ID ยาวและพร็อพเพอร์ตี้ต่อไปนี้: geometry.location_type=APPROXIMATE

หากพบตัวบ่งชี้เหล่านี้ในการตอบกลับ โปรดพิจารณาทำเครื่องหมายที่อยู่ของอินพุตว่าไม่ถูกต้องและลองตรวจสอบอีกครั้งด้วยวิธีอื่น

หมายเหตุ: นี่เป็นอีกตัวอย่างหนึ่งที่ Address Validation API จะแสดงผลข้อมูลโดยตรงหากที่อยู่ไม่มีอยู่

ทำความเข้าใจการตอบกลับของ Address Validation API

เรามีเอกสารประกอบที่ยอดเยี่ยมเกี่ยวกับวิธีทำความเข้าใจการตอบกลับจาก Address Validation API อยู่แล้ว ดังนั้นเราจะไม่ลงรายละเอียดเพิ่มเติมในที่นี้

• ดูภาพรวมของออบเจ็กต์การตอบกลับได้ที่ นี่
• ดูเดโมที่แสดงคอมโพเนนต์ต่างๆ ของการตอบกลับได้ที่ นี่
• ในเอกสาร Address Validation for Checkout มีคำอธิบายโดยละเอียดเกี่ยวกับวิธีแยกความแตกต่างระหว่างที่อยู่ที่ดีกับที่อยู่ที่ไม่ดี

แนวทางปฏิบัติแนะนำ

การระบุภูมิศาสตร์

เมื่อเรียกใช้ Address Validation API หรือ Geocoding API แนวทางปฏิบัติแนะนำคือการพยายามจำกัดภูมิศาสตร์ที่จะค้นหาที่อยู่นั้น API ทั้ง 2 รายการใช้การดำเนินการนี้ใน 2 วิธีที่แตกต่างกัน ดังนี้

• Geocoding API - การกำหนดภูมิภาค

  หากทราบว่ารหัสพิกัดภูมิศาสตร์จะอยู่ในประเทศใดประเทศหนึ่ง การใช้การกำหนดภูมิภาคจะให้ผลลัพธ์ที่ดีกว่ามาก ตัวอย่างเช่น หากคุณกำลังเข้ารหัสพิกัดภูมิศาสตร์ในแคนาดา เราขอแนะนำให้เพิ่ม &region=ca ลงในคำขอเพื่อกำหนดภูมิภาคเป็นแคนาดา โปรดทราบว่าการกำหนดภูมิภาคจะ เลือก ผลลัพธ์ภายในภูมิภาคนั้นเท่านั้น คุณยังคงได้รับผลลัพธ์นอกภูมิภาคได้

• Address Validation API - รหัสภูมิภาค

  ในลักษณะเดียวกัน Address Validation API จะแสดงผลลัพธ์ที่แม่นยำมากขึ้นหากมีการส่งรหัส ISO2 ในคำขอโดยใช้ฟิลด์ regionCode

การจัดเก็บ Place ID

หากต้องการจัดเก็บข้อมูลจาก Google Maps Platform เกี่ยวกับสถานที่ตั้งสำหรับคำขอในอนาคต คุณสามารถจัดเก็บ Place ID ไว้ในฐานข้อมูลเป็นแอตทริบิวต์ของสถานที่ตั้งได้ไม่จำกัด คุณจะต้องส่งคำขอ Find Place เพียงครั้งเดียวต่อ Place ID นอกจากนี้ คุณยังค้นหา Place ID ทุกครั้งที่ผู้ใช้ขอรายละเอียดธุรกรรมได้ด้วย

หากต้องการให้แน่ใจว่าคุณมีข้อมูลที่อัปเดตล่าสุด ให้รีเฟรช Place ID ทุก 12 เดือนโดยใช้คำขอ Place Details พร้อมพารามิเตอร์ place_id

หมายเหตุ: โปรดตรวจสอบคู่มือแนวทางปฏิบัติแนะนำสำหรับการเข้ารหัสพิกัดภูมิศาสตร์ด้วย

บทสรุป

เอกสารนี้อธิบายความแตกต่างหลักระหว่าง Address Validation API และ Geocoding API โดยสรุป ให้พิจารณาใช้ Address Validation API ในกรณีต่อไปนี้

• ต้องใช้ที่อยู่ไปรษณีย์ที่ถูกต้อง โดยเฉพาะอย่างยิ่งเพื่อวัตถุประสงค์ในการจัดส่ง
• ทราบว่าข้อมูลอินพุตมีคุณภาพไม่ดี Address Validation API ยืดหยุ่นต่อข้อผิดพลาดของอินพุตมากกว่า จะไฮไลต์คอมโพเนนต์ที่อยู่ที่ตรวจสอบไม่ได้ และแก้ไขข้อมูลอินพุต
• ต้องใช้ข้อมูลเพิ่มเติมสำหรับที่อยู่ เช่น ที่อยู่อาศัยเทียบกับเชิงพาณิชย์ (พร้อมให้บริการในบางภูมิภาค)

ขั้นตอนถัดไป

ดาวน์โหลดเอกสารไวท์เปเปอร์ "ปรับปรุงการชำระเงิน การจัดส่ง และการดำเนินงานด้วยที่อยู่ที่เชื่อถือได้ " และดูเว็บบินาร์ "การปรับปรุงการชำระเงิน การจัดส่ง และการดำเนินงานด้วย Address Validation "

อ่านเพิ่มเติมที่แนะนำ

• Address Validation for Ecommerce Checkout
• เอกสารประกอบของ Places Autocomplete
• เอกสารประกอบของ Address Validation API
• การรายงานของ Google Maps Platform

ผู้ร่วมให้ข้อมูล

Google เป็นผู้ดูแลบทความนี้ ผู้ร่วมให้ข้อมูลต่อไปนี้เป็นผู้เขียนบทความนี้ในตอนแรก

ผู้เขียนหลัก

Henrik Valve | วิศวกรโซลูชัน

Thomas Anglaret | วิศวกรโซลูชัน

Sarthak Ganguly | วิศวกรโซลูชัน