Brian Dunning wrote: >>> I realized one day that at a distance of a hundred miles or less, I >>> just >>> didn't *CARE* about curvature of the earth, and replaced that trig >>> with >>> your basic Cartesian distance. > > True, but be aware that this is only true when all of your coordinates > are in the same general latitude. For example, lines of longitude are > much closer together in Montana than they are in Texas. But we DON'T CARE! I just want the closest Wendy's (as a real example of a HORRIBLE on-line geographical search feature). I don't really care that that calculation in miles is "off" by a mile or two, or 10, or 20, because the error will be consistent within the data set. I just want the CLOSEST whatever to country/postal XX/ABC-DEF. You have to be at Santa's workshop or in that research complex down on the South Pole for this to be a problem in the real world. >>> If tomorrow the USPS creates zip code 60609, I can be >>> pretty damn sure it's "close enough" to 60601 through 60608 and just >>> average them to make up bogus long/lat. Sure, it's "wrong". It's >>> also >>> FREE and "close enough" for what I (and almost for sure you) are >>> doing. > > As the purveyor of a zip code database, I can assure you that this is > not at all true. In many cases it is, but in many cases, not. Example: > Here in So Cal we have 8 new zip codes since last month where the > nearest zip code numerically is over 25 miles away. As a soon to be purveyor of a world-wide FREE postal code database, where the OpenSource community, many of whom just happen to have those nifty GPS devices, will be donating their hometown zip[s] I am not at all concerned about this. PS I also cross-check the city names. Frequently, you can eliminate all but a couple records from your interpolation simply because they're in the wrong city. Plus, sometimes you have to extend or shrink your range based on the density of entries. But I've never had somebody complain because the long/lat I interpolated was too far off. Been doing it for years now. > But I hear what you're saying as far as "good enough" for this > particular application. EXACTLY! I don't even care if a few entries are off by 25 miles for now. Somebody will step up and fix them shortly. That's how Open Source works. I've been using this succesfully for YEARS, so I know it works. I just don't have the data for Canada, England, France, Australia, ... that I want. But there are a lot of common applications where it's good enough. Store Locater Gross-resolution tour-planning, such as a band on tour Aggregate shipping/delivery planning I'm sure there are a lot more applications that don't need the fine-grained resolution of a MapQuest, but want this sort of feature to be easily integrated to their site. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
