This article is an introduction to the concept of location and hierarchy of locations in the platform.
Contents of this article:
- Location definition
- Location Configuration
- Hierarchy of locations definition
- Filtering locations in the analysis screen
Locations are the units that the platform uses to organise the inserted data and display it in a defined way. A location might represent a city, a factory, a building, a floor, an apartment, a room... This will depend on the project, i.e. the user can choose what exactly a location means to them.
Locations must be organised in a hierarchy, where each element will be linked to a so-called parent, which will define the way through which the devices can be analysed in the platform once they have been created.
There are four types of elements inside the hierarchy:
- Root: The highest element in the hierarchy, present in every account. This element cannot be removed as it literally represents the whole account.
- Zones: Zones are mainly used to differentiate groups of facilities/buildings. For example, a zone could represent a city. Then, the elements underneath this zone would be the monitored buildings in that specific city.
- Locations: Locations are the most useful elements inside the hierarchy of locations. They represent the facility being monitored.
- Sub-locations: Sub-locations may represent a portion of a location, e.g. a floor inside a building.
In the following image, an example of the possible distribution of different elements in the hierarchy of locations is shown:
As it can be seen, there can be multiple zone levels (a zone may have another zone as a parent); only one location level (a location cannot have another location as a parent); multiple sub-locations levels (a sub-location may have another sub-location as a parent), which leads to the following possibilities in the hierarchy parents organisation:
Please note that it is not compulsory to configure each of these elements in a project. If in a project sub-locations might not add value, then it is not necessary to configure them.
Another important difference between the locations' elements are the features that can be associated with them:
The elements that should be configured in a location are the following, together with its purpose:
|Region parent||Build the hierarchy of locations|
|Area||KPI for surface (automatically created)|
|Reference temperature||Degree-Days calculation (automatically calculated if temperature data is received)|
|Tags||Filter the data included in the platform and benchmark buildings easier|
|Address||Display and benchmark different locations in a map|
- Dashboards creation
|Assign supplies and prices||
Calculate the energy cost of your devices
Calculate consumption that is not being monitored inside the facilities, such as Remainder Consumption or Total Consumption
In order to learn more about locations' configuration, zones and sub-locations, visit our article.
Hierarchy of locations definition
It is really important to correctly define the hierarchy of locations in order to enhance the benchmarking capabilities offered by the platform. Depending on the project you are working on, your hierarchy of locations will include a different number of elements. This means that you should apply different strategies for each project you are working on, as different strategies are going to be needed to analyse each of them.
So, what should be taken into account while deciding the best hierarchy of locations? Check out our article Understanding the hierarchy of locations to find out!
Filtering locations in the analysis screen
If you have already decided how to organise your hierarchy of locations, you might be wondering if there are other tools to choose and filter the devices that can be benchmarked in the analysis screen. The hierarchy organisation will determine the available devices you have once you select an element inside the hierarchy.
However, this selection can also be combined with the use of tags, which will filter even more the selection of devices that can be represented.
Tags are configured inside locations and sub-locations, which means that they do not apply to Zones or the Root.
If you are interested, do not hesitate to learn more about filtering and tags!