Calculating distance based on "Blocks" rather than miles

71 views
Skip to first unread message

Ian Nesbit

unread,
Aug 23, 2011, 3:18:16 PM8/23/11
to google-map...@googlegroups.com
Hi,

I'm building this delivery application where I need to calculate the distance between 2 different addresses and compare it to pre-defined number, i have it now running by Miles, so if the distance between both address are more than 2 radius miles (for example) it will be false, now my clients are calculating distance based on Blocks, so they deliver only 10 blocks away, i need to find a way to figure out how many blocks in certain route between two addresses..

I do believe this feature is available using Google Maps, but now sure what APIs i can use, so any ideas?

Kesuke

unread,
Aug 23, 2011, 8:20:18 PM8/23/11
to Google Maps JavaScript API v3
I have to admit I'm slightly ignorant on blocks as a measurement since
we don't use that system in Europe. The problem is they don't have a
fixed unit of distance which makes calculating a block distance
arbitrary. I am not aware of any built in function to calculate the
distance in blocks, since the API is not aware of where or how blocks
are demarkated on the map.

How you go about this will probably depend on how many areas you need
to do it for. Can you tell us a bit more about the project - for
example is it for a company with 3 stores in one city, or a chain with
thousands of stores across the country?

If it is a small number, I would simply create a bounding box
encompassing the area which that store will deliver to. Then test to
see if the customers lat/lng address is within that area. If the
number of stores is large then that becomes impractical. In that case,
off the top of my head, you could try to give blocks an estimated unit
of measurement (e.g. 0.75 miles to a block) if that distance is fairly
regular across the areas you are dealing with, and then divide the
linear distance in miles by the blocks per mile. E.g. 5 miles / 0.75
blocks per mile would return 6.67 blocks. If the company has stores
ckustered in several specific cities/locations you could set different
rules for each one, based on each areas average "blocks per mile". But
obviously this latter approach will be subject to a potentially
enormous margin of error.

Ian Nesbit

unread,
Aug 23, 2011, 9:01:53 PM8/23/11
to google-map...@googlegroups.com
thanks Kesuke for your reply,

I have considered all of your options, let me tell you a bit about my project

We provide a online way for restaurant to receive orders, most of orders are to be delivered, we have just started in New York City but gaining more clients in different states (Tri State area)

 Our competitors provide restaurant a way to calculate distance based on blocks which i'm trying to figure out how, I know that Google APIs can help with it because when I use it myself for directions sometimes it tells me how far is that place in blocks (specially in Manhattan area)

Giving an estimated length for every block is not a good idea, for example mid town Manhattan have streets in numbers and avenues, the blocks between each street are almost half way shorter than ones between avenues, so given a fixed length for all block isn't practical

on the other hand my current solution works based on Miles, which started to cause problems, for example restaurants located in Mid Town Manhattan are not that far from West New York (that is New Jersey state)  and sometimes would fall within delivery area if it's only 2 miles radius, yet these restaurants cannot deliver to another state

also validating addresses based on zip codes is not going to give accurate results for the same above reason, one restaurant go across different zip areas for delivery just because they are near to them, others are not.

I'm thinking of having different solutions for different cities and/or states based on its nature of streets and distances, but the more markets we gain the worse customized development need to be made, i dont want to end up trying to develop my own Google Maps lol

can you elaborate more on your second idea "if it is a small number, I would simply create a bounding box encompassing the area which that store will deliver to. Then test to see if the customers lat/lng address is within that area."

thank you again


 
 


Rossko

unread,
Aug 24, 2011, 5:36:59 AM8/24/11
to Google Maps JavaScript API v3
Each store's area is fixed, however arbritary their choices or weird
their measurement system.
Devise a tool for drawing polygons on maps and storing them.
As each store is signed up, get the manager to draw his patch on your
map.

In service, test if an address falls within the polygon.

Ian Nesbit

unread,
Aug 24, 2011, 3:19:54 PM8/24/11
to google-map...@googlegroups.com
sounds like a good approach, thanks Rossko,

But I have three questions:

1- How to store the polygon into database (probably given the shape points coordinates right?)
2- How can Google's API help me to identify every point coordinates?
3- How can Google API's help me to test current point with stored polygon?

If you can point me to a tutorial or so that explains this and take me step by step into it (coding wise as well) i'd really appreciate it


geoco...@gmail.com

unread,
Aug 24, 2011, 3:36:38 PM8/24/11
to Google Maps JavaScript API v3
On Aug 24, 12:19 pm, Ian Nesbit <ian.nes...@gmail.com> wrote:
> sounds like a good approach, thanks Rossko,
>
> But I have three questions:
>
> 1- How to store the polygon into database (probably given the shape points
> coordinates right?)

You can use a spatially enabled database.
You can store the coordinates encoded (see the geometry library for
encoding/decoding methods).

> 2- How can Google's API help me to identify every point coordinates?

I don't know what that means.

> 3- How can Google API's help me to test current point with stored polygon?

They can't but there are algorithms that exist for point in polygon
analysis that can be implemented in your code.

Example:
http://www.geocodezip.com/geoxml3_test/v3_collection-map2e.html

-- Larry

Ian Nesbit

unread,
Aug 24, 2011, 4:21:43 PM8/24/11
to google-map...@googlegroups.com
thanks Larry

what i meant with question 2 is that how can I store the polygon into my database? i guess i'd store every point of the polygon shape coordinates into the database which forms one particular restaurant delivery area, right?

I'm using MS SQL Server 2005 which I will have to upgrade to 2008 to get the spatially support

 

geoco...@gmail.com

unread,
Aug 24, 2011, 4:51:32 PM8/24/11
to Google Maps JavaScript API v3
On Aug 24, 1:21 pm, Ian Nesbit <ian.nes...@gmail.com> wrote:
> thanks Larry
>
> what i meant with question 2 is that how can I store the polygon into my
> database? i guess i'd store every point of the polygon shape coordinates
> into the database which forms one particular restaurant delivery area,
> right?

Yes. But if you encode the coordinates, you save the resulting string
in the database, query for it, decode it back to coordinates to create
the polygons on the map.

-- Larry

Kesuke

unread,
Aug 24, 2011, 8:12:28 PM8/24/11
to Google Maps JavaScript API v3
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:
Reply all
Reply to author
Forward
0 new messages