Proposal talk:Charging connectors
Suffix neccessity
- If a plug is only configured for AC or DC, is plug:*:ac=yes + plug:*:dc=no (or vice versa) needed? It should use pre-existing plug:*:frequency=* directly.
- When there is a combination of the two, it could use semicolon multival plug:*:frequency=0;60 as other features eg power=* and light_source=* have done. plug:*=1;1 and capacity=1;2 follows for the examples.
—— Kovposch (talk) 05:51, 22 March 2024 (UTC)
- there is a list of assumed defaults Proposal:Charging_connectors#Common_Plugs/Sockets_and_assumed_defaults as long as it fits to the default, no :ac or :dc is required.
- I don't think that frequency fits. Only AC has a frequency and it is a technical term a normal EV driver never comes along. Chargers and even pricing lists are always separated in AC and DC. That is something an EV
Driver knows in his context, without actually needing to know how electricity works. - Multiple values separated with ; is thinkable, but at the moment I don't see any needs for that. Do you have an example where it could be beneficial?
- --Kevinq (talk) 08:14, 22 March 2024 (UTC)
- To clarify, I'm talking about having to use *:*:ac=no + *:*:dc=yes in Proposal:Charging_connectors#Tagging_Suggestion and Proposal:Charging_connectors#Examples . If this is changed to some *:*:*=dc , that's not much different from *:*:frequency=0 .
—— Kovposch (talk) 07:19, 23 March 2024 (UTC) - DC already uses frequency=0 by standard. By the same criteria, do drivers always know the exact socket:*:current=* , socket:*:output=*, or even socket:*:voltage=* ? They only need to know the standard. That doesn't prevent such info from being added by some, or others. If you are adding info about electricity, the attributes and format used there should be followed.
Quite the opposite, the need of theses 2 suffixes is what I want to ask here. If there will only ever be dc and ac, semicolon won't be complicated. There will only be 2 entries. You don't need the extensibility of suffixing. This is simpler than power=* , where there can be a longer list that needs to be maintained across different attributes.
—— Kovposch (talk) 15:48, 22 March 2024 (UTC)- frequency is a highly technical term, people who don't care about electronics might not know what that means. It also make more room for misstakes, people could add frequencies that aren't corrent, or add units whre they don't belong. For the average EV driver the question about AC and DC is nicht an electrical question, it is a practical question. DC means usually higher prices and faster charging than AC. Maingau wants 0,49€/kWh for AC and 0,59€/kWh for DC. LichtBlick wants 0,55€ for AC and 0,75€ for DC. AC or DC is also sometimes written with big letters on the Station. Frequency is in best case on a little type plate somewhere at the bottom, maybe even back of the charger. Sometimes you don't find the Info at all. Also no one maps the current at charging stations. Voltage is also uncommon (but might be sometimes beneficial for the few 800V system cars). I would prefer to have it easy to map. frequency is in my opinion a workaround
- --Kevinq (talk) 20:58, 22 March 2024 (UTC)
- What's "no one"? There are >11k socket:*:current=* . Tag:amenity=charging_station lists this as combination, with examples.
How is frequency more or less "technical" than voltage and current? The different standards, and the plug:*=* vs socket:*=* terminology can be argued as more technical too. Dc is frequency=0 , and ac is the mains frequency there. That's in some sense simpler to input than the exact socket:*:output=* number. Semicolon can be said as further easier than *:ac=* + *:dc=* . Both could eventually be handled by the editing software to show a dc label, and format the pairs accordingly
Besides, there is Key:capacity:charging apparently. Then do you need to make it capacity:charging:*c=* to standardize, or make this a shorthand or context-dependent increasing the number of variables and combinations? Interfacing and intercompatibility is something you have to consider for suffixes.
—— Kovposch (talk) 07:13, 23 March 2024 (UTC)- Go to any charging Station and ask the people if they know what volt, ampere or frequency is, and if they can tell you what the value of the charging station is, you will probably not get a lot of answers. They probably also don't know what AC or DC in a technical sense is, but they know that there are DC and AC chargers. You can go to a gas station and ask for the difference between gasoline and diesel. You can also define a cetane number for both and tell them apart on that number alone, but 99% of the people on the gas station know only that they have either Diesel or Gasoline. And more isn't relevant for them. EV Drivers know about AC and DC charging, they know that there are different prices and different speeds but that is where it ends. Of course there are always some people who are deep into the topic like me, they can add a ton of extra data, but that data isn't important, it doesn't mater for people looking for a charging station. But if its AC or DC matters.
- --Kevinq (talk) 17:02, 23 March 2024 (UTC)
- There's no notion of ac or dc now. Does it prevent contributions? No, still works fine by using the socket:*=* directly.
As I said, the editing software can be made to show dc and ac as labels, fields, or presets. New users may not know how to enter raw tags anyway. If they want to do so, they can be told to enter *:frequency=0 or the mains frequency alongside. The consistency between different features for the same attribute is what's important. No need to reinvent the same concept for different things. Should there be some *:fast=* , *:medium=* , *:slow=* , because these charging speeds are further simpler to understand than ac and dc?
—— Kovposch (talk) 08:57, 24 March 2024 (UTC)
- There's no notion of ac or dc now. Does it prevent contributions? No, still works fine by using the socket:*=* directly.
- What's "no one"? There are >11k socket:*:current=* . Tag:amenity=charging_station lists this as combination, with examples.
- To clarify, I'm talking about having to use *:*:ac=no + *:*:dc=yes in Proposal:Charging_connectors#Tagging_Suggestion and Proposal:Charging_connectors#Examples . If this is changed to some *:*:*=dc , that's not much different from *:*:frequency=0 .
- Before we discuss this tagging, could we check where this might be used?
- Tesla used the type2 connector for DC for some years. This is one specific case, that can only be used by few Tesla models. A dedicated tag would be helpful to avoid any confusion for other users.
- A type2_combo connector might contain AC pins together with DC (or no DC at all). Do any actual charging points use this scheme? That would imply that you can charge a "basic" type2 car from this connector with a simple adapter.
- The graphic with the red border in the proposal is not really helpful. This is a suggestion from the manufacturer how the connector might be used and not related to any defined standards that might be in widespread use.
- Are any other connectors certified that can be used with AC or DC? Any connector might be misused, obviously, but to be used in a tagging scheme, it should be a legal use case that can be found in the wild. --Mueschel (talk) 20:06, 31 March 2024 (UTC)
- NACS can charge with AC or DC. If this needs individual tags depends on two possibilities:
- Are there any NACS stations that do not provide AC?
- Are there any NACS stations with DC limited to less than 43 kW?
- If not, then tagging the maximum output of the station is sufficient.
--Mueschel (talk) 09:09, 1 April 2024 (UTC)
- Hello @Kevinq:,
- I am wondering if the focus on AC and DC is a bit of a distraction for this proposal. The rationale section starts off with "AC and DC Charging makes a huge difference in car charging", then the Tagging Suggestion section "Add the suffixes ac and dc to plug:* socket:* and capacity to define if it supports AC or DC" but immediately follows it with "Can be omitted on plugs/sockets which are only standardized for one of it"
- I would suggest perhaps reversing this, and only mentioning :ac=* and :dc=* tags for the specific cases where it's actually necessary (... basically only pre-NACS Tesla?), and perhaps focusing more on power output.
- My background is: I am based in Ontario, Canada with an interest in EV and have driven a PHEV eight times and charged a PHEV five times. I have never seen a charging station or plug described as "AC" here. DC stations might be described as "DC", but usually as "DC fast charge". I don't think most EV drivers here think about AC vs DC - they think about what plugs are available, or what the power output (kW) is.
- A Type 1 plug charges AC here. A Type 1 combo plug charges DC. I haven't used anything Tesla/NACS so I cannot comment on this, but from a user's point of view, since it's the same plugs, doesn't it seem more obvious to tag the power output, rather than the technical detail of whether the plugs give AC or DC?
- As an example, Plugshare.com is probably the most popular charging station list-and-review site in Canada. When showing a plug, in the header it says "J-1772, FLO, 6.24 - 7 kW" (Flo is the operator) for this station or "CHAdeMO, CCS/SAE, J-1772, ChargePoint, 19.2 - 62.5 kW" for this one or "CHAdeMO, CCS/SAE, FLO, 50 kW" for this one or "Tesla (Fast), Supercharger, 250 kW" for this one. Nowhere does it say AC or DC. So I'm not sure "AC vs DC" is a distinction made by EV drivers in Canada. Certainly I have never seen a station that labelled plugs as "AC" or "DC" as shown in the picture above.
- (Not focusing on AC and DC also avoids the entire discussion whether the tag should use "frequency" or not :) )
- Just a thought and some local info! --Jarek Piórkowski (talk) 01:36, 1 April 2024 (UTC)
Two namespaces really necessary?
Is it really necessary to split one namespace (socket) into two (socket, plug)? I would very much prefer a solution with only one namespace (as is: socket:*) and a well defined scheme how plugs and sockets are described within this one namespace. The name of tags don't need to follow their dictionary definition exactly, they should be used to group tags logically (here: ways of connecting a device to the power supply). --Mueschel (talk) 11:37, 31 March 2024 (UTC)
Purpose of the proposal?
Is the main purpose of this proposal to get rid of "*_cable" tags or to replace the tesla* tags with a more sensible naming? I think these two should be strictly separated as they might have a different voting outcome. --Mueschel (talk) 11:37, 31 March 2024 (UTC)
- The purpose is to have the tagging more uniform/abstract and get rid of the workarounds. a socket with a _cable is a workaround that someone invented because there was no tagging that specifies if you need your own cable or not. Same with the tesla stuff. Tesla used some plug different, and there was no way to tag that, so someone invented a new type of plug, even when the actual plug was identical.
- My goal is to have it possible to tag all the differences, so that no one need to invent workaround plugs.
- --Kevinq (talk) 19:34, 5 May 2024 (UTC)
- You write about having "the tagging more uniform/abstract". Introducing new namespaces for plugs and cables is the opposite of this. Currently the term "socket" is used for any kind of connector between a power supply and a power consumer. It can't get more uniform and abstract than this. If you try to categorize all connection possibilities into sockets / cables / plugs you'll see that this works in many cases but far from all. The terms plug and socket are not as well defined as it may seem from most of the connectors you use every day. There are sockets on cables (like the one I need for my electric lawn mower), there are plugs installed on devices, there are even connectors where plug and socket are identical. E.g. if you compare the CCS-type2 and GB/T connections, you'll see that what you call a plug on a cable in one standard is a socket on a vehicle in the other. Right now it's simple: Both use the "socket" namespace, and the definition how it looks goes into the subkey. This kind of abstraction away from the literal meaning is something OSM does everywhere - for example no sane English speaker would call a mountain hiking path "highway" but OSM does. --Mueschel (talk) 07:50, 6 May 2024 (UTC)