Bicycle chargers - discussion in advance of potential proposal

General talk Tagging general discussion
,
21

I think this works as long as all mappers add the tag. Unfortunately that is unlikely. You might find that mappers omit this if they don’t know enough about them (e.g. non EV motorcar drivers might add the charging station as easy to recognise, but not add the socket; likely to be even worse for bike chargers as who remembers those socket/plug types?!)

So for me it is about making it easy for the novice mapper. Same way we don’t combine amenity=parking and amenity=bicycle_parking into one tag and ask the mapper to add extra tags.

As a non-cyclist, and with lack of consensus above, I think I will leave this here and not go on to make a proposal. Others can feel free to pick it up if they would like to. Let’s not kid ourselves: who is going to use OSM to find these chargers anyway. There are ample apps to help find chargers and they give you live availability data and pricing data.

22

I think this works as long as all mappers add the tag. Unfortunately that is unlikely.

Perhaps. There was a StreetComplete request for that: Complete sockets of an EV charging station · Issue #5164 · streetcomplete/StreetComplete · GitHub, but it requires quite some effort. It would be a very nice quest, though.

Yeah… But to have the same effect, then we should deprecate amenity=charging_station and replace it with amenity=tesla_supercharger, amenity=schuko_charger, amenity=chademo_charger etc. to be equally distinctive / useful.
In other words, we’d need to reimplement socket:* :man_shrugging:
After all, you can park both your diesel and your gasoline car at same car parking, and you can do it whether it is sedan or SUV of wagon… Not so with charging.

More apt comparison would be with amenity=fuel and different types of fuel – but, unlike electric charges, it is much more standardized (i.e. most petrol stations will offer both gasoline and diesel) so only few quite rare outliers (like LPG or LH2) suffer because similar lack of extra tagging for fuel:*.

Well, I would, should I need them. (like I do for example for amenity=device_charging_station)

I’m still on human-powered bicycle, though, so not much use of amenity=charging_station for me at the moment at all. I do map both car and bicycle charging stations where I find them, though.

While I agree with you that most users will thoughtlessly fall into walled-garden traps of their car manufacturer-provided apps, the point of OSM is to provide open alternative to those. So I do not subscribe to defeatist approach for this specific or more general issues (“oh why even bother with mapping in OSM when most people will use Google Maps anyway and it has traffic data too”), but instead redouble on mapping efforts!

1 Like
23

Interesting thought process but I believed it is flawed. Specifically you are wrong to assume that there is still a lack of standardisation in EV car charging. Sockets have become standardised (type 2 in Europe, USA heading to NACS, GB/T in China). Just Tesla as the outlier now and that’s not due to the socket it’s due to the fact they they (electronically) only allow for Teslas to be charged at many of their charger locations.

I think things look like car chargers or look like bike chargers. As such we can tag them differently. See duck tagging:

https://wiki.openstreetmap.org/wiki/Duck_tagging

24

Since you mentioned fuel, it’s worth pointing out that we have all these instead of forcing the key detail (who is the fuel for) into sub-tags.

amenity=fuel
railway=fuel
waterway=fuel
aeroway=fuel
shop=fuel
2 Likes
25

Maybe the editor programs should give warnings if the important tags are missing. Also this would be a good task for the StreetComplete app.

26

@chris66 As @Matija_Nalis mentioned above, there is already a ticket for a StreetComplete quest: Complete sockets of an EV charging station · Issue #5164 · streetcomplete/StreetComplete · GitHub

Any help moving that forward is appreciated. (It doesn’t have to be coding; helpful tasks include researching common sockets per country, finding/creating usable graphics, cleaning up the wiki page, …)

1 Like
27

That’s not on the same level. Both bikes and motorized vehicles are road vehicles. This is akin to discussing =boat_fuel vs =ship_fuel , or =avgas vs =jet_fuel , here. amenity=fuel is used, with different fuel:*= further.
The topic here is more influenced by having =parking vs =motorcycle_parking vs =bicycle_parking , and =charging_station vs =device_charging_station
For that matter, does charging motorcycles need to be differentiated?

28

I fully agree with this. These stations do not just look like stations either to charge cars or to charge bicycles, they are also named as such or differentiated by symbols making that very much clear.

There are still many mappers who have no problem to identify a car charging station or a bike charging station but are not common with the different types of sockets still. Let them map the station and someone else add the details lateron. This is how OSM works in many different areas.

29

