Proposal:EV Charging Station Mapping

EV Charging Station Mapping
Proposal status:	Voting (under way)
Proposed by:	NKA, based on draft by Jmarchon
Draft started:	2023-03-13
RFC start:	2023-03-30
Vote start:	2023-04-17
Vote end:	2023-05-01

Proposal

Following a long discussion on the OSM community site, I propose certain clarifications on how to map and tag EV charging stations. The definition of amenity=charging_station will change slightly and will represent both locations with a single charge point and locations with a group of chargers. A new optional feature, man_made=charge_point will be created to separate detailed mapping of each charge point from the main amenity=charging_station feature at locations. Please see the details of the proposal in the Tagging section below.

Rationale

Currently, some users create one amenity=charging_station node (or area) to represent a charging location, regardless of the number of charging points at the location. Other users map each individual charge point within a charging location as a separate amenity=charging_station node. This second approach creates duplicate entries in search results and elsewhere, such as in this case with 36 identical charge points. As the number of charging stations are growing rapidly it would be helpful to clarify how charging stations should be mapped.

As background, analysis of charging stations currently in OSM shows that as of March 2023:

• There are in total 91,006 amenity=charging_station in OSM.
• There are 5,736 groups of such stations with a distance of less than 20 meters between stations within a group. 16,203 amenity=charging_station belong to those groups. 3,982 of the groups have 2 stations only.
• Of the other stand-alone 74,803 amenity=charging_station (which is a mix of single charge points and of nodes which represents a group of charge points), 4,892 have capacity=1, 31,952 have capacity=2 and 14,273 have capacity=3 and higher (the others are not tagged with capacity).

This proposal will:

• Enable search queries, apps and maps to present only one instance of a location for charging stations, instead of one instance for each individual charge point.
• Enable detailed mapping of charge points for users who desire that.
• Establish a relationship between the location/group of charge points and each individual charge point when amenity=charging_station is mapped as an area around all man_made=charge_point.
• Relate to how charging brands/operators display charging locations and individual charge points to their users.
• Be backwards compatible for the amenity=charging_station tag. Approx 5,700 groups of charging stations would require retagging, but they are easily identified and the retagging is minimal.
• Leave 82% of amenity=charging_station unaffected, reflecting that the proposal builds on current mapping practice.

The proposal below is based on amenity=fuel and man_made=fuel_pump.

Tagging

I propose that:

1. The main tag amenity=charging_station should be redefined slightly to mean "a location where an electric vehicle may be charged". It may represent one individual charge point (without others close to it) or a group of charge points. 82% of charging stations are already mapped this way. Different brands/operators on the same location should be mapped separately.
2. While often not needed, a new optional tag man_made=charge_point can be used on a node for each “charge point” (sometimes also known as “dispensers”). For the avoidance of doubt, if there is only one charge point at the location, then the main tag amenity=charging_station must be used. That is to say that man_made=charge_point does not replace amenity=charging_station on single charge point locations. The reason for this is so that all charging locations may be identified using one tag only. Mapping of individual charge points at a location is permitted but not encouraged in order to avoid duplication of information and inconsistency, unless there is a specific need for it.
3. The amenity=charging_station feature may be mapped as a node or an area (a closed way):
   • As a node, it is mapped more or less in the middle of the charge point(s).
   • As an area, it is mapped around the location used by the charge points and associated parking slots. If man_made=charge_point are mapped, they should be inside the area. Multipolygons may be used to map the area for dispersed charge points. Multipolygon example Multipolygon example.
4. Where a new amenity=charging_station area is added around several existing charge points which are currently mapped as individual amenity=charging_station then those elements within the area should always be changed to man_made=charge_point.
5. As a general rule, tags currently described on the wiki page for amenity=charging_station are essentially the same for both the charging station and for the charge point, however with the following guidelines:
   • An amenity=charging_station should be tagged with at least name, brand (if any), the total number of each socket type at the location and the maximum available outpout in kW for each socket type at the location (see first table below).
   • When man_made=charge_point is being used for a location then tags which are common for the location as a whole, such as name and brand should be put on amenity=charging_station and do not need to be repeated on each man_made=charge_point. Also, if the socket information is the same for all charge points, it may be tagged on amenity=charging_station only to avoid inconsistency.

The tables below provide an overview and comments for the most important keys of the two features.

Non-exhaustive table of tags for amenity=charging_station objects:

Key	Description
amenity=charging_station	Feature tag.
name=*	The name of the charging station, for example "Tesla Vestby Supercharger".
brand=*	The brand operating the charging station, for example "Ionity".
access=*	Who has access to the charging station, for example "yes" (public access), "customers", "employees", "residents".
capacity=*	The total number of vehicles which can be charged at the same time at the location. The total number of sockets may be higher.
socket:<type>=*	The total number of sockets/cables of the type <type> that can be used at once at the charge point(s) of the lcoation.
socket:<type>:output=*	The maximum power (in kW) that can be sourced from a single socket/cable of the type <type> at the charge point(s) of the location.

