Proposal:Bicycle parking=no on not amenity=bicycle parking to indicate absence

Bicycle parking=no on not amenity=bicycle parking to indicate absence
Proposal status:	Draft (under way)
Proposed by:	Malle Yeno
Draft started:	2025-08-20

Proposal

This proposal suggests that:

bicycle_parking=no is a tag that can be added to features which are not amenity=bicycle_parking.
when bicycle_parking=no is used, it means that a mapper has checked a feature for bicycle parking and failed to find any.
bicycle_parking:check_date=* is a tag used in combination with bicycle_parking=no.
when bicycle_parking:check_date=* is used, it indicates when a mapper last checked and failed to find bicycle parking around a feature.

These tags can be used on nodes, ways, and areas that are tagged as something one can reasonably expect to have bicycle parking available, but where none is found.

These tags should not be used on amenity=bicycle_parking since that would be contradictory.

Rationale

Goal

This proposal aims to address the situation where a mapper checks around a feature where one may expect bicycle parking to exist, yet fails to find any. The goal of addressing such a situation is to clarify to mappers and users whether a lack of bicycle parking is due to lack of data (as in "nobody checked") or lack of feature (as in "someone checked, there isn't any") by specifying when and where the latter situation occurs.

This proposal does not seek to adjust how bicycle parking that is present is mapped. Put another way, no change to the positive case is being suggested. Where alternatives are considered, the option that minimally adjusts existing tagging procedure is proposed so that current tagging practice is minimally altered. This proposal aims strictly to document a way of handling the negative case.

As a comparator, consider Key:ref:signed which describes the exact situation handled here but for a lack of signage for reference codes.

Current Case

When a feature that one might expect to have some kind of amenity=bicycle_parking around it actually lacks such a node, no change is made to the map.

Problems arise because of this:

If a feature lacks any nodes with amenity=bicycle_parking, it is ambiguous whether that means no such nodes exist on the ground or whether such nodes do exist but are not mapped.
A user making a decision to go to a feature they would expect to have amenity=bicycle_parking nearby but does not see it on the map is in effect gambling on which of these two situations is the case.
A user who wants to visit features where they can park their bicycle nearby is limited to places where such amenity=bicycle_parking exists or taking the gamble that a feature simply does not have an existing amenity=bicycle_parking mapped. They are not able to filter out places that are known to have no amenity=bicycle_parking.
Mappers wanting to add missing amenity=bicycle_parking may end up visiting places other mappers (or even themselves in the past) have tried searching for amenity=bicycle_parking but failed to find any. If they had known this, they may have made the decision to look for missing amenity=bicycle_parking elsewhere, which would be a better use of their effort.

Future Case

This proposal introduces bicycle_parking=no and bicycle_parking:check_date=* for features that are not amenity=bicycle_parking and ideally, features one would expect amenity=bicycle_parking to be present nearby.

In effect, this proposal expands the usage of bicycle_parking=* by creating and documenting the tag bicycle_parking=no. It also introduces bicycle_parking:check_date=*. Both of these tags are intended for use on features that are not amenity=bicycle_parking.

Introducing these two tags would hopefully do the following:

Clear up the ambiguity between features where amenity=bicycle_parking is not present nearby because it has not been mapped yet (as indicated by a lack of bicycle_parking=no) and where amenity=bicycle_parking is not present nearby because none has been found upon checking (as indicated by the presence of bicycle_parking=no and bicycle_parking:check_date=*)
Users who see bicycle_parking=no will know that they should not expect to find any bicycle parking if they go to a feature, assuming bicycle_parking:check_date=* was soon enough. Where bicycle_parking=no and bicycle_parking:check_date=* are not present, theoretically that means there may be bicycle parking there and they are still taking that gamble.
Users who are not interested in going to features that lack nearby bicycle parking may add a filter to remove bicycle_parking=no while still considering amenity=bicycle_parking .
Mappers looking to map amenity=bicycle_parking can more efficiently decide where to look by using bicycle_parking=no to avoid double checking (unless bicycle_parking:check_date=* is old). Apps like StreetComplete could use this tag to encourage mappers to survey for such features or confirm whether the lack of parking is still the situation in play.

check_date

