Frequently Asked Question​

The Alliance for Parking Data Standards (APDS) is an international organisation. It managed the creation of a consensus-built international parking and kerbside data specification, which it is now maintaining and evolving. The goal is to establish adoption of a common language for parking entities, the automotive industry, IT developers, service providers, and other stakeholders. The APDS specification has been adopted as a published ISO standard and underpins a CEN European standard.

The APDS specifications provide a common language for sharing parking, kerbside and mobility data. This can help to reduce costs, improve efficiency, and enable new and innovative services. Using APDS, firms and public authorities can share and find place, rate and occupancy data to support value-added services. In turn, these can be offered to businesses and consumers.

Here are some specific benefits of using APDS:

• Improved communication and data sharing between parking entities, service providers, and other stakeholders.
• Seamless integration and compatibility between different parking systems.
• Reduced costs associated with data integration and management.
• Enhanced efficiency of parking operations.
• Development of new and innovative services for parking customers.
• Increased transparency and accountability in the parking industry.

Place: where a vehicle may park or a person may change modes of transport.

Right: how a facility owner or operator authorises use of a place.

Rate: tariffs and fee schedules for a place element.

Occupancy: the number of spaces that are occupied or available.

Quote: proposed pricing for services.

Observation: documentation of an entity performing an action in a place.

Common Elements: concepts that are referenced and reused across several domains.

The Place hierarchy is a key concept in APDS. It allows parking places to be broken down into smaller and smaller units, from the overall place down to individual parking spaces. This enables data to be shared at different levels of granularity.

For example, a parking operator could share data about the overall occupancy of a parking garage. Or, they could share data about the availability of spaces in a specific zone within the garage. They could also define a parking place which is all the available parking at, say, an airport or a major retail or commercial venue. The Place hierarchy is defined using the following data classes:

• Place: the top level of the hierarchy, representing the overall parking facility.
• SubplaceElement: a subdivision of a Place.
• IdentifiedArea: a specific area within a Place, such as a zone, level, or row.
• Space: a single identifiable parking space

A RightSpecification defines the operating parameters for parking or related activities. It is essentially a template that defines the permissions that are being granted to a user or vehicle.

For example, a RightSpecification could be used to define the following:

• The type of vehicle that is allowed to park in a particular space (e.g., passenger cars only).
• The times of day when parking is permitted.
• The maximum length of time that a vehicle can park.

Eligibility defines the criteria that must be met in order to use a RightSpecification or RateTable.

For example, Eligibility could be used to define the following:

• That only members of a particular group are eligible for a certain parking permit.
• That a vehicle must meet certain emissions standards in order to park in a particular zone.
• That a vehicle must be a certain type (e.g., electric car) in order to qualify for a discounted rate.

RateTables define the charges that are applied for the use of a RightSpecification.

For example, a RateTable could be used to define the following:

• An hourly parking rate.
• A daily parking rate.
• A monthly parking permit rate.

RateTables can be complex, with different rates applying for different times of day, days of the week, and other factors. The APDS specifications provide a standardised way to define and communicate RateTable information.

Quotes are used to get a firm price for the use of a RightSpecification at a specific time. This allows users to evaluate a purchase before committing to it. A QuoteRequest is sent to an entity that controls the inventory of available RightSpecifications. The entity responds with a QuoteResponse, which includes the price and other relevant information.

Quotes are not authorizations to use a RightSpecification. They must be converted into an AssignedRight in order to be used.

Observations document the observation of an entity performing an action in a Place.

For example, an Observation could be made of:

• A vehicle entering a parking garage.
• A person paying for parking at a pay station.
• A vehicle being present at a particular location
• A vehicle exceeding the time limit for parking in a particular space.

Observations can be made visually or electronically. The APDS specifications provide a standardised way to document and communicate Observation data.

APDS convenes experts to develop, maintain and evolve the APDS specifications. It does not store data or act as an aggregator. Participation in APDS is voluntary, and adoption of the specifications is driven by the marketplace. APDS is committed to developing open and transparent specifications that benefit all stakeholders. The APDS specifications are versioned and subject to ongoing maintenance. APDS welcomes feedback from all stakeholders and is committed to ensuring that the specifications meet the needs of the parking and kerbside management industry.

Several APDS resources are available through this website.

• The APDS specifications themselves that describe the APDS data model and how it is expected to be used.
• API definition, which are considered experiment, which define a series of endpoints and API services to support data exchange in an APDS compliant system.
• Access to training resources.
• Use case and testimonial materials concerning some of the organisations deploying APDS services.

No. The APDS specifications may be freely downloaded and used without restriction. However, no reselling or rebranding of the APDS content is permitted.

No, they are freely available to subscribed members of the APDS website.

The two following standards are heavily based on APDS specification content:

• ISO Technical Specification (TS) 5206-1:2023 – “Intelligent transport systems – Parking – Part 1: Core data model”
• CEN Technical Specification (TS) 16157-6:2022 – “Intelligent transport systems – DATEX II data exchange specifications for traffic management and information – Part 6: Parking publications”

This is not essential. Many of the early implementations are providing data mapping from pre-existing bespoke data structures into APDS compliant data. Some developers and data users are, however, considering re-basing their systems to use APDS data as they expect this will improve internal consistency of larger disparate operations and also ease exchange of data with other parties.