Sự khác biệt giữa Vincenty và tính toán khoảng cách vòng tròn lớn?

Gói địa lý của Python có hai kỹ thuật đo khoảng cách: Công thức Great Circle và Vincenty .

>>> from geopy.distance import great_circle
>>> from geopy.distance import vincenty
>>> p1 = (31.8300167,35.0662833) # (lat, lon) - https://goo.gl/maps/TQwDd
>>> p2 = (31.8300000,35.0708167) # (lat, lon) - https://goo.gl/maps/lHrrg
>>> vincenty(p1, p2).meters
429.16765838976664
>>> great_circle(p3, p4).meters
428.4088367903001

Sự khác biệt là gì? Đo khoảng cách nào được ưa thích?

Theo Wikipedia, công thức của Vincenty chậm hơn nhưng chính xác hơn :

Công thức của Vincenty là hai phương pháp lặp có liên quan được sử dụng trong trắc địa để tính khoảng cách giữa hai điểm trên bề mặt của một hình cầu, được phát triển bởi Thaddeus Vincenty (1975a) Chúng dựa trên giả định rằng hình Trái đất là một hình cầu bắt buộc, và do đó chính xác hơn các phương pháp như khoảng cách vòng tròn lớn giả định Trái đất hình cầu.

Sự khác biệt chính xác là ~0.17%trong một khoảng cách 428 mét ở Israel. Tôi đã thực hiện một bài kiểm tra tốc độ nhanh và bẩn:

<class 'geopy.distance.vincenty'>       : Total 0:00:04.125913, (0:00:00.000041 per calculation)
<class 'geopy.distance.great_circle'>   : Total 0:00:02.467479, (0:00:00.000024 per calculation)

Mã số:

import datetime
from geopy.distance import great_circle
from geopy.distance import vincenty
p1 = (31.8300167,35.0662833)
p2 = (31.83,35.0708167)

NUM_TESTS = 100000
for strategy in vincenty, great_circle:
    before = datetime.datetime.now()
    for i in range(NUM_TESTS):
        d=strategy(p1, p2).meters
    after = datetime.datetime.now()
    duration = after-before
    print "%-40s: Total %s, (%s per calculation)" % (strategy, duration, duration/NUM_TESTS)

Để kết luận: Công thức của Vincenty nhân đôi thời gian tính toán so với vòng tròn lớn và độ chính xác của nó tại điểm được kiểm tra là ~ 0,17%.

Vì thời gian tính toán không đáng kể, công thức của Vincenty được ưu tiên cho mọi nhu cầu thực tế.

Cập nhật : Theo các nhận xét sâu sắc bằng câu trả lời của whuber và cffk và cffk , tôi đồng ý rằng độ chính xác phải được so sánh với lỗi, không phải là phép đo. Do đó, công thức của Vincenty là một vài đơn đặt hàng có độ chính xác cao hơn, không ~ 0,17%.

Nếu bạn đang sử dụng geopy, thì khoảng cách great_circle và vincenty đều thuận tiện như nhau để có được. Trong trường hợp này, bạn hầu như luôn luôn sử dụng kết quả mang lại cho bạn kết quả chính xác hơn, tức là vincenty. Hai cân nhắc (như bạn chỉ ra) là tốc độ và độ chính xác.

Vincenty chậm hơn hai lần. Nhưng có lẽ trong một ứng dụng thực tế, thời gian chạy tăng lên là không đáng kể. Ngay cả khi ứng dụng của bạn yêu cầu một triệu phép tính khoảng cách, chúng tôi chỉ nói về sự khác biệt về thời gian của một vài giây.

Đối với các điểm bạn sử dụng, sai số trong vincenty là 6 m và sai số trong khoảng cách vòng tròn lớn là 0,75 m. Sau đó tôi sẽ nói rằng vincenty chính xác hơn 120000 lần (chứ không phải chính xác hơn 0,17%). Đối với các điểm chung, sai số trong khoảng cách vòng tròn lớn có thể lên tới 0,5%. Vì vậy, bạn có thể sống với một lỗi 0,5% trong khoảng cách? Đối với sử dụng thông thường (khoảng cách từ Cape Town đến Cairo?), Có lẽ bạn có thể. Tuy nhiên, nhiều ứng dụng GIS có yêu cầu độ chính xác chặt chẽ hơn nhiều. (0,5% là 5m trên 1km. Điều đó thực sự tạo ra sự khác biệt.)

