Exploring Local
Mike Dobson of TeleMapics on Local Search and All Things Geospatial

More on NAVTEQ, ADAS and MPE (Part 3 of 3)

October 15th, 2008 by MDob

(This blog is the continuation of my review of NAVTEQ’s press release on MPE. I spoke with Bob Denaro (NAVTEQ’s Vice President of ADAS) for details on the release and the essence of his comments are included in the reported below. I realize the blog is quite long, I guess I did not pace myself to end it in 3 segments – but really, publishing part 4 of 3 would have looked quite silly.)

Is NAVTEQ’s ADAS strategy still focused on a limited road class solution (only categories 1 and 2)?

Bob Denaro (NAVTEQ vice president of ADAS) indicated that NAVTEQ designed the MPE solution to include road classes 1–4 and possibly 1-5 depending on application requirements. It is likely that many ADAS applications will only need road classes 1-4, but category 5 roads might be needed for map matching.

Detailed specifications for the accuracy of road data in the MPE-map database include 1-meter relative horizontal (point to point) and 5-meter absolute horizontal, with the vertical error being better than 1% of the distance traveled (rise/run). Bob explained that NAVTEQ’s unique post-processing algorithms are a very important part of improving the accuracy of the MPE data.

It is my understanding that the planimetric data accuracy specification for NAVTEQ’s navigation database (a less demanding application than ADAS) is 5-meters relative (horizontal) and 15-meters absolute (NAVTEQ did not confirm this specification). The change in specification to meet the Company’s ADAS accuracy requirement for map data is significant in terms of its influence on level of effort, compilation methods, and processing. At present, NAVTEQ has finalized the ADAS specified data for road classes 1-2 and Bob told me that the data for road classes 3 and 4 are rolling out now.

I was somewhat surprised that the geometry of NAVTEQ’s MPE map data specification was not aimed at a higher level of accuracy, but presume that this measure meets the need of their customers for map-enhanced ADAS applications.

When I asked about the difficulty of capturing road data at the desired level of accuracy over large coverage areas, Bob indicated this issue had received considerable attention from NAVTEQ. He continued by explaining that some of their map data may not meet the NAVTEQ MPE specification. In order to provide for this possibility, NAVTEQ has placed a flag (attribute) on every link in the MPE map database indicating whether the point meets the NAVTEQ accuracy standard for MPE. Bob continued by noting that querying this attribute would allow the application software to decide if, when and how the map data would be used to support its functionality.

My perspective is that the inclusion of vehicle safety features that work some of the time and fail to operate appropriately at other times due to inadequate data appears a significant problem. I realize that no spatial database can be perfect, but the ADAS venue may cause us to ask different questions about the quality and comprehensiveness of map databases than we have needed to ask in the past.

It is my opinion that the issue of error handling and reporting in ADAS map databases is a major problem that continues to plague the industry and one that may delay the rollout of map-based ADAS applications.

The navigation applications of the past had relatively loose accuracy requirements, since the map data were considered true and map matching simply placed the vehicle’s location on the most likely position of the most likely road in the database. Whether the geometry of a curve was correctly positioned was relatively unimportant, certainly it was of lesser importance than geocoding, at least for most routing and finding applications. In ADAS, however, the map data are being put to more stringent and critical uses than ever before. Calculating curve speed warnings, for example, requires that you know the location of the vehicle, the exact shape and position of the curve, and associated variables that could make the solution more robust (passing lanes, number of lanes, width of lanes, slope, curvature, etc.).

One has to wonder how successful ADAS-compliant map data will be in view of the rigorous need of the applications for consistently accurate data. In addition, it is likely that the problems could be even more significant for map data gathered under the previous navigation standard and retrofitted for ADAS applications. While it is a reasonable precaution to provide a measure of whether an individual data point is robust enough to support the application, how does one describe the effective usability of an ADAS database compiled across large spatial coverages in a meaningful manner?

An example of this problem is the likelihood that the accuracy of most of today’s navigation databases is weaker in rural areas than in urban areas. Unfortunately, approximately 75% of the road lanes in the United States are in rural areas and it is these road lanes that exhibit an unusually high density of accidents. If ADAS is ever going to realize its promise for enhancing road safety, then improving the accuracy of the geometry and attributes describing rural roads is necessary.

In addition, it is likely that the greatest source of error in today’s navigation databases is related to attributes and geometry for local streets and local roads, not in the national and state road type of category. Unfortunately, if we look at the dispersion of these categories across the world (see below – I realize the legend does not fit worldwide) we can see that most of the roads fall in the local street/road category. If the industry has not able to resolve the accuracy problem for streets and local roads for navigation databases, what type of effort will be required to solve this problem in respect to ADAS-compliant databases?

Road classes worldwide

Well, that’s enough melodrama from me. Let’s move on.

The usefulness of data warning flags, figures of merit and other measures of goodness of fit applied to map databases have yet to play out in ADAS applications. While every industry player will continue to update and extend their ADAS databases to eliminate “inferior data”, updating map databases is a game of “Whack-A-Mole” that never concludes. I think we will have to think through this issue in a future blog, but for now, let’s just note that it remains an important, unresolved issue for the industry.

The NAVTEQ press release indicated that the MPE map database would include ADAS geometry and precise ADAS attributes. I asked Bob what some of these precise ADAS attributes were and he allowed that these attributes could include speed limits, curve value, slope, land count, lane markings, exit ramp locations, locations of stop lights, stop signs and other data. Bob continued “… NAVTEQ is working on collecting lane widths and bank angle (for roll over warning).

If you are interested in what else might be “in there”, I suggest you take a close look at NAVTEQ’s two patents related to the system of providing an electronic horizon that were referred to in the press release but were not identified (Adrian Paul of NAVTEQ graciously provided me the patent identifiers). The second patent is a continuation of the first (an option that allows one to add relevant claims to the original patent). The earlier patent is 6,405,128 and the continuation is 6,735,515 (the links I have provided are to Google’s excellent “patent finder”).

Although I think you will find both patents interesting, my focus here is on Figures 3A and 3B (the same in both patents), which are shown below. The images are quite small, so click here for a larger version of 3A and here for a larger version of 3B . The caption for these figures provided in the patent is as follows: “Figs. 3A and 3B show the types of data contained in the map database component of the advanced driver assistance systems map data architecture.”

Figure 3a from the NAVTEQ ehorizon patent

Figure 3b from the NAVTEQ ehorizon patents

Although it is clear that the core ADAS data are the accurate position and height information of roadways, the figures/illustrations in the NAVTEQ patents and Bob Denaro’s comments seem to show that the company is thinking and, perhaps compiling other types of data that could extend the MPE strategy. While the addition of these new types of data with enhanced position and elevation data may provide a natural market advantage to the company, I shudder to think of the cost.

Certainly, NAVTEQ has the problem of creating an ADAS map database in its headlights, as does Intermap. Unfortunately, I do not know the status of these developments at TomTom/TeleAtlas. Anyone there up for an interview?

As I noted in my last blog, I am headed for Germany tomorrow and will be there for the rest of the month. Some of my travel is professional work (consulting) and some is related to my other business – www.ThereArePlaces.com.

I’ll blog if I can and have a couple of interesting topics to discuss with you.

Finally, I wanted to thank Bob Denaro, NAVTEQ Vice President of ADAS for speaking with me on the MPE press release.

Best regards,

Mike

Bookmark and Share

Posted in ADAS, Intermap, Mapping, Navteq, TeleAtlas


(comments are closed).