What exactly are you having trouble with?
You can map the different sockets with the socket:= and socket::output=* kWh for the power of individual chargers
If you have to span a cable across another parking space, I’d ignore that you theoretically could charge 3 vehicles at the same time and map it as capacity=2
How could I add the EVSE ref for each output ? Each output could contains multiple socket.
By output you mean individual charging columns like in the picture?
With the new scheme you simply map an area around all the chargers with amenity=charging_station and each charger as man_made=charge_point.
EVSE ref you can map to the charge_point.
I haven’t mapped EVSE ref to individual sockets yet but you could probably do so by inventing socket:type2:ref:EU:EVSE=*
Hello
According to ref:EU:EVSE wiki page, sockets don’t have any refs.
And it’s done on purpose: charge points can have one or more sockets but only one is usable at a given moment.
socket:type2:ref:EVSE fails for stations with several charge point with the same socket type.
I’ll add that mapping individual charge points on appropriate features is useful for dynamic data mapping, with charge point state and availability. OSM will be more used if we able to do so.
You a e right technically the ref is depending on internals of the charger as far as I understand. But from what I have seen in the wild, charging columns can have a individual ref for each socket (probably because the sockets are internally seperate units).
The socket ref of course can not be applied to amenity=charging_station but only to man_made=charge_point
We should always check that.
It’s not because the ref is shown beside the socket that it’s the socket’s ref.
It’s the charge point ref most of the time.
A charge point with one socket remains an independent charge point, it can’t be merged with its single socket.
As I pointed out in the discussion that led to vote on man_made=charging_point the piece of equipment the cable or socket is connected to is nearly never a “charger”.
In the case of AC charging the charger is in the vehicle, in the case of DC (fast) charging the charger tends to be big equipment off to the side that is connected via bus bars to the outlets. With other words there are lots of different topologies possible and I would expect that a sensible reference number would refer to groups of connectors that cannot be used at the same time.
I would expect that a sensible reference number would refer to groups of connectors that cannot be used at the same time.
Yes, it’s the charge point reference, grouping one or more sockets.
Well, I have the impression that not everyone understands the same thing under the term “charge_point”. Let’s check it out:
What do you think “charge_point” means (as described in the wiki)?
With a 62%/38% result on the poll, I think we have a problem : The wiki page need some better explanation. Isn’t it ?
man_made=charge_point was described as a physical stall. A physical stall is usual easy to identify and relate to.
Most of the B)'s I have seen are also A), and the reverse cases are often the same as well, so that may explain the confusing result.
The ref:EU:EVSE identifier, as provided by operators for example under the Open Charge Point Interface (OCPI), refers to individual EVSE devices. There is often more than one EVSE in each physical stall (usually one per socket), which means that there could be more than one identifier per charge_point. This is indicated by the multiple ref’s per charge point, separated by semicolon, in the wiki example.
The proposal did not discuss the ref:EU:EVSE tag. I think it would be consistent to tag multiple EVSE identifiers on a physical charge point using semicolon.
I do not think we could achieve a full dynamic mapping/description of available output power in OSM. For example, automatic load balancing at the site would depend on the number of cars connected as well as on the input capacity of each individual car. Also, some sockets are often out of service. Correct, updated pricing is also challenging. An advanced app would instead get real-time/dynamic data through OCPI and fetch just the more detailed coordinates of charge stations or charge points from OSM. Also, detailed mapping in OSM of highways leading to the charging stations would be helpful, as “last meters” mapping over parking lots often is not available from other sources.
What’s “stall” in german? The integrated translator says stillstand.
Bucht / Box / Stand (Ausstellung) etc
I’m fairly sure that originally it is the same word (aka stable).
Thanks for your answer.
So man_made=charge_point isn’t the charge point in emi3/Opendata. That’s a little confusing.
Summary:
There’s lots of differing standards out there, so we can’t match them all 
emi3 is the only standard I know. Opendata in EU use this standard. So no, that’s not a lot 
Regarding your question mark at level 3 in the figure: I believe there is a 1:1 relation between EVSE and “socket” in OSM. At least that is the case among thousands of EVSE identifiers available through OCPI in my country.
How could you get a 1:1 relation when you can have multiple sockets for one EVSE, and several EVSE on a single level 2 (man_made=charge_point / charging station / stall).
Real exemples :
Example from the wiki:
How do you link the ref and the socket to know which socket is in use or out of service ?
There is no link between the ref and the socket in OSM. The link would be in the app from the operator.
I think it would be too complicated to map EVSEs in OSM. Most users would not be able to establish how many and which EVSEs are contained in a stall. I think it is sufficient to map which refs are handled by each physical stall. Personally I do not map stalls at all, just one node for the site.