Gần như tất cả các công việc lập bản đồ nghiêm túc đều được thực hiện trên ellipsoid tham chiếu và do đó có ý nghĩa rằng khoảng cách cũng nên được đo trên ellipsoid. Có lẽ bạn có thể thoát khỏi khoảng cách vòng tròn lớn ngày hôm nay. Nhưng đối với mỗi ứng dụng mới, bạn sẽ phải kiểm tra xem điều này có còn được chấp nhận hay không. Tốt hơn là chỉ sử dụng khoảng cách ellipsoidal từ đầu. Bạn sẽ ngủ ngon hơn vào ban đêm.

ĐỊA CHỈ (tháng 5 năm 2017)

Trả lời câu trả lời được đưa ra bởi @ craig-hicks. Phương pháp vincenty () trong địa lý thực sự có một lỗ hổng có thể gây tử vong: nó gây ra lỗi cho các điểm gần như cực âm. Các tài liệu trong mã đề nghị tăng số lần lặp. Nhưng đây không phải là một giải pháp chung vì phương pháp lặp được sử dụng bởi vincenty () không ổn định cho các điểm như vậy (mỗi lần lặp sẽ đưa bạn đi xa hơn từ giải pháp chính xác).

Tại sao tôi mô tả vấn đề là "có khả năng gây tử vong"? Bởi vì bất kỳ việc sử dụng chức năng khoảng cách trong thư viện phần mềm khác đều cần có khả năng xử lý ngoại lệ. Xử lý nó bằng cách trả về NaN hoặc khoảng cách vòng tròn lớn có thể không thỏa đáng, bởi vì hàm khoảng cách kết quả sẽ không tuân theo bất đẳng thức tam giác loại trừ việc sử dụng nó, ví dụ, trong các cây điểm thuận lợi.

Tình hình không hoàn toàn ảm đạm. Gói python của tôi geographiclib tính toán khoảng cách đo đạc chính xác mà không có bất kỳ thất bại. Các geopy kéo yêu cầu # 144 thay đổi chức năng khoảng cách của geopy để gói sử dụng geographiclib nếu nó có sẵn. Thật không may, yêu cầu kéo này đã ở trong tình trạng lấp lửng kể từ tháng 8 năm 2016.

ĐỊA CHỈ (tháng 5 năm 2018)

geopy 1.13.0 hiện sử dụng gói geographiclib cho khoảng cách tính toán. Đây là một cuộc gọi mẫu (dựa trên ví dụ trong câu hỏi ban đầu):

>>> from geopy.distance import great_circle
>>> from geopy.distance import geodesic
>>> p1 = (31.8300167,35.0662833) # (lat, lon) - https://goo.gl/maps/TQwDd
>>> p2 = (31.8300000,35.0708167) # (lat, lon) - https://goo.gl/maps/lHrrg
>>> geodesic(p1, p2).meters
429.1676644986777
>>> great_circle(p1, p2).meters
428.28877358686776

Tôi xin lỗi vì đã đăng câu trả lời thứ hai tại đây, nhưng tôi tận dụng cơ hội để đáp ứng yêu cầu của @ craig-hicks để cung cấp sự so sánh chính xác và thời gian cho các thuật toán khác nhau để tính toán khoảng cách đo đạc. Điều này diễn giải một nhận xét tôi đưa ra cho yêu cầu kéo số 144 của tôi cho phép địa lý cho phép sử dụng một trong hai cách triển khai thuật toán của tôi cho phép trắc địa được sử dụng trong địa lý, một là triển khai python bản địa, trắc địa (geographiclib) và các cách sử dụng khác một triển khai trong C, trắc địa (pyproj) .

Đây là một số dữ liệu thời gian. Thời gian tính bằng microsecs trên mỗi cuộc gọi

method                          dist    dest
geopy great_circle              20.4    17.1
geopy vincenty                  40.3    30.4
geopy geodesic(pyproj)          37.1    31.1
geopy geodesic(geographiclib)  302.9   124.1

Dưới đây là độ chính xác của các phép tính trắc địa dựa trên Bộ kiểm tra trắc địa của tôi . Các lỗi được tính theo đơn vị micron (1e-6 m)

