Many of the companies now collecting spatial data to support the development of autonomous and semi-autonomous vehicles appear to be evolving their approach to match sentiments espoused in Nineteenth century literature where Mein Herr, a character in Lewis Carrol’s story “Sylvie and Bruno Concluded” (1893), said, “And then came the grandest idea of all! We actually made a map of the country, on the scale of a mile to the mile!”
“Have you used it much?” I enquired.”
“It has never been spread out, yet,” said Mein Herr: “the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.” (Footnote 1)
In today’s world of proprietary database building numerous companies are imaging the environment in both archival and real-time modes. The purpose is to create highly accurate spatial databases of the environment that can be used to support the operation of autonomous vehicles. Conversely, the industry might be better off building one common spatial database, or by instrumenting our roads, streets and associated “road furniture” than by creating multiple representations of the same thing. Unfortunately, the decision by major players to make spatial data one of their monetizable, competitive advantages bodes poorly for a common spatial database or a smart transportation infrastructure to support the operation of autonomous vehicles.
Is Multiple Representation Really a Problem?
Yes! Many companies are building proprietary master spatial databases to support their interests in autonomous vehicles. In addition their vehicles are creating real-time positional databases. If one could merge of the data from these efforts and map/overlay them, do you suppose the data for geographical positions would precisely align? How about comparing spatial databases created by different parties? The sad state of affairs is that it might be impossible to meaningfully integrate these multiple representations of the same data due to differences in collection technologies, methods, measurement, classification, design, and a host of other variables. Comparing the “rightness” of one representation of reality to another can be a very difficult task. Let’s take a look.
Guess we should take a step back for some perspective
Compiling spatial data to support vehicle navigation is based on a long and illustrious history of innovating techniques and methods to deal with the issues of capturing, storing, handling, and using attributes critical for representing identified transportation arteries and their surround. Although we might now smile at some of the resulting products, such as pocket globes, wall maps, folded maps, road atlases, auto-photo-guides that showed a photo at every intersection between an origin and destination, and TripTiks, these and other displays were based on spatial data compilations systems that once helped solve the navigation problems of the traveling public.
When digital spatial databases were developed to create “computerized” navigation, routing and presentation systems, established and mature methods of spatial data handling served to help create the modern tools required to build the database and rendering methods supporting these efforts. Many of these efforts were essentially data-driven systems replacing the previous conceptually-driven drawing methods that were focused on creating a map or some related form of spatial display. During these developments cartographers and spatial scientists met and began wrestling with the problems generated by multiple representations of the same geographic locations.
Tomorrow’s autonomous vehicles may provide, but will not require, visual map displays for their operation. Rather they will implement geographical data in a manner that can serve to provide the spatial information required for the autonomous vehicles to safely and reliably manage a vehicle’s operation without the intervention of a human pilot/driver.
An important consideration in this pursuit is that many companies seem prepared to rely on sensing or imaging the transportation networks and appear to imagine that by doing so on a global or regional basis, they may be able to solve the operational problems required to support the emergence of autonomous cars that will actually be “fit” for some intended use. It is important to note that not all data about the environment required for controlling and navigating autonomous vehicles are visible. For example, sirens that provide drivers information about not yet visible approaching service vehicles that legally have the right of way cannot be sensed by most imaging systems. Similarly postal codes, addresses in high rise office complexes, jurisdictional boundaries, some toponyms (place names), etc. often require diverse collection methods other than imaging from a road surface. The existence of these “escapees” from current sensor capabilities means that multiple spatial database (multiple representations) will need to be merged in order to provide the comprehensive view of the real world required to operate autonomous vehicles.
There are a host of spatial data issues that need to be addressed by those developing systems to guide the performance of autonomous vehicles. Today, I will cover three of these topics. We will get back to multiple representations, after we take a look at requirements.
The Importance of Setting Requirements for Spatial Data
Starting your development for an autonomous vehicle with, “We’ve got the know-how to make A and B and can create some of the spatial data for this system using the technologies C and D,” is not the useful approach to solving the problems the system might need to negotiate. For example, and in my opinion (see footnote 2), if Tesla’s Autopilot system could not: 1) sense a white semi-trailer with black tires sitting astride a road, 2) decide the object was not in its spatial database, 3) process it as a dangerous spatial exception, and 3) take evasive action, then specific performance and safety requirements may have been missed when planning the system. If the ranging capabilities of Tesla’s cameras and radar were not sufficient in respect to the distance over which it could observe navigation critical variables, or if its threat processing was not capable of informing its operating system that an action must be taken due to this fault (if sensed), then requirements were either missing or not met. Designing a system whose components do not solve common spatial problems or spatial threat situations even infrequently encountered by ordinary drivers is not a positive option for an industry that needs to convince its user base to have confidence in its products.
Purposeful, disciplined, comprehensive design documents for spatial data and its use will be required to build vehicles fit for autonomous functionality. I hope the industry is thinking about this challenge, as much as it is thinking about the race to market. Spatial data has not been something that the automotive industry has traditionally incorporated in its vehicle build process and, as a result, new challenges face those intent on competing in this market. I suggest the players who are considering building either autonomous vehicles or guardian angel types of applications for vehicles pay some attention to the following topic when considering the use of spatial data.
Multiple Representations – or – this data item is another representation of this geographical descriptor, except maybe when it doesn’t quite match or you can’t even decide if they are representing the same thing (Footnote 3)
At some point, there may only be one spatial database operating in or provided to an autonomous vehicle, but that time is not now. Today, we have companies using LIDAR, radar and optical sensing techniques to build highly precise master positional spatial databases for navigation that are attributed with additional information. The moving vehicle platform, itself, is creating a GPS path (perhaps INS based) of where the vehicle is being guided for purposes of matching its location with the master spatial database. When the highly precise positional spatial database is not spatially comprehensive other spatial databases are used to calculate: paths, travel time, congestion and similar information. Concurrently, the sensors with which a vehicle may be equipped, are also mapping a path along which the car is moving, recording such things as position, distance between vehicles, lane marker position, speed, and other variables that can be used to safely control the operation of the vehicle. It is in this sense that the spatial databases that are used in autonomous cars provide an example of the simultaneous use of multiple representations of the same geographical space – specifically along the path that the vehicle is currently traversing.
How dissimilar must the spatial data in the onboard/in-cloud master spatial database and that collected by the on-board sensors be before a fault is called? Which source is regarded as the failsafe and is it always considered the failsafe? What are the results of a fault being identified? While the sensors would seem to have the upper hand, what if they are not operating within required tolerances? How are these distinctions to be measured and prioritized during vehicle operation? If neither data source is regarded as optimal or reliable at a brief instant in time, how is the issue resolved to the benefit of the vehicle and its occupants? What is the fallback when a vehicle does not provide a steering wheel, brakes, or gearshift, but its autonomous system can no longer navigate the vehicle due to discrepancies in spatial data?
The question of when a reported deviation along a segment of a route becomes significant can be a complex issue. If the sensors on each vehicle encountering an actual change in a path are measuring the change compared with a proprietary spatial database, how will specific differences in these sources be reconciled? When do these differences become critical? Does vehicle speed sway and stance alter these evaluations? If differences in the reconciliation recommendations at a specific geographic location vary between vehicles by manufacturer due to differences in the requirements set for their proprietary spatial data, as well as the on-board methods of sensing the environment, what happens? How will emergency command and control decisions be prioritized and implemented in a rational manner?
When we get to the stage where autonomous vehicle control systems can speak to each other, what happens when they are impacted by sensed current data that reflect different images of reality and the geometry of a proprietary spatial databases that do not reconcile? For a variety of reasons static reconciliations (edits) are a common part of using spatial data, but it is when you add in the concept of multiple representations of potentially non-homogeneous spatial databases acting in concert to solve a problem that must be dynamically reconciled that your headache may suddenly become a migraine.
Then, add in consideration of the potential differences in the content, coverage and comprehensiveness of the various spatial databases that someone might be using to support the spatial data requirements for a typical autonomous vehicle. Another unfortunate fact dogging multiple representations of a spatial object is related to issues of data quality. Of course, the situation is complicated by the fact that few people understand how you might critically measure the data quality issue in potentially non-homogeneous spatial databases that will be used for purposes of autonomous vehicle operation.
Speaking of People
Where will the experience in spatial data collection and handling come from? Well, yes there are a lot of people who have always liked maps and even more who have used them. But the number of professionals steeped in the theory and practice of the use of spatial data handling for navigation and related issues is extremely small. My concern here is that the appropriate sensitivity to understanding the problems of integrating spatial data into on-demand, real-time systems may not be well understood by many of the developers of these systems.
Make no mistake – there are a number of people who are vaguely familiar with the notion of spatial data, yet appear markedly unfamiliar with the myriad problems of compiling, creating, handling and using spatial data in a manner that accurately reflects the limitations and advantages of the spatial databases they are building. If these people do not understand the problems or fitness-for-use posed by merged, multiple-sourced databases containing multiple representations of the same data, it is unlikely that the software they create to interrogate and use these spatial data are going to consistently and reliably perform their intended function in the support of autonomous navigation – or even in navigation efforts is aimed at performing a Guardian Angel type of support.
The Problem of Hubris
Yes, I know. All of the problems that I mentioned here have already been solved by brainiacs of untold wisdom. Yet I persist. Why? Well, I persist because the brainiacs have actually not yet solved these problems. Ask your development team what they are going to do about the multiple representations of spatial data. They will probably ask you what that means and then tell you they have already solved the problem.
Those of you who follow my blog know that I sounded an alarm when Apple announced it had started building a spatial database to support its need for an online mapping product to be released within the same year. In my blog I suggested that Apple was in for a surprise, as they clearly did not appreciate the difficulties of compiling a data base to be used for mapping and routing. Shortly after the Company released Apple Maps, I critiqued Apple for the product’s numerous failures, all of which were avoidable. As a matter of fact, the whole word seemed to criticize Apple’s inept attempt at creating a mapping product. In a recent article Apple executives admitted they originally failed in mapping because they did not understand the scope of the challenge. And so it goes.
I’m getting too old for this kind of stuff, so today’s blog marks a new focus on issues in spatial data handling that more people ought to think about before their efforts to build “functional autonomous vehicles” proves disastrous for the transportation industry. More next month.
Until next time.
Footnote 1. I used the same Sylvie and Bruno example in, “Silicon Valley Mapenings” an article focused on the interest in autonomous vehicles that was occurring in early 2015. The quote is an example of the gift that just keeps on giving.
Footnote 2. For obvious reasons Tesla has been reluctant to publicly comment in detail on the accidents experienced by its users. As a consequence, my statement is speculative and may not be borne out by the facts, if they are ever revealed. It may well be that some factors or factors unknown to me and unavailable in public literature (as of this date – 8/29/2016) related to these incidents will reveal that the company bore no fault in any manner in any these incidents (8/29/2016). I do note that today (8/30/2016) that Tesla announced an update to Autopilot that will significantly enhance the advanced processing of its radar signals.
Footnote 3. I briefly discussed multiple representations in several blogs, but most recently in “Comments on the Development of Spatial Databases to Support Autonomous Vehicles” .
Posted in Apple, autonomous vehicles, Categorization, Data Sources, Mapping, Mike Dobson, multiple representations of spatial data, routing and navigation, spatial databases for autonomous vehicles | 1 Comment »