Skip to main content

Importing layers

Layer imports bring vector data from external sources into Siter as a new layer — typically reference content from a .dwg, shapefile, or GeoJSON exported from another GIS tool. This lesson covers the format and projection requirements you need to satisfy before an import will succeed. For the click-by-click flow, see Layers → How to import a layer.

Learning objectives

By the end of this lesson you should be able to:

  • Pick a supported format for the source data
  • Project source data into a CRS Siter will accept
  • Package a shapefile correctly for import
  • Configure the import (flavor, default type code, name column) at the dialog
  • Spot-check the result and correct outliers with bulk editing

Supported formats​

Siter accepts two layer-import formats:

FormatSourceNotes
GeoJSONA single .geojson filePreferred for round-trips with another Siter project or for GeoJSON-native tools
ShapefileA .zip archive containing the full sidecar setThe interchange format for most legacy GIS data

Other vector formats (KML, GeoPackage, raw .dwg, etc.) need to be converted upstream — typically via QGIS — into one of these two before importing.

Projection requirements​

FormatAcceptable projection
GeoJSONUTM zone or WGS 84 latitude/longitude (EPSG:4326)
ShapefileAny projection supported by proj4 — Siter converts on import using the shapefile's .prj

For GeoJSON, reproject your source in QGIS to UTM or WGS 84 before exporting if it lives in any other CRS. For shapefiles, ensure the .prj sidecar is present and accurate — without it, the import has no way to interpret the coordinates and will reject the file.

Packaging a shapefile​

A shapefile is not a single file but a bundle of sidecars that all need to travel together. Minimum required set:

FilePurpose
.shpGeometry
.shxGeometry index
.dbfAttributes
.prjCoordinate reference system

Optional but commonly present: .cpg (character encoding for non-ASCII attribute text).

Package the sidecars into a single .zip archive with files at the root of the zip — not in a subdirectory:

my-shapefile.zip
├── parcels.shp
├── parcels.shx
├── parcels.dbf
└── parcels.prj

Loose individual files will not import; nested directories will not import.

tip

Siter can see multiple shapefiles per .zip as well as nested folder structures. If you have a lot of layers to examine and bring in, just .zip them all together if you wish

What you pick at import time​

The import dialog asks for three things up front, applied to every feature in the imported layer:

ChoiceWhat it does
Layer flavorQD-visible or background — see Adding layers. Reference content (CAD line work, parcel boundaries) usually wants background; explosive facilities imported from another QD source usually want QD-visible.
Default feature type codeThe type code applied to every imported feature. Pick the type code that fits the majority of the layer's contents; outliers can be corrected after the import via Bulk feature editing.
Name columnThe attribute column from the source data to use as each feature's name in Siter. Pick a column with stable, human-readable labels.

Get these right at import time and the post-import work is mostly review rather than rework.

Siter assigns its own internal feature indexes — you don't need to think about that.

After the import​

Once the layer is in:

  1. Spot-check a few features — confirm the chosen name column populated as expected, and that the default type code fits the actual content.
  2. Correct outliers with Bulk feature editing — for the features that don't match the default type code, or that need attribute values different from defaults.
  3. Assign fronts via Facility fronts for any multi-face PES (e.g., ECMs) before re-running analysis.

Try it​

Take a small shapefile from any source — a parcel layer from a GIS department, a building footprint export from CAD:

  1. Confirm the .prj is present and accurate
  2. Package the sidecars into a single .zip with files at the root
  3. Import into a Siter project, picking the right flavor, default type code, and name column at the import dialog
  4. Spot-check the imported features — confirm the name column populated and the default type code fits
  5. Run analysis and confirm the imported features participate as expected (or are correctly silent if you wanted them as background)

Repeat with a GeoJSON export from QGIS, ensuring the CRS is WGS 84 before exporting. Confirm the round-trip lands cleanly.