mileage
Chris Miller
or better yet, door-to-door mileage and can be implemented into a web-app
using asp? (actual street mileage, not Lat-Long calculation - mapping would
be a +)
(Does Mappoint offer a solution? Would have to be hosted on-site, so it
looks like .NET is out)
I've looked into PC*MILER, but find it overpriced and quite lacking in
performance.
Any ideas are appreciated..
Thanks,
Chris
Chris Gebhardt
What you want to do can be achieved through the obvious, mapping. But for your former request, zip-to-zip mileage, why not just
output a database and then lookup the values in the database through ASP? It is easier to implement and less likely to fail (the
KISS principle.) As for door-to-door, the routing function you are looking for is available from several mapping vendors. However,
they are much more expensive than MP.
///Chris\\\
Christopher S. Gebhardt, Microsoft MVP
Crime Analysis Associates
www.CrimeAnalysis.net
ch...@crimeanalysis.net
"Chris Miller" <cmi...@keyresinc.com> wrote in message news:uwvnjsdpBHA.1600@tkmsftngp07...
Chris Miller
DB.. By ALL I mean, any combinantion in America? Sounds like a huge DB with
millions of records.
You spoke of some other software that's more expensive.. Do you have
examples? I DO expect to pay more than the price of MP.
Anyone else have alternatives?
Thanks,
Chris
"Chris Gebhardt" <ch...@crimeanalysis.net> wrote in message
news:#Ug#JVfpBHA.1852@tkmsftngp07...
Walt Cygan
combination once would require a table with 623415705 rows (35311 squared,
minus 35311 to eliminate comparing zips with themselves, divided by 2 to
avoid 'A'-'B', 'B'-'A' duplicates). Assuming 15 bytes of storage per row (2
zips plus the distance) and 10% overhead, that would be a table that is 9.58
gigabytes. Don't use Access!
Sadly, I don't have any particularly good alternative.
Walt
"Chris Miller" <cmi...@keyresinc.com> wrote in message
news:O3J2njmpBHA.2148@tkmsftngp07...
JeffK
zip code in your table, and have the distance between any other zip come
from a parameterized query on demand? You don't want to store combinations
that you'll never use.
To implement this, you'll need a way to extract a 'location object' or some
other equivalent area-centroid for zip codes in mappoint, unless the table
is available elsewhere. Anyone implemented this before?
Eric Frost
> zip code in your table, and have the distance between any other zip
That sounds good, but I think he needed road mileage, not crow mileage..
I think Walt's solution doesn't sound bad, what's 10 GB? OTOH there's
got to be a clever way of compressing that down considerably storing it
in some kind of matrix along the lines of what your are describing, but you'd
have to preserve more items than just the lat/lon centerpoint I would
think to ge road mileage out of it..
Eric
Walt Cygan
the mileage, but since this is a web app doing this with MapPoint would
violate the EULA. There was a similar question (though concerning straight
line distance) recently about tabling the zip codes within a certain
distance of each other. I'm not sure what the ultimate goal is for these
calculations, but given the need to make this info available on the web,
perhaps MapPoint.NET will be more of an appropriate solution.
Walt
"Eric Frost" <fr...@please-delete-this-section-cnsnet.com> wrote in message
news:#Xs$Ub1pBHA.2220@tkmsftngp02...
Chris Miller
a system that calculates crow mileage using lat/long coordinates.
I'm now looking for an upgrade (actual street mileage). There are programs
that do this, (PC*MILER) but I haven't found any that do this well and for a
fair price.
I got the evaluation version of MP2002 hoping that it would support ASP
integration with +COM, but found none.
I was also optimistic that MP .NET would provide my ideal solution, but I
must have the solution on the client server, not out on the internet. It
doesn't look like MS will provide the software.
Thanks for your replies.
-Chris
"Walt Cygan" <nospam_...@hotmail.com> wrote in message
news:erMqlR7pBHA.1716@tkmsftngp02...
Tony Toews
>Given that MapPoint knows about 35311 zip codes, to include every
>combination once would require a table with 623415705 rows (35311 squared,
>minus 35311 to eliminate comparing zips with themselves, divided by 2 to
>avoid 'A'-'B', 'B'-'A' duplicates). Assuming 15 bytes of storage per row (2
>zips plus the distance) and 10% overhead, that would be a table that is 9.58
>gigabytes. Don't use Access!
FWIW I'd store the zips and the distance in long fields which are four
bytes each thus making twelve bytes. That said you'd want to index
on each of the zip code fields for performance reasons so thats eight
bytes per index. Unless there's some interesting binary tree
optimizing going on which is quite likely which could dramatically
shrink the size of the index.
Therefore its somewhere between 12 and 28 bytes per record plus the
ten percent overhead.
Also some zip codes in places such as Alaska, Nevada, Arizona and New
Mexico are going to be huge. They could easily be a hundred miles or
bigger in any one direction.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Uffe Kousgaard
news:1jcc5u83r1v6d188j...@4ax.com...
> FWIW I'd store the zips and the distance in long fields which are four
> bytes each thus making twelve bytes. That said you'd want to index
> on each of the zip code fields for performance reasons so thats eight
> bytes per index. Unless there's some interesting binary tree
> optimizing going on which is quite likely which could dramatically
> shrink the size of the index.
>
> Therefore its somewhere between 12 and 28 bytes per record plus the
> ten percent overhead.
Please see www.routeware.dk/download/distancetable.xls for an example on
how it is not needed to store indexes at all.
35311*(35311-1)/2 * 2 bytes/record = 1.25 Gb should be enough.
The 2 bytes can be a word since no more precision is needed when doing
zip-2-zip calculations. 0-65535 provides sub mile precision, i.e. 65535
could mean 6553.5 miles or just 65535 miles.
MS Access may not support 2 byte words, but there is probably something
similar.
Kind regards
Uffe Kousgaard
www.routeware.dk
Chris Miller
information to a table, using Mappoint?
I have the trial version, and I am an asp programmer.. Does this require
programming a macro or something. I have never designed add-ons for MS
software.
"Uffe Kousgaard" <uf...@routeware.dk> wrote in message
news:Oqke1iKqBHA.2516@tkmsftngp03...
Walt Cygan
http://www.mp2kmag.com/articles.asp?ArticleID=50 and other mp2kmag.com
articles for some VB code that can work with MapPoint and SQL Server via ADO
to access and update data. As an ASP programmer you have probably done this
many times. You just have to move your ADO code from VBScript to VB and use
the MapPoint object model.
Walt
"Chris Miller" <cmi...@keyresinc.com> wrote in message
news:es2k6vMqBHA.2056@tkmsftngp03...
Tony Toews
>Please see www.routeware.dk/download/distancetable.xls for an example on
>how it is not needed to store indexes at all.
>
>35311*(35311-1)/2 * 2 bytes/record = 1.25 Gb should be enough.
>
>The 2 bytes can be a word since no more precision is needed when doing
>zip-2-zip calculations. 0-65535 provides sub mile precision, i.e. 65535
>could mean 6553.5 miles or just 65535 miles.
Gotcha. Smart thinking. Yup, that'd work quite nicely.
>MS Access may not support 2 byte words, but there is probably something
>similar.
Integer would be fine which is two bytes. But then you'd still need
a record delimiter which increases the space required by 50%. And
I'm sure there'd be other overhead within Access. So I'd just use a
binary file which I read using the Get statement in random mode.
Uffe Kousgaard
> Integer would be fine which is two bytes. But then you'd still need
> a record delimiter which increases the space required by 50%. And
> I'm sure there'd be other overhead within Access. So I'd just use a
> binary file which I read using the Get statement in random mode.
You can try it here: http://62.242.60.210/distdemo/demo.html
It is only as-the-crow-flies distance so far, but will be road distance
soon.......
It is of course a binary file.
Eric Frost
60611
60514
and it reports: 0 miles from Error to Error
Uffe Kousgaard
33171 and >35000 were reported ?
Anyway the interface only allows to type in the index of the zip's,
which means you should type 20702 and 20648 to get the zip's you are
after. I only spent very short time putting the interface together and
this will have to do for a first demo.
20 miles seems OK ?
Regards
Uffe
"Eric Frost" <fr...@nospammer-cnsnet.com> wrote in message
news:uqZLZGarBHA.2524@tkmsftngp03...
Eric Frost
Yes, that sounds right :-)