Yeah, it does have some advantages, I agree. My two main concerns are:

  • there then would be different tags truck charging, car charging, e-bicycle charging, e-scooter charging, e-skateboard charging etc., and some of those would overlap. So there is a risk that some grouping would probably still happen, which would only partly solve the problem and make solution much less attractive.
    That being said, if those new tags were to be proposed (where there are most likely to succeed and catch on), I’d definitely suggest using different keys (not just tags) to mark those charging stations – so One feature, one OSM element remains possible (like it is luckily possible today to tag both e.g. amenity=fuel and waterway=fuel on the same element, when same fueling station on the seaside covers both cars and boats, and not like unmergable shop=copyshop / shop=stationery / shop=books which often share the same shop key, so are unmergable (yeah I know about ‘;’ but that doesn’t really work) )

  • it is little late in lifecycle to propose such drastic changes (i.e. deprecating amenity=charging_station and replacing it separate tags for truck charging, car charging, motorcycle charging, bicycle charging, kickscooter charging etc). (even more problematic IMHO would be to try keep existing tag for some vehicles, but delegating for others – that would likely lead to failure of new proposal and only increase the problem (ObXKCD #927).

30

Sure. That is why I would prefer to integrate all kinds of charging station into the existing amenity=charging_station scheme, specifying the type by subtags like

truck=yes - only
bicycle=yes - only
scooter= yes - only

and so on. More details about capacity, sockets etc. etc. to be added by whoever is willing to do so. But if such tagging scheme would be accepted it should include all kinds of charging station, also those which got a separate primary tag already like amenity=device_charging_station as I have posted earlier in reply #11.

Whatever we go for has to be applicable by an average eletrical dummy like myself as well as an electrical expert knowing every socket type by name. That is the compromise we have to find.

31

I agree that is the easiest way forward; but isn’t that exactly the current situation (both as recommended in the Tag:amenity=charging_station - OpenStreetMap Wiki, and also as on-the-ground taginfo situation shows)?

So, unless I misunderstood, your suggestion is to “just keep doing it as we always were”, right?

Yeah, that is problematic. If you lookup at the socket wiki, just using names is unlikely to work even for above-average user (i.e. many in EU might recognize schuko term, but not its official CEE 7/3 designation, and likely the connector their own vehicle uses, but not more [1]).

Thus one definitely need pictures (see that StreetComplete issue linked few times by now). In EU, it was recently significantly helped by requiring all new chargers to have those compatibility letters in hexagons, but is still far from universal.

At least, using StreetComplete on the ground, one can leave a note with photos, so it should help adding the information – especially as there are not that many charging stations in an average city, so a single interested mapper in a city (or even a whole country) could easily keep up with fixing those, provided users leave pictures.

  1. although I’m likely falling in XKCD #2501 trap here :smiley: ↩︎
32

Oh yes, it is recommended in the wiki but that is only the first step talking about bike charging stations. It does not make much difference if I start tagging with

amenity=bicycle_charging_station
or
amenity=charging_station + bicycle=yes - designated - only

the task starts with the next step going into the details. Knowing that there are some CEE 7/3 sockets does not give me a clue if these are for bikes only (bring your own lock and adapter) or if there are some kind of bike lockers or even locker boxes where one can lock a battery or even another electronic device for charging. Just have a look at the sample pics I posted in #9. That is what we should have a comprehensive and consistent tagging scheme for.

And this is only for car chargers according to my knowledge. It was at least in 2021 when I posted a summary about the then acutal EU labels.

1 Like
33

Well, while I agree that more details are always good, I wouldn’t say it “starts” only after that. When I know that that this charging station has compatible socket able to charge my specific e-bicycle, that is already some very good (if basic) information.

Just like I wouldn’t say that the task of mapping bicycle parking starts only after amenity=bicycle_parking.
E.g. is that bicycle_parking=stands or locker? Is it covered=yes? What is its capacity? Is it supervised? Does it have fee? Is it lit? What is maxstay?

Those are all important questions, but the most important one IMHO was establishing one can park a bicycle there.

Just like knowing you can charge your e-bike there is a great help, even if it means you have to sit on a nearby bench and watch if anyone is going to wander by to steal it instead of walking to nearest pub and leaving the bike alone.

Yeah, the details are always useful, I agree. For some there are existing tags:

  • some to be used on standalone nodes and more related (e.g. amenity=device_charging_station , amenity=bicycle_parking, amenity=locker)
  • some less directly related but as important (e.g. amenity=bench with nearby natural=tree in summer, or amenity=pub etc) and
  • some to be combined with others (e.g. lockable=yes, fee=*, payment:*, covered, bicycle_parking=*)

Just have a look at the sample pics I posted in #9.

(Thanks for those pics BTW, they were quite helpful!)

That is what we should have a comprehensive and consistent tagging scheme for.

If something is missing a tag, there is always a widely supported description=*, in which I would add everything I deem important about the amenity and for which there is no popular tag yet.

That freeform description=* will cover everything, even if it makes harder to fully automate a search for them[1]

But, if separate tags are useful (and they often are), then the proposal should concentrate on extracting those which are popular and easy to encode in certain machine-readable tags, and then give suggested names/values and descriptions (ideally with pics also for all values).

So, do you (and others of course) have concrete list of suggestions here? What details related to bicycle charging are not possible to express with (non-freeform) tags yet? How would you name a tag for them?

  1. i.e. instead of running overpass query to check for hypothetical lockable_box_for_battery_charging=yes one would have to check nearby chargers one by one and read their descriptions. It’s not so horrible as it sounds, as usually there are less then a dozen viable options when you find your battery is running low ↩︎