On certain Interstates, and even non-interstate divided highways I've run across problems with Microsoft Streets and Trips going off the highway taking an Exit down a ramp then right back up the on-ramp back on the Highway or Interstate. A few days ago this happened on a Texas Highway # 181. It happened three or four times along this route. I was using it in GPS mode and as I traveled it kept telling me to take the next Exit to get off the highway. Of course I didn't so it would go into a re-calculate mode.

Why would Streets & Trips route off and on at these Exits instead of stay on the main Highway?

I've had it do this in other parts of the country on other highways/interstates as well.

Which version? 2010?

This sort of behavior has been reported in this Forum before, although I cannot find the specific threads. I think they were before S&T 2010 was rolled out so this may have been mostly corrected.

I always think it is a good idea to review a new route, if I have time to, before setting out to adjust anomalies such as what you report. But, in the end, what I see through the windshield always trumps what I see on the computer screen.

I've heard people mentioning this in earlier versions, and I'm just curious if the new Streets & Trips 2010 still does this.

It's usually anomolies in the map data that cause the routing software to do strange things to route around them. Garmin products do this,too.

...ken...

Sorry I didn't mention the version, but yes, this happened in Version 2010. Just last week when I set a route to follow Highway 181 between San Antonio, Texas and Sinton, Texas which is a southerly heading. It happened where Hwy 181 becomes a divided highway at Beeville, Texas where there are actual exit and entry Ramps off and onto the Highway. I didn't notice it until while driving until I got to this location with the GPS active. I then noticed it, because the GPS tried to route me off and then back onto the Highway.

Now, just for kicks and grins just a few minutes ago I created the same route again, but the route didn't goof up. It stayed on the main highway like it should this time around. I don't get it, I guess it's just a fluke that might happen once in awhile.

I agree that it's normally map data that causes this kind of issue. My Garmin and TomTom GPS units don't have this particular problem though. This is the default route the S&T 2010 creates for a trip from Mission Lake Blvd in Desert Hot Springs California to Mesa Az:



Now it makes no sense to travel all the way to Barstow and around Joshua National Park to get to I-10 when we are exactly 6 miles due North of I-10 interchange #120. I am forced to drag the route to I-10, creating a 'stop' there in order for the route to be calculated as 6 miles down Indian Road and the rest of the trip on I-10.

Attached Images

Desert Hot Springs to Mesa.jpg (50.4 KB)

That is pretty weird. S&T must have some goofy things that don't compute properly in it's map based data, because I tried your route on my S&T and got the same thing you did. However, depending on exactly where you set your Starting Point in Desert Hot Springs it sometimes takes the route you show, but from other locations as little as a couple blocks difference it goes from Desert Hot Springs straight to I-10 and then due east on I-10 to Phoenix/Mesa.

That would suggest the "break" in the data is somewhere in Desert Hot Springs, probably on one of the major "feeder" streets that would normally be expected to get you onto I-10. And possibly at a significant intersection so that it affects routing from places in town that would normally try to use those streets, through that intersection, to get onto I-10.

Streets which would normally feed you onto I-10 somewhere just past the point with the break (e.g. on the I-10 side of the break) will get "proper" routing.

The easiest way to understand this sort of routing behaviour is to imagine a real break in a road or intersection as if someone had actually taken a backhoe and dug a big, deep, impassible trench across it. Now imagine what the routing software will do when it sees that trench ... where is it going to send you in order to get you around it?

If you think about it that way and think about what parts of town get the right routing and what parts get the wrong routing, it's generally straightforward to figure out where the break most likely is and test for it.

If you take the time to do that (it's kinda fun, at least the first time), then you can make a note of the location and provide that information to Navteq (the folks who supply the map data to Microsoft) on this page:

NAVTEQ Map Reporter

If you don't have the time to track down the exact location of the break, you can still help the cause by reporting the example above to them and they can figure out what's causing it. They will be happy to get notified of the error either way.

...ken...

I agree with a lot of what your saying Ken but if Navteq provide the maps to Microsoft and they also provide the maps for my Garmin Nuvi, why does the Nuvi route me 6 miles straight to I-10 and S&T routes me hundreds of miles out of my way? I'm probably using a newer version of the Navteq maps on my Nuvi which I guess could be one reason for the difference but the road in the particular area of my 'start' position hasn't changed in many years.

I will try to start my route along the most logical road to I-10 and see if at some point S&T goes in the right direction.

I'll also forward this to Navteq as you suggest.

I would bet that error is in S&T, not Navteq. I checked my MapSource back to NACN v4.1 (2004?) and routing is via indian Road and I10. What was the actual starting address on Mission Lakes Blvd?

Terry

64256 Mission Lakes Blvd or try the intersection of Mission Lakes Blvd and Clubhouse Blvd. The route should be west on Mission Lakes about a quarter mile then left onto Indian Road and not right on Indian.


Funny thing is, if I use 64436 Mission Lakes Blvd as the starting address S&T seems to calculate the route correctly even though that address is farther away from the Mission Lakes/Indian Road intersection where the problem begins.

I see what you mean. If you drag the Mission Lakes start to the right, the route is corrected at Indian Road even though it goes through where the starting point was when it routes wrongly. The changeover seems to be where Oakmont Blvd is directly north of Mission Lakes Road.

I don't see this anomaly in MapSource.

Terry

Attached Images

Turn left.jpg (66.9 KB)

Turn right.jpg (18.8 KB)

Yeah, this is a really wierd one. If you move far enough east on Mission Lakes Blvd you will get the right routing. I can't get it to work from 64436. I have to go much farther east. I can't get it to go south on Indian Ave until I set the start point way over to a point even with Oakmount Blvd or east.

If I drag the start point even a tiny fraction of an inch more west, the route instantly swings north on Indian Blvd.

.....

Wow! Desert Hot Springs is totally hosed! Here's a pic of an even wierder route to Mesa. It starts on 11th Ave, S on Western Ave, W on Pierson, then N on #62 to Barstow.

.....

And here's another one. If I set the start point way out on the NE end of Annandale Ave it goes down to Pierson, over to #62, down to I-10 then WEST on I-10 to just west of Beaumont before doing a U-turn and heading for Mesa.

.....

I found these while dragging the start point around to various points in the general area of the first problem in the original post. I have determined that there is a Bermuda Triangle to the west of that point and north of approximately 14th ave that will always produce the original (problem) routing.

Is there a really strange story about Desert Hot Springs we should know?

YOH!!! Larry!!!! Terry and I cannot duplicate this bizarre routing behaviour on Garmin's maps with the Navteq data. I can only go back to 2009 but Terry went much farther back and no problems.

Did someone in Desert Hot Springs, CA, do something to really annoy you guys at Microsoft???

...ken...

Attached Images

Desert Hot Springs1.jpg (29.9 KB)

Desert Hot Springs2.jpg (46.5 KB)