การตรวจสอบที่อยู่เทียบกับการเข้ารหัสพิกัดภูมิศาสตร์

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

คุณมักจะต้องตรวจสอบตำแหน่งของสถานที่ Google Maps Platform มีบริการต่างๆ ที่ช่วยคุณในกรณีการใช้งานนี้ได้ เอกสารนี้จะช่วยคุณเลือกระหว่างบริการตรวจสอบสถานที่ตั้งหลัก 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 เทียบกับ Geocoding API

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

• กรณีการใช้งานการโต้ตอบของผู้ใช้หมายถึงเมื่อผู้ใช้อยู่เพื่อโต้ตอบกับผลลัพธ์
• 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 ไม่มีอยู่ในเมาน์เทนวิว แคลิฟอร์เนีย และ 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 จะได้รับการประเมินตามลำดับนั้น การจับคู่แรกในกรณีนี้คือชิคาโก และเจาะจงยิ่งขึ้นคือรหัสไปรษณีย์ 60007 ดังนั้น ระบบจะแสดงผล Place_id ต่อไปนี้สำหรับรหัสไปรษณีย์ดังกล่าว

ChIJwRKzf8ixD4gRHiXqucwr_HQ

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

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

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

หากไม่มีการแก้ไขคอมโพเนนต์ใดๆ ของอินพุต 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 ดังนี้

• ROOFTOP บ่งชี้ว่าผลลัพธ์ที่แสดงผลเป็นรหัสพิกัดภูมิศาสตร์ที่แน่นอนซึ่งเรามีข้อมูลตำแหน่งที่แม่นยำถึงระดับที่อยู่
• RANGE_INTERPOLATED บ่งชี้ว่าผลลัพธ์ที่แสดงผลแสดงถึงค่าประมาณ (โดยปกติจะอยู่บนถนน) ที่ประมาณค่าในช่วงระหว่างจุดที่แน่นอน 2 จุด (เช่น ทางแยก) โดยทั่วไปแล้ว ระบบจะแสดงผลลัพธ์ที่ประมาณค่าในช่วงเมื่อไม่มีรหัสพิกัดภูมิศาสตร์ระดับหลังคาสำหรับที่อยู่
• 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 อยู่ในการตอบกลับ partial_match บ่งชี้ว่า Geocoding API ไม่ได้แสดงผลลัพธ์ที่ตรงทั้งหมดกับคำขอเดิม แม้ว่าจะจับคู่ที่อยู่ที่ขอได้บางส่วนก็ตาม

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

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

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

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

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

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

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

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

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

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

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

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

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

• Geocoding API - การให้น้ำหนักตามภูมิภาค

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

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

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

การจัดเก็บรหัสสถานที่

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

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

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

บทสรุป

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

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

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

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

ข้อมูลเพิ่มเติมที่แนะนำให้อ่าน

• Address Validation สำหรับการชำระเงินอีคอมเมิร์ซ
• เอกสารประกอบเกี่ยวกับ Place Autocomplete
• เอกสารประกอบของ Address Validation API
• การรายงานของ Google Maps Platform

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

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

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

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

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

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