Talk:Tag:amenity=charging station

From OpenStreetMap Wiki
Jump to navigation Jump to search

Gathering proposals in a collaborative sheet

Anyone can summarize things in this sheet: https://lite.framacalc.org/charging-tags-osm

Authentication vs Payment

Perhaps its interesting in the first place to note the difference between authentication and payment. The payment has the role of an authorization. Ideally such an authorization should allow anonymity or at least pseudonymity in the sense that no trace is left who made the payment. If a charging_station offers its use without the need of becoming a member in any way, it might be worth mentioning. Guess you are travelling on foreign grounds, and all charging_stations rely on a chip you just dont have. In other context great efforts are taken to allow anonymous transactions, e.g. three-tier AAI (Authentication-Authorization-Infrastructure) systems as Shibboleth and Athens.. (And what about cryptocurrencies?!) 

Proposal: use the 
payment=paypal (or applicable) perhaps in combination with
payment:url=<the url that leads to a valid payment>

Authentication (Payment?) with QRcode/URL

There are some stations which can be used after authorization of (e.g.) 50 EUR via PayPal. This is done by calling an URL which is given on the station as QRcode. I found this on an innogy station here: https://www.openstreetmap.org/edit?node=1272507506 The charging starts after authorization, the effective prize is pulled from the PayPal account later. 

Proposal: lets invent another authentication:url=<the URL from the QRcode>

Authentication

What's about if the authentication works with a NFC chip which is in the membership card? authentication:nfc=yes or authentication:membership_card=yes? --Klumbumbus (talk) 18:54, 3 July 2014 (UTC)

I guess "nfc" is for a chip and "membership_card" is for a bar code? --Beatnick (talk) 18:01, 8 Nov 2018 (UTC)

RFID authentication

Is authentication:nfc=yes designed to include the traditional RFID chips present in many credit cards? I'm assuming that it is unless someone argues otherwise. T99 (talk) 23:03, 20 July 2014 (UTC)

Seems to be so. I thought at first this was for systems like ChargePoint, but those should use membership_card instead (even if they are using NFC.)

--Mapify (talk) 09:07, 1 August 2014 (UTC)

Power in kW

I propose a tag giving the maximal power in kW which a single charging point is able to give.

max-kw=xx

So a Schuko at 240 Volt can be used at 10 or 16 amp giving 2.4 or 3.7 kW

Voltage and amperage alone are not sufficient to calculate the maximal power a car can draw. With AC sockets it also depends on the number of phases. USA 1 phase, Europe and others 3 phases.

So a 240 Volt socket at 16 amp gives 3.7 amp with ONE phase (type 1 socket) but 11 kW with 3 phases (type 2 socket). At the moment this can only be calculated indirectly via voltage, amperage and socket type combined, but this is the most important information for a driver.

Barthwo (talk) 20:02, 30 June 2016 (UTC)

I agree with you, I also noticed that there is no way to map the max kw. In my understanding the amperage tag refers to the one connector with highest output. If there are multiple outputs this can be an issue, e.g.: One station with 2x Type 2 connector each with 32amp but the entire station is max powered with 22kw. This means if both connectors in use each can only be rated with ~27,5 A.

--Nickel715 (talk) 07:37, 2 September 2016 (UTC)

Such a tag is definitely necessary. In my oppinion the specification of the max power output is way more important than the voltage or amperage.

I'd suggest to specify the max power of one socket using the special tag output like it's used on generators. The power=* tag is already in use for something different. I wouldn't mix this up.

socket:[type]:output=22kW

or

socket:[type]:output=22

e.g. socket:type2:output=22kW

This value was given at every charging station I visited. Sometimes there is another description (usually on the back of the station) about the maximum power of the entire station. The maximum power available for all sockets together. (I think this is mandatory in Germany) This could be added like

output=30kW or output=30

I wouldn't add the unit "kw" or/and "max" in the tag-names, because I think both of them are implied.

--Owla (talk) 12:16, 21 November 2016 (UTC)

Currently we specify the max amperage and voltage via amperage=*, voltage=*. IMHO this is less important if there's a max output of the whole station given. I think it's more important to map the amperage and voltage of each socket type.

To sum up my suggestions here an example:


output=98kW (max output of whole station at once)

amperage=143kW (amperage input of station)

voltage=400V (voltage input of station)

socket:type2:output=43kW

socket:type2:amperage=63A

socket:type2:voltage=400V

socket:chademo:output=50kW

socket:chademo:amperage=120A

socket:chademo:voltage=500V

socket:type2_combo:output=50kW

socket:type2_combo:amperage=125A

socket:type2_combo:voltage=500V

I think this is the most self explaining syntax.

In Europe this syntax is already used 119 times: http://overpass-turbo.eu/s/kL7

whole station
charging station sockets: Type2, CHAdeMO, CCS
station specification on back

--Owla (talk) 17:50, 19 December 2016 (UTC)

I think it is the best to specify the unit indicated on the charging station. Then there are no arithmetic errors and non-engineers can also map this information
But we should specify it individually for each socket.
So I would prefer socket:type2_combo:amperage=125A before amperage=125A
or socket:type2_combo:output=50kW before output=50kW --geozeisig (talk) 08:22, 10 July 2017 (UTC)

Type B sockets

The current documentation is somewhat Eurocentric and is not specifying the tags for some connectors used in the rest of the world. I will have to start using an undocumented tag socket=typeb to refer to receptacles which accept the grounded, polarized, 3-prong plug known as "Type B" plug and commonly used in households and offices in most of North America and parts of South America and Asia. I would also like to document the tag by adding the following to the table on the main page. -T99 (talk) 03:19, 21 July 2014 (UTC)

Tags Definition Photo Comments
socket:typeb=* the number of sockets for "Type B" plugs Americas, Asia: NEMA 5-15 receptacle, also known as "Type B", maximum rating 125 V, 15 A (USA). The count should include any NEMA 5-20 (20 A) T-slot receptacles which accept NEMA 5-15 plugs. The nominal supply voltage varies by country between 110-127 V. The user must generally provide a portable "Level 1" trickle charger and connect it between the socket and the vehicle.

(Was not signed.)

Standard receptacles are a nightmare, so we should add them when they're in use. This one is.

--Mapify (talk) 09:07, 1 August 2014 (UTC)

Other Chargers

Hey,

I'd suggest adding the following:

socket:type1_combo (J1772 "Frankenplug" w/ DC charging)

socket:tesla_roadster (Tesla Roadster plug. Not [as far as I know] available as a for-a-fee charging station, but since I have seen some at public places, I feel this should also be included)

socket:tesla_supercharger (Tesla supercharger. For use only on their supercharger stations.)

socket:tesla_standard (Standard plug, found on post-roadster cars.)

Supercharger and standard should be separate although the plug is the same since the supercharger connectors are DC-enabled and in all cases official (by Tesla themselves.)

socket:magne_charge (obsolete, but still installed in some places. For the sake of completeness)

Some places also offer high-amperage receptacles. Of these, the NEMA 14-50 is by far the most used to my knowledge. The TT-30 is also used (mostly at RV parks).

For these, you could use:

socket:nema_14_50

socket:nema_TT_30

--Mapify (talk) 09:07, 1 August 2014 (UTC)