Because this tag is to describe places where someone failed to find parking, it should also describe how long ago it was since they last failed to find such parking.

Positives

Surveyors can make more efficient decisions on where they map if they know someone else has already checked for bicycle parking.
Users will know not to expect bicycle parking when visiting a feature. This reflects truths about the experience one will have when visiting a feature that are relevant to a substantial base of users.
- Routers and applications can warn users about a reported lack of parking with this information, without impacting ability to route to mapped amenity=bicycle_parking.
Addresses how a lack of parking is relevant information to a user who is looking for parking by resolving ambiguity between unmapped and unavailable parking.
Explicit attention can be called to areas that are verified to have no parking. This can be of interest to user groups looking for areas friendly and unfriendly to cyclists.

Negatives

DB size will increase to accommodate more tags on features that are widespread.
It is debatable whether this fulfills the on-the-ground principle. As one commenter put it, "We usually map what is on the ground, not what is not on the ground."
- On the other hand, a lack of parking reflects a real quality that impacts the experience of a user visiting a feature. It is possible to verify whether a place has no bicycle parking available.
Clarity on which features "one would normally expect bicycle parking to be available on" is going to be a longer discussion
- as a starting point, what about anything tagged shop ?
What distance is considered "nearby" is subjective.
- for validation purposes, a more "obvious" threshold could be used. If something is 10m close to a feature, then it is likely close enough to be nearby.
Without validation tools, this makes mapping bicycle parking more complex as mappers must check nearby features for bicycle_parking=no.
Mappers might get confused about bicycle_parking=no meaning parking isn't allowed vs not available, unless attention is called to access.

Alternatives Considered

Key:service:bicycle:parking

There is an existing service:bicycle:parking= tag that is described as:

The tag service:bicycle:parking can be used to describe if an amenity or facility like hotels (tourism=hotel), restaurants (amenity=restaurant) or shops (shop) have specific bicycle parking services like a garage or a dedicated shed. In addition, attributes such as access, capacity and covered can be used to provide more detailed information about the bicycle parking facilities. It is recommended to map the bicycle parking separately in the map with amenity=bicycle_parking.

This may be a viable alternative to this proposal if service:bicycle:parking=no is possible, but at time of writing, it does not appear that service:bicycle:parking=no is used. Current existing values are yes (58), garage (13), and shed (1). At present, this tag is not being used to mitigate the ambiguity between unmapped vs unavailable bicycle parking.

Given that this service tag has values that seem to contradict the practice of tagging separate amenity=bicycle_parking nodes, I do not want to propose it. There may also be points that can differentiate how service:bicycle:parking is used compared to how bicycle_parking=no can be used.

service:bicycle:parking seems to suggest that the parking in question is a service specifically being provided by a business, which puts the onus on the mapper to determine who the service provider is. bicycle_parking=no asks for an observational claim about parking being near the feature.
- In this same vein, bicycle_parking=no isn't about whether parking is provided as a service. It answers the question of "can I park my bike near/at here at all?" rather than "Is bike parking a dedicated service afforded to customers here?" It's a difference between someone parking their bike at a hotel without being a guest, versus guest service bicycle parking.
service:bicycle:parking seems to be for more "larger bicycle structures" such as garages or sheds. bicycle_parking=no is about anything that is clearly meant to used for bicycle parking, including front-fenders or stands or (potentially) informal structures like railings.
service:bicycle:parking seems to be tailored for service providers like hotels, restaurants, or shops. bicycle_parking=no proposes the same domain of providers be included, but can be generalized to any feature that a user would reasonably expect to find parking, even if no service is provided. A park may be tagged bicycle_parking=no even though nobody is providing you a service at a park.

`bicycle_parking=no` and `bicycle_parking:no:check_date=*`

I considered having the check_date instead be bicycle_parking:no:check_date=* since this seemed to be more technically correct. The situation being checked is that there is no bicycle parking around a feature, especially since in the positive case, you'd put the check_date on the amenity=bicycle_parking.

But I elected not to propose this because:

The key is longer and less human readable.
If a proprietor installs parking after this tag, one could still argue that bicycle_parking:no:check_date=* does not need to be removed (as it was true at the time of checking that there was no bicycle parking). I don't think that's a good idea since it gets into mapping things that were true in the past but not visible now rather than presently true and visible.

