Term for the charge point (not the UK/OSM one, the other)

Help and support Tagging help & support
1

A previous proposal established man_made=charge_point for the terminal/device/unit used to charge an EV (UK term).
Unfortunately, in the rest of the world, including in the documentation, the point does not represent the terminal/device/unit but the set of cables or socket or induction coil intended for a single vehicle.
A terminal/device/unit can therefore have several ‘points’, often between 1 and 4.
Is there a UK term to describe the not-uk point ?
Is there a term that could be unambiguous worldwide?
This would allow to have a ref: to put the refs that are sometimes incorrectly put in other keys.

ex Node: ‪FRFR1EBYBZ FRFR1ECSZW FRFR1EFSVZ FRFR1EPCKC FRFR1EPRKX FRFR1EQCGT FRFR1ESCMD FRFR1ETUQM FRFR1EFYGB FRFR1EEBEA FRFR1EATVB FRFR1EBNMJ‬ (‪11109170821‬) | OpenStreetMap
ref:EU:EVSE is correctly set with the station ref.
ref is wrongly set : it’s not the local/ground ref of the station, it’s all ref of all slots of all devices.
I had initially thought of ref:socket, but this is not the reference for sockets. If a terminal/device/unit is multi-standard (e.g. Chademo + Combo CCS + Type 2), there is a single European ref xxxxxE for the 3 cables/sockets
a terminal/device/unit with capacity=2 have 2 ref for those 2 “not-uk points”.

ref<…>:slot ?could be confused with the local number of parkign space
ref<…>:individual_charging_output/capacity/slot ? very long
ref<…>:EVSE ? EVSE is the correct term in EU and maybe elsewhere but with the prefix ref:EU:EVSE:EVSE is a tautology

E-Auto-Ladesäule - welche Angaben zum Taggen finde ich vor Ort?
2

I think you mean EVSE but we don’t map these in OSM as they are not a physical thing. Instead they represent the internal logic of the charger:

Electric Vehicle Supply Equipment (EVSE) refers to the part of a man_made=charge_point that controls the supply of electricity to a single electric vehicle (EV). The EVSE handles the charging process of one EV at a time. An EVSE may have one or several connectors (sockets/plugs) but only one connector can be used at the same time.

ref:EU:EVSE as a tag is not consistently used in OSM. Sometimes a “Pool ID” is put in it, other times a “Station ID” and other times an “EVSE ID”.

In the case you linked to a “Pool ID” has been put in this tag. It looks like the set of EVSE IDs at this location have all been put in the ref tag.

One option, if you can, is to work out which EVSE ID(s) belong to each man_made=charge_point and put those tags there.

See Key:ref:EU:EVSE - OpenStreetMap Wiki

P.s. I am not sure what you mean by “non-UK”. If you mean not United Kingdom then you may be getting confused by the presence of “EU” in ref:EU:EVSE. From the research I have done it has nothing to do with the official bodies of the EU. The schema was developed by the ISO and eMI3 industry groups. The EU has subsequently set up the governance around who creates the operator IDs used within the EVSE ID (FR1 for Freshmile in your example) but it’s not limited to EU and other countries participate in the use of the ISO/eMI3 standard/schema too. The UK was still a member of the EU when they did their bit for Operator ID assignment. This is all documented on the above wiki page.

3

To make things even more complicated in the Open Charge Point Interface protocol (developed by the industry) felt the need to introduce the EVSE.uid as they want a unique identifier that can never be re-used. In comparison, the eMI3 (and IDACS) EVSE ID relates to the physical hardware so could be re-used if that hardware is moved from one location to another.

OCPI is all about data sharing between operators and is what the United Kingdom stipulated must be used when they extended previous regulation (that has been adopted while a member of the EU regulations) to force charge point operators to publish more open data that the previous EU regulations required.

See Open Charge Point Interface - OpenStreetMap Wiki

1 Like
4

EVSE ref exist on sign on terminal/device/unit, and everybody is able to see how many vehicles can be charged simultaneously, we map it with capacity=*, so the argument “not a physical thing” is flawed.
it’s maybe the 2nd most important thing (if you can’t charge, helpdesk often ask the EVSE id to reboot the correct slot).
that’s also the id used in severals app to start the charging, sometime with a short version (only the last digit or last 2 digits).

the root issue is not “no consistently”, the issue is that osm don’t have the dedicated objet to put the tag, nor a suffix to add it to another objet.
ref:EU:EVSE on a amenity=charging_station is about the station (xxxxxP)
ref:EU:EVSE on a man_made=charge_point has no clear meaning because no european ref exist for a terminal/device/unit.
ref:EU:EVSE with xxxxxE on a slot/EVSE ? osm doesn’t have a standardised objet for that, it’s why I ask what correct term could be used to add a sufix on a amenity=charging or man_made=charge_point