My problem is I cannot correctly assign the power of a socket. A CHAdeMO with an max ouput power of 50kW can have a different amperage related to the voltage of the battery. So Amperage is not a good choice for such sockets. Also a station can have more than one socket types which are limited to the max. of the station: A 50 kW triple charger can have a 50kW CHAdeMO, 50kW CSS and 2x 22kW Menekes Type2. But if more than one sockets are used, e.g. CHAdeMO and Menekes the CHAdeMO will be limited down to 20/25 kW. CHAdeMO + CSS usage is not allowed at the same time because both sockets use the same AC/DC charging unit.

How can we map it now? We use the old socket attribute but extend it with the power seperated by a colon. Here a view examples:

socket:schuko:2.3=2 means two Schuko plug with 2.3 kW output power (which is limited by a 10A circuit.) socket:schuko:3.6=2 means same but with 16A circuit.)

socket:cee_red_16a:11=1 means a cee red of type 16A with 11kW output power. socket:cee_red_32a:22=1 means a cee red of type 32A with full 22kW output power. socket:cee_red_32a:14=1 means a cee red of type 32A with limited output power by 20A circuit which is sometimes found.

socket:combo:43=1 means a combined socket type with a output power of max. 43kW. socket:chademo:50=1 means a combined socket type with a output power of max. 50kW.

To limit the whole charger a special attribute can be used like: socket:all:50=2 means on this combined charger max. 2 sockets can be used at the same time with a max. combined output power of 50kW on all sockets.

But to have better describtion I guess it's better to use a mechanism like the opening hours attribute which maybe can be declared as sockets (with s). The parsing is from left to right, where a new rule is beginnig with a socket name. The other in right of the last socket definition are the attributes of the sockets. the all socket type means a limit of all sockets to the right as long a new all socket has to been found. All keywords on left side up to the first socket are absolute declared limits. I use the following key words addionally as the attributes allready described:

power: power in watt phases: 0 for dc or dc, 1 for one phase, 3 for triple phase 120° phase movement plug: yes/no where yes means the chager has no socket, a cable + plug is availabe where then length: the cable length is known in m or feet ( e.g. 7m or 5ft) locking: yes/no which means, the socket locks the plug from foreign removement

Examples:

A simple socket 2 charger with a limit of 11kW: sockets=type2:1 power:11000 voltage:400 phases:3 amperage:32

A simple chademo charger: sockets=power:50000 voltage:0-500 phases:dc chademo:1 plug:yes

A charging station which is used in my near by enercity with 1 Schuko 16A unlocked + type2 22kW which also can used by 7,6kW 1phase EVs: sockets=type2:1 power:22000 voltage:400 phases:3,1 amperage:32 schuko:1 voltage:230 phases=1 amperage=16 locking:yes

Another example with a limit declared by the special all key word of 35kW sockets=all:max power:35000 type2:1 power:22000 type2:1 power:11000 schuko:2 locking:yes power:3600

A double charger of 50kW with a chademo + css which is limited by a voltage range and only one of them can be used at the same time: sockets=all:1 power:50000 voltage:0-500 css:1 chademo:1

A tripple 100kW charger with one combined dc charger for css/chademo + two 22kW socket 2 cables sockets=power:100000 all:1 voltage:0-500 css:1 power:50000 chademo:1 power:50000 socket2:2 power:22000

Here a special private charger station I found: sockets=power:43000 cee_red_32a:2 cee_blue_32a:2 cee_red_16a:1 socket2:1 power:22000 schuko:2 cee_blue_16a:1

What do you think about?

A small change to my sugggestion is to use a keyword type: + amount: instead of use type:amount like type:socket2 amount:2 ... instead of using socket2:2. In this case a all:max will become type:all simply without the amount keyword. Another small difference is instaed of use type all use type limit to limit e.g. the power. Maybe better use all for declaring e.g. voltage aso.


--Pbkawph (talk) 21:24, 18 April 2015 (UTC)

Authentication via smartphone app

What's about authentication with a smartphone app, how do I tag this? I suggest: authentication:app=yes

In my case there is also a authentication possible via text so I only mapped this at the moment.

--Nickel715 (talk) 07:45, 2 September 2016 (UTC)

authentication:app=* sounds all right to me. But I would not only map if it's possible to authenticate via an app. I'd also add what apps. Just like authentication:money_card=*, authentication:debit_card=* and authentication:membership_card=* we should give the chance to specify. To avoid different tagging schemes we could add a list of known apps to the wiki. This way all people use the same spelling to describe one app.

I don't know any of these apps, maybe someone could make a list.

--Owla (talk) 20:15, 9 December 2016 (UTC)

Parking situation

How do I map the parking situation? In Germany charging stations are often placed on regular parking areas.

  • The parking lots in front of the station can be reserved for electrical cars
  • The parking lots can be free only for electircal cars
  • The amount of reserved parking lots can be different to the amount of sockets at the station

So I think it would be helpful to map this informations as well.

--Nickel715 (talk) 08:02, 2 September 2016 (UTC)

You‘re right - we should be more precise in mapping the parking conditions for charging stations. My ideas to your distinctions:

  • The parking lots in front of the station can be reserved for electrical cars

I perceive this as a parking lot for electrical vehicles only (often blue painted ground or signs like "This lot is for electrical vehicles only" - as far as I know Tesla uses such signs on his supercharging stations). This doesn’t have anything to do with the possibility to make a reservation for one lot at a given time. For the tag amenity=parking already exists the additional tag capacity:charging=yes;no;number 

“Defines whether or not dedicated parking spaces with charging infrastructure for electric vehicles are available. If known, the number of spaces can be specified.”

But this info could be difficult to query, because it’s not actually on the charging station itself, but on the parking space. If we add another tag to the charging station the info will be twice, on the parking space and on the charging station itself. This can and will lead to conflicts. What do you think?

  • The parking lots can be free only for electrical cars

Here I assume you mean the parking fee. In the examples for charging stations there already exists parking:fee=* (I added the tag to the “Tags to use in combination” category). This can be interpreted as the fee only for electrical vehicles charging. Other vehicles which are not using the station have to pay the (default) fee=* of the amenity=parking space.

  • The amount of reserved parking lots can be different to the amount of sockets at the station

I think this one follows from the above. Amount of reserved parking lots: capacity:charging=* (currently only possible to add to the parking space). Amount of sockets usable at once: capacity=*

--Owla (talk) 19:56, 9 December 2016 (UTC)

About battery swapping stations

Hi there,

Just passing by look for suggestions for battery swapping stations, of which is not stated in the page.

Any suggestions? Since socket tag is not the best option on tagging, is there any chance to propose new sub-tag in to this amenity?

Many thanks.

--Assanges (talk) 03:04, 1 December 2016 (UTC)

conflict between english and german translation of this wiki page (CCS taging)

for the combined charging system (CCS) the english version currently uses socket:type2_combo=*, the german socket:combo2=*.

socket:type2_combo=* https://taginfo.openstreetmap.org/search?q=socket%3Atype2_combo (121 times used)

socket:combo2=* https://taginfo.openstreetmap.org/search?q=socket%3Acombo2 (80 times used)

To avoid confusion regarding socket:type1_combo=* I'd suggest adapting the german to the english one. Staying with socket:type2_combo=*.

Regarding this, I asked at the german irc, there the user Nakaner hold that we should go back to the socket:combo2=*, because the history of the english version shows the user Mentor switched the tag without any justification/discussion back in 2015. The mailing list does not say anything regarding this.

What do you think about this conflict of tagging schemes?

--Owla (talk) 16:53, 10 December 2016 (UTC)

I wrote to the tagging list and no one opposed my suggestion. So I modified the german wiki version.

https://lists.openstreetmap.org/pipermail/tagging/2017-January/030997.html

