Oh, that sounds like map error. Maps generally only know the first and last address on a block and interpolate in between. If all lot widths aren't equal or the addresses increase in non-uniform steps, that interpolation leads to noticeable error.
--- On Sat, 2/4/12, Carleton MacDonald <[email protected]> wrote: From: Carleton MacDonald <[email protected]> Subject: [USMA:51453] RE: Leap second lives to leap another year To: "U.S. Metric Association" <[email protected]> Date: Saturday, February 4, 2012, 9:21 PM >From the traffic light to my house is exactly 1 km. The error is about 200 m, >or, about 19 seconds of driving, given the low speed limit on my street. It >may be just a coincidence, or the map data being off, so the GPS thinks that >“9533” is in some other place. Carleton From: John M. Steele [mailto:[email protected]] Sent: Saturday, February 04, 2012 15:51 To: U.S. Metric Association; [email protected] Subject: Re: [USMA:51450] RE: Leap second lives to leap another year That is a HUGE error, nearly 0.6 km. I suspect a datum error between your GPS and your map. Unless you know you have to accomodate a different datum, GPS should be set to WGS84, and map datum should be that or NAD83. With waypoint averaging, my GPS agrees with the National Map to about 0.1" of arc. The 19 s between GPS time and TAI was the difference between TAI and UTC at the epoch of GPS time. It is a constant. --- On Sat, 2/4/12, Carleton MacDonald <[email protected]> wrote: From: Carleton MacDonald <[email protected]> Subject: [USMA:51450] RE: Leap second lives to leap another year To: "U.S. Metric Association" <[email protected]> Date: Saturday, February 4, 2012, 3:05 PM “GPS time does not incorporate leap seconds and lags TAI by 19 s. It is widely distributed as a precision time source.” Wonder if this is why GPS shows my house as about 19 seconds south of where it really is. Carleton From: [email protected] [mailto:[email protected]] On Behalf Of John M. Steele Sent: Friday, February 03, 2012 08:05 To: U.S. Metric Association Subject: [USMA:51443] Leap second lives to leap another year Three actually, and the next leap second is the end of June 2012 (2012-06-30T23:59:60Z). I don't know if this really relates to metrication, but the current issue of "Metric Today" has about a 1.5 page story on the proposal to kill the leap second. People may be interested that any further decision has been deferred to at least 2015: http://www.nature.com/news/leap-second-granted-extra-time-1.9865 Leap seconds are currently declared with more than five months notice and can only happen (or not happen) at defined times. Any time-critical software can and should be defined to accomodate this. GPS time does not incorporate leap seconds and lags TAI by 19 s. It is widely distributed as a precision time source. Critical timing applications might do better keeping TAI or GPS time and computing UTC with a leap second table. Events more than 6 months ahead would have a 1 s uncertainty in TAI until the potential leap second in the interval is declared up or down. But really, If you know in mid-January, how hard is it to recompute events for the end of June? For less critical applications, the GPS navigational message includes the current offset to UTC, and the binary code embedded below voice in the WWV broadcasts carries a leap second flag if there is a leap second at the end of the current month. I see no need to completely disconnect time from the sun.