by “not-uk” term, I would like to point out that in English word “point” does not mean the same thing as in the rest of the world.
As osm used the UK meaning of “point” to define man_made=charge_point, we can’t use “:point” as suffix to describe the ref of the point in the same sense as this word is used in the rest of the world.
Specifically, which tag should be used to indicate ref xxxxxE?

5

I’d also consider the slot namespace as a prefix, i.e. use slot:ref:EU:EVSE. The content should then be a ; (semicolon) separated list.

This key could exist either on the amenity=charging_station to include all slots available at that station; or on the man_made=charge_point to include all slots available at that charge point.

Using the suffix reads to me as if it was a part of the EVSE for the station, which I believe isn’t what is meant.

6

Says who? There is a schema for EVSE IDs that happens to be similar to a schema for Pool ID and Station ID. The former is compulsory while the later two are optional and may go away. I already see a lot of charge point companies not using it and instead using the OCPI standard as their guidance for giving stations/pools an identifier.

A quote from the wiki page:

While in the EU an EVSE must have an [EVSE] ID, for Pools and Stations it is up to the owners/operators to decide whether to assign an ID.

So basically in my mind ref:EU:EVSE is best used for the EVSE ID and can be added to either amenity=charging_station or man_made=charge_point as a semicolon separated list.

If you want to record the Pool ID then make up a new tag. As noted in my earlier reply the schema is actually from ISO/eMI3 not the EU so maybe ref:eMI3:POOL_ID is better.

P.s. I still don’t get the non-UK part of this thread. In English “point” can have many meanings. One of those is “a particular spot, place, or position in an area or on a map, object, or surface”. That is all that is mean here. Perhaps a better word could have been selected to cause less confusion for non English native speakers but probably too late to change that now. Thankfully translations can be used in the wiki and on some editors.

7

In summary:

  • we have problems here as we started mapping something that was still in its infancy and has changed quickly.
  • ref:EU:EVSE is a bad tag as people are using it to record one of three different IDs which is madness.
  • Two of those IDs are not even compulsory in the only location (EU and participating countries) that have in some way integrated the ISO/eMI3 standard.
  • And the one that is compulsory (the EVSE ID) has turned out to be sufficiently flawed that the automotive and charging industry is now recommending something different in their own OCPI standard.

So my recommendation is to not loose sleep over this. Map the EVSE ID and ignore the Pool and Station ID (or create a new tag specifically for them if that is what you want)

8

The question is not whether this information is interesting to you or not, or whether you think another standard is more interesting or not.
The question is where to put one or more EVSE slot ID when it is found by survey.

1 Like
9

An image says more than a thousand words. Do you have an image where the slot ID can be found?

10

If by “Slot ID” you mean the EVSE ID then you put it in the ref:EU:EVSE tag on the man_made=charge_point object. Use semicolon separator if there is more than 1.

11

bad quality sorry https://community-photos.pools.cdn.chargemap.com/840x560/2025-02-18_100104_600_392914.png
we can guess the ref CHxxxE at the bottom center of the image below the station reference

12

I mean the EVSE slot ID (not the station one)

see the 1st message, the osm object is a station and therefore the ref:EU:EVSE is already used by the EVSE id of the station. which is why I think a suffix is needed to clarify that it is not a reference to another object linked to this one but absent from OSM.

13

Only if you think that tag should be used for the Station ID which I don’t. But even if you do, why not just add it in the same tag semicolon separated? So you put a “S” and one or more “E” values in the tag. Any data consumer can then simply parse the bit they want.

14

Put it on the slot object since that’s the slot reference? … Well, no, the slot doesn’t exist in OSM.
So inevitably, it has to be put in the parent object.
We do the same thing with socket:*, which describe the fourth level and yet are entered en masse as a characteristic of stations.

With your logic, we could put the number of sockets:* in capacity separated by semicolons.
OSM has adopted the namespace principle when two values represent two different levels of information.

15

Well tell the person who created ref:EU:EVSE and defined it to allow the user to put one of 3 different IDs in it!

I think the problem here is that you are too fixated on the Station + Pool + EVSE (+ Socket) hierarchy that was developed by eMI3 years ago. The industry has moved on from this and I think OSM should too.

We know that the industry has moved on because (A) the only one of those IDs that was made compulsory by the EU was the EVSE “Slot” ID. And (B) the industry went on to develop the OCPI standard which only has “Location” and “EVSE” (slot), thereby dropping one level in the hierarchy.