Tagging


Element Type	Tag	Meaning	Notes
Node	`bicycle_parking=no` `bicycle_parking:check_date=*`	This kind of node could reasonably have had bicycle parking in or around it. As of the check_date, this element does not have bicycle parking in nor around it.	Even in cases where a node exists within an area (say a POI inside a strip mall), using `bicycle_parking=no` on the node separately from the area can be useful. For example, this allows surveyors to look around some shops in a strip mall and give information about "that part" of the mall, rather than scouring the whole strip mall. It can also specify that while some parts of the mall may offer nearby parking, the area around the POI does not.
Way	`bicycle_parking=no` `bicycle_parking:check_date=*`	This kind of way could have reasonably had bicycle parking along it. As of the check_date, this element does not have bicycle parking along the way.	There may be way elements where parking could be expected, such as on certain boulevards. But I do not think this type will see a lot of usage with this proposal.
Area	`bicycle_parking=no` `bicycle_parking:check_date=*`	This kind of area could reasonably have had bicycle parking in (or around) it. As of the check_date, this element does not have bicycle parking in (nor around) it.	Whether the criteria for areas is strictly "no parking inside the area" or "no parking in or around the area" depends on what the area represents. It's reasonable to use in/around for a building (such as a university hall), but for a open space (such as a park), the criterion would likely just be in.
Relation	N/A	This proposal does not recommend using `bicycle_parking=no` nor `bicycle_parking:check_date=*` with relations. I am unsure what the tags would mean in that context.

Examples


Situation	Image	Tags	Notes
A node one would expect to have bicycle parking lacks parking	Cyclists use banks, so you'd figure a bank would give them a place to park. But you'd figure wrong is some cases! Tagging with `bicycle_parking=no` lets us communicate when this is the case.	(in addition to other tags) `bicycle_parking=no` `bicycle_parking:check_date=*`	This is the intended use case for this proposal.
An area feature one would expect to have bicycle parking lacks parking within or around the area	Parks are mapped as areas, and we should probably only say `bicycle_parking=no` if there's no parking inside the park. (For the record, this is Victoria Park in Regina, which does have bike parking.) University lecture halls are likely to be mapped as areas. In this case, `bicycle_parking=no` if there is no parking in nor around the building since one isn't expected to park a bike indoors in a lot of cases.	(in addition to other tags) `bicycle_parking=no` `bicycle_parking:check_date=*`	This is the intended use case for this proposal.
A feature does not allow bicycle parking legally.	Bikes not being allowed (either to park or in general) is an access issue, not a presence issue.	(in addition to other tags) `access:bicycle_parking=no`	The lack of parking is due to access, so access should be tagged instead.
A feature has low quality parking or inconvenient parking.	An open space marked for bikes may be inviting bike theft. But it's more correct to describe the situation on the node, not to say that there is no parking.	(no change to existing mapping)	The matter is about the quality of existing parking, so it would be misleading to say that parking is missing.
A feature has informal parking such as signs or rails, but no obvious bicycle parking.	A nearby tree shouldn't qualify as bicycle parking, so `bicycle_parking=no` is very justified. A railing that acts as a stand to lock a bike and where such practice is acceptable may not qualify for `bicycle_parking=no`. In the end, users want to know if they can actually get parking for their bicycle, and we should not trick them by saying something may be available when it isn't. Use your judgement but be bold in your editing.	Either: Map `amenity=bicycle_parking` as appropriate and describe the situation, or Add `bicycle_parking=no` and `bicycle_parking:check_date=*` where your judgement says the "parking" is not effective to that role.	This is a grey area and mapper judgement may be needed. Tagging as `bicycle_parking=no` may be appropriate in many cases.
A feature used to be tagged as `bicycle_parking=no`, but it now has `amenity=bicycle_parking` nearby or within. Or, someone tagged a feature as `bicycle_parking=no` and `bicycle_parking:check_date=*`, but you found some `amenity=bicycle_parking`.	So your local business owner converted a car parking spot into a bike spot. Yipee! Let's map that and not say that there's no parking anymore.	Both: Map `amenity=bicycle_parking` as a separate node/way, and Remove `bicycle_parking=no` and `bicycle_parking:check_date=*` from the feature.	It is no longer the case that the feature lacks bicycle parking, so `bicycle_parking=no` and `bicycle_parking:check_date=*` are no longer correct and should be removed.

