Reference · built on requestCommons signalTransit, roads & mobility

On-street Parking Bay Sensors

Occupancy of in-ground sensors in City of Melbourne on-street parking bays, refreshed every 2 minutes, from the city's open data portal.

About

The City of Melbourne fits in-ground sensors to on-street parking bays across the municipality and publishes their readings on its open data portal. Each row is one sensor: status_description of Present or Unoccupied, status_timestamp, lastupdated, kerbsideid, zone_number, and a location point. The dataset is refreshed every 2 minutes through network relays and is served by the portal's Explore API v2.1 as JSON, with exports in CSV, GeoJSON, Parquet, and other listed formats. The city licenses it under Creative Commons Attribution 4.0 and notes that the sensors do not operate on public holidays and read a bay as vacant when construction blocks it.

An operator uses it to see whether kerbside space is free near a site before a technician, shuttle, or delivery arrives, and to propose a different bay or time when it is not.

This is a reference listing. It documents what Fibric would read from On-street Parking Bay Sensors and what it could propose, based on the publisher's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Sensor rows from GET /api/explore/v2.1/catalog/datasets/on-street-parking-bay-sensors/records, with select, where, order_by, limit, and offset in ODSQL
  • status_description per bay, Present or Unoccupied, with status_timestamp for the last change and lastupdated for the last relay update
  • kerbsideid, marked as the row id in the dataset schema, zone_number, and location as a geo_point_2d for distance filters
  • Counts by status from the /facets endpoint on status_description, and data_processed from the dataset metadata
  • Whole-dataset snapshots from /exports/csv, /exports/json, /exports/geojson, /exports/parquet, and the other listed formats, without the records page limit
  • Dataset bounding box, records_count, and the quality metadata: update frequency, known issues, and reliability level

Proposed actions

Read-only. This feed informs operators; it changes nothing.

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Send a technician to a bay that is free

    Field Dispatch reads Unoccupied bays within a short distance of the job address at dispatch time and proposes the arrival point and bay in the work order.

    With Field Dispatch

  • Warn when kerbside space is gone before a service window

    Service Window watches the bays around a customer site as the window approaches and proposes an earlier or later arrival when none has read Unoccupied for a while.

    With Service Window

  • Time a shuttle pull-in

    Shuttle Timing checks the bays at a pick-up point before departure and proposes an alternate stop when every sensor there reads Present.

    With Shuttle Timing

  • Direct overflow to the street

    Parking Overflow reads nearby bay status when a property's own parking is full and proposes a message that points visitors to zones with vacant bays.

    With Parking Overflow

Requirements

  • No key. A portal account is optional and only changes quotas
  • A point and radius or a bounding box inside the City of Melbourne, written as an ODSQL where clause on location
  • A check on lastupdated, since the city says relay outages delay updates and asks users to watch that column
  • A site or job location from another source to decide which bays matter
Authentication
None. The portal serves this dataset to anonymous callers; a portal account and API key, passed as Authorization: Apikey or the apikey parameter, extend the platform's call quota.

Limits

  • The records endpoint returns at most 100 rows per call and offset plus limit must stay below 10000; use exports for the whole dataset
  • Anonymous calls to the portal reported an X-RateLimit-Limit of 10000 per day in the response headers; the API answers 429 once the quota is spent
  • Sensors are not operational on public holidays and show a bay as vacant when a construction zone blocks it
  • Coverage is the City of Melbourne municipality; the row count moves as sensors connect and reconnect to the network

Access and pricing

Reference listing. Public feed access is separate from Fibric integration. If you request this feed, your quote covers the build, usage, and support.

Request On-street Parking Bay Sensors ↗

Questions and answers

How often does the data refresh?
The dataset's quality metadata gives an update frequency of 2 Minutes and a source update frequency of Real-time. Updates arrive through network relays that can be disrupted, so the city asks users to watch the lastupdated column for delays.
What does each row hold?
One parking bay sensor: status_description (Present or Unoccupied), status_timestamp, lastupdated, kerbsideid, zone_number, and location with lat and lon. On the day this listing was written the metadata listed 6324 rows, and the city notes the count fluctuates as sensors connect and reconnect.
Do I need a key, and what license applies?
No key is needed for anonymous reads. The dataset is licensed Creative Commons Attribution 4.0 (CC BY). The City of Melbourne accepts no responsibility for errors, omissions, or unavailability, per the dataset disclaimer.
Ask about On-street Parking Bay Sensors

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.