Almost every property dataset you can buy gives you a neighbourhood name. Zonaprop listings carry latitude and longitude, and that difference changes what questions you can ask — because a neighbourhood average hides exactly the variation that matters when two blocks apart is a different market.
Why a neighbourhood is not a location
Palermo is not one market. It contains streets where a square metre costs twice what it costs six blocks away, and a dataset labelled “Palermo” averages that difference out of existence. Coordinates keep it.
The practical consequence: with a neighbourhood label you can build a table. With coordinates you can build a surface, and a surface is what tells you where the boundary between two price regimes actually runs.
The fields
| Field | Notes |
|---|---|
latitude, longitude | From the listing itself, not geocoded from the address string. |
address | Street address as published. |
address_visibility | How precise Zonaprop was willing to be about the street. |
neighborhood, city, province | Administrative levels, for grouping and joins. |
zone, subzone, location_path | Zonaprop's own hierarchy, useful for splitting a search. |
Because the coordinates come from the listing rather than from geocoding, there is no geocoder error layered on top. What there is instead is publisher discretion, which is what the next section is about.
The accuracy flag, and honesty on a map
address_visibility records how exact the published address was. A publisher who withheld the street number gives you a point that is approximately right — fine for a heatmap, wrong for “this specific building”.
Four analyses coordinates make possible
- Price per square metre as a surface. Group by a small grid rather than by neighbourhood, using
price_amount,price_currencyandtotal_area_m2. - Distance to a transit line. Join to open subway or rail geometry and measure the price gradient with distance — one of the few property findings that generalises.
- Walkable catchments. What is within 800 metres, rather than what shares an administrative label.
- Boundary effects. Where two neighbourhoods meet, the label changes and the market usually does not. Coordinates show the real seam.
Using the location view
The location dataset view projects exactly the columns this work needs — identifier, URL, title, address and its visibility flag, the administrative levels, coordinates and price with currency. Sixteen columns instead of 54.
SELECT
ROUND(latitude, 3) AS lat_cell,
ROUND(longitude, 3) AS lng_cell,
COUNT(*) AS listings,
ROUND(AVG(price_amount / total_area_m2)) AS usd_per_m2
FROM listings
WHERE price_currency = 'USD'
AND total_area_m2 > 0
AND latitude IS NOT NULL
GROUP BY 1, 2
HAVING COUNT(*) >= 5
ORDER BY usd_per_m2 DESC;The HAVING clause is the important line: a cell with two listings is noise, and a surface built without a minimum count is mostly noise rendered confidently.
Joining to other geospatial data
Coordinates are the universal join key, which is why this is worth the trouble. Argentine census tracts, subway stations, school catchments and municipal open data all carry geometry, and a listing with a point can be joined to any of them without matching a single string.
Keep the administrative fields anyway. They stay in Spanish deliberately — they are proper nouns, and translating them would break exactly the joins you are about to make.
