Charging stations (sites or individual chargers?)

General talk Tagging general discussion
21

We have mapped thousands of sites in my community. There is no problem tagging them. The socket tags represents the number of sockets and the selection of connection types available, as well as the maximum output for each connection type.

1 Like
22

You never had the case that the same type of connector had different maximum charging power at different chargers? Or do I understand it wrong and only the highest rating is tagged?

Anyway
I’m fine with either devices or sites getting a new way of tagging.
Since the split is pretty even in the data right now, the workload is gonna be similar and the growing pains with renderers and other data users just as much.

The problem I feel rolling towards is if we wanna have a vote on it, we would probably have issues finding a majority for either.

23

I tend to agree with the point that charging station should be the site (in keeping with amenity=fuel for the whole petrol station). I suspect the only reason it is not this way is because in the early days of EV chargers it was just 1 charger or a couple added to an existing feature (e.g. a car park). Now we are getting dedicated places built for EV charging.

I will look in to the OCPI standard today as I think whatever we agree should link to future OpenData.

1 Like
24

I took a quick look at GitHub - ocpi/ocpi: The Open Charge Point Interface (OCPI) allows for a scalable, automated roaming setup between Charge Point Operators and e-Mobility Service Providers. It supports authorisation, charge point information exchange (incl transaction events), charge detail record exchange and finally, the exchange of smart-charging commands between parties.

OCPI seems to call the site a ‘Location’, each charger a ‘charge point’ and each charge point can have one or more EVSE’s (Electric vehicle supply equipment aka internal system that allows/controls charging of one vehicle)

25

I propose the following:

  • Use amenity=charging_station as an overview for a whole station or “location”. As a node, it should be more or less in the middle of the charging station. As a closed way, it should be an outline of the whole station, including parking, street cabinets, etc. At DC fast charging locations, these street cabinets often contain the actual EVSE. Rendering and mapping this would be the most important, in my opinion. capacity= can be used to show how many things (typically cars) can charge here at once, along with name=, network=, etc (but not individual socket/plug/cable info).
    Example of a charging station with 7 visible stalls:

    Example of a charging station with 7 visible stalls
    Example of a charging station with 7 visible stalls1280×624 144 KB

  • Use man_made=charge_point on a node for each charging stall or “charge point” (not to be confused with the operator “Chargepoint”). Sometimes also known as “dispensers”. Tags like socket:type1_combo= would go on this node. There can be many of these per charging station. Oftentimes there are multiple “connectors” at each =charge_point, but they are typically fed by a single “EVSE”, meaning that only one can be used at once.
    Example of a charging stall/point:

    Example of a charging stall/point
    Example of a charging stall/point1920×1280 172 KB

  • Use a relation containing the amenity=charging_station node/way, surrounding parking used for the station, man_made=charge_point nodes, street cabinets, etc. This is useful for applications to know what belongs where. I propose the tags type=site and site=charging_station on the relation. Roles for the relation members would be station for the amenity=charging_station node/way, charge_point for the man_made=charge_point nodes, parking for the, well, parking, and cabinet for the street cabinets. Minimizing the amount of tags on this relation, and putting most or all the general info on the amenity=charging_station node would be optimal, in my opinion. This and the charge points would be less important to map and render, as they only provide additional info.

Thoughts? Questions? My first time proposing something like this, so feedback is appreciated. Also, my view on this is rather focused on North America, because that is where I live and have the most experience and knowledge charging electric cars. I have used terminology from the OCPI standard wherever practical, in the interest of standardization and reducing confusion.

I hope I didn’t overthink all this :slight_smile:

7 Likes
26

Not at all. I think you are onto something here. Still doing my own research but so far your proposal seems to be spot on.

2 Likes
27

Thank you!

28

This turns out to be a very productive thread :slight_smile:

