(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
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...
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...
Sadly, I don't have any particularly good alternative.
Walt
"Chris Miller" <cmi...@keyresinc.com> wrote in message
news:O3J2njmpBHA.2148@tkmsftngp07...
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?
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
"Eric Frost" <fr...@please-delete-this-section-cnsnet.com> wrote in message
news:#Xs$Ub1pBHA.2220@tkmsftngp02...
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...
>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
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
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
"Chris Miller" <cmi...@keyresinc.com> wrote in message
news:es2k6vMqBHA.2056@tkmsftngp03...
>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.
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.
60611
60514
and it reports: 0 miles from Error to Error
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...
Yes, that sounds right :-)