Streets & Trips 2009 Routing Errors

Musty, I see the problem you are facing. No matter where you draw your avoid area rectangle(s), the routing seems bizarre, taking you on an unreasonably long detour.

jharpur, strange routing, but in your case at least the avoid area feature can fix it:

I just tried it in S&T 2008 and get the same results as you get in 2009.

I also tried it in Garmin's MapSource with City Navigator North America 2009. That's the same map data that's in Microsoft's S&T 2009. The routing is just as you would expect it to be (see attached screenshot), so we can rule out the possibility that it's an error in Navteq's map data.

Looks like it's a glitch of some sort in Microsoft's routing algorithm or Microsoft has introduce a map data error subsequent to receiving the data from Navteq.

...ken...

Attached Thumbnails

 

I have a workaround for the St. Marys to Nobel trip, just pick someplace that is likely on the route, add it as a stop and re-route. Presto sanity reigns, even if the place you choose is on the sane part of the insane route.

The routing algorithm is busted.

I've noticed that most unusual routings are corrected (sometimes causing other insanity further downstream, though) when another point is added and re-routing is needed - this happens whether you select a point to add while planning the route, or as I'm prone to do while travelling, using the GPS to reroute from my current point, assuming I'm already on the "non-loopy" route.

Algorithm: Definitely skewed. It might also explain why, when travelling across Canada (Moncton, New Brunswick to Vancouver, BC, for instance) the router (on both Shortest- and Quickest Route preferences) will, annoyingly, divert you into the states at every possibility, even if it adds hundreds of miles. The algorithmic "weighting" of the roads differ from US and Canadian sources.

What S&T denotes as a passable, but unpaved road in the US is shown as being the equivalent of what may be a roughcut logging road in Canada. Experimenting with S&T2007, I followed two routes with my preferences for nice, wide roads turned waaaaaay down; once for a trip in the US, and once in Canada.
What I noted was the roads in the US were generally about a grade higher than the "matching" roads in Canada - but I also found that the best Canadian highways weren't given equal values to their US counterparts - occasionally with reason, but if a route is safe at 110km/h, it ought to be considered roughly the equivalent of one safe at 65mph.

Rant rant rant, gripe gripe gripe. Still love S&T.

Microsoft's Maps.Live.com can generate this route better than Streets & Trips 2009. It may not be as good as the route Terry generated with his Garmin Mobile PC, because Maps.Live.com routes you through Edmonton, but Terry's route avoids Edmonton. Nevertheless, the online map doesn't make the big error discussed above. View the route here.

It seems to me that S&T rates US Interstate Highways as the Gold Standard beyond which there can be no better. This is, of course, pure nonsense inasmuch as very few US Interstates are as good as, say, the TC1 from Regina to Calgary. And S&T makes some perfectly good Canadian highways look like goat tracks and vice versa for some US roads.

I guess it is futile to expect reality or at least a true equivalency in road ratings.

I wonder if it has anything to do with the sources of Navteq's data for Canada? It's possible that the attribute coding on road segments is different from whoever supplies the Canadian data and that's what causes the discrepancy.

...ken...

Highly likely.

There is a solution for that problem. It's a map product called Metroguide Canada. After nearly five years we are finally being treated to an update (from v4 to v5). It's Canada only and it's about the best map on the planet. The data supplier is DMTI Spatial, a Canadian company. Unfortunately the map product comes from Garmin so that's not much good for S&T users.

...ken...

But unless we can convince Microsoft to use that data we are stuck with poor routes.

Hello,


I am using the trail version of S&T and it has been great till now....

Now, when I enter in my route (45+) stops it wont optimize correctly. I enter in the route and it says its optimizing but keeps it in the same order as I entered it. I have to then manually re route it myself. How can I help it to optimize correctly again?

Larry from MS said (at the beginning of this thread):

The avoid area feature is also suffering for some bugs and it is not always working neither. See:
Streets & Trips 2009 avoid area bug

Maybe you can add a fix for this issue as well in next version of S&T 2010...

Sorry i am a little bit late for giving a feedback on this thread

Just chiming in - I've been hit with some routing glitches in the past when planning out some "line chase" trips (first using S&T 2004 then with S&T 2008). My solution was always to add in some "routing" stops to force the route planner to 'wake up and smell the coffee'.

Also, in my experience, hitting the "Optimize Stops" button almost always reverses the order of the stops and injects a healthy dose of insanity as a result. I just pulled up the planned trip for next month and tried it - sure enough. I then decided to try hitting the 'undo' button and I then get "Invalid argument was encountered" and S&T then locked up - had to kill the process in the task manager (0% CPU but nonetheless locked up). Relaunching the program, I find that it didn't even remember I had recently opened that same file (it didn't list that map in the most recently used list).

I then just thought of hitting 'reverse route' after S&T reversed my route and it skews the timing further - like all those stops where I had marked as 'stay overnight' or stops where I plan to spend a few hours have had all the timing information removed. Even restoring the timing still left a route that looked good but was insane time-wise.

I usually end up shuffling the order of the stops and regenerating the route until I get a route that looks good and has some breathing room built in.

Yup. S&T 2008 has routing issues too. Try routing between Benedict, ND and Norwich, ND - it will send you up the Ward / McHenry County line (181st St. SE / 20th Ave. SE). Go look at it on your preferred satellite view website and see why that won't go. The correct routing from looking at the satellite imagery would be through Sawyer (Dakota Ave.) then 153rd or 167th St. north to US 2 then east...

I tried it with Garmin's MapSource/City Navigator North America 2009. Garmin's data comes from Navteq, the same supplier as Streets.

If I set the route preferences to faster time it takes me north up CR-23 to highway 52, north-west on 52 to the junction of highway 2 at Logan, then east on 2 to Norwich.

If I set the route preferences to shorter distance it takes me north all the way: north on CR-23, jog east on ND-23/233rd, north on 181st to cross highway 52 just east of Sawyer, jogs east on 47th to 19th Ave N, then north on 19th to Norwich.

In MapSource you can also set "Road Preference". It's a slider with "Prefer Highways" at one end and "Prefer Minor Roads" at the other. Mine is set in the middle (the default).

With such a variety of possible routes available in this particular case, it appears that routing preferences will have a significant impact on the resulting route.

...ken...