Charging stations (sites or individual chargers?)

General talk Tagging general discussion
141

Why not simply use area with stalls inside it? Relations are horrific to edit and create.

And even with multiple charging stations in the same are above each other (some mall or something) you can still use level/layer tags to disambiguate.

1 Like
142

That could work too, in my opinion. It just requires the amenity=charging_station to be mapped as an area.

1 Like
144

that might be an option e
e) keep amenity=charging_station ambiguous but have sites be areas/relations exclusive and devices nodes exclusively

  • minimal changes to current tagging
    +mostly backward compatible (even apps not aware of the new scheme will simply show devices and sites) this might lead to one additional result (the site) being shown
  • might be confusing if someone tries to add a site as a simple POI which also seem to be used like that pretty widely
  • socket: information might be redundant and could lead to conflicts
145

does not really work, ability to map multiple-stall site as node without micromapping area is needed

1 Like
146

Given the growth of EV chargers, would that actually be a prerequisite?
It would be good to have, but shouldn’t preclude an otherwise excellent tagging scheme

2 Likes
147

Yes, at least in as much as there needs to be a plan to get from where we are to where we want to be. We aren’t going to just pretend that there isn’t anything mapped in OSM already.

2 Likes
148

Parking spaces reserved for charging electric vehicles at a charging station are already covered by amenity=parking_space + parking_space=charging

I really don’t like the idea that the same tag mapped as a node or as an area represents two different concepts. That’s just going to lead to more confusion and awkward situations. Also, that’s basically option a) but without the differentiating subtag.

149

How to map a site is definitely also something we need to think about.

  • Relation containing charging devices
    • Direct association of devices, no post-processing needed
    • A bit cumbersome to use and confusing for new mappers
    • No implicit area, just individual points
      • Sucks for rendering on a map
    • Single device sites? (a relation with just one member seems rather pointless)
    • Cannot map site only without individual devices (relation needs to contain something)
  • Area covering the charging site
    • Association of charging devices with site if they are within the site area.
      • More post-processing required for data consumers
    • What counts as the ‘charging site’? The parking area?
      • Charging devices might be slightly outside of the parking area on a sidewalk, etc…
    • Does the tag need to coexist on the same area as amenity=parking?
      • Not possible if the site also uses the amenity=* key.
  • Node
    • Easy, straightforward
    • No detail at all, just general location. Stepping stone towards more detailed mapping.
    • Cannot really associate individual devices with site aside from general proximity

Also: do we want to have a way to associate individual charging devices with the parking spots reserved for charging next to them?

2 Likes
150

It would be nice to have more information how amenity=charging_station objects are currently being used by data consumers. (Who’s using it in what way and what for)

151

Be aware that amenity=parking_space is only used if the parking spaces are part of a larger, already mapped parking lot/area with amenity=parking (example on a charging station). In particular for charging stations in public street space, the associated parking area would thus have to be mapped separately with amenity=parking + restriction=charging_only (according to the new street parking scheme).

Example:

amenity=parking
+ parking=lane
+ restriction=charging_only

(or alternatively as a property of the street center line with parking:left=lane + parking:left:restriction=charging_only etc., but that would require dividing the road into small pieces – and it’s also hard to group this road segment with a possibly charging site relation.)

grafik
grafik1005×594 61 KB

1 Like
152

I don’t think associating street side parking mapped on the street itself with a charging station is practical. Those parking spots would probably have to be mapped separately as dedicated objects (which is also possible and allowed in the new street parking scheme).

At the moment the association of charging parking spaces with chargers is only an idea and tangentially related to the main problem of differentiating between devices and sites.

1 Like
153

Maybe the wiki says that it should be, but that is not always the case.

154

In agreement with @jmarchon I have updated the wiki page proposal. Let us try to work towards a consensus.

1 Like
155

Thanks. I think this looks great. It would be even better if it addressed the question what to do with capacity:charging: do you propose any changes to that tag?