method                        distance destination
geopy vincenty                 205.629  141.945
geopy geodesic(pyproj)           0.007    0.013
geopy geodesic(geographiclib)    0.011    0.010

Tôi đã bao gồm yêu cầu kéo của hannosche # 194 để sửa lỗi xấu trong chức năng đích. Nếu không sửa lỗi này, lỗi trong tính toán đích cho vincenty là 8,98 mét.

19,2% trường hợp thử nghiệm thất bại với vincenty.distance (iterations = 20). Tuy nhiên, bộ kiểm tra bị lệch về các trường hợp sẽ xảy ra lỗi này.

Với các điểm ngẫu nhiên trên ellipsoid WGS84, thuật toán Vincenty được đảm bảo không thành công 16,6 trên 1000000 lần (giải pháp chính xác là một điểm cố định không ổn định của phương pháp Vincenty).

Với việc thực hiện địa lý của Vincenty và lặp = 20, tỷ lệ thất bại là 82,8 trên 1000000. Với lần lặp = 200, tỷ lệ thất bại là 21,2 trên 1000000.

Mặc dù những tỷ lệ này là nhỏ, thất bại có thể khá phổ biến. Ví dụ: trong bộ dữ liệu 1000 điểm ngẫu nhiên (có lẽ là các sân bay thế giới), tính toán ma trận khoảng cách đầy đủ sẽ thất bại trung bình 16 lần (với số lần lặp = 20).

Dường như gói geopy.distance cung cấp hàm "distance ()" mặc định là vincenty (). Tôi sẽ khuyên bạn nên sử dụng khoảng cách () theo nguyên tắc, vì đó là khuyến nghị gói, trong trường hợp được chuyển hướng từ vincenty () trong tương lai (không chắc là như vậy). Tiếp tục đọc:

Ghi chú tài liệu này được bao gồm trong mã nguồn cho hàm vincenty () bạn đã chỉ định:

Lưu ý: Việc triển khai khoảng cách Vincenty này không hội tụ được một số điểm hợp lệ. Trong một số trường hợp, có thể thu được kết quả bằng cách tăng số lần lặp ( iterationsđối số từ khóa, được đưa ra trong lớp __init__, với mặc định là 20). Có thể nên sử dụng: class : .great_circle, ít chính xác hơn một chút, nhưng luôn tạo ra kết quả.

Mã nguồn với nhận xét / ghi chú ở trên có thể được tìm thấy tại https://github.com/geopy/geopy/blob/master/geopy/distance.py Cuộn xuống định nghĩa cho vincenty ()

Tuy nhiên, hàm khoảng cách mặc định được gói đó sử dụng khi caliing distance () là hàm vincenty (), hàm ý rằng việc không hội tụ không phải là thảm họa và trả lời hợp lý - quan trọng nhất là không có ngoại lệ.

Cập nhật: Như đã lưu ý bởi "cffk", hàm vincenty () thực sự ném một ngoại lệ ValueError khi thuật toán không hội tụ - mặc dù nó không được ghi lại trong mô tả hàm. Do đó, các tài liệu là lỗi.

Cho dù sử dụng vincenty hay haversine hay luật hình cầu của vũ trụ, sẽ có sự khôn ngoan trong việc nhận thức được bất kỳ vấn đề tiềm ẩn nào với mã mà bạn dự định sử dụng, những điều cần chú ý và giảm thiểu, và cách người ta đối phó với các vấn đề vincenty vs haversine và sloc sẽ khác nhau khi người ta nhận thức được các vấn đề / edgecase của mỗi người, có thể hoặc không được biết đến phổ biến. Các lập trình viên dày dạn biết điều này. Người mới có thể không. Tôi hy vọng sẽ giải phóng một số trong số họ thất vọng khi một đoạn trích từ một diễn đàn làm điều gì đó bất ngờ, trong một số trường hợp nhất định. Nếu một người nghiêm túc sẽ sử dụng một số phiên bản của bất kỳ trong số này, vincenty, haversine, sloc, thì SE, SO, Reddit, Quora, v.v., có thể đã cung cấp trợ giúp hạn chế trong một số mã hóa ban đầu của một giải pháp, nhưng điều đó không có nghĩa là giải pháp của họ hoặc được chấp nhận 'câu trả lời' là không có vấn đề. Nếu một dự án đủ quan trọng, nó xứng đáng với một lượng nghiên cứu hợp lý thích hợp. Đọc hướng dẫn, đọc tài liệu và nếu đánh giá mã của mã đó tồn tại, hãy đọc nó. Sao chép và dán đoạn trích hoặc ý chính được nâng cấp hàng trăm lần trở lên không có nghĩa là sự an toàn của nó là toàn diện và được đảm bảo.

