On amenity=charging_station wiki page is example how to tag charging station for cars:
amenity=charging_station +
access=yes +
motorcar=designated.
Does this mean that the station is also accessible for bicycles, buses, etc.?
If I understand correctly, according to access wiki page, such tagging is not recommended for different modes of transport.
Could such charging station be tagged as
access=no +
motorcar=designated +
motorcycle=yes?
Strictly speaking this means you can not get out of the car 
. But around here lots of charging stations consist out of one charge point, often along the side of the street, and I do not tag access at charging stations at all.
Also, I could imagine that you park the car for charging a couple of streets away from your destination and then grab the folding bike out of the trunk and cycle to the destination.
Edit: Let me expand on this. I do not add the acces=no tag but I do add motorcar=yes and motorcyle=yes to indicate that those could be charged at that station, But I am getting a bit unsure about that now.
To some extent it looks to me like misusing legal access tags to map the types of vehicles that can be charged at the station. Instead, this should be tagged at a separate parking object.
One could argue that the parking spots are designed for cars (in terms of width and length). Yet, legally speaking, if you could park your bike there, then it is indeed access=yes, even if it looks weird.
=parking + access=yes is the most common, while it should not be understood as all vehicles allowed. Bikes, motorcycles, buses, trucks, etc.
Although technically true, applications may better not interpret the hierarchy strictly. Safer to treat access= as unspecified, only applying to some expected modes by default, ie motorcar= only on =parking, and perhaps =charging_station here. If you mean it, more explicit to use vehicle= , motor_vehicle= , with the added reason that foot= or horse= doesn’t make sense either.
OSM wiki says something different:
Adding
access=*is equivalent to adding all 2nd level access tags with the same value e.g.access=nois equivalent to addingfoot=no,dog=no,horse=no,vehicle=no, etc. Specific access keys may be added to override a default values specified by a parent key.
For example:
access=nofoot=yes– access is only allow by foot and via no other means.access=no,bus=yes– only buses are allowed to enter (for example a road only for buses and forbidden also to pedestrians)access=yes,motor_vehicle=no– all transport modes except motor vehicles can use the element
According to this description, it means that the amenity=charging_station with access=yes can also be used by bicycles, buses, etc.
I’m describing the existing situation. Another factor is this being considered for highway= road lines usually. In practice, it was further influenced by Carto rendering only access= before recent years. Haven’t checked whether vehicle= and motor_vehicle= are rendered on PoI icons.
To note explicitly, access=private may also be inherited by foot= , horse= , vehicle= , motor_vehicle= , bus= , hgv= , motorcycle= (etc)
For your question, access=no should not be added. The default or expectation can be seen as other modes =no
Access tag on charging stations has a very good description on the wiki.
private- Only accessible for dedicated individuals or vehicles (such as a workplace charging station.)
customers- Dedicated for use by customers of an establishment regardless of affiliation (such as a hotel or vehicle-exclusive stations.)
yes- For public access stations (such as shopping plazas.)
It’s not about access of vehicle type.
It’s about allowed access to the premises.
Strangely that seems to a bit at odds with the examples used at Tag:amenity=charging_station.
For example:
The first bicycle example has bicycle=yes and motorcar=no but in the notes says "Example of a small public e-bike charging station ". Which should, according to the wiki description, be access=yes.
You still think like access for the vehicle. Maybe you should think this like access to a building. Which person can access the door.
Now to better clarify the missing access tag. If omitted then we suppose it’s access=yes. It’s the default.
The description in your example says “public e-bike charging station”. The access tag is omitted so we suppose access=yes (public) so no problem at all.
I personally add access=yes to the cases i am sure they are public access just to show this is certain.
There is confusion here about whether a charging station is legally accessible to vehicles, and whether it is suitable for charging your vehicle. bicycle=yes means that the station is legally accessible with a bicycle but doesn’t tell you if the plug fits your e-bike. I think the access=* space should not be used to tag usability of the charging station, just like it shouldn’t be used to tag usability of ways (for that we have smoothness=*).
True. But, in this example, if acces=yes is the supposed default then bicycle=yes is redundant. While it wouldn’t matter much if used “in the field” it should not be used in an example then?
This is what I was thinking. Anyway, the combination of the “rule” in the tag description part (clearly about the legal access) and the usage in the bicycle example section (seems to imply usability) confuses me a bit.
Looking into this a bit more I came by vehicle in the tag description section on amenity=charging_station which says:
Probably based on
in this proposal.
Unfortunately using the same words for key names as are used for legal access ( Key:motorcar).
Technically for the most accuracy and precision, legal reachability restriction should be obtained from the highway= roads. Physical reachability from the surroundings is a routing problem, application, analysis, or enriched/processed/assessed data, which shouldn’t be added. In other cases, some modes can’t be used to reach somewhere, but can be used inside.
access= on the PoI could be interpreted as for the PoI itself. Physical usability is not the only possibility, as they can be legally usable for only certain motorized vehicles.
However, it can be seen as unspecified, or applying to all these aspects when they are the same. For clarity, I agree they should be distinguished.
That part of the proposal doesn’t even make sense. The sockets should already provide the information as to whether a specific vehicle can be charged there or not. Misusing access tagging for that is redundant.
Part of the charging station is an amenity=parking_space which can be tagged with the legal parking access if not any vehicle is allowed there. I’m not aware of any instances (though theoretically possible) where charging itself is restricted to certain vehicles (i.e. even if the plug fits and you can somehow reach it, you are still not allowed to use it).
I second that. Imagine that nowdays we have the first motorcycles with Type2 / CCS2 plugs.
There is NO case they are not allowed in a charging station with that plug.
There is already a discussion about that.
These tags are useful for distinguish a small charging station for carts or bicycles. Their plugs will be different also (not Type2/CCS2/MCS).
These days we also see the first MCS connectors (Megawatt) which will be used for trucks, so these stations i believe will have a HGV=yes tag. These are coming fast, i already mapped 2 MCS stations in Bulgaria and Romania.
So, access=yes for free access and not private space or customers only usage.
And selective vehicle specification for VERY SPECIFIC charging station.
The main concern is the plug itself.