Proposal for More Detailed EV Charging Station Pricing Tags

General talk Tagging general discussion
, ,
1

(Copied from r/openstreetmap)

I’m working on adding comprehensive pricing information to a Lidl charging station and would like to discuss a tagging approach that could handle the complexity of modern EV charging pricing structures.

Current Scenario:

The station has 3 plugs:

  • 1× Type2 (43kW) @ €0.35/kWh

  • 1× CHAdeMO (50kW) @ €0.45/kWh

  • 1× CCS (50kW) @ €0.45/kWh

Challenges with Current Tagging:

As far as I know, individual socket tags currently only support power, voltage, and current specifications. However, modern charging stations have increasingly complex pricing that varies by:

  • Socket type (different plugs at the same station)

  • Payment method (credit card, app, RFID, etc.)

  • Starting fees (socket-specific connection charges)

  • Idle fees (charged per minute after charging completes)

  • Grace periods (time before idle fees begin)

  • Authorization holds (e.g., pre-authorization of €50 that’s later released)

Proposed Solution:

I’m thinking of something like: socket:<socket_type>:<payment_type>:fee= where the fee value is in local currency per kWh.

Additionally, we might need tags for:

  • socket:<socket_type>:<payment_type>:starting_fee=

  • socket:<socket_type>:<payment_type>:idle_fee= (with appropriate time unit)

  • socket:<socket_type>:<payment_type>:grace_period=

  • socket:<socket_type>:<payment_type>:authorization_hold=

2

In my area you’d need to consider that the $/kWh can change during the day and, as far as I can tell, may not be the same every day of the week. Given that type of dynamic behavior, I will not be tagging EV charging station pricing in OSM.

7 Likes
3

I know the pricing systems are a mess. But currently the best thing that I can do is post comments on Plugshare about it since the tools only let me specify a fixed price.

4

Please don’t add pricing to OSM. Where will it end? Will you use OSM to track how much a pound of apples costs at the local supermarket? Over here, fuel prices at gas stations change up to 20 times per day. This doesn’t make sense - OSM is not suitable for this kind of endeavour.

11 Likes
5

I’d argue the juice isn’t worth the squeeze.

We don’t track gas station prices because these changes happen more than 3-4 times a year. The data would be outdated by the time slower toolchains catch up.

Oklahoma mappers tried to keep up with OTA toll changes, but, there was a myriad of problems: Things nominally landed on “full length base 2-axle fare when paying with PIKEPASS” but that’s woefully incomplete: What’s the fare for shorter distances? What if you have more axles? What about PlatePay? And then diving into PlatePay, which jurisdictions plates can it actually look up and which ones are effectively free (we formerly, before this year, got a lot of Swiss, German and Austrian tourists bringing their own car or campervan to tour Route 66 and/or indian country, and PlatePay doesn’t understand EU plates, so those drivers haven’t been charged since OTA stopped accepting cash).

How would charge point pricing be any different from either of the above?

3 Likes
6

Charger prices don’t fluctuate like fuel or groceries. Most networks update prices maybe once per year. It’s more similar to parking fees, tolls or public transit fares, which are already tagged in OSM without issue.

1 Like
7

I get your point. Gas and tolls are chaotic because they’re influenced bt dynamic markets, vehicle categories and live systems. But charger pricing isn’t nearly as messy.

Most networks have simple, published static price tables. The difference is that tolls and fuel require constant field validation. Charging rates are part of a network tariff policy.

Even partial data (like “AC 0.35, DC 0.45”) is still more useful than nothing for route planners, aggregators, and data analysis, just like how maxspeed=* or opening_hours=* aren’t always perfect but remain invaluable.

EDIT: That being said, I agree that my original proposal would involve unnecessary manual work. A more efficient approach would be to group chargers by network, allowing pricing data to be updated once per network rather than for every individual charger.

8

(Writing this as a German)
As others already said, I too think it is not beneficial trying to map these prices:

  • There is not one price; depending on the operator of the charging station, the network the use is with or if it is only ad-hoc the price differs significant
    • might also differ if your already exceeded your monthly kWh quota
  • Shell apparently started to test dynamic kWh prices based on current market prices in July here in Germany. On the first day they apparently had 6ct difference (~10%).
  • I think most people are part of a network where they get good prices with certain operators. Therefore network and operator information is much more valuable.

What I would think would be much better: Map the ref / ref:EU:EVSE data. This would allow data consumers to access up-to-date data from the respective operators.

One thing what can be mapped is if there are “blocking-fees” after a certain time. These normally don’t change often and could be handled like normal parking fees.

3 Likes
10

First of all, you should know fee= is =yes / =no
What you are looking for is charge=
You have already said “modern charging stations have increasingly complex pricing that varies by” many things. That alone is already an argument against adding them all. Complicated fare systems are not added.
Besides what’s mentioned here already, you could consider linking to the price list eg charge:url= similar to opening_hours:url=

11

First of all, you should know fee= is =yes / =no
What you are looking for is charge=

basically if charge is given we can omit fee, or is it desired to add a little redundancy here?

For the general idea I agree with Frederik, tagging the current pricing seems out of scope because too volatile. Even if the prices still seem more or less stable now, it is foreseeable that practices will likely align with what we see for petrol: highly dynamic based on various factors (e.g. demand).

12

I’m not sure this will be the case for that much longer though. We have already had some people in this thread comment that pricing is dynamic in their country. I suspect the same will happen in other countries. The charge point operators will be exposed to dynamic pricing in the wholesale electricity market. In time they are likely to pass this dynamic pricing on more that currently. In my home country we have some apps that offer discounts on the price when wholesale electricity prices are low (due to lots of solar and wind).

Best to hold off from adding prices in OSM for at least a few years to see how this market develops.

P.s. I recently updated a load of EV charge points in my home country. Every instance of price data I came across was already wrong.

2 Likes
13

This is exactly what i am doing in Greece. Having a unique key in whole of Europe for every charging station is a solid base for reference in maps and data gathering.

14

Thank you for this.

Looking at the wiki it seems the equivalent in the US would be to add ref:adfc=* information to each charging station. I just checked and the charging stations in my area were missing that so I have added it. And I have made a note to myself to include that reference information in future when editing EV charging stations.