So my tagging recommendation:

  1. If the operator has a ref for the whole location (regardless of whether this follows the old eMI3 format or not) put it in the ref tag of amenity=charging_station.
  2. If the operator has a ref for the physical stand (regardless of whether this follows the old eMI3 format or not) then put it in the ref tag of the man_made=charge_point
  3. Put the EVSE “slot” IDs in the ref:EU:EVSE tag on the man_made object.
3 Likes
16

By the way “charge point” is defined in OCPI for exactly what we use it for in OSM. Again reinforcing my point that OSM needs to move on from the fixation that the eMI3 hierarchy is the definitive hierarchy and terminology. It is not!

1 Like
17

In Greece a station has these tags on the national registry

The charging station has it’s own ID.

"id":  "GR-PPC-Scs34702-L",

I use ref:GR:IDRO tag for that. It only goes to the amenity=charging_station

ref:GR:IDRO = GR-PPC-Scs34702-L

If the operator has it’s own ref, then i also include a “ref” tag. It’s not the same as the station registry id.

Then, each socket has it’s own EVSE record. This is strait from the registry and also, the providers use these EVSE ID’s when reffering to each socket in their apps, in the stickers on the sockets etc.

"evse_id":  "GR*PPC*E0002000672*1",
"evse_id":  "GR*PPC*E0002000672*2",

The easy thing to do is include these on the amenity=charging_station without making each man_made=charge_point. In that case i include the EVSE’s like

ref:EU:EVSE = GR*PPC*E0002000672*1;GR*PPC*E0002000672*2

If i want to make the man_made=charge_point stalls, i will designate each one with the EVSE’s on that stall. It can have 2 or even 3 sockets (ie, Type2 and 2x CCS2) so it will have 3 EVSE:ID’s like above.

I don’t have the time to do charge_point mapping, i only do a single POI for charging_station with all the info.
If some other mapper has the charge_point’s then i fill in the EVSE’s. Like this example.

I agree that we need to make a universal template for better mapping. My current goal is first to include all the actual officially working stations on Greece and maybe refine the data at a later stage.

2 Likes
18

I think the main issue is not at this level but by not having the 3th level in osm and therefore not objet to put the ref without a namespace.

Maybe in UK, but this is factually wrong in UE.
In France, for example, the standard requires two IDs (station and slot), i.e., exactly the same number of levels and the same objects as OCPI.
In Swiss 2 id, the same. Despite being outside Europe, the European format is used for slots, making roaming easier.
However, even though I was also in favor of OSM following the standard in the previous proposal instead of trying to fit a square into a circle, all this crusading to show the supposed superiority of one standard over another makes no sense : putting 2 id of 2 levels of info into one key is not a good idea.
for ex we have name and name:bridge and not putting name=name1;name2 when a highway is on a bridge, to describe precisely what the value refers to, rather than leaving the data user to guess.
The other incomprehensible aspect of your request to switch to another standard is that the field sometimes provides the EVSE reference.
It’s not OSM that’s going to change the signs on the ground.
But I’m happy for you to open another topic to discuss standards and how you’re going to fit a square into a circle with two references of different levels in a single key.

19

Yes, that’s true.

I believe you mean Key:bridge:name - OpenStreetMap Wiki? Of course the best solution is to map the bridge separately, but yes, doing it like that is much better than list.

The ref for the station is quite simple:

amenity=charging_station
ref:EU:EVSE=xxxxxP

If we had a separate man_made=charge_point, then Tag:man_made=charge_point - OpenStreetMap Wiki recommends using the ref:EU:EVSE tag with a list of all EVSEs at that charge point.
If we only have a charging station, I’d tag it with charge_point:ref:EU:EVSE, so if later on, someone wants to map the charge points, they can just copy that info from there.

20

You are actually agreeing with me here then. That is to say that a 3-teir hierarchy, as per the old eMI3 standard, is NOT required.

By the way, I actually read the EU regulations and all they say is:

(b)further static data for publicly accessible recharging points operated by them:(i)ID codes, at least of the recharging point operator,

They don’t specify that these need to follow the Emi3 schema. They do reference back to the IDACS working group outputs though which does state that the eMI3 standard should be used for the EVSE ID (the one with the letter “E” in it)

Now, for those that don’t know, each EU member state have to then “transpose” these into their own national law. When doing so they can add more than the minimum requirement set out in the EU regulations text. France may have been more prescriptive and forced a 2 teir system following the eMI3 schema (I don’t know as I haven’t looked).

The only ID the EU regulations seems to require in the EMI3 schema is the EVSE one with the letter “E” in it.