Data for many 'Avenues' missing in Streets & Trips 2008
I have found a problem in Microsoft Streets and Trips 2008 that did not exist in earlier versions - it can't find addresses on many "avenues".

In the Find Address box type "Regent Ave, Winnipeg" and click ok. The best Streets and Trips 2008 can find is a Regentview Drive in Brampton, ON. Try again with 1364 Regent Ave and Winnipeg and you get the same result. But search for "Saturn of Regent" and you'll find that its at 1364 Regent Ave in Winnipeg and the program can find that on the map. The problem appears to affect some but not all "avenues". For example it can find Wolseley Ave but not Alfred Ave, both real streets but in different Winnipeg neighborhoods. I found examples in Victoria, Edmonton and Ottawa too. None so far in the US but I only looked at a couple of places.

A quick test is to click on an avenue and if a street number isn't displayed then there is a problem. Streets, roads, crescents, drives don't seem to be affected. At least not the ones I tried.

It makes S&T 2008 pretty much useless if you use it mostly to get an idea where a particular street address is and the street name is an "avenue"

Another probably related problem is that in areas where the program isn't able to find or display addresses on avenues, is will display imaginary addresses on the cross streets where there are no real addresses on the those streets because most properties front onto the avenues.

I have written to Microsoft but their response suggests that they may not have really understood the problem (even though I gave specific example) but they did suggest that "If the issue causes you to feel that the product is of less use to you, please call the Microsoft Refund Desk at 1-888-673-8624 for refund options & please refer to the same case number." So perhaps they do recognize that there is a problem.

George M
I don't want to sound cynical about MS cust service but the C/S rep you were dealing with may live in an area of the world where avenues of the type you mean are unknown. There may be a language problem as well, it's possible the english language is only used at work.
I had a nagging problem with MS XP that went on for two years and numerous e-mails back and forth. I never did get the feeling that they understood what I was talking about.
I never did get a solution through that avenue( oops there's that word again).
Finally a solution appeared on the MS web site.

Marvin Hlavac

The above picture illustrates the issue. The search only works if you omit the word "Ave" from your search query. This seems to be a new issue related to the new Microsoft Streets and Trips 2008 version of the product, as I haven't heard users mentioning this specific problem before. Also, this appears to be related to Canadian addresses only. I tested it briefly with a few US addresses, but I couldn't reproduce the issue. I've heard from about 5 users about this issue, and they were all Canadians.

I've forwarded info about this to the product team, just in case they haven't yet been made aware of it.
This certainly improves the usefulness Streets and Trips 2008 but it leaves the problem of not being able to get idea of a street address by clicking on the street - if the street is one of the affected avenues.

The weird part of all this is that the problem only affects some avenues. You can get an address by clicking on Bannerman Avenue in north Winnipeg but not on its immediate neighbors or the other avenues in the area.
Ken in Regina
Hi Marvin,

The problem is not unique to Streets & Trips. I think it's more likely a problem with Navteq's data. I have the same problem in Garmin's City Navigator North America product which is also based on Navteq data.

I used City Navigator North America to do the "ernest ave" test that you used to illustrate the problem and I got the same results. Type "ernest ave" and no hit. Type "ernest" and the ernest ave entry is there.

Actually it's more interesting than that. Using Mapsource on the PC to do the search, as I type the search argument I have a window displaying results in real time as I type. "ernest ave" shows in the list as soon as I have typed "ernes" and stays there as I type "ernest". As soon as I type the space character to start typing "ernest ave" it disappears from the list.

For the record, in the Garmin product I've also run into the problem with other designations such as "st" and "road" and such. So I'll bet that it also exists in Streets and Trips.

I know that doesn't solve the problem, but hopefully it points the finger in the right direction -> Navteq, not Microsoft.

Marvin Hlavac
Thanks Ken. I just sent another message to the product group (including a link to this thread). I pointed them to your theory.

Did you experience this issue in earlier versions of Garmin software, too? This seems to be new in Streets & Trips 2008.
Ken in Regina
Originally Posted by Marvin Hlavac
Did you experience this issue in earlier versions of Garmin software, too?
Hi Marvin,

First a detail. It's not a problem in the nav software, as far as I know. That's an important distinction. Perhaps because Garmin sells map products seperately from their nav hardware and software it is easier for me to make the distinction between maps as a seperate product from the nav software. Eg. I can buy an upgrade to a completely new set of map data for my Garmin iQue 3600 without buying a new iQue 3600 or an update to its nav software. Conversely, I can get an update to the nav software without buying new maps.

To answer the question I think you wanted to ask, Yes, the Garmin map products that are based on Navteq data have had similar types of problems for as long as I've had my Garmin GPS (4 1/2 years).

I did a further check and I have determined that the specific "ernest ave" problem also exists in Garmin's Metroguide Canada map product, which is built on data provided by DMTI, not Navteq.

I also did the "regent ave" test from George's original post and was able to duplicate George's results with S&T 2008 (Navteq), Garmin Mapsource searching City Navigator North America v8 (Navteq) and Metroguide Canada v4 (DMTI).

I checked both addresses in an older Garmin/Navteq product, City Select North America v5, which is a precursor to the City Navigator product. This product is five years old so that makes the data closer to seven years old. I get the same results for both addresses, with one small exception. When I type in the full "regent ave" search I don't get "regent ave" but I do get a "regents ave".

Finally, I did both the "ernest ave" and "regent ave" tests with both Garmin map products (CNNA v8 and MG Canada v4) on my iQue 3600 and duplicated the results there as well. (This matters because the search software is different again from S&T or Mapsource but the underlying map data would appear to be from the same ultimate source).

So it appears that the root problem may be in the data created by some urban authorities, in this case the cities of Winnipeg and Toronto, when they enter their civic address information. This is the data that would be acquired from cities and towns by any map-making company like Navteq, TeleAtlas, DMTI, etc.

Again, it doesn't solve the problem but I hope it at least contributes to a better understanding of the possible root of the problem and why it is so difficult for the nav vendors (MS, Garmin, etc.) to have fixed. It's not a problem of their making so they can't fix it themselves.

In this particular case it's quite likely the problem is not even a problem of the map data providers (Navteq, et al). It looks like it is a problem created by the people who originally input the data (whoever does the geomatics work for, in this case, the cities of Winnipeg and Toronto.). And it might only be repairable at that level.

At the end of the day, your solution is the easiest. Just get into the habit of never putting in "ave", "st", "road", whatever. That's what we Garmin users have been doing for years.

Marvin Hlavac
Ken, I would suspect the map data was to blame if this was a brand new issue observed also in other Navteq-based products. But you are describing a behavior that has been the same in several versions of Garmin products. In previous Streets & Trips users didn't experience this. This issue is new to the 2008 version of Streets and Trips. I just double checked it with Streets and Trips 2007 - that version works just fine as far as this new issue... So I would still suspect the Streets and Trips software itself (not map data).
Ken in Regina
Or it's something that got left out of Microsoft Streets and Trips 2008. Eg. They previously had a workaround for the underlying problem in the data and didn't include it this time?

In any case, feel free to forward anything to the development team if you think the additional info will help resolve it in S&T. Clearly there's nothing going to happen with the Garmin stuff because it has been there forever.

I'm glad I found this thread as I've had the exact same problem as everyone described here (I'm in Winnipeg and MS S&Ts couldn't find my house if I added "Ave"). Thanks for the "solution" but since there doesn't seem to be a problem with US addrfesses as well as some Canadian addresses there is obviously a problem.

I contacted MS to tell them there is a problem with this product and after a number of emails and phone calls they finally told me there is no problem as it "was designed this way"!! I couldn't believe what they told me. I told them it was a flaw and they should provide a fix or send me a copy of Microsoft Streets and Trips 2009 for free as there is a flaw in 2008. That is when they said it was designed that way! Wow, that is amazing.

I guess when you're that big 1 complaining customer makes no difference!
Marvin Hlavac
Hi Gordo,

:welcome: to Laptop GPS World.

I brought this issue to their attention as well. That's all we can do. Now let's hope this problem will be fixed in the new version of Microsoft Streets and Trips 2009.
We did have a problem with the AVE and BLVD find for Canadian addresses in S&T 2008. But this has been fixed in S&T 2009. I picked some addresses with AVE from this thread and did a search in S&T 2009 and they are findable. The addresses I used are given below,

Regent Ave W, Winnipeg, MB
1364 Regent Ave W, Winnipeg, MB
100 Ernest Ave, Toronto, ON
Marvin Hlavac
Hi Gladwin,

:welcome: to Laptop GPS World.

That is excellent news! Another issue that has been addressed by the upcoming Microsoft Streets and Trips 2009.

I'm happy the problem has been fixed (I guess it wasn't designed this way!), but what about those of us who have purchased a flawed product? We should have a fix or a free copy of 2009, should we not?

