Some countries are planning to multiply by 10 the number of stalls in the next 5 years and we are far from being exhaustive on the existing data, even in the open data about this.
Following the topic about the confusion around what is a charging_station (a totem or a pool of totems?), it is a good time to build a discussion about how to make things evolve to a more eloquent tagging scheme on this topic.
There is an European standard that describes things like this:
a pool, contains stations (= stall, totem), contains point (group of sockets), contains socket.
We do not necessarily have to think of each level as a different object in OSM, some of these concepts could be tags or relations. Currently, there is no OSM description of a group of sockets for example.
I also think saying “point” for something that is a group of socket is misleading. There is a group of suggestions in the end of this post to make the… point.
Open data mentions unique identifiers for pools and stalls in EU. These could be used as a relation link, but we can also do things to build relations between objects.
The most useful data to guide electric vehicle car owners is the higher level, the pool, which should be placed as a point or an area, centered in the zone where stalls are.
We might keep the amenity key for this higher level, but many people do not think of “station” as a pool but as a stall, which results in bad representation and wrong capacity measures.
We may consider having an explicit top level key that mentions “pool” and use it as a summary of the lower levels of details. There are already tags like this to summarize things like the maximum power delivered at for the most powerful stall.
To specify the maximum output of the entire station: charging_station:output=<xxx> kW
So to make things more clear i suggest to modify the tagging scheme like this with a category kind of key around charging_station, bringing clarity on the value side. Each of these are not necessary different objects:
- instead of amenity=charging_station we should use charging_station=pool because amenity is also a “put everything here” kind of key. Could be node, polygon, or relation, but i would prefer to use a node. During transition we can keep both tags. It would remain the higher abstraction of the concept of what is a charging station and keep the description of what kind of things we can find in the pool, placed in the center of the area where stalls are.
- charging_station=stall for the totem part detailing if there is a cable, counting the outlets and if we can use several at once. Node.
- charging_station=price_board for the totem displaying prices. Yup, this is a new thing. Node or polygon.
- charging_station=terminal for the part with a screen or keyboard to interact with subscription cards.
- charging_station:socket_groups=socket1+socket2;socket3 would enumerate the sockets linked on a side of one stall. it could be added on a stall.
- charging_station:socket:= being the smallest object physically of all the levels, it would be hard to map. then comes the decision to choose where to define the data of outlets and if we should repeat some of it at the higher level to ease reuse, or count on relations and references id linked on things to gain in precision.
- charging_station:battery_swap=yes, waiting for more of this kind, this would be a starting point.
That is just an opening, feel free to add ideas.