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

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)

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)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:amenity%3Dcharging_station&oldid=2675524"