Site Context Explorer

When an architect or planner starts on a site, the first question is what surrounds it. How many schools within walking distance, where the nearest clinic is, how far to a bus stop, whether there is a substation nearby. The existing answer was to open Google Maps, search "schools near X", screenshot it, and repeat a dozen times for a dozen categories, then assemble the results by hand. It is slow, it comes out differently depending on who does it, and the output looks like what it is: screenshots.

Site Context Explorer does the whole thing on one screen and produces a drawing. A planner enters a location, ticks the categories the job needs from 80 individual categories in 14 groups, and picks a radius from nine options between 200 m and 10 km. Everything matching appears on the map, colour-coded, with the counts per category and the distance to the nearest of each alongside. Four presets — Residential, Retail, Institutional, Infrastructure — cover the common cases without going through the list. It exports as a print-quality A3 image, straight to the clipboard for Word or PowerPoint, or as a PDF report with a table of every result, and a shareable link restores the exact analysis for a colleague.

The part that answers the half of the brief no dataset can is hand-placed markers. A planner clicks to drop a point, drags it into position, labels it and picks a type — hydrant, manhole, catch basin, valve, pole, access, tree or a general note. Where a city publishes nothing, they mark what they can see in Street View or what the authority sent them, and it becomes part of the drawing. Markers persist in the browser across refreshes and export to GeoJSON, which QGIS opens directly, so the work leaves with them. On the sheet they render as numbered squares rather than the circular pins used for dataset places, and the panel lists them under a heading saying they were placed by hand. That distinction is deliberate: a reader months later has to be able to tell an observation from a record.

The rule the whole application is built around is that nobody should be able to mistake generated data for a survey. Eight cities — Toronto, Vancouver, Calgary, Montréal, Dubai, Abu Dhabi, Riyadh and Doha — serve real OpenStreetMap extracts, and anywhere else falls back to generated sample data. Real data carries a badge naming the source and the extraction date; sample data carries a different-coloured one, and every exported image and PDF prints "INDICATIVE SAMPLE DATA — NOT FOR STATUTORY USE" across it. The docs are equally plain about the two caveats: the extract is a snapshot that goes stale until someone re-runs it, and OpenStreetMap has OpenStreetMap's gaps — one hotel where there are two, a fraction of the restaurants on a street.

The data question got more attention than the code. The recommendation is Overture Maps for places, and the reason is the licence rather than the coverage: most open map data carries a share-alike condition that makes clients nervous about putting it in a commercial report, and Overture's place data explicitly does not. For a product whose entire purpose is producing client deliverables, that settles it — supplemented with OpenStreetMap for the infrastructure categories a business directory does not carry. Two things are written down before building rather than after: the free public OSM servers do not permit an application pointing at them, so hosting the data is a real cost; and Gulf coverage is an expectation rather than a measurement, so the plan is a one-day per-city check against Canadian controls before anything is promised to the client.