Talk:Tag:amenity=bicycle rental

Misc

Every train station in Europe has something like a Velostation where you can rent a bike for a fews days, providing an ID card and a fee. --Gummibaerli 10:43, 19 August 2007 (BST)

Every is perhaps over-estimated  :)--PhilippeP 13:20, 19 August 2007 (BST)

My current opinion is that a Velostation should be taggued with shop=bicycle_rental. But a Vélib station is not a shop and could be taggued using amenity key. Maybe we should clarify this on the proposition. What do you think ? --Wawet76 18:21, 21 August 2007 (BST)

Then you have the Vélib'[1] and Co madness, which are decentralized system where you pick a bike for a half an hour or so. But you have to join the system first and need a credit card. --Gummibaerli 10:43, 19 August 2007 (BST)

Adding a tag type=self/... maybe to differenciate ??--PhilippeP 13:20, 19 August 2007 (BST)

Or simply leaving the network argument empty ? --Wawet76 18:21, 21 August 2007 (BST)

I think we would need something like class=free for bicycle rental. In vienna all bikesharing stations are already included to OSM by the bicycle_rental tag, network citybike Vienna. Foreign people would not know that those bikes are free to rent for up to 1 hour time. Or are all amentity=bicycle_rental supposed to be for free (limited time)? While shop=bicycle_rental is used for commercial bike rentals?--Extremecarver 09:57, 5 December 2008 (UTC)

If there is no rent to pay this is not the tag for you. It is explicitly stated that "bicycle_rental" (as also the tag itself states) needs a rent to be paid. See below: Bad choice of Key. --Dieterdreist 12:37, 5 November 2012 (UTC)

"spaces" vs. "capacity"

IMO, "spaces" should be "capacity", in line with amenity=parking and amenity=bicycle_parking --achadwick 22:02, 29 December 2008 (UTC)

• So any objections to me doing this? --achadwick 12:48, 13 February 2009 (UTC) Update: well, I've done it. Be bold and all that; let me know if you have any objections. --achadwick 13:05, 13 February 2009 (UTC)

"network" → "operator"?

Is the current page's recommendation of network=* sufficiently different from the established usage of operator=* to warrant a different tag? network=* is currently undefined in this Wiki, however there's an abandoned proposal for network=* with a conflicting meaning. IMO, we should use operator=* for this amenity in place of network=* --achadwick 22:10, 29 December 2008 (UTC)

• The link given by network=* now goes to a proposal with a completely conflicting meaning. Given that the meanings are the sameOkay, maybe not...! --achadwick 17:28, 17 June 2009 (UTC), I've switched the main page to suggesting operator=*, which retains approximately the same meaning. --achadwick 13:05, 13 February 2009 (UTC)

• The french mailing list proposed to use both (Network and Operator). For Paris, "network=Vélib'" and "operator=JCDecaux", sticking to the meaning of "network" and "operator". Most important is network of course. It would be nice also to User:Sebek 12 Jun 2009

I restored the original "network" tag as it was the key used during the validation process. Use operator=* only for the operating company, not for a trademark. -- Pieren 20:02, 16 June 2009 (UTC)

Thanks for responding, guys. "validation"=="voting"? I don't have strong beliefs in the validity of voting in the wiki, but I do accept data that people have entered into the map in argument: and [2] looks plausible :) The node-and-area meaning of network=* established right here needs to be written up on its own page, I think: it'll be useful elsewhere. That said, maybe the key should be trade_mark=* or brand=*... :) --achadwick 17:28, 17 June 2009 (UTC)

specifying the possibility to pay

In the velocity and other community bike rental system, only a limited number of station offer the possibility to pay (credit card usually) - this should be indicated on the station. What could we use? vending=yes or vending=subscription? We may also want to add the type of payment accepted using for example payment:coins=yes and so on... FranCk 11:31, 5 May 2009 (UTC)

Yes, don't use "vending" because this is not about any "sale", it is about "rent". Go for payment=*. --Dieterdreist 12:37, 5 November 2012 (UTC)

Bad choice of Key

In all cases that this is used for "bike-sharing" this is a bad choice for the key for several reasons: first because most bike-sharings are free of cost or offer bikes for a low fee, so "rent" does either not apply to them at all or is missleading (the scope is mostly not making money by offering bikes for "rent" but offering a sustainable means of transport and reduce traffic and parked cars, etc.). These services are also very well known under the term "bike sharing" and putting them under bike rental makes them less easily retrievable in the wiki and leads to wrong intuitive interpretations. I suggest to use amenity=bike_sharing or sth. similar instead. --Dieterdreist 12:37, 5 November 2012 (UTC)

