[Policy API] better support for fee 'schedules'

[jean-populus]

Is your feature request related to a problem? Please describe.

A lot of cities are moving towards more sophisticated fee structures where the price can vary by state duration or time or day. Currently it seems like a separate rule needs to be created every time the price changes. But it seems there might be a more elegant way to convey this information given that all the other variables are the same and only the price is changing. I've seen other schemas around parking pricing that use 'tables' that seem like they could work here too.

Describe the solution you'd like

Is this a breaking change

• I'm not sure

Impacted Spec

• policy

Describe alternatives you've considered

Additional context

[marie-x]

Yes, if you want a series of price changes during the day on a fixed schedule, each time-period needs its own rule.

I like fee tables in addition to flat fees. Can be done non-breaking. But tables would be an optimization.

Is dwell time an example of "state duration", or the same thing as "state duration"? Can you provide a couple of concrete examples?

[jean-populus]

One of our customers has parking fees based on a duration table:

• 0-30min, free
• 31-90min, $0.02/hour
• 91-150min, $0.04/hour

Then for their no parking zones they assess a fee/fine as a table as well:

• 0-30min, free
• 31-90min, $0.04/hour
• 91-120min, $0.08/hour
• 120+, $25/hour

[schnuerle]

Notes from the working group meeting discussions.

• GBFS has support for more complex for pricing. However, the design is intentionally more human-friendly than machine-readable.
• Car share and e-moped programs are used to parking fee structures - does it make sense to create a parallel structure?
• Populus works with car share and others, and they use fee tables.
• It can be expressed with spec, but lots of new rules
• Policy not designed for human readability but 30 rules in Policy vs a table is more complex
• Looks messy if you put it in Policy now

Even if it is messy, is this possible for you to show these examples here using Policy as it currently is? Then we can discuss how complex it is and how another solution might work.

[jean-populus]

Yes, we can certainly use Policy as-is. There's no issue really, just messy. This was just a nice-to-have request for our consideration.

…

On Fri, Feb 12, 2021 at 7:28 AM Michael Schnuerle ***@***.***> wrote: Notes from the working group meeting <https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2021.02.04-(Joint-Working-Group)> discussions. - GBFS has support <https://docs.google.com/document/d/1gJYR2u-rfZI0-HxHkhiXz5nkh7vR1JF2Ux4NwiCI4Gg/edit> for more complex for pricing. However, the design is intentionally more human-friendly than machine-readable. - Car share and e-moped programs are used to parking fee structures - does it make sense to create a parallel structure? - Populus works with car share and others, and they use fee tables. - It can be expressed with spec, but lots of new rules - Policy not designed for human readability but 30 rules in Policy vs a table is more complex - Looks messy if you put it in Policy now Even if it is messy, is this possible for you to show these examples here using Policy as it currently is? Then we can discuss how complex it is and how another solution might work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#621 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN6R4GDLMFNAWHPJFTW2B33S6VCJ5ANCNFSM4WZZNM6Q> .

[jean-populus]

Posting an update from presentation MDS Policy Extensions 15 July 2021

• Might be premature optimization
• Proposal: defer any decisions for now

FYI I support deferring this issue. We can close it for now and see if it comes up again.

[jean-populus]

This could be resolved by implementing #785