Proposal talk:EV Charging Station Mapping

Comparison

I want to know any reason of not using power=outlet for a stall as it comprises multiple sockets, To the extreme, not one will add each USB port either. Unless the exact position and facing can be added on each stall with it. However, power=* is more preferable than amenity=* in any case. man_made=* is used for man_made=fuel_pump in amenity=* fuel, not amenity=* to stay the same. --- Kovposch (talk) 05:49, 14 March 2023 (UTC)

I would say using power=outlet can be misleading in many cases where there is no outlet present, just a cord. As for man_made vs. amenity, I originally proposed man_made, but received feedback against that on the OSM World Discord.

Thank you for your feedback, Jmarchon (talk) 16:25, 14 March 2023 (UTC)

Isn't that a hidden one with a cord you can't remove? Then it's related to whether you need to bring your own charging cable. Talk:Tag:amenity=charging station#charging cable availability
It does say "outlet" not "socket". The connectability is shown with socket:*=* anyway.
What about power=* vs man_made=* ?
--- Kovposch (talk) 05:37, 15 March 2023 (UTC)

(Note that the proposal has been substantially updated after this comment.--NKA (talk) 09:10, 15 April 2023 (UTC))

There is no change that solves my issue. --- Kovposch (talk) 19:46, 17 April 2023 (UTC)

I believe power=* is used mainly for the production and transmission of electricity in the grid. man_made=* was chosen due to the analogy with man_made=fuel_pump.--NKA (talk) 20:49, 17 April 2023 (UTC)

1. power=catenary_mast is dedicated to transport. One still use the same power=* for all electrical equipment, regardless of where they are.
2. There are only ~200 man_made=fuel_pump , which isn't decisive. It is related to man_made=* features, so it could use man_made=* (if not pipeline=* ). But here it is electrical, so power=* is where it belongs.

--- Kovposch (talk) 22:11, 17 April 2023 (UTC)

power=charging_station and power=charging_point sound perfectly fine for me, even better than power=pole and power=catenary_mast Fanfouer (talk) 22:22, 17 April 2023 (UTC)

I will give a pass to amenity=charging_station , as amenity=fuel exists, and they can provide more services than merely fueling or charging in the whole facility. But this proposal is about connectors, It's already a power=outlet , which doesn't need to be limited to domestic mains socket:bs1363=* etc. --- Kovposch (talk) 22:33, 17 April 2023 (UTC)

Business objects definitions

According to past discussions, both here and on community forum, I want to make the point of existing business definitions in eMI3 standard which currently drives most of existing norms in EVSE roll out industry.
OSM should be compatible with such industrial standard as to make third party data match with our own model. It's a strong need for maintenance and OSM data accessibility.
Terms & definition are pretty well written in the Terms & definitions v1.4 document. Here are the most important points to reuse in this proposal:

• Power Outlet: A receptacle in an EVSE, into which an EV's charging connector can be plugged to allow electricity to flow.
• EVSE (Electric Vehicle Supply Equipment): is used to exchange energy between the EV and the Grid . This can be both “slow chargers”, “fast chargers” and “battery switch stations”. Even a simple plug is regarded as EVSE
• EV Charging Station: A device that contains one more more EVSEs, an HMI and other components required to provide EV charging. => It's a device.
• EVSE Pool: A set of charging stations, aggregated together due to some common property (geographic location, controller, administrative owner). In some implementations, an EV user searching for a charging station may be directed to an EVSE pool, and be able to use any charging station in the pool. => What we call a site.

We'll find several useful examples in eMI3 standard v1.0 part2, starting at page 23 with relevant situations we face in OSM.
We should take care of this in rationale chapter of this proposal if we want to make a persistant move forward with EVSE mapping. Fanfouer (talk) 18:21, 14 March 2023 (UTC)

Thank you, this is a useful reference.--NKA (talk) 09:10, 15 April 2023 (UTC)

EVSE identifiers in Europe

In Europe, we currently use ref:EU:EVSE=* to map EVSE and pools identifiers, as per eMI3 standard and 2014/94/EU regulation. Fanfouer (talk) 18:22, 14 March 2023 (UTC)

You are correct, and that would continue. The ref=* key is the shorter part of that identifier which is displayed on the device and often in the apps.--NKA (talk) 06:19, 30 March 2023 (UTC)

I think both should be added to the proposal, ref=* as got from ground and ref:EU:EVSE=* as mandatory continental regulation practice, to be used to conflate between datasets. Fanfouer (talk) 13:48, 15 April 2023 (UTC)

I agree that ref:EU:EVSE=* would be useful in Europe, but if it is to be mandatory then source data needs to be readily available. Do you know where the data may be found? And please note that I am not planning to define the use of a range of tags - the proposal is about locations vs charge points.--NKA (talk) 16:04, 15 April 2023 (UTC)

