id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
22115	[PATCH][RFC] Extract methods from LatLon into ILatLon where they are generally applicable	taylor.smock	team	"The attached patch does the following:
* Moves `greatCircleDistance` and `bearing` into `ILatLon` from `LatLon`
* Where possible, remove `getCoor()` calls and instead call the appropriate method directly
* Deprecates the original methods (rather unfortunately, this does mean we will have deprecation warnings when compiling for a bit, as most of the remaining calls deal with EastNorth conversions)
* Where possible (when noticed), if something calls `Node#getCoor` and then directly passes the result into something that accepts `ILatLon`, the `Node` is now passed instead.

This does not move `interpolate` and `getCenter`, as both return a `LatLon`.

For those reading the code, `Node` extends `INode` which extends `ILatLon`.

This should decrease overall memory allocations significantly. One major win is in `SearchCompiler#match`, where a `Bounds#contains(LatLon)` is replaced by `Bounds#contains(ILatLon)`, where the `ILatLon` is the `Node` (in a validation test of Mesa County, Colorado, the `getCoor` call accounted for 284 MiB of 2.216 GiB memory allocations for `SearchCompiler#Match`).


Note: I'm not sold on the `@deprecation` annotations. I'd like to be able to remove the methods from `LatLon` someday, but those methods are used a lot, so there will be a lot of breakage when we do remove them.

Profiling results (again, Mesa County Colorado `nwr in ""Mesa County, Colorado""`):
* `Node#getCoor` (using method back traces) went from 501 MiB to 97 MiB.
* `SearchCompiler.InArea#Match` went from 2.216 GiB to 2 GiB, which is about right."	defect	closed	normal	22.06	Core		fixed	performance