dsh-geodesy

LLMs are impressive at reasoning and code, but they are remarkably bad at spherical geometry: swapping latitude and longitude, conflating degrees with radians, forgetting the Earth radius, treating a spherical polygon as a flat triangle. These mistakes slip silently into final answers. dsh-geodesy takes a straightforward approach — move the math out of the model's head and into a set of deterministic, pure-computation tools so the LLM only handles intent and invocation.

The plugin ships seven tools covering the most common geodesic tasks: great-circle distance (haversine, with km/m/mi/nmi output plus initial and final bearings and a 16-wind compass point), bearings and great-circle midpoint, the direct geodesic problem (start + bearing + distance → destination, with a round-trip check), coordinate-string parsing (decimal, DMS, suffixed pairs, axis hints — invalid input returns a reason, never a silent guess), rhumb-line (loxodrome) distance and bearing with a great-circle comparison, the intersection of two great-circle paths (nearest crossing, antipodal crossing, and distances from both starts), and spherical polygon area and perimeter via Girard's spherical-excess theorem. All calculations use the IUGG mean Earth radius of 6371.0088 km, configurable to lunar or planetary radii via the radiusKm option.

There are zero runtime dependencies. The math is fully local, deterministic, and reproducible. Semantic edge cases are handled: polygon area always reports both the interior and its complement regardless of winding order; a great-circle intersection that lands on the reverse side of a path is annotated; a zero-length rhumb line returns bearing 0 instead of an error.

Ideal for developers, GIS analysts, and navigation or aviation professionals who need Earth-surface math in a conversational context, and for anyone who wants a model to compute correctly rather than merely sound convincing. In short: stop letting the model do spherical trigonometry by hand — let it call a tool.