mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 13:36:48 +00:00
Maurice
0246e5c317
haversineKm in src/utils/geo.ts answered NaN for some near antipodal pairs, for example 47.3812, -10.8827 and -47.3812001, 169.1173. Rounding pushed the haversine term a hair past 1, and asin of a value above 1 is NaN, which then spread into route sums and range checks. Cause: unlike the Studio legKm and the roadtrip haversineKm in @trek/shared, the shared client helper had no clamp before Math.asin. Fix: clamp with Math.min(1, ...) before Math.asin. With the clamp the helper runs exactly the operations of Studio legKm in the same order (2 * 6371 is 12742), so Studio now uses haversineKm and legKm goes, with its cases carried into the new geo tests. The roadtrip variant multiplies its terms in another order and gives different last bits, so it stays as it is. Red test: src/utils/geo.test.ts FE-UTIL-GEO-002 failed on the unfixed code with "AssertionError: expected NaN to be close to 20015.086796020572, received difference is NaN, but expected 0.0005". Removed tests: src/components/Studio/legKm.test.ts went with legKm. Its four cases (zero for one point, a degree of latitude about 111.19 km, the same both ways between 8700 and 8900 km, 0,0 to 0,180 equal to 12742 * PI / 2) now run against haversineKm as FE-UTIL-GEO-001, 003 and 004.
36 lines
1.7 KiB
TypeScript
36 lines
1.7 KiB
TypeScript
/**
|
|
* Straight-line distance between two coordinates, in kilometres.
|
|
*
|
|
* Lifted out of useTransportRoutes so the day-route builder can share the one
|
|
* implementation instead of adding a fourth copy. The map overlays keep their own
|
|
* `[lat, lng]`-tuple variants — different call shape, and they only sum arc lengths.
|
|
* The clamp keeps `asin` defined when rounding pushes two near antipodal points a hair
|
|
* past 1, which would otherwise answer NaN.
|
|
*/
|
|
export function haversineKm(a: { lat: number; lng: number }, b: { lat: number; lng: number }): number {
|
|
const R = 6371
|
|
const dLat = (b.lat - a.lat) * Math.PI / 180
|
|
const dLng = (b.lng - a.lng) * Math.PI / 180
|
|
const la1 = a.lat * Math.PI / 180
|
|
const la2 = b.lat * Math.PI / 180
|
|
const h = Math.sin(dLat / 2) ** 2 + Math.cos(la1) * Math.cos(la2) * Math.sin(dLng / 2) ** 2
|
|
return 2 * R * Math.asin(Math.min(1, Math.sqrt(h)))
|
|
}
|
|
|
|
/**
|
|
* How far a day out of a hotel and back plausibly reaches, straight-line.
|
|
*
|
|
* Consulted where a stay records no check-in/check-out time and the shape of the day is
|
|
* therefore a guess (#2157): a stop inside this radius is somewhere the hotel sent you out
|
|
* to for the day, a stop outside it is where you travelled from or to. It has to be a
|
|
* road-day radius rather than the booking-geometry MAX_DRIVE_KM in @trek/shared: 2000 km
|
|
* spans the whole of Europe, so every car journey on the continent passed as a day trip
|
|
* and kept the phantom hotel leg the issue reported.
|
|
*/
|
|
export const MAX_DAY_TRIP_KM = 150
|
|
|
|
/** Whether a stop is near enough a hotel to be a day out from it and back. */
|
|
export function withinDayTripRange(a: { lat: number; lng: number }, b: { lat: number; lng: number }): boolean {
|
|
return haversineKm(a, b) <= MAX_DAY_TRIP_KM
|
|
}
|