Brand, operator and network

brand=*, operator=* and network=* shouldn't be confused when it comes to describe charging stations. In regard of brand=* recommendation, Ionity would go in the operator=* which is more suitable than brand=*: Ionity not only put their name on the stations, they also operate facilities on the long run. Finally, network=* got the most interest from charging facilities users as it allows them to know which membership they are going to use to pay for a charging session. brand=* is less likely to be used there. Fanfouer (talk) 05:02, 30 March 2023 (UTC)

Thank you for bringing this up. The thing is, these features are being used differently by OSM users and local communities. In my part of the world, brand=* is used for the name of chain which the customer is dealing with, similar to supermarkets, operator=* is used for any local operator of the site, for example a local hotel or a parking garage owner, and network=* is not used because it would be similar to brand. I am not trying to tackle these questions in the proposal in order to achieve consensus on the main proposed changes. I have included a comment now in the proposal about it.--NKA (talk) 06:19, 30 March 2023 (UTC)

Link between stations and charge points

In the rationale it is stated that the proposal will Establish a relationship between the location/group of charge points and each individual charge point..
How is it done in the provided example with 1 amenity=charging_station and 3 man_made=charge_point? Fanfouer (talk) 05:08, 30 March 2023 (UTC)

You would map amenity=charging_station as a closed way around the charge points. Thank you for this note, I will try to clarify in the example.--NKA (talk) 06:19, 30 March 2023 (UTC)

Do you have any official opendata to see how this particular location is modeled please? Fanfouer (talk) 18:28, 7 April 2023 (UTC)

I do but it is not easily accessible. See the link to the import wiki below in your "Link to opendata" section. In that wiki there is a link to the source data (a JSON file + a translated OSM file). Look for id 6051 for this location--NKA (talk) 09:10, 15 April 2023 (UTC).

I've found the file, thank you. Why the id 6051 isn't part of the example in this proposal then? Fanfouer (talk) 13:31, 15 April 2023 (UTC)

I believe a different dataset was the source of this particular station.--NKA (talk) 16:04, 15 April 2023 (UTC)

References aren't a particular dataset matter, as they are links between datasets. Furthermore, several region in the world force a particular kind of reference for interoperability sake and it's a crucial point in OSM too. We need to understand why id 6051 wasn't mentioned in the dataset you use to build the example. Fanfouer (talk) 13:27, 17 April 2023 (UTC)

This proposal never intended to deal with references to certain regional datasets, so I did not want to confuse the examples with such references. It is primarily about the hierarchy between a location and the charge points on that location.--NKA (talk) 17:56, 17 April 2023 (UTC)

This proposal introduces an additional level to map EVSE infrastructure and thus implicitly deal with references. References are part of the hierarchy you intend to describe. Precisely because they are mostly read from ground or opendata and they reinforce the verifiability principle. Fanfouer (talk) 19:57, 17 April 2023 (UTC)

Charge point confusion

Resolved

Regarding references lists, the proposal states Some charge points have one reference number for each socket, which may be tagged with a semicolon, for example "2126A;2126B". and it's confusing.
A more accurate sentence would be The stations always have one reference number for each charge point, which may be tagged with a semicolon, for example "2126A;2126B"..
The sockets don't have references, only the charge points do. When you add capacity=2 + ref=2126A;2126B it means you merge two charge points on the same node, it doesn't deal with sockets at all. Fanfouer (talk) 05:13, 30 March 2023 (UTC)

Thank you, you are right. Now clarified in the text.--NKA (talk) 06:19, 30 March 2023 (UTC)

Add other examples

Some people will not read everything but look at the pictures/examples. Could you add at least a "lonely charge point" example and maybe a multipolygon also? Nielkrokodil (talk) 06:20, 30 March 2023 (UTC)

Good point. I will look for more examples. I have added a link to a multipolygon example in the text now. "Lonely" charge points will be untouched (no changes from current mapping).--NKA (talk) 16:19, 30 March 2023 (UTC)

Ideally, captured map images may be nice (will not change unlike links to leave map data) or schematic image of typical situation like https://wiki.openstreetmap.org/wiki/File:Amenity_school_usage_example_single_school_-_Proposal.svg Mateusz Konieczny (talk) 16:54, 30 March 2023 (UTC)

Also ways

Around where I live charge points are usually set up in groups of 3 or 4 on the sidewalk along a road. It would be more natural to put the charging_station tags on a way than a node or an area. Elgaard (talk) 10:02, 30 March 2023 (UTC)

I also see several of those along streets. Of the 90.000 charging stations in OSM, however, there are only 62 which have been mapped as a node belonging to a highway, and zero which have been tagged on a highway.--NKA (talk) 16:25, 30 March 2023 (UTC)

Capacity