Câu trả lời hấp dẫn được đăng bởi cffk nêu lên quan điểm nhận thức về việc ẩn giấu các edgecase, trong các giải pháp đóng gói, có thể tạo ra ngoại lệ hoặc những khó khăn khác . Các yêu cầu cụ thể được đưa ra trong bài đăng đó vượt quá ngân sách thời gian của tôi để theo đuổi hiện tại, nhưng tôi nhận thấy rằng có những vấn đề thực sự ẩn giấu trong các gói nhất định, bao gồm ít nhất một triển khai vincenty, trong đó ít nhất một người đã đề xuất cải thiện Bằng cách này hay cách khác, để giảm thiểu hoặc loại bỏ nguy cơ gặp phải những khó khăn đó. Tôi sẽ không thêm vào chủ đề đó liên quan đến vincenty (vì quá thờ ơ với nó), nhưng sẽ chuyển sang haversine, ít nhất là một phần về chủ đề với OP.

Công thức haversine được xuất bản phổ biến, dù bằng ngôn ngữ python hay ngôn ngữ khác, bởi vì nó rất có thể sẽ sử dụng thông số dấu phẩy động IEEE 754 trên hầu hết tất cả các hệ thống giống như intel và intel hiện nay, và bộ xử lý ARM, powerPC, v.v. cũng dễ bị các lỗi ngoại lệ hiếm gặp nhưng có thể lặp lại rất gần hoặc ở khoảng cách vòng cung 180 độ, các điểm đối cực, do các xấp xỉ điểm nổi và làm tròn. Một số người mới có thể chưa bị cắn bởi tình huống này. Bởi vì thông số fp này gần đúng và làm tròn, điều này không có nghĩa là bất kỳ mã nào gọi trên fp64 đều có thể gây ra lỗi ngoại lệ, không. Nhưng một số mã, một số công thức có thể không quá rõ ràng trong đó các phép tính gần đúng và làm tròn của IEEE 754 fp64 có thể khiến giá trị đi lạc ra khỏi miền của một phương pháp toán học được dự đoán sẽ đánh giá hoàn hảo giá trị đó. Một ví dụ ... sqrt (). Nếu một giá trị âm tìm đường vào sqrt (), chẳng hạn như sqrt (-0.00000000000000000122739), sẽ có một lỗi ngoại lệ. Trong công thức haversine, cách thức mà nó tiến tới một giải pháp, có hai phương thức sqrt () trong atan2 (). Cáca được tính toán và sau đó được sử dụng trong sqrt (), có thể, tại các điểm đối cực trên địa cầu, hơi đi lạc dưới 0,0 hoặc trên 1,0, rất ít vì xấp xỉ fp64 và làm tròn, nhưng hiếm khi lặp lại. Độ lặp lại đáng tin cậy nhất quán, trong bối cảnh này, làm cho điều này trở thành một rủi ro ngoại lệ, một edgecase để bảo vệ, để giảm thiểu, thay vì một con sán ngẫu nhiên bị cô lập. Đây là một ví dụ về một đoạn ngắn python3 của haversine, mà không có sự bảo vệ cần thiết:

import math as m

a = m.sin(dlat / 2)**2 + m.cos(lat1) * m.cos(lat2) * m.sin(dlon / 2)**2
c = 2 * m.atan2(m.sqrt(a), m.sqrt(1 - a))
distance = Radius * c

Rất gần hoặc tại các điểm đối cực, một tính toán trong dòng đầu tiên của công thức có thể đi lạc âm, hiếm khi, nhưng lặp lại với các tọa độ lat lon tương tự. Để bảo vệ / sửa những lần xuất hiện hiếm hoi, người ta có thể dễ dàng thêm, sau khi một tính toán, như bên dưới:

import math as m

note = ''

a = m.sin(dlat / 2)**2 + m.cos(lat1) * m.cos(lat2) * m.sin(dlon / 2)**2
if a < 0.0: a = 0.0 ; note = '*'
if a > 1.0: a = 1.0 ; note = '**'
c = 2 * m.atan2(m.sqrt(a), m.sqrt(1 - a))
distance = Radius * c

