It differs because it is a tag that clearly states “this is an individual charge point”. As noted above the current tag fails to be clear as to whether it is one charge point or a site of many charge points.
And, yes, it should be used with the existing amenity tag.
I know this is not ideal, but as noted, the EV tag scheme was put in place before we really knew what the future of EV charging looks like. We do now, and therefore should look to improve the tag schema before too long.
@NKA, thanks for trying to summarize, that is useful!
To me, that actually seems like the simplest solution (except for doing nothing). It requires no retagging, and I think it would make life easier for map makers like @SomeoneElse(?). However, I still don’t understand what this site concept is… I mean, standing in front of a number of plugs/socket (already mapped as charging_station/charge_point/…), how would I know if I should add a site (relation/node/way)?
Has already been proposed way back in 2013: Proposal:Charging place - OpenStreetMap Wiki.
This looks to me like the current (mixed) usage of charging_station, but with a hard split (to charge_point) somewhere in the spectrum from site to socket… I would prefer to just continue using charging_station for the full spectrum (and maybe add a new aggregating site feature as said above).
Some possible drawbacks/questions to this suggestion:
charge_point/charging_station. How to decide if some physical feature is to be mapped as one or the other? If charging_station can be used for “one … charge point” it seems to me there is ambiguity…charging_station is needed, and I guess redefinition is to be avoided at some fairly high cost (though I appreciate @RobJN’s point about many more future objects to be mapped) .So an individual charger would need both tags? That implies re-tagging a couple of 10’000 objects.
And those 50’000 lamp post sockets would need both too.
It’s an optional extra tag, so no.
But let’s not fool ourselves; there are endless places in OSM where optional additional tags are required to convey some (important) additional information. This is precisely one case. Where there are locations like the Gridserve example, it is useful for data users to be able to get from OSM data that “this is a location with multiple chargers”. It’s no different to how our competitors do it and it is no different to how live open data will be made available.
Do you have an alternative workable solution?
The question is what you actually want.
If you want to have some form of “automatic” summary then we need a new tagging for charging sites that one way or the other can model a hierarchy (note that man_made=charging_point does not do that).
If you just want to be able to differentiate if the object in question models a site or an individual “charge_point” then a tag that adds a charge_point count to the tagging is the trivial (and already suggested) option.
Here is a file with all charging stations in OSM with groups of chargers indicated: link.
Purely for illustration, charging stations closer to each other than 20 meters have been grouped together and retagged to man_made=charge_point, and a new node with amenity=charging_station has been generated to represent the group. The number of charge points in each group is provided in a (not to be used) GROUP tag, which is searchable.
Please note this is not intended for uploading. This is just a rough indication of candidates for man_made=charge_point, and there are several mistakes.
I want to be able to map sites like the Gridserve one. It has multiple charge points with different capabilities (a mixture of sockets, AC/DC and charge speeds). A simple charge_point tag won’t cover this detail. This detail is important as there is little point turning up to the site going to get a 350kW change to find that only a slow 50kW charger is available!
Perhaps you can send me file showing how you’d map the site.
P.s. if you don’t believe these sort of sites are worth being able to map, then we are not even agreed on step 1.
From the picture you posted I estimate that this site has about 10 devices/cabinets. Would adding 10 amenity=charging_station nodes, each having appropriate socket/output/payment tags not be sufficient? That would allow consumers to search for and find chargers having e.g. type2_combo with output>=350 kW… What is missing in this approach in your opinion?
This approach has the issue that duplicates will show up in search results, etc. Also, tags that apply for the whole station, not just one charge point, will have to be repeated many times, because there is no feature type for a whole charging site/station.
I guess they are not really duplicates insofar as there really does exist 10 devices… Nonetheless, I agree that presenting too many (10?) equally valid result to a user is not great, but is that not more an issue with the search user interface than with the data model?
Out of genuine curiosity, what tags would that be? I can think of operator, but in some cases several operators will be present next to each other[1], so it’s not so clear to me that repeating the same value (where appropriate) is wasted; it actually provides information that all these devices are from the same operator=X.
Anyway, both of these annoyances could probably be helped by introducing a site relation (or encompassing way), I think?
[1] I suspect this is even encouraged here in Denmark, to increase competition.
@SimonPoole: Would you use a site relation to establish the relationship between the site and the charging points on it? Or something else?
I think charge_station should represent the equivalent of a fuel pump. Like a fuel pump, it can have 1 or more customer facing displays each with thier own set of fuel types and/or methods. The electric version could be charge points.
Each point should be mapped as nodes on the area representing the charge_station (like street furniture) that they are apart of. Charge stations with one charge point can mapped as node. The charge point can be omitted it and all of its tags can be add directly the charge station node because we can assume that at least one exists. This should simplify adding of new and previously mapped stations with one charge point.
Maybe worth pointing out this Norwegian (and potentially Nordic) import effort (I at least wasn’t aware of it until just now). @NKA, I suspect you know something about this, are there any lessons learned that might be useful for the current discussion?
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Nordic_Charging_Station_Import
Let’s list our intended goals for the tagging scheme so we can discuss them systematically:
Due to (1), we are limited in what changes we can make to amenity=charging_station. At a minimum, socket:*=* tags need to stay on the amenity=charging_station object.
Current situation:
amenity=charging_station is used for both individual devices (multiple nodes in close proximity in a single site) and charging sites (one node/area for multiple devices). In a lot of cases there is only one charging device at a site, so a single amenity=charging_station node represents both a device and a site.
Options:
a) No dedicated tagging for devices and sites. Use amenity=charging_station for both with a subtag for differentiation.
b) Create a new tag for devices, use amenity=charging_station for sites.
amenity=charging_station for individual devices would be misinterpreted as sites. Requires re-checking of currently existing objects to prevent misinterpretation. Non-incremental upgrade path.amenity=charging_station site object.c) Create a new tag for sites, use amenity=charging_station for individual devices.
amenity=charging_station object. No tag duplication on site required for backward compatibility.amenity=charging_station objects in close proximity into a site.amenity=charging_station for sites would be misinterpreted as devices. Requires re-checking of currently existing objects to prevent misinterpretation. Non-incremental upgrade path. (But: + current objects with socket information are still semantically useful and backward compatible, even if the number of physical devices is not correctly represented)d) Create a new tag for sites, treat amenity=charging_station as ambiguous (current situation) unless it it is part of an explicit site (which indicates it’s a device) or has a tag that clarifies that it’s a physical device.
amenity=charging_station object. No tag duplication on site required for backward compatibility.amenity=charging_station. Not ideal but it works.)This would be my personal preferred option.
This is the way.
Maybe, only maybe, we should add a goal of being able to link with online status information?
I see the drawbacks of option b) as a dealbreaker unfortunately. Especially since it will always require tag duplication on both sites and individual devices, which is a surefire way to get incorrect and outdated information. Option c) mostly avoids that problem and allows for more detailed tagging while remaining backwards compatible.
I see option c) as a workable solution in an ‘ideal’ world, but realistically we will likely have to do something like option d) or a mixture thereof.
I think that’s an easy add-on after we’ve figured out the device/site situation. I don’t see it having an impact on that discussion.
To describe the physical appearance/construction/shape/type of a charging station device, I propose using a tag like charging_station=*
charging_station=pillar/column
Image by Lichterfelder
charging_station=wall_mounted
Image by Dr Kludge
Ideally with a descriptive namespace instead of just raw charging_station=*:
charging_station:<type/appearance/construction/shape>=*
If you have an idea for better wording instead of just ‘type’ or have other examples or examples of similar tagging schemes, please share.
Here are a few observations from the import of over 2000 charging stations in Norway since 2018 and onwards:
capacity tag has often been determined by the number of market parking places in front of the charge points and the socket tag has been used to indicate the number of different socket types available at the site.