Does the capacity for charging stations refer to the number of sockets or the number of parking spots? In the given example, the capacity for the charging station shows a value of 5 adding all sockets of each charging point, but there are only 3 parking spots for charging. So I guess the actual capacity should be 3. Kjon (talk) 09:52, 31 March 2023 (UTC)

In the given example, you will see 5 market parking spots if you look up the aerial, but only 3 got into the more narrow picture. In general, it is very hard to determine exactly how many cars may be charged at the same time, even when standing at the location, because it depends on the charge point device used, the internal configuration of that device and the version of it. In the example, the middle charge point is capable of charging only 1 car at a time, while the right charge point may charge two cars at a time. capacity=* should denote the number of cars at the location which may be charged at the same time, but because this may be hard to determine, I often have to resort to let it denote the number of available parking spots. The number of sockets is just a count of that socket type at the location.--NKA (talk) 10:24, 31 March 2023 (UTC)

Link to opendata

It's not mandatory but it could be interesting to provide examples with official opendata to show how OSM data is equivalent to operator's data.
Particularly in Europe, opendata is mandatory in regard of every publicly reachable charging station. Fanfouer (talk) 18:33, 7 April 2023 (UTC)

Here is the open data source and translation I have used for the Nordic countries: Import/Catalogue/Nordic_Charging_Station_Import. All charging stations were imported at the location level (one node per group of charge points).--NKA (talk) 09:10, 15 April 2023 (UTC)

In the import script, I wasn't able to find out what was the location aggregation criteria. Was it an id or geographical coordinates? What if several stations are found at the same place?

In the Nobil source, the location (site) is the main record with a unique id. Each id has one coordinate point. Each id has one or more charge points at the next level. The script generates one node per location/id. If there are more than one brand at a location it will have a separate id, and it will get a separate node in OSM.--NKA (talk) 16:04, 15 April 2023 (UTC)

Does it mean that several brands on the same site will lead to overlapping nodes in OSM? The site should have only one brand (operator), right? Two brands/operators should lead to two sites with different coordinates, shouldn't you? Fanfouer (talk) 13:35, 17 April 2023 (UTC)

Example 1 (Vigra) only has one brand. The new example 2 (Rygge) shows a case with 4 different brands, but they are mapped separately and are not overlapping.--NKA (talk) 17:56, 17 April 2023 (UTC)

Regarding this import in Nordic area, how will we able to conflate again OSM data and further release of Nobil database? It's a key point regarding such a developing infrastructure. Stations and charge points will appear and disappear. Too much of original records aggregation could prevent such a conflation in the future. Fanfouer (talk) 13:41, 15 April 2023 (UTC)

I use a separate script, update2osm to update existing objects (in this case stations) and to discover new or closed objects. This script is being used for updating many kinds of datasets (schools, retail stores, toll stations etc). In reality I have done that per brand to get a more manageable size.--NKA (talk) 16:04, 15 April 2023 (UTC)

Using Osmose QA would provide the necessary framework to ease this work I guess. Fanfouer (talk) 13:35, 17 April 2023 (UTC)

Problematic for Data Users and conflation with external sources

I'm afraid I am not convinced that this proposal is the best way to go, particularly thinking about data users and conflation of OSM data with data from external sources. There are a number of issues. (I think some, but probably not all, of these could be addressed by tweaking the proposal slightly.)

Thank you for your comments. Please see my response on each below.--NKA (talk) 10:54, 21 April 2023 (UTC)

• It's not completely clear whether it is mandatory for each group of man_made=charge_point objects to have an amenity=charging_station object with them. I assume it should be.

You are right. The proposal only describes man_made=charge_point as a further detailing of an amenity=charging_station.--NKA (talk) 10:54, 21 April 2023 (UTC)

• There is no direct connection between the man_made=charge_point objects and the amenity=charging_station object. If both exist, then these should be linked by a relation, to allow data consumers to easily associate them. (Just going on geographic location is a real pain in terms of processing for data users.)

You are right that a relation could have been used. Using a site relation was discussed on the forum but it did not get sufficient support. Instead the relationship is established when mapping man_made=charge_point inside of an amenity=charging_station polygon, which was considered to be easier for most users.--NKA (talk) 10:54, 21 April 2023 (UTC)

It may be slightly easier for mappers, but it makes things much harder for data users. --Rjw62 (talk) 16:10, 21 April 2023 (UTC)

• It is not clear whether brand/network/operator tags should also be added to the man_made=charge_point objects. It feels like duplication if they are, but it makes any data use much more difficult if they're not - particularity if the charging_station and charge_point objects aren't linked by relations.

These tags should be added to to amenity=charging_station, as shown in the tagging table and in the examples.--NKA (talk) 10:54, 21 April 2023 (UTC)

