Short answer

Drawing a polygon on the map and giving it a location tag turns it into a named area (e.g. Memorial Park, Depot, Allotments). Any asset whose location falls inside that polygon automatically inherits the area's location tag — both for assets uploaded after the area is drawn, and through AI on subsequent processing. You can then search and filter the asset list by area in one click. Always remember to set the Location tag field (on the right-hand side of the form, just below the asset type), or the inheritance won't fire.

Detail

Areas are the primary tool for organising a council's asset register. You draw them once and they pay back forever:

To create an area:

  1. On the map, select the drawing tool in the right-hand toolbar.
  2. Plot the polygon — click each corner of the boundary, close the shape.
  3. Name the area (e.g. Memorial Park).
  4. Set the Location tag to the same name — it's on the right-hand side of the form, just below the asset type. This is the bit people miss — without the location tag, the area exists visually but won't auto-tag the assets inside it.
  5. Save.

What you get from this:

  • Auto-tagging. Every asset whose GPS location falls inside the polygon picks up the area's location tag — no manual work per asset.
  • Search and filter by area. In the asset list, filter by location tag Memorial Park and you get every asset in the park instantly. The same filter is the basis for bulk operations like creating a routine over the whole park.
  • Cleaner field experience. The location tag travels with the asset, so the operative on the mobile app sees Memorial Park alongside the asset name.
  • Better AI placement. When new photos are uploaded, the AI checks whether each photo's GPS point falls inside any drawn area; if it does, it tags the asset to that area immediately. (See When I upload photos as assets, how does Civic.ly decide where to place them on the map and what to call them?.)

A reasonable starting set for most councils: every park, every cemetery / churchyard, every allotment site, every depot or yard, every play area, every car park, and every building. Two hours of map work up front saves enormous amounts of asset-by-asset tagging later.

Buildings work the same way — and it's how you group "all the X in this building" today. Draw the building footprint as an area (e.g. Town Hall, Cedars House) and tag it. Every asset inside — fire extinguishers, fire alarm, emergency-exit signs, radiators — inherits that building's tag. To pull up a list of, say, all the fire extinguishers in the Town Hall, filter the asset list by location tag contains the building name and asset type is Fire Extinguisher; you can download that filtered list as a spreadsheet. (Photos taken indoors place loosely, so after upload drag each pin inside the footprint on the map view.) This is the interim answer until the dedicated building roll-up lands — drilling into a building record to see all its child assets and all their tasks in one place.

Watch-outs

  • The Location tag field is a separate input from the area name. Forgetting to set it is the single most common mistake. Make it a habit to fill both.
  • Inheritance is at upload time, not retroactive. If you upload assets first and then draw the park boundary, the existing assets don't get retagged. Either draw areas first, or do a manual filter-and-bulk-edit pass to apply the tag to existing assets after the area is drawn. (If a council has already loaded a lot of assets ahead of naming their areas — e.g. Newton Abbot loading their full register for an audit — Civic.ly support can run a one-off back-end backfill: copy each area's name into its Location Tag, then reprocess every asset so those inside an area inherit the tag. Ask your contact rather than re-tagging hundreds by hand.)
  • The tag re-derives on every save — so a hand-typed tag won't stick without an area. The Location Tag is recalculated each time an asset is saved: inside a tagged area it inherits the area's tag, otherwise it reverts to the nearest street. Typing a tag onto an asset that has no area over it gets overwritten on the next edit. This is by design, not a bug, and the asset's pin is unaffected. See Why does the Location Tag change to a street name every time I edit an asset?.
  • Polygon edges matter. An asset that sits a metre outside the polygon (because GPS drifted, or because the boundary was drawn loosely) won't inherit. If you spot one, either nudge the asset's pin into the polygon or expand the polygon slightly.
  • Assets added indoors can miss the building footprint entirely and stack on top of each other. Photos taken inside a building often carry an imprecise GPS fix, so a batch of assets added the same way (e.g. several students or team members onboarding a building's compliance assets together) can land just outside the drawn polygon — no inheritance fires, and they pick up the AI's nearest-street-name fallback instead of the building's tag. Because the fix is the same imprecise indoor GPS each time, several assets can end up stacked on the exact same coordinate, making them hard to spot individually on the map. To find them anyway, use the asset list's advanced filter: Location tag → contains phrase → your street/area name, combined with Subcategory (e.g. Fixtures and Fittings) to narrow it down — this catches assets even though their tag reads the wrong (street) name rather than the building's. Once found, drag each pin into the building's footprint to fix the tag. (Henley, 6 Jul 2026 — James's Old Fire Station assets.)
  • Overlapping areas — an asset can pick up the wrong area's name. Where a smaller area sits inside (or overlaps) a larger one — e.g. a play area within a wider recreation ground, or next to a neighbouring site's boundary — an asset can occasionally show the other area's tag. The quickest fix: open the asset, give its pin a small nudge (a "little wiggle") and save — that re-runs the inheritance and pulls in the correct area. Locking the larger polygon first (right-click → lock) makes the small pin easier to grab without dragging the whole area. When you're setting up nested areas, draw the small inner areas first and the large enclosing area last — the intended rule is that the smallest area containing an asset wins the tag, so building them small-first keeps the inheritance predictable. (Corroborated across several councils, 2026-05/07.)
  • Don't use the asset name field for the area. "Jubilee Park Play Area" as an asset name is a classic mistake — the area belongs in the location tag, not the name. See Why does the asset's name show up as the task title in the field, and how do I get it right?.
  • Hide areas temporarily when pinpoint-editing. Once you've drawn a few overlapping areas (e.g. a park with a playground sub-area), they can visually obscure the assets inside. When you're nudging point positions or zooming on detail, open the map's layer controls and turn off the areas overlay; turn it back on when you're done. The areas are still in the data — you're just hiding them on the view.
  • Drawn polygons start out locked. They behave as a single shape you can't accidentally drag. To resize or recolour, right-click the polygon to unlock; from the same menu you can set fill colour and adjust front-to-back ordering.