then you can use level info (if such distinction between levels even matters)
Still, what’s the harm in keeping site relations as an approved alternate way of mapping charging stations when a node or area won’t suffice?
Multipolygons enables some flexibility in mapping a dispersed group of charge points. Charging station multipolygon example. And unlike a site relation, it gets rendered. I do not have a strong opinion on site relations, though.
How would this be possible?
Level is not part of EVSE opendata or even data.
Is there any return on experience about this?
It should be low priority now.
It should be a point addressed later, when we will have a consensus of what should be achieved.
1 Like
I would welcome that. If the proposal is accepted the wiki page for capacity:charging could then encourage people to add a charging_station and charge_points and vice versa. This would make clear that they are complementary, not competing tagging schemes.
I think anyone holding this hope will inevitably be disappointed (as pointed out above). Thus such hope should not be the basis for the chosen way of tagging. Instead, any system we choose should allow a good way of mapping individual devices.
And why wouldn’t we want to map individual chargers? They exist and are easily verified on-site or even from imagery.
It probably also means something that all the example images on Tag:amenity=charging_station - OpenStreetMap Wiki are of individual devices…
5 Likes
The proposal supports both tagging individual chargers and only tagging the location. It is entirely up to the user to decide and the proposal is not dependent on any preference and this regard. Personally, I would not tag 30 identical Tesla charge points on a location as it would create unnecessary duplicated information, but other users may think differently.
It probably also means something that all the example images on Tag:amenity=charging_station - OpenStreetMap Wiki are of individual devices…
There actually is a Tesla example at the end of the wiki table which is not an individual device (but the image is). And there clearly are several thousand non-individual locations mapped in OSM. But I agree that more examples of groups should be included on the wiki.
I will soon start the voting process for the proposal. Please let me know if there are any more comments.
1 Like
From the tagging mail list:
@Mateusz_Konieczny :
I guess that in such cases it may be possible to tag it both as
charging station and
a charge point at the same time?That’d work - it makes it clear that this is a “new”
amenity=charging_station (e.g. a “group of chargers”, even if there is
only one), not the previous “probably a single charger but we don’t
really know”.No man_made=charge_point | Tags | OpenStreetMap Taginfo
are yet mapped, so any with that tag must be the “new” schema.
@SomeoneElse: I am trying to conclude the charging station proposal and I am considering how to resolve this question. I would very much like to make the proposal as usable as possible. However, I am struggling to understand the use case here.
For my understanding, could you explain why it is important for consumers to know if an amenity=charging_station has a single charge point or multiple charge points? (beyond what can be interfered from capacity and socket tags)
I am thinking that we do not know this today either, and users may not always add an extra tag to clarify (for example double tagging with man_made=charge_point as suggested below). Is it not sufficient for map rendering and for apps to know that “this is a location for charging cars”? Additional information will be available through the other tags (capacity, sockets etc) + tags on individual charge points at the location if mapped.
If you were to know with certainty that an amenity=charging_station is either a single charge point or representing a group of charge points, how would you then use that information? And what would you do with the other “uncertain” locations?
1 Like
Let me rephrase that, in terms of petrol/diesel infrastructure - yes, I would like to be able to tell the difference between an “amenity=fuel” and a “man_made=fuel_pump”. Currently I render the former and ignore the latter (see the pumps such as this one here).
Indeed - but we currently have one of two situations (continuing the petrol analogy):
- “
amenity=fuel” mapped, but not any “man_made=fuel_pump” - Each “
man_made=fuel_pump” mapped, with no surrounding “amenity=fuel”
We don’t have a situation today where people have mapped both “amenity=fuel” and “man_made=fuel_pump” on different objects at the same site, with the same tag. If we did, we’d have to change the tagging on one of them to know which was which.
You seem to be suggesting using “amenity=charging_station” for both the equivalent of “amenity=fuel” and “man_made=fuel_pump” on different objects at the same site, which means that I wouldn’t be able to tell which was which there.
2 Likes
Actually which generation and how many of each tesla super chargers are present at a location is quite relevant, and it could be that you have 10 V2s and 10 V3s (and soon V4s), which have different power output and other characteristics that you can’t model with a single object.
2 Likes
Thank you for clarifying.
With the proposal, the idea would be that you render amenity=charging_station only and ignore man_made=charge_point, similar to your fuel example. man_made=charge_point should only be present if there also is a amenity=charging_station present.
If somebody maps a single man_made=charge_point anyway without an amenity=charging_station it will just be ignored in rendering. I would not rule out that some users would do that, for example for charging points which are not really intended for general public usage (even if the access=* tag should be used for that).
1 Like
Sure, but then they are not identical …
It is correct that you would not capture all details in such a case - you would get the maximum output only. Most Tesla Superchargers seem to be mapped in that simplified way (with only one node).
One thing that you can guarantee is that for any given thing, some OSM users will have done that. The problem is if enough of them have. 
I’d suggest adding an extra line to the first paragraph of the proposal to say that (continuing the analogy) where a new “amenity=fuel” is added around several existing “man_made=fuel_pump” (currently mapped as “amenity=charging_station”) that those “amenity=charging_station” within should always be changed to “man_made=charge_point”.
Other than that, the proposal is refreshingly detailed, especially in terms of the example.
1 Like
Done (new item 4 in the Tagging section).
2 Likes
Fantastic. It’ll get my approval. A good step in the right direction for clarity before the charge point rollout really starts to grow.
Just a quick reminder that a lot (742) of charging stations for e-cars are mapped with car=yes instead of motorcar=yes. They seem to be coming from the old tagging scheme which was changed 3 years ago in the osm wiki.