In many areas, not limited to routing, speed can be also a weakness. Not
necessarily the speed itself, but things leading to high speed.
It is like a half-joke about software usability:
It can be free, easy, but not powerful.
It can be free, powerful, but not easy.
It can be powerful, easy, but not free.
( Sure there are many exceptions, but the point is in trade off, not
limited to software. Focusing on some parts and neglecting other parts ).
The focus on high speed often means sacrifying things not leading to high
speed or blocking high speed.
In domain of WWI/WWII battle cruisers, high speed for hunting smaller
cruisers/destroyers and escaping mighty battleships had meant sacrifying
either firing power, either protection.
( Remember Hood vs Bismarck, where Hood weak protection was its fate.)
In domain of athletic running, speed of sprinters sacrifices their
endurance for long runs due high volume and mass of muscles, high oxygen
consumption and low aerobic capacity.
In domain of routing, it sacrifices routing flexibility and puts on high
load the provider resources.
And that is why it is good to have both high and low speed routing
applications,
wher it is on the end user, what he/she prefers.
Those blindsided with high speed of contraction hierarchy do not see
the price to achieve that speed.
--
You received this message because you are subscribed to the Google Groups
"OsmAnd" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osmand+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osmand/1711c8c1638.2799.a291d67f9894f806060d35c996ca15e9%40gmail.com.
