There is no footfall data for Ambon, so busyness is inferred from what OpenStreetMap does record. The island is cut into 175 m cells and each cell scores four layers, blended by weight:
| Layer | Weight | How the cell scores |
|---|---|---|
| Road hierarchy | 0.30 | Nearest road, weighted by class (trunk 1.0 → service 0.15), decaying over 250 m |
| Anchor institutions | 0.25 | Sum over markets, ferry terminals, hospitals, schools, mosques and churches, decaying over 800 m |
| Commercial clustering | 0.20 | Sum over shops and small amenities, decaying over 300 m |
| Junction density | 0.15 | Count of road vertices within 120 m |
Each layer is divided by its own 95th percentile so the weights are comparable, then the blend is divided by its 90th percentile so a typical busy cell reads about 1.0. Cells with almost no road or anchor signal are dropped rather than drawn as zero — which is right over sea, and misleading wherever OSM is simply thin. A population layer is picked up automatically if a BPS density file is present; this build has none.
The index ranks places. Only one thing turns a rank into rupiah:
The exponent decides the verdict, and no Ambon measurement sets it. It is worth stating plainly what it is: a claim about how much busier the busiest place on the island is than your cafe. That is checkable by standing in both places, which no exponent ever is.
Two independent signals in the same OSM extract can be pushed at it. Fit an
inhomogeneous Poisson process — intensity proportional to
index^elasticity, maximum likelihood over all 15,792 cells —
using a predictor built only from road proximity and junction density,
so it contains no point of interest of any kind and is exogenous to what is
being predicted:
| What is being located | Elasticity | Implies busiest cell is |
|---|---|---|
| Schools and places of worship (n=189) — sited by population, and near-exhaustively mapped in Indonesia | 2.65 ± 0.16 | 2.3× the cafe |
| Shops and food outlets (n=192) — sited by trade | 4.12 ± 0.23 | 3.6× the cafe |
Face value — the default — puts the busiest cell at 2.37×, just above the population estimate and well below the trade estimate. The old default of 0.5 put it at 1.54×, below both. Three further things point the same way: the road layer is capped at 1.0 by construction, so a trunk road in a village scores what a trunk road beside Pasar Mardika does and no traffic volume enters anywhere; the layer normalisation clips the top tail at 8×; and restated as a rent gradient, 0.5 asserts that premises in the Mardika market district let for about 1.5× what they do in suburban Lateri.
None of that is a footfall measurement. Business density is not pedestrian density, and both estimates carry known biases running in opposite directions: OSM maps shops harder downtown, which inflates them; and under free entry, concentration shows up in the number of outlets rather than in the trade each one gets, which deflates them. Treat the calibration as bracketed, not settled — and note the sharpest version of the same point: if the site is being offered at the going market rate for its location, then in equilibrium the move is roughly break-even by construction, and it only pays if the rent is below market or your costs are below a commercial operator's.
Two numbers meet. The bar is exact arithmetic with no proxy in it — the multiplier at which the move washes its face in an average month:
The odds come from a Monte-Carlo simulation whose draws are baked into this page. Each of the 6,000 draws pairs a plausible month's visitor count — drawn from your own records, with Student-t tails so that having only a few months honestly widens the spread — with a plausible contribution margin. The footfall multiplier is log-normal around the map's estimate, with the "surprised if above" bound set 70% higher, because the proxy is unvalidated. Then
and the headline percentage is the share of draws with net ≥ 0. Every
control on this page is an exact recomputation over those same draws, checked
at build time against the full model. The map's second shading mode uses the
identity that net_i ≥ 0 exactly when
median ≥ (B_i + cost) / A_i, so sorting those thresholds once
gives every cell's probability by binary search — the colours are the same
number as the headline, not an approximation of it.