But can/should they also be added to the charge-point objects too? They arguably also have that brand/operator. If you don't do this, it would make it really difficult to search for all chargepoints in a certain network -- which it what you'd want to do for any conflation / data matching. --Rjw62 (talk) 16:10, 21 April 2023 (UTC)

• It's not clear whether you should add the total capacity, socket-types, etc. of the site to the amenity=charge_point object if that information is also mapped on the individual charge_point objects. If feels like duplication if you do, but it makes life harder for data users if you don't. Worse still is if there's no consistency here, since data users need to know how to count the total charging capacity in an area. Should you count just what's on the charging_station objects, or do you need to include what you find on the charge_point objects too?

The proposal says that the total capacity, the number of each socket types and the maximum capacity available for each socket type should be tagged on the amenity=charging_station.--NKA (talk) 10:54, 21 April 2023 (UTC)

• There's an inconsistency in that the proposal suggests using amenity=charging_station to represent a single charge point, and then not map the individual charge point separately in that case. So sometimes amenity=charging_station will include charge point metadata, and sometimes not. Presumably both the site and the single charge point could have their own refs and names. What do we put in the name=* and ref=* tags in that case?

The name should be tagged on amenity=charging_station, as shown in the tagging table and in the example. Not sure why there would be a different name on the charge_point. In all the cases I have seen there would be a different suffix for the ref (ref:xxx) to denote which data source is being referenced and what it data is referenced. Worst case is that you have to map the charge point as well. With the proposal, at least there would be a way to get around any potential problem (by mapping an extra charge point), which is not the case today.--NKA (talk) 10:54, 21 April 2023 (UTC)

For example https://charge.pod-point.com/address/lidl-warstock-road-kqd0k/ has the site name "Lidl - Warstock Road" and ref "16079", while the single charge-point there has name "Dave-Gino" and ref "23248". On the ground you would only see the charge-point details, so there's a risk those will (incorrectly) be put on the charging_station object. --Rjw62 (talk) 16:10, 21 April 2023 (UTC)

• The data I've seen tends to have records for individual charge points. Sometimes these are grouped into sites, but not always. In the real world, the charge points typically have visible names/reference numbers, but there's usually on-the-ground signage for any official name/reference number for the site. In terms of matching with external data, it's going to be much more difficult to do so without having the individual charge-points mapped. This proposal seems to be discouraging that.

It is entirely up to the end user to decide if charge points should be mapped. The proposal is trying to leave the message that there is no requirement to map individual charge points on every site, nor is it desirable to duplicate information if for example all the charge points are equal.--NKA (talk) 10:54, 21 April 2023 (UTC)

Personally, I would think more about using amenity=charging_station for both sites and individual points. You could add a charging_station=site type tag to distinguish the cases (much like with do already with amenity=recycling and recycling_type=container or recycling_type=centre). If you want to map the individual charge points and link them together to form a site, then a site relation could be used. I think this would make things much easier for data users to handle. -- Rjw62 (talk) 08:03, 21 April 2023 (UTC)

There are several ways the current situation could have been resolved. Both special tagging and site relations were discussed in the forum but met with restistance there. A clear benefit of having two different feature tags is that only amenity=charging_station will be needed for rendering and for searching/navigating.--NKA (talk) 10:54, 21 April 2023 (UTC)

amenity & man_made together for single charge points?

For single charge points, amenity=charging_station will of course remain present, but could/should man_made=charge_point be added to state explicitly that the charging station consists of a single charge point? 501ghost (talk) 21:45, 25 April 2023 (UTC)

Just for my understanding, why would you need to know that a charging station has exactly one charge point? When would it be used?--NKA (talk) 14:47, 26 April 2023 (UTC)

This has been suggested on the mailing list too: https://lists.openstreetmap.org/pipermail/tagging/2023-March/067133.html

I think it will be useful to have a way to communicate the fact that you know for sure that there is only a single charge point at a location. An amenity=charging_station with capacity=4 could be one charge point, two or four. Of course, if there are two or four `man_made=charge_points` in the vicinity, then we know. But if there aren't, it's ambiguous. I imagine that someone who is micromapping all charge points in an area might want to communicate "I have already surveyed this and there's only one charge point here".

Or a data consumer might want to count the charge points in an area, regardless of whether they are part of a larger site, for example to calculate operator market share. In a completely mapped out area they would be able to do this by just querying for all man_made=charge_point nodes. Osmuser63783 (talk) 07:19, 27 April 2023 (UTC)

This is not explicit in the proposal, but there is nothing preventing you from tagging both on the same element. The alternative would be to map amenity=charging_station on an area around the location and a node with a man_made=charge_point inside that area, but I guess both on the same element would be easier. Note that many users would not map man_made=charge_point at all, so there would not be a definite way of knowing the number of charge point devices on a location. Instead, the focus of charging station tagging has always been to record the number of sockets and the capacity.--NKA (talk) 16:35, 27 April 2023 (UTC)