> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/platform/guides/data-setup-guide/location-module.md).

# Location Module

Setting up boundary hierarchies for tenants

## Overview

The location module serves the boundary hierarchies for a tenant. Location is defined separately for every tenant (mostly ULBs) in DIGIT. Each tenant has a unique tenantId.

## Steps

The tenantId key can be a combination of `state` or `state.city` or `state.city.ulb`. The hierarchyType can be one of Revenue, Admin or Election. Multiple hierarchy types can be defined for the same city tenant.

{% code lineNumbers="true" %}

```
{
 "tenantId": "pb.amritsar",
 "moduleName": "egov-location",
 "TenantBoundary": [
   {
     "hierarchyType": {
       "code": "REVENUE",
       "name": "REVENUE"
     },
     "boundary": {
       "id": 1,
       "boundaryNum": 1,
       "name": "Amritsar",
       "localname": "Amritsar",
       "longitude": null,
       "latitude": null,
       "label": "City",
       "code": "pb.amritsar",
       "children":[
         {
```

{% endcode %}

The entire hierarchy can be defined in a nested way as children. One sample of location data for the Amritsar ULB is [available here](https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/amritsar/egov-location/boundary-data.json).

Location data is stored in GitHub as part of MDMS. The `egov-location` folder needs to be created inside the city tenant (see Amritsar example above). It is stored in the following format:

```
Module name: egov-location (folder) 
Master name: TenantBoundary (key)
```

## Data Setup

Enter the boundary hierarchy data in the `<tenant>/egov-location/boundary-data.json` file in the appropriate branch of your forked MDMS repository. For example - if you want changes to be visible in the Dev environment, add the data in the DEV branch of the MDMS repository.

{% hint style="info" %}
Follow the Git flow processes to ensure high-quality data. Make sure the PR requests are raised, verified and merged especially where multiple people are working on the same branch.
{% endhint %}

Restart the MDMS service in your environment once the new data is available in the desired branch.

### Boundary Localization

Users also need to upsert localisation codes for any new boundary data in MDMS. Else, users see the label names (auto-generated) for the city names in the UI. Check the [Localisation Data Setup](/platform/guides/data-setup-guide/localisation-module.md) guide for more information on how to perform localisation.

The localisation code should follow the following format - \**tenantId\*\_\*moduleName\*\_\*hierarchyType\*\_\*cityCode\*\_\*zoneCode\*\_\*blockCode\*\_\*areaCode*

For example, to find the localisation code for "Ajitnagar area 1", assuming tenantId as "pb" and hierarchyType as "Revenue":

1. moduleName: EGOV-LOCATION
2. cityCode: PB.AMRITSAR
3. zoneCode: Z1
4. blockCode: B1
5. areaCode: SUN04

So finally the localisation label code for "Ajitnagar area 1" would be PB\_EGOV-LOCATION\_REVENUE\_PB.AMRITSAR\_Z1\_B1\_SUN04 (visible in the UI if no localisation is present).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.digit.org/platform/guides/data-setup-guide/location-module.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.