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

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

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

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

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

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

กรณีที่ควรเลือกการตรวจสอบที่อยู่เทียบกับ Geoที่อยู่ในรายการ 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 เมื่อเทียบกับ Geoที่อยู่ในรายการ 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 บักกิงแอมม์ พาเลสโรด ถนนลอนเดน สW1W 9TQ บริเตนใหญ่

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

ทั้งการตรวจสอบที่อยู่และการระบุพิกัดทางภูมิศาสตร์ 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 สามารถแก้ไขข้อผิดพลาดทั้งสองข้อนี้และแสดงผลรหัสพิกัดภูมิศาสตร์ระดับ PREMISE และที่อยู่ที่ได้รับการยืนยันที่ระดับ PREMISE แล้ว

Bölschestraße 86, 12587 Berlin, DE

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

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

111 8th Avenue Ste 123 นิวยอร์ก นิวยอร์ก 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 ผลจากรหัสพิกัดภูมิศาสตร์จะมีคำใบ้ต่างๆ ในคำตอบ ซึ่งสามารถใช้เพื่อทำความเข้าใจรายละเอียดของที่อยู่ที่ให้ไว้

GeoCocode 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"
           ]

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

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

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

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

"types": [
  "route"
]

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

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

คุณสามารถใช้เทคนิคข้างต้นเพื่อเพิ่มความมั่นใจในความถูกต้องของที่อยู่จากการตอบกลับของ Geo{8} 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 ก็อาจยังคงเป็นผลการค้นหาที่เหมาะสมสำหรับคุณ

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

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

การจับคู่บางส่วนและการจับคู่ที่เป็นเท็จ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • API การระบุพิกัดทางภูมิศาสตร์ - การให้น้ำหนักภูมิภาค

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

  • การตรวจสอบที่อยู่ API - รหัสภูมิภาค

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

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

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

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

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

บทสรุป

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

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

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

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

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

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

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

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

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

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

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