Skip to main content

Moving features

Moving a feature changes its position without changing its type code, attributes, explosives, or relationships. The move can be physical (relocate the geometry on the map) or organizational (reassign the feature to a different layer). This lesson covers both. For the click-by-click flow, see Feature shapes → How to reshape a feature for geometry edits, and Features → How to view and edit a feature for the layer field on the Details tab. Bulk moves across many features at once live in Module 11.

Learning objectives

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

  • Distinguish a geometry move from a reshape
  • Reassign a feature to a different layer
  • Recognize the symptom of a feature on the wrong layer flavor
  • Anticipate the effect of either kind of move on prior analysis results

Moving versus reshaping​

Two distinct geometry edits:

  • Move — relocate the feature without changing its shape. Every vertex shifts by the same offset.
  • Reshape — drag individual vertices to change the outline. The feature's footprint changes; its anchor location may or may not.

Both are routine edits, and both invalidate any analysis that referenced the prior geometry.

Snapping during a move​

Snapping latches the moving feature to nearby reference points — other feature vertices, edges, or grid lines. It makes precision moves much easier (aligning a magazine to a known control point, for example), but it can also surprise you when a vertex you thought was free decides to attach to a nearby edge. Toggle snapping off when you need true free-form placement.

Changing a feature's layer​

Moving a feature to a different layer is the other kind of move. The geometry stays put; only the layer assignment changes. The layer field is on the Details tab of the feature dashboard.

The reason this matters separately from a geometry move is layer flavor — the layer's flavor determines whether the feature participates in analysis at all. A magazine on a background layer produces nothing: no arc, no result entry, not even an error. See Adding layers for the conceptual background.

The fix for a feature in the wrong layer flavor is always the same: reassign it to a layer of the right flavor.

tip

The feature retains its data when moving from a QD-visible layer to a background layer and back. This is a primary way to "turn facilities on and off" for analysis when desired.

Symptom of a wrong-flavor layer​

You expect a feature to appear in results, and it doesn't:

  • The feature has a type code, attributes, and explosives entered
  • It is not in the Requires Analysis list (which would indicate a missing input)
  • It simply isn't in results at all

That silent omission is the signature of a wrong-flavor layer. Check the layer assignment before assuming the engine is broken.

Effect on analysis​

Any move — geometry or layer — invalidates the analysis. Required distances may not change much for a small geometry move (10 feet usually doesn't), but the engine cannot know that without re-running. After moving, re-analyze before reading any results.

For features with assigned fronts, a geometry move that significantly rotates the feature may invalidate the front. Re-confirm the front orientation after a move that involves rotation.

Try it​

In an analyzed project:

  1. Move a PES by a small distance and confirm the Calculate button surfaces a stale-results indicator. Re-run analysis and inspect the feature's Calculations tab.
  2. Reshape one vertex of an ECM-style feature and re-run; verify the segments and arcs respond to the new geometry.
  3. Add a PES with explosives to a background layer (intentionally — practice the symptom). Confirm the PES produces no arc. Reassign the feature to a QD-visible layer (Details tab → Layer) and re-run; the arc appears. Move it back to the background layer and re-run; the arc disappears.