BlenderGIS Imported Mesh Too Small or Wrong Scale: Causes and Fixes
You import a shapefile or raster into BlenderGIS and the result looks absurd: the X and Y extents are microscopic, while the Z (elevation) dimension looks roughly right — or the whole model is squashed into a sliver you can barely see. You didn’t do anything wrong. You’re looking at a coordinate-unit mismatch, and the fix takes about two minutes.
Quick answer: Geographic coordinates (latitude/longitude) are measured in degrees, and 1 degree ≈ 111 km. When BlenderGIS imports data in a degree-based CRS like WGS84 (EPSG:4326), a city a few kilometers wide becomes a mesh only ~0.05 units across — while elevation in meters stays full-size, so Z looks huge by comparison. Reproject your data to a meter-based CRS (your local UTM zone) before importing, or preprocess in QGIS, and the scale problem disappears.
Why Imported Meshes Come In at the Wrong Scale
The confusion comes from mixing two different units in one scene:
- Horizontal coordinates in degrees. If your source data uses WGS84 (EPSG:4326) — the most common CRS for downloaded GIS data — positions are stored as decimal degrees. A 5 km wide study area spans roughly 0.045 degrees. BlenderGIS imports those numbers as-is, so the mesh is 0.045 Blender units wide.
- Vertical coordinates in meters. Elevation values in a DEM are meters above sea level. A hill 200 m tall imports as 200 Blender units tall.
The result: a model that is 0.045 units wide and 200 units tall — a needle, not a landscape. This is the classic “X/Y tiny, Z normal” symptom.
There’s a second, subtler problem. Blender uses single-precision floating point internally — about 7 significant decimal digits. If you import data in a degree-based CRS and keep the full global coordinates (e.g., longitude 116.3974), vertices near the scene get rounded to ~1e-7 degrees ≈ 1 cm precision at best, and geometry far from the origin degrades further. Importing in a projected meter-based CRS keeps coordinates in the hundreds-of-thousands range (typical UTM eastings), which sits comfortably inside float precision.
In short: degrees are the wrong unit for a 3D scene. Meters are the right one.
How to Fix the Scale Problem
Fix 1 — Reproject to a meter-based CRS (UTM)
The cleanest fix is to reproject your data into a projected coordinate system that measures in meters. The standard choice is the UTM zone covering your area of interest.
- Find your UTM zone. UTM divides the world into 60 zones, each 6° of longitude wide. Zone number = floor((longitude + 180) / 6) + 1. For example, central Europe (lon ~13°E) is UTM zone 33N; New York City (lon ~74°W) is UTM zone 18N. The “N” is northern hemisphere (EPSG:326xx), southern hemisphere uses EPSG:327xx.
- Reproject in QGIS. Load your shapefile or raster, right-click the layer > Export > Save Features As… (vectors) or use Raster > Projections > Warp (rasters), and set the target CRS to your UTM zone (e.g., EPSG:32633).
- Import the reprojected file into BlenderGIS. Use GIS > Import > Shapefile or the GDAL raster import. X, Y, and Z are now all in meters and the scale is correct.
Our QGIS-to-Blender workflow guide walks through the whole QGIS preprocessing pipeline — clipping, resampling, and reprojection — step by step.
Fix 2 — Sort out the CRS in QGIS before importing
If your project already mixes sources (a shapefile in WGS84, a DEM in UTM, a basemap in Web Mercator), sort out the CRS situation in QGIS before importing anything into Blender:
- Load all layers into one QGIS project and check each layer’s CRS in its properties.
- Reproject every layer to one common meter-based CRS (your UTM zone) using the export/warp tools from Fix 1.
- Verify alignment in QGIS — if layers line up there, they’ll line up in Blender.
- Then import the consistent set into BlenderGIS.
This also prevents the related class of CRS mismatch errors, which we cover separately in the shapefile CRS mismatch guide.
Fix 3 — The mesh is already imported — now what?
If you’ve already imported a degree-based mesh and don’t want to redo the import:
- Rescale manually (approximate). Scale X and Y by 111,320 (meters per degree of latitude) — but note this is only exact for latitude; longitude degrees shrink with cos(latitude), so for precise work this is a hack, not a fix.
- Better: re-import properly. Reproject the source in QGIS (Fix 1) and re-import. The five minutes it costs beats fighting a subtly wrong scene for hours.
- Check Z separately. If elevation came from a DEM in meters, Z is probably already correct — only X/Y need the CRS treatment.
Don’t “fix” it with a 111,320 scale factor on the final render. The float-precision issue means degree-coordinate geometry far from the origin develops visible vertex jitter. Reprojecting the source data is the only fix that addresses both scale and precision.
Frequently Asked Questions
Why is only the Z axis the right size?
Because elevation values are stored in meters while horizontal positions are stored in degrees. A 200 m hill is 200 units tall, but a 5 km wide area is only ~0.045 units wide in degrees — so Z looks correct and X/Y look microscopic.
Which CRS should I use for my area?
Your local UTM zone is the standard answer for site-scale work: EPSG:32601–32660 for the northern hemisphere, EPSG:32701–32760 for the southern. Zone number = floor((longitude + 180) / 6) + 1. National projected systems (like a country-specific grid) work equally well if your data already uses one.
Can I just scale the mesh up by 111,320 in Blender?
As a rough visual hack, yes — but it’s wrong in two ways: longitude degrees aren’t 111,320 m (they shrink toward the poles), and single-precision float rounding on degree coordinates causes vertex jitter. Reproject the source data instead.
Does this affect basemaps too?
Basemaps from web services arrive in Web Mercator (meters, EPSG:3857), so they don’t suffer the degree-scale problem — but Web Mercator has its own accuracy issues at high latitudes. See our basemap measurement accuracy guide for details.
My shapefile and DEM don’t line up after import. Is this the same issue?
Often, yes — it’s the CRS mismatch version of the same problem. One layer in degrees and another in meters will never align. Reproject both to the same meter-based CRS in QGIS before importing, as described in the shapefile CRS mismatch guide.
What about very large areas, like a whole country?
UTM is designed for zones 6° wide; for country-scale work it still beats degrees, but consider an equal-area or country-specific projected CRS. The key principle doesn’t change: use meters, not degrees, for any 3D scene.