Non-exhaustive table of tags for man_made=charge_point objects:

Key	Description
man_made=charge_point	Feature tag.
ref=*	The reference number or code used to identify the charge point, if available, for example "2126". Often displayed on the charge point and used in apps. Some charge points have two or more reference numbers, which may be tagged with a semicolon, for example "2126A;2126B".
socket:<type>=*	The number of sockets/cables of the type <type> that can be used at once at the charge point. Not needed if all charge points are identical (put on the amenity=charging_station object instead).
socket:<type>:output=*	The power (in kW) that can be sourced from a single socket/cable of the type <type> at the charge point. Not needed if all charge points are identical (put on the amenity=charging_station object instead).

Using site relations has been discussed but it was excluded from the proposal due to more complex editing for inexperienced users and limited support among data consumers.

There is also a capacity:charging=* key used with amenity=parking. It is not part of this proposal but may be regarded as a useful indication of locations where amenity=charging_station could be created.

In Europe, the ref:EU:EVSE=* tag would also be relevant.

Please note: I am not trying to redefine all the subtags used in relation to charging stations. For example, the tags brand=*, operator=* and network=* are being used differently among OSM users and local communities. These tags are not tackled in this proposal in order to focus on getting consensus on the main proposed changes.

Examples

Image	Tags
Recharge Vigra charging station Recharge Vigra charging station	Main feature: amenity=charging_station name=Recharge Vigra brand=Recharge access=yes capacity=5 socket:type2=2 socket:type2_combo=2 socket:chademo=2 socket:type2:output=22 kW socket:type2_combo:output=150 kW socket:chademo:output=63 kW Mapped either as a node, or as a closed way around the charge points and parking slots if the charge points are also mapped. Note: Most users would not map the charge points in this case, only one node for the charging station.
	Optional charge point 1: man_made=charge_point ref=2146A;2146B capacity=2 socket:type2=2 socket:type2:output=22 kW
	Optional charge point 2: man_made=charge_point ref=2126A;2126B capacity=1 socket:type2_combo=1 socket:chademo=1 socket:type2_combo:output=50 kW socket:chademo:output=50 kW
	Optional charge point 3: man_made=charge_point ref=2888A;2888B capacity=2 socket:type2_combo=1 socket:chademo=1 socket:type2_combo:output=150 kW socket:chademo:output=63 kW
	Example of a site with 4 different brands. Each brand is mapped (in this example) with a node. They could also have been mapped with areas. Click below to view the tagging. Tesla Rygge Supercharger Tesla Rygge Supercharger Recharge McDonalds Rygge Recharge McDonalds Rygge Ionity Rygge Ionity Rygge Mer Circle K Rygge Mer Circle K Rygge

Rendering

• Rendering of amenity=charging_station would be unchanged.
• Rendering of man_made=charge_point is not required but could be done at detailed zoom levels.

Features/Pages affected

• The wiki page for amenity=charging_station would be modified to clearly document the updated intended usage and tagging.
• A wiki page for man_made=charge_point would be created.
• This OSM file illustrates which charging stations in OSM are affected. Search for the GROUP tag.

External discussions

There is a long discussion on this topic on the OSM community site: Charging stations (sites or individual chargers)

Some discussion has also occurred on the discussion page for this wiki page.

RFC post

Comments

Please comment on the discussion page, grouped by topic.

Voting

Instructions for voting

• Log in to the wiki if you are not already logged in.
• Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	{{vote|yes}} --~~~~	Feel free to also explain why you support proposal.
I oppose this proposal. reason	{{vote|no}} reason --~~~~	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	{{vote|abstain}} comments --~~~~	If you don't want to vote but have comments. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For full template documentation see Template:Vote. See also how vote outcome is processed.

{{vote|yes}}—- 09:13, 26 April 2023 (UTC)

