IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Any obvious pitfalls in using this?
[link|http://www.webdevelopersjournal.com/articles/dealer_locator.html|http://www.webdevelo...aler_locator.html]
New expensive aint it?
psuedo code
$zipwho=`read zipcode from field`
sqlplus /
select `pimp` where zipcode-'zipwho'
populate form zip=pimp
regards,
daemon

that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
clearwater highschool marching band [link|http://www.chstornadoband.org/|http://www.chstornadoband.org/]
New Huh?
Given a table of location (not ALL zips, just where stores exists),
given a single zip where someone lives, show me the 5 nearest stores in increasing order of distance.

Something tells me your solution won't do this.
New isnt that what mapquest and grep comes in?
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
clearwater highschool marching band [link|http://www.chstornadoband.org/|http://www.chstornadoband.org/]
New Well, I see the L pseudo scripting language is catching on.
New Possible distance quirk.
Depending on the latitudes and longitudes of your zip codes, it might be possible for it to mis-sort the distances slightly.

For instance, say you have three zip code areas in a line, west to east, in somewhat decreasing size. You have a dealer near the east edge of the western-most (#1). You have another dealer in the middle of the eastern-most (#3). You have a customer closer to the western edge than the centre of the middle one (#2). Which is going to list closer? Well, it depends on where the latitude and longitude are. If they're in defined as the middle of each area, then the customer is probably going to be told #3 is closer when he is in fact quite a bit closer to #1.

Now, this probably wouldn't happen all that often: it depends on how many dealers you have! But listing the closest 5 would tend to alleviate that and many people would understand the problem enough to overlook it, anyway.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
 
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

New Yep, thought of that
Here is the email I sent to my boss when he asked me to look into it:


Seems straight forward.

How many dealers?

What about the granularity?

This is based on the center of the zip.

Does this need to find multiple dealers in a single or a couple of zips,
which would possibly send a person to the wrong area?

New Consider natural barriers like rivers too...
If I were to use something like this in the DC area, I'd want to consider that there are only a few Potomac river crossings. Thus a Lat/Long bee-line distance may be quite short, but the actual distance may be much longer due to the necessity of going across a major bridge.

If you were looking for the nearest McDonalds, it wouldn't be an issue. If you were looking for the nearest IKEA, it would be.

There's probably not a simple way around this problem (unless you're tied into MapQuest or something similar), so giving several possible answers and letting the user choose is probably the most reasonable approach.

Cheers,
Scott.
New As the bird flies
That is the directive. So rivers, etc, are OK
New You do something clever with the number of results.
If you figure out (say) 10, then stop displaying them once the distance gaps get suddenly a lot bigger. So if someone is real close to 2, moderately close to another 3 and quite far from the next, they see 5. But if someone is moderately close to only 4, they see 4. And if someone is quite a ways from 3 and quite a long way from the next, they see 3.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
 
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

New Too confusing
I can imagine the tech support calls when people get a variable number of responses that do not seem to correlate to exact distances.
New Well the code is crap...
and performance will suck and (without looking closely) it looks like it assumes that each store is at the center of its zip code (which can be a sizeable error if the stores are within your zip code).

Otherwise it probably works.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New Not much code there to be THAT bad.
Yeah, he abuses regexes for no good reason, and the concept of wrapping a single line of code in makequote is kinda stupid, but just the general concept is what I'm looking for comments on.

Anybody who says Let's take a walk through this bad boy makes me want to smack him, but I'll bury that impulse.

We've already discussed the zip centroid issue, the multiple hits in a single zip issue.

As far as performance, I have no idea what the user population is, nor the number of comparisons I'd have to do. But I can optimize to minimize them, so it does not worry me. Too much.

New It doesn't take much to be bad
Let's see. Without looking hard, no strict, uses cgi-lib.pl, makequote reinvents DBI's quote method (badly - and if you did this in Oracle then you'd want to use placeholders, really), there is a horrible parsing technique, no indentation, method calls inside of strings (that won't work very well), the aforementioned zip code issues and his formula for distance is computationally unstable at low distances (which is ironically where you care most about accuracy). I also think that the formula should be documented in the code...

But other than the fact that every detail sucks, the general idea is workable.

If you want a better calculation, then I'd suggest using Haversine's formula (faster for computers to calculate, more numerically stable):
\ndlon = lon2 - lon1\ndlat = lat2 - lat1\na = (sin(dlat/2))^2 + cos(lat1) * cos(lat2) * (sin(dlon/2))^2\nc = 2 * atan2(sqrt(a), sqrt(1-a))\nd = R * c\n


where R should be the radius of the earth, aka 3,959 miles (on average - it varies). You can find a derivation at [link|http://mathforum.org/library/drmath/view/51879.html|http://mathforum.org...h/view/51879.html].

Also given how many services (Google, mapquest, etc) do accurate geocoding, I'd suggest that today the zip code approximation is not good enough. Sure, use it as a fallback. But go negotiate a contract with someone like mapquest allowing you to geocode lots of addresses. I don't know what it costs, but I don't think it is that much. And take your program and add an artificial limit, such as "closest 3 within 20 miles". (Or reorganize it about that limit) Who's going to drive more than that just to get to a dealer? That limit will let you use a "bounding box" of latitude/longitude combinations allowing you to significantly reduce how many dealers you have to do the expensive calculation for.

Have I explained my response sufficiently? The idea works. The approach is inefficient. The code is crap.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Expand Edited by ben_tilly Jan. 7, 2005, 01:53:56 PM EST
New Nice. It's things like this that make zIWeThey a great read.
New 20 is nothing
"closest 3 within 20 miles". (Or reorganize it about that limit) Who's going to drive more than that just to get to a dealer?
distince is relative. When I lived in Corpus Christi, it was "forever" to drive anywere that was over 15 miles away. Now that I live in a large city, I think nothing about driving someplace that's 40 miles away(Fry's Electronics comes to mind).

I'd say just list the closest 3 or 5, regardless of how far they actually are.
Darrell Spice, Jr.                      [link|http://www.spiceware.org/cgi-bin/spa.pl?album=./Artistic%20Overpass|Artistic Overpass]\n[link|http://www.spiceware.org/|SpiceWare] - We don't do Windows, it's too much of a chore
New I may be biased
I work for a company where people do a lot of searching. It has critical for us to find ways to optimize them.

If your volume is low and performance needs are not critical, then sure. Go with the obvious dumb approach. But if you need to optimize later...

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New no disagreement about the code
just the limit of < 20 miles.
Darrell Spice, Jr.                      [link|http://www.spiceware.org/cgi-bin/spa.pl?album=./Artistic%20Overpass|Artistic Overpass]\n[link|http://www.spiceware.org/|SpiceWare] - We don't do Windows, it's too much of a chore
New Thanks
     Any obvious pitfalls in using this? - (broomberg) - (18)
         expensive aint it? - (daemon) - (3)
             Huh? - (broomberg) - (1)
                 isnt that what mapquest and grep comes in? -NT - (daemon)
             Well, I see the L pseudo scripting language is catching on. -NT - (ChrisR)
         Possible distance quirk. - (static) - (5)
             Yep, thought of that - (broomberg) - (4)
                 Consider natural barriers like rivers too... - (Another Scott) - (3)
                     As the bird flies - (broomberg) - (2)
                         You do something clever with the number of results. - (static) - (1)
                             Too confusing - (broomberg)
         Well the code is crap... - (ben_tilly) - (7)
             Not much code there to be THAT bad. - (broomberg) - (6)
                 It doesn't take much to be bad - (ben_tilly) - (5)
                     Nice. It's things like this that make zIWeThey a great read. -NT - (Another Scott)
                     20 is nothing - (SpiceWare) - (2)
                         I may be biased - (ben_tilly) - (1)
                             no disagreement about the code - (SpiceWare)
                     Thanks -NT - (broomberg)

For he IS the Kwisatz Haderach!
215 ms