NavList:

Yes. If you have adequate computing power available, then that works.

Start with any convenient latitude. For each sight, we feed in that initial latitude. The result is a longitude for each sight. Usually the computed longitudes from the chosen latitude for the two sights will not match. So you bump the latitude by any convenient amount (0.1° ?) and try again. Now you have two points on two lines. If you plot those points, you can easily see where the two lines intersect. But if you prefer computation, you can simple repeat the work with yet another different latitude. Repeat until the longitudes for each sight are identical, using smaller increments of latitude until the difference in longitude is below some level of significance (maybe a difference less than 0.01°... maybe 0.00001°).

If you work this with a simple binary search (go up in latitude... is the difference in longitude better or worse? if better, go up again... if the difference changed sign, reverse direction and reduce the size of the increment...), the process converges soon enough. But it's far more efficient if you calculate the slope of the lines. Then it's a trivial problem in simultaneous equations (trivial if you ignore the matrix material). Thing is, that's just an algebraic version of crossing two straight lines. Genuinely the same thing. So the trade is drawing two lines on a piece of common graph paper versus some extended computation steps. If a device does the work, we don't care.

Frank Reed

PS: Thanks for posting this as a question for the NavList community. I'm sure you'll get other answers. There is no single answer to this line of inquiry.