# note = '*'  # a went below 0.0 and was normalized back to 0.0
# note = '**' # a went above 1.0 and was normalized back to max of 1.0

Tất nhiên tôi đã không hiển thị toàn bộ chức năng ở đây, nhưng một đoạn ngắn như thường được đăng. Nhưng điều này cho thấy sự bảo vệ cho sqrt (), bằng cách kiểm tra a và bình thường hóa nó nếu cần thiết, cũng tiết kiệm nhu cầu đưa toàn bộ vào thử ngoại trừ. Ghi chú = '' lên trên cùng là để ngăn giai đoạn mã byte phản đối ghi chú đó đang được sử dụng trước khi được gán một giá trị, nếu nó được trả về với kết quả của hàm.

Với sự thay đổi đơn giản này, thêm hai một bài kiểm tra, các sqrt () chức năng sẽ được hạnh phúc, và mã ngay bây giờ có thêm lưu ý rằng có thể được trả lại cho gọi mã, để cảnh báo rằng kết quả đã bị bình thường một chút, và tại sao. Một số có thể quan tâm, một số có thể không, nhưng ở đó, ngăn ngừa một lỗi ngoại lệ, điều đó 'có thể' xảy ra. Một thử ngoại trừ khối có thể bắt ngoại lệ, nhưng không sửa nó, trừ khi được viết rõ ràng để làm như vậy. Có vẻ như dễ dàng hơn để mã dòng chỉnh (s) ngay lập tức sau khi một dòng tính toán. Đầu vào được kiểm tra kỹ lưỡng nên sau đó không yêu cầu thử ngoại trừ khối ở đây.

Nói tóm lại, nếu sử dụng haversine, mã hóa một cách rõ ràng hơn là sử dụng một gói phần mềm hoặc thư viện, không có vấn đề ngôn ngữ của bạn lựa chọn, nó sẽ là một ý tưởng tốt để thử nghiệm và để bình thường hóa một trở lại vào trong phạm vi cần thiết của 0.0 <= a <= 1.0 theo thứ tự để bảo vệ dòng tiếp theo với c tính toán . Nhưng phần lớn các đoạn mã haversine không hiển thị nó và không đề cập đến rủi ro.

Kinh nghiệm: trong quá trình kiểm tra kỹ lưỡng trên toàn cầu, với mức tăng 0,001 độ, tôi đã lấp đầy một ổ cứng với các kết hợp lat lon gây ra một ngoại lệ, một ngoại lệ có thể lặp lại đáng tin cậy, trong suốt một tháng cũng kiểm tra độ tin cậy của việc làm mát CPU fan hâm mộ, và sự kiên nhẫn của tôi Có, tôi đã xóa hầu hết các bản ghi đó, vì mục đích của chúng chủ yếu là để chứng minh luận điểm (nếu cách chơi chữ được cho phép). Nhưng tôi có một số nhật ký ngắn hơn về 'giá trị lat lat', được giữ cho mục đích thử nghiệm.

Độ chính xác: Liệu một và toàn bộ kết quả haversine sẽ mất một số độ chính xác bằng cách bình thường hóa nó một chút trở lại miền? Không nhiều, có lẽ không nhiều hơn các phép tính gần đúng và làm tròn fp64 đã được giới thiệu, điều đó gây ra sự trôi dạt ra khỏi miền. Nếu bạn đã tìm thấy haversine chấp nhận được trên vincenty rồi - đơn giản hơn, nhanh hơn, dễ tùy chỉnh, khắc phục sự cố và bảo trì hơn, thì haversine có thể là một giải pháp tốt cho dự án của bạn.

