emilyeros
commented
4 years ago What we already have
The regulation and manifest already communicate the following info:
What the payment object can store
In addition, the payment object could hold the following info:
In this model, the payment object can contain a set of rates as well as a set of conditions when those rates apply.
This means that we can specify a rate(s) that apply to conditions like the time of day, time of entry, user permit, or vehicle type. A payment profile can include multiple sets of these rate-condition pairs. For example, it could assign a $2/hr charge for weekday parking during business hours, and a $10/8 hr charge for early bird parkers that arrive before 9am. The payment profile can also describe what forms of payment are accepted, and the name and contact of the parking operator.
Conditions could hold the following properties:
- Timespans. This includes the ability to specify whether this is a "rate timespan", such as 9am-5pm Mon-Fri, or a "entry" or "exit timespan", such as 6am-9am. Note that the entry and exit timespans are likely less applicable to curbs and more applicable to off-street parking. But it's a light enough addition that we could consider adding them in for those who need this field)
- User classes. This includes properties such as the vehicle type, permit type, emissions rating, vehicle size or weight. CurbLR is designed to hold information about the parking rules and rates, but is not intended to hold enough information to necessarily determine which rate applies to a given user. For example, the spec may list the rates that apply during different times for motorcycles, passenger vehicles, and commercial vehicles. But a navigation or routing app would need to ask for additional informational information from users (and potentially combine this with a LPN database) to determine which of those three categories the user falls into.
- Occupancy (in grey font, recommend that we hold off on adding this to the spec). At least one city (Madrid) uses real-time occupancy as one factor that determines a parking rate. This is very rare. If it becomes necessary, CurbLR could add an occupancy object to store the occupancy rate (e.g. >80% full) at which the rate is used, along with some sort of zone number (ex. 18A) that a payment or navigation app could use to query an occupancy database for the desired destination. Let's hold off on that until at least one data producer/consumer actually needs this feature.
- Sessions (in grey font, recommend that we leave out). I've spec'd out the minimum fields that I think are necessary to cover examples like Oak Park's maximum overnight parking sessions per month. However, these types of rules are very rare and difficult to enforce without a dedicated mobile permitting and enforcement provider (e.g. you couldn't do this with regular street signage and parking officers). They add a lot of additional complications to an already-cumbersome part of the CurbLR spec (probably bc these "rates" seem like a way to push out NIMBY land use policies rather than a way to charge for parking). Given the bulk and complications, I think it's better to leave this out of the spec for now and treat it as something that dedicated mobile payment/permit operators handle within their platforms. If it is necessary to include this information, it could be done by specifying a permit type (ex.
permit=free_overnight,permit=paid_overnight). This communicates to the user that an overnight permit is required. It would be up to the payment platform to check records to determine how many previous permits that person had obtained and what price should apply. This is consistent with how CurbLR handles residential or commercial permits; the spec describes whether these are needed but does not list their cost, how to obtain them, or the guidelines for permit eligibility... that's on the local user. - Other properties. These hold information about how a payment can be made, which device(s) or zone(s) the street segment is associated with, which operator is responsible, and the associated phone number. These are already part of the CurbLR spec.
Other, city-wide info about payment terms
Additional info can be included in the payment object or the manifest to determine the area-wide specifics of how rates are calculated. (e.g. what math rules apply)
Other payment properties, such as operator may be suitable for bundling into the manifest as well.
Which uncommon use cases does this handle?
Below, I've repeated the list of exceptions we discussed, with a comment about whether or not this spec handles the use case.
- 🤷♀️Fee or eligibility based on entry or exit time that differs from paid period time block (paid period from 9am to midnight, last entry at 5pm). Note: Sort of solved. Entry or exit timespans could be included in the payment object of the spec. For some cases, this is pretty simple because we the regulation stores the time when it's valid to enter the space, and then the payment object to lists the rates that apply at each set of entry times. For others, this is more difficult. For payment purposes, we can specify exit times and their associated rates. But the regulation doesn't currently have a way to state that existing users can stay but no new users can enter - I suspect this is particular to off-street lots/garages. It's something we'd have to think about more. It may not fit well into CurbLR, particularly if it's not really a curb thing.
- ✅Overlapping rate blocks (early bird entry, regular entry).
- ✅Enter before paid period starts, pre-pay for overlap with paid period (ex enter at 8am, paid period starts at 9am). Note: the difference in the regulation timespan and the payment timespan enables us to do this. For example, the regulation would state that a section is free parking until 9am, then paid parking from 9am-6pm. The payment profile states that $1/hr is required for parking 9am-6pm. If someone enters at 6am, there's enough information to determine that payment is not necessary for the first 3 hrs. Making a pre-payment is for the payment company to do.
- ✅Event-based rates and exceptions (ex. Game day). Note: already part of a timespan object, though concept of "game day" must be externally defined or triggered.
- ✅Session extensions and isolations (ex. First 15 mins free, then $1/hr. Extending a session should use the last fee in the array, rather than starting from scratch. That should happen on implementer side). Note: There's enough info in the array for an implementer to do this; they just need to make sure they use the last number in the array for extensions.
- ✅End parking early for full refund (ex. within first 10 mins) or partial refund (ex. Return to car earlier than expected). Note: Captured in manifest properties.
- ✅Fractional parking, rounded to nearest X unit (ex. Indicate if $5/hour also means $2.50 per half hour, and if so, what is the appropriate interval to round to). Note: Captured in manifest properties.
- ✅Rate amounts dependent on length of stay (ex. $2/hr or $10 for 8 hours). Note: there's an option to store multiple rates (amount + duration) to capture this case.
- 🤷♀️Example: In Oak Park, 2:30-6am permissions and rate and based on number of times the user has parked overnight in past month, and can be pre-paid. Note: this is addressed in the comments about holding a set of session properties in the payment object. I don't think this is a good idea. I do think the essential info can be captured (when necessary) by storing this type of info as a particular kind of permit that's required, and treating like any other permit.
Based on feedback from payment company. Cases to consider handling: