Public event site plan
What the score means for your operation
The gauge at the top of this report is how well the file is built. This one is what that means for your business: the risks you carry while it stays as it is. The two move together, one is the cause, the other the consequence. Each risk below is drawn from the drawing evidence further down, tap any card to see it.
Key-person dependency
Six different naming styles across 194 labels, none of them explained anywhere, and nine of those labels hold nine tenths of the drawing. Whatever logic exists lives in one person's head.
Onboarding and scaling the team
There is no system to learn and nothing written down. A newcomer would need someone to sit beside them and explain the drawing feature by feature before they could safely change anything.
On-site accuracy and safety
The drawing carries a map reference, but it points at a spot roughly 20 km from the park. Nothing in the file has been checked against the real site. Anything set out from it needs measuring first.
Change turnaround
Every tree, bollard and path is loose linework rather than an object, so moving or removing anything means editing dozens of individual lines by hand. There is no quick change here.
Procurement and budget accuracy
Nothing in the drawing counts itself, and 31,207 objects sit stacked exactly on top of one another, so any tally taken off it is inflated before anyone starts.
Reusability across events
There is no reusable park master and no library of assets. What exists is a single flat drawing, so every event and every project starts by working over the same unsorted picture.
Handover and supplier independence
The file is self-contained and opens cleanly anywhere, which is a genuine plus. But with no system to hand over, whoever receives it starts from the same standing start you would.
Single source of truth
The drawing carries its own history in its labels, with tranches dated 2011, 2019 and 2024 sitting alongside each other. Which one is current is not recorded anywhere in the file.
Governance and approvals
There are no printed sheets, no name-and-details panel and no revision history in the file at all, so there is no record of what was issued or when.
Future value and strategic readiness
Not one object in 191,970 carries any information, and the drawing is not truly pinned to the real world, so nothing here can feed asset management or reporting as it stands. Fixable, but not from this file alone.
The park is all here. Almost none of it is sorted.
Where the file stands for a decision-maker: a real head start on the structure, held back by gaps that cost your team time and certainty on every event.
What is working
- The whole park is here. Boundaries, paths, kerbs, services, trees, buildings and the river are all drawn.
- The measurement units are consistent and set in metres, which is the right choice for a site this size.
- The file is self-contained with no broken links, so it opens cleanly on any machine.
- There is real detail in it. The problem is how it is held, not what it contains.
What it is costing you
- Nine tenths of the drawing sits under labels like “0”, “2d” and “46”, so it cannot be switched on or off, recoloured or controlled as a set.
- Roughly 2,000 trees are drawn as loose lines rather than objects, about 77 lines each, so they cannot be counted, scheduled or reported on.
- 31,207 objects are stacked exactly on top of one another, invisible on screen, slowing the file and inflating every count.
- The map reference in the file points about 20 km away from the park, so the drawing cannot be trusted to sit correctly on a map or an aerial photograph.
Where it sits
- 19 out of 100. No system.
- A picture of the park rather than a plan anyone can work.
- Someone new could open it and see the park, but could not change anything with confidence.
- The good news: a second, older survey of the same park holds much of what is missing here.
Right now this is a picture of a site. Here is what it could become to run your events.
Investing in the plan buys back time and certainty. In plain terms, the work is:
- Clear out the clutter and give every object a home. Strip the tens of thousands of leftover objects dragged in with the old survey, then give everything a class it locks to, so nothing gets lost, mislabelled or dropped when a plan is shared, and the file stays fast with numbers you can trust.
- Build the venue once and reuse it. Hold the site as a single master that every event plan references, so it is never redrawn from scratch and a change is made in one place.
- Name everything to one simple system. So anyone on your team can open the file and find their way around it without a handover.
- Anchor the plan to the real world. Fix it to real-world map coordinates with a dynamic grid overlay, so a point on the plan is the same point on the ground, and your crew can call a location off any drawing with everyone meaning the same place.
- Put the event assets in one shared library, and information on every object. Barriers, generators and marquees held once so an update pushes to every plan, and each object carrying its own data so the plan counts itself.
Then the park is drawn once and drawn properly. The trees, paths and kerbs become objects instead of two hundred thousand loose lines, so the drawing is a fraction of the weight, a change takes seconds instead of an afternoon, and anyone on the team can pick it up and work it.
The good news is you are starting from a real base, not from nothing. The event assets are already built at true real-life size, and the site survey and the event plan are already kept on separate layers.
Because this file is not pinned to real-world coordinates (not georeferenced) and its base is a traced-over survey, there is also an optional first check worth doing: a measured pass proving whether the base plan is truly to scale, how far it departs from the real world, and whether it corrects with a simple rescale or needs more. It is the cheapest way to know what the base is worth before anything is built on it.
The four that cost you most
Nine tenths of the drawing has no usable label
In a drawing, a class is like a labelled pen: it sets how something looks and lets you control every item of one kind at once, turning it on or off, recolouring it, hiding it. There are 194 labels in this file and most of them read plainly, KERB, FENCE, GARDEN, TREE. But 174,468 of the 191,970 objects sit on just nine labels called “0”, “1”, “2d”, “30”, “46” and the like, which say nothing about what they are. Everything inside them is one flat grey, so there is not even a colour to tell one thing from another. That is why the drawing is slow to change and impossible to report on: the sorted part of it is only about six per cent.
The trees are drawn as loose lines, not objects
Every tree in the park is drawn as roughly seventy-seven separate short lines forming a scalloped outline with a small marker at the centre. Drawn that way, a tree is not a thing the drawing knows about. It cannot be counted, it cannot carry a species or a trunk size, it cannot appear in a schedule, and moving or removing one means editing dozens of lines by hand. That single choice accounts for most of the file's weight. Held as real objects instead, the same trees would count themselves, carry their own information and take seconds to edit.
The drawing is not truly pinned to the real world
The file does carry a coordinate system, so at first glance it looks georeferenced, which is the CAD term for a drawing pinned to real-world map coordinates. But the point it names sits about twenty kilometres away, in the city centre rather than at the venue. That is the software's default setting, not a reference to this site. The drawing content itself sits about 6,255 km from the file's own zero point, with nothing locking it there. So the plan will not line up on a map or an aerial photograph, and nothing set out from it can be trusted until it is measured on the ground.
There is no library of park assets, and heavy hidden duplication
The file contains a hundred reusable objects, but ninety-six of them are anonymous, machine-numbered fragments holding two lines each, the standard signature of a CAD file dropped in without cleanup. Only four are genuinely named. On top of that, 31,207 objects are stacked exactly on top of themselves, invisible on screen. They make the file slower to open and work in, and they quietly inflate every count taken off it. Neither problem is anyone's fault: both are what an untidied CAD import always drags in, and both clear out in one pass.
A picture is lines a person reads. A model is objects that carry data and count themselves.
The single biggest daily win from a model is reporting: the file counts itself, live, on every change, instead of being counted by hand and recounted every revision. AI, automation and a digital twin can do nothing with a picture. Here is where this file sits.
The base is a picture
Of the objects in this drawing are raw lines and arcs carrying no information at all. A picture of the park, not something that can report, count or schedule anything.
The event assets are real objects
Genuinely named reusable objects in the whole file. The other 96 are machine-numbered leftovers from the CAD import, so there is effectively no library of park assets here.
The deciding fact sits across both: not one object in the file, survey or event, carries any information of its own. The fix puts that information onto the objects the event assets already give you, which is the shortest path from a picture to a file that reports itself.
The ten areas we measured
These ten technical areas are what we actually checked inside the file. The operational exposure at the top is drawn from them. This is a site and event plan, so production content (rigging, positions, equipment) is out of scope and not scored.
Tap any area to jump to the detail behind its score.
Everything we examined
Each area shows what good looks like, what this file actually is, then the specifics underneath.
Structure & governance
Classes & appearance
17 · No systemThink of classes as the labelled pens you draw with. A class sets how something is drawn, its colour, line weight and fill, and groups like things together so they can be controlled as one set. Good practice is one clear set of classes used on everything, sorted so anyone can find the right one, and named to one structured system so the name itself tells you what a thing is and where it sits, like Venue-Landscape-Trees rather than a loose TREE or 46. Items are locked to their class so nothing ends up on the wrong one.
The named half of the list is better than it first looks. Most of the 194 labels read plainly and would map onto a proper standard without much argument. The problem is that they cover almost nothing: nine labels that say nothing at all hold nine tenths of the drawing.
- 194 classes. Six naming styles collide across them: ALL CAPS on 150, Title Case on 16, twelve with no clear rule, seven multi-separator, six with no letters at all, two lowercase and one Sentence case.
- Most of the named ones are readable survey shorthand in recognisable families: kerb codes, edge-of-bitumen codes, fence types, an irrigation set, and a text set graded by size. Each family decodes once and then covers every member.
- 174,468 of the 191,970 objects sit on nine classes named “0”, “1”, “20”, “30”, “41”, “46”, “2d”, “DESIGN1” and “L_HELP”. Class “0” alone holds 165,081 of them.
- Everything inside class “0” is drawn in one flat grey, so there is not even a colour to separate one kind of thing from another.
- 23 of the classes are near-duplicates of one another. None are unused, so the list is live rather than stale.
- Objects are not locked to a class, so anything can be drawn onto the wrong one, or none at all, by accident.
Layers
15 · No systemThink of layers as sheets of tracing paper laid over one another: you turn a sheet on or off to show or hide a whole part of the drawing. Good practice is a short set of clearly named layers, with the park base kept on its own layers, separate from anything laid over it, so you can show exactly what each audience needs to see.
There is effectively one layer holding the entire park. Nothing is separated from anything else, so there is no way to show or hide a part of the drawing without hunting for it.
- Two layers: one holding all 191,970 objects, and one empty spare.
- Base survey, services, trees, boundaries and event content all sit together on the same layer.
- No duplicate or near-duplicate layer names, which is at least clean.
- With everything on one layer, the only control left is the class list, and that is where the problem above bites hardest.
Resources & tidiness
25 · FragmentedA tidy, filed set of the drawing's stored items (the patterns and styles it keeps on a shelf to reuse), named for people to read, with nothing dead left in the file.
There is almost nothing here either way. The file carries two stored items, so there is little clutter, but equally there is no set of standard patterns or styles behind anything.
- Two stored items in the whole file: one line style and one document record.
- Neither is filed into a folder. Both sit loose at the top level.
- No set styles for repeated things like paths, hardscape or garden beds. How everything looks is left to the classes.
- There are no text styles behind the 2,369 pieces of text in the drawing, so every label was formatted by hand.
Shared library & links
30 · FragmentedOne central asset library that every file references, so a change to a bollard, a bin or a light is made once and pushes everywhere.
The file is self-contained, which is good for opening it anywhere, but nothing is shared, so every fix has to be redone by hand in every file it touches.
- No broken links. The file does not depend on missing external files, so it opens cleanly on another machine.
- No shared library is used. Nothing points at a central set of park assets.
- This is not set up as a central working file, so there is no controlled place for the team to work from.
- That means a change to a standard park item has to be repeated by hand everywhere it appears.
Content & intelligence
Park assets & scale
18 · No systemThe park assets built as real, reusable objects (a bollard, a bin, a light, a tree, drawn once and dropped in wherever needed), each at its true real-life size, with clean insides, and everything filed where you would look for it.
There is effectively no library here. Almost every reusable object in the file is an anonymous fragment left behind by the CAD import, which is the telltale of a drawing dropped in without cleanup.
- 100 reusable objects. 96 of them are machine-numbered fragments holding two objects each, named Group-1, Group-2 and so on.
- Only four are genuinely named. That is the whole park asset library.
- All 100 are drawn at their true real-life size (what CAD calls real-world scale), so at least nothing needs redrawing for scale. That is worth confirming rather than assuming.
- They are all filed inside a single import folder, which is a symptom rather than a filing system: it is where a raw CAD import lands, not somewhere anyone chose.
- The audit flags eight likely duplicate candidate groups among them, the largest holding 32 members. These are candidates, not confirmed duplicates.
Real objects vs raw lines
12 · No systemA drawing made of intelligent objects that know what they are, not thousands of raw lines, and no hidden duplicates dragging on the file.
This is the heart of it. The drawing is a picture of the park rather than a model of it, and it is carrying heavy hidden duplication on top.
- 98.7 per cent of the objects in the file are raw lines, arcs and outlines carrying no information. 176,906 are plain lines.
- Roughly 2,000 trees are drawn as about seventy-seven loose lines each, forming a scalloped outline with a small marker at the centre.
- 31,207 objects are exact duplicates stacked on themselves across 13,538 stacks, invisible on screen. They slow the file and inflate counts and exports.
- The drawing is essentially flat plan geometry, with no screen-plane annotation floating free of the model, which is clean.
- 113 objects are not given a class at all, which is a very small number and easily tidied.
Data & reporting
5 · No systemObjects that carry their own information, so the file counts itself, live, on every change: trees, bollards, bins, lights, all reported automatically.
This is the biggest gap and the biggest opportunity. Nothing in the drawing carries any information, so every count and schedule is manual and every revision means recounting from scratch.
- Across all 191,970 objects, not one carries any information of its own. The file holds nothing about what its objects are.
- There are no auto-counting tables, so nothing in the file produces a count or a schedule.
- There are no labels that read information off the objects.
- A tree schedule, a bollard count or a path length would all be done by hand today, and redone from scratch every time the drawing changes.
Spatial & output
Real-world position
10 · No systemThe drawing pinned to real-world map coordinates (this is what CAD calls georeferencing), with its zero point locked and a coordinate grid you can read locations off, so the same spot reads the same numbers at any scale and the plan sits correctly on a map or an aerial photograph.
The file looks georeferenced but is not usefully so. It names a coordinate system, but the point it names is about twenty kilometres away from the park, which is the software's default rather than a reference to this site.
- The file reports a coordinate system, a national grid zone. That much is right for the state.
- But the point it reports sits at [coordinates removed], which is the city centre, roughly 20 km from the venue. That is the default the software supplies, not a tie to this site.
- The drawing content sits about 6,255 km from the file's own zero point (its datum), with nothing locking it there, so it can shift if that zero point is ever reset.
- The drawing does not sit on an aerial photograph, so it cannot be checked against the real site by eye.
- Some of the labels record their own history, with tranches dated 2011, 2019 and 2024, so the base has been built up over more than a decade and its oldest content is 2011 or earlier. Whether any of it is still true on the ground needs checking against the site.
Units
75 · CoherentOne unit setting, consistent across the file, and the right base unit for the size of the site.
The strongest area in the file. Units are consistent and set in metres, which is exactly right for a park of this size.
- The document is set to metres, with no mixing of millimetres and metres. That consistency is a genuine positive.
- Metres is the natural choice at park and precinct scale, and makes distances easy to read and check.
- The drawing's overall extents span about 12 km by 10 km, but the real content sits within roughly 330 m of its centre. Something is sitting a long way out and pulling the extents with it, which is worth finding and clearing.
Sheets & presentation
10 · No systemClean sheets, with the on-screen windows (viewports) set from styles rather than tweaked one by one, and a managed name-and-details panel that carries the issue and revision history automatically.
There are no printed sheets in the file at all, so there is nothing set up to issue, and no record of what has been issued before.
- No printed sheets and no viewports (the framed windows on a printed sheet that show the plan).
- No managed name-and-details panel, so sheet information would be typed by hand.
- No revision or issue tables, so there is no drawing history captured in the file.
- No text styles sit behind the 2,369 pieces of text, so labels are placed by hand rather than from a standard.
- This is a working drawing rather than an issued set, so some of this is expected. It is noted once because it is what would need building before anything could be issued from it.
The standard this is scored against
Generic good, a file any team can pick up and run. Reporting is the flagship. This file already has part of 4 (the layer split), part of 8 (event assets at true real-life size) and part of 9 (clean sheets and consistent units). The gaps are the rest.
- Reporting: the file counts itself. Barriers, generators, capacities, live on every change.
- Objects that carry their own information, with labels that read straight off the object. The engine under reporting.
- One set of classes, sorted so they are easy to find, and named to one structured convention so the name itself tells you what a thing is and where it sits in the hierarchy (the multi-separator style flagged in the naming chart, for example Event-Barriers-Fence rather than a loose FENCE or fence_1). That is what lets anyone read a class name and know exactly what it controls. Every object locked to its own class, so nothing drifts or ends up with no class.
- A short set of clearly named layers, the venue kept separate from the event.
- The venue held as one master, built once, every event plan pointing at it.
- Pinned to real-world map coordinates, its zero point locked. Nothing floats.
- A real-world coordinate grid you read locations off, the same numbers at any scale.
- One central asset library, held once and reused, at true real-life size.
- Set styles for the on-screen windows and printed sheets, managed title-block details, fonts and units. Repeatable output.
Items 5 and 7 are built once by a superuser, not chores landed on the drag-and-drop crews. They are things the file has, not tasks for every planner.
The evidence behind the scores
The measurements behind each score, from a 71-part audit that read every object in the file. The figures that carry a finding are shown here; the full raw data sits behind them.
Classes
| Total classes | 194 |
| Naming styles present | 6 (ALL CAPS 150, Title Case 16, no clear rule 12, multi-separator 7, no letters 6, lowercase 2, Sentence case 1) |
| Objects on the nine unnamed classes | 174,468 of 191,970 (90.9%) |
| Largest single class | “0”, 165,081 objects |
| Unused | 0 |
| Near-duplicate flagged | 23 |
| Objects not given a class | 113 of 191,970 (0.1%) |
| Objects locked to a class | No |
Layers
| Design layers | 2 |
| Layer holding the park | 191,970 objects |
| Empty spare layer | 1 |
| Layer scale | 1:350 |
| Printed sheets | None |
| Duplicate/near-duplicate layer names | None |
Stored items
| Stored items total | 2 |
| Line styles | 1 |
| Document records | 1 |
| Filed into folders | 0 of 2 |
| Set styles for paths/hardscape | None |
| Text styles | None |
Park assets (reusable objects)
| Reusable objects | 100 |
| Genuinely named | 4 |
| Machine-numbered import fragments | 96 |
| Confirmed at true real-life size | 100 (100%) |
| Shrunk to page size | 0 |
| Filed in a folder | 100, all in the single import folder |
| Likely duplicate candidate groups | 8, largest holding 32 members |
Objects & duplication
| Objects checked | 191,970 |
| Share that is raw lines and outlines | 98.7% |
| Plain lines | 176,906 |
| Hidden duplicate stacks | 13,538 |
| Objects duplicated on themselves | 31,207 |
| Drawing type | Essentially flat plan |
Data & reporting
| Objects carrying information | 0 of 191,970 |
| Auto-count tables (worksheets) | 0 |
| Auto labels (data tags) | 0 |
| Automatic counts or schedules | None |
Real-world position & units
| Reports a coordinate system | Yes, a national grid zone |
| Point it reports | [coordinates removed], the city centre |
| Distance from the park | ~20 km |
| Usefully georeferenced | No; this is the software default, not a tie to this site |
| Centre of drawing vs the file's zero point | ~6,255 km away, unlocked |
| Sits on an aerial photograph | No |
| Measurement unit | Metres |
| Unit consistency | Consistent, no mm/m mix |
| Content spread | Median object ~330 m from centre; extents pulled to ~12 km by strays |
Sheets & title panel
| Printed sheets | 0 |
| Viewports (windows on sheets) | 0 |
| Title panel | None |
| Revision / issue tables | None |
| Text blocks | 2,369 |
| Text styles behind them | None |
Shared library & links
| Broken links | None |
| Shared library used | None |
| Set up as a central working file | No |
| Opens cleanly elsewhere | Yes, everything is baked in |
Get this for your own plan
This is an example of the report you receive when you have your own drawing audited. The file behind it has been anonymised. Yours reads the same way, on your own plan, with your own numbers.
- Book an audit and upload your native Vectorworks file.
- We run the same checks on your drawing and score it the same way.
- You get a report like this one, in plain English, on your own site.
No obligation. You keep the report either way.
Book your audit →