I am trying to work on an updated amenity=charging_station tag as the data around these is quite a bit and prevalence is only gaining. OSM should aim to keep up as a result.
Charging stations (we’re talking multi-charger) are split into what I’d call “charging bays” which at a minimum have:
(1) Energy dispenser
(1) Parking space
But can contain many amenities and elements already common in OSM (waste bins, lights, benches, etc.)
I’ve thought of 2 ways of organizing this and would like the community opinion:
Option A: Continue using amenity=charging_station as an area and associate elements in a bay using a new key, ref:evse=*. This is not great in my opinion but keeps the current tag in place.
Option B: Convert to a relation where the overall station is the top level, made up of charging bays, which are themselves relations with their elements. See an example of one here I mapped for this question:
I am leaning towards 2, it makes it very clear bays make up stations and elements make up bays. Data consumer wise, it would be easier to display stations / bays if they have this explicit relation verses matching ref.
Yes, well managed is hard to edit.
OSM often “organises” just by positions inside areas. Like building:part(s) are just inside a building footprint without relation (mostly). The data consumer needs to sort this “is inside” out.
For Bus routs it is very different.
Still, in this case, I tend to prefer A.
I think I’d be okay with that, charging stations are much more “utility” scale and utility tagging in OSM I wouldn’t recommend for a beginner. But I see the point, if relations are used there should also be a simple node / area to serve as a “good enough” option with perhaps a MR challenge to upgrade to the relation for those comfortable with it. Of course, I’d make a detailed wiki page with steps and “how to map” explaining the 3 levels of nesting a charging station has.
As far as option A, it would need to introduce a new ref:*=* tag (I suggest ref:evse=*) since some dispensers can charge more than one vehicle at a time and can load balance depending on charge management systems in place. For a data consumer it would be beneficial to know the elements of side A vs side B even if they originate from the same dispenser.
Thanks for the insight! My concern with this is, at least in the United States, these charging stations are much less their own element (although I have mapped some: Way: Rechargery (1387016726) | OpenStreetMap ) and more often in a parking lot of another amenity (think this huge 44 stall Tesla Supercharger in a “L” pattern with multiple different hardware types: Node: 12328376507 | OpenStreetMap ) so to encompass the whole area would not be accurate. A relation is by definition for these cases. This would be a site relation as the initial example is, not a route relation.
Most, if not all, of these are elements that can exist on their own without a relation. Option B appears to be a good candidate for Relation:site, but consider the caveat that it’s not advisable to use for mere organisational or spatial relationships.
I’ve landed here from the proposal page. I find it too confusing to have nested relations.
Have you tought about having a single main relation where instead of bays being the members you have the dispensers (man_made=charge_point) and the parking_spaces as members ?
A single relation per charging_station would be much easier to handle.
PS: If it comes to voting I would vote against a scheme with nested relations.
Just adding 2 more CS I found on a cycle run today and see as locations at the operator’s site, one actually fresh off the press, the plastic bag still over the traffic sign (Warning you will be towed!) at the location and a dark display on the pillar… not operational yet, so you can park in the bays 24/7 while it lasts. Entering the basics, the rest can’t tickle my fancy.
According to the wiki changelog, how to map these was substantially changed in May 2023 - that’s basically “yesterday” in OSM terms.
The new proposal (arguably at least the third, not the second) seems to suggest using a type=site relation(!) for amenity=charging_station. We typically don’t create a site relation for (say) bins in a park; we map the park as an area and the bins as nodes within that area. Why is this different?
Thanks @SomeoneElse for taking the role of the spoilsport this time around
I could kind of technically see (one level of) a site relation making sense if there is infrastructure that is not easily included in the area* of the facility (maybe shared with a mall or whatever, for example toilets), but it is kind of an edge case of usefulness and site relations are just not particularly well supported. A completely new relation type is a clear no no though.
* using a multipolygon as the area should cover most of the cases.
Here in the Netherlands (but also in many German cities) many slow chargers come with 1-2 associated parking spaces that are not full-time available for charging but, taking into account the general scarcity of parking for residents, only during daytime (e.g. 10:00-22:00), or have a time restriction (3h max). Including these parking spaces in a relation would overlook that they are part of this relation during daytime and not part of the relation but “normal” public parking slots at night… so I’d tend not to include parking spaces into a relation at all, at least for slow chargers.
For the slow chargers, socket outputs (in kW; and currents, voltages etc.) will be associated with a charging_station point tag. For fast charging stations having a plurality of charge points, these quantities will be associated with the charge_point tag. Any parser used for, say, searching chargers supporting a 400A cable or having a Chademo socket, will have to process both types of tags. I wonder whether this is anywhere implemented (would love to hear about an app doing so) - until now it seems to me that EV drivers basically use commercial sites like chargefinder.com, oplaadpalen.nl etc. We do not tag for the renderer, but I think it makes sense to think about the practical usability of our data - and not to make the scheme too complicated.
I have to agree with most I what people already have said here.
I can understand your position of trying to put everything neatly into a relation(s). I thought the same way before we found the consensus on splitting it into charging_station and charge_point.
I think the way things are getting tagged now (there is still a lot of old stations needing to be converted to the newer scheme) works pretty well (from an editor’s point of view). It allows for pretty simple creation of just the charging station (as either a point or an area). Area has the advantage that it envelops all the things you are hoping to add to the site relation. I don’t think I have come across a station that couldn’t be enveloped in a simple area but in case it’s more distributed, a multipolygon should works as well.
On the other hand it allows mapping to be more detailed by drawing the parking spaces and the charge points.
It probably puts. a bit more burden on data consumers, as they will have to look for things within the area but as other have mentioned that’s pretty usual for OSM, so I would guess tooling is already available.
I would suggest splitting your proposal for the additional tags you wanna introduce/formalize and the changing of the scheme regarding the use of relations.
