---
title: Custom Locations
id: "en:tpm:ROOT:custom_locations.adoc"
site: en
component: tpm
module: ROOT
version: 3.0
lang: en
url: "https://help.rtlscloud.io/en/tpm/3.0/custom_locations.html"
source_repo: "https://github.com/iot-invent/rtlscloud-tpm.git@3.0.x"
source_path: docs/en/modules/ROOT/pages/custom_locations.adoc
---

# Custom Locations

Your own position database: mobile network cells, WiFi access points and beacons whose position you know. Where the application finds a match here, it needs no online service.

-   Three tabs: **Cells**, **WiFis** and **Beacons**

-   Create, edit, import and export positions

-   Exclude disruptive WiFi access points through the **Ignored** status

-   Mark a beacon as **Gateway** so it locates other devices as well

## Reference

![Custom Locations](_images/tpm_app_custom_locations.png)

| Module | Description |
| --- | --- |
| Tab | Switches between **Cells**, **WiFis** and **Beacons**. All actions apply to the active tab |
| ![refresh](_images/refresh.svg) Refresh | Reloads the list |
| ![filter](_images/filter.svg) Filter | Restriction by identifier |
| ![plus](_images/plus.svg) New | Starts the wizard for creating an entry |
| ![edit](_images/edit.svg) Edit | Opens the selected entry in the wizard |
| ![delete](_images/delete.svg) Delete | Removes the entry |
| ![export](_images/export.svg) Export | Exports the entries of the active tab |
| ![info](_images/info.svg) Info | Number of entries shown |

A double click opens the entry with its position on the map.

## Cells

A mobile network cell with a known position.

| Field | Type | Description |
| --- | --- | --- |
| Cell Id | Number | Identifier of the cell |
| MCC | Number | Mobile country code |
| MNC | Number | Mobile network code of the operator |
| LAC | Number | Location area code |
| Longitude | Number | Position of the cell |
| Latitude | Number |  |
| Accuracy | Number | Radius in metres the position is valid for |
| State | Selection | See [State](#state) |
| Notes | Text | Free text |

## WiFis

A WiFi access point with a known position. The most common and most effective means of improving positioning accuracy.

| Field | Type | Description |
| --- | --- | --- |
| Mac Id | Text | Hardware address of the access point |
| Name | Text | Network name (SSID), for recognition |
| Longitude | Number | Position of the access point |
| Latitude | Number |  |
| Accuracy | Number | Radius in metres |
| State | Selection | See [State](#state) |
| Notes | Text | Free text |

## Beacons

A BLE device with a known position.

| Field | Type | Description |
| --- | --- | --- |
| Mac Id | Text | Address of the device |
| Name | Text | Display name |
| Gateway | Yes/No | See [Gateway](#gateway) |
| Longitude | Number | Position of the beacon |
| Latitude | Number |  |
| Accuracy | Number | Radius in metres |
| State | Selection | See [State](#state) |
| Notes | Text | Free text |

### Gateway

A beacon with **Gateway = Yes** is a device that **sees other tags** and lends its own position to every one it sees.

A single registered beacon thereby locates everything within its range — those devices need no online request at all. The typical use case is a fixed device at a gate, a ramp or a storage area.

As long as a tag is seen by a gateway, the application asks no online service for it. This is deliberate: a second, independently resolved position would contradict the first, with no rule for deciding which one is right.

## State

| Value | Meaning |
| --- | --- |
| Enabled | The entry is used normally |
| Disabled | The entry is not used but is kept. Useful for not losing coordinates |
| Ignored | **Blocklist.** The observation is not processed locally at all — it is also **not sent to an online service** |

> **IMPORTANT:** Ignored is the tool against mobile hotspots.A phone or a vehicle router looks like a fixed access point to a device and pulls every position towards wherever it was last resolved. Excluding it only locally is not enough — as long as it is still sent to the online service, it keeps distorting the result. That is why Ignored excludes it completely.Excluded access points are shown as excluded in Decision events, so their absence remains explainable.

## Creating and Editing

The wizard has two steps:

1.  **Enter data** — the identifier and the master data of the entry.

2.  **Set position** — place the point on the map and set the accuracy radius.

If the identifier already exists in the current tenant, the wizard reports this when saving — a second entry for the same identifier makes no sense.

The faster path often goes through [Decision events](decision_events.md): there you create an entry directly out of a concrete event, with its identifiers already filled in.

## Import and Export

Both always refer to the **active tab**. Export delivers the filtered entries; import adds entries of the same type.

Import is the practical route when an existing list of access points or beacons is available — for example from network infrastructure documentation.