Nationwide field force survey coverage, from state to ward

What is the LGD code list, and why does a survey need it?

The Local Government Directory (LGD) is the official register kept by the Government of India's Ministry of Panchayati Raj. It assigns a permanent numeric code to every state, district, sub-district/tehsil, block, gram panchayat, village, urban local body and ward, and records how they relate (which village sits in which GP, which GP in which block). A survey needs it for three reasons. (1) Duplicate names: one district can hold several Rampurs and Naglas, and the code keeps them apart. (2) Matching other data: government schemes, the Census and department portals use the same codes, so your survey report can join up with them. (3) Stability over time: spellings drift, codes don't. All of Bharat Survey's geography is built on these codes, and every area record shows its LGD code, source and load date.

Vidhan sabha wise survey planning, seat by seat

An assembly election survey plan comes down to four questions. What is the unit? Gram panchayats in a rural AC, wards in an urban one, and booths (part numbers) for roll-up in both. How many seats? An AC has 200–400 booths and 1.5–3 lakh voters; a 10–30 seat plan is typical, with one volunteer covering 300 households in 8–12 days. What is the supervisor's patch? A block or zone, with 8–10 volunteers per supervisor. At what level do you report? Issues by panchayat or ward, ratings by booth, a summary at AC level. Import the booth master from the CEO list, pin booth locations, and settle the “near boundary” review policy on day one. No personal voter-roll data is imported in v1; the work runs on the booth-level master.

Ward wise survey in ULBs: surveying city wards

In municipal corporations, councils and nagar panchayats, the ward is the unit. Ward boundaries come from the State Election Commission notification and change after delimitation, so each project is verified against the latest notification. Mohallas and colonies get a local ID, so a volunteer's assignment can be as precise as “Ward 14, Gali No. 6”. Urban surveys bring two particular challenges: GPS accuracy of 50–200 m in dense lanes, which swells the “near boundary” and “weak signal” groups; and multi-storey buildings, where a household roster (one building, many homes) does the job. In retail audits and facility surveys, the shop or facility list is mapped to wards and reports are built with photo evidence.

Panchayat survey: working GP by GP

Panchayat elections, rural development programmes and NGO or government household surveys all run on the gram panchayat. LGD provides the block, GP and village lists and the GP-to-village mapping; village centroids are Census-based. Zila panchayat and kshetra panchayat wards come from the State Election Commission list. Assign by GP, set targets by village, report GP → block → district. Village boundaries are approximate, so the badge says “approximately in area”, and only records that are clearly outside (kilometres away) get flagged “outside area”. Tolas, majras and purwas, which aren't official villages, get a local sub-area ID inside the village, and the report marks their source as “local” so the match with LGD holds.

How to read an LGD code: five things worth knowing

An LGD list looks like a wall of columns the first time you open it, but only five things matter for survey work. (1) A code is an identity, not an address. A village code's digits don't encode its district or block; a separate mapping table tells you which village belongs to which gram panchayat. So don't try to read the district off the leading digits. (2) Each level has its own code list. State, district, sub-district/tehsil, block, gram panchayat (local body), village, urban local body and ward all run in separate series, so ‘1234’ could be a block in one list and something else in another; always read a code together with its level. (3) Names change; codes don't. ‘रामपुर’, ‘Rampur’, ‘Ram Pur’: three spellings, one code. Join your household list or old reports on the code, not the name. (4) A revenue village and a gram panchayat are different things. One GP can hold several villages, and they can share a name (GP Barauli, village Barauli Khas). (5) The list is alive. New districts, new urban bodies, reorganised panchayats: LGD keeps updating, so we date every load and pull the latest version when a project starts.

How codes appear in your exports

CSV and Excel exports carry both the area name and its code as columns on every record, along with boundary status (verified / approximate / not available) and location status. That lets you join your report to government scheme data or your own older survey files by code. Local units such as tolas and majras are marked with source “local” and come with their parent LGD village code.

Rural vs urban: one survey, two structures

Say your project is one assembly seat in Lucknow district (names are samples). In its rural part the path runs: district → Block Malihabad → Gram Panchayat Barauli → village Barauli Khas → Purab Tola. The urban part has no block or panchayat; its path is district → Nagar Palika → Ward 14 → Gali No. 6. Above both sits the electoral structure: assembly seat → booth (part number). In practice that means three decisions. Assignment: by GP in villages, by ward in town. Location policy: villages have bigger radii and open sky, so more records land “in area”; city wards are small, buildings are tall and accuracy runs 50–200 m, so expect more “near boundary” and “weak signal” and agree the review policy first. Household identity: in a village, a house label and the head of household's name are enough; in a multi-storey building you need a household roster (one building, many homes).

How an approximate boundary is built, and how it improves

Where an open polygon exists (district, assembly seat, Lok Sabha seat), we use it and record its source and date alongside the boundary status. For villages and most wards, no such polygon is publicly available in a uniform form. There the boundary is built from two things: the centroid, the village's Census-based centre point, and a radius estimated from the village's size. That is a circle, not the real boundary; in a long or scattered village, outlying tolas will fall outside it. That is exactly why “near boundary” is its own group and such records are not rejected outright.

Improvements come three ways. First, on setup day: the missing-mapping report shows how many areas have a boundary, how many are approximate and how many have none, and anything unclear stays “verification pending”. Second, from the field: if a village's valid records keep landing “near boundary” or “outside” and the supervisor keeps logging exceptions with reasons (“the eastern tola sits outside the radius”), that area's centroid or radius needs fixing. Third, from you: if you hold a verified boundary, such as a municipal corporation's GIS, it can be imported into the project and that area's badge becomes “verified”. In all three cases older records are reclassified against the new boundary, but each record's original evidence (lat/long, accuracy, time) stays as it was, so anyone can later see what the status was before and why it changed.