Can I contact MS again and quote you that it has been "fixed", that it was, despite what the MS representative said, a flaw in the 2008 version?
Being the newbie to this forum, I was interested in this particular thread for two reasons. I have used Streets & Trips since 2001 and I am webmaster for our school's transportation information web. A few years ago I worked with our tech dept to develop a street search engine that parents and schools could use to look up streets in our school district and find out what bus, if any, would serve that area. An immediate problem we found was that, depending on which map used, some roads use extensions such as Street, Avenue, Court, Lane, Road, etc interchangeably. If a person had lived here all their lives they may call a road by one name or extension while newer folk (and maps) would use another. It created less problems to limit the search criteria to only the street name or even the first two or three letters of the name and not allow use of extensions at all. This simplification reduced the problems you described which refused to show a result because of too much information in the search input. Yes, it is frustrating but it is very probably the same reason that Streets and Trips was set up that way. I have maps from various sources that will show different names and extensions for the same streets. If you use the wrong look up source you will get the wrong, or no, results. So it may not have been a mistake or even an oversight but an over simplification that was intentionally designed for S&T. Unfortunately it is also an aggravation to users who simply want to offer more search info than necessary in order to reduce query results to a narrower return. If there is a discrepancy between say a taxing appraisal district's ESRI map and local mapping entities because of new land developments with same names but different extensions and you enter an extension that is or has changed then you will get limited, wrong or no result. Thus, even if you know the proper current street designation you would still be wise not to enter too much search information and pick from the assorted returns for what that mapping authority considers the correct name for your street.
laptopgpsworld.com About