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

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

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

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

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

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

เมื่อใดที่ควรเลือก Address Validation API กับ Geocoding API

Address-Validation-vs-Geocoding

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

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

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

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

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

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

  • เป้าหมายหลักของคุณคือการดึงตำแหน่งของที่อยู่ และความถูกต้องของที่อยู่แต่ละรายการอาจไม่สำคัญ
    • เช่น เพื่อสร้างฮีตแมปจากชุดข้อมูลขนาดใหญ่
  • คุณต้องการโซลูชันระดับโลก แต่ 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 ระบบจะจับคู่ "แคลิฟอร์เนีย" ได้ตามที่เห็นในภาพหน้าจอจากเครื่องมือการเข้ารหัสพิกัดภูมิศาสตร์ ซึ่งคุณลองใช้ได้ที่นี่

alt_text

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

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

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 ผลลัพธ์ของ Geocode จะมีคำใบ้ต่างๆ ในการตอบกลับ ซึ่งสามารถใช้เพื่อทำความเข้าใจรายละเอียดของที่อยู่ที่ระบุ

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

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

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

ChIJwRKzf8ixD4gRHiXqucwr_HQ

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 และถนน Henrietta โปรดทราบว่าหากคำขอมีคอมโพเนนต์ที่อยู่ซึ่งสะกดผิด Geocoding API อาจแนะนำที่อยู่อื่น ระบบจะไม่ทําเครื่องหมายคําแนะนําที่ทริกเกอร์ด้วยวิธีนี้ว่าเป็นการจับคู่บางส่วน

ที่อยู่ที่สร้างขึ้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทสรุป

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

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

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

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

อ่านเพิ่มเติมที่

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

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

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

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

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

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