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

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

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

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

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

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

เมื่อใดควรเลือกการตรวจสอบที่อยู่เทียบกับ Geocoding API

Address-Validation-vs-Geocoding

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

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

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

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

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

คุณอาจเลือกใช้การระบุพิกัดทางภูมิศาสตร์ผ่าน 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 และ 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, เยอรมนี

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

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, สหรัฐอเมริกา

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

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

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

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

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

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

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

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

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

บทสรุป

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

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

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

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

แนะนำให้อ่านเพิ่มเติม

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

ซึ่ง Google เป็นผู้ดูแลจัดการบทความนี้ ผู้เขียนต่อไปนี้เขียนขึ้นเป็นคนแรก

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

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

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

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