Proposal talk:Charging Stations v2

From OpenStreetMap Wiki
Jump to navigation Jump to search

current / amperage

Resolved: Proposal updated
Finally, in the context of EV charging stations, socket:*:current=* should refer to if the charging bay provides [W]Alternating Current (AC) or [W]Direct Current (DC) (values of socket:*:current=direct or socket:*:current=alternating.) socket:*:amperage=*

Please don't try to redefine tags already in use. ```:current``` is (since at least 8 years) defined as the current output of the socket. ```:amperage``` never has been defined and is used on less than 200 charging points. For most sockets it's not even necessary to specify if they are DC or AC - there is just one option. --Mueschel (talk) 10:47, 21 May 2025 (UTC)

Hi Mueschel, unfortunately OSM is not using the best tags here, and since EV charging stations were not exactly front of mind when key socket:*:current=* was created, the need was not expressed.

In most applications, the electric grid outputs AC power, and the AC -> DC conversion happens post-socket (another thing OSM is confused on - a socket is not a connector/cable) such as in a smartphone or power tool battery since batteries store energy in DC.

As explained in the quoted section, EV charging stations can be either AC or DC with varying uses and speeds. For example, there is a [W]ChargePoint station near me that has 3 charging bays, 2 of which are slower, cheaper AC charging with 1 bay being a DC Fast Charger (DCFC) with a CHAdeMO connection. If the DCFC was "in-use" it would be very disappointing for a user to arrive to the "available" station only to find a level 2 charger when they expect a DCFC (level 3). This is not a hypothetical, I have had conversations with people at that station on exactly that since it is about a 10 minute drive from the motorway.

Similarly, the amount of amps a dispenser can deliver is important for maximizing charge time and minimizing charge curves on newer and next-generation vehicles. This information is included on the charger itself and can be easily verified.

While I do wish all of OSM would switch to :amperage for amps, this proposal is not suggesting or advocating for a retag across the board, simply a "amenity=charging_stations use this tag this way". --GA Kevin (talk) 12:15, 21 May 2025 (UTC)
Please give an example of a station. From you explanation, it sounds like any other station without any notable difference.

Another remark: The terms 'amperage' and 'current' convey exactly the same meaning and can be used interchangeably in almost every technical context. So, if there is a need to explicitly tag AC/DC (which might well be the case in some places), there can be a new tag for it - but redefining a subkey that is used way more than 10,000 times since a long time is a very poor choice. --Mueschel (talk) 13:00, 21 May 2025 (UTC)
Charging station in front of the Lowndes County Courthouse

This is the [W]ChargePoint station from my example. The unit on the right is a 1-bay DCFC (level 3) and the unit on the left is a 2-bay AC charger (level 2).

Amperage and current are similar but not interchangeable. Amperage quantifies the current, so I can say a dispenser has a current of 600A or an amperage of 600A. However, while I can state the current is DC or AC, it would be inappropriate to say something has an amperage of DC.