--Owla (talk) 16:29, 30 January 2017 (UTC)

inductive charging

First versions of inductive charging are getting closer to get into cars. We should be prepared for that and be able to distinguish cabled (conductive) and inductive charging stations. for example:

charging:cabled=yes / charging:inductive=yes

charging cable availability

I think we will need a tag to separate real charging stations (with the cable between car and charger) from simple wall boxes (just a socket --> bring your own cable).

maybe: cable_fixed=yes/no

  • In my opinion it is neccessary to tag this. A friend of mine has a Renault Fluence with an type1 port at the car. He can use type2 sockets but not if there is a fixed cable.

--Uboot (talk) 15:50, 8 June 2018 (UTC)

interesting point. I would specify it in more detail.

An interesting station for this case is http://www.charge-ultra-fast.com/en/Introduction-621.htm

This station has:

  • 1 CCS
  • 1 Chademo
  • 1 Type2 with a socket
  • 1 Type2 with a plug

i would suggest (in addition): socket:<type>:cable=number (number of sockets for the specified type with a fixed cable).

so for the this stations it would look like this:

  • socket:chademo=1
  • socket:type2_combo=1
  • socket:type2=2
  • socket:type2:cable=1

now its open to discuss if socket:type2_combo:cable=1 is needed too, I think no because a ccs or chademo socket does not exists so its obvious.

--Nickel715 (talk) 20:36, 13 June 2018 (UTC)

Same issue here, i want to charge my Renault on a socket:type2 but there's already a cable:type2 so they're not compatible. Furthermore, Chademo and CCS are cables, not sockets. Therefore, for Nickel715's example, I would suggest :

  • cable:chademo=1
  • cable:type2_combo=1
  • cable:type2=2
  • socket:type2=1

--Beatnick (talk) 18:22, 8 Nov 2018 (UTC)

>Furthermore, Chademo and CCS are cables, not sockets
According to OpenChargeMap reference data, [Type 2] and [GB-T AC - GB/T 20234.2] have a Tethered Connector or a Socket.
After a quick search, it seam that GB/T 20234.2 is Type 2.
So, adding cable:type2_tethered=* could be fastest and simplest ?
--Pyrog (talk) 18:18, 15 March 2020 (UTC)
ChargeMap have only the Type 2 with socket or tethered cable.
Other plugs with cable are:
  • AU & NZ domestic plug
  • CHAdeMO
  • China Part 3
  • Combo CCS EU
  • Combo CCS USA
  • Tesla Supercharger Euro
  • Tesla Supercharger CCS
  • Tesla HPWC Roadster plug
  • Tesla USA
  • Type 1
--Pyrog (talk) 19:00, 15 March 2020 (UTC)

That's something that's definitely needed. Right now none of the variants you suggested gets used at all. The only thing used that I found is the plug: tag (https://taginfo.openstreetmap.org/search?q=plug) I'll push this discussion into some com channels. --Hedaja (talk) 13:00, 25 January 2020 (UTC)

Please consider the point at the bottom of this page : are we talking about places, devices or sockets? It can't be all 3 at the same time. amenity=charging_station is not clear currently and sockets, cables are related to devices, not pool or places. Fanfouer (talk) 13:16, 25 January 2020 (UTC)

suggestion: key for amount currently used charging-slots

I suggest to add keys for the amount of currently used sockets/parking-slots, of each type; these should be live updated by the operator. That would allow OSM to have the information on charging stations available to the users in the same useful quality as a proprietary service offers it.

On the other hand there should be a solution to avoid outdated data. Therefore the information could be supplemented with a timestamp or deleted by a bot when there haven't been an update for a longer time.

Live-Data is something that's meant for OSM. This would probably overload the Servers too, as live data of thousands of charging stations and potentially other live-data would have to uploaded constantly. --Hedaja (talk) 12:56, 25 January 2020 (UTC)

Examples misusing 'name' tag

Several of the examples show name=* populated with the operator=* or brand=* of the station, rather than the station's actual name - contrary to the Key:name page, which says:

name=* tag is supposed to contain solely name, not to describe the type or location of the object or one of its other properties

Please can these be fixed?

--tms13 (talk) 17:22, 9 January 2018 (UTC)

Agreed, these are not proper names in the OSM sense. I will fix it. --RobHubi (talk) 16:52, 8 February 2024 (UTC)

Please note that «Recharge Vigra» in the first example was in fact the proper name, as used by the operator, customers, in listings etc. NKA (talk) 18:20, 8 February 2024 (UTC)

Brand + place is a group name, not a proper name. There are several charging stations there. Descriptive names in public lists of charging stations are initially only descriptions. More is needed for them to become proper names. --RobHubi (talk) 19:30, 8 February 2024 (UTC)

Charging Point Reference Number

Is there any interest to add a 'ref' tag to each charging station ? I suppose every station have its own reference number, but I don't find any normalized specifications. For instance, in France, every Mobive station have this kind of number : FR-S47-E47049-001-1. Is there something similar for other companies or/and country ? Have you any information to share about it ?

If each station have effectively a normalized reference number, and if also seems relevant to you to add it in OSM, the main question will be: how to tag it ? The problem is, for what I know, that the reference number (as the one above) doesn't concern charging stations but charging points. It means that for a two-point charging station, there are two references.

For a solution, I see three different options :

  1. add on the map as many charging stations as charging points, in order to get one reference per charging point. This solution seems really difficult, as it means remap all the existing charging points ! Say we drop this one.
  2. create a special reference type, in order to be able to add several references for each charging point, for instance: 'ref:chargingpoint:1', 'ref:chargingpoint:2'...
  3. make a charging station reference by ourself, based on charging points references, in removing the last digit (which seems dedicaced to each charging point). With the previous example, it would give : FR-S47-E47049-001.

For my part, I prefer the solution #3, which is the least labour intensive solution, and which will probably fit with normalized specifications (if they exists).

Any answer ? Any comment ?

--Archi02 (talk) 11 May 2018 (UTC)

I'm from Germany, I also stumbled over this problem. At first here are some random samples from germany:

Regrading your suggestions:

  1. I don't like this for two reasons, first i don't know any station tagged like this, so we had to change a lot, second I think a node should represent the physical charging station, so:
    • a station has two plugs => one node
    • there are two stations with multiple plugs => two nodes
  2. Interesting, because maybe it's helpful to know which ref is related to which socket e.g. socket:<type>:ref=BA-1102-3 but if there are two plugs from same type this will not help.
  3. I think this will lead to problems if you want to use the ref for referencing the station somewhere because the ref we created does not exists in other databases (like in a short message to unlock the station). And not all refs are consecutive or have an dash as separator (see examples)

My suggestion: Use the ref tag and if there are multiple refs split them with a semicolon as it is described in Multiple_values

--Nickel715 (talk) 16:24, 13 May 2018 (UTC)

I like your suggestion as it seems both the easiest and the fastest way to resolve this issue. But I wonder if it's a proper one: for what I know, we're really supposed to avoid multiple values. On the other hand, it's true that it's hard to make a tag convention (inspired by the solution #2, for instance) if we are only two to discuss. So, if nobody else join us, I'll proceed like you.

If we keep your suggestion, it would seem good to add a little note on the documentation page, wouldn't it ?

--Archi02 (talk) 07:07, 14 May 2018 (UTC)

Sounds great! Can you add the note to the documentation page? I can provide a german translation.

--Nickel715 (talk) 20:46, 13 June 2018 (UTC)

All of this is related to eMi³ standard and defines which format these identifiers should follow. I propose to adopt dedicated ref:EU:EVSE=* to document those specific rules at continent scale Fanfouer (talk) 23:39, 17 January 2020 (UTC)

Vehicles

In the Vehicle section there's the value scooter.
Don't know if it's relevant at all (as the power output should be more important),
but a scooter is a type of motorcycle, so this usual key should be preferred ?

Definetly yes !
car=* should be dropped too and moved to motorcar=* please Fanfouer (talk) 22:53, 8 January 2020 (UTC)
yes, definitely Singing-Poppy (talk) 13:16, 18 January 2020 (UTC)
Definitely it shouldn't suggest scooter=*, although I think the existing tags moped=* and/or mofa=* are more appropriate here than motorcycle=* Famlam (talk) 12:47, 27 February 2021 (UTC)

Charging robots

Any recommendation how to tag charging robots? --Lulu-Ann (talk) 15:17, 10 January 2019 (UTC)

Is this a device or a place ?

It should be stated clearly what does this value represent: a site or a device?
A fuel station can have several pumps with different capabilities. Should we put a node on each device in the charging place (and remove like gas stations in the page) or this value corresponds to the whole place? Fanfouer (talk) 21:34, 8 January 2020 (UTC)

A few months ago, a supermarket near me installed free charging points. There are two devices a couple of metres apart. Each of those devices has two charging connectors. Four cars can charge simultaneously. Is this one, two or four stations? I've mapped it as two stations because each has its own name and is identified in the phone app as such (you can find out before you go how many cars are currently using it) or via a web interface. Given the way their web/app interface identifies charging connectors (Kent-Ewan A and Kent-Ewan B) my vote is for devices. Brian de Ford (talk) 15:31, 18 January 2020 (UTC)
I really hope that it is for a place. If it is equivalent of tagging every pump separately then we need a new tag for the entire equivalent of amenity=fuel Mateusz Konieczny (talk) 15:23, 18 January 2020 (UTC)
Several parts of the current page strongly imply that this is for a whole set of charging plugs:
1) "Like gas stations" - as mentioned
2) "number of vehicles that can be charged at the same time" - more than one device is assumed
3) "capacity=* The number of vehicles which can be charged at the same time. The total number of sockets can be higher." - again, more than 1 vehicle
4) "socket:<type>=number - number of this socket type" - more than one socket.
Overally it seems clear that one amenity=charging_station can include several parking spaces and several charging devices. --Jeisenbe (talk) 05:49, 19 January 2020 (UTC)
It is equally clear to me the page is discussing devices. "Number of vehicles that can be charged at the same time" applies equally to devices with more than one socket. "Total number of sockets can be higher" can apply to a device with more than one type of connector, but only one of those types can be used at a time (see example on page for eins energie which has two type2 connectors, two schuko connectors and a total capacity of 2 vehicles). "Number of this socket type" many charging stations have two Chademo connectors, which can be used simultaneously. --Brian de Ford (talk) 12:16, 19 January 2020 (UTC)
We have to consider a third level corresponding to the actual station we talk about : a pool. Some standards as the eMI3 in Europe describe things as follow:
  • A pool : the place including several chaging devices (our station)
  • A station : a charging device with one several sockets (our device)
  • An equipment (actual EVSE) : a socket (or a group of sockets) allowing to charge one individual vehicle at the same time
