The headline announcements out of Autodesk University this week are about AI, as expected – pushing the boundaries of interoperability, plain language-driven workflows, and agentic work, and we’ll be covering that in more depth in the coming week. But for anyone working the geospatial side of AEC, there was a piece of consequential news announced in a single bullet point, but took over a year of engineering and manual negotiation to achieve.
Autodesk has announced that they’ve built a “unified geolocation engine” spanning Forma, Revit and Civil 3D. Until now, moving a model between Autodesk tools meant the coordinate system did not reliably travel with it, a problem that has irritated surveyors, civil engineers and GIS teams for as long as those tools have coexisted. The company’s stated goal is keeping location information consistent as teams move between products, cutting manual transforms and the model misalignment that follows them. CEO Andrew Anagnost described it in a press Q&A as one coordinate system that propagates across everything, built on internal technology but shaped heavily by Esri, their geospatial partner.
Dan Lohmeyer, who runs design applications for the AEC portfolio, filled in how it was actually done. Autodesk took the coordinate system that already lived inside Civil 3D and promoted it into a shared geolocation service, authored by the Civil 3D team, now serving Revit and Forma as well. Revit, he noted, effectively did not have one before. “It was actually a big piece of engineering work over the past year to enable that,” he said.
Autodesk and Esri faced the product of years of accumulated divergence in how they labeled the same things, down to spacing and punctuation in coordinate system names, which wouldn’t line imports and exports in ways that looked like data problems but were really naming problems. “The team [working on the new coordinate system] reviewed over 2,000 labels, so they would match,” Lohmeyer said. When there was a conflict, the answer was simple. “We told them to pick one.”
The new capability is live now for Revit, though currently only in connected workflows, with broader availability signaled but not dated. In practice, a user can start from a site address or lat/long coordinates, place a Revit model into the site, and have Civil 3D understand it, because the coordinate system originated in Civil 3D to begin with. The larger architectural changes underneath that, including where Civil 3D is headed, deserve their own treatment and we will come back to them.
It’s worth being clear about the limits, though, because this solves how products name and hand off a location, not the harder measurement questions underneath it. Elevation still depends on which vertical reference a project uses, long corridor projects still have to account for the distortion that comes from flattening a curved earth onto a flat grid, and the custom projections that DOTs increasingly build for a single highway are still their own problem. It’s also Autodesk to Autodesk, so handoffs to anything outside that stack run through the same exchange formats and the same assumptions they always have.
Still, there’s something telling (encouraging, even?) about a company spending a year of engineering and two thousand label negotiations on a problem that produces no demo, in a week otherwise given over to agents and plain language prompts. Coordinate systems are the kind of infrastructure nobody notices until they’re wrong, and the people who have been quietly absorbing that cost, usually a surveyor at the start of a project and whoever gets stuck proving the geometry was fine at the end, are the ones who will notice this first.