• I approve this proposal. Solves not-yet-solved problem, I have not found problems with this proposal. Note that it is a rare case where redefining tag in use makes sense: data consumers except rare, maybe nonexisting, cases will be not negatively impacted - typical uses will be even better served. It is possible to review and fix all currently existing data to migrate to a new standard. And it is less disruptive than deprecating old tag and invent two new tags for both meaning or ending with ugly subtagging forever. (it is not explicit but single charger points may carry both amenity=charging_station and man_made=charge_point, right? If proposal author agrees - maybe it can be added to examples section?). --Mateusz Konieczny (talk) 13:49, 17 April 2023 (UTC)
• I approve this proposal. --Bradrh (talk) 14:17, 17 April 2023 (UTC)
• I oppose this proposal. do not change the meaning of an existing tag! especially as it will now be impossible to know whether this tag concerns the old definition or the new one. the solution was either to create 2 new tags and abandon this one (not my preference) or to create a sub-tag to describe whether the individual object or the whole, as is done with recycling_type=site/container Marc marc (talk) 14:57, 17 April 2023 (UTC)
• I approve this proposal. --Jmarchon (talk) 15:06, 17 April 2023 (UTC)
• I approve this proposal. I like it --chris66 (talk) 16:18, 17 April 2023 (UTC)
• I approve this proposal. I like the proposal. I also like the approach of using amenity=charging_station for a general definition of an "area (or point) in which vehicles can be loaded on one or more columns". At amenity=fuel, we also don't tag every gas pump with this tag, but use an area for the entire fuel station. --Lukas458 (talk) 17:13, 17 April 2023 (UTC)
• I have comments but abstain from voting on this proposal. As several discussions aren't over in the Talk page. It's necessary to find a suitable way of addressing references between OSM, business objects and opendata. This proposal should solve this permanently beside introducing man_made=charge_point. Fanfouer (talk) 17:29, 17 April 2023 (UTC)
• I approve this proposal. -- Something B (talk) 19:05, 17 April 2023 (UTC)
• I approve this proposal. -- Carnildo (talk) 19:10, 17 April 2023 (UTC)
• I approve this proposal. --OSMRogerWilco (talk) 19:27, 17 April 2023 (UTC)
• I oppose this proposal. No reply for my question about using power=outlet in common with other features. The difference between connector and cable is already handled by socket:*=* eg socket:type2=* vs socket:type2_cable=* . man_made=* should be used for the structure, similar to power=transformer in, or power=substation as a man_made=street_cabinet. man_made=* itself is a problem of bloat and poor connotations that can be solved with power=* here. --- Kovposch (talk) 19:45, 17 April 2023 (UTC)
• I approve this proposal. --Msuchy (talk) 19:59, 17 April 2023 (UTC) Although this does not solve all problems, it solves the biggest problem we have now.
• I approve this proposal. --Riiga (talk) 20:02, 17 April 2023 (UTC)
• I approve this proposal. --Vincentius (talk) 20:11, 17 April 2023 (UTC)
• I approve this proposal. --Mathiash98 (talk) 21:43, 17 April 2023 (UTC)
• I oppose this proposal. Same as @Marc marc:. We cannot simply change a tag that is used so widely. Here a relation makes much more sense than a redefinition and thus a destruction of currently used usages for data users. The OSM data are partly very important. --SafetyIng (talk) 21:58, 17 April 2023 (UTC)
• I approve this proposal. Very well discussed, especially on the new community forum. This change brings the clarity we need in OSM before EV Charge Points start to be deployed in significant numbers (what we have now may seem a lot but is tiny compared with what is coming - hence the immediate need to approve this proposal before the mass installations). --RobJN (talk) 23:02, 17 April 2023 (UTC)
• I approve this proposal. --Gazer75 (talk) 04:45, 18 April 2023 (UTC)
• I oppose this proposal. Same as @Marc marc:.User 5359 (talk) 04:59, 18 April 2023 (UTC)
• I approve this proposal. I think this proposal clarifies the tag rather than changes it --Leojth (talk) 17:44, 18 April 2023 (UTC)
• I approve this proposal. I think this allows better incremental detail. --Gnesss (talk) 18:26, 18 April 2023 (UTC)
• I approve this proposal. This is such a minimal change to amenity=charging_station it hardly counts as a redefinition --Spiffy (talk) 19:30, 18 April 2023 (UTC)
• I approve this proposal. Gets rid of the ambiguity. The old uses are easy to identify and migrate to the new tagging scheme. There was ample discussion in the community forum and the most important questions were addressed, and suggestions taken on board by the proposal author. --Osmuser63783 (talk) 06:51, 19 April 2023 (UTC)
• I approve this proposal. --Hidoo (talk) 12:25, 19 April 2023 (UTC)
• I approve this proposal. Good change --Tjuro (talk) 18:36, 19 April 2023 (UTC)
• I approve this proposal. I agree with @Spiffy: --Shaun das Schaf (talk) 10:22, 20 April 2023 (UTC)
• I approve this proposal. --scai (talk) 06:16, 24 April 2023 (UTC)
• I oppose this proposal. I think the voting here is a bit premature, as there are unresolved issues in the discussion. More thought needs to be given to data users / conflation, being more explicit in how the new tagging works, and how we will transition to any new tags. --Rjw62 (talk) 07:55, 24 April 2023 (UTC)
• I approve this proposal. --501ghost (talk) 21:43, 25 April 2023 (UTC)

• I approve this proposal. --Msiipola (talk) 09:09, 26 April 2023 (UTC)