I do think there is a benefit in having this information in OSM and agree redefining a key is not ideal without a separate proposal. How do you feel about key socket:*:polarity=*? Since direct current is a constant polarity and alternating current is no polarity, tag socket:*:polarity=dc or tag socket:*:polarity=ac could be used. This would leave key socket:*:current=* with the same definition it currently has in OSM. --GA Kevin (talk) 15:23, 21 May 2025 (UTC)
I don't see anything in your example. There are type1_combo and nacs connectors. Both don't need a ```socket:type1_combo:current=direct``` tag - type1_combo always includes DC (otherwise it would be a simple type1 connector) and for NACS it is evident by the maximum power/current tagged. All the European connectors are inherently AC or DC as well. The only open question (I'm not fully familiar with American charging stations): Are there ever ```type1_combo``` connectors used for AC charging?

Semantics: dc/ac is not a "polarity". "power_delivery" might be a matching term. --Mueschel (talk) 18:35, 21 May 2025 (UTC)
From a quick search of Plug Share, it seems there is quite a few stations in the United States with charging speeds that suggest they are AC chargers despite having combo connectors. Of course Plug Share, Open Charge Map, nor the Alternative Fuel Data Center explicitly track this, so surveys and reading labels would be needed, something OSM contributors are very well equipped to do. The better alternative is to get a key manufacturer:wikidata=* and key model:wikidata=* and use values from there for more information, but that is a heavy ask for contributors in the field vs "read the label and report AC or DC". Some connectors, like the MCS Connector only have the option to DC charge so a bit of quality analysis can be done on that when MCS is more widespread.

As far as the key, I am okay with key socket:*:power_delivery=* if that is technically correct and clear enough for the average user. --GA Kevin (talk) 19:43, 21 May 2025 (UTC)
I agree with the first comment here: Please don't try to redefine tags already in use. You may not agree with the tag that is in use but changing it now is too late in my opinion. --RobJN (talk) 21:04, 21 May 2025 (UTC)
Thank you Rob and Mueschel, I have updated the proposal to match key socket:*:power_delivery=* based off your feedback. --GA Kevin (talk) 02:40, 22 May 2025 (UTC)


length:cable

Resolved: Proposal updated

A separate tag for a length of a cable doesn't make sense. Charging stations usually have more than one cable, and they can be of different length. The length needs to be a subkey of a socket tag like ```socket:type2_cable:length``` or ```socket:type2_combo:length```. --Mueschel (talk) 10:49, 21 May 2025 (UTC)

Great idea, I have updated the proposal to key socket:*:length=*! --GA Kevin (talk) 12:15, 21 May 2025 (UTC)

Proposal is too broad

This proposal tries to add too many things at once. E.g. an possible import from external data bases or a new scheme of payment tags with an 'app' subkey. All of this should be separated into individual proposals. --Mueschel (talk) 10:52, 21 May 2025 (UTC)

I am happy to discuss any additional examples you may have but key payment:app=* is an already established key, and in use in at least iD and GoMap!! from what I can tell. key payment:*=* in itself is very flexible with tagging so suggesting additional apps is not unheard of.

On imports, this proposal is not a suggestion, proposal, or discussion on any particular import. I included the import section (with a known license-friendly example) because relations can be tricky to import. I wanted instead to offer the "simplified" tagging and make sure the key note=* is added so contributors can manually upgrade these to relations post-import.

This is also good information for data consumers if they want to give an option to add stations to OSM not currently present (akin to Open Charge Map) which can be much easier added as a node (+ note) vs relation. I don't think that section provides anything new to the proposal, simply a guide for a potential future concern. Open to discussing if that should belong elsewhere though. --GA Kevin (talk) 12:15, 21 May 2025 (UTC)
```payment:app``` is an established key, but there are no instances of it being used with another subkey to specify the name of the app. This should be discussed in the context of payment methods and not in the very specific context of charging stations.

In my experience, proposals should not have too many side remarks like the import - they tend to create votes abstaining or against just because of what is mentioned there, even if it has no influence on the main proposal. I would even suggest to separate the grouping relation from the update of tags on the objects themselves to avoid a "No, because relations are too complicated". --Mueschel (talk) 13:12, 21 May 2025 (UTC)
key payment:*=* already encourages subkeys when appropriate. I do not see this as controversial to add new payment methods when ones arise. Unlike some other places, key payment:app=* is not specific enough in the context of charging stations, as some apps have roaming agreements with Charge Point Operators (CPO) which is described in the "Tagging" section of the proposal in the Roaming and Charge Point Operator subsections.

I am conflicted on the import concern, as extra information that's already been thought about does not have an alternate place in the proposal stage. It would be unfortunate if a contributor voted against a proposal simply because it had too much information, not because of the substance.

The "relations are too complicated" has been addressed in the proposal via the discouraged but valid node amenity=charging_station. A lot of things in OSM are complicated because the world does not like to be neatly organized, that does not, to me, mean we don't use 1/3 of our element types (node way relation). An opposition to this proposal should be based upon the content of the proposal, not the ability of the contributor, especially when there is a simple alternative. --GA Kevin (talk) 15:23, 21 May 2025 (UTC)

Proposed site relation is confusing and does not work in reality

I'm doing a lot of EV charging station mapping at the moment and the proposed relation wouldn't work for many of them. You state that "a bay is a space where one vehicle may charge" (which I assume you mean a parking space / bay). You also state that the socket information should go on the bay. This doesn't work in cases where a bay can be served by more than one man_made=charge_point. This can occur if the cables are long and allow the user some flexibility of which charge point they plug in to.

I include an example of this below. The black lines are the parking bays, the yellow circles are the charge points. You see that charge points (dispensers) are between two rows of parking bays. A user who parks in the, e.g. top-left bay, can grab a charging cable from two different man_made=charge_point features. These may have different sockets/cables on them.

Not that this arrangement also means that the operator has no idea of which bay is in use. They just know which socket/cable on the charge point is in use. Thus failing another part of your proposal.

--RobJN (talk) 21:31, 21 May 2025 (UTC)

Can you please share a photo of a charging station that does this? A properly designed charging station should have 1 parking space per concurrent dispenser capacity regardless of the number of connectors offered by a dispenser. In your diagram, do all the dispensers face the same direction? Is there dedicated parking / signage in the area explaining where you are to park for each? While people may use a charging station incorrectly (we've all seen the posts I am sure), OSM should reflect the intended/official use of an amenity not a desired use. If a contributor really wanted to mark a desired, unofficial use, tag informal=yes can be used as it does on paths. As far as in-use, it would be up to the data consumer or CPO to determine how closely they want to monitor informal uses. A simple Arduino sensor can tell you if a spot is occupied coupled with data from the dispenser. Again, that is up to the data consumer to implement if desired, not OSM. --GA Kevin (talk) 02:04, 22 May 2025 (UTC)
Here is a "stall" with 3 charge points and 3 parking spaces. You can't say if a parking space is linked to a charging point.

https://panoramax.openstreetmap.fr/?background=streets&date_from=2023-04-01&date_to=2023-07-15&focus=pic&map=22.05/46.97056252/-1.43506499&pic=bad14b90-afd3-450e-a2ca-80299cbaf253&speed=250&theme=default&xyz=174.00/0.00/30 StephaneP (talk) 10:56, 22 May 2025 (UTC)

Hi StephaneP, unless I am missing something, there are 2 connectors on that charge point, meaning 2 bays. There is indeed 3 spaces reserved for EVs but unknown what that third space is intended for (maybe waiting if the dispenser is in-use?) We already have parking space tagging and conditionals to tag that odd third space and this proposal does not aim to address non-station EV parking spaces. --GA Kevin (talk) 20:29, 22 May 2025 (UTC)
Look again, it has 3 connectors: 2 cables + 1 socket. --RobJN (talk) 22:05, 22 May 2025 (UTC)
You’re right, it actually has 4 connectors, 2 AC and 2 DC. Regardless, the dispenser can serve as the dispenser for 3 bays just like in the example where it serves 2 bays. --GA Kevin (talk) 22:32, 22 May 2025 (UTC)

Further to the proposed site relation being too complicated whilst not actually working very well, it is also contrary to how relations are currently being used. I reviewed this a few months ago. There are a couple users adding site relations (in France and USA) but these are there simply to allow the users to associate all the equipment and bays together with socket info going on the charge point. Others, including myself, feel this is simply too complex and a simple closed way around the charge station area is sufficient. In the case of one CPO having multiple disjointed areas then a simple multipolygon will suffice. No need for a site relation. Run this query to see how mappers are currently using relations: https://overpass-turbo.eu/s/24Cz --RobJN (talk) 21:46, 21 May 2025 (UTC)

relation type=site states "A site relation is appropriate when a single real-world feature, with a common name and other common characteristics, cannot be accurately represented by a single or multiple areas forming a multipolygon, since it incorporates one or more point or linear features." As charging stations include (critically) at least 1 node man_made=charge_point, this node automatically disqualifies this relation being a multipologon and neatly into a site relation. Reading that page, this is exactly the type of thing a site relation is designed for. In your example on the community forum this relation does not associate the charge points with their parking space, nor the bay to the overall station, with tags that are impossible to identify to which bay they belong due to semicolon tagging. A site relation makes this simple, repeatable, and explicit in its meaning and relation, as is intended by tag type=site. --GA Kevin (talk) 02:04, 22 May 2025 (UTC)
Regarding your comments on my example on the community forum, the relationship does not associate the charge points with their parking space intentionally because that one to one mapping does not consistently exist in the real world (see my points elsewhere). As for a node within a way "automatically disqualif[ying]" the use of a multipolygon, this is utter rubbish. A building outline can be mapped with a multipolygon if needed and nobody claims that if there are shops mapped as node (or even areas) within the building then it disqualifies the use of a multipolygon relation for the building. --RobJN (talk) 13:37, 22 May 2025 (UTC)
A building outline can be mapped with a multipolygon if needed and nobody claims that if there are shops mapped as node (or even areas) within the building then it disqualifies the use of a multipolygon relation for the building. That may be true, but both the relation multipologon and the relation site clearly state that nodes are not acceptable in a multipologon relation. As such, to add a node man_made=charge_point to a relation multipologon is incorrect. The suggested alternative is a site relation. Not by me, by both wiki pages. --GA Kevin (talk) 20:29, 22 May 2025 (UTC)
I'm not adding the nodes to the multi-polygon. I'm creating a closed way around the whole charging station site (using a multi-polygon if and only if needed to properly surround the whole area). I'm then adding nodes for the charge points. I could also add closed ways for each parking bay but I choose not to map that level of detail. As noted, this is the same as how buildings are mapped (closed ways, with multi-polygon if needed). If a mapper then puts a shop node within the building that is acceptable and people will correctly assume the shop is in the building. Same for the charging station. If I put a man made charge point node within the closed way then it's assumed to be part of that charging station. No need for complex site relations. --RobJN (talk) 22:05, 22 May 2025 (UTC)

Your own photo of the IONNA EV Dispenser shows the problem here as well. What is stopping a driver parking in (what you are assuming is) the "2A" bay but plugging in the 2B cable? They probably won't in this case but could do if 2A was a Type 2 CCS cable while 2B was a Chademo cable. (or 2A was a Type 1 CCS cable while 2B was NACS cable if you want a USA example instead of a European example). This is very much a thing here in Europe. I found a photo of exactly that within 1 minute of searching: https://resizer.nationalworld.com/5a494666-3f44-4815-ba1f-9dae3e87b0b4.jpg?tr=w-1200 The car has parked in what you would say is the Chademo bay (Chademo has the blue handled connector) but has plugged in the Type 2 CCS connector (black handle). --RobJN (talk) 22:13, 21 May 2025 (UTC)

While I havent looked up that exact model of dispenser to know for sure, something tells me it is much like many ChargePoint or Electrify America chargers here in the United States, where there are multiple connectors available but only 1 may be used at a time, which is why it in a properly designed station, there is 1 parking space (and 1 bay) for each concurrent dispenser capacity. In the IONNA example, the Alpitronic HYDC400 is capable of simultaneously charging 2 vehicles. As such, a single dispenser is part of 2 bays, both with role dispenser (this exact dispenser has a name of "CCS 2" serving as the dispenser for bay "CCS 2A" and bay "CCS 2B" seen here. To use the incorrect stall for a dual charger such as this would be incorrect and the spots are labelled with the corresponding bay. If a user incorrectly uses a charging bay, that is more an error on the user or CPO side than OSM. OSM should reflect the intended use. In fact, at this station, you may be abe to see there is a parking lot behind the station. I have seen people try to park on the kerb there and stretch the cables to charge improperly, I would not mark those spaces as part of the charging bay or station or even as tag parking_space=charging even though it is possible to do. --GA Kevin (talk) 02:04, 22 May 2025 (UTC)
Quote: "something tells me ... only 1 may be used at a time". Well you are wrong. This particular CPO installs these chargers with two cables on them. On most they put two Type 2 CCS cables as that is the standard here in Europe. But on about 1/3rd they switch one of the connectors for a Chademo connector as we still have vehicles that use those. I cannot support your proposal when you continue to not listen to real world examples and assume that all charging stations are "properly designed" to the standard you expect. This is simply not the case and as such your relation proposal simply will not work universally. It will add more confusion. To blame the user for "incorrectly uses a charging bay" is also wrong. I have seen plenty of examples where the user is given free choice as to where they park within the area because it is not as simple as a one-to-one relationship between socket/cable and parking bay. Here (google streetview link) is another example that shows it is not as neat as your view of a "properly designed" charging station. On the left is a charge point with a Chademo cable, a CCS cable and a Type2 socket. On the right is a charge point with two CCS cables. In the May 2022 image there is 3 parking bays; the Nissan Leaf is plugged in to the Chademo connector (and parked in the correct bay, as you would see it), the VW into the CCS and the mid bay is free and can connect to either charge point including the type 2 socked on the left one if they have a long cable. In the June 2024 photo, the CPO has marked 4 bays and has even lablled them. You will see that they are perfectly happy for the car to park in the second bay and plug in the Chedmo connector (the "wrong" bay in your mind). Note that there is also a mini parked in the disabled bay, which is outside of the CPO's area, but plugged in to the Type 2 socket. The real world does not work in a "properly designed" way! --RobJN (talk) 09:40, 22 May 2025 (UTC)
Please be assured we are on the same team of trying to make OSM better and more reliable. I sense a bit of unease not proposal-related and I want to make sure any discussion here is fruitful. Maybe (hopefully) I am mistaken about that! I appreciate your example, it seems this particular station went from a row of disabled parking spaces to the initial charging station, not fully taking advantage of their capacity properly but reusing the same lines as the disabled spots previously. It seems sometime before the 2024 imagery was taken, they updated the lines to reflect efficient design (4 simultaneous charging capacity = 4 charging bays). Of course, nothing is stopping a particularly wonky setup from having multiple dispensers assigned to the bay relation, this proposal allows for that. It would be a headache for the CPO, but that is none of our concern as OSM contributors. Regarding that first one, it is indeed a ABB charger which has a simultaneous charging capacity of 1, thus 1 charging bay, even though it is able to accommodate multiple connector types. If you attempt to plug in 2 vehicles, it will not work. I have done this myself on these dispensers and a ChargePoint dispenser that is similar. --GA Kevin (talk) 20:29, 22 May 2025 (UTC)
Any unease you sense comes from the fact that I believe your proposal will make OSM worse not better and the frustration that my points seem to be being dismissed. I'm sorry but I don't think your proposal is a good one and therefore I will say so to ensure OSM is not made both worse and complex. Tagging is hard and any proposal needs a lot of work including listening to feedback. Many thanks. --RobJN (talk) 22:15, 22 May 2025 (UTC)
I would encourage you to assume good faith. --GA Kevin (talk) 22:42, 22 May 2025 (UTC)

Model and manufacturer

Resolved: No action needed

These seem to be good additions for those that want to add the detail to the man_made object. I suggest you start with an RFC for that (or just add it to the wiki page as probably doesn't need an RFC). P.S. "model=Rechargery Relay" doesn't seem right though. Rechargery Relay appears to me to be a sub-brand of IONNA rather than a model. --RobJN (talk) 22:29, 21 May 2025 (UTC)

Thanks Rob! I am trying to think of ways to easier identify common chargers and link them to known brands (i.e. Circle K in the United States uses ABB Terra chargers, Tesla has known versions, etc.) if this passes. I can then add that to things like iD, StreetComplete, or other projects.

I chose tag model=Rechargery Relay because it is a type of station by IONNA. You can see a list of types here which includes their flagship "Rechargery", as well as "Rechargery Relay"s, "Rechargery @"s, and new "Rechargery Beacon"s coming soon. I am open to another tag, but model seemed close to type in this case.--GA Kevin (talk) 02:33, 22 May 2025 (UTC)

ac vs dc

As I have pointed out before, the standard for this is frequency=* . frequency=0 can be presented by editing software as dc. There's no problem with user knowledge in this aspect. If there's really a need for adding ac manually without assuming knowledge of mains frequency, eg frequency=ac could be accepted as an *=unknown / fixme=* . However as with other national presets, an editing software may theoretically match and fill the correct mains frequency automatically when such a table is compiled.
—— Kovposch (talk) 02:52, 22 May 2025 (UTC)

I find this to be an elegant solution, would you suggest the use as a top-level tag (i.e. tag frequency=0) or as a part of the socket (i.e. tag socket:*:frequency=0)? --GA Kevin (talk) 20:31, 22 May 2025 (UTC)
For consistency, you can certainly make it socket:*:frequency=*
—— Kovposch (talk) 04:22, 23 May 2025 (UTC)

Feature and topology

site=* is used when there's no suitable feature. power=plant , amenity=university , etc, are already widely used. site=charging_station should simply be amenity=charging_station . The proposal even mentioned it as "Legacy tag describing the type of the site, better use the full tag (main tag). Existing usage may continue. Might also be used for new sites if no suitable full tag exists". https://wiki.openstreetmap.org/w/index.php?oldid=2064610
As always, relational features will be get pushbacks for complexity, and should be avoided unless absolutely neccessary. A presumption against them. amenity=charging_bay can be an area enclosing the amenity=parking_space and man_made=charge_point when there's only one side. Using direction=* could still be considered when there are only 2 sides. There should be an simpler initial alternative/option against Template:Type + amenity=charge_bay by using some ref=* / *:ref=* attribute-wise.
—— Kovposch (talk) 03:07, 22 May 2025 (UTC)

I think the current tagging and this proposal can coexist since the role label in this proposal contains tag amenity=charging_station it would not change current queries that use that or Carto rendering (as seen in the rendering section). I do not intend for this proposal to mean we need a mass edit on existing features, just that this would be the new standard moving forward.

I realize the challenge of getting a relation proposal passed, unfortunately from discussions I have had people may abstain because of their own confidence in mapping something rather than the merits of the proposal itself. I for one do not understand a lot of OSM (water and railroads being 2 big examples) and while I won't personally touch those as I am not familiar, I do not object to their (rather well-done) mapping. Likewise with others and a charging station relation, which is why I have included the option for a simple node alternatively with a note stating expansion is needed. refs are certainly present in charging stations, and that was my initial thought as well, but a site relation makes the 3 levels of the station (station, bay, dispenser) much clearer. Happy to discuss how the alternative node part of the proposal can be improved, it is essentially unchanged from present day to be compatible.

As always, you have some great insight and I appreciate you taking the time to write this out! --GA Kevin (talk) 20:41, 22 May 2025 (UTC)
In geographical data, it's not always a must to link related objects together explicitly. Usually any database can already work by joining different tables, ie simply matching some ref=* / *:ref=* on both levels. When there are polygons, there's automatically an implicit spatial relationship when something is inside one. This can be compared to how role subarea is criticized as unneeded in boundary=administrative , despite how it may make subdivisions obvious.
—— Kovposch (talk) 04:28, 23 May 2025 (UTC)

kW and kWh are not the same

Resolved: Proposal updated

The current proposal says Output is measured in kWh. It should be kW. These are not the same thing. Think of a tap filling a bathtub. You have two elements: (1) The instantaneous rate at which the bath fills (how fast the flow of water through the tap is) and (2) how much water is in the bath (the volume of water). In electricity kW is the instances flow while the kWh is the volume. An instantaneous flow of 1kW of electricity gives a "volume" of 1kWh after 1 hour of flow which is why people often get this mixed up. An instantaneous flow of 1kW of electricity gives a "volume" of 0.5kWh after half hour, 2kWh after 2 hours, etc. --RobJN (talk) 10:56, 23 May 2025 (UTC)

My bad, it's even clearly listed on the key socket=* page and Alpitronic's own website as well as on the physical label on the example dispenser:
Regulatory label on an IONNA Alpitronic HYDC400 EV Charger

I have corrected on the proposal. The only kWh left is under key charge=* as the cost is listed across multiple sources in kWh (I checked my recent invoices from IONNA and Tesla to verify this.) Does it look correct now? --GA Kevin (talk) 12:57, 23 May 2025 (UTC)
That's right; fees paid are typically in pence or cent per kWh (volume) of energy supplied. --RobJN (talk) 13:21, 23 May 2025 (UTC)

A way to dicern available capacity on entire site

A collection of charge_points in a site has a maximum of A it is wired to.
Would be great if we could record this information, just becuase a socket has a maximum amount of say 22kW - that does not mean that it will always output that, that depends on the infrastructure on the site. How would be denominate that a collection of charge_points share a breaker of, say 60-100A or something like that?

Imagine you are arriving or are planning to go to a site to charge and the site has spread their chargers too thin, you get to little power becuase there is a lot of people charging at the same time, you can then use . Even if there are 10 charge points with 2 sockets each, 20 vehicles may not be able to charge at the same time. (you may not want to risk it if you are multiple people that are needing to charge that there may not be the capacity to charge your vehicles in a timely manner or at all)
I realize it is hard to find this information on a charger in the field, would be great if our schema extends on this (maybe it is described in OCCP?)

So this proposal would be like something of a "guarantee" of a minimum amount of power levels.

I have recorded the information we got from our installer on our sport facilty website for reference: Hållbarhet, EV charger - Emmaboda GK
(In Swedish but I think you can translate it in your browser, so you can get a picture of it)'
For example, our EV charger has a breaker of 63A which gives 44kW, each socket can give a maximym of 22kw, and this is then split between the sockets, we have three "poles"/chareg_points with 2 sockets each. But only 4 could be used on a typical load of 11kW before we do not have more breaker capacity. This was becuase we do not have enough power in the local net to deliver these loads but we future proofed our installation and installed to many charge points, which I think will be more and more widespread becuase our electricity infrastructure is getting strained(but in a good way, room to impove) by these charge sites. HuggeK (talk) 06:42, 27 May 2025 (UTC)

Proposal to enrich cable metadata

The discussion rightly points out that charging stations often have multiple cables of different lengths. To capture that properly, I propose using sub‑keys per socket type. For example: 

socket:type2_cable:length=5m  
socket:ccs_combo_cable:length=7m

This:

  • maintains precision without losing useful data
  • avoids confusion of a vague general length tag
  • stays in line with the proposal’s philosophy of detailed, future‑proof tagging

--Ksetdekov (talk) 08:40, 17 June 2025 (UTC)

---

⚡ Optional enhancement: vehicle‑to‑grid support

With bi‑directional and V2G capacible chargers becoming more common, could we add a Boolean tag, e.g.: 

socket:*:vehicle_to_grid=yes

This would let mappers indicate whether a charger supports vehicle‑to‑grid functionality per socket. --Ksetdekov (talk) 08:40, 17 June 2025 (UTC)

Does amenity=charging_station always feed back to the grid? Should consider how to generalize. Vehicle-to-grid
  • "Vehicle-to-load (V2L) and vehicle-to-vehicle (V2V) are related concepts, but the AC phase is not synchronised with the grid, so the power is only available to "off-grid" loads."
  • "California's grid operator, CAISO, defines four levels of Vehicle-Grid Interface (VGI):[20]" "Bidirectional local V2G (V2H, V2L, V2B, V2X)"
Cf backup_generator=* . There was a question about (backup) batteries somewhere I forgot. Only 1 electricity=battery now.
Fundamentally, do public stations have this? Depends on whether public users would agree to it. Unidirectional V1G smart charging seems more likely and relevant, as it can save you money and battery life, while you need to be aware of the charging rate in the process.
—— Kovposch (talk) 08:11, 18 June 2025 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Charging_Stations_v2&oldid=2867542"