Talk:Key:foot traffic

Verifiability of this tag

Hey, this tag seems to be highly problematic in many respects:

• Just _how_ are we supposed to verify this tag: what is exactly the difference between 'medium' and 'high' foot traffic?
• Someone living in a small village and someone from a big metropolis probably have widely different ideas about what "high" foot traffic is. You're gonna have to specify more precisely what "high" or "low" means if you want this tag to be viable
• Isn't foot traffic quite variable? What with situations where foot traffic surges at certain moments, but is quite calm at other times - e.g. with a religious place having their weekly service? Is this tag not derivable from highways nearby?
• I don't think they fit the OSM-mantra of verifiability - which explicitly mentions that e.g. 'the number of cars passing by' is not suited for OSM. We had a similar, but lesser controversy with smoothness
• Has this tag been discussed with the community before? Was there a proposal? I cannot seem to find it.
• What about this mechanical edit, changing many 'traffic' values into 'foot_traffic'?
• This tag is mostly used on bicycle parkings. I don't think that many pedestrians walk over or via bicycle parkings. Even if this tag were to be used, a bicycle parking is the wrong place to add this to.
• This page seems like a copy-past from the Traffic=* page which has the same concerns
• It seems like this was added to https://rackfinder.app/ which has been generating these tags, and that this is the only source of those tags .

Pietervdvn (talk) 00:37, 2 March 2024 (UTC)

Not sure how to reply to this post, so I will here.

This tag as mentioned is derived from the original `traffic` tag. At a point I realized `traffic` should be different than `foot_traffic`, as `traffic` is specifically talking about vehicular traffic in a roadway. While I agree the tag value is hard to "verify", it is easy to judge the area's nearby foot traffic based on these four broad categories. I have placed guided descriptions within my app, which match the comments column in the wiki page, to help a user determine which they should pick.

This information is particularly useful for a commuter cyclist to determine whether they choose to lock up at a given location. Unlike car parking, not all bike racks are the same. It is generally a good rule of thumb to choose a rack that is visible from a public area with lots of eyes nearby. Racks that are placed behind buildings and in parking garages tend to be less desirable because opportunities for theft are much higher. Nearby foot traffic is a good gauge to determine how many people might be nearby on an average day. Of course, foot traffic depends on many variables such as time of day, day of week, holidays, etc. The aim however is more to understand how likely it is for someone to be walking nearby, proportionally to other, more traffic'ed spots in the area.

I posted a discussion to introduce this tag and received only one reply from another user in support of the idea, and so here we are. 19:26, 22 June 2024‎ [[User:Alexwohlbruck|Alexwohlbruck]

Traffic volume is not very verifiable, nor necessary. What's needed is multi-modal functional classification for pedestrians and bikes, or even transit, as highway=* class is for vehicles. The need is mirrored from modern place vs movement road matrix. This can't be inferred from traffic volume. A school, factory, or office park may have high pedestrian traffic outside, but can be argued to be not that important to the public in general. Then you have to consider the extent of time period. The problem remains this is more unverifiable than vehicular traffic functionality.
What is your "app"? First of all, you should consider making it your own classifications in your own database. Different people and communities may have different definitions, that you may disagree. Crime and safety is highly variable, and generally doesn't belong to OSM. class:bicycle=* physically may be more useful, yet still has verifiability problems.
On the contrary, much of your definitions can be inferred from existing physical or functional classes. place=square , amenity=parking , service=alley and footway=alley , shop=* , etc. They can be per-processed spatially, or detected dynamically.
—— Kovposch (talk) 10:35, 23 June 2024 (UTC)

My answer:

• "While I agree the tag value is hard to "verify", it is easy to judge". This seems to be very contradictory, or rather: to 'judge' is inherently a personal opinion and that is precisely the issue I'm raising - what one person might judge as 'busy' might seem 'calm' for someone else passing by, giving rise to data quality issues. Keep in mind that I have similar problems with the `traffic` tag _and_ that the biggest application of this are _automatically applied_ values from an external dataset.
• "which match the comments column in the wiki page" I had a look, and the values in the wiki page are just as vague. "Low traffic, e.g. side of building, parking lot". A parking lot of a popular shop is something else then an oversized parking lot of an office complex, that only sees crowds when the workers arrive and leave . If it were something like "5 pedestrians/hour during peak hours", this would be more verifiable - but still be dependent on e.g. the season. (A street in front of school would be way busier during the week then in the weekend). This breaches both the "no temporary items" and "only verifiable items.
• "This information is particularly useful": I'm not denying that this is useful information, I'm denying that OSM is not the platform to store this information in.
• "I posted a discussion to introduce this tag": Can you please link this post? Was this on the tagging mailing list?
• Furthermore, I'm objected to traffic=* as well, but I don't have the energy to fight against that. I'm more involved with bicycle parkings and want to weed out this tag before it gains foothold - something I do have the energy for.
• At last, I'd like to restate that, even though I object to the tag as a whole, adding this tag onto the _bicycle parking_ is not correct from a semantic and data normalisation perspective. This tag should be applied onto the nearby foot paths, as _they_ carry the traffic. Consider, for example, that some commuter wanted to know the road categorisation and maximum speed of the road nearest to the bicycle parking. Are you gonna add this information to every bicycle parking worldwide? And what if I, as a building owner, wanted to know this as well. Am I gonna add this information onto every building worldwide?

--Pietervdvn (talk) 20:19, 23 June 2024 (UTC)

I'm considering mass-deletion of this tag

Hi @Alexwohlbruck,

I'm considering to mass-delete all these tags in OSM, as I haven't had any more response from you which addresses the many concerns I have with this tag.--Pietervdvn (talk) 14:28, 1 August 2024 (UTC)

I suggest Alexwohlbruck (on osm, edits, contrib, heatmap, chngset com.) to make a uMap storing own data from Overpass. You can retrieve attic data there. It's never completely wiped from database.
—— Kovposch (talk) 08:23, 2 August 2024 (UTC)