This proposal aims to address the situation where a mapped feature lacks bicycle parking by explicitly tagging said feature with bicycle_parking=absent. Additionally, bicycle_parking:check_date:* would be tagged so that mappers know when it was confirmed that bicycle parking was absent.
The goal is to disambiguate the situation where a lack of mapped bicycle parking is due to said parking being absent entirely, or if the parking is not mapped yet. This proposal attempts to address this situation while minimally impacting the existing method for mapping the bike parking that does exist.
Please discuss this proposal on its wiki talk page. This is my first proposal, so feedback and suggestions are welcome.
As part of my drafting, I have solicited some feedback from the OSMUS slack. I will paraphrase those discussions in my next post, so please treat the first reply as reserved until I post that here. Thank you!
In the first iteration of this proposal, the tag suggested was bicycle_parking=no, primarily to follow suite with other tags accomplishing this same goal. Since being more explicit like this would make conflation with access less likely (which was a concern that was raised during my questions on whether this tag already exists), I have adopted the change.
Q: Should this tag mean “no public parking is available” rather than “there is no parking available”?
A: under the old bicycle_parking=no proposal, this may have been one reading of the tag. But under the current bicycle_parking=absent proposal, it is more clear that it is a lack of presence being mapped, not lack of access.
Mappers should read the tag as “there is no parking period”. If a place has private parking for bikes, that should disqualify a feature from this tag.
Q: Can we make it clearer that mappers must put in effort before declaring a place as having no bike parking?
A: the proposal has been adjusted in response to this to make it clearer that mappers should put in the work before using this.
Q: How far from a feature can something be before it is declared absent? Should we use bylaw regulated distance?
A: This is subjective and I don’t think there is a clear line to draw. This may need some amount of mapper’s judgement and gut-feel.
I would disagree on the use of bylaw requirements, as we should not aim to make mappers into bylaw officers. OSM is not a legal database, and bylaws can change.
Q: How do we handle the case of a strip mall with POIs inside of it?
A: The proposal was edited to make it clearer how to handle the situation. In summary: you can map both a containing area and the more local POIs.
Consider the example where a cyclist may want to park right out front of a POI, even if the mall offers general parking (say to have their bike easily in eyeshot). This tagging could help them make such a decision.
Q: Parks should be able to be tagged as “in or around” just like buildings.
A: I agree, and have adjusted the proposal.
In previous iterations, an open space area would only be tagged like this if there were no parking inside the park, regardless of parking around. But buildings were allowed to be tagged in both cases (you normally don’t park a bike inside a building.)
Since it was pointed out that bike parking can be located close to an entrance to a park, and it would make it more consistent for mappers, this difference was dropped. You can tag parks and building areas the same way.
I agree, but proposing this would affect the positive case for bicycle parking, which I am trying to minimally impact. As such, I won’t adopt it in the proposal at this time.
If this proposal passes and then such a parking namespace scheme passes after, the tags bicycle_parking=absent and parking:bicycle=absent are essentially the same and could be migrated as such.
This is not interpreting =no in bicycle_parking= properly. bicycle_parking= is from amenity=bicycle_parking , therefore it should mean parking facilities. If there’s really any problem, you should still improve upon bicycle_parking= first, before considering to invent a new =absent to replace the common no in OSM.
Furthermore instead of access:bicycle_parking= , referring to parking:*=no + parking:*:access , they should be bicycle_parking=no + bicycle_parking:access=no
Hello, I am the one who created service:bicycle:parking in the wiki back then. This was based purely on this discussion at the time. The need was probably not so great back then, but based on the considerations at the time, I would say that the value no was simply not considered back then.
I’m sure I’ve added service:bicycle:parking to some hotels or similar establishments in the past, but as is often the case, I lost sight of it at some point. But I still consider it to be correct usage.
Now that I think about it, that would be a great quest for SCEE: Is there a bicycle parking lot here? (asked at various amenity, shop, or tourism tags).
Thanks for linking that thread where service:bicycle:parking was discussed. I’m happy that some of what I describe in the proposal were things people already considered (like how amenity=bicycle_parking is the mapping of the positive case). I brought up the tagging you had made because it was presented as a tag that was already existing that could address the situation I was asking about re “how do I tag that I looked for bike parking and didn’t find any?”
Just to clarify, is “it” in this case using service:bicycle:parking to describe the kind of parking offered by hotels? Or a value of service:bicycle:parking=no? Asking because when I looked for examples of the latter case during drafting, I didn’t find any examples.
Funnily enough, that is a use case that prompted me to start drafting this!
That’s what I meant by “I would say that the value [no] was simply not considered back then.”.
I think I classified that as spammy in my StreetComplete “Thinking” at the time. Or maybe I didn’t even think about SC, because there was no reason for me to actively tag no for the use case via JOSM at the time, as it would have occurred too often.
But today, I would definitely consider the value no to be correct and valid.
I don’t disagree, which is why my initial version of the proposal was bicycle_parking=no so that it aligned with other no values like ref:signed=no. But given that you would need this background to understand that this is what no means, I believe absent is a useful change to make it unambiguous based just off the text of the value.
When I was investigating existing usages of bicycle_parking=no in drafting the proposal, I found instances where it was being used on path ways where it was unclear whether the mapper meant “there’s no parking on the sides of these paths to be found” or “you can’t legally park your bike along this path.” In my mind, that suggested that it could be valuable to make the values less ambiguous.
Thinking about it again, I don’t know why I mentioned anything about how to tag access:*= here since that’s a consideration for amenity=bicycle_parking. Which would be parking that already exists. I probably put it there as a way to say “don’t use this in place of access considerations” since that was top of mind at the moment, but I can probably remove that bit.
This was a concern raised as part of drafting, but the view in the thread seemed to suggest “Even if it’s not on the ground, it’s a useful thing to know.” I understand the concern that this gives way to “this bank doesn’t sell golf balls”, but I believe this is different because it’s a real problem of ambiguity experienced by cyclist users. Further to that, I learned after my initial draft that this is apparently something transportation researchers are actively interested in having a method of modelling to understand which transit stops lack bicycle infrastructure.
To answer your specific concern on precedent:
I mention ref:signed=no in my proposal, which is an example of “this reference number does not have a sign showing this reference number.” This is an attribute showing that something doesn’t exist for another thing already mapped, which is similar to what the proposal is doing.
And highchair=no was brought up to me as an example of a tag added to an amenity to signify that something you might expect to be there actually isn’t. This is also in the same vein as this proposal.
Could you clarify what service:bicycle:parking=no would mean? I had some concerns about suggesting that while I was drafting:
Is this tagging for service providers only? Could someone tag a park as service:bicycle:parking=no even though nobody at a park would normally be providing you bike parking as a service?
Would this be an observational claim (“I looked around the hotel, and there’s no parking I can see”), or one that requires knowledge of the business’ offerings (“they don’t list bike parking anywhere on their website as a thing for guests”)?
Say for example a hotel has a bike stand out front, but they disclaim all liability for it and have no security. Could one map amenity=bicycle_parking but tag the hotel as service:bicycle:parking=no in that case?
Like @GuardedBear I have reservations about mapping things that aren’t there. I would actually be ok with “this bank does not sell golf balls” because it would be a non-feature of that particular bank which the bank could decide to fix at any time. But I am not ok with mapping “at present there’s nothing of type X in the vicinity of this Y” if there isn’t a direct relation. There not being something of type X in the vicinity is not a property of Y; it is the result of a geometry operation. Just like we don’t use is_in any more, we shouldn’t start tagging how near or far two things are from each other.
“This bank doesn’t have an ATM” is fine. But “there is no ATM near this bank” isn’t. In your case, “this supermarket doesn’t offer cycle parking” is fine, but “there is no cycle parking in the vicinity” is not. Because it would mean that someone recording a new cycle parking feature would have to check and potentially modify all surrounding POIs - even if none of those POIs’ properties have changed.
(I didn’t see Jarek’s post when I wrote mine but his two examples about bus stops and fast food places are of my “this bank doesn’t have an ATM” class - so I’m fine with those, as they say something about the properties of this particular thing, and not about whether or not there’s a shelter or a drive-through somewhere nearby.)
You probably have a bicycle that isn’t worth stealing, and you are happy to put a lock in the wheel when you park it. But today’s cyclists often ride on things that cost more than a used small car and they’re eager to lock it to something solid.
Are “there isn’t any parking around this feature” and “this feature doesn’t have parking” different claims? How would you know if a feature has parking without looking around it?
Based on others’ answers to my question above about precedent, it seems we do have the ability to tag things that don’t exist (highchairs, shelters, drive-throughs, etc.). So that’s good to know.
But looking at those examples reveals a big difference with this proposal (which @woodpeck already pointed out): Existing examples are objective, definitive and easily verifiable. A restaurant not having a high-chair is easy to confirm as the restaurant has a defined boundary in which to look (also, you can ask the staff, and the restaurant would owns and look after any highchairs it has). A bus stop not having a shelter is also easy to confirm. As is the lack of a drive-through at a fast-food joint.
But a location having bicycle parking “around it” is subjective, not definitive and hard to verify. What if there’s bicycle parking at a park right across the road from a shopping centre’s front doors? Is that considered “around” the shopping centre? What if the parking was in the middle of the park, or on the other side of the park from the shopping centre? Where do you draw the line of what’s considered “around” a location?
I was writing a response to this discussion about “around”. But in the middle of it, I realized that I don’t have the energy to continue through with the proposal process until the end. So I will mark the proposal as cancelled.
Edit: I have been told that it’s better in this case to leave it as just proposed instead of cancelling it, in case a future mapper wants to take it forward. So I marked it as proposed again.
But I still consider it to be correct usage.