Talk:Tag:amenity=bicycle parking

Discuss Tag:amenity=bicycle parking here:

---

fee= tag

Resolved: "fee" is now described on the main page, and it's probably best to use that --achadwick 18:11, 3 May 2011 (BST)

Using the tag fee=* is the recommended way for other potentially non-free amenities (eg. parking, toilet) (vs. paid=* above ) Alv 13:36, 28 January 2008 (UTC)

See Proposed features/Price tags for a discussion - fee=yes/no is surely too similar to free=no/yes. Ojw 18:44, 28 January 2008 (UTC)

"capacity" is used often instead of "spaces". On Opencyclemap "capacity" seems to be the ordinary tag. [1]--KartoGrapHiti 17:16, 19 October 2008 (UTC)

• I've incorporated these changes onto the main page

Old Vote

Resolved: Voting passed. Now on Map Features

• I approve this proposal. FredB 13:35, 12 May 2007 (BST)
• I approve this. --Damian 15:13, 12 May 2007 (BST)
• I approve this. --Gregoryw 23:36, 12 May 2007 (BST)
• I approve this proposal. (for node and area as spaetz suggested above)Ben 14:18, 13 May 2007 (BST)
• I approve this too. --Kumakyoo 17:05, 14 May 2007 (BST)
• I approve this proposal. (for both node and area) --Thewinch 14:52, 18 May 2007 (BST)
• I approve this. -- motp 22:58, 9 November 2007 (UTC)
• I approve this proposal. Tric 18:58, 11 November 2007 (UTC)
• I approve this proposal. Longwayround 13:43, 6 January 2008 (UTC)
• I approve this proposal. --Uwe Hermann 00:16, 28 January 2008 (UTC)
• I approve this proposal. --Polyglot 14:53, 28 January 2008 (UTC)

Area too?

Resolved: Yes, areas are fine for cycle parking --achadwick 18:12, 3 May 2011 (BST)

Just thinking about the bike parking at Oxford station, or some of the multi-storey monsters in Amsterdam. Ignore me. It was from the start; main page was just missing a sensible description.

Legacy tags

Unresolved: OSM database issue. How many remain? I've been lazy. --achadwick 18:13, 3 May 2011 (BST)

(Comment moved here when cleaning up the main page --achadwick 20:28, 9 March 2009 (UTC)) "We may need to convert some existing amenity=cycle_parking tags. [2]"

Types of stand/locker/whatever

Resolved: Now has its own page: bicycle_parking=*. I'll move the discussion to its talk page --achadwick 17:30, 3 May 2011 (BST)

It would be useful to know what kind of bike parking one can expect when visiting an area, and the main page already hinted at different types of stand and rack before I had a go at cleaning it up. I think it would be helpful to tag types of parking in a similar way to what our sister tag, parking=* does with parking=surface/multi-storey/underground/park_and_ride. But describing the form and thus hos secure the stand is to lock your bike to. What about

