Sydney Parking Data: Why It Is Scattered and Hard to Use

What I learned building a Sydney parking map from council, TfNSW, street-rule and public car park datasets.

A parking map of Sydney with highlighted streets and highlighted parking zones on mobile

Most people are not trying to become parking-data researchers.

They are just trying to park their car.

That sounds trivial until you try to answer a simple question like: where can I park near Town Hall right now, for two hours, without accidentally ending up in a loading zone or paying too much?

I originally assumed Sydney parking data would already exist in some unified form somewhere. Maybe not perfect, but consolidated enough that you could build a genuinely useful parking map on top of it.

Instead, I found a maze.

Parking information across Sydney is scattered between council open-data portals, ArcGIS layers, PDFs, parking meter systems, committee documents, operator websites, road-sign inventories, transport datasets, embedded web maps and street signage itself.

Some of those sources are excellent. Some are partial. Some are hard to find. Some are easy to read as a human but painful to use as software. Very few were designed to work together.

That realization ended up shaping the direction of Park Me For Free.

Sydney already has plenty of parking information. What it does not really have is a consistent way of reconciling all of it into one practical view that a driver can trust.

The York Street bug that changed how I thought about the product

The moment the problem really clicked for me happened on York Street in the Sydney CBD.

One public dataset showed evening and weekend 4P Ticket parking on a stretch of the road. Another source showed weekday daytime loading-zone restrictions in roughly the same location.

The original app logic did something naive. It looked at the selected time, saw that the paid meter window was inactive, and concluded that the space was free.

At first glance, that sounds reasonable. It is also exactly the kind of assumption that can make a parking product wrong.

An inactive paid-meter rule does not automatically mean parking is free. It might mean another restriction is active. It might mean the meter dataset is silent for that time. It might mean another authority controls the kerbside rule. It might mean the app has incomplete coverage.

The old logic looked like this:

No active paid meter
  -> show free parking

The safer logic became:

No active paid meter
  -> meter source is silent
  -> check restrictions and overlapping evidence
  -> if nothing confirms parking is allowed
     return unknown instead of free

That one bug changed the architecture of the app.

The product should not treat missing data as permission. It should gather evidence, resolve conflicts and be honest when the available information is not strong enough.

Parking rules are not stored as “parking rules”

One of the more frustrating things I discovered is that parking restrictions are rarely stored in one clean system.

They are spread across operational systems that were built for different jobs.

Meter systems exist to manage paid parking. Road inventories exist for infrastructure and asset management. GIS layers exist for mapping workflows. Traffic orders and council records exist for compliance. Operator systems exist for off-street parking businesses. Transport datasets often exist for enforcement, loading zones or traffic operations.

A person driving down the street can reconcile some of this by reading the sign in front of them. Software has to do that reconciliation explicitly.

That is where the real difficulty starts. Drawing a parking line or marker on a map is relatively easy. Deciding whether the available evidence actually supports the parking decision is much harder.

The fragmentation is structural

The more I researched Sydney parking systems, the more obvious it became why a single reliable parking map is difficult.

Sydney is not one parking authority. It is a network of independent councils, state transport agencies, private car park operators, old systems, new systems, vendors, open-data portals and local rules that have evolved over time.

Even where data exists, the formats are inconsistent. Different councils use different naming, geometry, schemas and update cadences. Some expose clean machine-readable feeds. Some expose ArcGIS layers. Some publish useful documents that are not really designed for automated ingestion. Some have information that is public in theory but awkward to turn into a consumer product.

The problem is not incompetence. Most of these systems were created to support operations, enforcement, planning or asset management. They were not created so that a driver could compare every nearby parking option in one interface before leaving home.

That mismatch is the gap.

Public data is only valuable if people can actually use it

I like public government data because it carries a simple promise: information collected for the public should create public value.

Parking is a good test case for that idea.

Councils and transport agencies already maintain a lot of useful raw material: parking signs, paid meter zones, loading zones, accessible bays, council car parks, road geometry, timed restrictions, permit areas and some live occupancy feeds.

But raw availability is not the same as usefulness.

If a driver has to compare a council map, a PDF, a transport dataset, a street sign, an operator page and three overlapping GIS layers, the hard part has simply been pushed onto the user.

That might be acceptable for a data audit. It is not acceptable for someone trying to park before an appointment.

The goal of Park Me For Free is to pull that information into one place, normalize it and present it in a way that is useful at the moment someone actually needs it.

Why I moved toward an evidence-based resolver

The first versions of the app treated datasets too independently.

