Upload an MS Excel spreadsheet or CSV file of South African addresses, tell us which columns hold the address, and download latitude, longitude, a standardized address and the property key for every row — matched against Riskscape's own national address and property data.
This is the actual flow, animated. It plays through on its own — click any step to jump to it. Every address, reference and property key shown below is fictitious sample data.
Your identifier comes back on every row, so the output drops straight into a join. Choose only the fields you actually need.
One full_address column, or build it from separate street, suburb, town and postal code columns. Either way you see a live preview of the exact string we'll geocode before you start.
Bias matching toward the provinces your book actually sits in. It's a preference, not a filter — a confident match elsewhere still comes back rather than being silently dropped.
Download a CSV for the actuarial model and the spreadsheet, or GeoJSON to drop straight into QGIS, ArcGIS or a web map — same job, no re-run.
The expensive mistake in geocoding isn't a missing coordinate — it's a confident-looking coordinate that's wrong. So every row lands in one of three buckets, and you decide what to do with the middle one.
The geocoder is confident. Coordinates, the candidate address it matched, and any add-on fields you selected all come back. These are the rows you can push into a model without looking at them.
A plausible candidate was found, but something didn't line up. You get the coordinate and the candidate address side by side with your input line, and you accept or reject each one — on a map or in a table.
Nothing credible was found — usually a partial line, a farm portion, or a suburb with no street. You get told plainly instead of getting a suburb centroid dressed up as a street address.
Starting a review turns the flagged rows into a short queue: input line, candidate match, coordinate, map pin. Accepting a row promotes it to a confirmed match and releases the add-on fields for it. Reviewing a job also extends its 7-day retention window to 14 days.
Structured input wins. Separate street / suburb / town / postal code columns beat one concatenated line; a postal code column resolves duplicate suburb names; and stripping complex or estate names from the street field lifts results noticeably. Run a sample first and see for yourself.
Address data is personal information. The geocoder is built so you hand over the least possible amount of it — and so nothing lingers.
The UI is for the analyst with a spreadsheet. When the same job needs to run every night, post the file to the API, poll the job, and pull the results — identical matching, identical grading, identical output fields.
# 1. submit a job POST /v1/geocoding/jobs file="sample-addresses.csv" address_column="res_source_line" identifier="src_id" fields=["latlng","candidate","sg21"] # 2. poll until complete GET /v1/geocoding/jobs/a9f3… > { "status": "completed", > "rows": 2000, > "matched": 1262, > "review": 601 } # 3. pull the results GET /v1/geocoding/jobs/a9f3…/results?format=csv
No GIS licence, no data science team, no integration project. A CSV and a browser.
Locate a policy book or claims history to property level before running catastrophe, flood or fire exposure.
Resolve collateral and valuation portfolios to a property key so risk layers can be joined per asset.
Turn service, rates or infrastructure registers into mapped datasets without a procurement cycle.
Logistics, utilities, retail networks, research samples — any list of South African addresses that needs coordinates.
Take a few hundred rows off your real book, put them through the six steps above, and look at the three buckets. That's the only benchmark that actually tells you anything.