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