There was meter logic, off-street parking logic, kerbside logic, loading-zone logic and search logic. Each piece was useful, but each one answered its own narrow question.

Real parking decisions do not work that way. A single stretch of road can involve a paid meter, a loading restriction, a no-stopping window, an accessible bay, a permit rule or a nearby off-street option. The user does not care which dataset produced which layer. They care what applies now.

So I started restructuring the system around evidence.

Instead of allowing each source to directly decide what the map says, each source contributes evidence into a resolver pipeline:

source
  -> normalized evidence
  -> matched to road or kerb asset
  -> conflict resolution
  -> parking decision
  -> confidence level

That sounds like a small architectural change, but it changes the behaviour of the product.

A weak map hint should not override a stronger public authority source. An inactive meter should not imply free parking. Conflicting evidence should reduce confidence instead of producing fake certainty. Missing data should sometimes remain unknown.

A trustworthy parking app needs to be comfortable saying, “we do not know enough yet.”

Free parking has to be earned

One thing I have become increasingly careful about is the word “free.”

A lot of parking information can look free if you simplify it too aggressively. A paid meter might be inactive. A time window might not apply right now. A map tag might suggest parking is allowed. A street might have no obvious pricing information.

None of that automatically proves that a driver can park there for free.

A space might stop being paid after 6pm but still have time limits. It might require a resident permit. It might become a loading zone during business hours. It might sit inside a clearway window. It might have restrictions that are visible on street signage but not represented cleanly in a dataset.

So the decision logic has to be conservative.

The current hierarchy is roughly:

  1. Temporary and active restrictions first.
  2. Hard restrictions like no stopping, clearways and bus zones.
  3. Special-use bays like loading zones.
  4. Active paid meter or ticket windows.
  5. Explicit free or timed parking evidence.
  6. Weak supporting hints.
  7. Unknown when the evidence is missing or conflicting.

That approach is less flashy than colouring everything green, but it is much more useful. Free parking should be the result of positive evidence, not the absence of paid evidence.

The app should explain why

A parking map becomes much more useful when it can explain the decision it is showing.

If the app says a location is a loading zone, the user should be able to see why. A useful explanation might look something like this:

Loading zone active
Confidence: High
Evidence:
- TfNSW loading-zone dataset
- City meter data indicates paid parking later

That kind of explanation helps in two ways.

First, it helps the driver understand the result quickly. Second, it makes the system easier to improve when something is wrong.

Parking data will be wrong sometimes. Street signs change. Roadworks happen. Council datasets lag. Geometry gets messy. A matching algorithm can attach a record to the wrong side of the street.

If the app exposes the evidence behind a decision, mistakes become easier to investigate. You can see whether the problem came from a stale source, a bad merge, a missing rule or an incorrect interpretation.

That is how a public-data product gets better over time.

This problem exists across Sydney

Every part of Sydney has a different version of the same problem.

In the CBD, Town Hall and Circular Quay, the challenge is density. Meters, loading zones, no-stopping windows, commercial car parks, event traffic and access rules can all overlap in a small area.

In Surry Hills, the pattern shifts toward residential streets, restaurants, offices, venues, resident permits and time-limited kerbside rules.

In Bondi and Manly, beach access, visitor demand, council car parks, seasonal traffic and local permit rules become more important.

In Chatswood and North Sydney, commuter demand, station access, retail parking, office traffic and off-street car parks play a larger role.

The sources change by suburb and council area, but the underlying user problem stays the same. People need one practical place to compare the best available parking information around them.

The community benefit is clarity

When parking information is hard to find, everyone pays a small tax.

Drivers circle for longer. Local streets get more congestion. Visitors avoid areas because parking feels uncertain. Businesses lose customers who give up before arriving. Councils publish useful information, but the public value gets trapped inside formats that are hard to compare.

A better parking map does not solve every transport problem. It does not replace public transport, better planning or safer streets.

But if people are already driving, better information still helps. It can reduce uncertainty, reduce wasted circling and make public datasets more visible and useful.

That is the practical value I am aiming for.

What I am building toward

The long-term goal is a Sydney parking map that can combine council parking datasets, TfNSW transport data, mapped street rules, off-street car parks, live availability where authoritative feeds exist, confidence labels and source explanations that normal people can read.

The app should be honest about what it knows and what it does not know.

Static street rules should not be described as live vacancy. A loading zone should not be treated as free parking. A weak map tag should not override a stronger public source. A missing paid meter window should not become a green answer by default.

The work is really about turning fragmented public parking data into decisions that help real people.

Sydney already has much of the raw information. The next step is making it usable.

Back to blog