Our problem is amenity=charging_station can be a pool or a station depending on situations but it shouldn't imho. Fanfouer (talk) 13:12, 25 January 2020 (UTC)
For me, it's a station with capacity for 1,2,4 cars.
--Pyrog (talk) 17:57, 15 March 2020 (UTC)
According to practices, amenity=charging_station is mostly used on nodes, then for devices (even with one socket, the place includes the space required to park vehicule while charging). Then we miss a tag (amenity=charging_pool) to include devices + parking space. Fanfouer (talk) 13:38, 25 January 2020 (UTC)
But 2/3rds of amenity=fuel (gas / petrol stations) are also mapped as nodes. Many moderately-large features are appropriately mapped as a node. I would suggest rather creating a new tag for individual devices, if someone wants to map with that level of detail, and allowing amenity=charging_station to be used for a pool, since current it is also sometimes used for this and it is unlikely will would be able to change that. --Jeisenbe (talk) 15:06, 25 January 2020 (UTC)
Our problem isn't to extend a key to an additional use case but to choose between a pool, a station or a socket for its definition. Using amenity=charging_station for more than one sort of feature makes it unusable both to contribute and to consume. If it's a pool, it can't be a device or a socket in the same time. Fanfouer (talk) 15:42, 25 January 2020 (UTC)
The filling station analogy is a bad one for three reasons. Fuel pumps are clustered together because the tanks are in one place and, often, the forecourt is small anyway. Charging stations in a car park do not have to be clustered together, they could be distributed around a large car park (there are arguments for and against that arrangement). More important is the time taken to fill the vehicle: a few minutes for petrol and an hour or more for an electric vehicle. Most important is that more than one type of device may exist in a car park. The Tesco supermarket chain is installing charging points: one type has two 7kW sockets and is free; the other type has a 50kW socket and is not free (I did see something on their site saying that the 50kW device would deliver 7kW for 30 minutes for free, but can no longer find it). Smaller Tescos are only getting the 7kW units, the larger ones may get a mix of the two types. --Brian de Ford (talk) 16:00, 25 January 2020 (UTC)
Re: "Charging stations in a car park do not have to be clustered together, they could be distributed around a large car park" - in that case it would be fine to map them as separate stations, no? Similarly, it's common to find 2, 3 or even 4 amenity=fuel stations at the same intersection, one on each corner, in the USA. Re: "more than one type of device may exist in a car park." - fuel stations often offer diesel, petrol, ethanol etc. - and the pumps for large HGVs (trucks) are located at a separate location from the pumps for cars, at large "truck stops" along the motorways in America, but these are usually mapped as a single amenity=fuel. One station I know in California offered biodiesel, regular diesel, several octane levels of gasoline (petrol), ethanol in various concentrations, kerosene, butane and something else too. --Jeisenbe (talk) 12:19, 26 January 2020 (UTC)
Similarly to large wind farms, pumps/charging devices can be linked under a single type=site relation for the sation even if spread around a large car park. Does the example you took around intersections in USA involve several operators or not? If not it would be preferable to group pumps in the same site relation (or multipolygon if composed of fenced perimters) around the intersection. As said, if pumps dedicated to large HGVs and regular cars are located in different locations for the same fuel station mapped as node, routing directions won't be accurate or even inconsistent. Fanfouer (talk) 00:53, 27 January 2020 (UTC)
Site relations are nearly useless for processing, avoiding them is very desirable Mateusz Konieczny (talk) 08:05, 28 January 2020 (UTC)
Site relations are first of all useful to maintain 1:1 links with external files (open data mainly) for distributed facilities that can't be mapped with nodes or polygons. Then they are used in QA processes, some renders (OpenInfraMap) or urban planning studies. Feel free to propose a better way to describe things like relation 7947863 or a single charging facility distributed around a car park. Fanfouer (talk) 09:26, 28 January 2020 (UTC)
As an EV owner who is very active in the EV community both in real life and online, I have never heard, read or used the term "charging pool" before. I don't think it is practical to tag every charging device separately. Most charging stations with multiple charging units include a number of devices of the same hardware. There is probably scope for multiple tags where there are multi-charge network operations at the same site (e.g. a Tesla supercharger next to a public DC fast charger.) -- Chuq (talk) 07:33, 31 January 2020 (UTC)
In my country, electric vehicles now represents 80% of total new cars sold each year, and charging stations are found everywhere. The charging stations are for the most part branded and the sites are very similar to a fuel station which we map with the amenity=fuel tag, either on a node or on an area (example). Each operator brand (Tesla, Fortum etc) are mapped separately. I have understood the wiki to refer to a charging site, rather than to charging point/outlet, and this is how we have mapped a few thousand sites. In the same way as fuel pumps are not mapped for amenity=fuel, the individual charging points/outlets are not mapped for amenity=charging_station. The station/site interpretation has the advantage that maps will show the station only once, for example "Fortum Bergen", applications will show it only on one line in searches, and it will be possible to query and see the total capcity (number of simultaneous users) and selection of socket types across the station.--NKA (talk) 13:36, 12 March 2023 (UTC)
I agree with you on the principle that amenity=fuel is equivalent to car charging site but a station is contained in a charging site (officially a pool). amenity=charging_station should be used on every station. See definitions on eMI3 standard specification (particularly EVSE chargin station p17, EVSE pool p 19 and EVSE p 18). Fanfouer (talk) 17:33, 12 March 2023 (UTC)
I disagree with the use of this definition. There is power=outlet for sockets. Multiple sockets at the same location will not realistically be added as multiple points. In fact amenity=fuel hasn't solve the issue of fuel pumps either.
People have asked about public power points at parks and outdoors. They have some resemblance to chargers.
--- Kovposch (talk) 04:54, 13 March 2023 (UTC)
Fanfouer: That document is just adding to the confusion due to a different nomenclature. amenity=charging_station is the tag we have in OSM, inherited from amenity=fuel, and we need to get to an agreement in OSM on what it makes sense for this main charging tag to signify - a collection of chargers (site) or an individual physical device.
You're missing that an EVSE is not equivalent to a socket but a group of socket (possibly composed of a single socket). power=outlet will be useful to document each socket of an actual EVSE, just like you can get wether gasoline or unleaded petrol but not at the same time on a given pump.
The eMI3 document is providing a reliable nomenclature, more robust than OSM in this particular case. We are at risk to be unable to make data comming from different data sources matching with OSM. I don't agree that amenity=charging_station is equivalent to amenity=fuel, even in practice we map each terminal just like they were fuel pumps. We need to understand a station is not a site. Fanfouer (talk) 08:55, 13 March 2023 (UTC)
I opened up the discussion for a wider audience in the forum
https://community.openstreetmap.org/t/charging-stations-sites-or-individual-chargers/96810/1 Hedaja (talk) 18:46, 12 March 2023 (UTC)
Sorry but I don't agree here.
At least in Germany and other European countries and the US as I see the tag being used in both forms. For a collection of charge points (site) and for individual chargers.
I don't think it's helpful just editing the wiki here without clarifying things first. Especially since since ALL the examples on the page show an individual charger and not a whole charging site.
At them moment we don't have a tagging scheme that clearly helps distinguish between those things. So we will need to find a way to distinguish them first. I know enough charging sites that have very different chargers installed, with varying outputs and varying plugs and different refs. We therefore definitely need a representation of chargers on an individual level.
Bu I wholeheartedly agree that calling it a station and using it for an individual charger is not good. Before changing the Wiki to completely falsify a big part of the way the tag is used currently, we need to come up with an alternative tagging and document it. Something that man_made=vehicle_charger (as equivalent for man_made=fuel_pump). I'll open up a topic in the community forum so we can reach a wider audience. Hedaja (talk) 18:03, 12 March 2023 (UTC)
Almost ok and beware with Bu I wholeheartedly agree that calling it a station and using it for an individual charger is not good: please consider the EVSE charging station definition p17 here eMI3 standard specification. A station is not a site. Fanfouer (talk) 18:14, 12 March 2023 (UTC)
Of course you are right. Unfortunately common language use for this is difficult in in English as well as in German. I usually here people talk about a 'charging station' for the site and a 'charger' for the individual devices. But people also sometimes use station for the device. Same in German Ladestation[charging station(charging park)] sometimes gets used for either as well. Ladepark (charging park) and Ladesäule (charging culumn) for devices would be more clear. Hedaja (talk) 18:33, 12 March 2023 (UTC)
It worthes the effort to match natural langage as often as possible and sometimes it could bring more mess than benefits. We have the same in French regarding fuel: we use to say "Let's go to the pump" which refers to the fuel station actually. We'd better look at standards to find a shared solution between OSM and third parties, it will ease data sharing. Fanfouer (talk) 18:53, 12 March 2023 (UTC)

Use For Home Charging Points

Finally housing developers in my area are starting to fit EVCPs to their newbuilds, either adjacent to the driveway or in the garage if the house comes with one. When doing a "complete" mapping of features it would be useful to indicate the EVCP along with other features like entrances, indoor features and whathaveyou that exists in the OSM building mapping schemes.

Is this tag suitable? I was hoping for a "charging_point=yes"/"charging_point:type=motorcar;motorcycle" type tag combination to use on the building outline but a Wiki search drew a blank. This tag would be presumably be appropriate where the actual socket position was known, along with "access=private" and "location=indoor/outdoor...?" --John Grubb (talk) 19:28, 3 March 2020 (UTC)

I would not map ones used solely by owner of the house (like we are not mapping toilet in a private house). I would consider mapping ones shared among multiple households Mateusz Konieczny (talk) 20:59, 3 March 2020 (UTC)

tagging disabled charger?

Can't find proper way to tag/flag broken/dead/disabled/damaged/out-of-service charger. Found one that's been busted for 4 months now (hit by snowplow, I was told.) Don't know if it'll be repaired/replaced or removed. DougGrinbergs (talk) 06:32, 30 March 2020 (UTC)

I Would use the standard lifecycle prefix ("disused" for example) on the amenity=charging_station if all the station is disabled/unusable/...

For 1 charger among multiple ones (on the same station), we can temporary reduce the number of socket available and put a note/fixme with the information that xx socket are disabled/damaged/... and awaiting repair. And maybe use a lifecycle prefix on the socket tag like for example : "socket:type2=2", "disused:socket:type2=1" (or "destroyed:socket:type2=1") to indicate that 2 are available and 1 is not. --Anakil (talk) 07:59, 30 March 2020 (UTC)

The standard or mapping battery swapping station

As i've noticed that 3 years ago there was a topic asking about battery charging station. As of now, Taiwan has that 1,500 scooter's battery swapping stations operated by Gogoro Network. I can't find that how to map these features correctly in OSM. Could anyone complete the contents or draft a proposal for mapping that? Tntchn (talk) 05:33, 14 April 2020 (UTC)

You can do this yourself, if you have the time. Try signing up for the Tagging mailing list and ask about it (https://lists.openstreetmap.org/listinfo/tagging), or make a proposal (see Proposal_process). Or you can just pick a tag and start using it: maybe amenity=battery_swap or something like that? --Jeisenbe (talk) 06:05, 14 April 2020 (UTC)

Fall 2022: sorry to see there seems to be no tr/action in the battery swap tagging department. (:-( Alas, wiki search for "EV battery swap" doesn't find anything useful.

Seems battery swap stations mostly in Asia, but slowly heading to Europe; Gogoro continues to expand e-scooter stations, with NIO and SAIC/CATL working on auto battery swap stations. Combined, thousands of stations to map. Wondering if battery swap operators could be convinced to contribute their map location data to OSM. DougGrinbergs (talk) 07:56, 2 October 2022 (UTC)

Was discussed this year https://www.reddit.com/r/openstreetmap/comments/utom73/ebikes_charging_station_battery_swap_or_not/ --- Kovposch (talk) 09:13, 2 October 2022 (UTC)

Vehicle access tag : should we use a more general tag by default (like access=yes) ?  

I see a lot of charging station mapped with just "motorcar=yes", but i never saw a sign on these that would forbid any other type of vehicle to use the charging station. I would assume that anyone with a matching socket can charge at a charging station, except if explicitly forbidden ?! In my experience, the only case where there is such sign is for motorbike and bicycle chargers, and so these one would be the only one where tagging motorcar=no, truck=no,... All other places should be accessible for everyone : so should we map motorcar=yes, truck=yes, motorbike=yes, bicycle=yes, scooter=yes... or just use access=yes instead ? Most modern vehicle use the same few standard of sockets (either Type2 for slow charging (bicycle, car, motorbike,...) or CCS for fast charging (or Chademo in Asia)) and we see things like motorbike starting to get CCS plug, EV trucks too, so i think it is time to question the tagging of vehicle access on charging station. --Anakil (talk) 08:43, 20 October 2020 (UTC)

I would rather propose two new values:
1. access=electric_vehicle, if the collocated sparking space is only for electric vehicles (usually the case, but not always), but can be used by these even if they are not charged, and
2. access=charging, if access is only allowed during charging and the vehicle has to be removed after that. -- DerGuteMercator (talk) 16:22, 6 August 2021 (UTC)
  1. That's a mode, not a restriction.
  2. There's 21 maxstay=charging instances, similar to maxstay=load-unload
---- Kovposch (talk) 06:59, 7 August 2021 (UTC)
maxstay=charging is a good idea, thanks! How could we make this official?
For the electric vehicle thing, I found that there is already a discussion going on elsewhere: https://wiki.openstreetmap.org/wiki/Talk:Key:access#electric_vehicles -- DerGuteMercator (talk) 16:45, 10 August 2021 (UTC)
Yeah, I posted some follow-up comments there. Now I can see some problems with maxstay=* (and possibly a minstay=*) as "approved", that could be updated (the proposals is quite old from 2008):
  1. You aren't supposed to use multiple units (duration=* uses HH:mm, and interval=* uses a mix with m and mm)
  2. All of these are not in ISO 8601 time period format (P1Y2M3DT4H5M6S), unlike start_date=* complying with the standard YYYY-MM-DD.
  3. Actually since Key:maxstay#Tagging now mentions maxstay:conditional=*, it would be better to change maxstay=charging and maxstay=load-unload (there are "only" 223 instances) to conditions, so that you can cover anything from maxstay:conditional=ASAP @ (charging) (an new common value as an example) to maxstay:conditional=unlimited @ (delivery), including different durations. There's a way 878664257 in Lunen near Dortmund using maxstay:conditional=4 hours @ charging. Elsewhere, there are 20 access:conditional=yes @ charging, and 6 parking:condition:*=charging instances (parking:lane=* was also called on to be updated to parking:lane:conditional=*)
More details at taginfo
More details at taginfo
More details at taginfo
More details at taginfo
More details at taginfo
---- Kovposch (talk) 18:29, 10 August 2021 (UTC)

Multiple CCS chargers with various output on the same station ?  

I start seeing more and more charging stations with multiple CCS stalls but with various output power, like for example : a lot of Ionity station, there are 4 x 350 kW charger and 1 x 50 kW tri-standard charger (1 CCS, 1 Chademo both at 50kW and 1 type2 at 43 kW). At the moment, the only way to tag both is to make two separate node with the 4 x 350 kW CCS charger on one and the other charger on a separate node (as we can't differentiate them otherwise for the plug that's used on the various charger but at different output power). I give the example of the Ionity station of Tignée in Belgium (near Liège) :

Do you have an idea how to solve this in the tagging and show both on the same node ? :-) --Anakil (talk) 13:08, 23 November 2020 (UTC)

Just for clarification: Ionity is CCS-only in almost all countries, but France demands that Chademo (used by old Peugeout Ion and Citroen C-Zero) and AC (Renault Zoe) is offered, too.--MattGPS (talk) 20:17, 2 June 2025 (UTC)
I encountered the same problem, and with the current tagging scheme, I also have no better idea than to add two nodes. But ideally I think this should be modelled as a relation. I.e. one node with the entire facility and its properties (operator and so on), and then one node for each combination of socket/output/power that are related to the facility node. -- DerGuteMercator (talk) 12:25, 21 June 2021 (UTC)
Could we adopt something like socket:type1:output:350_kW=2 + socket:type1:output:150_kW=4? Invidious (talk) 17:55, 5 January 2022 (UTC)
I have the same problem. I can see the logic in your suggestion, User:Invidious, but would it be easily machine-readable? If machines are looking for the outputs, they will have to look for as many keys as there are outputs.
I can't see a good alternative, unless we're allowed to comma the value? charging_station:output=7 kW,3 kW. At least that would throw an error in the machine reading and prompt someone to parse the comma if necessary. eteb3 (talk) 05:58, 10 August 2023 (UTC)
After the recent approved proposal, tag the maximum output on the amenity=charging_station (350kW in your example). If you want to have detailed information about the various stalls then also add a man_made=charge_point node for each stall, each with the output of the stall.--NKA (talk) 06:13, 10 August 2023 (UTC)

Amperage and voltage tags

  1. The infobox has amperage=* + voltage=*
  2. The article body has socket:<type>:current=* + socket:<type>:voltage=*

Lack of indication that scheme 1 is only for backwards compatibility (or instead, is allowed for new POIs) is confusing to data reusers/renderer applications and to new mappers.

Scheme 1 was striked over in [1] and deleted in [2]. taginfo says scheme 2 clearly dominates for the most common socket types.

I assume the deletion was meant to deprecate and I will adapt the article and the infobox accordingly. If that is wrong, please have the article say explicitly whether scheme 1 is encouraged or instead is an old relic.

Cc User:WayneSchlegel, User:Mxdanger, anyone else? --Pippo6 (talk) 09:43, 19 June 2021 (UTC)

on areas?

Any good reason why according to the info box, the tag should not be set on an area?

Many/most charging station reserve the parking space in front for charging cars, so it cannot be used otherwise. Also, larger charging stations exist that may have the size of a small parking lot / gas station. For both these situations, it may make sense to map the area reserved for car charging as an area. --Westnordost (talk) 23:41, 7 July 2021 (UTC)

-- I agree. -- DerGuteMercator (talk) 06:53, 8 July 2021 (UTC)

Changed to allow areas Mateusz Konieczny (talk) 10:01, 23 July 2021 (UTC)
Link to mentioned change: https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dcharging_station&diff=2178547&oldid=2176802 --Das-g (talk) 14:35, 14 July 2022 (UTC)

OpenStreetBrowser charger search?

Who knows how to *search* OpenStreetBrowser website for chargers? OSB and OSM maps display existing chargers but unclear how to search and highlight points (as in overpass turbo display - not user-friendly UI for general public!). DougGrinbergs (talk) 21:36, 10 October 2021 (UTC)

I don't think it's possible right now, as zooming in doesn't display it at all right now. Probably open a GitHub issue for them. Zyphlar (talk) 05:11, 11 October 2021 (UTC)

trucks

How one may distinguish whether given charging station is for cars or for cars and trucks?

Is it about vehicles such as https://en.wikipedia.org/wiki/File:Actros182201.jpg (as indicated by `hgv` tag) ? Are there any such vehicles in operation which are powered by electricity?

Mateusz Konieczny (talk) 11:23, 3 May 2022 (UTC)

I think this is mainly about the available parking space, most charging stations will not have sufficient space to park a truck. See this (German) blogpost for an example of a charging station that can be used by trucks: https://www.goingelectric.de/2021/03/11/news/oftringen-ost-hpc-elektro-lkw-elektroautos/ The charging ports / standards on the other hand are the same as for regular electric cars. --DaniloB (talk) 19:19, 3 May 2022 (UTC)
That would generally be interesting in order to know if you can park there with a trailer! Actually I am missing a tag like this. David Hubert (talk) 15:20, 6 March 2024 (UTC)

"capacity"

This is very misleading, should be changed to "number of stalls" or "number of cables". The most important info for those with modern EVs is power, like 300 kW, some cars can take more. And last, "capacity" might be used for battery powered chargers, which already exist.--MattGPS (talk) 20:10, 2 June 2025 (UTC)

There seems to be a misunderstanding: "capacity" is the number of users that can charge concurrently. That's the same definition the 'capacity' tag has in any other combination of tags outside of charging infrastructure. It's neither the number of cables or sockets nor the number of marked parking spots. Each of these have their own tags. --Mueschel (talk) 20:35, 2 June 2025 (UTC)

DC or AC?

OSM has to distinguish between fast charging DCFC HPC supercharger charging sites, that are equivalent to gas stations, done in under 30 minutes, and the more numerous slow AC charging places, eg. on car parks, near railway stations, companies, appartements, where the EV stands for hours. --MattGPS (talk) 20:14, 2 June 2025 (UTC)

This information is already available. AC/DC is not the relevant piece of information - that's just the underlying technology. The important part is the type of connector (most are inherently either AC or DC) and the available output. Both are tagged using socket:*=* and socket:*:output=*. --Mueschel (talk) 20:35, 2 June 2025 (UTC)

Vehicle Information

Hello, today's edit of the vehicle section I have reverted for several reasons. Let's discuss here before adding back to the page. Here are my concerns:

  • It is a duplication of information already in this page as well as on the vehicle page. Vehicles are a type of access, and this is highlighted in the box on the access row of suggested tags. The charging station as it is used in OSM refers largely to EV charging, not other charging, so a mention to `motorcar=no` as a possibility since `yes` is implied may be in order.
  • The list provides nothing specific for charging stations, only replacing generic terms with "charging" from the vehicle page. If someone wants a comprehensive list of vehicle tags, they should refer to that page, not this selected few.
  • It muddies the definition of some values. Such as "electric cars can be charged only if you're a customer of that place (e.g. for so signed charging station on restaurant's parking lot)" for motorcar=designated when in reality and in use, customer can refer to what is said here in addition to customers of a particular brand (such as Tesla-only superchargers). This, again, was stated clearly already in the article in the access section. There is no need to repeat it later on in my opinion.
  • "access=private - only vehicles belonging to persons having explicit permission from the owner may charge here. Specific type of such (possibly allowed) vehicles is not known/specified." You can absolutely know the socket and other information on a private charging station. Some of these are quite large, some of which are even publicly available in databases but simply are not open to the public. Workplace chargers are famous for this. I am not sure where you got this definition from but it should not be assumed. Again, the rest can be seen on the access row or the access page.

I don't see the value in muddying the wiki with duplicate (partial) information. Other wikis do not partially duplicate tangental information even if directly referenced. Wikipedia does not go into a brief history of the country if someone is from there, they link the country and if the reader wants to know more they can follow that. For OSM, some tags are used certain ways on certain elements, such as those in the tagging section table. Where it would otherwise be a duplicate, we should instead link to the page and let the reader follow the links around. Is there a piece of information specific to EV chargers not already present on the access or vehicle pages that we should add? Im open to improvements. --GA Kevin (talk) 20:33, 7 July 2025 (UTC)

Then instead of deleting the entire section, we should focus on fixing these issues. I believe we can find a reasonable middle ground here in what should stay but removing it entirely makes no sence as now there is no mention that this tag is used by non car charging stations, and zero examples on how todo so. The wiki page should clearly inform the reader what this tag is used for and I doubt anyone reading it in its current state would reasonably assume that it can also be used for example for bikes. This is highly autonomative.--Wombatmaper (talk) 20:59, 7 July 2025 (UTC)
Also: removing the hgv=yes section removes an important tip that the key deciding factor if an hgv can use this station if about the parking lot size, not the charger.--Wombatmaper (talk) 21:09, 7 July 2025 (UTC)
How do we feel about instead of an entire section (giving in my opinion too much weight to this) we do the following:
  1. Update the first sentence to read "EV charging stations are places designated for the use by EVs, such as motorcars and bicycles, for the charging of their battery."
  2. Update the banner in the access row of the table to read "Please refer to the access page for more options. Refer to vehicles if access is not designated for motorcars."
  3. Add to the parking space page: "For HGV, consider access to the space as well as if the space itself can accommodate a HGV."
I will update the examples, there are tags it's just wiki formatting the gallery strangely. Thanks for pointing that out --GA Kevin (talk) 23:44, 7 July 2025 (UTC)
Good idea, I agree that the section is to heavily weighed with the restructure. Two things I would change though:
"EV charging stations are places designated for the use by EVs, such as electric motorcars, trucks and bicycles, for the charging of their battery." To make it clear it's about EVs and also include trucks since they are probably the second most common one after cars?
Instead of adding the access hint to the banner, could we add it to the tags table? Maybe in the "optional" section similar to how the socket:<type>:... information is presented? I just feels like the current hint in the "access" section is to easy to miss or misinterpret for newbies who might not know that access is also referring to physical capabilities in this case. It feels like the socket section also has some information that could be found elsewhere (on the socket) page but is still better repeated here for ease of use, and thus a good example.--Wombatmaper (talk) 00:38, 8 July 2025 (UTC)
  1. Agreed.
  2. How is this for an alternate row and update the message box to just be access then:
Key Status Type Description
vehicle=* Optional Value value Charging Stations imply motorcar=yes, if not please specify with motorcar=no and vehicle values for appropriate access.
--GA Kevin (talk) 17:31, 8 July 2025 (UTC)
Good suggestion, sounds good to me.

operator/brand/network

amenity=charging_station combinations gives:

  • operator 69.4%
  • name 31.6%
  • brand 28.6%
  • network 16.6%

So I think we should update the Wiki to move operator to Suggested Tags and brand to Optional Tags and maybe removed the network tag from the Wiki page. See also the forum discussion -- Emvee (talk) 10:29, 27 July 2025 (UTC)

Hi Emvee! Thanks for this! The forum post linked is mainly surrounding the network key, not the brand or operator keys. That said, that is another topic that has been bubbling up lately. It sounds like there's fairly good consensus on striking network from the list, but brand and operator are often times the same. There's also the ongoing issue OSM-wide but particularly in charging stations of "legal names" (i.e. "Tesla, Inc.") versus "trade names" (i.e. "Tesla"). I believe for ease of mapping and verifiability on the ground vs in the boardroom, charging stations should use the trade name. With all this in mind, may I suggest the following:
Key Status Type Description
brand=*
operator=*		 Suggested Value value The verifiable brand displayed on the station or charge points. If no brand is present, or the brand and operator are different, operator may be used using the trade name of the business. In either case, consider adding *:wikidata where possible.
-- GA Kevin (talk) 12:54, 27 July 2025 (UTC)

Today's Revisions to the main page

Hi @RobJN! Glad to see you around as always! I didn't want to start an edit war so I am opting for here on the talk page instead. Most of today's edits are very welcome and I can see where you are coming from, particularly:
1. Moving the socket:type:current and socket:type:voltage to optional, I agree that's where they should live!
2. Adding kW as a unit, I saw the discussion on the forum. While I am no longer on the forum, I did see socket was updated to request units but imply kW when not present. This seems like a good middle-ground and charging stations should reflect that.
3. Updating the example, I even went all the way to [REDACTED] street view to this station and kinda threw my hands up on that example. It's a good photo, just hard to get the full info on as I am not in coastal Norway. The section could probably stand to be modernized even more. You know as well as I do that EV infrastructure moves quick.

Some things I have questions about:
1. You removed the When a relation relation is not appropriate section. Perhaps we can add it back but with better wording? My concern was that people would see something like a Supercharger with V2 and V4 posts (visually distinct) and then tag it as 2 stations, hence why it mentioned model of dispenser. This is in agreement with When a relation relation is appropriate which deals mainly with brands that are disconnected (like when there's some on either end of a parking lot.)

I see what you mean now. How about after "This should not be done if the stations are distinct but share a close proximity (such as two brands in a since parking lot.)" we add: "Also do not create a relation to segment adjacent groups of different chargers (e.g. by model our output) - a relation is only required if they are dispersed across an area. --RobJN (talk) 16:40, 14 September 2025 (UTC)
  • I support this proposal. I think that will keep the spirit of the addition quite well. --GA Kevin (talk) 18:15, 14 September 2025 (UTC)

2. Capacity now seems quite long and introduces doubt (and maybe even a twinge of discouraged) by mentioning the usage by data consumers. I am unsure why the (now previous) concise wording of "The total amount of BEVs that can charge concurrently regardless of the quantity of connectors present or in-use." is inadequate. The reason I wrote it as clear and concise as possible is to not overwhelm a new mapper. They can look at the section, see there's a few suggested tags and where to find them, and move along. I am unsure adding data user adoption to the tagging table is the best location. Maybe we can have a section with "how data consumers use the data"? or similar.

While I also support being as concise as possible, I just don't see any way to keep it shorter here. When I looked at how people were using the tag it was very inconsistent (and therefore somewhat useless as it wasn't possible to know how to interpret it). Hence I added more to this description several months ago. Any ideas yourself? --RobJN (talk) 16:40, 14 September 2025 (UTC)
"The total amount of BEVs that can charge concurrently regardless of the quantity of connectors present or in-use." is what I would recommend but I realize that is one of those "should we document how it should be done or all the ways it is" scenarios so if you feel strongly we should keep the longer definition at the expense of brevity. --GA Kevin (talk) 18:16, 14 September 2025 (UTC)

Some concerns I have that I would like to revert or edit:
1. Frequency. You removed it when it is a well-established way to distinguish if a station is AC or DC. This information is super valuable if no precise socket:type:output is given, as AC charging is much slower than even a mediocre DCFC. We need to add this back. If your concern is multiple values, this is already used with semi-colon value separator at least in the United States. It is not uncommon to see a station with frequency=0;60. I have one in town, I would be happy to add that as an example, I just have to dig up a photo of it.

Ah I see. So you are using this tag for when people cannot / are too lazy to add the socket info. Although they will need to know the sockets in order to work it out (perhaps with the exception of some data imports). How about putting it in the optional section as the preference is to have socket info (hence sockets remain the "suggested" method), with a note that this is particularly useful if sockets are not tagged? Out of interest, if sockets are tagged, do you think this frequency tag is still needed? (I don't). --RobJN (talk) 16:40, 14 September 2025 (UTC)
It serves as a quick easy filter for fast vs. slow even if output is also present so I don't see the need to advise removing it upon more detail. For instance I can query if frequency=0 if so, its a DCFC, if any other value its a slower AC. Versus trying to parse the socket tag, with output if available, and common mistakes. I think it is very important to know approximately how fast a station is so I added it to suggested, but that's just one opinion, and a US-centric one at that. So long as it's included somewhere I will be happy. --GA Kevin (talk) 18:20, 14 September 2025 (UTC)

2. The note on semi-colon value separator in the socket row. Firstly, I don't think your example is correct (states 6 CCS when previously it was 9) but anywho, this seems like an imprecise way to try and tag a charge point in the charging station element. I get what you're after, reading left to right, the socket type and output should match. Not all countries read left to right, which is fine we prefer british English when possible, but also this is just not reasonable to expect on a charging station element. I support semi-colon value separator in the socket key, of course, it's just the implication that it's in a particular order I have concerns with.

I'm not sure I follow this at all. Where does it say "previously 9"? It says 9 in total made up of 6 x 350kW and 3 x 90kW. It also reads correct both left to right and right to left so I do not follow that concern either. I agree that, if the mapper can, then the info is also worth adding to the charge point but if you don't map this detail, or just want a sumamry of what is available on the who station, then this seems like the best way to do it to me. --RobJN (talk) 16:40, 14 September 2025 (UTC)
To be honest, on a second read-through I am not sure I understand my former self here either. I'd still prefer a simple "for multiple values, use semi-colon value separator" but see previous response on the strength of that. --GA Kevin (talk) 18:21, 14 September 2025 (UTC)

3. Examples have been added to the tagging section, they should be in the examples section to simplify the tagging table and better organize the page.

As above, I'm all for keeping things short, but it does need to fully convey the key information. A short example is often a good way to do this. Moving it elsewhere on the page just makes it harder for the reader as they have to collect the info from across the page and piece it back together again. --RobJN (talk) 16:40, 14 September 2025 (UTC)
Maybe we can link an example with a photo and proper tagging? Would keep the table precise and page organized without the reader needing to make assumptions on where the example applies. Thoughts? --GA Kevin (talk) 18:22, 14 September 2025 (UTC)

Let me know what you think, I am looking forward to it! All the best. --GA Kevin (talk) 11:54, 14 September 2025 (UTC)


See comments in line above. I forgot one more edit earlier; namely to remove the suggestion that the correct relation type is "site". This edit was made without discussion and is not one I agree with. I researched what people were using some months ago and it is a mix of site and multipolygon. Suggest we just leave it ambiguous on this page for now. --RobJN (talk) 16:44, 14 September 2025 (UTC)
I see site as disconnected but related elements, the primary example being a windmill farm. I see multipologons as a "donut" shaped building such as those with a courtyard. I am not sure that would apply to a charging station. EV charging station relations are pretty rare in my part of the world so I am pretty sure we can just discuss here and whatever we agree on is the "consensus" moving forward. --GA Kevin (talk) 18:25, 14 September 2025 (UTC)

OCPI term?

@Marc marc: can you clarify what you meant by "OCPI term: location" in this change ? It is very confusing to me. Perhaps add e.g. WikiIcon template for "OCPI" linking to Wikipedia (so people have an idea what it is talking about) and expand the wording to be more understandable; e.g. "(in OCPI terminology, they are called `Charging locations`)" (if that was the intention, of course) --mnalis (talk) 15:01, 6 December 2025 (UTC)

OCPI = Open Charge Point Interface, one industry standard on this subject
The phrase ‘in OCPI terminology, they are called “Charging locations”’ sums up what I wanted to say, but I wanted to do so in a shorter form.
However, if the shorter form is less understandable, I have changed the wording. I have also added a link to the OCPI page.
Marc marc (talk)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:amenity%3Dcharging_station&oldid=2927639"