A map of Saint Petersburg in DWG: how to export it without getting an unusable file

A map of Saint Petersburg in DWG is something designers need almost daily — as an underlay for a master plan, a site plan or a landscaping scheme. Technically the export is simple, but Petersburg has its own specifics: the city is large and densely mapped, so "take it all at once" is almost always a mistake. Let's look at how to limit the area, which layers to keep and which coordinate system to choose so that the file stays workable.

Why you shouldn't take the whole city

DWG stores every house, every driveway and every path as a separate primitive. Petersburg is mapped in detail in OpenStreetMap: buildings, courtyard driveways, embankments, canals, greenery, tram tracks. Within the city boundary that's hundreds of thousands of objects, and the outcome is predictable — a file of hundreds of megabytes that takes minutes to open, lags while panning and is barely usable.

It's more practical to slice the task:

1. A block or the site surroundings — for a working drawing and a site plan.
2. A district or municipal okrug — for transport and urban planning schemes.
3. The whole city — only for an overview scheme, and then lower the detail level: arterial roads and major objects instead of every driveway.

If you do need the whole city in detail, export it district by district and assemble the parts with external references into one master drawing: that way each file stays light.

Which layers to take

The file arrives sorted into AutoCAD layers: roads and streets, buildings, water bodies, green areas, railways, points of interest. For an underlay the first four are usually enough: roads, buildings, water and greenery give full, recognisable context. Points of interest and minor categories more often get in the way — switch them off right after opening.

Layer names come out in the interface language the export was made in: with an English interface the layer manager shows Roads and Buildings, with a Russian one «Дороги и улицы» and «Здания». If the file is going to a colleague on a different locale, agree on one language and export in it.

A useful habit: freeze the underlay layers immediately after import (LAYFRZ or the lock in the layer manager) and dim their colour. Then someone else's geometry won't grab your object snaps while you draw.

Coordinate system: local or UTM

The key export parameter. OpenStreetMap data natively sits in WGS84 (EPSG:4326) — in degrees, so without reprojection into metres the drawing ends up a fraction of a unit across and DIST and AREA report values in degrees; the mechanics are covered in exporting OpenStreetMap to DWG for AutoCAD.

The options for Petersburg:

• A local coordinate system. Petersburg design practice talks about the city grid descended from SK-1964. In the export list it corresponds to a Gauss-Krüger zone marked ~MSK-78 (Leningrad Oblast gets ~MSK-47). The tilde is honest: this is an approximation of the local grid, not the grid itself, because the official parameters of regional MSK systems are not published. The number is the region code — 78 for Petersburg, while MSK-64 is Saratov Oblast and has nothing to do with the city. If the brief names a specific local system with parameters, enter it as your own proj4 or WKT in the custom CRS field. Either way, check the fit against a known point — a building corner or a junction whose coordinates you have from the project.
• UTM zone 36N (EPSG:32636). A universal metric projection, fine when there's no strict requirement: distances and areas come out in metres straight away.
• WGS84. Keep it only if the file goes into GIS or a web map rather than into a drawing.

How MSK zones are arranged and how they relate to UTM is covered in UTM and MSK zones in Russia.

Detail level and file weight

The detail level affects the result more than it seems. At a high level every polyline vertex is kept — outlines are precise, but there are a lot of objects. At a reduced level geometry is simplified: the shape of blocks and streets still reads, while the weight drops several times over.

The rule of thumb: an underlay for a working drawing — maximum detail over a small area; an overview scheme — reduced detail over a large one. Try a smaller area first: rebuilding an export is faster than waiting for an overloaded file to open.

Opening in AutoCAD, nanoCAD and BricsCAD

1. Open the file and run ZOOM E — you'll see the whole exported area.
2. Check the units with UNITS: decimal, one drawing unit equals one metre with a metric projection.
3. Run AUDIT and PURGE — this clears unused entities and speeds up work with a large file.
4. Attach the underlay as an external reference (XREF) at point 0,0 with scale 1 rather than pasting it into the model: that makes it easy to swap for a fresher export.
5. If you work in nanoCAD, BricsCAD, ZWCAD or KOMPAS rather than AutoCAD, DXF is safer — the text interchange format is read by everything. What actually sits inside a DWG and why format versions differ is described in the DWG deep dive.

OpenStreetMap data is collected by a community: excellent as context and an underlay, but not a substitute for a topographic survey or official records.

Easier — get a ready file straight away

Select the part of Petersburg you need on the osm2cdr.ru map, choose DWG, set the coordinate system and detail level — and download a layered drawing. For approvals a PDF of the same area is handy — any recipient can open it without CAD.

Maps of other cities work the same way: Mariupol in AutoCAD and a map of Minsk in various formats.

In short

• The whole of Petersburg in DWG is hundreds of thousands of objects; take a district or block and assemble larger areas from parts via XREF.
• For an underlay the roads, buildings, water and greenery layers are enough; switch off the rest, and expect layer names in the export's interface language.
• Coordinate system — the ~MSK-78 zone (an approximation of the local grid, so check it against a known point) or UTM 36N; WGS84 only for GIS.
• Detail level drives file weight: maximum over a small area, simplified over a large one.
• Not AutoCAD — take DXF, read by nanoCAD, BricsCAD, KOMPAS and the rest.