A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Frank Reed
Date: 2012 Aug 6, 08:40 -0700
Lu, you wrote:
"These machines are located in his home in San Jose. He found some Comcast "support" feature that gave the position of his servers based on their IP address -- it said Orem, Utah!"
Yeah, it's interesting when that happens. I don't know the cause, but it seems it's probably a problem with the IP database. In any case, IP matching is a fairly coarse method of determining a computer's position. But you can try this out yourself. Just google "what is my ip address" and you'll find numerous web sites that will tell you the string of numbers and also generally give you the physical location of your Internet service provider. I just tried this here. It says I am in Marriottsville, Maryland. In fact, I am in Clarion, Pennsylvania, but I am getting Internet this morning via a little Internet "hotspot" which I use for my main Internet access instead of, e.g., a cable modem (which is somewhat faster, but physically fixed). The server for my Internet access today is presumably in Maryland. This is not the same issue as the occasional wildly incorrect IP location lookups. Incidentally, this is a weird location. I have so-called "4g" wireless Internet access speed here, around 1000kbps, just sitting in a park in a small town, but I have zero bars on my cell phone (same provider!).
"It then offered to calculate the distance from the server to major cities in the US -- and came up with 6003 miles to San Jose, 5557 miles to Portland, Oregon, and 5420 miles to Houston, etc. My friend looked at the numbers, played around with them, and somehow tried Nice, France as a location. Comes out very well. "
But this really is just the standard celestial navigation "circles of position" problem. There is, of course, a closed-form solution. It's rather involved mathematically for manual computation, and historically it was too cumbersome (which is why the intercept method became the standard). But back to basics, just get out a globe (or find, or code, a virtual one with the right properties). If you do this with a real globe, you may want to find a vinyl inflatable globe that you can draw on without worry. For a scale, get a string or a narrow strip of paper and mark it up using the scale on the globe or if it doesn't have one, you can make your own by remembering that it's 10,000 km from pole-to-equator or 5400 (=90*60) nautical miles. Now place a marker at any point from which great circle distance is known, e.g. Houston, as in the example above. With your scaled string measure off the distance away in any direction and pull it taut. A great circle is a "geodesic" on the globe so a string pulled taut across the surface automatically follows a great circle path. Grab a marker and mark off the circle of points around the central point at the correct distance away, sweeping the string around, keeping it taut. That gives you one standard circle of position, just like we've seen in countless introductions to celestial navigation. If it were a celestial navigation problem, the central point would simply be the spot where some celestial body is straight up and the distance away would be equal to the corrected angular zenith distance. Do it again with one or more other circles. Where they cross is your position. If they don't exactly cross, you get into cocked hats and least squares solutions (like the solution in the back of the Nautical Almanac ...note: the solution in the back of the N.A. is not a separate solution to this problem; it's just a statistical least squares method of averaging the error of multiple circles that don't quite cross in an exact point).
Tools that calculate distance between computers by "IP address lookup" have been around for years and years. Here's one: http://www.ipmarker.com/ip-distance/. They're usually just for amusement. They demonstrate that there are geeky programmers out there constructing these things. The algorithm for great circle distance has been standardized and "canned" for well over a decade. That does not prevent bugs in implementation, of course! The simplest bug that I can think of is an error in the conversion from angular arc to distance in statute miles. Were the numbers that you posted previously actual distances as quoted by the site? If so, you may be able to scale them and determine the error in the unit conversion, if that is actually the bug here.
NavList message boards and member settings: www.fer3.com/NavList
Members may optionally receive posts by email.
To cancel email delivery, send a message to NoMail[at]fer3.com