It all started about 6-7 years ago, when I first began experimenting with augmented reality using the FME AR app. At the time, AR was mostly a curiosity, a passion project of our developers, but it didn’t take me long to realize that underground utilities were a perfect match for it — especially for our existing audience of cities, utility companies, and departments of transportation. Utilities is something that exists unseen, other than some on-the-surface manifestations of the networks, such as manholes, fire hydrants or catch basins.
So I decided to go big. Why not try adding an entire city as an example? My first choice was obvious: Surrey, home of Safe Software HQ. But then, of course, COVID happened, and we were all suddenly working from home. So I pivoted to something closer to my doorstep — literally. The City of Coquitlam, just 500 meters away to the closest street, became my test ground. A short walk was all I needed for real-world testing. I grabbed open data shapefiles for all the utilities: simple 2D points and lines, the perfect sandbox to start with.
The first prototype workspace had around 50 transformers — modest by FME standards — and produced a flat 3D model. Flat, as in “no elevation changes,” which is mildly inconvenient when your test city is a literal mountainside. To avoid confusing perspectives of mismatching real and augmented worlds, I had to drive a bit more than half a kilometer to the patches where things looked believable. But step by step, the example grew.
I added surface draping, external styling (all colors defined neatly in a spreadsheet), and later, fancy HTML-based AR labels using whhtml2image. Before I knew it, the workspace had ballooned to nearly 300 transformers. At that point, it wasn’t just a prototype anymore, but a fully functional example. I could walk anywhere in the city, send my location to FME Flow, and instantly get back an AR model of that exact spot on demand, with no pre-converted data.
It worked. Beautifully. It was also… a bit complicated. Between 2D-to-3D transformations, dealing with data inconsistencies, formatting and styling, there was plenty to manage. But it proved that the concept worked. We even tested it with a GNSS receiver provided by our partner Eos Positioning Systems, and the accuracy of the model placement was great.
Then came 2024 — the year of a big change for our AR product. Safe added WebView support, and that single feature opened the floodgates. Suddenly, from within the AR interface, I could connect to HTML interfaces, live database updates, IoT feeds, AI integrations, 2D maps and 3D visualizations, and voice input. It became so much more than the old FME AR app, and we knew it deserved a name of its own. That’s how FME Realize was born. Behind it, there is always the key idea: everything runs on the FME platform. The power and flexibility behind FME Realize come directly from the platform itself. And our creativity.
The Game-Changer: Data Virtualization Joins the Workflow
After years of building and expanding my example, there was still one area that felt… messy. The data preparation.
Originally, my workflow used a FeatureReader to bring the data in. The idea was simple: get the location from the device, buffer it, and send that buffer into the FeatureReader. The transformer would then return all the features within that buffer — everything from pipes to catch basins to street centerlines. It worked perfectly in theory.
In practice, though, it was a lot. Every feature type — every table, layer, or asset — came out of its own port. Forty layers meant forty output ports, which all needed to be connected, handled, cleaned, and standardized. And with each one came a pile of attributes, many of them irrelevant for the 3D model but still valuable for field users. So I had to choose: carry all that extra data through the workflow or spend time trimming it down. Neither option was particularly elegant.
The real challenge was consistency. Different data sources used different naming conventions for the same thing — for example, diameter could appear under six different attribute names. To generate 3D models correctly, I had to unify them; otherwise, every geometry creation step would turn into a small headache. And honestly, most of that work wasn’t about AR models at all — it was good old data cleaning and standardization.
That’s when Data Virtualization entered the picture.
Data Virtualization, a new capability built entirely on the FME platform, takes away one of the biggest pains in complex projects: dealing with formats, connections, and authentication for every data source. It lets you create secure, OpenAPI-compliant REST APIs directly on top of your existing data — no extra infrastructure, no custom code. Each API endpoint (GET, POST, and so on) is powered by an FME workspace designed in FME Form and deployed in FME Flow, so everything follows the same no-code logic FME users already know. Behind a few simple API calls, it hides all the heavy lifting, such as authentication, permissions, caching, and the quirks of each format. In other words, your workspaces don’t need to know where the data lives or how to talk to it — they just ask for what they need.
By introducing Data Virtualization to my city-scale AR example, I was able to separate all that heavy lifting — data preparation, quality control, cleaning, and formatting — from the actual 3D model creation. The model-building workspace suddenly became lean and focused.
Now, all I need for model generation are the essentials:
- The feature ID and type,
- Coordinates (X, Y),
- Size parameters like diameter or height, and
- A few key attributes for visualization — things like status or install date that field workers want to see right away on labels above the assets.
Everything else stays where it belongs — in the data layer, ready to be accessed when needed.
Instead of a massive FeatureReader, my workflow now relies on three OpenAPICallers:
- One for lines (pipes and cables),
- One for points (manholes, catch basins, valves, hydrants, etc.),
- And one for street centerlines (because seeing street labels helps confirm you’re looking at the right place).
With that setup, I can start transforming data to 3D right away, with no extra data wrangling required. The workspace shrank from nearly 300 transformers down to about 180. Still a beast, but a much more elegant one.
Adding a New City: When Three Hours Beat Five Years
With Data Virtualization in place, the workflow felt cleaner and lighter — and I could finally invite others to experience it in the real world. So one morning, I took a small group of colleagues — including our founder and CEO, Don Murray, a few AR developers, our AR product manager, and support team members — on a field trip to see FME Realize in action.
It was a great outing. Everyone got to see both the polished and the still-improving parts of FME Realize (and yes, both are equally important). The demo worked beautifully, but organizing a trip like that wasn’t exactly easy. Driving to Coquitlam isn’t far (it’s still part of Metro Vancouver) but it requires planning, coordination, and, let’s be honest, snacks.
That’s when Don said, “Wouldn’t it be easier if we could just step outside the office and test it here?” Good point. And just like that, Surrey — home of Safe Software HQ — joined the wish list.
Looking back at my five years of building and polishing this example, I thought: “Okay, adding a whole new city… give me a couple of weeks.”
But once I started, I realized that thanks to Data Virtualization, most of the heavy lifting was already done. All I needed was to adjust a few things in the workspaces behind the API calls — mainly accommodating Surrey’s naming conventions and adding a couple of new layers that didn’t exist in Coquitlam’s dataset.
I also added a simple logic tweak so the API workspaces could detect which database to read from. Now I have two databases — one for Coquitlam, one for Surrey. I created boundary polygons for both cities, and a quick overlay check determines which city the user’s location falls into. From there, the workspace simply writes one word — coquitlam or surrey — into the Data Virtualization API call. That’s it.
https://myar/api/coq_ar/point?x=-122.84&y=49.18&radius=60&city=surrey
The rest just worked.
From the moment I started looking for open data to the moment I stood outside our office, viewing Surrey’s underground utilities in AR, only three hours had passed.
The Impact
When we stepped outside our office in Surrey and launched the new AR model for the first time, it felt like a full-circle moment. The same workflow that once took months of experimentation and debugging was now flexible enough to handle a completely new city with almost no effort.
For me, this was both a technical milestone and a validation of how far the platform has come. FME Realize is built with the same building blocks available to every FME user, yet it delivers something both empowering and visionary — a true realization of the creative and technical potential we already have at our fingertips.
My colleagues could see the simplicity, speed, and reliability too. Since then, I’ve led two workshops about FME Realize, taking both groups outside to experience the data where it truly belongs. What started as a small experiment five years ago has become a showcase of what’s possible when the FME platform, and especially Data Virtualization, is used to its full potential.
This experience proved that innovation doesn’t always come from reinventing workflows — sometimes it’s about connecting existing pieces in smarter ways. Data Virtualization turned a complex, city-scale AR project into something portable, scalable, and easy to extend.
Today, I can add a new city in hours, not weeks. I can safely run auxiliary tools (such as whhtml2image) in isolated environments. I can trust that data preparation and visualization live in perfect harmony, each doing exactly what it should.
That’s what makes FME Realize special — and what makes FME, as a platform, so powerful. The tools are already there; we just need to imagine how far they can go.
