Bridging CDS's current form and Montreal's needs

[LaurentG-AMD]

Following the meeting we had the opportunity to attend this summer, I am posting our primary concern regarding the current model in order to initiate a discussion. While I am unsure whether it should be formally categorized as an issue, its significance warrants our attention and deliberation before proceeding with breaking it down into potential changes.

With that said, here is the central topic:

A rapidly evolving regulation that uses a different logic than CDS

The Agence de mobilité durable (AMD) covers the whole territory of the City of Montreal, representing ~8000km (5000 miles) of curb. While the outer boroughs may be relatively simple in terms of regulations, the inner boroughs are notorious for segmenting the curb into tiny zones catering to different usages (up to 10-20 zones on a single streetcorner). Most of these regulations are often time bounded and the zones may overlap differently throughout the day, week or year (with school and/or summer/winter related regulations). Moreover, these regulations constantly evolve at a very rapid pace: up to 2000 changes/month globally and they seldom affect uniformely what was previously existing on the curb.

These overlaping regulations are mainly excluding people from using the space since the default state is that parking/stopping is legal unless otherwise specified. From these interdictions/prohibitions emerge the zones where people can actually stop/park and this is in opposition with how CDS seems to be working, where the parking zones is the primary building block on which regulations are attached. While this may seem minor, it had implications on how maintaining the data up to date and the history relevant can best be implemented.

The implications with the current model:

Receiving a change in policy

• In Montreal, when the city changes a regulation, they mainly provide the locations of the new signs that will display it on the street. This means that we have an array of one or many points in space to work with that then needs to be transformed into a curb geometry depending on some properties.
• The transformation from sign(s) to geometry itself is out of the scope of the CDS model but it cannot be avoided. Which means we basically end up with an augmented policy object that do not really fit the current paradigm where policies are saved independently from the geometries and can be refered to by many zones.
• However, these geometrically enhanced policies are necessary to determine which CDS zones are affected by the change we are trying to implement.

Now, this could all be worked with behind the scenes and these objects discarded once the changes implemented, but these objects are still really interesting in themselves and we built them anyways... so why not save them?

Exploring policies

The number of different policies existing in Montreal depends on your actual definition of "different", but for the sake of this discussion, the AMD considers any entry in the Policy table to be different policy. By this definition, then number of different policies in the city are actually unknown as of now but are estimated to be in the hundreds. Which means that exploring what exists on a single street becomes more of a chore: to know where a single policy that exists inside one of the multiple zones on a given street exists, one must query throughout all the curb zones that exist on said street and join the geometries that return positive. This rapidly becomes unoptimal to explore the regulations in a given area, which is something the AMD does quite a lot.

The impact of Curb Zones

As mentioned, regulations in Montreal often overlap and changes to regulations are not always made to match the geometry of any other pre-existing regulations. Moreover, these changes may or may not (more often not) match the Time Spans of other regulations.

With the conditions set to define a Curb Zone, this means that the process of updating the model to the changes made on the ground will involve quite a bit of geometry splitting and/or merging, which in CDS means deprecating previous curb zones and creating new ones.

History

This then means that the history of events or metrics for this particular zone will be lost or needs to be archived in a way that can be linked to the new zones, which is not yet something that the current version of CDS can handle.

What would need to change?

We don't prentend to know the best way to reconcile our needs with the current functionalities all while breaking the minimal amount of things. We understand that we approach this subject from an angle that might not fit entirely with how the data model was first envisioned, but there might exist a point where most of our issues become backend concerns that could be mostly transparent to our main users and there might exist more than a single path to reach that goal.

Our next steps

We are currently working on a project to create an Open Data Portal in order to share as much mobility related data as possible with the public and are determining which standard to use, We believe that if the changes we are opening up to the discussion are implementable, it could be a great use case to present CDS to the public and academics that will be using the platform.

[bhamlinSDOT]

@schnuerle Thoughts on this? I missed this post last month and need to review.

[schnuerle]

This is a great comment and something to discuss. The public working group talked about this a lot when CDS was created. I think there is importance to thinking about how changes to zones work, what qualifies as a change, how to handle lots of more real time changes, and how historic zones can still be tracked and referenced for auditability and data completeness and maybe stored separately from the main feed to reduce file sizes.

If you are familiar with the spec as is, how do you think it could be updated to accommodate these needs?