(Table removed: it's been fully written up at bicycle_parking=*) --achadwick 17:41, 3 May 2011 (BST)

Probably the most basic concept of bike parking is that you have the ability to lock your machine up without it falling over. Hence I've not listed simple slots in concrete,

bicycle_parking=rack?

Resolved: Subtype discussion moved to bicycle_parking=* --achadwick 17:41, 3 May 2011 (BST)

Comments on "bicycle_parking=*" subtag

Resolved: Seems to be in fairly widespread use and now has its own wiki page --achadwick 17:41, 3 May 2011 (BST)

Any takers? --achadwick 21:22, 9 March 2009 (UTC)

• I'm not sure about plural vs. singular for the key values. Thoughts? --achadwick 21:22, 9 March 2009 (UTC)

Multi-level bicycle stands?

Resolved: Subtype discussion moved to bicycle_parking=* --achadwick 17:41, 3 May 2011 (BST)

See also

Stale: Link is dead, but accessible via archives. It was just for information anyway. --achadwick 17:48, 3 May 2011 (BST)

• DfT "Key elements of cycle parking provision"

Open issues

Unresolved: Probably needs splitting too --achadwick 17:48, 3 May 2011 (BST)

• In the Netherlands we have moped only parkings, so i'm using amenity=moped_parking for it.. --Rubke 22:26, 26 August 2009 (UTC)
• Further more we have guarded parkings, how should i tag those ? --Rubke 22:26, 26 August 2009 (UTC)
  • Could we extend the access tag cover this? If necessary we could use come up with something like a security=none/lockup/guarded/cctv/??? designation, although I've never needed to use any of these values so we may only need something simple. Ash 00:28, 11 December 2009 (UTC)
• Perhaps bicycle_parking=enclosure would be better than shed or building, as it can refer to either, as well as other similar structures? Ash 01:42, 11 December 2009 (UTC)
  • See bicycle_parking=* for full discussion of this --achadwick 17:48, 3 May 2011 (BST)

Stand types and varieties

Resolved: Please use surveillance=* for CCTV --achadwick 18:01, 3 May 2011 (BST)

Resolved: Types of bike stand are under discussion at bicycle_parking=* --achadwick 18:01, 3 May 2011 (BST)

I've been beginning to make note of the type of cycle parking that is available at any given node. I feel that this tag, along with capacity=* -- and other such as covered=yes/no and cctv=yes/no -- could aid in producing a complete cycle parking map for (at least) metropolitan areas. I'm suggesting using standard names for cycle stand types, and semi-colons can be used as normal where more than one stand type exists.

• type=sheffield -- Sheffield stands are (without a doubt) the most common cycle parking infrastructure.
• type=a-frame -- A-frames are similar in general feel to Sheffields, but have a crossbar between 1/3 and halfway up the stand.
• type=toastrack -- toastracks, toast racks, toaster racks, w/e; not terribly useful (because one of your wheels is always on one of the stand's bars), but they are frequently around
• type=* -- pretty much every type of stand can be added to the map, but one should try to tag with common names

Feedback would be a great thing and I would like to thank you for your patience. --Kevin Steinhardt 11:27, 9 December 2009 (UTC)

I think you posted this to IRC, and I've gone and added a few notes to the bicycle_parking= section not realising it wasn't the bit you were working on. This seems to be much the same kind of proposal though. Are any of these tags in use right now? Ash 02:04, 11 December 2009 (UTC)

Never touched IRC in my life. :P I posted this proposal to my diary and there's a couple of comments there. capacity=* is well within use; covered=* is less frequent, and I'm not sure about cctv=*. Kevin Steinhardt 19:26, 12 December 2009 (UTC)

For CCTV, please use surveillance=*. It's quite well established! --achadwick 18:01, 3 May 2011 (BST)

Regarding types, something is emerging: see bicycle_parking=*. I've been moving some of the discussion to it's talk page. Personally I don't much care for keys named "type" because they could apply to any sort of OSM object ☹ --achadwick 18:01, 3 May 2011 (BST)

Bicycle parking buildings

Some bicycle parkings are actually whole buildings with several floors etc.. So far, I have used building=* with building:levels=* for that (ie. 30582233 30582233 and 30582492 30582492). Is that the correct way tag those? --hangy 00:17, 23 May 2010 (UTC)

Looks good to me, and s are fine for cycle parking. You've got a few options even within this: If it's a purpose-built building for cycle parking and it's fairly imposing, you might want to say building=bicycle_parking to express that a bit more deeply. If the building was built for something else originally but is used entirely for cycle parking now, you might want to use that "something_else" as the building key's value (and tag it as cycle parking too). Finally, if just one end of a building is used for cycle parking, use one for the building itself, tagged appropriately, and place a separate amenity=bicycle_parking within it at the appropriate place --achadwick 18:10, 3 May 2011 (BST)

SVG

I propose this file as image: http://page.mi.fu-berlin.de/pborgers/bicycle_parking.svg Based on wikipedia material. Feel free to use.

Motorcycle parking?

Unresolved: Similar, but not the same. You probably shouldn't use amenity=bicycle_parking for this. --achadwick 18:20, 3 May 2011 (BST)

Parking for motorbikes. Sometimes with really fat metal bits.

File:Motorcycle-parking.jpg

Motorcycle parking

What's the tag?

-- Harry Wood 21:27, 29 June 2010 (UTC)

Since the photo seems to imply that parking is next to the driving lane, it would be parking:lane:left=orthogonal ; parking:condition:left=free ; parking:condition:left:vehicles=motorcycle, see Talk:Proposed_features/parking:lane#Specifying_the_vehicles_allowed_to_park. Example rendering looks like this: (diagonal motorcycle parking). Kay D 15:13, 16 July 2010 (UTC)

amenity=motorcycle_parking would be my choice, and it seems fairly popular: http://taginfo.openstreetmap.de/search?q=motorcycle%20parking#values . Anyone want to document it and make it a thing? --achadwick 18:20, 3 May 2011 (BST)

Assessing capacity=*

Designers have sometimes the weirdest ideas. What's the capacity for this bicycle stand?

Just estimate how many bikes could be parked without locking them together. My value would be 12 or 15. Hadhuey (talk) 15:10, 20 September 2014 (UTC)

Something between many and quite a few ;-). Agreed: you can estimate, a wrong number (if an estimation!) is still OK.--Nospam2005 (talk) 10:04, 9 April 2022 (UTC)

Capacity for "stands"

For rendering purposes, I would like to know the number of individual stands in a bicycle_parking=stands. As there is no tag that stores this piece of info directly, I need to infer this from capacity. So, how many bikes per stand? 2? --Tordanik 14:42, 24 April 2015 (UTC)

It depends on bicycle_parking=*. It may be: 2N, N+1, N. In my area the most popular design is bicycle_parking=wall_loops - so I would expect N slots, not N + 1 or 2N. You can add column "estimated capacity=*" at Key:bicycle_parking. Xxzme (talk) 15:17, 24 April 2015 (UTC)

owner/ownership

Hi, The list of common tags includes operator but not owner, when in many instances it would seem to me that owner (and ownership) is more appropriate. I have the list of bike parking installed by the City of Hobart, so they own the parking, but most have been tagged previously with operator.

I typically tag with operator=*/operator:type=* but there is also owner=*. I prefer operator, as it is usually verifiable/surveyable while ownership would often require going through an involved legal research Mateusz Konieczny (talk) 10:21, 13 July 2020 (UTC)

Bike Capacity for Wave Type Stands

What’s the typical formula to follow for adding bike capacity for wave-type (essentially multiple U-type) bike stands? For example what’s the capacity for a bike stand with three upright U’s and four upside down U’s?--IanVG (talk) 17:07, 20 February 2021 (UTC)

• 

  Wave Type Bicycle Parking

Edit: Picture and typo (comment by IanVG)

• @IanVG: It depends on location of stand, width of each U and other factors. Additional question: is this stand intended to be used and used in this way as on photo? I expect bicycle to be laid parallel to the stand - depicted position seems really unstable Mateusz Konieczny (talk) 21:56, 20 February 2021 (UTC)

@Mateusz Konieczny: Okay, I found a manufacturers description of the rated capacity of this kind of bike parking, here. So from this reference I would gauge this bike parking capacity to be 9. --IanVG (talk) 15:03, 6 March 2021 (UTC)

Following the same thread, the ring style bike bollard would be able to hold two bikes.

Ring Style Bike Bollard with Two Bike Capacity

Inverted U-Type Bicycle Parking with Two Bike Capacity

Inverted U-Type Bike Rack, each with a capacity of two bikes.

Wide Spaced Grid Bike Rack with 22 Bike Capacity

Coil or Spiral Bike rack with 11 Bike Capacity

Triangle Type Bike Rack with maybe a capacity of 12 or so.

--IanVG (talk) 15:14, 6 March 2021 (UTC)

In fact if it's okay, I think these pictures may serve as good starting points for others curious about how to add the capacity tag-value to bicycle parking. --IanVG (talk) 22:22, 6 March 2021 (UTC)

9 on that first picture makes sense to me. Since you could have seven bikes in the inside loops and then one on each outside end. I think that totals 9. Going by that logic you could have 3 bikes on the Inverted U-Type Bicycle Parking rack though. One in the middle and one on each side. With the Wide Spaced Grid Bike Rack you could technically do 24. Except two would out of the green lines. So maybe they wouldn't count. --Adamant1 (talk) 11:41, 5 June 2021 (UTC)

@Adamant1: I sort of see what you're saying about the Inverted U-Type Bicycle Parking stand, but I am currently running with what I have seen more often in my city and what manufacturer of these bicycle stands have stated which is that normally two bikes can be stored here. If two bikes were stores in the inverted U-type bicycle stand on the outer ends, then it would make it pretty difficult/almost impossible for people with U-locks to be able to store their bikes in the middle. I am going to run with two bikes for that kind.--IanVG (talk) 01:29, 17 August 2021 (UTC)

Bike Stand Conversation

I am mapping/analyzing my campus' bike infrastructure and, and have been following the one feature one object OSM best practice guidelines in doing so. However, Although I am able to count how many bikes are able to stored in a given area, I am not able to tell how many individual pieces of infrastructure (i.e. individual stands, loops, racks whatever) are used to store this number of bikes. It's kind of bugging me that there doesn't seem a way to add this piece of information. Does anyone have any suggestions on how best to do this? I was thinking maybe using a namespace tag, like maybe bicycle_parking:count= or something like that. --IanVG (talk) 16:23, 5 August 2021 (UTC)

I assume your talking about a bicycle parking area with multiple bike stands that your mapping as an area? If so, there's various tags for the number of stands. For instance bicycle_parking=stands + stands=*(whatever number of them there are) has like 20 uses. There's also 84 uses of parking_stands=Whatever_number. Which isn't much for either, but still more then if you invented a unique tag for it. On that, I wouldn't do it. Since "count" doesn't really say anything meaningful and it doesn't follow pre-existing tagging conventions either. --Adamant1 (talk) 06:27, 7 August 2021 (UTC)

@Adamant1: No, I am not talking about a bicycle parking area with multiple bike stands, I am talking about amenity=bicycle_parking as a node. The one feature one object best convention has led me to map multiple grouped-together individual bicycle parking stands (two to five or so stands doesn't really merit an area in my opinion, although it could be mapped as an area) as individual nodes. But thanks regardless for the references, they will work equally well for a node. I wasn't suggesting that my method was the right one, only that I wasn't aware of any others. IMO "count" in the absence of any other tag did add something meaningful, but other pre-existing tags seem to already get to the point as well. Thanks for pointing out there are others already in use. I am going to go with parking_stands=. --IanVG (talk) 01:25, 17 August 2021 (UTC)

How to map "locky dock" locking station + charging?

A bicycle locking station that includes power for charging, also allows scooter parking.

https://www.stuff.co.nz/environment/climate-news/300010373/ebike-charging-and-locking-stations-coming-to-christchurch

It already is amenity=bicycle_parking, so can't also be amenity=charging_station

It depends on why you need to specify this property. There is a namespace tag
service:bicycle:charging=yes/no/fee/free — you can charge e-bikes/pedelecs (bicycle assisted by a small electric motor)
See also: shop=bicycle
— Grass-snake (talk) 12:23, 14 October 2021 (UTC)

Values bicycle_parking=shed and bicycle_parking=building

All other values (except 'shed' and 'building') proposed for 'bicycle_parking' characterize a way to hold the bicycle, to lock it, to stand it, etc. The two values ('bicycle_parking=shed' and 'bicycle_parking=building') seems odd in this list !

So if today the bicycle parking is a 'shed' bicycle_parking=shed, we should rather keep 'bicycle_parking' tag to characterize the way the bicycle is hold/locked in the shed (are they 'wall_loop' or 'stand' ?) and add a tag building=shed on the node (if it is a node) or change the value of the 'building' tag to 'shed'
amenity=bicycle_parking
bicycle_parking=*
capacity=XX
building=shed

So if today the bicycle parking is a 'building' bicycle_parking=building, we should rather keep 'bicycle_parking' tag to characterize the way the bicycle is hold/locked in the building (are they 'wall_loop' or 'stand' ?) and add a tag building=yes on the node (if it is a node)
amenity=bicycle_parking
bicycle_parking=*
capacity=XX
building=yes

Barnes38 (talk) 15:35, 12 March 2022 (UTC)

There are several problems here. building=yes+amenity=bicycle_parking may represent either locked shed/building or covered stand/wall loop. So you would still need bicycle_parking=shed and bicycle_parking=building. In addition in many cases bicycles are not locked at all within shed/building or that is impossible to survey Mateusz Konieczny (talk) 15:47, 12 March 2022 (UTC)

yes, ok. covered=yes only means the bicycle parking is covered, and does not mean that bicycle parking is inside a building or inside a shed (in these cases the covered=yes is implicit and not necessary) ? Bicycles may or may not be locked inside a shed or a building : when these sheds/buildings are shared by several people, most often bicycles needs to be locked ? I agree that inside a building which is totally closed, it is impossible to survey and provide a rigth value for bicycle_parking, but quite often the inside is visible from outside ? Barnes38 (talk) 06:42, 13 March 2022 (UTC)

bicycle_parking:indoor=* ( for bicycle_parking=building) and bicycle_parking:outdoor=* would be better replacements. bicycle_parking=shed could be converted to covered=shed, similar to covered=booth. This allows showing of the parking mechanism inside, especially for underground and multi-storey ones (which could be combined with location=*). Kovposch (talk) 11:12, 13 March 2022 (UTC)

You still need value for "closed shed with bicycles, no idea what is inside" and to distinguish between "unlocked bicycles not attached to anything" and "unlocked bicycles not attached to anything in a closed shed" Mateusz Konieczny (talk) 07:39, 14 March 2022 (UTC)

To distinguish the cases you speak about:

1) "closed shed with bicycles, no idea what is inside" => amenity=bicycle_parking; building=shed; bicycle_parking=* is only set if it is known,

2) "unlocked bicycles not attached to anything" (bikes stand on their own stands?) => amenity=bicycle_parking; bicycle_parking=*,

