Solved: WSD Indoor Mapping Floors Showing on Top of Each Other in Manage Directions

Edwin5 · an hour ago

Sharing a solution for a ServiceNow WSD / Indoor Mapping issue where places from one floor appeared on another floor in Map Studio / Manage Directions, even though the CAD files and floor assignments were correct.

We recently worked through this issue, and at first it looked like a CAD or georeferencing problem. The actual cause turned out to be in the Indoor Mapping Place data.

THE SYMPTOM

In a multi-floor building, selecting Floor 2 in Manage Directions would still display room markers and places from Floor 1.

Visually, it looked like the two floors had been imported on top of each other.

Our first assumption was that the CAD files had been imported incorrectly or that both floors had been georeferenced to the same location. That was not the case.

WHAT WE CHECKED FIRST

Before changing anything, we validated the normal suspects:

sn_map_core_floor
sn_map_core_place
sn_map_core_layer
AutoCAD sources
Generated fc.geojson attachments
WSD space synchronization records
Place Properties
Browser cache using Incognito
Map Studio View configuration
Floor numbering and source-to-floor relationships

The CAD files were correct. Each AutoCAD source belonged to the correct floor, and the generated Indoor Mapping geometry was also associated with the correct floor.

We also inspected the generated GeoJSON and confirmed that the actual floor geometry was not being mixed.

That was when this stopped looking like a CAD problem.

THE CLUE THAT LED TO THE ROOT CAUSE

The issue became clear when we inspected the requests Map Studio was making while switching between floors.

In our environment, the Place request used by Map Studio was effectively returning records associated with the selected Floor OR Campus.

Some affected floor-specific Indoor Mapping Place records looked like this:

sn_map_core_place
Name = 126A
Floor = FLOOR 001
Campus = Example Campus
Active = true

Places that were behaving correctly looked like this:

sn_map_core_place
Name = 216
Floor = FLOOR 002
Campus = blank
Active = true

The Floor 1 places had both Floor and Campus populated.

Because those records also qualified as campus-associated places, Map Studio could return them while Floor 2 was selected. That is what made the floors appear to overlap.

THE IMPORTANT DISTINCTION

There are two different records involved here.

The WSD Space record should still keep its normal location hierarchy:

Campus
-> Building
-> Floor
-> Space

For example:

sn_wsd_core_space
Campus = Example Campus
Building = Example Building
Floor = FLOOR 001
Space = 126A

We did not remove Campus from the WSD Space record.

The correction was made only to the underlying Indoor Mapping Place:

sn_map_core_place
Floor = FLOOR 001
Campus = blank
Active = true

This allowed the place to remain associated with its correct floor without also being returned as campus-level content.

HOW WE PROVED IT BEFORE MAKING A BULK CHANGE

We did not start with a bulk update.

We selected one affected room and cleared only the Campus field on its sn_map_core_place record.

Before:

Name = 126A
Floor = FLOOR 001
Campus = Example Campus

After:

Name = 126A
Floor = FLOOR 001
Campus = blank

We refreshed Map Studio and tested both floors.

Floor 001 selected - 126A still displayed correctly
Floor 002 selected - 126A no longer displayed

That confirmed the cause before we touched the remaining records.

We later found the same condition in another multi-floor building and corrected it there as well.

QUICK READ-ONLY CHECK

If you are experiencing similar behavior, you can filter sn_map_core_place using:

active=true^floorISNOTEMPTY^campusISNOTEMPTY

This identifies active Indoor Mapping Places where both Floor and Campus are populated.

I would treat these as candidates for investigation, not automatically as bad records.

You can also use this read-only background script:

var gr = new GlideRecord('sn_map_core_place');
gr.addQuery('active', true);
gr.addNotNullQuery('floor');
gr.addNotNullQuery('campus');
gr.query();

while (gr.next()) {
  gs.info(
    'Place=' + gr.getValue('name') +
    ' | Floor=' + gr.getDisplayValue('floor') +
    ' | Campus=' + gr.getDisplayValue('campus') +
    ' | Source=' + gr.getDisplayValue('source')
  );
}

WHAT I RECOMMEND BEFORE CHANGING ANYTHING

Test one record first.

Confirm the place is truly floor-specific.
Confirm its Floor is correct.
Confirm its AutoCAD source is correct.
Confirm its geometry is correct.
Confirm the corresponding WSD Space hierarchy is correct.

Then clear Campus only on the sn_map_core_place record and test again.

Do not clear Campus from sn_wsd_core_space.

If the place disappears from the incorrect floor while remaining visible on its assigned floor, you likely have the same condition.

ONE MORE THING WE LEARNED

Repeated map imports can leave behind inactive layers, older place generations, and sometimes duplicate Floor records.

Those are worth reviewing separately, but in our case they were not the cause of this particular floor-overlap issue.

That distinction saved us from unnecessarily rebuilding and re-importing the CAD files.

FINAL TAKEAWAY

If Indoor Mapping looks like two floors were imported on top of each other, do not immediately assume the CAD is wrong.

Check the relationship between sn_map_core_place.floor and sn_map_core_place.campus.

In our case, the corrected pattern was:

WSD Space
Campus = populated
Building = populated
Floor = populated

Indoor Mapping Place
Campus = blank
Floor = populated

After correcting the affected Indoor Mapping Place records, floor switching in Manage Directions worked normally across the affected multi-floor buildings.

Hopefully this saves someone else a few hours of troubleshooting CAD files, GeoJSON, layers, synchronization records, and georeferencing.