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.

Ed

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.

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.

...ken...

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.

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.

...ken...

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).

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.

...ken...

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!

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

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.

I agree with you Mr Fixit, however when I entered "too much" information as you have described, it should still find the location I have entered. When I entered my full address (i.e., including "Ave.") it could NOT locate my home. If I only entered my street name without the Ave it could locate it. The search parameters are more inclusive when entering only a partial address, which is a good thing, however when entering a complete address it SHOULD find it!

Well, only if you enter that full address exactly the way it is stored in the database. And that's the risk. If you enter "avenue" and the city planners submitted the data as "ave", or vice versa, you're going to get it wrong.

I have been using Garmin maps for years and they are better than S&T2008, but they still have the same issue. I have long been in the habit of leaving off the street designation and only using the number and name. I would rather have to pick my result from a bit larger list than not get a hit because I didn't have a mindmeld with the person who entered the data.

...ken...

I am using 2010 version, and still have the sample issue! I could not even find my home address. If Ken is right, the problem is caused by Navteq then which PC based GPS software is not using their data?

Delorme uses their own data and others may use TeleAtlas but none we list here. Navteq is still the best mapping data supplier for North America though.

Terry

When you say you still have the "sample issue", does that mean you have verified that your address is in the map database by using a less specific search, e.g. without the street/avenue designation, as in the original post?

Or have you verified that your address is missing completely?

You can verify independently by floating the cursor over the block you live on and see if your house number shows up.

You can verify exactly what to search for for your own address by clicking on the street in front of your house and see what displays for the street name.

...ken...

Hi Ken,

I think at least in some cases the address is completely missing. I will do more verification to see.

Thanks
Hardy

Ken,

I tried, and when I hover mouse over, I could not get the house number and nothing to display at all..

I also tried some address in States and it works.

I'm a little confused now. I thought you were trying to do this in the United States with City Navigator North America 2010.

Can you please confirm which Garmin map product you are using, which country and state/province you are having the problem in?

Is there a street displayed where you are having the problem? That is, is there a line that looks like other streets? What happens when you hover the hand icon over it? Does it display something like the word "road" or anything like that?

...ken...

It thought we were discussing Streets & Trips 2010. If you don't live in North America or Puerto Rico, you are using the wrong product!

Terry

Ooops, my bad .. I meant to say Streets&Trips 2010, not City Navigator. But it's pretty much the same data in both.

Hovering the arrow cursor over a street won't do anything in Streets&Trips. Again, my mistake. You need to click on a street to get an address to display. If you click in the middle of a street, you might only get the street name to display so you might need to click on the edge of the street to get a house number and street name to display. If you click at an intersection you might get a popup with multiple addresses in it.

I'm sorry about the confusion I might have caused.

...ken...

Ken,

I tried to click on street, or right beside street and nothing happened (my address in Toronto, Ontario). I did same thing to some of the streets in states and it worked.

If clicking on a street doesn't result in you seeing a pop-up with an address, it may be an indication the street has no other data associated with it yet (usually a brand new street).

Hi Marvin,

My house number exists for more than 30 years, I don't think it is new.

Hardy

Hardy, could you give us a sample street name(s) which doesn't give you address when you click?

Marvin,

300 Bridletowne Circle, Toronto, ON is found in Bing map, but not in Streets & Trips 2010.

Hardy

Hardy, that address works just fine on my computer. Are you by any chance using a non-English version of Windows? I recall a user about a year or two ago, who also had an issue with Canadian addresses, later discovered the issue was related to his non-English version of Windows. I think I could find the thread around here for you, as I believe there was a solution to it, just let us know if this could help.

You are right, I am running non-English Windows.

But I could not find any language selection from Streets and Trips menu.

The address search just works fine to get US addresses.

I had no problem finding 300 Bridletowne. You are probably entering too much information or you are searching in the US.

Terry

Attached Images

Bridletowne.jpg (204.0 KB)

Thanks Terry,

I am pretty sure I have searched in Canada only.

Hardy

Marvin probably has the right answer. I was not aware of that issue.

Terry

Here is the thread that links to the unicode issue. I guess it isn't fixed yet!

Unable to search some addresses in Streets and Trips 2009, 2010

Terry

[Ooops, I missed Marvin's and Terry's messages so if this is no longer relevant please ignore it.]

I found your problem. You need to change the country in the FIND dialog window. The reason it works in the States is because the default country in Streets&Trips search function is United States.

See the attached picture.

...ken...

Attached Images

bridletown circle address.jpg (42.0 KB)