Considerations

Not Present vs Not Allowed? Only for Not Present. Use Access for Not Allowed.

A comment put forward in the OSMUS slack suggested that bicycle_parking=no does not clarify whether a feature lacks parking or prohibits bicycle parking.

A search in taginfo for bicycle_parking=no shows the tag being used on line features where one would assume you cannot legally park a bike, such as on freeways (though whether that tag is used like that due to signage or logical conclusion is unknown to me).

For this proposal: bicycle_parking=no means that parking is physically not present. Access tags already exist to describe legal and signed restrictions.

A key such as access:bicycle_parking=no or similar would be more appropriate. Access tags have the added benefit of already covering nuances such as conditional restrictions. Even if the ambiguity is present or a mapper makes this mistake, bicycle_parking=no provides the correct answer to "can I park my bike around here?" in both cases.

To summarize, this proposal is just for the physical presence of parking. Legal and signed restrictions are out of scope and best handled through access tags.

Not Present vs Not Convenient? Only use for Not Present. Map inconvenient parking.

Proprietors may elect to offer bicycle parking but place it behind the facade of their establishment or in a place that is not convenient for a user looking to park their bicycle. Should the lack of convenient parking justify the use of bicycle_parking=no on a feature?

For this proposal: no, it does not justify such usage of the tag. A feature that offers inconvenient bicycle parking should not be tagged bicycle_parking=no.

The convenience and location of existing bicycle parking is a nuance related to the positive case. Routers and users can make the decision of what level of inconvenience and lack of accessibility they are willing to accept based on the data being offered. The point of bicycle_parking=no is not to offer a value judgement of existing parking, it is only to state whether parking is available at all.

Mappers should put in effort to identify whether there is no bicycle parking available before tagging bicycle_parking=no. This tag should not be treated as a default value.

Definitively No Parking vs Ambiguous Parking Offered? Mapper Judgement may be required, do not use this tag as a default.

Proprietors may not offer parking that is explicitly and obviously meant for bicycle parking. But they may have railings or tall sign posts around their establishment that could be used to lean a bicycle or lock one up. But since there is no actual parking made available, does this feature qualify for bicycle_parking=no?

For this proposal: it depends, this may or may not qualify a feature for bicycle_parking=no. In most cases where it is not obviously bicycle parking, it will qualify.

bicycle_parking=no should not be treated as a default value. However, it should be acceptable to tag a feature as bicycle_parking=no if it lacks features that are obvious to users as being for parking a bicycle. If the argument that informal bicycle parking spots should be accepted is taken, then this could expand the scope of amenity=bicycle_parking to practically anything that you can lean a bike on and put a long chain around (like a tree). Given that this would reduce the utility of mapping bicycle parking, it should be acceptable to tag bicycle_parking=no where no feature obviously meant to park a bicycle is offered at an establishment.

Nevertheless, local knowledge and on the ground surveying should guide this decision. If a mapper is aware that a proprietor accepts cyclists locking their bikes to their railing, that may be worth not tagging as bicycle_parking=no. This tag is not meant to limit the nuances of mapping bicycle parking.

Scenarios Examined

What if parking is available after something is tagged?

bicycle_parking=no and a check_date describes when a mapper could not find parking around a feature. It is entirely possible that a proprietor may offer bicycle parking after the check date, or that the mapper missed parking on their original visit. What happens in the situation where parking is available near a feature tagged with bicycle_parking=no and bicycle_parking:check_date=*?

Proposed: Map the parking node, then delete the bicycle_parking=no and check_date

The goal of this proposal is to allow for a solution to bicycle parking not being found while minimally influencing how mapping bicycle parking that is found is performed. To align with that goal, the best solution in my view is to map the parking as is normally done, then to remove the bicycle_parking=no and bicycle_parking:check_date=* on the nearby feature. This would remove traces of this proposal's impacts and make the positive case return to how it is already being mapped. It also enables validation of these tags by using a buffer around features labelled bicycle_parking=no and bicycle_parking:check_date=* to see if any amenity=bicycle_parking are present within a set distance and flag them.

