I think I figured out a routing design flaw in my Rand device.

Like I thought. You have no interest in actually addressing the problem. All you want to do is defend what exists by pretending it is already perfect.

I do not think I know it all, but I do know what I saw, and what the unit does regularly.

It simply does not matter what Rand calls interstate exchange ramps and bridges, but if you want to improve your routing algorithms, ramps and bridges at interstate exchanges with non-interstates should, no matter what they are called, be considered the equivalent of interstates.

Since you have absolutely no interest whatsoever in recognizing the criticisms of an experienced IT professional with nearly two years OTR driving experience who has been using your device in the field non-stop for more than six months, I think this discussion is over.

Thank you for helping me decide what my next brand of truck GPS will not be.

 

I did, but I cannot tell if it has made any difference in routing accuracy, since I have had very little opportunity to test it so far - am currently on a 34.

 

The actual code errors (crashes during long route planning) that I have been seeing are irregular. I have seen no other obvious ERRORS in the code or electronics, and can only tell if those faults stop after I use the device for a long time..

That's what you seem to be misunderstanding here. There is a different between an error or fault, and a logical design flaw. The routing design flaw existed before the software was ever written, back when the planning team was figuring out the logic for how routing would be performed.

Your code might be working perfectly to do exactly what your design team planned for it to do.

That does NOT preclude the possibility that there is a routing design flaw that has existed al the way back to the planning stages.

It is a simple fact that if an experienced driver were to plan the route that the machine presented to me the other day, I would consider them an utter moron. One does not add 10 miles to a trip to avoid crossing a 500 foot bridge unless there is a reason to avoid that bridge.

Granted, expecting the machine to be as good at route planning as a competent professional driver is not something that should be seriously expected. Eventually, perhaps, but not if you don't put effort into improving routing logic.

However, I also pointed out a very simple way to enhance the routing logic to allow the device to make a smarter route decision in 'prefer Freeway' mode. During the pathing process, if the bridges crossing interstates at interchange exchanges with non-interstates, and their connecting ramps, are considered to functionally be interstates, then the pathing process can properly make the decision to cross the bridge without needing to change to a different routing algorithm.

I call it a logic flaw, because it is a pathing logic flaw that would be easily addressable by adjusting the routing values assigned to specific types of interstate exchanges. AGAIN, that doesn't mean it is an error in the code. It may be working exactly as it was planned and written to be working. Logical flaws in code frequently go back before any code was written at all, sometimes even back to the napkin stage before it was ever expressed on a flowchart.

****

I will provide another example of a logical flaw on the TND 730:

When I plan a route, if I choose to look for points of interest along that route, the device clearly follows the route mile-by-mile, looking for POI's matching the criteria I set.

HOWEVER, despite the fact that the device is clearly following the path that I have routed while looking for POI's, the list of POI's appears with distances from my current location which are measured as the crow flies.

My truck is not a crow. It does not fly. Your device traced out a route, and could have very easily also tabulated the actual road mile distances between my truck and each POI that matched my search criterion. In fact it DID tabulate the distance. It clearly does so at the top of the screen as it performs it's search! It simply doesn't report that tabulated distance, preferring a useless distance instead! Pre-code Logic Flaw!

That is a logical error even though the information is entirely accurate. The POIs' ARE along my path, and the distance to them IS accurate, but the distances provided are air-miles, NOT road miles. And in many cases, the difference between air miles and road miles is huge.

If you don't believe me on the air miles vs. road miles issue, I can hammer you with example after example, from anywhere in the US, with 100% guaranteed repeatability. But right now, I need to sleep.

 

You are being deliberately obtuse. There is a difference between something being incorrect and something being inefficient and logically deficient.

It would be correct for me to say that the end result of turning 450 degrees right is the same as turning 90 degrees right.

For the device to search and route to each POI does indeed take time, which is why it is utterly stupid and ridiculous for that time and effort to be wasted when one does a POI search ALONG A ROUTE and the device is clearly and obviously calculating along the already defined route for matching POIs.

You are not interested in improving your product line, only defending it from any challenges.

 

Again defending what is, rather than having any interest whatsoever in improving the device.

That way leads to Google eating your lunch when they finally get off their ##### and launch a truck product.

But you don't care. You just want to defend, defend, defend.

When we calculate a route, THEN SEARCH ALONG THAT ROUTE for a POI, the device shows what road distance has been scanned as it follows the route. It shows that mileage at the top of the screen. I have intentionally chosen extremely odd, long pathing tests to prove this.

So every time it finds a POI along that route, it also knows how many road miles are between the truck and that POI. Rather than saving that data and displaying it in the list of matching POIs, the current code discards the more accurate, useful mileage data that the drivers actually could use, and provide garbage direct-line mileage likely based on GPS coordinate arithmetic.

You are providing an excellent example of how a dogmatic and too-defensive employee can prevent a company from improving their product line.