We are in the process of turning on new map tiles for API sites. The map tiles are built from Tele Atlas data in the US (the same vector data used in Google Earth) rather than Navteq data. This should be a relatively transparent change on your sites, but we are eager to hear any issues you have with data quality and/or the tiles themselves, which should be identical in terms of design.
The tiles have not changed in the rest of the world, including the UK and Japan.
I've had several users complain that mapping data is older now than it was before, and they're correct. (See comparison links below.)
Why did you stop using the Navteq data, can we go back to it? It's clearly superior to the TeleAtlas data. Is this related to the street lines now being missing from the hybrid maps too?
I posted a while ago about areas of the UK that are incorrectly portrayed as underwater. You might want to look at doing something about that, as I'm running out of oxygen.
also - looks like there is an error there in the new maps in the general area (luck?), if you zoom in one step the tiles are missing, but then you zoom in one again they are there.
paul.deg...@gmail.com wrote:
>I've had several users complain that mapping data is older now than it
>was before, and they're correct. (See comparison links below.)
>Why did you stop using the Navteq data, can we go back to it? It's
>clearly superior to the TeleAtlas data. Is this related to the street
>lines now being missing from the hybrid maps too?
Just a question... If the new mapping data that is being turned on for API sites is older than the NavTeq data, is this the step for Google to introduce a premium or commercial API? A pay model which includes the most up to date mapping info as opposed to the free model with older satellite and mapping tiles?
This could be the only logical step as to why Google would replace current data (NavTeq) with older TeleAtlas data. Thoughts?
Bret, can you please create an official Google Maps API Blog or a read-only 2nd group for official Google announcements and communication? This group is too high volume for many developers to stay on top of. I mostly search it but stumbled upon this note.
Hi Bret, thanks for the post, it's great to see google communicating. I'd like to second Mike Orb's suggestions, important announcements could easily be missed in this busy group.
Mike if you use a email client to read this maillist, you can easily set up a filter to look for posts by Bret and Pasha and flag them or create alerts or however it is you like to be notified.
The Tele Atlas data seems older and more error-prone as others have noted. What could the reason be to change the API maps to older data while leaving the google maps with newer? It's a retrograde step, which is "anti-Google" by definition. Bret - why?? John
One little trick I just tried -- I only did it earlier today, so I don't really know if it'll work well or not -- set yourself up a google alert with the search terms:
True, but what if someone else posts? Pasha? Another google employee? Set up the filter for @google.com addresses? And if I filter through mail user agent X but am on Web client Y then what? I don't subscribe to many mailing lists because of this.
I'm not trying to be difficult, but I think the complexity and scope of Google Maps API combined with the high traffic of this group merits a separate channel for official communication.
and to address Mike's frustration further down, the Google Map group defnately needs to get a user name for important announcements so we are not confused about looking for announcements from a variety of people, Pasha, Bret, ?, ? - one official announcement user name please.
How about cross posting this same update on the API website? Just place a post in this group and put the same update on the API page. Give a link from the API page to the discussion thread here so the change can be discussed. This way the API page is a once stop place for official announcements and we can come here to give our ideas or problems we come across. Probably the best idea with the current setup.
Tony wrote: > How about cross posting this same update on the API website? Just > place a post in this group and put the same update on the API page.
Google owns Blogger. An official blog is trivial w/ last X posts summarized on the API home page. Slam dunk that would take the talented Google developers minutes. If you want this folks, reply and support the general concept. I'm sure Google has hundreds of things they can do that are easy, and it is just a matter of prioritizing these hundreds of "easy" tasks :-).
Bret Taylor wrote: > ...we are eager to hear any issues you have with data quality and/or > the tiles themselves, which should be identical in terms of design.
Bret, comparing the 2 just within a mile of my house.. the NAVTEQ data has new streets built 2 years ago that Tele Atlas does not. Additionally, Tele Atlas shows a non-existant street that branches off an existing street and goes right through an existing house then up a mountain (in other words, false data).
Bottom line, in my eyes the change to Tele Atlas is a bad change.
Bret, as you can see the response is pretty much unanimous that this was not a good change. It's a particular bummer for me since my site got mentioned on an email newsletter with pretty high distribution, of all days, yesterday, so all those new users came in seeing old map data.
What I'd like to know is: why did google make the change, and more importantly is there any chance of it being rolled back? I could see this being somehow related to haggling over the use rights of the different data sets, and perhaps some pointy-headed lawyer just came to the decision that the API sites are not eligible to use the good data.
I'm not asking for proprietary business intelligence here, just give us a hint -- is this something that has a chance of being corrected, or is this something we're stuck with?
Navteq data in general is much better than Tele Atlas/GDT data and that's the reason why Navteq data is used in most, if not all in-car navigation systems for street level maps.
If I have to bet, the switch is due to money issue. Technically Google can release their geocoding and driving direction APIs if they want to or have to, if the competitions pressure on. If that happens Navteq will surely ask for lots of money.
I am hoping Google can work out a deal with Navteq. I do not mind, actually I hope Google would release commercial subscriptions which allow me to use Navteq data and avoid ads. I tested out Google Maps with a few of my large projects but refuse to go to the full implementation precisely because of fears of uncertainty. The switch from Navteq is sadly, somewhat anticipated.
I am hoping the Google Team would do a better job in communication. Personally I will NOT invest more in Google Map until I see a clear product/service roadmap.
Hmmm....the Google Maps Dev Group is clearly having a bad press cycle right now. LOL
But seriously, this is the second change this week causing a good deal of consternation among the devoted. There was better communication at first on this one, a heads up announcement, that was great. But now there has been no follow up explinations given. And this is the first major change which effects the quality of the product in a negative way. One would expect there to be more reassurances to developers during a change negatively effecting the product...especially the first time it happens.
While we can read and understand the literal meaning of the TOU's reserve clause "we can change this puppy any time without notice", the communication here is not exactly breading confidence for future changes.
Here's an issue that may be related to the change of Navteq data to
Tele Atlas data:
We started experiencing a problem yesterday (October 5, 2005) in that
IE no longer displays state borders/boundaries when in hybrid mode. It
could be that the tiles are still there, but IE is just having a
layering problem. The borders show up fine in firefox. This is
definitely a new issue. IE worked fine on October 4th. Did the change
of Navteq data to Tele Atlas data somehow cause this?
Don't send anything personal, but if you find specific locations, I am
really interested in the lat/lngs of areas that have incorrect data. Please send them my way. Without the specific region or lat/lng, it
is difficult for us to follow up with our data providers.
We are looking into this now. The change is not related to the
underlying data, but another IE PNG issue. We will have an update out
this weekend to fix the problem.
Asking users to submit areas of problems is NOT the way to go. If most people actually DO submit, your inbox will run out of space very quickly.
The quality difference between TeleAtlas/GDT and Navteq is KNOWN in the industry. Whoever at Google dealing with data providers should talk to a few GIS/mapping data experts, if they have not already done so. Go back to your business guys to beat on them.
Fundamentally bulk of GDT data came from original TIGER, which was really bad. GDT did as much as they could to "enhance" the data, but they NEVER enjoy the same prestige as Navteq data. You get what you pay for.
Bret, thanks for the update and the top priority to get this fixed. As I am sure you are aware, the state names in the hybrid maps also look jagged on their edges in IE.
And here is one other issue that may be related to your recent release: There is a content filtering software we use, provided by contentwatch.com, that is making any Google map very slow (1-3 minutes) to load. Last week, the load was a little bit slow (maybe 10 seconds) but this week, any computer with this software is loading the maps slow, as opposed to last week, when things were relatively fine. The contentwatch people tell us that it is something related to CSS/DOM and their software's ability to parse it efficiently. Something major must have changed in these recent map releases...
