It sounds like the polygon solution will work best for you as the
delivery areas could end up being very complex shapes, such as where
they hug state boundaries or are impeeded by obstacles like rivers.
That wouldn't work very well with simple bounding boxes.
Rather than try to jump straight into the database stuff, if it were
me I would probably structure my workflow the other way around like;
1.) Make a basic map and an accompanying polygon for just one
resteraunt.
2.) Then next get the geocoding stuff working to convert a users
zipcode into a lat/lng position.
3.) Then get the code working to evaluate whether that lat/lng positon
lies within the area of the polygon using geocodezips' example
algorithm.
4.) Then finally once everything else works make the backend database
and JS/HTML utility for creating, saving and recalling the polygons.
There is a practical limit to how many polygons can fit on a map, so
depending on how many stores there are you might need to set it up so
a user enters their position (GPS/zip code or whatever) and then your
map calculates which store is nearest, loads it's specific polygon and
tests to see if the zipcode is inside it.
HOWEVER, there are a few situations where this might fall short: such
as where the geographically 'nearest store' as the crow flies is not
actually the one that delivers to that address - for example because
two stores hug a state boundary, or where two stores are located on
opposite sides of an impassable object like a river. So to provide
some safety, perhaps load the nearest 2-3 stores polygons and test to
see if the address falls into any of them?
You will probably also need some sort of mechanism to handle
situations where two stores have overlapping delivery zones - i.e. you
either choose the most geographically proximal store automatically OR
perhaps give the user a selection box to choose their prefered store?
On Aug 24, 9:51 pm, "
geocode...@gmail.com" <
geocode...@gmail.com>
wrote: