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:

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: 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>


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.


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.




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)










I think this is the most self explaining syntax.

In Europe this syntax is already used 119 times:

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 Domestic AC Type B USA.jpg 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


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:



--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


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=* (121 times used)

socket:combo2=* (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.

--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

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)

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.

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)

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)


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 ?

Charging robots

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