Open ksinga opened 1 year ago
A key question I have about EV-chargers as "curb adjacent" is whether we're just talking about the location of the EV chargers in physical proximity to the curb and parking lane, or if we're also considering data/information from the EV chargers as well? While the former is interesting, I think the latter is more valuable from the city-perspective.
For example, there's data from EV chargers that is of the public interest, such as charger utilization, total charge time, average charge time, kWh, cost to charge, etc., that would help with curb management and city planning. Some of these metrics could be useful for determining when to sunset an EV charger (because of low utilization) or add more (because of high utilization). Information about cost would be useful to ensure residents in underserved areas are not being given a higher cost than residents in other areas that might see more use.
However, at this point in time, I do not believe this data is being considered as part of CDS, or am I wrong? I also understand there is not an adopted, consistent specification for what that EV charger data would entail either. I recall that Atlas Public Policy has done some work on a Charging Use Spec, but it's not widely adopted at this time.
As we work on CDS, I think we should discuss whether EV charging fits in it, or if we need to spin up another committee to explore this topic more thoroughly. The federal government is putting $7.5 billion into EV charging around the U.S., so let's not miss this opportunity to get it right from the outset.
@jacob-sherman For EV chargers in CDS both location and more info are on the table for discussion. The first step is a way to define the location of all types curb-adjacent elements in CDS. Then each of those elements could get custom information fields and details defining them (like the publicly published Curbs API) and then they could additionally get usage info (like we do with Events API) and even metrics (Metrics API) on top of that. This data could certainly be considered as part of CDS, or as some sort of extension to the spec, or possibly a new spec.
We do want to evaluate what is out there already. It could be that we just point to an existing spec. The trick is most of the existing ones are a) only defining the chargers and not providing usage/metrics or b) have unclear or non-open governance and development processes which is important for updates and buy-in and open ecosystem creation and c) clear privacy concerns and data sharing agreements. Here is a short list of specs we've looked at, talked about in WG meetings, or had presentations on:
EV Charging as a CDS object seems like a no-brainer to me. "Re-fueling" for EVs will look much different than for gas powered vehicles (unless we find a way to fully charge vehicles in under 5 minutes. I anticipate we will eventually see quite the variety of ways for EV owners to charge their vehicles while also doing something else as the vehicle is parked. And with curbs being one of places we often park vehicles for extended periods of time, this seems like a natural location for lots of EV chargers to be located. @jacob-sherman does a great job with first pass at all data points that may be useful to gather to ensure that limited curb space is being utilized efficiently for the public good.
Is your feature request related to a problem? Please describe.
Interested in learning about and contributing the regional and policy perspective.
Describe the solution you'd like
This is not a solution but some topic possibilities as well as a CDS need:
Is this a breaking change
A breaking change would require consumers or implementors of an API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
Impacted Spec
For which spec is this feature being requested?
Curbs
Events
Metrics
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.