วัตถุประสงค์
คุณมักจะมีความจำเป็นที่จะต้องตรวจสอบความถูกต้องของตำแหน่งของสถานที่ มีบริการบางอย่างใน Google Maps Platform ที่ช่วยในกรณีการใช้งานนี้ได้ เอกสารนี้จะช่วยให้คุณเลือกบริการตรวจสอบตำแหน่งหลัก 2 บริการ ได้แก่ Address Validation API และ Geoที่อยู่ในรายการ API
Address Validation API คือข้อเสนอจาก Google Maps Platform ที่ช่วยลูกค้าตรวจสอบว่าที่อยู่ถูกต้องหรือไม่
การระบุพิกัดทางภูมิศาสตร์ด้วย Geoที่อยู่ในรายการ API คือกระบวนการแปลงที่อยู่ให้เป็นพิกัดทางภูมิศาสตร์ ซึ่งคุณสามารถใช้เพื่อวางเครื่องหมายบนแผนที่หรือตำแหน่งในแผนที่ได้
ดูภาพรวมระดับสูงของความแตกต่างระหว่างการตรวจสอบที่อยู่และ Geocoding API ได้ที่นี่
กรณีที่ควรเลือกการตรวจสอบที่อยู่เทียบกับ Geoที่อยู่ในรายการ API
หมายเหตุเกี่ยวกับโฟลว์ชาร์ตข้างต้น
- กรณีการใช้งานเพื่อการโต้ตอบของผู้ใช้หมายถึงเมื่อผู้ใช้อยู่เพื่อโต้ตอบกับผลการค้นหา
- 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 เครื่องมือจะสามารถจับคู่บน "แคลิฟอร์เนีย" ตามที่คุณเห็นในภาพหน้าจอจากเครื่องมือระบุพิกัดทางภูมิศาสตร์ซึ่งคุณลองใช้ได้ที่นี่
อย่างไรก็ตาม ผลที่ได้จะเป็นรหัสพิกัดภูมิศาสตร์ของทั้งรัฐ โดยมีความคิดเห็นเพียงเล็กน้อยว่าองค์ประกอบใดในอินพุตที่อาจมีข้อผิดพลาด
ตัวอย่างข้อผิดพลาดในการสะกด
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 การระบุพิกัดทางภูมิศาสตร์ - การให้น้ำหนักภูมิภาค
หากคุณทราบว่ารหัสพิกัดภูมิศาสตร์จะปรากฏภายในประเทศใดประเทศหนึ่ง คุณจะได้ผลลัพธ์ที่ดีขึ้นมากโดยใช้การให้น้ำหนักภูมิภาค ตัวอย่างเช่น หากคุณระบุพิกัดภูมิศาสตร์ในแคนาดา เราขอแนะนำให้เพิ่ม
®ion=ca
ในคำขอให้มีอคติต่อแคนาดา โปรดทราบว่าการให้น้ำหนักภูมิภาคต้องการผลลัพธ์ภายในภูมิภาคนั้นเท่านั้น คุณจะยังรับผลการค้นหานอกภูมิภาคได้การตรวจสอบที่อยู่ API - รหัสภูมิภาค
ในทำนองเดียวกัน Address Validation API จะให้ผลลัพธ์ที่แม่นยำมากขึ้นหากมีการส่งรหัส ISO2 ในคำขอ โดยใช้ช่อง
regionCode
การจัดเก็บรหัสสถานที่
หากต้องการจัดเก็บข้อมูลจาก Google Maps Platform เกี่ยวกับสถานที่ตั้งสำหรับคำขอในอนาคต คุณสามารถจัดเก็บรหัสสถานที่ไว้แบบไม่มีกำหนดในฐานข้อมูลเพื่อเป็นแอตทริบิวต์ของสถานที่ตั้ง คุณควรส่งคำขอค้นหาสถานที่เพียงครั้งเดียวต่อรหัสสถานที่เท่านั้น นอกจากนี้ยังค้นหารหัสสถานที่ได้ทุกครั้งที่ผู้ใช้ขอรายละเอียดธุรกรรม
เพื่อให้มั่นใจว่าคุณมีข้อมูลที่อัปเดตล่าสุดอยู่เสมอ ให้รีเฟรชรหัสสถานที่ทุกๆ 12 เดือนโดยใช้คำขอรายละเอียดสถานที่ที่มีพารามิเตอร์ place_id
หมายเหตุ: โปรดอ่านคู่มือแนวทางปฏิบัติแนะนำสําหรับการระบุพิกัดทางภูมิศาสตร์ด้วย
บทสรุป
เอกสารนี้อธิบายความแตกต่างหลักๆ ระหว่างการตรวจสอบที่อยู่และ API การระบุพิกัดทางภูมิศาสตร์ โดยสรุปแล้ว ให้พิจารณาใช้ Address Validation API ในกรณีต่อไปนี้
- ต้องระบุที่อยู่จัดส่งที่ถูกต้อง โดยเฉพาะสำหรับวัตถุประสงค์ในการนำส่ง
- เป็นที่ทราบกันว่าข้อมูลที่ป้อนมีคุณภาพต่ำ Address Validation API จะยกเว้นข้อผิดพลาดในการป้อนข้อมูลมากกว่า ซึ่งจะไฮไลต์องค์ประกอบของที่อยู่ที่ยืนยันไม่ได้ แล้วทำการแก้ไขข้อมูลอินพุต
- ต้องระบุข้อมูลเพิ่มเติมสำหรับที่อยู่ เช่น ที่พักอาศัยหรือสำนักงาน (มีให้บริการในบางภูมิภาค)
ขั้นตอนถัดไป
ดาวน์โหลดเอกสารประกอบปรับปรุงการชำระเงิน การนำส่ง และการดำเนินการด้วยที่อยู่ที่เชื่อถือได้ และดูการสัมมนาผ่านเว็บเกี่ยวกับการปรับปรุงการชำระเงิน การนำส่ง และการดำเนินการด้วยการตรวจสอบที่อยู่
แนะนำให้อ่านเพิ่มเติม:
- การตรวจสอบความถูกต้องของที่อยู่สำหรับการชำระเงินอีคอมเมิร์ซ
- เอกสารที่เติมข้อความอัตโนมัติใน Place
- เอกสารประกอบเกี่ยวกับ API การตรวจสอบที่อยู่
- การรายงาน Google Maps Platform
ผู้ร่วมให้ข้อมูล
Google เป็นผู้ดูแลบทความนี้ ผู้เขียนต่อไปนี้เป็นคนเขียน
ผู้เขียนหลัก:
Henrik Valve | วิศวกรโซลูชัน
Thomas Anglaret | วิศวกรโซลูชัน
Sarthak Ganguly | วิศวกรโซลูชัน