Skip to main content

ESS imports

ESS exports can be brought into Siter as a starting point for an evaluation. Imports preserve facility geometry, type codes, and explosive entries; conventions that differ between the two systems are reconciled during import or surface for manual review afterward.

Learning objectives

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

  • Prepare an ESS export for import into Siter
  • Run the import and verify the resulting project
  • Identify which fields require manual review after import

What ESS imports cover​

[TODO: FILL IN — list of supported ESS export formats and the data each carries. Confirm version coverage (which ESS versions Siter accepts).]

A typical ESS-to-Siter import preserves:

  • Facility geometry
  • Facility type codes (mapped to Siter's type-code taxonomy)
  • Explosives by hazard division
  • Some attributes (those that have direct Siter equivalents)

It typically does not automatically carry:

  • Result sets or stored analysis output (re-run after import)
  • Drawings (regenerate after import)
  • Sharing or user-permission state

[TODO: FILL IN — confirm the preserved-vs-not list against the current Siter import behavior.]

Pre-import preparation in ESS​

[TODO: FILL IN — any export-side steps the user takes in ESS to produce a Siter-compatible export: format selection, scope choice, version selection.]

Running the import​

[TODO: FILL IN — exact UI flow in Siter for ESS import: menu path, file picker, any per-import options for type-code mapping or attribute reconciliation.]

Reviewing after import​

ESS-to-Siter is rarely a 100% lossless transition — the two systems express some concepts differently. Plan for a review pass after import:

  • Type-code mappings — verify each imported feature has the correct Siter type code. ESS facility classifications do not always map 1:1.
  • Attributes — many ESS attributes do not have direct Siter equivalents. The import may leave attributes at defaults; bulk-edit to bring them to actual values.
  • Relationships — confirm the imported relationships use the correct relationship code under Siter's taxonomy (unrelated, related, sameline, integral, idsessential).
  • Fronts — multi-face features that needed orientation in ESS may need fronts reassigned in Siter.
  • Run analysis — the first run after import is the real verification. Differences from ESS results are expected (the engines are different) but should be explainable.

[TODO: FILL IN — specific known mappings or gotchas for ESS-to-Siter type codes and attributes.]

When the import looks wrong​

If the imported project produces results that diverge significantly from the ESS source:

  1. Check type-code mappings first — a mis-mapped type can produce dramatically different arcs
  2. Check the relationship codes — unrelated vs related vs sameline produces large swings
  3. Check attribute completeness — defaults may be more conservative or less conservative than the ESS values
  4. Check the criteria-engine version — ensure both Siter and the source ESS reference the same edition of the criteria

If results still diverge after these checks, walk a single pair through the analysis path to see exactly which step the engines disagree on.

Try it​

Take a small ESS export (one or two facilities) and import it into a Siter project:

  1. Run the ESS export from the source system
  2. Run the Siter import flow
  3. Review type codes, attributes, and relationships — fix anything that didn't transition cleanly
  4. Run analysis and compare results to the ESS source
  5. For any divergence, walk the analysis path and identify the engine's reasoning