An alarm points to a hidden device: floor filters and location in a digital twin
Finding an object is not the same as showing it. Resolve access, floors, filters, occlusion and camera framing in an agreed order, with a way back to the prior view.
On this page5 sections
If an alarm link reports successful location but the equipment remains invisible, inspect the location workflow rather than adding another camera flight. The object may belong to a hidden floor, be excluded by a filter, sit behind a building shell or remain unloaded. Confirm the user's access first, then decide how the interface should reveal the target.
Break location into observable steps
A useful sequence is to resolve the object, check access, load its area, reconcile floors and filters, frame the camera, and select the detail view. Each failed step should report its actual outcome, such as missing mapping, unloaded area or restricted access. A generic success message cannot show where the process stopped.
Location does not always require clearing every filter. When the user is viewing Floor 1 and the target is on Floor 2, the application can temporarily switch floors and make the change apparent. If the user has deliberately locked an analytical scope, it may instead show the target location and ask for an explicit jump. Choose behavior according to the task and apply it consistently across entry points.
Distinguish hidden, obstructed and missing objects
| Condition | Possible action | Unsupported conclusion |
|---|---|---|
| Hidden by a floor or parent | Temporarily reveal the required hierarchy | Enabling the child alone makes it visible |
| Excluded by the active filter | Reveal temporarily or explain the exclusion | The object does not exist |
| Behind a building shell | Use agreed sectioning, transparency or camera framing | Correct coordinates complete the task |
| No model mapping | Keep list details and location information available | A similarly named object is the correct target |
The Cesium Entity documentation explains that show is affected by parent visibility and isShowing considers ancestor entities. That API state still does not prove that the object is inside the viewport or unobstructed. The actual scene and selection behavior need visual verification.
Keep the list and scene on the same object
Use a stable identifier for selection. When a device is chosen in the list, its highlight, name, floor and detail panel must all describe that device. Selecting it in the scene should also locate the corresponding list item. Names alone are unsuitable when several devices share a label.
The current alarm and the equipment's operational state may differ. Locating the model answers where to look; it does not establish that an alarm has been handled. Temporary visibility adjustments must not reveal detail that the user is prohibited from accessing. Treat display filtering and access control as separate concerns throughout the workflow.
Restore the previous task after location
Before the jump, retain the floor, filters, camera, selected list item and reading position. An intentional return can restore that context instead of always sending the user to a campus overview. If models or data change in the meantime, apply a reasonable fallback for state that no longer exists, rather than restoring an invalid relationship silently.
Repeated clicks need a rule too. If a user selects a second alarm while the first area is still loading, the second target should remain the active task. The first load or camera animation must not later take control again. Decide whether manual camera movement cancels automatic location, so that the system does not repeatedly pull the user back.
Accept location using targets that are genuinely hidden
Prepare targets on another floor, outside the filter, inside a shell, sharing a name, lacking a mapping and outside the user's permission. Test entry from lists and scenes, cancellation, repeated location and return. Record whether users can actually see and select the target, not merely whether coordinates or a success message are produced.
How to Accept a Digital Twin Project covers the general acceptance scope and How Should Dashboard UI Design and 3D Modeling Work Together? addresses coordination between space and interface. For digital twin development services (Chinese), turn the location sequence and restoration rules into a practical test script. Execute it on the target phone and desktop with the real model structure; a demonstration in an empty scene does not establish usability across a complex building.