Proposal:EV Charging Station Mapping
The Feature Page for the approved proposal EV Charging Station Mapping is located at Tag:amenity=charging_station |
The Feature Page for the approved proposal EV Charging Station Mapping is located at Tag:man_made=charge_point |
EV Charging Station Mapping | |
---|---|
Proposal status: | Approved (active) |
Proposed by: | NKA, based on draft by Jmarchon |
Tagging: | amenity=charging_station man_made=charge_point
|
Applies to: | node ![]() ![]() |
Definition: | clarifications on how to map and tag amenity=charging_station and adding a new optional feature man_made=charge_point
|
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 havecapacity=1
, 31,952 havecapacity=2
and 14,273 havecapacity=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 allman_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:
- 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. - 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 tagamenity=charging_station
must be used. That is to say thatman_made=charge_point
does not replaceamenity=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. - 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 exampleMultipolygon example.
- Where a new
amenity=charging_station
area is added around several existing charge points which are currently mapped as individualamenity=charging_station
then those elements within the area should always be changed toman_made=charge_point
. - 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 onamenity=charging_station
and do not need to be repeated on eachman_made=charge_point
. Also, if the socket information is the same for all charge points, it may be tagged onamenity=charging_station
only to avoid inconsistency.
- An
The tables below provide an overview and comments for the most important keys of the two features.
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. |
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 |
Main feature:
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:
| |
Optional charge point 2:
| |
Optional charge point 3:
| |
![]() |
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 Recharge McDonalds Rygge Ionity 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.
Comments
Please comment on the discussion page, grouped by topic.
Voting
Voting on this proposal has been closed.
It was approved with 25 votes for, 5 votes against and 1 abstention.
1 unsigned vote not counted.
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". Atamenity=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 bysocket:*=*
egsocket:type2=*
vssocket:type2_cable=*
.man_made=*
should be used for the structure, similar topower=transformer
in, orpower=substation
as aman_made=street_cabinet
.man_made=*
itself is a problem of bloat and poor connotations that can be solved withpower=*
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)
{{vote|yes}}—- 09:13, 26 April 2023 (UTC) —Preceding unsigned comment added by Skinfaxi (talk • contribs) 09:13, 26 April 2023 [this was added in Special:Diff/2509430]