In step by step order:

Step 1: Map the bicycle parking node as you normally would

Place a node where you found the parking with amenity=bicycle_parking. You should also add other tags like [TODO]

Step 2: Remove bicycle_parking=no and the check date

For the feature with bicycle_parking=no and bicycle_parking:check_date=* that the newly mapped parking pertains to, remove both of these tags.

Alternative considered: update check_date and set bicycle_parking to something like yes or nearby

I don't like this option because it impacts how the positive case of bike parking mapping is performed. My hope is that the proposal has as low an impact as possible while addressing the negative case.

Alternative considered: remove just `bicycle_parking=no` but keep bicycle_parking:check_date

One could remove only bicycle_parking=no and update bicycle_parking:check_date=*. This could still be argued to be true on the ground, since a mapper went and checked for bicycle parking on a given date and did find some nearby.

I chose not to propose this option because it changes existing practice for mapping the positive case. This option could mean that mappers would need to tag features nearby an amenity=bicycle_parking to give it bicycle_parking:check_date=*. Perhaps that does reflect what they were doing, but mapping how existing bicycle parking nodes are mapped is outside the scope of the proposal.

Rendering

For most renderers, this proposal has minimal rendering implications. They may wish to show this tag in a detailed view or table.

Cyclist-Focused Renderers

Renderers that focus on cycling and especially cycling parking (such as RackFinder) may wish to render this tag combination as a clue to users that they should not expect bicycle parking near a location, possibly with different symbology.

Data Collection Apps

Renderers focused on data collection, such as StreetComplete or Every Door, may wish to offer quests or input methods for users wanting to survey for bicycle parking.

Validators

Validators may wish to use bicycle_parking=no as a way to detect when a situation has changed (bicycle parking was installed after survey) or a mistake was made (bicycle parking was already mapped and the surveyor didn't notice). A validator might be able to check for situations like these and produce a warning. An algorithm could proceed like this:

 case bicycle_parking=no is tagged:
 
     if amenity=bicycle_parking:
         raise error ("contradictory tags amenity=bicycle_parking and bicycle_parking=no")
         
     if not bicycle_parking:check_date=*:
         raise warn ("bicycle_parking=no tagged without bicycle_parking:check_date=*")
         automatically_add(bicycle_parking:check_date=*) #maybe?
         
     with find_nearest_distance_to(amenity=bicycle_parking) as nearest_bikepark_dist:
         let threshold_dist = some_distance_that_is_considered_nearby
         if nearest_bikepark_dist < threshold_dist:
             raise warn ("potential improper use of bicycle_parking=no with nearby amenity=bicycle_parking")
             
 case amenity=bicycle_parking is tagged:
 
     if bicycle_parking=no:
         raise error ("contradictory tags amenity=bicycle_parking and bicycle_parking=no")
         
     if bicycle_parking:check_date=*:
         raise warn ("redundant bicycle_parking: prefix on bicycle_parking:check_date=*") #maybe?
         
     with find_nearest_distance_to(bicycle_parking=no) as nearest_nobikepark_dist:
         let threshold_dist = some_distance_that_is_considered_nearby
         if nearest_nobikepark_dist < threshold_dist :
             raise warn ("nearby bicycle_parking=no not removed after amenity=bicycle_parking added")

Features/Pages affected


Page Impacted	Impact Description
Key:bicycle_parking	Remove introduction statement that `bicycle_parking=*` is "always used together with `amenity=bicycle_parking`" (Alternatively, add to the end of the introduction "unless `bicycle_parking=no`") A row is added to the page's table that describes `bicycle_parking=no` as a valid tag
Tag:amenity=bicycle_parking	Add statement saying that `amenity=bicycle_parking` is not to be used in combination with `bicycle_parking=no`
Tag:bicycle_parking=no	Page is created and key is documented to describe situations where bike parking is not available
Tag:access=bicycle_parking	Page is created and key is documented to describe situations where bike parking is not allowed

External discussions

Discussion on #tagging on OSMUS slack

Comments

Please comment on the discussion page.

Proposal:Bicycle parking=no on not amenity=bicycle parking to indicate absence

Contents

Proposal

Rationale