Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

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.

Info

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

FMS - SFTP Setup and Configuration

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

https://updates.mazemap.com/v1/docs/

...

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

...

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 /

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

...