Your property map looks perfect in development.
Pins drop exactly where you expect. The neighbourhood boundary renders cleanly. The "500 metres from metro" radius looks right on screen.
Then a buyer drives to the location and finds themselves standing outside a warehouse two streets away from the actual listing.
You did not write buggy code. You used the wrong coordinate system — and the map never told you.
Every Map Looks Correct Until It Does Not
Here is the uncomfortable truth about mapping in web development: Google Maps, Leaflet, Mapbox, and OpenStreetMap all use WGS84 (EPSG:4326) as their display coordinate system. But the coordinates stored in your database, pulled from a third-party data feed, or entered by an agent on a desktop form — may be in an entirely different system.
India officially uses Everest 1830 and its derivatives for survey data. Much of the cadastral land registry data that property platforms ingest comes from government sources that have never been converted to WGS84. The offset between these systems in the Indian subcontinent can be anywhere from 150 metres to over 1 kilometre depending on the region.
150 metres is the difference between a property being "next to the school" and "behind the commercial complex down the road."
For a buyer making a decision worth ₹60 lakh, that is not a minor rendering glitch. That is a broken product.
The Three Places Coordinate Errors Enter Your Platform
1. Agent-entered coordinates
Most platforms let agents drop a pin to set location — WGS84, fine. But some platforms also accept a text field because agents copy-paste from government portals, survey documents, or older GIS exports. Those coordinates may not be WGS84. Your validation does not catch this because both look like valid decimal degree numbers.
2. Third-party property data feeds
If your platform ingests listings from a broker network or a government housing database, the coordinate system of that feed is often undocumented. It is assumed to be WGS84. It frequently is not — particularly for data sourced from municipal corporations or state housing boards that maintain their own GIS layers in local projections.
3. Geofence and boundary data
Neighbourhood polygons, ward boundaries, school catchment areas — these are almost always sourced from shapefiles. Shapefiles carry a .prj file that declares the coordinate system. Most developers ignore the .prj file and import the coordinates directly. If the shapefile is in a projected coordinate system (metres, not degrees), the polygon will render in the middle of the ocean.
What WGS84 vs Projected Actually Means in Practice
WGS84 coordinates look like this: 12.9716° N, 77.5946° E — decimal degrees, globally referenced, what every web map expects.
A projected coordinate system like UTM Zone 43N, commonly used in India, looks like this: 756432.12 E, 1434521.87 N — metres from a reference origin, not decimal degrees.
If you store UTM coordinates and pass them to Leaflet as latitude/longitude, Leaflet will try to render a pin at latitude 756432. The pin simply does not appear, throws a silent error, or in some implementations wraps around to a completely wrong location.
The dangerous scenario is when coordinate values fall within a plausible lat/lng range by coincidence. Some projected systems produce values that look like valid decimal degrees for certain regions. The pin appears. It appears in the wrong place. No error is thrown anywhere.
GPS Drift on Mobile: A Separate Problem That Compounds Everything
Even when your coordinate system is correct, GPS accuracy on mobile devices in dense urban environments introduces a second layer of imprecision.
In areas with tall buildings — central Mumbai, Connaught Place, parts of Bangalore's CBD — multipath interference causes GPS readings to drift 30–80 metres from the true location. When a buyer uses "show listings near me" while standing on a street, their device-reported location may place them half a block away.
This is not fixable at the application level. What is fixable is your response to it:
• Use the coords.accuracy value from the Geolocation API and surface it in the UI rather than treating every reading as precise
• Show a confidence ring around the user location instead of a sharp pin
• Do not auto-filter to listings within 100 metres of current position — the margin of error makes this meaningless in dense areas
The Bounding Box vs Viewport Problem
Most property map implementations load listings by bounding box — the visible rectangle of the map. Broadly fine. But it creates a specific failure mode at scale.
When a user zooms out to see an entire city, the bounding box query returns every listing in the city. At 50,000 listings, this query will not return in any acceptable time, and the response payload will crash a mobile browser.
The standard fix — clustering — is implemented correctly by almost nobody on the first attempt. Developers typically cluster on the frontend, which means 50,000 records still travel over the network before clustering happens. The cluster should happen at the query level, using a spatial grid or geohash bucketing in the database, so only cluster centroids and counts are returned for high-zoom-out states.
PostGIS handles this with ST_SnapToGrid. If you are evaluating a real estate property listing script as a foundation, check whether clustering is happening server-side or client-side before you inherit the architecture decision.
How to Audit Your Platform Right Now
If you are not sure whether your property platform has a coordinate system problem, here is a five-minute audit:
Step 1 — Pull the raw lat/lng values for five listings from your database.
Step 2 — Paste each coordinate pair into Google Maps manually and verify the pin lands on the correct property.
Step 3 — If even one is off by more than 50 metres, you have a coordinate system issue. If one lands in the ocean, you have an undetected projection mismatch.
Step 4 — Open the .prj file from your neighbourhood boundary shapefile. If it says anything other than WGS_1984 or GCS_WGS_1984, your boundaries need reprojection before import.
Step 5 — Add an EPSG code metadata column to your listings table. Store not just the coordinates but the coordinate system they were entered in. One column. Saves a full data migration later.
The Fix Is Not Complicated — But It Has to Be Deliberate
Three decisions made early eliminate the entire class of problems above:
Store in WGS84. Always. Convert at ingestion, not at display. If data arrives from a government source in Everest 1830, convert it using PROJ before it touches your database. Never store mixed coordinate systems in the same column.
Validate on input. A valid lat/lng for India is approximately 8°N–37°N, 68°E–97°E. Any coordinate outside this range entered for an Indian property is wrong. Reject it at the API layer.
Handle the .prj file. Every shapefile import pipeline that does not read the projection definition is broken by design — it just has not failed visibly yet.
Mapping is the feature users trust most on a property platform. It is also the feature most developers wire up in an afternoon and never revisit.
The coordinate system problem is not obscure GIS trivia. It is a foundational data quality issue that shows up between month three and month twelve — always at the worst possible moment, always reported by a buyer standing on the wrong street, and always traced back to a decision made on day one that felt too small to matter at the time.
The developers who never hit this problem are not luckier than you. They just spent twenty minutes thinking about coordinate systems before they wrote the first line of map code. That is the entire gap.
