[nycspaces.]

Running original release OS 10.0.9.2372 and dismayed about the poor quality of the mapping. It's not just bb maps coming up short but a total fail in the mapping of contacts. This is a major step backward in an area where RIM had worked out the logic almost flawlessly in OS7. More than 75% of the time in OS 10 when clicking on a contact's address the link to bb maps takes you to an incorrect address or location.

In OS 7 it is a sub/full menu option, that one has to find in the menu, but selecting "view Work on map" or even more importantly "Show on Google Maps" nails the location for almost every contact of my 2,900+/- contacts on the device.

In OS 10 more than half, i would venture to say 3/4, of the contacts i have tested find the completely wrong address. Not just the wrong location on the map by a few blocks or something off. Completely wrong addresses, often the wrong version of a similar street name in another section of New York or even in the wrong city completely.

Why this is infuriating is because the SAME contact information on OS 7 works while on OS 10 it is working incorrectly, it even works correctly on PB 2.1.0.1526 with Bing.

For an example:

Selecting on OS 7 and PB my contact with offices at 777 Third Ave nails the location. The exact same contact on OS 10 opens bb maps and indicates 777 Sixth Ave. (WHY?) One issue may be that i am located very close to the 777 6th Ave address and there is some kind of broken logic that assumes i am looking for something close but this does not make sense. It may also be that os 10 bb maps is trying to hard and not running the same logic checks it used in prior OS's (lack of finish) or possibly a QNX legacy issue as entering mapping data on a gps is so counter intuitive compared to modern mapping tech like google maps on a desktop or android or even bb7.

Another contact has a 200 Park Ave S address, this is pretty standard short hand for Park Avenue South. On OS 7 BB maps and Goog it works and PB/Bing works, OS 10 it is a total fail and finds 200 Park Avenue in Brooklyn NY, several miles away from the correct location found in earlier OS's and not even in the same zip code or Borough of the city as in the contact record. An expected error might have been it would have found 200 Park Avenue in Manhattan, same city, different zip, but it would almost make sense that it's missing the abbreviated "S" for South. Hey i have even showed up at the wrong 200 Park for a meeting once (you see why i need a good mapping program). If this was gps or proximity related fault it would more like have found the 200 Park Ave address as i am within a mile of that location so the earlier 777 6th Ave example is likely not a proximity issue. It seems that OS 10 is not using the correct logic to use the ZIP to differentiate the correct address searches before doing the refined address search.

A simple Map search on Google, correctly starts returning the various 200 Park options after entering "200 P" into the search (200 Park Ave S, New York, NY / 200 Park Avenue, Hoboken, NJ / Metlife Building, New York, NY / 200 Park Avenue, New York, NY / and several other potentially correct options including the 200 Park Avenue, Brooklyn, NY). While i would hope RIM was shooting to out-class the competition, i would not expect it to match up with Google maps but i definitely expect it to preform at the same or better level than the last 2 OS's developed by BlackBerry. Why deliver this broken after all this time.

The times the address look up fails in OS 7 with BB maps it almost ALWAYS works with Google maps, similarly challenging addresses (often with Floor or Suite numbers) seem to choke the old bb maps function but seemed to work in PB/Bing almost as well as Google maps.

Sorry for the long post but hopefully someone at BBRY can use this information to raise these problems to their bug or issues tracking for future releases.

Anybody getting better results in big cities with multiple street names in close proximity.