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

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

คุณจำเป็นต้องตรวจสอบตำแหน่งของสถานที่บ่อยครั้ง 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

Address-Validation-vs-Geocoding

หมายเหตุเกี่ยวกับแผนภาพด้านบน

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

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 จะแสดง 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

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

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

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

แหล่งข้อมูลอื่นๆ ที่แนะนํา

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

Google เป็นผู้ดูแลบทความนี้ ผู้เขียนเนื้อหาต้นฉบับมีดังนี้

ผู้แต่งหลัก

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

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

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