3) "unlocked bicycles not attached to anything in a closed shed" (bikes stand on their own stands?) => amenity=bicycle_parking; bicycle_parking=*; building=shed. Barnes38 (talk) 12:10, 16 April 2022 (UTC)

Yes, I understand, but wish to explain again, "bicycle_parking=building" and "bicycle_parking=shed" are orthogonal to all other values (stands, wall_loops, racks, anchors, bollards, lockers, wide-stands, ground-slots, etc.) which all denote the way the bicycle is hold standing, or denote against what the bicycle can be locked. The two values "bicycle_parking=building" and "bicycle_parking=shed" tells that the bicycle_parking is inside a building or a shed. Therefore could be replaced by "building=yes" or by"building=shed" (or as you said "covered=building" or "covered=shed" why not ?): in any case, "bicycle_parking" key is then no more engaged, and can be used to tell what hold standing the bicycle. (see as well just below ) Barnes38 (talk) 12:12, 16 April 2022 (UTC)

How to characterize premises dedicated to park bicycles

Quite recent regulations oblige, in France, real estate developpers to propose shared and private dedicated premises to park bicycles, most often on ground floor of buildings, and close to the main entrance, and this is called in French 'local à vélo'. Shared dedicated premises to park bicyles can exist in any country. There is no clear way of tagging such bicycle_parking so far...
To characterize this kind of premises, it is proposed to use the following way of doing:
amenity=bicycle_parking
bicycle_parking=*
capacity=XX
indoor=room
level=0
access=private