Minor comments:

  • I think it should be possible to map the site (amenity=charging_station) only, with man_made=charge_point being optional, reflecting current mapping practice in many countries. This means that at least the following two socket tags should be permitted on the amenity=charging_station:

    • socket:<type> - the number of each socket type on the site
    • socket:<type>:output - the maximum output available

  • I do not mind a site relation, but it tends to be complicated for many users, and there could be some overlapping tag issues with amenity=charging_station object. An alternative could be a looser understanding that all man_made=charge_point within an area (way) tagged with amenity=charging_station would imply that these objects belong to the same site.

1 Like
29

I was already thinking that man_made=charge_point is optional and only to add additional information, kind of like amenity=parking_space inside amenity=parking.
The idea without a site relation makes sense too. But I think we could have both, no? For those who want to map extremely detailed, the relation exists. But for others, just an outline is enough, and data consumers will assume that all man_made=charge_point inside are related.

1 Like
30

In general I agree with the proposed scheme. It solves the question.
I also thing “backwards compatibility” should be guaranteed.

1 Like
31

One of the issues with this, is that there may not be an obvious area. In contrast to petrol stations where the pumps are on a dedicated site, EV charge points can be put in pretty much anywhere. For example a series of charge points on street lamp posts could be considered as part of the same installation, but drawing an area around them doesn’t make sense (from a land ownership point of view).

I think we could do with a few examples of the range of infrastructure (from forecourt to street lamp changers) to test our proposal against and for showing examples in the wiki.

1 Like
32

Meanwhile, I ran an analysis of all amenity=charging_station on the planet to understand how many are individual charge points vs sites. I made the assumption that a group of nodes within 20 meters of each other are separate charge points on a site (the typical distance is 5-10 meters). Here are the results:

  • There are 6356 different clusters with nodes within 20 meters of each other, with a total of 17790 nodes. These nodes are likely charge points.

    • 4441 of these clusters have 2 nodes only
    • 811 have 3 nodes
    • 542 have 4 nodes
    • 192 have 5 nodes
    • 141 have 6 nodes
    • 51 have 7 nodes
    • 57 have 8 nodes
    • 12 have 9 nodes
    • 29 have 10 nodes
    • 80 have more than 10 nodes, up to 56 nodes at the maximum.

  • The other 69702 amenity=charging_station nodes had no adjacent nodes with the same tag within 20 meters. They are likely separate sites. Some of them could be single chargers, so still a site but with only one charge point with, say 1-4 outlets.

  • I also ran the same analysis with a 50 meters threshold. This produced similar results, with 7673 clusters of 21164 nodes (charge points), and 66328 separate nodes (sites).

So there are likely a lot more sites mapped than individual charge points within a site. I think this confirms that the amenity=charging_station tag should be used for a site rather than for the individual charge points.

6 Likes
33

Thank you! This is useful information.

34

I have made an example .osm file of how I would map a typical Electrify America charging station. How could I share that here?

2 Likes
35

Here is an example of a set of “On-Street” chargers by char.gy for us to test our proposal. As shown in G StreetView images there are a series of these charging posts along a service road in front of the shops. They are a little spaced out.

First question is would we map these as a single amenity=charging_station or multiple? If one, then how do we relate them together? Perhaps we may actually have to wait until the UK open data is made available to see how they appear in that (as a single “location” with multiple EVSEs, or as multiple “locations” each with just one EVSE)…

1 Like
36

Nice idea and great question. Maybe upload it to a file sharing site (OneDrive, Google Drive) and link to it from here.

37

These appear to be rather spaced out with other parking in between. I would probably map these as separate stations.

38

Here is a link: Charging Station Proposal Example Eugene EA.osm

1 Like
39

We should also find a way to map separately:

  • Number of parking spots
  • Maximum number of simultaneous vehicles that can charge

Here we have a lot of stations with 2 parking spots but only 1 DC connector can be used at the same time. It is good for different plug locations on cars, but creates confusion with the capacity tag.
Any proposals on this matter ?

40

I’d say that capacity= should show how many can charge at once. In this case, 1. I think this is documented on the wiki. Same for socket: - the number which can be used at once.

1 Like