Streets & Trips 2009 Routing Errors

Linechaser said:
Unfortunatly you are correct. The avoid yellow zone technic is not always working all the time when you need it as we can see in the example i have given above. Only the manually added stop at a strategic point to force the routing, safe me in the illustrated case i have given

Ken: Interesting route. At any rate, I only use S&T to get a good idea of the route I want to take. I have never printed out the final product, since I prefer to just transcribe the route between stops (since I am pretty familiar with central ND; having grown up there). I did get bit by another routing bug when developing a side trip north from Bottineau, ND through the Lake Metigoshe area and which was all the more infuriating since I know that area well to say the least. It is good to know that I'm not alone with these glitches and my "forced" stop approach is the better of the two workarounds.

In real life I rarely use the GPS for long distance routing. I travel for fun, not business. So I travel in one of two modes. One, is that I'm going to visit family or friends or go to a favorite vacation spot. No need for routing .. been there lots of times.

The other is going somewhere we've never been. Or somewhere we've been but we want to take a different route. In either of these situations, I fire up the map on the screen to see what roads - major and minor - exist between here and there. Then I look at what "places" exist along those various roads that might be of interest.

Once we have an idea of the various things that might interest us between here and there, we do some more detailed research into some of the places to be sure we will be interested. The "route" we want to follow will usually become pretty obvious by the things we want to see.

This is the point where the routing of laptop/PC nav software becomes useful. I get the software to calculate the distance and driving times between here and there via the various places we want to see (I use MapSource so this is literally a quick point/click exercise). This allows us to do our planning for overnight stops along the way so we'll know where to book hotels, if we decide to book them in advance.

We don't get the opportunity to do trips like this more than once or twice a year. So, while this is important use of the routing features, it's not very frequently used.

My most frequent use of routing is if I'm in a large, unfamiliar city and I need to get to an address or POI (my wife considers Ikea to be a POI ). In these situations I'm only looking for a way to get there without getting lost. I really don't care that a local could probably find a shorter/faster way to get there. The efficiency of the route is of little concern to me in these situations.

...ken...

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.

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.

...ken...

Attached Thumbnails

 

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:

http://mapreporter.navteq.com

...ken...

Attached Thumbnails

 

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.