see also

• Proposed_features/rental

Vote (moved from main page)

• I approve this proposal. --orgoz 11:50, 31 August 2007 (BST)
• I approve this proposal. FredB 11:54, 31 August 2007 (BST)
• I approve this proposal. PeterIto 12:20, 31 August 2007 (BST), with observation that bike rental within bike shop is the same problem as car parkings within shopping centre. We need a relationship to associate an amenity with a larger entity but Frederik is leading on that. Also toilet within shopping centre etc.
• I approve this proposal, with reservations: the tag should cover all types of bike rental. Even if it isn't done explicitly, I'm afraid the name of the tag will make people do it accedently :( --Kleptog 12:13, 31 August 2007 (BST)
• I approve this proposal. with the same reservation as Kleptog, it should be clarified in the description of the tag that it is an automated station and not a shop. --PhilippeP 12:37, 31 August 2007 (BST)
• I approve this proposal. Axel584 12:59, 31 August 2007 (BST)
• I approve this proposal. TomChance 14:29, 31 August 2007 (BST)
• I approve this proposal. --David.earl 15:39, 31 August 2007 (BST)
• I approve this proposal. --Hleroy 17:04, 31 August 2007 (BST)
• I approve this proposal. --Alban 18:43, 31 August 2007 (BST)
• I approve this proposal. --Andrewpmk 01:58, 1 September 2007 (BST)
• I approve this proposal. --Metehyi 14:02, 1 September 2007 (BST)
• I approve this proposal. --MikeCollinson 15:37, 2 September 2007 (BST)
• I approve this proposal. --Gregoryw 18:20, 3 September 2007 (BST)
• I approve this proposal. --Ryra6453 12:17, 4 September 2007 (BST)
• I approve this proposal. -- motp 23:01, 9 November 2007 (UTC)

Similar to bike rental or sharing but restricted to registered volunteers : Cycling Without Age

There is a growing "movement" that offers residents on elderly people's homes trips in rickshaws. It is called Cycling Without Age, and has spread to more than 20 nations. Would it make sense to map them on OpenStreetMap ? Currently the system uses a Google Map overlay (I think). See the (somewhat outdated) map on the front page of cyclingwithoutage.org Could one use a tag of service:bicycle:rental and attach it to the POI of the elderly people's home ? Other suggestions ? MortenLange (talk) 10:14, 28 May 2016 (UTC)

Mapping as a (linear) way?

It looks like mapping bike share stations as a way is deprecated, both on this page and in the JOSM validator. This seems a bit silly to me though since many bike share stations are long straight rows of docks. I've seen some that were probably about 20-30m long and only as wide as a bicycle. Is there a reason for this restriction? If I map a large station as a polygon, it will still essentially be a linear feature. Nate Wessel (talk) 20:57, 16 March 2019 (UTC)

I don't think there is any reason, other than someone in the past couldn't imagine it being meaningful. I fully agree now that it is meaningful, for the reason you give: many TfL cycle hire stands are many tens of metres long, and in OSM pretty good to be mapped as lines. I've done TfL stations as linear ways plenty, for this reason. How do we un-"deprecate" it? I've never really noticed it being suppressed.--Danstowell (talk) 01:55, 17 March 2019 (UTC)

it is not a given that a bike sharing station will put all bikes in one long row (although I have seen these as well). I would suggest you use the area, as it is more explicit about the extent. I do not have a very strong opinion in this case and agree, a linear way could be an appropriate representation as well. --Dieterdreist (talk) 11:14, 18 March 2019 (UTC)

Area is much easier to process. For example, it is extremely useful in deciding whatever icon should be displayed and its priority. And for me the most important part is that in reality it is an area, not a way. Nodes makes sense as are much easier to map, but difficulty in mapping area and line is very similar, while area data is much more useful. For examples see https://www.openstreetmap.org/way/677266656#map=19/50.07839/19.96038 (amenity=bicycle_parking case) or https://www.openstreetmap.org/way/655025821#map=19/50.05589/19.92761 (amenity=bicycle_rental case). Note how map display ( https://www.openstreetmap.org/?mlat=50.07829&mlon=19.96002#map=19/50.07829/19.96002&layers=N ) works well at z18 and z19. It would be unfeasible with line - tweaking it to fit this specific example would not work well for the same object in a different location. Mateusz Konieczny (talk) 11:24, 18 March 2019 (UTC)

Yes, but the question was for linear ways as opposed to areas. The length of the ways could be taken into account in rendering (although it is not currently done AFAIK). Generally I would also prefer the area because it is much better supported and doesn't require special treatment compared to other POIs. --Dieterdreist (talk) 12:03, 18 March 2019 (UTC)

Nothing is strictly a line (or a point) when you get right down to it though. The question is how the feature is best represented in a simplified form. I say line is most appropriate because what's being mapped is often 1 foot wide by thirty feet or more long, assuming you don't count the bikes themselves which are transient. Lines also have two sides, just like bike share stations can dock bikes on either one or two sides. I've never seen a station that was four-sided in any meaningful way. Length would also be a better proxy for capacity than area, especially with if tagged something like entry=left vs. entry=both etc. Then there's the kiosk, which could be well represented as a node on the line, typically on one end or the other. Nate Wessel (talk) 14:32, 18 March 2019 (UTC)

Current usage is 1100+ linear ways vs. 33 areas. Areas may be easier for CartoCSS to consume, but ways are clearly much easier for a mapper to add: mapping areas from aerial imagery in cities like London with taller buildings is very error prone, whereas the way can easily be correlated with other mapped features. In general data in OSM should follow what is most convenient for mappers, not for consumers. If areas are needed buffering in the lines is entirely possible at some post-processing stage.SK53 (talk) 14:54, 18 March 2019 (UTC)

In reality usage is 32 824 nodes, 1117 areas and 10 lines. See http://overpass-turbo.eu/s/H87 and https://taginfo.openstreetmap.org/tags/amenity=bicycle_rental "1100+ linear ways vs. 33 areas" is probably misinterpretation of taginfo stats. Note that on taginfo "way" category covers both lines and closed ways forming areas, while relations may be not only mutipolygons. Mateusz Konieczny (talk) 20:19, 18 March 2019 (UTC)

@Nate I would say the bike station comprises the space the bicycles take up. It is clear that this is a dynamic property, but there will usually be some bikes at any time, and the space is reserved for them. —Dieterdreist (talk) 00:56, 22 March 2019 (UTC)

It looks like OSM-carto does not currently render amenity=bicycle_rental when mapped as a linear way, example 677305653 677305653. Could one of the advocates of this tagging scheme open an issue in carto's bug tracker please? --Jarek Piórkowski (talk) 13:38, 27 March 2019 (UTC)

Crossposts

It was also discussed (without support for tagging as lines) at https://lists.openstreetmap.org/pipermail/tagging/2019-March/044081.html and https://osmus.slack.com/archives/C2VJAJCS0/p1552842220046300 Mateusz Konieczny (talk) 13:53, 27 March 2019 (UTC)

Tagging on bicycle rental shops

It seems to me that this tag should be able to be used on bicycle rental shops and just apply to "a place that rents bicycles" like the other amenity=whatever_rental tags are. There's several I believe this, aside from that it is already established for other rental amenity tags. For one, the language of the tag Amenity=bicycle_rental doesn't describe that it's just for "parking stations" and it's not intuitive to make it inherent in the tag that it only applies to them. When it doesn't contain the words "parking station." Instead, there be a descriptive complement tag for it like parking_station=yes to tag that kind of thing. That's how it's done with every other object. Also, not allowing it to be used on things other then parking stations has led to an unnecessary and convoluted mess of rental tags, service:bicycle:rental, bicycle:rental, rental=bicycle, etc etc (that are often tagged in combination with each other on the same object) and places that don't sell bicycles being tagged as shop=bicycle when they shouldn't be, because they don't sell bicycles. All because we are only allowed to use this tag on bicycle parking stations. It's non-sense, leads to bad/miss-tagging, and doesn't follow convention. So, I think what the tag can be applied to should change to anything that involves bicycle rental. Instead of us being hamstrung with only one type of object we can use it on while leaving every other type of bicycle rental place flapping in the wind to be tagged as shops. --Adamant1 (talk) 13:55, 6 June 2020 (UTC)

New rental concept needs tags

There is a trend of new rental shop that is not a go and rent bicycle, but a suscription based rental. These are for example https://swapfiets.com/ or https://www.kleta.com/.

I would propose to differentiate them from normal rental.

I'm thinking of:

bicycle_rental=renting or bicycle_rental=subscription

--Pantufla (talk) 16:49, 6 November 2023 (UTC)

bicycle_rental=* is about a physical format of the rental; i.e. is the rental manned by staff, automated by a payment or membership card, or requires a physical key. Do not confuse that with business-related decisions (like is it pay-per-ride or subscription based). In fact, I'd say that majority of bicycle_rental=docking_station are subscription based (in whole or partially). If you want to indicate that bicycles are only available on subscription, use membership=required (or membership=yes if there is membership, but also alternative arrangements such as pay-par-hour/day exist too). If access to the area with bicycles is limited (e.g. card is required to unlock the doors to reach the bicycles), use access=customers+membership=required on that area. --mnalis (talk) 17:24, 6 November 2023 (UTC)

How to tag branded/sponsored networks?

In the tag description tfl_cycle_hire is mentioned as an example value for the network key. This network however is branded under a different name (sponsor), see [3]. Should we in that case (and similar cases where all signage is different from the network owner/organiser) therefore change the "network" value accordingly or should we add an additional "brand" tag?

Key:authentication=

I would like to get opinions on using Key:authentication for bike share stations. Whereas many bike share systems used to have mostly stations with kiosks, where one could buy passes as well as unlock bikes, nowadays there are many systems that have kioskless docks, where bikes can only be unlocked with a key fob or mobile app. Current tagging guidance only includes Key:payment, but the authentication scheme (currently used for electric vehicle charging stations) would be a good addition in my opinion. I'd be happy to draft something up for the wiki. --Hobbesvsboyle (talk) 11:05, 12 October 2021 (UTC)

Hi Hobbes, Maybe just start tagging a few, and once you have something that works, add it on the wiki. The authentication-tagging scheme is quite well understood and in-use, so this isn't such a big change. I'm also working on an editor specifically for bicycle rental, so I'll be happy to include authentication as well Pietervdvn (talk) 23:36, 7 November 2021 (UTC)

Tagging the different types of bicycle rental

Hi all, I'm aware that the "amenity=bicycle_rental"-tag could have been better. Right now, there are various and multiple types of bicycle rental one can distinguish:

• A staffed shop renting out bicycles as core business (e.g. geared towards tourists). Proposal: either use bicycle_rental:type=shop OR add shop=rental, rental=bicycle, or add shop=bicycle_rental, or a combination of those.
• In touristical regions (esp. the belgian coastline), there are rental shops renting bikes, go-karts, skeelers, ... Proposal: retag these an additional shop=rental and rental=* to those.
• A bicycle shop which also rents out bikes. These should be tagged with shop=bicycle and an additional service:bicycle:rental=yes
• Another amenity (e.g. a hotel or B&B) which offers bicycles for rent - possibly to anyone, possibly only to their guests. These get tagged with the respective tagging (e.g. tourism=hotel and receive a service:bicycle:rental=yes or maybe service:bicycle:rental=customers?
• There are also recreation parks having their own, private bicycle rental shop. These might get an additional access=customers. In the same vein, there are bicycle rental amenities for students, staff of universities which get similar tagging.
• A docked system (such as the Transport For London bikes), typically for short trips (<30minutes) and where one can leave their bike at a different dock. Proposal: add bicycle_rental:type=docking_station on them, with ofc. the network information (and perhaps a relation linking them, or a wikidata link, ...)
• Systems where one gets a bike at a fixed location and has to drop their bike at this same location again (e.g. Blue Bike in Belgium) - typically with a machine to retrieve the key... (Proposal: add bicycle_rental:type=key_dispensing_machine)
• ... and the variation where there is a (signposted) drop-off location, but the 'smart locks' are unlocked with an app (Proposal: bicycle_rental:type=dropoff_location). (One could also map the bike parking as area an additionally map the key_dispensing_machine, allthough this might get confusing)
• There are also apps with fixed parking locations, but without any infrastructure (e.g. Donkey Republic). This is merely a virtual drop-location and are on the edge of verifiability. I propose to offer a key for them (e.g. bicycle_rental:type=virtual), but clearly state that these should _not_ be mapped as they are hard to verify, have little value and are hard to maintain). This is mainly to retag already existing such points and to open up discussion about them.
• And at last, there is the free-floating system of bikes. This is not relevant for OSM, but I mention them here for the sake of completeness.
• (Also: an honourable mention for amenity=bicycle_library, which could be seen as a bicycle_rental too but is distinct enough to get their own key)

I'm planning to create a MapComplete theme for bicycle rental and would like to improve the tagging scheme for this. Disclaimer: I'm getting paid to create this theme by a touristical agency, but unaffiliated with any rental service.

Please discuss!

Pietervdvn (talk) 23:33, 7 November 2021 (UTC)

" bicycle_rental:type=shop OR add shop=rental, rental=bicycle, or add shop=bicycle_rental, or a combination of those." - we already have shop=bicycle + service:bicycle:rental=yes. But note that amenity=bicycle rental is perfectly fine for places where you may rent a bicycle and do basically nothing else, maybe except minor repairs

shop=rental, rental=bicycle, or add shop=bicycle_rental would be duplicating shop=bicycle + service:bicycle:rental=yes

bicycle_rental:type=shop seems fine

Mateusz Konieczny (talk) 09:23, 8 November 2021 (UTC)

service:bicycle:rental=customers seems a good idea if it is available solely for their customers Mateusz Konieczny (talk) 09:24, 8 November 2021 (UTC)

"I propose to offer a key for them (e.g. bicycle_rental:type=virtual), but clearly state that these should _not_ be mapped" - just mention it without offering key if mapping them would be a bad idea Mateusz Konieczny (talk) 09:25, 8 November 2021 (UTC)

I added `bicycle_rental=virtual` to the list after all with a big strikethrough. Even though I agree that _not_ proposing a value would be better, I added this because someone added this to the wiki page and stated that these are a valid value for dropoff points which have a painted area on the floor! To avoid having this value co-opted and spread out, I marked the territory for them... Pietervdvn (talk) 23:07, 26 July 2023 (UTC)

Proposed features/bicycle rental:type now exists (I added an image there, feel free to revert it if something went badly) Mateusz Konieczny (talk) 15:57, 9 November 2021 (UTC)

关于共享单车 About the Shared Bikes

有些城市在共享单车运营区域的规范停车区设立了P点（不是虚拟的），人们只能在P点锁车，这些P点可以使用这个标签吗？Herman Lee Zh (talk) 10:46, 26 January 2022 (UTC) Some cities marked some areas (not fictional) for peoples locking their renting shared bikes, should we need to map these areas with this tag?Herman Lee Zh (talk) 10:46, 26 January 2022 (UTC)

Excellent question. As such a parking space can hold various operators, I'd propose you tag this with `amenity=bicycle_parking; access=rental_bikes` or something like that. —Preceding unsigned comment added by Pietervdvn (talk • contribs) 12:22, 26 January 2022 (UTC)

我也关注这一个话题了，我是今天看到北京的公共自行车都停止运营，让步给商业共享单车。因此我在找有没有合适的tag用来标记。电子围栏因为没有实地物件是没法标注的，但我们可以标注画出来的停车区域。对于这些停车区域应属于“自行车停车处”（amenity=bicycle_parking）。而bicycle_rental=*更多指的是租赁模式，我其实想提议一个bicycle_rental=shared_bicycle来专门指共享单车这种扫码/向车上投币的使用方式。（如下是共享单车不符合现有三种标签的依据，可能只有bicycle_rental=dropoff_point是包含共享单车的模式的）
① 目前的bicycle_rental=shop是专门的出租店，而共享单车没有店面
② 共享单车大部分是无桩的（政府设立的公共自行车大多数是有桩的），因此不是bicycle_rental=docking_station
③ 共享单车不用钥匙，因此不是bicycle_rental=key_dispensing_machine
因此最终我的看法是：bicycle_rental=dropoff_point/shared_bicycle + amenity=bicycle_parking
--快乐的老鼠宝宝 (talk) 17:01, 7 September 2022 (UTC)

My Translation: I noticed this topic today because I removed all closed down bicycle rental point in Beijing, those place then become commercial shared bikes parking area. I want to find a proper tag to mapping them. For electronic fence, because its virtual and don't have on ground object, I don't think we need to map it, but only mapping the marked parking area. I think those area can be tagged with amenity=bicycle_parking. Besides, I think bicycle_rental=* means how it rentaled, so I want to propose a bicycle_rental=shared_bicycle for those shared bikes that need to scan a QR code on APP. (Maybe only bicycle_rental=dropoff_point suitable for this situation)
--快乐的老鼠宝宝 (talk) 17:07, 7 September 2022 (UTC)

Reference picture for "Shared Bike"(共享单车)

--快乐的老鼠宝宝 (talk) 17:43, 7 September 2022 (UTC)

bmx for muddy areas and crazy_bikes

While translating this page to Italian, I had some problems with the rental values "bmx" and "crazy_bikes". In Tag:amenity=bicycle_rental#Types_of_bicycles_and_accessories it is said that a bmx is "A sturdy bike, typically to drive in muddy areas"; isn't that the definition of mountain bike (or mtb)?

As for the second term, I find it difficult to understand the definition of a "crazy bike" and the fact that "This kind of rental mostly doubles as touristical attraction". I'd like to see a picture of this kind of bikes.

Thanks in advance --Marcor (talk) 13:31, 30 April 2022 (UTC)

> Hi Marcor: bmx was a mistake and should have been mtb from the start. I've added a link to a crazy bikes example Pietervdvn (talk) 00:33, 1 May 2022 (UTC)

rental=disabled

These are sites/shops for the rental of many different style of bikes to suit various disabilities.

https://www.warmleywaitingroom.co.uk/about/warmley-wheelers/

Any reason why it shouldn't be in the list? --DaveF63 (talk) 13:20, 9 May 2022 (UTC)

These types of bicycles can definitively be listed as (bicycle)rental types too. Keep in mind that rental is used amongst many rental facilities, so the values must be a bit more descriptive then just `rental=disabled`, e.g. `rental=wheelchair_bike;tricycle;duo-bike`,... (If I'm in a mean mood, I might interpret `rental=disabled` as a service where one can hire a disabled person to do some chores for me... And these bikes might also be rented by non-disabled people, e.g. someone wants a duobike to make a trip with their kid or a wheelchair-platform-bike to move some goods).

I've sent an email to https://gfietst.be/ too a while back with the request to reuse their images, but didn't receive an answer.

The main reason that these types of bike aren't listed yet, is that no-one took the time yet to add them (searching their proper name, adding description and getting a good picture takes quite some time), so I can only encourage you to pick this up! Pietervdvn (talk) 12:15, 9 May 2022 (UTC)

capacity=unlimited

@Wombatmaper: has this capacity=unlimited been discussed anywhere? It does not make sense to me. Perhaps the places are not marked, but there is certainly some limit (so it not unlimited). Can you park 100 bicycles there? Thousand? A million? A billion? At some time you'll hit a limit: that is forced upon us by the reality of physical 3D world.

So I would instead estimate how many can be parked in such amount of space, put that estimate (e.g. capacity=50), indicate that the parking places are not individually marked with markings=no and add source:capacity=estimated to indicate the number may not be exact (if one wanted to provide as much information as possible).

Also, capacity=unlimited has very low usage count (just ~150 worldwide, which is maybe `0.005%` of the usages), and it is not even documented in the wiki, so it is unlikely data consumers will be able to cope with it. I would advise against using it. --mnalis (talk) 20:57, 25 June 2025 (UTC)

I posted a thread in a forum a while ago and no one had any objections, but I can't seem to find that thread now. So I guess this is the best place for a discussion?

Similarly to how we don't tag roads without a speed limit as maxspeed = lightspeed, I believe the physical constraints matter less here. Instead, I believe this value should be used to say "This rental system does not impose a limit on how many bikes may be parked here", which I believe is more useful for most users. Additionally, in my experience, in most bike rental system the limiting factor is not the amount of area but the amount of bikes available in the system as well as how dense the users park.

An estimate on how many bikes can be parked is also very much in the eye of the beholder, especially if you consider that many of these dockless stations function with a radio transmitter, where the radio waves that allow parking can travel up to dozens of meters, and depend on stuff like weather and interference, from, for example other bikes.

Am I understanding right that you argue that we should not add it to the wiki because it is not already in the wiki? Because that seems like a bit of a circular argument to me. Same as arguing that we should not use it since it is not being used very much.Wombatmaper (talk) 22:13, 25 June 2025 (UTC)

Sure, wiki is fine place to discuss (if clunky), if you prefer. If you do find a forum post, it would be useful to link it here for background (and also likely easier to continue discussion there). I was also unable to find a match ah community.openstreetmap.org when searching for "capacity=unlimited". In general, it is considered best practice when opening a forum thread about tagging to also link to it from that wiki talk page to the forum discussion, so interested parties may follow.

Will create a forum post tomorrow.

As for the maxspeed=*, note that that tag is about legal limitations only. So maxspeed=none (which is a real existing tag) means there are no legal limitations placed by legislators. There also exists maxspeed:practical=* which is used to indicate what are the speeds you may expect to accomplish in physical reality. You'll notice that it does not have a maxspeed:practical=lightspeed value as that would not be true, due to level of human technological advancement and road conditions among other things. capacity=* is also about about physical reality too (like maxspeed:practical=*) and not about legal restrictions. If there existed say additional different tag like capacity:legal=*, then I agree it might perhaps have sense to tag capacity:legal=unlimited to indicate that there exist no legal limit on maximum number of vehicles, but that one is limited only by physical space (indicated by capacity=some_integer_value). But tag capacity=* itself would still be about how many it is physically suitable for.

I think this is the key point we disagree on. For leisure=stadium or amenity=cinema capacity is not used to describe how many people can physically fit into a stadium, but how many (for legal / safety reasons) will be sold tickets. Similarly for amenity=kindergarten or amenity=school, where we describe the amount of pupils a school can legally teach, not how many can physically fit into the school.--Wombatmaper (talk) 23:44, 25 June 2025 (UTC)

As you say, it may well be that the limited factor is amount of vehicles that the rental company has, but that is not the purpose of capacity=* tag. For example, if some new startup rental had just 10 bicycles altogether, and they build a new docking station which can hold 15 bicycles (e.g. they were planning for the future), one should mark that docking station as capacity=15, and not capacity=10, even if the company never grows and always has only 10 bikes.

I agree with you that if the capacity=* is a guess, it may vary (which is not ideal!), so you should use markings=no and add source:capacity=estimated tags that I mentioned to indicate that it is such a guess. But even a bad guess is much better source of information than (provably untrue) "unlimited" (i.e. infinite) number of dropoff spaces. Note that while there are also some uses of ranges, e.g. capacity=100-250 and similar, I would advise not to use that, and to stay with simple integer if you prefer the data to actually be used by data consumers. (and isn't that why we map things? So the data will get used and benefit someone?). Also another alternative is to tag it as a polygon instead of a node (so its physical area is known), and omit any capacity=* tag at all. Then the data consumers themselves could estimate from the available area how many bikes might be dropped off there.

As for the last paragraph; yes, you misunderstood (thanks for checking!). My intention was not to prevent you from mapping or documenting things (to the contrary! thanks for doing that!); it was merely to inquire about a reasons you've had for it and to set up expectations - to make you and other people aware that unless that tag is documented and/or more wildly used (and preferably both!), that this data is going to be ignored by vast majority (or more realistically: all) data consumers. Also, I'm not trying to forbid you from using it, far be from it! So, if you want to ATYL, you're absolutely free to do so, and I'll defend your right to do it to the bitter end! But if you're not convinced of advantages of tagging estimated number of spaces instead (which I was hoping to convince you is a better approach), you should preferably at least document that capacity=unlimited tag (just click on that red "unlimited" word here!), and add a sections about its usage, but also its advantages; e.g. how you envision it may be used in practice, and why it is better than more informative alternatives like estimated capacity. --mnalis (talk) 23:29, 25 June 2025 (UTC)

Ah sorry, misunderstood, thanks for clairifying!--Wombatmaper (talk) 23:44, 25 June 2025 (UTC)

How to tag that a certain type of bike is NOT available for rental?

Is there a way to indicate yes/no on bicycle types (e.g., city, road, gravel, MTB, etc.)? This could save map users a ton of time calling around various bike shops trying to see if they rent the type of bike that they are looking to rent. For mountain bikes, for instance, I think rental:mtb=yes/no would be a more informative tagging schema than simply rental=mtb. Thanks -Osmedit (talk) 17:07, 14 October 2025 (UTC)

See page https://wiki.openstreetmap.org/wiki/Rental_namespace_standardisation - Osmedit (talk) 18:39, 14 October 2025 (UTC)