FMS - Data Specifications

Owned by Robert Cox
Last updated: 15 Mar, 2024 by Lasse Rasmussen Fosse
5 min read

 

 

About

MazeMap hosts a service that allows customers to push data from their Facility Management System for updating the maps directly. This service offers two interfaces for the customer to choose from; either they upload data using SFTP or via REST API.

The data must follow a predefined format: a building manifest that lists campuses, buildings, floors, and connects drawings to floors, as well as a list of points of interest (POI list) with room data. Additionally, new floor plan drawings in DWG or IFC formats (depending on the customer’s set up) can be uploaded.

This document provides the specifications of the types of data that needs to be provided to MazeMap for the automatic update of POI data and Drawings via our SFTP - FMS Integration.


For FMS updates via SFTP, documentation for this can be found here:

FMS-SFTP Setup and Connection Guide

For FMS updates via REST API, documentation for this can be found here:

MazeMap Updates API (DRAFT)

CSV Files Requirements

 

  • The delimiter must be comma

  • Must use double quotes to surround a column value if it contains commas

  • Must be encoded with Unicode (UTF-8).


Building Manifest File 

 

The Building Manifest (Building_Manifest.csv) describes each floor and links them to campus, building and drawing. It must contain the following columns (case and spelling must match exactly, but the order does not matter):

 

*Required

Column name. 

Description. 

Required

MazeMap Searchable

JS API Exposed

FILENAME

Name of the drawing file. Can contain more names separated by a slash ( / ). The .dwg extension must be included.

Yes

No

No

CAMPUS_ID

The ID-number for the campus, generated by the FMS. It should contain unique identifiers from the customer’s FMS.

Yes

No

Yes

CAMPUS_NAME

Name of the campus. It should contain human readable names for those entities.

 

Yes

No

Yes

BUILDING_ID

The ID-number for the building, generated by the FMS. It should contain unique identifiers from the customer’s FMS. It should contain human readable names for those entities.

Yes

No

Yes

BUILDING_NAME

Name of the building. 

Yes

Yes

Yes

FLOOR_ID

The ID-number for the floor, generated by the FMS. It should contain unique identifiers from the customer’s FMS.

Yes

No

Yes

FLOOR_NAME

Name of the floor.  It should contain human readable names for those entities.

Yes

No

Yes

LAT_COORDINATES

Latitude coordinates of the centroid of the building

No

No

No

LONG_COORDINATES

Longitude coordinates of the centroid of the building

No

No

No

 

NB: The order of how these columns are arranged does not matter. However it is important to note that the form is case-and spelling-sensitive that the file MUST be named Building_Manifest.csv 

Example;

 

For IFC Drawing files – BUILDING_ID and FLOOR_ID (maps to a BuildingStorey in IFC) should correspond to the IDs in the ifc file.

 

Point Of Interest File

 

The Points of Interest list (POIList.csv) describes each room in the customer’s system and links them to the floors defined in the building manifest. It must contain the following columns (case and spelling must match exactly, but the order does not matter):

 

*Required

Column name

Description

Required

MazeMap Searchable

JS API Exposed

CAMPUS_ID

The ID-number for the campus, generated by the FMS. It connects a POI to a campus defined in the building manifest.

Yes

No

Yes

BUILDING_ID

The ID-number for the building, generated by the FMS. It connects a POI to a building defined in the building manifest.

Yes

No

Yes

FLOOR_ID

The floorplan that contains the POI. It connects a POI to a floor defined in the building manifest.

Yes

No

Yes

ROOM_ID

The ID-number for the room, generated by the FMS. Must be a unique value. 

Yes

No

Yes

TITLE

Text that will be displayed as the title of the POI on the POI Information card.

New field added 3/10/2022

No

Yes

Yes

TEXT_DISPLAY_ON_MAP

Text that will be displayed on the map. If this column is empty the value in the ROOM_ID column will be used as the label in the map.

No

No

Yes

ROOM_TYPE

Type of room. Can contain more values separated by /

NOTE: If the text contains a /, replace it with a %.

i.e. SEMINAR/VIDEO → SEMINAR%VIDEO

No

No - Only matched MM POI Type

No - Only matched MM POI Type

EXTRA_SEARCH_WORD

Add search words. Can contain more words separated by /

No

Yes

Yes

LINKABLE_IDENTIFIER

<LINKABLE_IDENTIFIER>

The unique code / key that is used to identify the POI in your FMS system.

No

No

No

EXTERNAL_REFERENCES

Can contain one or more references for use with external systems.
A single external reference has the format ‘type;vendor;value’. It is possible to have multiple external references per room. Multiple external references should be separated by the forward-slash character ( / ). Some external references may contain the forward-slash character so as a rule of thumb, each external reference should be url-encoded. 

E.g.   Given the following external references,

  • room_booking;google;

  • room_booking;outlook;

  • room_booking;time_edit;

  • room_booking;office_app;

  • room_booking;planon;

  • occupancy_senso;iaconnects;

  • occupancy_sensor;johnsoncontrols;

  • occupancy_sensor;iotspot;

  • occupancy_sensor;sensorapi;

  • occupancy_sensor;dnaspaces;

  • occupancy_sensor;planon;

  • library_shel;alma;

  • webex;webex;

  • link_insertion;outlook;

  • ellucian;ellucian;

Each of them should be url-encoded like so...then separated by forward slashes ( / )

  • occupancy_sensor%3Biaconnects%3BA%2FB%2FC%2FD

Even single-value external references should be url-encoded as a rule of safety. Generally the idea is that, since we use the forward slash ( / ) as a separator, external references that could possibly contain forward slashes are unsafe...hence the url-encoding.

No

No

No

INFO_URL

 

Show more information about a POI containing an absolute url to a web site with additional, relevant information about the POI.

No

No

Yes

INFO_URL_TEXT

Can contain link text that will be displayed instead of the raw url provided in the INFO_URL column.

No

No

Yres

DESCRIPTION

Can contain a plain description of the POI.

No

No

Yes

PEOPLE_CAPACITY

Shows how many people can be accommodated inside the room based on the current person per sqm ratio

No

No

Yes

NB: The order of how these columns are arranged does not matter. However, it is important to note that the form is case-and spelling-sensitive and that the file MUST be named POIList.csv

 

Example:

Skærmbillede 2024-03-15 kl. 10.03.26.png

 

Drawing Requirements

DWG Drawings

Drawings need to be stored and uploaded in the DWG (Drawing) file format, used for storing design data and metadata. DWG files are the native format for several Computer Assisted Drawing (CAD) packages. The names of the DWG Files need to match the values in the FILENAME (a.) column in the Building manifest file (3.2). Note that the file extension (.dwg) is included in the filename in the manifest file. 

 

DWG Drawings must confirm to MazeMaps DWG Files Guidelines

IFC Drawings

IFC (Drawing) files are also supported. The names of the IFC Files need to match the values in the FILENAME (a.) column in the Building manifest file (3.2), however the file uploaded to the sftp server must have the extension “.ifc”. Note that the file extension (.ifc) is included in the filename in the manifest file.