The Regulation Page

Introduction to the Regulation Page

The Regulation dashboard allows you to digitally translate regulation and road safety rules into the platform. You can create temporary or permanent policies and visualize the list of active, pending, and expired regulations.

Who Uses the Regulation Page?

In many cities, mobility operators must abide by a set of conditions in order to operate. These policies* or regulations* are used by program managers to record these conditions spatially, and to monitor compliance with them. You may find yourself creating regulations as a program manager in order to enforce these provisions.

What is the Regulation Page for?

The Regulation page allows you to create the library of policies your city is enforcing. The policy includes both the geographic boundaries you are covering (the entire city, a district or subdistrict, or a custom area) as well as the metadata about the policy- when does it apply, for what type of operators, and other specific information.
When published, these policies are both visible to operators on their Cityscope dashboards and communicated to them in an API so that they can incorporate the information into customer-facing apps.

Creating Policies

There are several types of policies available to be created in the platform. For an exhaustive description of the metrics calculated for each policy, review the "Defining Metrics and Key Performance Indicators" article.

Cap, Floor*, and Cap and Floor* restrict the number of devices in a location. Caps set a maximum number of devices each operator is permitted to have in their fleet in the designated area (available, reserved and unavailable). Floors set a minimum number of devices each operator is required to have in their fleet in the designated area.

Low Speed zones govern the speed at which devices are permitted to operate in the zone.

No Deployment zones are areas where operators are not permitted to rebalance devices (monitored via the last event status of the vehicle). Vehicles which end in the location as a result of the trip are permitted.

Max Parked and *Max Unavailable compel the operator to either limit the number of devices which can be parked or unavailable at any given time, or limit the duration of time any device can be pared or unavailable.

No Go zones restrict both riding and parking in the areas they cover.

No Parking zones restrict parking in the locations they are present in

Parking zones indicate the city's preferred (or required) parking locations.

After selecting a policy type, you have the ability to set a geography- selecting the entire city or a particular district. Additionally, you have the ability to upload a GeoJSON, or draw the shape yourself using the drawing tools.

You can add further criteria to the policy, adding a date range (you can also leave it open-ended), limit the days of the week or hours of the day during which the policy applies, limit the types of devices or the providers for whom the policies cover.

Buffering Policies

Because of the practical reality of GPS error, there are often two different dimensions of a policy zone. There is the "official boundary", which represents the shape which should be communicated in the Policy API, and ultimately to the customer. But there is also the "enforced boundary", which describes the catchment area of data around the policy. The catchment area can be changed depending on what you are trying to minimize:

False Positives: A false positive occurs when you count a device in a zone when it is not in reality in the zone. To reduce false positives, shrink the enforced boundary away from the official boundary.

False Negatives: A false negative occurs when you do not count a device in a zone, when in reality it is actually in the zone. To reduce false positives, increase the enforced boundary beyond the official boundary.

Boundaries are editable for each regulation type using the Compliance Buffer. In general, cities prefer to increase the size of a parking hub beyond its official boundary, and to decrease the boundary of a no parking zone. Once a regulation is in place, the compliance buffer can be easily adjusted or re-adjusted.

🚧

Be careful to avoid creating a negative buffer which reduces the effective area of a policy to zero or a negative shape- you will not return observations this way.

Drafting and Publishing Policies

If the option has been enabled in your scope, you have the ability to default to making polices "private" first, requiring them to then be published. You may want private policies if you are trying to evaluate the prospective effect of a policy, for example. Private policies are not shared in the Policy API, nor are they made public in the scopes of operators in your city. They are only available to the owner of the scope.

When a regulation is created under this setting, the user will be asked to save the policy privately.

The regulation will then be considered "unpublished", and can be edited or modified in the future.

By selecting the three dots above the "unpublished" button, an admin can "publish" the policy once it has been finalized. Publishing the policy adds it to the Policy API and provides it to all scopes subscribed to policy changes.

A policy cannot be "unpublished", as the record of active policies is immutable. However, a policy can be disabled, ending its enforcement.

Reviewing Existing Policies

On the Regulations page, you have the ability to search for individual regulations, or filter by status (Active, Expired, Not Active Yet, Expiring Soon), or rule types (no parking, caps, etc.)

Please see below a definition of all the statuses:

• Activity
  • Active: start date in the past, end date in the future or no end date; so basically in effect right now, collecting infringements
  • Not Active Yet: has a start date, that is in the future
  • Archived: no longer in effect, that had an end date in the past
  • Expiring Soon: in effect, end date in next 48h

Publishing (notion of sharing externally the regulation - to operators)

• Unpublished (= Private): not on the Policy API, not being communicated to Operators, can still collect metrics on it, it still functions and can be seen in the Control panel
• Published: send in the Policy API and is communicated to Operators

Video Resources