Proposal talk:Bicycle rental:type

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discard :type suffix

Other tagging schemes show that there is no need to add the generic :type suffix. I would propose to just use bicycle_rental=* instead. Kjon (talk) 12:43, 14 November 2021 (UTC)

+1 for dropping :type suffix, like bicycle_parking. --Florimondable (talk) 18:49, 27 November 2021 (UTC)

I can live with dropping the :type, that would indeed be better. However, the non-suffixed type is mostly used for the kind of bicycles that can be rented, e.g. cargo bikes, electrical bikes, (see [1] ... This intuition was also why I choose to use the :type suffix. I'm gonna add the type of vehicle as paragraph, and maybe we should change the :type-suffix with a better tag Pietervdvn (talk) 21:05, 15 November 2021 (UTC)

By now, I've discovered that rental=* is what we need, freeing up the bicycle_rental=* so we can drop the :type suffix. --Pietervdvn (talk) 19:51, 5 December 2021 (UTC)

Improvements

I agree with the proposal and I also think there is not need for the :type suffix. Introducing the shop=bicycle_rental can be confusing and we wouldn't need the bicycle_rental specification on that case, so probably using bicycle_rental=shop with the existing amenity tag would be enough. --Wille (talk) 12:51, 14 November 2021 (UTC)

Good point, but the current situation is a bit messy. It is choosing where we want to be consistent. Do we want all amenity=bicycle_rental to get a bicycle_rental:type=*? Or do we want to have it nearly all the time, except in the case of shops which is consistent with shop tagging? I'm looking forward to your thoughts Pietervdvn (talk) 21:08, 15 November 2021 (UTC)

This mightn't be specific to bike rental

I second the :type suffix comments and while we are getting rid of it, we may build a more wider tagging scheme suitable for every vehicle rental service. You find bike sharing stations, car sharing stations, scooter sharing and so on...
If the point is to describe infrastructure, a whole new key rental_infrastructure=*, vehicle_sharing_infrastructure=* or shorter would be way better. Fanfouer (talk) 11:06, 17 November 2021 (UTC)

Good point. This would be the rental=* in this case. However, there are currently many competing tagging schemes; e.g. 'amenity=<vehicle>_rental', or 'shop=rental; rental=<vehicle>', or 'vehicle:rental=yes' and even '<vehicle>_rental=yes', all with relatively low usage. The main question is: what is the best and most consistent way to proceed? The really old and rental proposal is close to what we want to do here, maybe someone can revive it. Anyway, we are having a few aspects to think about: the physical rental infrastructure, what vehicles can be rented and the more abstract notion of 'we can rent here' Pietervdvn (talk) 01:44, 18 November 2021 (UTC)

Important distinctions - less important distinctions

I think the important distinction is whether something is a shop or a self-service station.

You already proposed shop=bicycle_rental for the former, but also write that adding bicycle_rental:type=shop is mandatory. So what if that tag is missing, isn't it still a bicycle rental shop then? Or what if that tag is there but shop=bicycle_rental is missing and it is instead an amenity=bicycle_rental? This duplication really seems to be there is one tag too much used here. Either shop=bicycle_rental should not exist (and instead continue using amenity=bicycle_rental) or the bicycle_rental:type=* should not exist.

An argument to not use shop=bicycle_rental is certainly backwards-compatibility. Up till now, all bicycle rentals should be tagged with amenity=bicycle_rental - whether shop or not - and thus data consumers expect it to be that way. Also, defining shop=bicycle_rental thus implicitly redefines amenity=bicycle_rental and this is something that we should avoid since it changes the meaning of existing data.

On the other hand, an argument to not use bicycle_rental:type=* is that the types all don't really matter except for the diferenciation between self-service and not-self-service: Because how does the difference between a "docking station" and a "dropoff point" really matter?

In my city, I see only docking stations. But unlocking works with an app so a bicycle rental station could just as well look like "dropoff point". Or whatever, let's say you have NFC card, or it works with SMS, it all doesn't really matter if that unlocking mechanism is in the docking station or in the bicycle itself. Same with the "key dispensing machine" which I've never seen before. What matters, for the customer, is not that you pay a machine that gives you a key, which with you unlock the bike, or if you pay in an app and that gives you a digital key with which you unlock the bike or whatever.

What matters, beyond being self-service, is how you unlock it. How do you pay? Coins? App? Girocard? Only through membership? For tourists etc. it very much makes a difference if you can simply pay somewhere quickly and get going or if you need to get a membership of some sort. This is the difference that matters.

It also matters whether this is a rental where you have to return the bike at the exact place you got it from (such is the case for shops) or if it is part of a network.

So, to summarize, my proposal would be to:

  • Continue to use amenity=bicycle_rental for all bicycle rentals, shops and self-service stations
  • Use self_service=* tag to denote if there is staff or not. Indirectly, this is the distinction between shops and non-shops. Shops that are self service are effectively bicycle docking stations too, no?
  • Not sure if there are any tags for denoting whether you need to be a member but this is also an important information.
  • Use network=* (if any) for bicycle rental stations of different operators. Or operator=*, not sure. If two bicycle rental stations have the same operator / network, it can be assumed that you can drop that bicycle off at either place.

--Westnordost (talk) 20:02, 18 November 2021 (UTC)

I agree with this reasoning. Also, there is already documented membership=* in use to indicate membership requirements. Also access=private might be used to indicate that only individuals who obtained permission on individual basis might access those facilities. --mnalis (talk) 16:35, 15 December 2021 (UTC)
* Wether or not a bicycle rental point is manned or not is an interpretation: quite a few 'self-service' station (e.g. the bluebikes) have someone around that could assist if needed (e.g. if someone can't figure out the app). self_service=yes in this case does not imply that there is no-one around to help out in case of troubles, and self_service=no does not imply that it is not a rental shop - it might be a rental shop that has a fully automated self-checkout together with a human to pay to.
  • Mapping the infrastructure is clearer, less error prone and closer to the 'map what is physically visible'. Furthermore, just because some group of bicycle rental users doesn't care about the infrastructure, doesn't mean there aren't cases where they do care: consider a network of bicycle rentals. Some locations have dropoff-points with automatic locks and GPS tracking, other locations are key dispensers and yet others are docking stations. Even though the members of this rental network can hire any bike, they must return a bike to a compatible infrastructure!
  • The intent is to tag rental shops with amenity=bicycle_rental, shop=bicycle_rental and =*. The last one is indeed a duplicate, but this is the fundamental tradeoff between backward compatibility, having a consistent tagging scheme or doubletagging. There is no perfect solution here. This proposal is an amend to amenity=bicycle_rental and intends to keep the original tag in place. One could argue that this mapping changes the meaning of amenity=bicycle_rental from fully automated locations to also include shops. However, the wiki noticed too that including shops happens in practice. This proposal tries to better define this and to fix this situation. And no, it is not a perfect solution.
  • Wether you need to be a member can be mapped with access=* and authorization=*. Payment methods are mapped with payment=* This proposal mentions to use them; these are pretty mature thanks to the EV-charging points.
  • The return policy (thus: return the bike to the same location aka boomerang_rental or drop it of at any other point) are very valuable too, but these are out of scope for this proposal and can be a good next step (together with e.g. max rental time, fee structure...)
  • network=* and operator=* are already described in amenity=bicycle_rental, which this proposal amends. Mentioning them here is thus unnecessary.

Pietervdvn (talk) 14:11, 6 January 2022 (UTC)

Bicycle type

For defining subtype of bicycle there is an other usage than bicycle_rental:type=* which is bicycle:type=*. I know it’s used for shops and routes. https://taginfo.openstreetmap.org/keys/bicycle:type#values I guess only one scheme should be used, bicycle:type=* is more versatile, it can be applied for different features.--Florimondable (talk) 19:04, 27 November 2021 (UTC)

Seems to be mostly and nearly exclusively used for bicycle route relations. If we are to pick a different key, I'd think rental=* is the way to go as it is already in use for (general) rental amenities. Pietervdvn (talk) 12:48, 29 November 2021 (UTC)

Edit: currently it is bicycle_rental=* that is used for the bicycle type. This proposal want to introduce tagging of the infrastructure of the bicycle rental with bicycle_rental:type=*, e.g. 'bicycle_rental=key_dispensing_machine'

Is bike library different?

Should amenity=bicycle_library be changed into *_rental=bicycle_library, or amenity=thing_library and amenity=tool_library. ---- Kovposch (talk) 06:28, 7 December 2021 (UTC)

Good that you mention it, but there are quite a few differences with bicycle_rental:

  • Bicycle-rental is often for shorter periods of time (a few weeks at most)
  • Bicycle-rental are often businesses and profit-oriented
  • A bicycle_library is often a community run-project where people lease a bike for years

This opens up the discussion where something like 'swapfiets' comes in... Pietervdvn (talk) 13:32, 6 January 2022 (UTC)

What exactly would this proposal improve?

I agree with Westnordost points above, I do not that this new key "bicycle_rental:type" would improve tagging situation at all.

  • Firstly, I think the proposal page has typos, it should likely be "bicycle_rental:type=docking_station" and "bicycle_rental:type=dropoff_point" in that table, and not "bicycle_rental=docking_station" and "bicycle_rental=dropoff_point" as it currently stands? (As bicycle_rental=* seems to be used as an alternate bicycle:type=* - with most common values: "yes", "cargo_bike", "e-bike"). Also in headers "Tagging:" it is mistyped etc.
I've fixed some of these typos. And yes: there is some usage of bicycle_rental=*, but it is minimal and I'd rather have rental=* as it is more future-proof: this also allows have _any_ rental shop that also happens to rent out bikes next to none-bike stuff. Pietervdvn (talk) 14:27, 6 January 2022 (UTC)
  • Secondly, the difference between "docking_station" and "dropoff_point" seems to be insignificant. As described, both seem to allow renting and also leaving the bike there. There is exactly one difference relevant to the user, and that is one of them allows only digital payment (via the app) and other might also allows physical payment (NFC or card), which should be specified via payment=* tag family instead. Only other discernable difference is the locking mechanism of the bike (manual combination lock or electrical unlocking), which should be irrelevant to the user (but can still be specified via for example actuator=* if one really wants)
It might be relevant to some users. Don't make assumptions for every bicycle rental system worldwide ;). Some hypothetical situation: a rental network which has mixed infrastructure throughout the network: some point are docking stations, other key_dispensers. People can rent bikes and return them to any station with compatible infrastructure. Furthermore, even though people renting bikes might not care about the infrastructure, someone who has to do maintenance on them might care; or some analyst might care. Pietervdvn (talk) 14:27, 6 January 2022 (UTC)
  • Also, "key_dispensing_machine" does not seem different from above. The user does not usually really care about technical implementation details like if the the bike is locked magnetically, electro-mechanically, via combination lock (with 3 or 4 or 5 digits), or via physical key which is dispensed via machine. Only real issue which is noted is that dispensing machine might be further away from the parking itself. In such cases, amenity=bicycle_rental could be marked with locked=*, and description=* and relations used to direct the user to correct amenity=vending_machine + vending=key which dispenses the key.
See answer above Pietervdvn (talk) 14:27, 6 January 2022 (UTC)
See the answer to WestNordOst above for self_service=*. Furthermore, shop=bicycle + service:bicycle:rental=yes is in the first place a bicycle shop where I should be able to buy a bicycle and might also rent one (typically as temporary replacement bike). shop=rental + rental=bicycle is an excellent tagging, but breaks backwards compatibility. Also see the answer above. Pietervdvn (talk) 14:27, 6 January 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Bicycle_rental:type&oldid=2512262"