Streets & Trips 2009 Routing Errors
After all the discussion, the fact remains that the routing software has serious flaws that need to be addressed by Microsoft. Here's another example of what I'm talking about using a very short trip in Council Bluffs, Iowa.

If I start at the intersection of S. 8th St. and 1st Ave and end at the intersection of N. 8th St. and Avenue A, the trip should be four blocks north. Instead, it takes me two blocks west to 10th St. then four blocks north to Avenue A and then two blocks east to 8th St. It suggests this route no matter if I pick the shortest route or the fastest route. I've looked at this area on an aerial photo and there's no reason not to go straight north on 8th St.

I did not purchase Streets & Trips 2009 but I would like to get 2010. I sure hope these routing problems are fixed by then.
Ken in Regina
As I mentioned above, the problem is usually in the map data, not in the routing routines of the program. I know this won't make you feel any better but the problem you described is in the map data supplied to Microsoft by a company called Navteq, not in Streets&Trips' routing. Here's the proof:

The attached image is from Garmin's Mapsource program using the very latest (2010) Garmin City Navigator North America map data. This map data is from the same supplier, Navteq. As you can see, it produces the same silly route, even with the latest map data.

Attached Images
Ken in Regina
Some more playing with the routing around this spot shows that there is a break in the map data somewhere very close to the intersection of West Broaday with 8th St S/N. My best guess would be that 8th St N is not connected to 8th St S. See the attachment for a couple more wonky routes that I used to narrow down the break point.

The route on the left is is from S 8th St and W Broadway to Top Creek and N 8th St.

The route on the right is from W Kanesville Blvd and W Broadway to S 8th St and W Broadway.

By the way, W Broadway is one of the strangest street layouts I've ever seen. Is that intersection I've selected by Papa John's Pizza really W Broadway and S 8th St.?

By the way, the only way errors like this get fixed is if they are reported to the map data supplier, in this case Navteq. You can report the error here:


Attached Images
Marvin Hlavac
Is that a newly built area by any chance? Is it possible the road was blocked at one point in the past?

We moved to our current house about 4 years ago. The first year we lived there there was a road that was blocked to car traffic at one point. You could access the road from the south and also from the north, but at one point in the middle there was a road closure, and people had to take a detour.

When the road opened I decided it would be an excellent opportunity for me to see if Navteq would EVER find out about the change. I didn't want to submit a map feedback, I was interested if Navteq on its own would update the short and relatively 'unimportant' road in a residential area.

It took (only) about a year or two (a version or two) till I saw the correction to the map data. I actually thought it could take much longer than that.

I have no way of knowing if some local resident filed a map feedback with Navteq, or if Navteq found out about the new map data on its own.
The vast majority of GPS users (laptop or PND) are unaware of Navteq's role, much less filing map feedback. I think you just got lucky that Navteq scheduled a drivethrough shortly after you moved in.

Navteq's scheduled drivethroughs are probably their biggest competitive advantage. In contrast, look at the sad state of Google Maps (nine months after they switched to Tele Atlas), or the open mapping project OpenStreetMap. User input simply isn't enough to get broad coverage of the road network.
Then there's the length of time for these mapping companies to even ACKNOWLEDGE receipt of submissions. I caught a typo on one of the park names here in town (Mackennan Park instead of McKennan Park) and reported it several weeks ago. The status is still at "We have received your report."
If it's Navteq, then you won't see any status updates until they do their next drivethrough. In addition, they appear to ignore POI reports entirely. Indeed, the POI data is overall of lower quality than the map data. I suspect they don't do any eyeball-verification, unlike the situation with road data where nothing goes in the database until one of their teams drives it.
As of today, I finally looked and the park name was corrected. I have long since lost the URL to my ticket so dunno if they found out on their own or what.
An example of a routing error in Streets 2010:

Request a "Fastest" route from New York, NY to Spencer, NY. Streets will propose a trip of 246.3 miles / 3:56, including a silly western detour and U-turn.

Request a "Shortest" route instead. Streets will propose a trip of 217.5 miles / 4:44.

Insert a stop at Candor, NY. The route will now be 215.7 miles / 3:32, which is both faster and shorter than either of the above.
Yes, AHR, it is unwise to rely unquestioning on Streets & Trips route calculations, if you have time to review. It is always a good idea to apply some human wisdom, as you have done.

But you do not have to change the route option to Shortest because that may introduce some other anomalies that are equally undesirable. If "visually" it looks like you should go through Candor, insert a Stop there and you will get a satisfactory result. Or click and drag the route to something that makes more sense than the calculated route.
laptopgpsworld.com About