[Routing] "SatNav warriors invade Somerset village" - the formula V0.1
Marcus Wolschon
marcus at wolschon.biz
Tue Mar 4 06:52:05 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stefan Baebler schrieb:
| what the car can take _safely_
|> * usual ACCEL-eration for accelerating and as factor for hills
|> * EFFICIENT_DRIVER == true if and only if the driver selected
|> ~ "most efficient route" instead of "fastest" or "shortest".
|> ~ Else we can assume he wants to arrive as early as possible
| then also
| * min_turning_radius
| * tire_wear, tarmac_temperature, humidity... (affects the grip)
| ...etc...
With a friction-constant of 0.7 the formula gets pretty reasonable
results. I was just stressing the "efficient"-metric because that's
how I drive (given current fuel-prices) and it's only seldomly found
in commercial software. (Travelbook has it but it's not very good.)
A metric gets called quite often, so I'd like to keep it simple.
I think using trigonometric functions (in "arc_radius(node0, node1,
node2)") is already quite heavy but barely acceptable in terms of
runtime.
| How about automatically _learning_ all the needed parameters from the
| GPS readings? Sure first few days the routes would be calculated with
| some default options, but would dramatically improve (personalize) over
| time. This would also take into account seasonal changes in weather (eg
| slower trough curves and avoiding high altitude in winter). Dynamic
| learning would also suggest you to take byroads if they are faster than
| your current average speed on highway (traffic jams, broken down
| vehicle), suggesting you first suitable exit.
Well, I offered to host a service to collect such data, did I not?
But I think you took the idea too far. We are looking for a better
metric for route-calculation. Most of the time routes found using
only the highway-type and distance are already good, so I think no
user would want to input any additional parameters except the type
and maybe weight of his/her car the first time uppon setup and the
metric to optimize for.
However, you are free to implement such an extended metric.
Here is the interface to implement:
http://travelingsales.wiki.sourceforge.net/IRoutingMetric
I'd be glad to write test-cases to run it against any other
metric for you on real-world data.
I'd really like to play with some anonymous car2car-communication
here. After all, if you have a navigator, you already have a computer
that most likely can do wirless lan or bluetooth-PAN and your own
software running on it. This way a car on the opposite lane can
tell you statistics about the road directly ahead of you and pass
on data from cars in fron of you that it just passed.
Anyone interested in specifying such a protocoll? e.g. broadcast
small, gzipped xml-chunks as udp-packets with 802.11a/b/g in
ad-hoc -mode as a physical layer.
Write a very easy to implement spec and a library, so that everyone
who is interested can implement it.
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHzPGVf1hPnk3Z0cQRAiBFAKCJkjaEtkSYLu8+oCvPBFYSlFjVMgCfaWd2
68BHX7pOjs5wS6kOoPSsNPE=
=PM/E
-----END PGP SIGNATURE-----
More information about the Routing
mailing list