Web conference notes, 2021.07.15 (Joint Working Group)

Joint Working Group

• Every week call at 9am PT / 12pm ET / 6pm CET

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)

Note: We are now collecting attendees upon entry into the Zoom meeting. A count will be posted after the meeting.

20 Attendees

Main Topics

1. Policy API updates - review ideas, pull requests, and new examples to address requests to update or clarify the Policy API.
   • 6 example additions can be found here
   • Presentation deck here

WGSC Meeting Organizers

• Host: Marie Maxham
• Facilitator: Angela Giacchetti
• Outreach: ...
• Note taker: Steve Brining

• MM – showing slide deck, noting that this is representing work from a lot of people at E&A

• Digital policy design goals

  • Focus on use cases, and focus on composability over complexity, clear measurability, machine-readability, and leaving room for expansion

• Digital policy original design decision

  • Separating geography from rules about geography, measuring against events, but not trips, since it’s sufficiency different. Didn’t try to rebuild calendaring. Because they’re using simple components, just use more, and didn’t include fees and fines initially. Immutable data means you can’t change history
  • Ordering of rules is important, humans can read it, but machines must read it, and some suggestions might be valid, but not having any premature optimization MM > Reviewing the 6 tickets that JK suggested, linked in agenda
  • We’re looking at 3 categories broadly for these issues: Can do already, Can do with non-breaking changes or clarifications, Breaking change
  • Issue #633 – adding rate options to other rule types, being able to assess fees over time.
  • There’s nothing that says we can’t apply fees to other rule types. For example, attaching a rate to a count rule
  • Its’ compatible with 1.1, but clarifications are needs if we want to make it more robust for 1.2, and it may be possible to drop the rate rule-type
  • JFH: Asking about time related to this and rate recurrence
    • NG: A time example is under #631
    • WH: Might be possible to simplify, but they added it instead of leaving it implicit to avoid rules that are nonsensical or ambiguous (logically inconsistent)
  • WH: Why stop at rates, could you combine account and time?
    • MM: We’ve discussed, and it’s worth exploring, but it can get messy. This could be for a separate discussion.
    • WH: Would suggest maybe a discussion for rule types
  • JK and NG – agrees on a discussion for this

• Issue #631 – support parking fees by duration

  • Showing an example on an escalating fee structure, and thinks it’s pretty readable, and showed PR658 related to this
  • NG: Made some additional changes outside the scope, and extended rate recurrence to change “once” to “once on matching”, and asking for feedback on this. “Once” previously occurred when matching the rule, but also wanted to capture when you exited the status. Provided example of parking duration based on how long you were parked, with variable rates, vs a flat rate just for parking.
  • WH: One other idea: instead of dropping rates rule type we could rename it to something “instantaneous” that clarifies its function and makes it more intuitive to have Fee/Fine rules that don’t use ‘rate’ rule type

• Issue #621 – better support for fee schedules

  • This might be a premature optimization
  • Proposal is to defer decisions on this right now
  • JK: I think that’s fine, but am also wondering if there’s any alignment with the CDS working group?

• Issue #620 support utilization policies

  • Need to rigorously define “utilization” to have a utilization policy, and there are interesting possibilities for metrics-based Rules, like “measure against this metric”
  • Some provider may have incentive to maximize utilization
  • Proposing to move forward on Metrics-based Rules, if not for 1.2 then 2.0
  • WH: Wouldn’t cities want to be in the position of evaluating a metric that affects compliance or fees?
  • FR: +1 for the ratio, in the case of fleet size, that could vary over time, otherwise it requires to re-adapt/change all related policies with a new count
  • JFH: Can we compose Metrics inside of Policy, and if not, how do we refer to, or recycle the Metrics definitions? Should metrics be separated from the Metrics API?
    • Note: Metrics discussion: https://github.com/openmobilityfoundation/mobility-data-specification/discussions/659
    • We should take advantage of Policy being immutable, so related calculations could be immutable.
  • JJ: As an operator, would like if the OMF, show recommendations or how they can use their own? They have a hard time, since even their own utilization calculation is complicated. Maybe for consistency across cities that cities can adopt if they chose to.
    • BH: +1 from Lime, and maybe more parameters so cities have more flexibility on metrics.
    • JFH: Can you clarify on that.
    • BH: For example, when counting vehicles in MDS, how many days to look back for status changes (like 2 days), and this can change vehicle count.
    • WH: Exactly. Look-back period doesn’t exist as a concept in the spec but IRL it’s critical
  • Agreeing: JJ, MM, NG
  • NG: Explicit encoding of look-back (specifically for Count policies where you have to consider the state across an entire fleet at a point in time) would be soooo nice
  • WH: FWIW there’s a ton of variability in implementation even with a policy as simple as Vehicle caps. I’m not sure that Utilization takes us across a bridge that we haven’t already crossed

• Issue #619 – Clarify how to meet min for vehicle distribution policies

  • This one also may make Policy more complex, and we’re lacking some very specific examples.
  • Proposing to collect examples and revisit.

• Issue #618 – Support for vehicle distribution

  • Another example of where a Metric-based Rule would provide a huge amount of flexibility and shift defining “distribution” out of Policy.
  • Coming up with the way that describe this elegantly without affecting/increasing complexity is the challenge.
  • JJ: We’re also challenged with vehicle distribution measuring challenges between operators and cities. Would like common ground on defining critical policies have in some form. Would like to know more about working group progress related to this.
    • JFH: Will open discussion item on metrics that need a common definition
  • Will be careful on taking things today and having a suggested calculation method.
  • Proposing for 1.2 or later

Action Items

TBD

New Attendees

N/A