Tôi đã sử dụng haversine trên một bầu trời được chiếu trên cao để đo khoảng cách góc giữa các vật thể trên bầu trời, khi nhìn từ một vị trí trên trái đất, ánh xạ góc phương vị và alt đến các tọa độ tương tự như skysphere lat lon, không xem xét elipsoid skysphere lý thuyết dự kiến ​​là một hình cầu hoàn hảo, khi nói đến việc đo khoảng cách góc nhìn góc giữa hai vật thể từ một vị trí trên bề mặt trái đất. Nó phù hợp với nhu cầu của tôi một cách hoàn hảo. Vì vậy, haversine vẫn rất hữu ích và rất chính xác, trong một số ứng dụng (cũng nằm trong mục đích của tôi) ... nhưng nếu bạn sử dụng nó, cho dù trên trái đất cho GIS hay điều hướng, hoặc trong các quan sát và đo lường đối tượng trên bầu trời, hãy bảo vệ nó trong trường hợp các điểm đối cực hoặc rất gần các điểm đối cực, bằng cách thử nghiệm mộtvà đưa nó trở lại miền cần thiết của nó khi cần thiết.

Các haversine không được bảo vệ là tất cả trên internet và tôi chỉ thấy một bài đăng cũ sử dụng cho thấy sự bảo vệ, tôi nghĩ từ một người nào đó ở JPL, và đó có thể là trước năm 1985, thông số kỹ thuật điểm nổi trước 754 của IEEE. Hai trang khác đã đề cập đến các vấn đề có thể xảy ra gần các điểm đối cực, nhưng không mô tả các vấn đề đó, hoặc làm thế nào một người có thể giảm thiểu chúng. Vì vậy, có mối quan tâm đối với những người mới (như tôi), những người có thể không phải lúc nào cũng hiểu thực hành tốt đủ để nghiên cứu thêm và thử nghiệm các edgecase, về một số mã họ đã sao chép và dán vào một dự án đáng tin cậy. Bài đăng hấp dẫn của cffk đã được làm mới ở chỗ nó công khai với các loại vấn đề này, thường không được đề cập, hiếm khi được mã hóa công khai để bảo vệ trong đoạn trích, và hiếm khi được thảo luận theo cách này, so với số lượng phiên bản không được bảo vệ và không được phát hiện.

Kể từ năm 20190923, trang wiki về công thức haversine thực sự đã đề cập đến vấn đề có thể xảy ra tại các điểm đối cực, do các vấn đề về dấu phẩy động trong các thiết bị máy tính ... đáng khích lệ ...

https://en.wikipedia.org/wiki/Haversine_formula

(vì lúc này trang wiki không có neo html cho phần mà tôi sẽ liên kết trực tiếp, do đó, sau khi tải trang, hãy tìm kiếm trên trang trình duyệt đó để tìm 'Khi sử dụng các công thức này' và bạn sẽ xem vấn đề của haversine với các điểm đối cực được đề cập, chính thức hơn.)

Và trang web khác này cũng có một đề cập rất ngắn gọn về nó:

https://www.movable-type.co.uk/scripts/latlong.html

Nếu một người tìm thấy trên trang đó để 'bao gồm bảo vệ chống lại lỗi làm tròn', thì đây là ...

Nếu atan2 không có sẵn, c có thể được tính từ 2 ⋅ asin (min (1, √a)) (bao gồm cả bảo vệ chống lại lỗi làm tròn).

Bây giờ có một trường hợp hiếm hoi trong đó các lỗi làm tròn được đề cập và bảo vệ được hiển thị cho phiên bản asin (), nhưng chưa được đề cập hoặc hiển thị cho phiên bản atan2 (). Nhưng ít nhất là nguy cơ sai số làm tròn được đề cập.

imho, bất kỳ ứng dụng 24/7/365 nào sử dụng haversine, đều cần sự bảo vệ này gần các điểm đối cực như một chi tiết quan trọng và đơn giản.

Tôi không biết gói haversine nào hoặc không bao gồm bảo vệ này, nhưng nếu bạn chưa quen với tất cả những điều này và bạn sẽ sử dụng phiên bản 'đoạn trích' được xuất bản phổ biến, bây giờ bạn biết rằng nó cần được bảo vệ và bảo vệ đó rất đơn giản để thực hiện, nghĩa là, nếu bạn không sử dụng vincenty và không sử dụng một haversine đóng gói mà không dễ dàng truy cập để sửa đổi mã của gói.

IOW, cho dù sử dụng vincenty hay haversine hay sloc, người ta phải nhận thức được bất kỳ vấn đề nào với mã, những điều cần chú ý và giảm thiểu, và cách mọi người đối phó với các vấn đề vincenty vs haversine vs sloc sẽ khác nhau khi mỗi người nhận ra vấn đề ẩn giấu / edgecase, có thể hoặc không được biết đến phổ biến.