Amenity=charging_station relations

General talk
, , ,
1

Hi all. More on EV chargers! I see that on the amenity=charging_station wiki page, only nodes and ways are allowable elements. Some users are already adding relations. I think they are needed so will set out why below.

First, examples of where relations are being used:

Relation, type=site (for 10 Ionity sites in France and some sites in North East USA and some sites in Florida & Georgia)

Examples in France:

In these examples all elements that make up a charging location (the car park, the individual car parking bays, the individual charging stalls, the overall charging site boundary) are added to a relation with type=site.

Example in north east USA:

Similar but just the charging stalls and the parking bays added to the site relation.

Example in Florid/Georgia:

Similar again, but this time just the charging stalls are added to the site relation.

Reflections: This site relation approach seems odd to me as tagging is often duplicated with the individual features, and may not even be accurate (e.g. I have seen ref:EU:evse tags added to parking bays which is wrong, and parking bays are often tagged as being operated by the charging company - which might not be the case if part of a larger car parking area).

Relation, type=multipolygon

Examples:

These seem to be used in various locations. Multipolygon relations are being added when a single charge point operator has charging in two distinct areas of a car park (sometimes very close to each other, sometimes 50 meters or so apart). I’m currently reviewing UK open data for EV charging and have seen that the charge point operators consider this to be a single site in their databases. For example I have seen Gridserve sites on UK motorway service stations where they started with some low kW output chargers a few years ago and then have gone back in and added higher kW output chargers in a slightly different area of the service station car park but consider this to be 1 site in their database.

This case make more sense to me. Allows the mapper to add the charging sites as they normally would (although they do need to add areas instead of nodes to create valid multipolygons) then add a multipolygon relation to reflect the fact that these slightly separated areas are considered to be 1 site.

Outlier example:

The 4 edges of the area rectangle are added to a relation. This seems to stem from a desire to not draw overlapping areas (i.e some sides of the multipolygon appear in another multipolygon of another feature).

My thoughts

I think we do need to change the wiki to make it clear that relations can be used. As noted above, I have seen cases where a charge point operator has 2 or 3 distinct areas within a single car park and they consider the collection of these to be 1 site.

I see the value of a type=multipolygon relation here. I’m less clear on the need for the type=site relation. Perhaps someone who has been using it can explain their thinking here.

2

A quick look at where else site relations are used:

  • Bus stops: associating a bus stop on one side of the road with the stop on the other side.
  • Wind farms: associating the nodes that represent each turbine (tagged as power=generator) together. power=plant is added to the relation.

These both seem logical to be. The charging station equivalent would, in my mind, be to map each charging stall (man_made=charge_point) as a node, add them to a site relation and tag that with amenity=charging_station. However 2 problems:

  1. Unlike wind turbines, individual charge points are hard to make out on aerial imagery - it’s much easier to make out the area of the entire charging facility.
  2. We have seen cases where mappers are already adding much more to the site relation.
3

Did a bike charging stations site relation on 10 the city installed under a mobility program… 2 years ago
Relation: ‪Pescara Ebike Power‬ (‪12616515‬) | OpenStreetMap and then this new sign appeared last month, experimental signage

Screenshot_20250313_202758_com.gbox.android
Screenshot_20250313_202758_com.gbox.android1080×2400 176 KB

4

In my view that is an incorrect use of relation. As noted on the wiki page:

They [relations] are not designed to hold loosely associated but widely spread items.

In this case, I think the relation should be removed. If you want to associate them together, then add an operator tag to each node.

5

Areas in OSM are closed ways and MP relations… :wink:

grafik
grafik375×146 8.32 KB

1 Like
6

Seriously! I wrote all that just for you to point out that mulpolygons are allowed anyway?!

So what does the no relations icon mean? No relation other than the multi polygon type?

P.s. any way to get that hover over text on mobile?

7

takes long drag on cigarette…

It depends. Wind mill farms are the quintessential example of a site relation where windmills need a substation that’s not connected and are on land that’s used for other purposes.

I took a look at the Georgia relation. A cluster of Electrify America chargers. On one hand, each charger is a distinct device that can be linked via manufacturer operator or brand. On the other, it’s a group of non connected entities, that require a shared separate connection (the battery / converter) on land not dedicated to it (a parking lot). One could say that’s the same as a mini windmill farm only it’s dispensing electric instead of producing it.

FWIW for simple clusters like this, I wouldn’t make a relation, but for larger charging facilities I would if there were several networks, circuits, power levels, etc. all connected to different chargers.

So, it depends. ™

8

This exactly.

2 Likes
9

On this basis, I have updated the wiki page to make clear that multipolygons can be used and to explain when and how to use them.

Those using type=site relations are currently mapping against the guidelines in the wiki so I encourage them to comment here why they feel that is necessary.

10

There is also some fun misstaggings like:

1 Like
11

Yeah, but this is normal for OSM and not limited to charging-tagging. :wink:

12

Good to catch it early though. I’ve fixed all the amenity=charge_point instances.

13

On man_made=charging_station my edit go reverted. Will need someone from the Russian community to help explain this one. See: Changeset: 163655840 | OpenStreetMap

@Zverik do you have any good contacts in the Russian community that might be able to comment on this? The logic that the amenity tag shouldn’t be used seems odd to me.

1 Like