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)

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)

Charging robots

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

Status "de facto" vs "in use"

I wonder why it is set to "de facto", even there is a formal proposal available: Proposed_features/Charging_station, should it be "in use" instead, because the description for status "de facto" says in Template:Description "the tag is in widespread use, but no formal proposal process has taken place" --MalgiK (talk) 10:01, 18 December 2019 (UTC)

Generally a proposal becomes "approved" (or "rejected") if there was a complete proposal process with a vote to approve at the end. --Jeisenbe (talk) 10:15, 18 December 2019 (UTC)
I agree, so "approved" or "rejected" we should not use here (now). --MalgiK (talk) 10:50, 18 December 2019 (UTC)
In this case, there was a proposal and an "opinion poll", but no formal vote, from what I can tell. https://wiki.openstreetmap.org/wiki/Proposed_features/Charging_station#Opinion_poll --Jeisenbe (talk) 10:15, 18 December 2019 (UTC)
My understanding for status "de facto" is once there is a proposal process started, status "de facto" can't be used anymore, or I missunderstood the description "but no formal proposal process has taken place". So that's why i would use status "in use" for amenity=charging_station. --MalgiK (talk) 10:50, 18 December 2019 (UTC)
I see how that can be confusing. There are several "de facto" tags which had a draft proposal which was never advanced to the voting stage but then became accepted as the main way to tag something. Amenity=charging_station is a good example of this. We can change the description of "de facto" to something like "...but the formal proposal process has not been completed" --Jeisenbe (talk) 21:11, 18 December 2019 (UTC)
Yes, it's confusing if it means that "de facto" is ok, even if there is a proposal process started (at least for me, a non-native speaker/reader). Yes, i would be happy, if then this sentence would be modified to your proposed wording: "... but the formal proposal process has not been completed". By the way, thanks for your work on creating the Approval_status article page. Would it be okay, to add links between Approval_status <=> Proposal_process at the "See also"-section for both pages?--MalgiK (talk) 19:59, 19 December 2019 (UTC)
However, the "de facto" status is just as good as "approved" in most cases. --Jeisenbe (talk) 10:15, 18 December 2019 (UTC)
I agree & i know. --MalgiK (talk) 10:50, 18 December 2019 (UTC)
De facto state is where something is de facto accepted, even in cases where there was never a proposal. For example highway=motorway Mateusz Konieczny (talk) 15:21, 18 January 2020 (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)

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 scotter'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)