Long before the term “geospatial” was introduced, distinct disciplines for field capture of spatial data were recognized - land surveying, topographic mapping, aerial surveying and mapping, bathymetry, to name a few. In reality (no pun intended), any of these field data acquisition disciplines, with the tools and methods employed, were capturing reality. Even early explorers using a variety of natural navigation techniques were mapping and capturing the reality of new lands. So, what is all the more recent buzz about the term reality capture (RC)? Is it an informal catch-all term for anything new and shiny, or a marketing term? No, it is a perfectly legit term that has been widely accepted by the global geospatial community, related industries, and professions.
But it wasn't always that way.
The term was used infrequently prior to the most recent decade. Presently, you hear it used often as a generic term for any form of mass spatial data capture, in contrast to the observation of discrete individual “points” that characterize more traditional forms of field surveying and mapping. There are many specific applications where conventional methods are absolutely essential. However, the advent of laser scanning, digital photogrammetry, and the ability to process and classify (increasingly with AI assistance) massive datasets brings a proximal richness that conventional methods could never deliver at scale.
RC encompasses any and all of the mass spatial data technologies and methods. The fruits thereof have enabled a flood of new, updated, and accelerated end-use applications—some that were impractical with legacy methods. It has even spawned a new type of practitioner, or at least a new moniker. Increasingly, we hear the term “reality capture specialist”, characterizing a broader group of practitioners. RC has opened access to the technology, methods, and automation to a much broader range of users. RC does not detract from or make moot the essential work of established disciplines; it has also added production-boosting capabilities to the toolboxes of skilled geomatics and geospatial practitioners.
One firm completely embraced the term and found that it fit a new and rapidly expanding operational and functional business unit. About five years ago, Leica Geosystems, part of Hexagon, established a Reality Capture division. Recently, we sat down for a conversation with Juergen Mayer, president of this division.
★★★
Ed. Note: This interview has been lightly edited for length and clarity.
Gavin Schrock: You've been head of the RC division for how long now?
Juergen Mayer: Ever since it has been in existence, which is now five years. It was formed five years ago with an expansion of terrestrial laser scanning. Those were the days after the initial release of the BLK360 and RTC360 laser scanners. And the whole thing grew and became big since then. I was told at the time by our then-president of Geosystems that a separate organization to look after reality capture was needed. Not only because it's becoming bigger, but also because it used to be part of geomatics, the core surveying business. And I think you can rightly identify that reality capture operates in a very different environment and different dynamics for a broader user base.
The RC division encompasses the entire BLK family of products, terrestrial laser scanning, mobile mapping systems and all accompanying software. However, large format aerial mapping is a different group. Total stations and GNSS are in the Geomatics division. RC is still widely used in geomatics and traditional surveying of course.
Leica Geosystems still strongly focuses on surveyors as a primary customer persona. They represent highly skilled users. However, RC technology can and is being leveraged by a growing group of other users, for many more applications.
I'm a surveyor myself, and for reality capture, surveying is where we traditionally come from. But this is where there were some initial misconceptions about the technology. An interesting story: When I first went into laser scanning, I would hear many people looking at laser scanners and thinking of them like total stations on speed. That’s not wrong, technically. But it's also not right, and it's selling it a little short.
Since those days, there has been a mind-shift toward seeing reality capture for what it truly is. There's a lot broader use of this, and there’s a whole potential out there to apply it to all sorts of things that are not necessarily exclusively surveying.
GS: In observing that evolution, I used to find different ways to differentiate between RC and traditional surveying and mapping. I would call RC “mass data capture” because it could be scanning, satellite, airborne, mobile mapping, etc. Whatever mass data tool or method captures proximal richness, rather than discrete points that is kind of a sampling of the features. And we’d string those points together, often with a lot of interpolation, as with contours.
JM: Yes, there are very distinct points. Yet one has power over another, but only in certain situations. To surveyors, it has always been reality capture, and they have made the maps from the beginning, no matter what the technology and tools.
Taking one point is also capturing reality. But here, there is a premium on specialist knowledge. As I said before, it needs to be a smart guy who knows which point you capture, which allows you to delay that decision to further down the process. With mass data capture, someone in the office could make that decision. Now, I'm thinking that the AI can do a lot of that, but how do we make sure it picks the right points? There are still crucial questions about accuracy and completeness - trust is a tough one. However, we are seeing promising progress with AI for specific tasks with highly reliable results, for instance, in point cloud classification.
GS: In interviewing your RC colleagues here at Heerbrugg, I keep running into the mantra of “everything, everywhere for everyone”. Is this a business philosophy or development approach?
JM: Both. You would have heard this often in your discussions with our software group. It's really about building our RC ecosystem. We are a software ecosystem in which you are flexible to use cloud-based software or tablet-based software or desktop-based software, depending on your specific needs. What we've seen is, I mean, traditionally, we had very desktop-based workflows, also given to the technical constraints at the time, but we see this big trend towards the cloud. The idea is to ensure that key functionality is available in all our RC software, no matter which software environment you are in.
At the same time, we see that not everyone wants to adopt the cloud. And we also see different tracks. If you look at what we want to achieve, we want to be successful with RC with different groups of customers.
GS: You mentioned two main groups, not tiers per se, but different types of end users.
JM: There are the measurement professionals who include expertise in the technical aspects and the professional aspects, like surveyors. They want or need to be able to control every aspect of the process.
And then there's the people who are simply interested in a deliverable, and they would only care a little about how it is being processed. We call this group the domain experts. They know their end-use discipline very well and simply want the data to do their work - think of archaeologists, architects, film crews, etc. These groups do essential work, and there are very specific situations where that work might be appropriate for one group to do rather than the other, or a team of both.
Therefore, we want to be able to serve both of these groups, which in a black and white way, we distinguish as the measurement professionals and the domain experts. For example, people come to me and say, “I'm a construction engineer; I want this."
Originally, we thought, Okay, the measurement experts these days will be the people who will typically use our traditional desktop-based software, which gives you all the bells and whistles for everything.
And then the second group would maybe lean towards cloud-based service offerings that could have pay-per-use models and these sorts of things. That would also give them a highly automated workflow. We only bother them with some of the steps and configuration settings. It's more automated as possible: You upload your data, and as much as possible, everything happens automatically.
Then, we also see that there might be hybrid versions of these workflows, where people will want to have certain aspects automated. They love the cloud, but then they want to intervene in a specific step because they want to optimize the results there. So, looking at the cloud, with Reality Cloud Studio, powered by HxDR, the approach we take is that it's fully automated with a simple-to-use workflow. But at some stage, someone will want to use the desktop software that gives them all the options to log into this, into the datasets that sits in the cloud, do some sophisticated manipulations - again, intervene. The approach of “everything, everywhere for everyone” is to enable these hybrid workflows.
GS: AI and the cloud strike visions, for many folks, of “button pushers," the same things folks said when EDM, GNSS, and total stations were introduced. However, those buttons, in responsible hands, certainly deliver excellent productivity gains.
JM: It is a valid concern because you may never get everything right if it is too automated, and people will miss opportunities to intervene. But if it's too complicated for certain people, then they will not adopt it. Options that provide for a balance of automation is essential. So, whatever you want, we can offer this in the cloud, we can offer this on the desktop, we can offer this in the field, but it might present itself slightly differently.
Therefore, it's also essential that you are able to combine these aspects from a development point of view. It forces us to apply a highly modular approach where the functionality is always the same. We want the same results to come out on different platforms. So, independent of that it needs to be that the same magic that we had happens in the background. We build functional modules for registration, for example. It's the same registration engine that runs in Cyclone REGISTER 360 PLUS that runs in the cloud. As a user, it might look different in the sense that it's a lot simpler and a lot more automated, but it's exactly the same algorithms that run under the hood. Mobile mapping is slightly different, but even so, there are some key elements in common.
GS: When I talk to users of say, UAV-based mapping or SLAM scanning, they want to be sure the data is complete and accurate before they leave the field. Nothing can be as frustrating as a crew driving across the state after field observations, only to find errors and omissions back at the office. In test-driving some of your field gear yesterday, I saw more functionality for field verification; this is encouraging.
JM: Yes, that's clearly a trend and market demand. Really, two things actually. One, it's being sure that you captured everything and that it's the right quality. The other thing is that sometimes you need a result directly in the field. Like in a construction process where you need to gauge floor flatness. You pour concrete, you want to -you need to - know within 10 minutes whether it’s good.
GS: That’s why some people like scanning total stations. They get the data right away, and it can be precisely and instantly registered to the same project control that you may have established with the total station.
JM: Same concept. Returning to the “everything everywhere, for everyone” concept, a result in the field doesn't necessarily mean that everything is being calculated on this instrument or tablet. That might be a combination of sending things to the cloud. This concept of clouds combined with edge computing is powerful. You do the things that need to happen really quickly on the device, but processing heavy things might still happen in the cloud and be fed back to you rapidly via a web browser etc.
GS: I’d like to throw a hypothetical at you; some future-casting. There are things I would dream about while trudging through the tundra or swamp with heavy legacy instruments and whimpy software. What I envisioned was very, very smart instruments.
Picture this: Five to 20 years from now, someone walks on to a site, and behind them is this walking robot with an instrument package.
How far away might we be from this?
JM: I would not put a timeline on it. However, I would say, to quite a degree, we have many ingredients. We do not have a full solution yet, but I’m confident that we have part of the solutions already for the field’s results. You want to extract these features right here and now? Well, it is because it impacts on the mission, helps with ensuring completeness, etc.
There are examples of how certain elements of your hypothetical solution are already happening. You mentioned mobile mapping. Mobile mapping is slightly different than other RC technologies in the sense that the data volume is so big, but that is also an advantage as to accommodate the large volumes. We have a lot of processing power directly in the car in a box.
There is a lot we can do with that much processing power. For example, we blur the people and car number plates in the images on-the-fly. This anonymization is required in many countries to meet privacy rules; there cannot be copies of images with faces and number plates in them stored somewhere. On-the-fly anonymization ensures this will not occur.
There will be steady progress in sophistication, but in the end it all goes into the theme of autonomy that automatically extracts the information in the field or at the end of capture that is important to the mission: is it complete and accurate? Real-time reality capture can be pretty powerful.
And the closest thing to your scenario might be a robotic carrier with a BLK ARC on top? Things are moving fast…
★★★
Whether it is for engineering surveys, asset mapping, digital twins, or even those “metaverses” some folks go on and on about, there will have to be a lot more reality capture. There needs to be tools and software, skilled professionals, and domain experts to do the capturing. RC has found its way into many non-traditional sectors. Think about the game developers that want to use models of real-world locations, or the film crews making sure the CGI elements can interact seamlessly with physical sets and actors.
RC is a thing, a big thing, and it is being adopted for a seemingly endless list of use cases. Leica Geosystems looked to the reality of a future for the company that sees RC as a prominent element, ripe for expansion.
