Skip to content

Site & survey import

The Site & survey import tool (Tools ▸ Site & survey import…, or Cmd/Ctrl-K → "site") reads georeferenced files - GIS layers and land-survey data - and uses them to set site inputs: a location, an AS/NZS 1170.2 wind region, an AS 2870 site class, and viewport context geometry. One modal, four sections, each independent.

Offline, no embedded hazard data, prefill only

This tool is offline and file-driven - nothing is sent anywhere. It ships with no embedded wind-region or soil-classification map: the region and site-class threads only classify a point against a polygon layer you load, because a wrong wind region (Region A vs the C/D cyclonic zones) is a life-safety error and the authoritative boundaries must come from a source you trust. Every value the tool derives only prefills a wizard field you can override - it is never used silently in a design result, and every result is flagged verified: false until you confirm it against the standard (or, for site class, a geotechnical report).

1 · Site location

Set the site's latitude and longitude either by typing them in directly, or by clicking From KML / GeoJSON point… to extract a coordinate from the first point placemark/feature found in a file. This location is what sections 2 and 3 classify against.

2 · Wind region (AS/NZS 1170.2)

Load region layer… reads a GeoJSON or KML polygon layer. Classify & set Wind wizard tests the site location against those polygons (point-in-polygon) and, on a match, sets the Wind loads wizard's region dropdown and opens it, with a banner: "Region <code> -> Wind wizard set to <X>. verified:false - confirm against Figure 3.1." If the site falls outside every polygon, or inside more than one, the tool tells you and asks for a manual selection instead of guessing.

The region map is not embedded in CivilKit - you load your own authoritative layer (see layer preparation below). Manual selection in the Wind wizard always stays the authoritative path; this tool only saves you looking the region up by hand.

The classified region code is mapped to the wizard's coarser option set: A0-A5 -> A, B1/B2 -> B, and C/D pass through unchanged. NZ codes (A6, A7, W) pass through as-is if the layer supplies them. A code that isn't one of the wizard's options is reported rather than silently forced onto the nearest one.

3 · Site class screening (AS 2870)

Load soil / class layer… reads a GeoJSON or KML polygon layer and populates a class attribute dropdown from the attributes found on its features. Pick the attribute that holds the classification, then Screen & set Footing wizard tests the site location against the polygons and reads that attribute at the match.

This is indicative only - not a substitute for a site-specific geotechnical investigation (AS 2870 Cl 2.2). The banner is deliberately loud: "PRELIMINARY class <X> from the map - INDICATIVE ONLY, not a substitute for a site-specific geotechnical investigation (AS 2870 Cl 2.2)." The value is normalised to an AS 2870 token (A/S/M/H1/H2/E/P, with -D deep variants) where it matches that pattern; an unrecognised coding is surfaced verbatim rather than guessed at. If it isn't one of the Footing wizard's options, you're told to set the class manually.

4 · Survey geometry

Import survey (CSV E,N,RL / GeoJSON / KML)… brings in:

  • Point CSV - a header row with Easting/Northing/RL (or similar) column names is auto-detected; without a header, the first three numeric columns are read as E, N, RL. An optional code/description column is carried through as a point label.
  • GeoJSON / KML - points and line/polygon boundaries import as plan-level (RL = 0) context.

Imported geometry is added as non-structural viewport context - it never becomes structural nodes or members, participates in analysis, or gets exported with the model - the same treatment the IFC importer gives slab/wall context. It shows/hides via the View menu, alongside the model, and recenters with it.

Coordinates are reduced to a local origin (the first point, or the layer's own origin) before display, so a raw MGA/GDA2020 easting in the millions doesn't throw the viewport out to infinity.

Preparing a layer

The wind-region and site-class threads both classify a point against polygons you supply - CivilKit does not ship an authoritative map for either. A layer needs to be:

  • GeoJSON (.geojson) or KML (.kml), of polygons, in WGS84 lon/lat (the format both use by default).
  • Carrying an attribute that names each polygon's class:
    • Wind region - an attribute such as region / REGION / WIND_REGION holding the AS/NZS 1170.2 region code (A0-A5, B1, B2, C, D, or NZ A6/A7/W). This one is auto-detected from common attribute names.
    • Site class - an attribute such as SITE_CLASS / CLASS holding an AS 2870 class. You choose which attribute to read from a dropdown built from the file's own attributes, since site-classification exports vary more than region maps do.

A worked example with a single, clearly non-authoritative polygon ships at studio/geo/assets/as1170.2-wind-regions.template.geojson to show the expected shape - replace it with a real, verified layer before relying on any result.

File formats & coordinates

InputFormatsCoordinate assumption
Site location / region / soil layersGeoJSON, KMLWGS84 lon/lat (GeoJSON and KML's native datum)
Survey pointsCSV (comma/tab/semicolon)Easting/Northing/RL in metres, any projected grid - reduced to a local origin, not reprojected
Survey boundariesGeoJSON, KMLWGS84 lon/lat, converted to local metres about the site origin

Try it with the example files

A set of example files (all around a Brisbane / eastern-coast site) ships with the app under web_demo/studio/geo/assets/examples/:

FileSection
brisbane-location.geojsonSite location (a point placemark)
example-wind-regions-eastern-au.geojsonWind region (classifies the site as B)
example-site-class-brisbane.geojsonSite class screening (classifies as M)
brisbane-site-survey.csvSurvey geometry (16 points in MGA/GDA2020 zone 56)

Load the location file first, then the region and soil layers, then the survey CSV, to walk all four sections. The wind-region and site-class layers are clearly-labelled example rectangles, not authoritative maps - they exist to exercise the mechanism, not to classify a real site.

Scope and limitations

Not yet handled (named follow-ups, not silent gaps):

  • Shapefile (.shp) import - binary, multi-file; GeoJSON/KML cover the common GIS export paths for now.
  • A full EPSG/projection engine - reprojecting between MGA/GDA2020 eastings/northings and lat/lon is out of scope; survey CSV coordinates are reduced to a local origin, not reprojected, so mixing a projected grid with a WGS84 layer in the same import isn't supported.
  • DEM / topographic data - no raster surface import, so the wind wizard's topographic multiplier Mt is not derived from terrain.
  • Land-use -> terrain category - the wind wizard's terrain category is still a manual choice.
  • Online basemaps or geocoding - everything is file-driven; there is no address lookup or map tile background.

See the wind loads and residential footings pages for what the prefilled region and site class feed into, and their own verified: false scope notes.