At the moment that is another method of tagging chargers (those in car parks, with dedicated parking bays) and it is used about 5,000 times. From a quick look on Overpass it looks like most of these are not also mapped separately as an amenity=charging_station, but some are.

If this is not addressed there will still be two different methods of tagging chargers in car parks and you won’t achieve the goal that all charging locations can be identified by a single tag.

156

Do you have a suggestion on what to do about it?

157

Maybe encourage people to use either amenity=charging_station or capacity:charging but not both?

If it’s one or the other, then capacity:charging would be a quick way to add just the number, and then anyone who wants to add more detail should remove the tag from the amenity=parking and place an amenity=charging_station node instead (or for even more detail, an area with man_made=charge_point nodes).

Data users can then find all charging locations by looking for capacity:charging OR amenity=charging_station, and don’t get duplicates. The downside is, there are already a few cases where capacity:charging is used alongside a charging_station, these would over time need to be cleaned up.

158

That sounds lovely, but it’s missing some way of telling if an " amenity=charging_station" is a “group of pumps” (to follow the analogy) or just one.

Alas, that’s not the case right now. People have tried to “tell everyone in OSM to do things differently” in the past with limited success.

What has worked in the past is where there are ambiguous main tags, have a subtag to identify which is which.

159

Taginfo suggests that these projects use it. Excluding tools that are primarily OSM editors, there are about half a dozen there. I just display it on a map. Here’s the relevant bit of the map legend:

Screenshot_20230325_182853
Screenshot_20230325_1828531170×169 22.1 KB

160

I meant the capacity:charging tag on an amenity=parking node. Your query returns capacity:charging on an amenity=charging_station, I’m not sure what that means / how it’s different from capacity.

To be clear I wasn’t trying to tell everyone they’re doing things wrong. capacity:charging on an amenity:parking node without a separate amenity=charging_station nearby is more common than both being mapped separately, according to my spot checks on Overpass, so I was just suggesting that we encourage the more common way of doing it.

161

From the proposal:

It may be mapped as an area or a site relation in adddition to a node.

A node AND an area are pointless. It should be either or, or you are missing a comma in there if that’s supposed to be as an area | a site relation in addition to a node.

The main tag amenity=charging_station should be redefined slightly to mean “a location where an electric vehicle may be charged”. It may represent one individual charge point (without others close to it) or a group of charge points.

A new tag man_made=charge_point can be used on a node for each charging stall or “charge point” (ometimes also known as “dispensers”). If there is only one charge point at the location, then it is mapped with amenity=charging_station rather than man_made=charge_point so that all charging locations may be identified using one tag only. The new man_made=charge_point is optional an often not needed.

I don’t see why a location with a single charge point (node) shouldn’t be tagged with man_made=charge_point in addition to amenity=charging_station. It is both things at once, there’s no reason to disallow this and doing so just complicates things. If the single charge point site is mapped as an area, there should be a separate (optional) man_made=charge_point node as normal.

I understand a ‘charging stall’ to mean a ‘parking space for charging’ (i.e. amenity=parking_space + parking_space=charging), which are two different things. I would not use that terminology here.

amenity=charging_station may be mapped as a node, an area or a relation:

You should specify a site=* tag for the site relation. (e.g. site=charging_station).

Other tags currently described on the wiki page for amenity=charging_station are essentially the same for both the charging station and for the charge point, however when both features are being used for a location then other tags which are common for the location as a whole, such as name, brand and capacity should be put on amenity=charging_station and do not need to be repeated on each man_made=charge_point. Also, if the socket information is the same for all charge points, it may be tagged on amenity=charging_station only.

Lumping capacity into the ‘common features’ doesn’t make sense. The capacity=* on amenity=charging_station should be for the whole site (i.e. sum of all chargers), the one on man_made=charge_point for the individual charge point. The same applies to the number of sockets. Does socket:<type>=4 mean there are 4 sockets of <type> at the location or that all charge points at the location have 4 sockets of <type> each? Only the former really makes sense and matches current usage.