> ## Content Index > Fetch the complete content index at: https://topographer-com.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # Import Toposolid CSV Files into Revit Correctly - URL: https://topographer-com.ghost.io/import-toposolid-csv-files-into-revit-correctly/ - Published: 2026-08-12T07:48:22.000Z - Updated: 2026-08-12T07:48:22.000Z - Author: Aki Olafsson A CSV can be numerically correct and still produce an unusable Toposolid. The elevation data is almost never the problem. What breaks the model is the boring stuff: X and Y swapped, feet interpreted as metres, a comma decimal separator colliding with a comma delimiter, 60,000 points where Revit will only import 10,000, or coordinates 200 kilometres from the internal origin. Since Revit 2024, the native workflow for this is straightforward: **Massing & Site → Toposolid → Create from Import → Create from Points File**. The command is documented, works with a plain XYZ CSV, and does not need Dynamo, a plugin, or Civil 3D. Dynamo is still useful for automation and for getting past a few of Revit's default limits, but it is a power-user path, not a required one. This is a guide to using the native route reliably, and then knowing when Dynamo is worth reaching for. ## The five things that actually break a Toposolid CSV import Before touching Revit, the CSV needs to survive its own contents. In order of how often they cause silent problems: 1. **Column order.** Revit expects X, Y, Z. Survey files often ship as Northing, Easting, Elevation (N,E,Z), which is Y, X, Z. Load that unchanged and your site is mirrored across the diagonal. 2. **Delimiter versus decimal separator.** European locales use a comma as the decimal separator (\`51,234\` means 51.234). If the file is also comma-delimited, Revit reads garbage. Use a period as decimal separator and keep the file comma-delimited, or switch to a semicolon delimiter and know what you did. 3. **Units.** A file in survey feet imported as metres will land compressed. A metric file imported as feet will land 3.28 times too large. Revit asks for units on import. Answer deliberately. 4. **Distance from Revit's internal origin.** Revit's model plane has a **10 mile (16 km) radius**. Import a CSV in national grid coordinates and every point is hundreds of kilometres from origin. You will get the "Geometry in the file has extents greater than 20 miles" warning, and even inside the limit, precision degrades as you move away from origin. 5. **Point count.** Revit 2024 and 2025 downsample any point-file import to **10,000 points automatically**. Revit 2026 lets you raise the ceiling via a \`Revit.ini\` edit (usually up to 50,000), but performance still tanks past 15 to 20 thousand. Get those five right and the rest of the import is boring, which is what you want. ## Prepare the CSV A clean CSV for Toposolid import is plain text, one point per row, comma-delimited, period decimals: \`\`\` X,Y,Z 365412.320,7042118.900,84.350 365413.500,7042118.850,84.120 ... \`\`\` A header is optional. Revit's import lets you skip the first row, so include it if it helps the surveyor understand the file, or leave it off if you prefer. Do not mix delimiters, do not include text notes at the top, and do not leave empty rows scattered through the file. Every one of those is a real support ticket somewhere. If the file came from a surveyor in PNEZD format (Point number, Northing, Easting, Elevation, Description), strip it back to just Easting, Northing, Elevation and reorder to X, Y, Z. If it came from CloudCompare as \`sweep 1 colour;intensity;X;Y;Z\`, strip the metadata columns and swap the semicolons for commas. The two minutes of prep saves the hour of chasing why a Toposolid arrived as a diagonal streak of points. ## Move the coordinates near Revit's origin Survey and mapping data usually sits in a national grid, state plane, or UTM zone. Those coordinate values are large. UK Ordnance Survey coordinates put central London at roughly (530000, 180000). Iceland's ISN2004 grid puts Reykjavík near (355000, 405000). Michigan State Plane North puts Detroit at coordinates in the millions of feet. Revit will not like any of that unchanged. The internal origin is the centre of Revit's model plane, which has a **10 mile (16 km) radius**. Geometry beyond that gets less accurate, and Revit displays it less reliably. Autodesk's own guidance is explicit: keep the geometry within the plane, and use the survey point to record where the project sits in real-world coordinates. The clean pattern is: 1. Pick an offset. The easiest is the coordinate of the first point in the file, rounded to a whole metre or foot. If the first point is \`365412.320, 7042118.900\`, use \`365412, 7042118\` as your offset. 2. Subtract the offset from every X and Y. The example above becomes \`0.320, 0.900\`. All the rest of the points land within a few hundred metres of Revit's origin. 3. Record the offset. Write it in the project survey information, in the coordination log, and on the file itself. This is now a documented transformation, not a fudge. 4. Apply the same offset to every other coordinated file: the surveyor's DWG, the civil model, the setting-out data, the neighbouring block linked into your central model. If the offsets do not match, the models do not line up. Do not use this to "make the numbers small so Revit is happy." Use it to keep your project near origin while preserving a clean, reversible link to real-world coordinates. ## Confirm units and vertical datum Two separate questions live in your CSV, and both need answers before import. **Horizontal units.** Metres or feet, and if feet, are they international feet or US survey feet? The difference is small (about 2 parts per million) but on a state plane grid in the US it compounds enough to matter. A CSV labelled in metres imported as feet will produce a terrain 3.281 times too large. Revit's import dialog asks. Answer with intent. **Vertical datum.** Z might be: - Height above a national datum (ODN in Great Britain, NAVD88 in the US, DVR90 in Denmark, DHHN in Germany, ISN2004 or ISN2016 in Iceland). - Height above a local benchmark. - A relative height from a project datum (finished floor level 0.000, for example). - Height above the ellipsoid, rather than orthometric height. This one bites when GPS data lands directly in a model. The two can differ by tens of metres. Decide what Z means and either keep the absolute value (and set Revit's project levels to match the datum), or subtract the offset deliberately and document it. Adjusting Z values by eye after import is how projects end up with floor plates 84 millimetres out of alignment with the civil model. ## Reduce points before you import Denser is not always better. On a 200m by 200m site at 1m spacing you already have 40,000 points, four times what Revit 2024 or 2025 will actually keep. Push that to 0.5m spacing and you are throwing three-quarters of the points away without knowing which three-quarters. Match spacing to the decision: - **Concept, massing, contextual model:** 5 to 15m spacing. Coordinates the site correctly, opens fast, edits without complaint. - **Site plan, drainage direction, access grading:** 1 to 3m spacing over the areas that matter, wider outside them. - **Landscape or hardscape detail:** 0.5 to 1m spacing, but ring-fenced to the zones that need it, not the whole site. Before you reduce, spot-check the raw data: - Sort the Z column and look at the top and bottom. Elevations 200m off the site mean either an outlier or the wrong coordinate reference. Fix it now. - Check for duplicate XY with different Z values, especially near the perimeter. Duplicates confuse triangulation and produce triangles that cross features they should respect. - Look at the point distribution. If half the points cluster along one edge because the source polygon was clipped there, thin them out. Data quality is easier to fix in the CSV than in a Toposolid. ## The native route: Create from Points File Once the CSV is clean and offset: 1. Open the Revit project and go to a plan or site view. Make sure the project base point and survey point are set correctly, and pinned. 2. **Massing & Site → Toposolid → Create from Import → Create from Points File.** 3. Pick the CSV. Revit asks for units. Answer. 4. Revit creates the Toposolid. Go to a 3D view and check that it landed near origin, oriented the right way, at the right elevation. A few things worth knowing about the result: - The **Elevation Base** parameter on the Toposolid controls how Revit measures point heights. If you added points earlier at "prescribed elevation" and they land at nonsensical values, this is usually the reason. Set it to Project or Level deliberately. - Assign the imported Toposolid to a phase (usually Existing) and pin it. This is your source-of-truth existing surface. Any grading goes on a copy in the New Construction phase, via Graded Region, so cut and fill volumes schedule correctly. - **Building Pads are gone as of Revit 2024.** If you were about to punch the building footprint into the terrain with a pad, use a void or a Graded Region on the Toposolid instead. - Toposolid behaves more like a floor than the old Toposurface. It is heavier to edit, especially when it hosts other elements. Split it into logical chunks if the site is large, rather than keeping one giant Toposolid with tens of thousands of points. ## When Dynamo makes sense The native command is enough for most projects. Reach for Dynamo when one of these is true: - You need to **repeat the import** on many sites with the same offset and unit conventions, and want a graph the team can run. - The 10,000 point downsample matters and you cannot regenerate at a lower density. A Dynamo graph using \`Toposolid.ByOutlinePointsTypeAndLevel\` (or the equivalent API call from Python) can push past the ribbon dialog's limit in some Revit versions. - You want to **do something Revit's ribbon does not expose**: pre-filter points inside a specific polygon, drape a proposed slab onto the existing surface, or export Toposolid points back out to CSV for coordination. Two things to know before you commit to a Dynamo route: - The Toposolid Dynamo API has changed between Revit versions and is still uneven. Nodes that existed in 2024 may be renamed or absent in 2026\. \`Topography.ByPoints\` does not work on Toposolids. \`Toposolid.ByOutlinePointsTypeAndLevel\` needs an outline, not just a point list. Adding points to an existing Toposolid is a known limitation that people still work around with copy-paste from a temporary Toposolid. - If your graph works but produces different geometry from the native command, trust the native command by default. Version-check the graph against a Revit release you can support, and pin it to the project. For most day-to-day CSV imports, the graph is not worth the maintenance burden. Use it where automation genuinely earns its keep. ## Verify the model before design decisions A Toposolid that looks plausible in a 3D view can still be wrong. Before it drives any design decisions, run through the same checks a coordinator would: - Place a handful of **Spot Elevations** on identifiable points (road centreline, building corner, kerb line) and compare them against the source CSV. If they disagree, the Elevation Base or the offset is wrong. - Cut a **section** through the building footprint, the access route, and the site edges. Look for triangulation crossing features it should respect. A retaining edge that appears as a smooth slope is a symptom, not a style. - Compare **northing and easting** to a known survey control point or property corner. Not just "does the shape look right", but "is that specific point at that specific coordinate". - Look at the **perimeter**. Interpolation artefacts often live on the edges of the sampled area, where the source data ran out. Once it passes, name the file properly (Existing Terrain, source, capture date, spacing), and mark it in the model browser and coordination register. If someone six months from now needs to know whether that Toposolid is a survey, a LiDAR extract, or a preliminary generation, the answer should be one click away. For teams without a GIS specialist, a terrain export service such as [Topo-grapher](https://topo-grapher.com/?ref=topographer-com.ghost.io) shortens the front end of this: define a site polygon, pick point spacing, download a clean XYZ CSV in the coordinate system you want. The import discipline still matters. What you save is the tile-hunting and coordinate-conversion time, not the coordinate offset and unit-checking discipline that belongs inside every Revit project. Done well, a Toposolid import should feel ordinary. When the coordinate offset, units, point count, and delimiter are all deliberate, the terrain becomes a dependable basis for levels, grading conversations, and coordination, rather than another file to troubleshoot. [Generate a Toposolid-ready CSV free →](https://topo-grapher.com/?ref=topographer-com.ghost.io) ## Frequently asked questions ### Does Revit have a native command to import a CSV into a Toposolid? Yes. Since Revit 2024: **Massing & Site → Toposolid → Create from Import → Create from Points File.** It accepts a comma-delimited XYZ CSV and asks for units on import. You do not need Dynamo, Civil 3D, or a plugin for this to work. ### Why does my Toposolid only include some of the points from my CSV? Revit 2024 and 2025 automatically downsample point-file imports to **10,000 points**. If your CSV was denser, Revit picked a subset. Regenerate at a lower spacing so you get to choose which points survive, or if you are on Revit 2026, raise the limit via \`Revit.ini\` (up to around 50,000). Performance still degrades past 15 to 20 thousand points, so more is not free. ### My terrain lands hundreds of kilometres from Revit's origin. What do I do? Do not move the geometry blindly. Revit's model plane has a 10 mile (16 km) radius from the internal origin, so you need the terrain inside that. The clean fix is to subtract a fixed offset from every X and Y in the CSV, document that offset in the project survey information, and apply the same offset to every other coordinated file (surveyor's DWG, civil model, setting-out data). Preserve the link to real-world coordinates rather than deleting it. ### Should I offset the Z values as well? Only if you have a specific reason. If the project uses finished floor level as 0.000 and the site is 84.350m above datum, you can either keep absolute elevations and set the project levels to match, or subtract 84.350 as a deliberate, documented transformation. Adjusting Z values by eye after import is how floor plates end up misaligned with the civil model. ### What coordinate columns does Revit expect in the CSV? X, Y, Z, in that order. Survey files often arrive as Northing, Easting, Elevation, which is Y, X, Z. Reorder before import, or your site imports mirrored across the diagonal. Aki's Nordic customers in particular should also check the decimal separator: \`51,234\` as a European decimal collides with a comma delimiter and produces nonsense. ### Do I need Dynamo for this? No, for a normal CSV to Toposolid workflow. The native command handles it. Dynamo earns its place when you are automating the import across many projects, working around the 10,000 point cap, or doing something the ribbon does not expose (pre-filtering, coordination, re-export). The Toposolid Dynamo API has changed between Revit versions and is still uneven, so a graph written for 2024 may not run on 2026 without work. ## Further reading - [Autodesk: How to create Toposolid from imported data](https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-create-toposolid-from-imported-data-in-Revit.html?ref=topographer-com.ghost.io), official documentation on the 10,000 point cap and supported file types. - [Autodesk: About the Maximum Distance Limit](https://help.autodesk.com/view/RVT/2025/ENU/?guid=GUID-3F79BF5A-F051-49F3-951E-D3E86F51BECC&ref=topographer-com.ghost.io), the 10 mile / 16 km rule from Revit's internal origin. - [Topography for Revit](https://topo-grapher.com/topography-for-revit.html?ref=topographer-com.ghost.io), the end-to-end XYZ CSV to Toposolid walkthrough. - [Extract terrain from a site polygon](https://topo-grapher.com/blog/extract-terrain-from-site-polygon?ref=topographer-com.ghost.io), the upstream step: getting a clean CSV in the first place.