Barnes38 (talk) 15:36, 12 March 2022 (UTC)

I am confused by description. Can you link a photo? Based on description it sounds like bicycle_parking=floor + access=private + indoor=yes + covered=yes Mateusz Konieczny (talk) 15:49, 12 March 2022 (UTC)

The idea s to describe specific premise, at the ground floor of a building, a private room, shared by several people living in this building, dedicated to bicycle parkings, with an entrance (large enough for a bike, locked and safe enough to prevent robbery) very close from the main entrance of the building. This premise is often totally closed and the value of bicycle_parking cannot be easily surveyed. This is almost indoor mapping. Barnes38 (talk) 06:52, 13 March 2022 (UTC)

That is covered by bicycle_parking=building and this proposed replacement seems to not be working well Mateusz Konieczny (talk) 07:40, 14 March 2022 (UTC)

Nope, what @Barnes38: is trying to say is that bicycle_parking=building and bicycle_parking=shed are orthogonal to other values. All but those bicycle_parking=building and bicycle_parking=shed explain how the bicycles are hold. The two exceptions explain where they stay. With his proposal you can say how they are hold (thanks to bicycle_parking=*), and as usual if you don't know (for instance because it's a closed and private room) you don't tag. KISS --Nospam2005 (talk) 18:29, 9 April 2022 (UTC)

Yes, that's what I meant Barnes38 (talk) 12:12, 16 April 2022 (UTC)

Note that indoor=room is not communicating that bicycles are locked in, provided by current bicycle_parking=building (also, access=private is not doing this) Mateusz Konieczny (talk) 07:27, 10 June 2022 (UTC)

Yes, but here rather to indicate a room at first floor of a building dedicated for bicycle parking ? This kind of equipement becomes more common now, this is not a specific building, but it's part of the main one ?Barnes38 (talk) 16:06, 31 December 2022 (UTC)

Scooter parking places inside bicycle parking

In my city, they have installed new bicycle parking spaces that include parking for bicycles, cargo bikes and also scooters. Would it be appropriate to add `capacity:scooter=X` as a tag rather than mapping it separately?