Geocoding, boundary matching, and what each costs

Two different jobs get confused with each other, and almost every question about cost comes down to telling them apart. Geocoding turns a street address into coordinates. It asks an outside service, that service charges per address, and so pplCRM meters it carefully. Boundary matching takes coordinates the workspace already has and works out which areas they fall inside. It is arithmetic on our own servers, it calls nothing, and it is free and unmetered.

What never costs anything

• Adding, drawing, reshaping, renaming or deleting a boundary map. Every one of these only re-reads coordinates already on file. No address is sent anywhere.
• Uploading a GeoJSON file.
• Re-matching every household in the workspace against a map you just changed.
• Importing district, ward or precinct names from a CSV column. See Import district, ward and precinct columns.
• Deleting a boundary set and adding it back.

So you can redraw a ward map as many times as it takes to get it right. It costs exactly the same as not redrawing it.

What does cost, and how it is metered

One thing costs money: finding the coordinates for an address this workspace has not looked up before.

• You add or edit one household in the app — looked up right away, normally within a minute. One address, one lookup.
• You import a file — never during the import, whatever its size. The import finishes without a single lookup: rows are saved and marked as waiting, and the first batch of lookups starts straight away. Anything beyond the day’s budget carries over to the following days. This is deliberate. A file of fifty thousand addresses would be a large bill arriving in one go, and metering it out is what keeps the feature affordable.
• An address this workspace has looked up before — free. The answer is remembered, including the answer “there is no such address”, so re-importing the same file, or importing one that overlaps something you loaded last month, costs nothing. It stays remembered even if you delete the household and add it back.

There is also a cap on how many new addresses one workspace can look up per day. It applies per workspace per day, not per import, so splitting a large file into several small ones does not get around it — and is not meant to. Going over it never fails anything: the remaining rows simply stay marked as waiting — their status chip reads Locating… — and carry on the next day. Nothing is dropped and no import is rejected.

What the status chip on a household means

• Located — coordinates are on file. The map pin is set, boundary areas are matched, and the household can be cut into a turf or routed for a delivery.
• Locating… — waiting for a lookup. The household record itself is complete and saved; the only things missing are its pin and the boundary areas that depend on it. A single edit usually clears within a minute or two. Imported rows start clearing as soon as the import lands, and a very large import is spread across several days on purpose — a file of tens of thousands of addresses will not all be located on the first day.
• Address problem — the address was looked up and could not be found. Open Edit and correct it; saving a corrected address queues a fresh lookup. The failed answer is remembered too, so leaving a bad address alone does not keep costing you anything.
• Not geocoded — geocoding is a Movement feature and this workspace is on a lower plan. The address is saved and perfectly usable; it was simply never sent for a lookup. See Settings and configuration for what each plan includes.