Web conference notes, 2021.04.01 (Joint Working Group)
Joint Working Group - City Services
- Every other week call at 9am PT / 12pm ET / 6pm CET
NOTE NEW ZOOM MEETING ID/LINK/PHONE! (as of Jan 1, 2021)
Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09
One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)
Dial by phone: +1 929 436 2866 (US) (Find your local number)
Add your own name, link, and organization during call
- Michael Schnuerle, OMF
- Matt Davis, Populus
- Steve Brining, BlueSystems
- Marie Maxham, Ellis & Associates
- Seth Herr
- 23 attendees
Main Topics
- Status of MDS 1.1.0 Release - Approved and live in
mainanddev- Michael - Discussion of new Policy issues:
Status of MDS 1.1.0 Release
- Approved and live in main and dev – Michael
- MS: Now in the main repository
- Now there are links to “Who’s using MDS” with links to cities with mobility providers, 3rd party software companies, cities, etc.
- JF – Thanking everyone who contributed to this for making it possible.
- MS: FYI We’re working on the 1.2 release now also
- Working group steering committees are meeting next week for one of our 4 checkpoint meetings. It’s our Midpoint, when we check to see how the proposals for the release are going.
- We’ll go over what’s here and use a newly developed rubric to help evaluate features and establish agenda for upcoming meetings.
- Will share results of that at next week’s meeting as well.
#633 add rate options to other rule types
- Cities want to be able to assess a fee due to non-compliance - for example a 10¢ fee for vehicles over a cap, or a 25¢ fee for each time a vehicle goes over the speed limit.
- Instead of creating separate rate rules, it would be nice to be able to attach a rate to one of the existing rule type (counts, time, speed).
- would there also be a grace period designed in, so that x amount of time after vehicles exceeded a deployment cap?
#632 support one-time fee after a buffer/duration
- Cities would like to implement a fee if a parked vehicle isn't moved after for example 2 days. This is a one time fee but there's a buffer/duration before it applies.
- We could add a new field for this buffer/duration before the rate is applicable?
#631 support parking fees by duration Policy
- Some cities have implemented fees where the rate varies by how long the vehicle is parked. This is to encourage operators to move vehicles.
- Proposals for extending MDS Policy API
- add new field for rate_duration, similar to what's in CurbLR for payments
- allow for arrays in rate_amount and rate_duration so we don't have to create new rules to accommodate the different rates by duration
- Jean Kao/JK: Talking about different prices for different parking durations. Some cities want to incentivize moving vehicles that have been parked too long.
- MS: You have cities requesting this?
- JK; Yes, one at the moment
- MS: Do you want to talk about your example?
- Neil Goldader /NG: You wouldn’t have a separate rule type for rate. Gets weird with temporal policies.
- Have a rate recurrence, looking at if statements and apply the rule that it matches
- Not specifying 2 hours after 1st rule since that was handled in first rule, and on down.
- Trying to capture tiered use cases for dwell time.
- Also can be used for spending a duration in too much of a state.
- Could limit trip times/length
- MS: looks like it works, need to take into account it’s hierarchical.
- https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/policy#order-of-operations
- MC > JC: What do you think
- JC: Wants to have a general discussion on why we can’t add rates to all rules.
- JC: I see you add a boundary, why?
- NG: You could have 0-1 hour bucket, and having the bounds means you meet the condition of the rule
- Semantics could change so we could change the trigger.
- MC: You’re describing about how policy is setup also, when you define the policy you want to make sure you’re inside the bounds of the policy. Positive vs Negative correlation.
- NG: Going in reverse order works for this, given the way it’s currently designed, but not intuitive at first.
- NG: We could add more language to explain how this works. We don’t have compliance that works in MDS yet. Need to apply how Compliance works to add that sentiment to Policy
- JF: on compliance, we might also consider providing examples on how rules should be evaluated.
- NG: Had some pseudocode for how the evaluation was supposed to work. So maybe that could work too. Would like to get some diagrams too.
- JF: this makes sense, showing it in pseudocode instead of a reference implementation
- JK: wants to summarize understanding that most fees would be from non-compliance. Because it’s not really a non-compliance policy.
- MD: Need to apply fee when it doesn’t match the rule
- MD: incredibly unintuitive to write a rule for everything that doesn’t match it.
- JK: looks like we can reuse the rules we have a combine it in a different way.
- This idea could be applied to 6 different policy issues, and may be able to apply to all of them.
- If Populous wants to move forward with this, can we just do it or does it require a release?
- MS: What Neil did here works back to 0.4.1
- NG: I worked on it starting in 0.4, so should be backward compatible.
- MS: Suggest adding it to the spec so that it’s referenceable.
- Adding example to README
- NG: Do we still want to have rate rules as their own thing?
- We could either keep rates as a rule, or make it so rates aren’t a rule type anymore.
- MS: Doesn’t think we have to do that before we do the example.
- Not sure if it’s going to be breaking > NG: Probably would be
- NG: Mark rate rules as deprecated but supported somewhat so you’re allowed to do both.
- JK: We have some rules that are rate only. Could rewrite them so everything gets a rate.
- MS: Are there other items you want to talk about now that you think could also apply to this?
- JK: I want to go back an review these issues and come back.
- NG: We can look at buffer and duration example in #632, just days not hours, and only charging once.
- MS: These are good examples. Enumerating a solution to a problem that isn’t clear. NG > can you come up with some examples on the other issues that are open?
#618 Support vehicle distribution by percentage
- MM: Said we’d need to add a new rule of percent.
- MM: We’d need different units. Will do an example.
- MS > JK : For your use case, you’re thinking of a more dynamic situation?
- Like always 20% and some value you’re trying to track?
- JK: It’s a percentage of the vehicles out there for the day in Baltimore.
- Hard to express the way the policy spec is right now.
- MD: Also, is it at a point of time or are we averaging within a window?
- JK: For Baltimore, if vehicle counts change they are supposed to rebalance.
- JK: Counts could change but the percentage would stay the same.
- MM: This would add some flexibility for sure
#620 Support Utilization Policies
- MS: We talked about this in previous meetings.
- JK: What we have now are counts and times. Even if we refer to the concept of utilization, people know what that means. The concept doesn’t exist for now in the spec.
- MS: Maybe on this one, you gave some examples of what cities are asking for, MM has some questions, maybe we could flesh this out some more.
- MM: Neil and I will go back and look at that.
