Which markets in India have property, and how much?

7 listings across 3 markets

Filters2

Refine which listings are counted. Clear all

Bedrooms

More filters
Layers

Where is there a market at all, and how big is it?

3 more readings, and 1 mode this map does not have — and why
Supply — see Explore
This is the same view as Explore, not a missing one. Supply is the listing count, Explore paints the listing count, and there is no second measure that would make them different pictures. Two chips producing a byte-identical page is a control that appears to do nothing, which reads as the page being broken rather than as the two being the same question.
12 more layers, not published yet — and why
Sold & rented
The STRUCTURAL gap this used to name is closed (0075): `listing_status` now has under_offer/sold/rented/leased terminal states, an agent or admin has a real button to say so (agent/dashboard), and each transition is stamped in `listing_status_history` (changed_at IS the closed-on date this lens needs — no separate `closed_at` column was needed once that log existed). What remains genuinely unsourced is DATA, not schema: zero listings have used these states yet — this is a brand-new, unused capability, same 'ships dark, no writer touched it before today' posture as every other structural addition this session. Computing this lens (and metricRegistry's inventory_months/days_on_market, which read the same gap) is a real aggregation query against listing_status_history that has not been written — deliberately out of scope for 0075, which built the state machine, not the analytics that consume it.
Months of inventory
Months of inventory is active listings divided by the number selling per month, and the denominator does not exist — see "Sold & rented". A count of what is for sale is already the Listings layer; dividing it by anything else to hand and calling the result inventory would produce a number that moves when the wrong thing changes. Six listings is a glut in a market that sells one a year and a shortage in one that sells ten a month, and until sales are recorded this platform cannot tell those apart.
Rental yield
A yield is annual rent divided by purchase price, so it needs BOTH kinds of listing in the same place. There are 12 listings for sale and 0 for rent, so there is no numerator anywhere on the platform. It becomes computable the day rentals are listed — the schema already carries `listing_for`, and nothing else has to change.
Price growth
A movement needs the SAME property observed at two different prices. `price_history` holds 12 rows across 12 properties and not one has been seen twice, so there is nothing to difference. Comparing this month's listings with last month's would measure what got listed rather than what things cost, and the two are indistinguishable once printed as a percentage. The video re-sync sweep records a price every time it re-reads a listing, so this fills in on its own.
New projects
The entity spine has a `projects` table (Location → Project → Building → Unit → Listing, migration 0022) and it holds 0 rows: every listing on the platform was posted as a standalone property, none as part of a launch. This is a capture gap, not a modelling one — the day a builder posts a project, this layer has data.
Schools
There is no points-of-interest dataset on this platform. The gazetteer holds 166,652 places and every one is administrative — country, state, district, city, locality — so there is not a single school row to count. This needs a POI source imported and matched to places: an OpenStreetMap extract (free, and its licence requires an attribution surface this site does not yet have) or a commercial feed. Until then a "schools" layer would be a coloured guess, and a buyer choosing a home for the school run is exactly who must not be given one.
Hospitals
There is no points-of-interest dataset on this platform. The gazetteer holds 166,652 places and every one is administrative — country, state, district, city, locality — so there is not a single hospital row to count. This needs a POI source imported and matched to places: an OpenStreetMap extract (free, and its licence requires an attribution surface this site does not yet have) or a commercial feed. Until then a "hospitals and clinics" layer would be a coloured guess, and a buyer choosing a home for the school run is exactly who must not be given one.
Metro & transit
There is no points-of-interest dataset on this platform. The gazetteer holds 166,652 places and every one is administrative — country, state, district, city, locality — so there is not a single station row to count. This needs a POI source imported and matched to places: an OpenStreetMap extract (free, and its licence requires an attribution surface this site does not yet have) or a commercial feed. Until then a "stations and transit lines" layer would be a coloured guess, and a buyer choosing a home for the school run is exactly who must not be given one.
IT parks & employment
There is no points-of-interest dataset on this platform. The gazetteer holds 166,652 places and every one is administrative — country, state, district, city, locality — so there is not a single employment row to count. This needs a POI source imported and matched to places: an OpenStreetMap extract (free, and its licence requires an attribution surface this site does not yet have) or a commercial feed. Until then a "employment centres — IT parks, SEZs, industrial estates" layer would be a coloured guess, and a buyer choosing a home for the school run is exactly who must not be given one.
Infrastructure
The forward-looking version of the transit and employment layers: a ring road, a metro extension, an airport. It needs a source none of the others do — announced and under-construction public works, with dates — which in India means state infrastructure authority publications rather than a map extract. It is the layer most likely to move a price and the hardest to source honestly, because a rumoured alignment printed as a fact on a property map moves money.
Agent coverage
Agents are not attached to places. An agent profile records who they are, not where they work — their territory is only implied by the listings they happen to have posted, which would make this layer a duplicate of Listings wearing a different name. It becomes real when agents declare a service area. There are 2 agent accounts today, so the layer would be a two-mark map regardless.
Administrative boundaries
Choropleth/administrative-boundary rendering does not exist on this map and will not until this changes: `loc_boundary_gix` has indexed zero rows since migration 0015, no vendor supplies Indian administrative boundaries as usable data, and 162,618 place centroids cannot be interpolated into polygons. A boundary layer here would be drawn shapes standing in for data this platform does not have.

7 videos in this view

Listings

fewer1more5

circle size = listings · shading compares the 3 places in this view, not the whole country · 2 marks left unlabelled where the names would have overlapped; every one names itself on hover