Proposal talk:Street vendors

From OpenStreetMap Wiki
Jump to navigation Jump to search

Original author

Personally, as someone who invented street_vendor=* I am not supporting this deprecation, though I see reason for proposing that. But it seems to be just making more complex (and less likely) to support processing of such objects for little benefit. Functionally street vendors are shops, especially in poorer countries.

I am not sure about "with no shop or own premises. As such, tagging them with shop=* is wrong" - not convinced by that, but I am not a native speaker (see discussion in https://wiki.openstreetmap.org/wiki/Talk:Tag:street_vendor%3Dyes) Mateusz Konieczny (talk) 13:18, 23 October 2022 (UTC)

There is huge difference between anything / anybody that sells something (should this be what you mean by "functionally are shops", basically a generic amenity=retail?) and a shop. A vending machine is not shop and is mapped separately on OSM. So should be a person (or a group of persons) who put(s) up their cart at a crossing every day.
There are certainly areas on this planet that do not have shops (it is a terminology from at least somewhat "developed" cultures after all). In particular in such "poor" areas it might be very relevant for navigation if a shop exists (permanently) or if the stall is only present on Wednesdays. amenity=street_vendor (edit: in an earlier version street_vendor=* was mistakenly written here) is very little extra complication for any data consumer that already supports both vending_machine=* and opening_hours=*, IMO.
--Freetz (talk) 05:41, 26 October 2022 (UTC)
"street_vendor=* is very little extra complication for any data consumer" that is why I think it is superior over amenity=street_vendor + vending=* that needs to recreate entire shop=* structure. It also seems friendlier to mappers who do not need to learn two separate tagging schemes depending on how shop operates. Mateusz Konieczny (talk) 13:34, 26 October 2022 (UTC)
street_vendor=* has the problems metioned in the proposal. We cannot expect that all data consumers start evaluating this tag. Including street vendors under shop=* would require a serious redefiniton of shop=*.
--Freetz (talk) 03:44, 27 October 2022 (UTC)
"Including street vendors under shop=* would require a serious redefiniton of shop=*." I disagree, but maybe I am wrong here Mateusz Konieczny (talk) 15:44, 27 October 2022 (UTC)
I do also think that using shop=* or for example amenity=fast_food for street vendors is not basically wrong. Even if it's difficult for data consumers, I still think that an additional tag for the affected shops and amenities is essential.--Lukas458 (talk) 16:24, 28 October 2022 (UTC)
street_vendor=yes is a Trolltag: "In general, any tag that must be processed to avoid serious misinterpretation of the feature is a trolltag.".
--Freetz (talk) 05:34, 7 November 2022 (UTC)
As author of trolltag term I disagree that it applies: street vendor is still place where you may buy specific products in its operating hours. If someone expects building based on presence of shop tag, then they are processing data in a wrong way. To look for buildings they should process building=* data Mateusz Konieczny (talk) 07:48, 8 November 2022 (UTC)

"Gamblers and performance artists are not street vendors." - what about permanently placed ones? Not sure how to deal with that. Mateusz Konieczny (talk) 13:18, 23 October 2022 (UTC)

They are neither merchants nor service providers, hence they don't fall under the street vendor umbrella. (I will not spend a second of my time to think about how to map gamblers. I leave it to others to invent an appropriate mapping scheme for them.)
--Freetz (talk) 05:41, 26 October 2022 (UTC)

"If the location is not fix within 15 meters around the node, it is not a amenity=street_vendor." - that seems overly strict, location fixed within 20m or 50m still seems fine to me Mateusz Konieczny (talk) 13:19, 23 October 2022 (UTC)

Hm, yes, I'm not fix on that. I think 15 meters seems somewhat reasonable to me in as "most of the time the street vendor can be spotted from 15 meters away". 50 meter, on a straight emtpy street, okay. But not in crowed downtown? What are other opinions?
--Freetz (talk) 05:41, 26 October 2022 (UTC)

"vending=hotdogs freshly cooked, fried or grilled sausages" - not all sausages are hotdogs Mateusz Konieczny (talk) 13:20, 23 October 2022 (UTC)

I removed it, I think this should better be under vending=fast_food + cuisine=*.
--Freetz (talk) 05:41, 26 October 2022 (UTC)
Makes sense Mateusz Konieczny (talk) 13:36, 26 October 2022 (UTC)
But why *=fast_food? You won't use *=restaurant etc here. *=cafe, *=bar, and *=biergarten don't fit vending=*. You should put that as what it actually sells, eg vending=pizza (documented), vending=hamburger, vending=taco. Another option is vending=food + food=* / food:*=* that already exists in Key:vending. The service type and culinary can fall into something else and cuisine=* separately. --- Kovposch (talk) 06:26, 7 November 2022 (UTC)

"physically_present=no - remove street_vendor=yes references (is wrongly listed anyways)" - what is wrong with it? Note that it in see also section Mateusz Konieczny (talk) 13:25, 23 October 2022 (UTC)

A street vendor is physically present while doing business (you wrote it yourself), otherwise it made no sense mapping them. If they were physically_present=no, at best, they'd be an amenity=online_shop :).
--Freetz (talk) 05:41, 26 October 2022 (UTC)
And it is listed in "see also" section - where similar and related but different tags and pages are listed Mateusz Konieczny (talk) 13:31, 26 October 2022 (UTC)

Missing vending values

Note that with this idea vending=* needs to replicate all shop=* values. At least values for places selling fish, meat, gifts, baskets are missing Mateusz Konieczny (talk) 13:32, 26 October 2022 (UTC)

I don't think the entire shop=* structure needs to be replicated for vending=*. There are many things under shop=* that do not apply to street vendors. I think for street vendors it is much more appropriate to concentrate on the products they sell (much like a vending machine) than what kind of industry a shop can be associated with. For example a typical bike shop sells much more (and provides much more services) than street vendor who sells bikes off of a truck could ever do. I don't think we need to be too specific and too detailed here upfront and I think we can leave it to the community what vending=* they find most useful and what street vendors will most commonly be mapped.
-- Freetz (talk) 03:44, 27 October 2022 (UTC)
Pretty much every shop=* tag value would require a matching vending=* tag value Mateusz Konieczny (talk) 15:43, 27 October 2022 (UTC)
I fully agree with Mateusz Konieczny. I think the concept of this proposal "amenity=street_vendor" is too narrow, failing to consider all possibilities of street vendors. I think that the current solution of using the Tag:street_vendor=yes is much more powerful, since it allows to tag any business. For instance, I arrived to this place trying to find how could I map a mobile bank office that is installed once a week in one specific place. Maybe this does not exist in every country, but it does exist in the world. I understand that with the current solution, I could create a bank node and tag it as street_vendor=yes with the corresponding opening times. I don't see how could I tag such business with this new proposal. In general, I think this proposal risks assuming that the whole world is homogeneous, risking not being able to reflect each country/region's diversity. Basically, I see very little advantages to this proposed feature (compared to the existing tag), while I see it a lot of added complications. --Barahona (talk) 15:50, 31 October 2022 (UTC)
amenity=street_vendor is tailored for street vendors. While there certainly exist other temporary, recurring features in the world that are mapable, they are not targeted by amenity=street_vendor because they are not street vendors - like for example performance artists. A bank does not trade retail (or wholesale) goods or services, a bank is a bank, and mapped with amenity=bank already, not with shop=bank. But if one wanted to consider a mobile bank to be a street vendor (which I wouldn't strongly oppose), it is still perfectly doable as amenity=street_vendor + vending=banking (note the -ing gerund form for services (where it makes sense)).
Adding street_vendor=yes has the fundamental problems described in the proposal. If we allow that a shop=* is no longer required to be a permanently present feature, that would be a very significant redefinition (apart from confusing the word "shop" with what should better be called amenity=seller). street_vendor=* applied to amenity=bank is even worse IMO. Not only does the wording make no sense to me, but more importantly does this require a redefinition of amenity=bank, too. Where does this end? Does every tag become a candidate for street_vendor=*, and every element could be a temporary feature unless specifically entered in OSM and checked by the consumer?

"This proposal risks assuming that the whole world is homogeneous, risking not being able to reflect each country/region's diversity."
I'm not yet understanding your concern about not being able to reflect regional specifics. In what aspects does the proposal assume a homogeneous world? Could you elaborate?

I might not be making a lot of friends, but I believe shop=* with its growth of new values has its own problems and is increasingly loosing usability. I find the values for shop=* rather chaotic. It is used for retailers that focus on a specific industry (e.g. shop=bicycle) or sometimes even on a specific trivial products (e.g. shop=pasta), while even others remain completely unspecific on what they sell but rather describe the organization of a the retailer (e.g.shop=charity). This works well if one is interested in pasta shops or in bike shops. If I want to use OSM, however, to find a place where I could buy pasta or a bike tire, shop=* is not all that useful. It also has the problem that a shop can only be of one type (One feature, one OSM element).
This already didn't work well for the "butcher" in my childhood neighborhood who also sold cheese, nor for shops where both bikes and sewing machines are sold, and it works increasing less well the more shop types are being added. What is really the use of shop=household_linen, shop=bed, shop=furniture, shop=interior_decoration and shop=candles - and what is IKEA here? There are many dealers that are hard to capture in a single shop type. vending=* is extremely powerful here to really help users find places where they can buy candles, even if it was the household linen shop down the street and not at the candle store downtown. To be clear, I'm not (yet) proposing to apply vending=* to shop=*, but I think applying the ageing concept of shop=* to street vendors, is not a direction that has a great future. If anything is too narrow, it is the concept of shop=*, IMO :)
--Freetz (talk) 04:55, 2 November 2022 (UTC)
The way I see it, most of your concerns on this topic are around a linguistic discussion over the semantics of the English words “shop” and “street vendor” and how to make the tag codes to perfectly match to your understanding of these words. I think that this approach is not correct: Codes are not words in the way you are seeing them.
Entering into deep semantic discussions about codes forgets that such codes are not only used for English, but for any language and country depending on the user of the OSM data. It's up to the renderer to decide how to display them.
I agree when you say “the values for shop=* might be rather chaotic”. But precisely because of that, I see no value on creating a new parallel mess for ”street vendors” while a common solution already exists. It would be better to improve shop=* values (which is a different discussion).
I said that "This proposal risks assuming that the whole world is homogeneous, risking not being able to reflect each country/region's diversity" because I felt that the effect of this proposal would be to limit the types of street vendors by putting in written which businesses can “qualify” to be tagged as a street_vendor=*. I still don’t see any practical problem to the existing street_vendor=* solution, which I find much more flexible and with potential to adapt to different local realities, so I do not see any reason to change it. --Barahona (talk) 09:03, 2 November 2022 (UTC)
"most of your concerns on this topic are around a linguistic discussion over the semantics of the English words “shop” and “street vendor”, that's not quite true, it's not about linguistics. It is not my semantics that a shop is permantly present, this is how features on OSM are commonly used and understood, not just shops. Are you okay with the consequence of street_vendor=* that a data consumer will have to check for each shop=*, and maybe for many other amenity=* to understand whether features are permanently present or not? I'm not really seeing an existing solution in street_vendor=*. It is used quite rarely and it's proposal was never released for voting, it wasn't even widely discussed on the Wiki. So it's not appropriate the leave the impression that there's consensus that street_vendor=* is a good scheme.
--Freetz (talk) 15:18, 2 November 2022 (UTC)
"I agree when you say “the values for shop=* might be rather chaotic”. But precisely because of that, I see no value on creating a new parallel mess for ”street vendors” while a common solution already exists. It would be better to improve shop=* values (which is a different discussion).". The long term fix could probably be to apply vending=* to shops. I haven't finalized the idea yet, so I'm not proposing anything. So far I can't think of a different approach. shop=supermarket doesn't tell we that I can buy candles at that specific store around the corner and I don't see how it ever will.
--Freetz (talk) 15:27, 2 November 2022 (UTC)
Sorry, but the more you elaborate on the rationale, the less convinced I am about it. Do you realistically expect to be able to find all shops selling candles by searching on vending=candles? Should shops have hundreds of vending=* codes to detail what they sell? OSM already struggles to maintain the existing shops. I cannot imagine how it would be possible to maintain a list of all categories of products that any retailer sells. A theoretically "perfect" system that cannot be maintained (so it cannot be trusted) is not an improvement. Nevertheless, I'm re-reading my last comments and I would like to apologise if my tone might seem aggressive. That was not my intention. --Barahona (talk) 19:44, 3 November 2022 (UTC)
Keep in mind that I'm proposing vending=* for street vendors not for big retail shops here. This proposal really has two aspects. The most important aspect is to retire street_vendor=yes because of its explained incompatability with existing (i.e. accepted) practices. To the sooner street_vendor=yes is deprecated the better IMO. I'm proposing amenity=street_vendor to still be able accomodate mappable street vendors on OSM. (Personally I have never felt tempted to map non-permanent businesses but I can see good reasons for it.) Street vendors need a dedicated tag if they shall have a place on OSM.
Only the 2nd aspect of the proposal is to better describe street vendors using vending=*. Instead of amenity=street_vendor, it could also be street_vendor=florist/fast_food/etc that stands by itself and gets all values of shop=* but is not applied to a shop=*. I don't like that idea (how to tag a street vendor selling only cheese and meat there? street_vendor=butcher and street_vendor=cheese on two nodes?), and I'm curious what the preference of a wider audience is. But at least street_vendor=florist/fast_food/etc would keep any harm from shop=* and amenity=fast_food.

vending=* is not a new invention of mine but already exists, and is used reasonably and successfully as far as I see it. I don't think we need hundreds of values to capture street vendors. vending=* should be as generic as possible and as specific as reasonable. vending=candles yes, but no on vending=red_candles, vending=bees_wax_candles, or vending=10cm_tall_candles. Thinking further towards applying vending=* to shop=* (which I'm not proposing): I'm thinking this could still work. There's no need to include every bar code in a supermarket. But tagging the biggest and most relevant categories of products sold at a shop could be both useful and maintainable. But you have a point, I'm not sure if this works in practice for shop=*, but I do believe it can work for street_vendor=* since they don't sell many different products. Most of the time, I'm sure, three vending=* values will describe a street vendor well, and only in rare cases I'm imagining a need for more than 5. Let's see how vending=* works for amenity=street_vendor, it works well for amenity=vending_machines. Just think of a street vendor more as a big modern vending machine, or serveral vending machines than as a retail shop with aisles and shelves.
(You're alright. We are all humans on here who have different cultural backgrounds and native languages, better and worse days, and individual personalities and styles of expression. As long as I'm not called names, I'm not bothered. Likewise I hope that my writing is not perceived negative in any way)
--Freetz (talk) 01:02, 4 November 2022 (UTC)

Greengrocer

How shop=greengrocer + street_vendor=yes selling both fruit and vegetable would be replaced? Mateusz Konieczny (talk) 13:35, 26 October 2022 (UTC)

From examples it seems that it would be vending=fruits;vegetables Mateusz Konieczny (talk) 13:36, 26 October 2022 (UTC)

What about unattended and automated shops

If you want to revise street vendors in relation to shop=*, it is best to consider them together. Honor system (especially boxes only) and autonomous shops have been discussed before. --- Kovposch (talk) 05:47, 7 November 2022 (UTC)

Thanks for your comments. Honor systems are something different from people or machines selling something in my view, and I don't plan to include them in this scheme. Autonomous shops, I haven't mapped any yet, and I haven't given it a thought if I'd rather map them as shop=* or as a amenity=vending_machine, I guess it depends on the very facility. I don't see a relation to street vendors though. Autonomous shops are permanently present, aren't they?
--Freetz (talk) 01:45, 8 November 2022 (UTC)

Ambigious

"Street vendor" is still unclear if it is fixed stalls, retractable stalls (ie there is still something left there), stalls packed away, a static trailer or vehicle attachment, a static vehicle, a movable cart, or a moving van/truck. Mixing everything up by treating them all as on-street doesn't completely distinguish them. You define amenity=street_vendor as "a place where a street vendor returns to", but on the contrary, some equipment could remain in place. As can be seen, this term is not the best choice, when it may refer to any on-street outdoor establishments.

Therefore I would envision what we need is separate attributes to clarify each aspect, could be re-used / borrowed from other existing features:

  1. installation=* (it is possible to have indoor stalls, or ones covered under another permanent structure)
  2. outdoor=* and covered=*
  3. movable=*
  4. Something for it is all cleaned up when closed, but it always return there when open (perhaps cf intermittent=* and seasonal=*?)
  5. Something for it is frequently moving, but there is a designated spot, possibility marked, physical, and with utility connections (ie amenity=parking_space but for food trucks, stalls, and such)
  6. Something for it is frequently moving, usually not physical presence ( cf amenity=mobile_library )

--- Kovposch (talk) 05:54, 7 November 2022 (UTC)

Ok I now see Proposed_features/Street_vendors#Examples_that_are_not_street_vendors. This list could be debatable, and "street vendor" remains a non-ideal word to describe them. It is too generic and unspecific. --- Kovposch (talk) 06:14, 7 November 2022 (UTC)

I see 3 aspects in your remarks, let me know if I missed any.
1. Ambiguity:
The proposal explains how to map vehicles and trailers. Is that not clear enough, anything that can be added to improve? Anything (stalls and similar) that look as if it is easy to remove suggests itself to be a street vendor to me. Stalls that are not easy to remove but where vendor removes their equipment routinely and leave no sign of their business would also be a street vendor to me. If the stall permanently displays signs of the vendor, then it'd be shop=*. I'll improve the wording if additional comments are made in this direction.
2. Additional attributes describing the scenery:
I'm hesitant about the six attributes you suggest. They add a level of detail I'm not convinced is useful. I believe the most eminent attributes end-users care about opening hours and products and serivces offered.
3. Debatable list of what are not street vendors, street vendor too generic and unspecific:
In what aspects do you find the list debatable? In many sources, street vendors are defined similarly as in the proposal text and in a very unspecific and generic way. What specific aspects are you missing and for what benefit should they be included?
--Freetz (talk) 02:39, 8 November 2022 (UTC)

Key and "shop"

You chose amenity=* to fit into your definition of "shop". Yet shop=kiosk is something you can't enter. shop=mall is not a single shop either. There is no significant benefit to move back to amenity=* from shop=*. --- Kovposch (talk) 05:59, 7 November 2022 (UTC)

The reason I'm moving away from shop=* is to protect shop=* from trolltags that question permanent presence of a shop, not to fit anything into "my" definition. I don't understand what you intend to express with the shop=kiosk and shop=mall examples. I'd appreaciate if you could rephrase. Thanks.
--Freetz (talk) 02:38, 8 November 2022 (UTC)

Intermittent is not trolling

The "What is the problem with street_vendor=yes?" section frames the problem as one of troll-tagging, specifically that tags like amenity=ice_cream are being used both for brick-and-mortar establishments and street vending stalls with a more ephemeral presence. I think this problem statement makes strawman arguments. As it is, we don't map temporary features, and we don't map fiction, but I'm not seeing any suggestion that we should stop mapping street vendors altogether. The street vendors you bring up are examples of intermittent features – that is, features that truly recur in the same place on a predictable schedule. If not for the street_vendor=* key, I might've considered tagging street vendors with intermittent=* or seasonal=*. Deprecating these keys would be quite a rabbit hole.

You point to the absurdity of data consumers checking whether a feature is physically present at every hour of the day. Indeed it would be absurd, but not for the reason you describe. A typical data consumer would want to include an ice cream shop whether it's a full-service parlor or just a popup stand. An ice cream icon represents a place of business, which is the nexus of a facility and a business. Yet users understand that not every ice cream icon on the map and not every search result for "ice cream" represents a 24/7 ice cream shop.

Granted, a 3D renderer might try to depict a realistic model of the facility, and you have a point that a shop can be a landmark even when it isn't open. However, routers can already avoid naming street vendors as landmarks today by looking out for street_vendor=yes. A 3D renderer can already decide between an ice cream parlor model and an ice cream stand model based on street_vendor=yes. How would amenity=street_vendor make these heuristics easier to implement? If anything, a novel, probably inconsistent tagging scheme for the miniature version of just about any retail POI tag would make it more difficult for data consumers to give street vendors fair coverage on the map. Presumably a renderer would still want to render an ice cream icon rather than a generic street vendor icon, whatever that would be.

 – Minh Nguyễn 💬 07:33, 7 November 2022 (UTC)

Thanks for your critique, I found six aspects to answer to.
1. Intermittent, seasonal:
Intermittent, temporary, recurring... they mean all the same to me in this context and I believe we know what we discuss here. Let's focus on the actual problems: intermittent=* is to indicate whether or not a waterway or water body does not permanently contain water. Intermittent water bodies and ways are different from street vendors in that the dried out feature is still existing at the location, and most of the time is even visible. intermittent=* describes a temporary presence of water but it doesn't question the existence of the underlying geographical feature (we don't map river beds separate from the water in it). A street vendor who packs their stuff at the end of they day and leaves does not continue exist at the location. I don't see what relevance seasonal=* has in this context and I'm not proposing to deprecate either seasonal=* nor intermittent=*, they are good for what they are being used for. If intermittent=* is applied to anything else other than water features, this is not in agreement with its definition (but it is not proposed herein to deprecate the non-compliant use).
2. Stop mapping street vendors:
Your understanding is correct. I'm not proposing to stop mapping street vendors. I can see value in mapping them if they are mappable.
3. "You point to the absurdity of data consumers checking whether a feature is physically present at every hour of the day."
I'm not sure where you think I pointed this out. I see street vendors as unreliable map features, that's all. If a consumer wants to present these features in whatsoever way it is their business and I'm not judging that.
4. "A typical data consumer would want to include an ice cream shop whether it's a full-service parlor or just a popup stand."
I don't share this assumption, and I don't presume what a typical or atypical consumer is or what they want to include. I strive to give data consumers acurate information so they can chose what they believe fits their application best.
5. "Yet users understand that not every ice cream icon on the map and not every search result for "ice cream" represents a 24/7 ice cream shop."
If and how OSM elements are displayed in an application and how end-users understand that is a matter of application and UX design, but is not relevant to information entered in the OSM database.
6. Consumers can already evaluate street_vendor=yes, how would amenity=street_vendor make these heuristics easier to implement?:
I explain in the proposal and on this talk page how this tag meets the criteria of a trolltag. Are there any counter arguments that can be made? amenity=street_vendor will simply only be queried by data consumers who are specifically interested in street vendors while others can safely ignore them. This is not the case with street_vendor=yes. amenity=street_vendor is heuristics for free.
--Freetz (talk) 04:24, 8 November 2022 (UTC)

@Freetz: I think it is reasonable to make some assumptions about what data consumers would want to do with our POI data based on what they have been doing with our POI data. If an insufficient distinction between brick-and-mortar shops and street vendor stalls has been such a problem, I'd think it would've hindered renderers' and search engines' adoption of certain POI tags that are more likely to be street vendors than others. Do we have evidence of this disparity? In this section, I focused on data consumers because they figure so prominently in the proposal's rationale. It would be inconsistent to then handwave about data consumer inconveniences as a mere UX problem.

As far as I can tell, the proposal only claims that street_vendor=yes is a trolltag but doesn't do very much to explain how it contradicts the main tag, as "completely_fictional=yes" or "proposed=yes" would. To the contrary, in many settings and many parts of the world, a restaurant in a food stall is a bona fide restaurant. Granted, it would typically be smaller, but most POI tags don't reliably imply a specific size.

I do appreciate you bringing up use cases for distinguishing between brick-and-mortar shops and street vendor stalls. To me, if the physical characteristics (or physical permanence) of a business is so important to a particular use case, then the data consumer should take advantage of a tag such as street_vendor=yes to opt into this distinction. However, using amenity=* for amenity=street_vendor and relegating the details to vending=* all but forces data consumers to make this distinction or actively opt out of it.

A clothing stall at the local flea market. This market's signposted street names are intermittent too.
I guess you could boil down my sentiment to: switching the longstanding opt-in to an opt-out would be a disruptive change. This change would be particularly disruptive in some of the places where I map (in California and Vietnam). Where I live, street vendors seem to outnumber brick-and-mortar retailers in some districts. On weekends, a drive-in movie theater's parking lot comes alive as a bustling flea market, every bit as important to the local Hispanic community as any formal business district. The public health department enforces the same health code against restaurants and food stalls alike. Personally, I would not be able to convince a layperson here that street vendors are fundamentally different than brick-and-mortar retailers; it's just a secondary detail. But I recognize that our perspectives on this matter are pretty far apart.

 – Minh Nguyễn 💬 08:46, 8 November 2022 (UTC)

Generally there is not a lot of feedback in OSM by data-consumers or end-users if features on OSM are outdated. I've seen many shops recently in busy downtowns in sizable cities (in countries where OSM is realitvely popular both among both end-users and mappers) left on OSM unchanged 2 years after they closed. I'm not expecting to receive any complaints by OSM users. I think it is more realistic to expect they will turn their backs to OSM and move on with Google. There are only 403 elements, spread around the world, on OSM tagged as street vendors street_vendor=yes that could even be used for any tracing of unexpected behavior. If there are other shops on OSM that mark temporary vendors, practically nobody will ever know about this. Data consumers don't have the information, and end-users don't report bad quality but run away from it. Incorrect data is incorrect, regardless if someone complains about it, minds or even notices. To me it is unethical to provide potentially misleading data and let the consumer and end-user figure out if they run into problems. Maybe that's the way some bay area companies work, at OSM we should have higher standards IMO. Distinguishing between street vendors and shops is important in my view as explained in the proposal. Nowhere does this proposal say that street vendors would be less important than stationary businesses. If data consumers want to purposefully use street vendors, they can easily use amenity=street_vendor. Those who don't want to use them must not be mislead by mixed up data. I see it as "opting in" to street vendors for those who want to and I see nothing wrong with it. A plain shop=* is stationary and permanent and always has been on OSM to the vast majority of data consumers and users, I'm sure. "We don't map temporary features" should have precluded anyone from entering temporary shopping or dining features. Temporary features that are already in OSM are not detectable and will not be changed to amenity=street_vendor, so no new "harm" is done to existing data with introducing amenity=street_vendor until someone re-surveys and re-tags - which will probably take long enough in most areas for data consumers to adapt and offer street vendors to their users. As I was trying to express on the proposal page and on the talk page, the Wiki explains a trolltag by "In general, any tag that must be processed to avoid serious misinterpretation of the feature is a trolltag." To me, misinterpreation of the presence of a feature is serious.
--Freetz (talk) 04:49, 9 November 2022 (UTC)
@Freetz: I'm not sure I subscribe to the notion that poor coverage of street_vendor=yes or any successor tag would be more unethical than leaving an outdated opening_hours=* on a shop. If we're worried that this is what will send users to Google, maybe Google's junk POIs and susceptibility to locksmith scams will send people running right back to us here in the Bay Area, where our coverage of some POI types is increasingly competitive against proprietary sources. But back on topic, the fact is that OSM has a significant existing ecosystem of data consumers, and this proposal as written nods to their importance. If you consider the current undifferentiated behavior of renderers and geocoders to be in error, then it should be possible to point to evidence that their developers consider their software to be behaving suboptimally. What would really help this cause would be to get feedback from developers. I happen to be one, but I look forward to reading the informed opinions of other developers whom this proposal seeks to accommodate. – Minh Nguyễn 💬 10:26, 9 November 2022 (UTC)
Not maintaining data is different from entering wrong data. Nobody is obliged to keep OSM up-to-date, but it's fair to expect that if someone enters data, they enter it correctly.
I don't really agree to the authority or at least benchmark that you seem to assign to developers. I seriously question that many developers have given this topic a lot of thoughts. There is practically no data on OSM that they could even use to distuish permanent from temporary dealers - even if they wanted to.
No offense, but data consumers are just that, they have no way of verifying the accuracy of data they show to their users (also: "even if they wanted to"). What they define to be optimal behavior is nothing I have any insight to (nor care about). They process and use the data they think is best for their application. If they are not interested in a specific datum, fine. Others might be. I personally would much like Osmand (or other products I might use) to show me the difference between stationary and temporary dealers - once street vendors get really mapped, so far there is only little of them in OSM so it's currently not really relevant. It should be the end-users choice whether they want street vendors mixed with stationary vendors. Not all users share the views of software teams in Norcal and appreciate being imposed their wills, view and moods on (greetings Apple & Google).
I'm not sure there are "ecosystems" handling street vendors deliberately. Currently, street vendors are not identifiable, nor should they even exist because they are temporary features. So they never had the choice to define an "optimal behavior" for street vendors. (I'm ignoring street_vendor=yes here because of its little use and I doubt that anybody parses that.)
For every application that supports amenity=vending_machine, amenity=street_vendor should be really easy implement. Note, this would not be a change of an existing feature (behavior), but a new feature (behavior).
--Freetz (talk) 03:18, 10 November 2022 (UTC)
@Freetz: I still see a contradiction: your proposal rests on the premise that it would make things more straightforward for data consumers, yet here your explanation seems more dismissive toward them. You're proposing a change that impacts them, ostensibly for their sake, but seemingly without much interest in consulting them to validate your predictions. I don't mean to suggest that you must put software developers on a pedestal and submit to their authority, but this "Rationale" section is misleading in its emphasis on data consumers. Maybe it would be better to focus on what you think is more accurate, based on the first principles you've outlined in your proposed definition, and let the voters decide based on the use cases they find important. – Minh Nguyễn 💬 06:48, 11 November 2022 (UTC)
I know similar flea markets as in your picture. I don't know this particular market, but if I see it right, this very vendor operates out of something that looks like an anchored garage and I guess all their equipment and goods are stored inside permanently. This would be a shop=clothes, not a street vendor neither using street_vendor=yes nor amenity=street_vendor. Vendors who sell their merchandise from the back of a truck they drive into the marketplace, however, they would be a street vendor.
--Freetz (talk) 05:29, 9 November 2022 (UTC)
@Freetz: I just picked one that I had uploaded from a Mapillary trace to Wikimedia Commons, but the full trace includes stalls that run the gamut, from the shed seen above to a frame with a tarp that probably gets removed regularly, to tents that definitely aren't sturdy enough to stay overnight, to some basically outdoor displays. I think I would find it awkward and pedantic to draw the line somewhere among these stalls based on degrees of mobility. Maybe I wouldn't consider the proposal to be so extreme if it were to focus solely on standalone street vendors who aren't using space deliberately set aside for them. In any case, feel free to use any of these examples to clarify your proposal further. – Minh Nguyễn 💬 10:26, 9 November 2022 (UTC)
There has a to be a line somewhere in a ruleset and there will always be cases that could be on either side. How rules are applied in practice is the mappers choice in this case. I'm not really suggesting to map invidivual stalls on market places (I'm not oppossed to either if someone does that), I'm happy to consider removing "A street vendor may be the only retailer at a location, or they may be one of several merchants at a market (e.g. farmers markets, food truck courts)" if this would make you more likely to approve the proposal.
--Freetz (talk) 03:18, 10 November 2022 (UTC)

shop=butcher vending value

As mentioned in Talk:Proposed_features/Street_vendors#Missing_vending_values many shops have no clear vending values and this proposal needs to find equivalent vending=* for every single shop.

I think that it is a bad idea as it doubles tagging schema.

But if you are proposing it please add missing vending value for shop=butcher street_vendor=yes

Mateusz Konieczny (talk) 08:06, 7 November 2022 (UTC)

shop=deli also comes to mind. – Minh Nguyễn 💬 08:52, 8 November 2022 (UTC)
I don't think I will add vending=gifts or vending=delicatessen to the proposal explicitely. To me, they are not well defined. "Gift" describes a purpose not a product ("gift shop", more often than not, is just a euphemism for "junk store" IMO). Delicatessen has different meanings in different regions around the world. As written on the proposal page though "Mappers may invent new values as needed.", I just don't want to be the person to explicitely introduce these two :)
--Freetz (talk) 03:49, 10 November 2022 (UTC)
Haha, junk store, the same thought crossed my mind more than once when mapping a shop=gift. – Minh Nguyễn 💬 06:52, 11 November 2022 (UTC)

shop=gift vending value

The same as previous section but for Tag:shop=gift Mateusz Konieczny (talk) 08:06, 7 November 2022 (UTC)

other shops

the same as two previous sections, but for every single documented shop value

Yes, that is obnoxious to setup and use. That is why I think that it is a poor idea Mateusz Konieczny (talk) 08:08, 7 November 2022 (UTC)

Thanks for sharing your concerns. As explained in the proposal and on this talk page, I consider replicating the entire shop-value structure neither needed nor to be a good fit for street vendors but I believe the focus is better placed on the few products and service they offer. I appreciate critism to this approach.
The butcher you inquire would be amenity=street_vendor + vending=meat. If they offer cheese, too, they would be vending=cheese;meat. With shop it would be shop=butcher;cheese, which is a multi-value list that is not appreciated on top-level tags and not widely supported by data consumers.
There are currently 403 elements with street_vendor=yes, for only 131 of them opening_hours=* are available. amenity=fast_food is by far the most popular use of street_vendor=yes at a total number of 190 elements, but only 77 of which have opening_hours=*. By far the most popular shop value is shop=greengrocer with an abbundance of 65 among all elements, but only 6 of them have opening_hours=*. All other shop values have single digit use in combination with street_vendor=yes. To me this shows that there is either significantly less interest in mapping street vendors that do not sell fast food or that mappers find that those street vendors are not appropriately mappable using shop=*. I lean towards the latter interpretation.
I'm happy to include some more vending=* values in the proposal, but this list isn't the heart of this proposal and is expected to grow if there is need. I'm not sure how to define gift different from souveniers. I appreciate your support despite me critizing your formerly proposed tag and despite values you might currently be missing in this list.
--Freetz (talk) 05:28, 8 November 2022 (UTC)
Based on my very limited travels: there is massive number of street vendors in for example Africa operating all kinds of shops. They are basically not mapped at all. If people start mapping POIs in Africa then then tagging will need to cover them Mateusz Konieczny (talk) 07:46, 8 November 2022 (UTC)
If nothing is mapped, then no existing practices are questioned, great :) I can't speak to the needs of African cultures, and whether shop=* is a good fit or not. amenity=street_vendor will add an additional option of mapping. Local mappers decide what and if any fits their trade businesses, or if they need something different. I'm happy to try to include concrete suggestions on how to improve usability of amenity=street_vendor in regions I'm not familiar with.
--Freetz (talk) 05:10, 9 November 2022 (UTC)
"I'm not sure how to define gift different from souveniers" - AFAIK souvenirs are at least sort of related to specific place, while shop=gift sells stuffs usable as a token gift rather than to remind about specific location Mateusz Konieczny (talk) 07:46, 8 November 2022 (UTC)
"that is obnoxious to setup and use." I couldn't agree more. Really, Freetz can say they aren't interested in recreating the shop tags only with vending=* all they want, but I don't see how that wouldn't happen. As a side to that, vending=* should really be confined to vending machines. Otherwise it kind of defeats the keys current definition and usefulness. Which was determined through an approved proposal BTW. Not that definitions or usage of approved tags can't change, but it probably occur through it's own separate proposal instead of being shoe-horned into this one. --Adamant1 (talk) 13:23, 12 November 2022 (UTC)

Temporary presence needs better tagging

I'm not happy with either street_vendor=yes or amenity=street_vendor, for different reasons. I don't think someone cleaning shoes and someone selling watches have anything in common, except for being only there temporarily. One is a mobile craftsman, the other a mobile shop. Yet, when a renderer sees an unknown vending=*-tag, there would be no hint whether that is a service, a product, or maybe religious blessing. Are we expecting a generic "street vendor" icon? Sounds absurd to me. Since this doesn't apply to vending-machines, the problem hasn't surfaced there. The other reason is that "misusing" the opening_hours=* key for presence. I know we're doing that elsewhere, but that doesn't mean it's a good idea.

We should rather think of a proper way to tag anything temporary, not only street vendors. Very much like seasonal=*, xmas:feature=*, and also farmer's markets. So rather than introducing amenity=street vendor, it's probably more feasible to have a generic present=* tag, like present=Mo-Fr 08:00-14:00 which would state that something isn't there 24/7, but rather temporarily, but on a continuous schedule. We're currently tagging farmer's markets as if they were a permanent feature, it's just up to the renderer to understand that the opening_hours=* imply absence on off-hours. Do we really want to add another special case to this?

I don't want to fully flesh out a proposal here, but I think approaching the general problem of temporary, yet regularly present features, needs a different solution than solving it for the specific use-case of street vendors and misusing opening_hours=* for times when something is physically there instead of just open/closed. --Nadjita (talk) 08:49, 7 November 2022 (UTC)

Thanks for your comment, I see four topics that I try to address separately.
1. Differentiate between street vendors who trade good and services:
Both kinds of vendors are commonly understood as street vendors, see the references in the proposal. I don't think it is useful to differentiate them in the present context. What is a vendor who both sells and shines shoes? I don't propose icons for rendering. This is the very responsibility of application designers. (Personally, I think icons that are too specific are not practical, both from the application and end-user perspective. I'm sure there is a reason why Google and Bing have only a small number of different icons for shops and the like.) I don't see a problem with a single icon for street vendors. I'm not picturing a scenario to be realistic in which someone looks at an icon in a map in an app, thinks "hey there is a street vendor, they might sell french cheese", goes there without checking in the app what that vendor has to offer, and finds themselves disapointed when they realize that the vendor sells pumpkins or manicures, or even both. What the vendor has to offer is best represented in text and not graphically (but that's up to the application designer).
2. Misusing opening_hours=* to indicate presence:
This is not what is proposed. The proposal text is "describes when vendor is present and selling". The focus here is really on the selling. It is trivial that the vendor is present when they are selling, so that addition could be left out if someone is bothered too much by it. The time when a street vendor is present and not selling is not verifiable; they don't usually post how long is takes them to set up and dismantle their display. Neither do I think it is relevant. To me, street vendors on OSM are only for marking potential shopping opportunities (with a significant risk they are not there), but not for landmarking in any way.
3. Tagging using present=* or seasonal=*:
In my view, any tag that is added to amenity=* or shop=* that effectively questions that the feature is permanently present until this tag is checked, is trolltag. present=* or seasonal=* would do that.
4. Tagging using a new/dedicated namespace:
Something like street_vendor:shop=* or street_vendor:amenity=fast_food would work for to at least retire street_vendor=yes. This would probably be my least favorite solution since it is not adapted to the specifics of street vendors. In my view, it is very desirable to tag the few products and services a street vendor offers rather. I know that there are some other temporary objects on OSM. For simplicity I focus on street vendors. I don't want to go down the rabbit hole to find something that works for everything :) I believe amenity=street_vendor is a good fit for street vendors. Other problems might need different solutions.
--Freetz (talk) 01:36, 8 November 2022 (UTC)
I'm gonna answer to each of your replies individually
1. I think there is a big difference between providing a service for money and selling something for money. The latter is a shop the first one isn't. You can argue all the way you want, it's simply not the same and we should not copy the mistakes that were made when cramping everything into shop=* instead of distinguishing between offering a service and selling products. shop=hairdresser always gives me shivers.
2. That seems nitpicking to me. "describes when vendor is present and selling" is what opening_hours=* is about, but in your case, it complete removes the feature most of the time. To put that into perspective: If your street vendor isn't there, no one could go there and verify your claim. That's a big difference to any other shop/amenity that is usually there all the time. I know you're implying that with your definition, but it's yet again another exception where each consumer has to know that opening_hours=* for shop=street_vendor means that the whole shop isn't to be found after the opening hours. As I also mentioned, we have the same exception for farmer's markets and you're just trying to add yet another exception, instead of finding a generic solution. That's what I'm complaining about, and that's the one thing you haven't addressed…
3. seasonal=* and present=* are not any more or less trolltags than any other tag that describes a temporary feature. By your definition, the whole amenity=marketplace is a trolltag. If you are so concerned about misinterpretation, then there's always the possibility to add another namespace to the main feature. Like regular:shop=hairdresser paired with present=Mo-Fr 08:00-20:00 or regular:present=Mo-Fr 08:00-20:00. I'm not proposing to use that, just showing that there are generic solutions one could come up with. Like I said: I don't want to flesh out a full proposal, I'm just saying that your current one is adding yet another exception to well-understood rules that would be better solved by a generic solution. "All the shops are there permanently, except for when the value is "street_vendor"" is just a plain old exception, not a generic solution.
4. Using a namespace like street_vendor:=* would work, but again, it's a specific solution to a generic problem: how to tag temporary, yet regularly present POIs. Think big, not small. There's are more temporary things to map than just street vendors. Would street_vendor:amenity=marketplace work? Obviously not… regular:amenity=marketplace? Moreso. But don't nail me down on "regular", I'm just using it as a placeholder of a proper namespace. Could be temporary=*, regular=*, periodic=*, or anything else that fits the brief. I'm not a native speaker and naturally very bad with these terms.
(1. I think you were more commenting than critizing this proposal here. Anyway, I don't see where you conclude from that only goods are sold in a shop but not services. This does not comply with OSM Wiki's definition of shop (which doesn't say a lot), but also not with any other source I've come across. Being nitpicking, a shop is really only just a word for a (commercial/professional) establishment, such as a building or a room in a building (strict definition), maybe even a piece land or floor (less strict definition). With our without walls and roofs, a shop is definetely some form of estate where the operator has the right to ask others to leave - that's not the case for street vendors. A machine shop is a shop, so is a workshop. "Shop" doesn't say what kind of business or profession is done, nor even if any. An emtpy shop is still a shop.) But some people on OSM Wiki question this despite arcticles reputable dictionaries. Anyway, I don't want to discuss about this here as it is off-topic.)
1.-3.: I'm having the impression that you might have misread my proposal and would like to ask you kindly to re-read. I'm not proposing shop=street_vendor, I propose to get street vendors out of the shop tag by using amenity=street_vendor. It is perfectly accepable to me that nothing is implied about the presence of a amenity=street_vendor outside its opening_hours=*. amenity=street_vendor is a top-level tag, and as such has its own definitions. "Undefined presence outside its opening_hours=*" is one of its most important peculiarities. I'm not defining trolltag, I only conclude that street_vendor=yes applied to shop=* meets the explanation of a trolltag on the Wiki page ("In general, any tag that must be processed to avoid serious misinterpretation of the feature is a trolltag." To me, misinterpreation of the presence of a feature is serious). I have absolutely no problem with amenity=marketplace. It is rightly tagged as an amenity and not as a shop. A marketplace is a place, and it exists when the market is not there.
4. Any namespace such as temporary:shop/amenity=* would probably work, however, this misses a major aspect of my proposal that is to handle street vendors differently from shops in the first place and to tag them by the products and services that they offer using vending=*, and not by a single shop category a mapper feels obliged to squeeze them in.
--Freetz (talk) 03:12, 9 November 2022 (UTC)
Sorry for mixing up shop=street_vendor with amenity=street_vendor, but the arguments stay the same: you're trying to mix services/craftsmanship with product in the same way this has been done with the shop=*. Hairdresser is a shop, restaurant/fast_food isn't. It's all over the place. And putting them all into vending=* makes it even worse. Instead of shop=hairdresser, we end up with vending=haircut;hairstyle;hair_coloring and the likes (maybe even haircuts, because someone puts in the plural). This would require a data consumer to understand how these are all related, because when we think of a "hairdresser", we basically know that we can expect certain services to be sold. We can precise some of them later on with the beauty=*-tag, but your proposal doesn't do this. You're not proposing a general "this is a mobile hairdresser", which can be refined later, you only want to specify specific services/products to be sold. It might work for some things like "food", but for services, I see lots of issues, because most professions cover more than just 1 service. You're basically moving from a smaller set of "base"-tags (from shop=* and amenity=* and the likes) to a plethora of precise vending=*-tags which sometimes have nothing in common with the base-tags and would require a huge amount of documentation and would be hard to consume. That's in addition to mixing craft/service and products. But I said that several times now ;o)
As to 4., there's nothing more to add here. I thought it was an overlook, but apparently, you want to design it that way. I disagree with this being a good idea along with many others here, and I'd prefer to see a generic "temporary, but regularly present shop"-way of tagging things instead of splitting a whole bunch of shops and amenities into their products and services.
I do agree that it would be nice to generally be able to add them to any "vendor" (or craftsman, or…) in addition to giving them some "base" class, but not instead. If you're considering your amenity=street_vendor to be the "base tag" and vending=* to be the refinement, then we are simply in disagreement of this being a good idea and I can live with that.
A haidresser would simply be vending=hairstyling in my idea (-ing form for services were possible). I don't consider it to be reasonable to pico-tag services or goods. I would be okay with distinguishing services from goods in separate tags, if there's a wider preference for that, e.g. vending=* for goods (to still fit with vending machines) and vending:services=* for services. I see that this could make sense.
What would be your preferred way of tagging a street vendor who sells both meat and cheese?
--Freetz (talk) 03:33, 10 November 2022 (UTC)
"A haidresser would simply be vending=hairstyling." No insult, but it seems like you fundamentally don't get what the vending tag is for. Either that, or you just don't care. Maybe you're just not fluent in English. Who knows. Either way though, vending=hairstyling is just nonsensical. The same way vending=bicycling or really any vending=whatevering would be, because "ing" implies an action and nothing (vending machines, street vendors, or anything else) "vends" actions. Just an FYI, but a good way to figure out if it would work or not is to remove the "ing" from it and see if it still makes sense. Like in this case, if you get rid of "ing" from hairstyling you have vending=hairstyle. Which clearly doesn't work. Or conversely, you could add "ing" to the end of keys that we already know work with vending=*, like say vending=cheese. Does vending=cheesing make sense? No. So there's really no way grammatically that vending=hairstyling or anything else with "ing" added to it would work. Again no insult, but it really seems like your just working backwards from your own conclusions in the moment to post hoc justify the proposal and didn't really think it through ahead of time. --Adamant1 (talk) 13:03, 14 November 2022 (UTC)

Leaving the stand behind

There's a passage I found confusing until I reread it a few times:

If the retail stand is not permanently present 24/7 year-round, including when closed or on vacation, a retailer may only be mapped as a street vendor. (However, leaving the stand behind after business hours does not automatically make them a shop but they are still a street vendor.)

At first, I thought the second sentence was implying that they would be a street vendor if the stand could not be moved after business hours, but I guess it's actually saying that a street vendor is still a street vendor even if the stand is technically portable but they leave it there nonetheless. Consider a wording like "leaving a portable stand behind" to reduce confusion.

 – Minh Nguyễn 💬 07:42, 11 November 2022 (UTC)

Food trucks

@Freetz: Above this you said "A street vendor may be the only retailer at a location, or they may be one of several merchants at a market (e.g. farmers markets, food truck courts)." So I assume the tag would be used on food trucks. If that's the case, I'd be interested to know how you think they should be tagged in conjunction with this since obviously it would preclude the usage of tags like amenity=fast_food, amenity=restaurant, amenity=cafe. Obviously substituting those tags for something like vending=restaurant or whatever would be suboptimal. Whereas, a tag like vending=cafe is just nonsensical. --Adamant1 (talk) 13:16, 12 November 2022 (UTC)

@Adamant1: I'm not sure I understand your question, so please rephrase if I'm not answering. Yes, food trucks could be a amenity=street_vendor + vending=fast_food + cuisine=* as shown in the examples. There will be no amenity=fast_food, amenity=restaurant or amenity=cafe in the node.
--Freetz (talk) 18:12, 13 November 2022 (UTC)
I asked this in Talk:Proposed_features/Street_vendors#Original_author. The suggestion to use vending=* for food items then vending=fast_food for service type is conflicting, when many fast food items are already tagged in vending=*. By extension, the overlap with cuisine=* is yet another issue. --- Kovposch (talk) 13:26, 12 November 2022 (UTC)
@Kovposch: vending=pizza etc isn't really a good tag. It doesn't say if ready-to-eat pizzas are sold or raw ones that need addtional preparation (it only says usually hot). That's a weakness of the existing tag. vending=fast_food + cuisine=pizza makes clear that the pizza is ready for consumption (whether hot or cold). I think applying vending=fast_food + cuisine=* to amenity=veding_machine would make a lot of sense and to redefine vending=pizza as not ready-to-eat pizzas only, but that's a different topic. vending=fast_food does not describe a service, fast food is the good that is sold.
--Freetz (talk) 18:12, 13 November 2022 (UTC)
Tag:vending=pizza has already been described as " (usually hot)". This assumption should not be redefined. Rather you should introduce something new for frozen food.
Why should vending=fast_food be used for ready-to-go, when the existing vending=* food item is already associated with it? Should those in amenity=vending_machine be moved too?
In fact, there are quite a few selling frozen breads. Should they be vending=breads and vending=pastries?
--- Kovposch (talk) 11:33, 14 November 2022 (UTC)
Sort of off topic, but the idea of a vending machine selling frozen pizza sounds really weird to me. Like, why would someone get a pizza from a vending machine in the first place if they have to go home and microwave it before they can eat it? Lol (not that there isn't vending machines out there that dispense fresh food, but the assumption with something like pizza is that it will be hot). --Adamant1 (talk) 12:47, 14 November 2022 (UTC)
Probably as alternative of going to regular shop and buying frozen pizza there. there are some new fully-automated shops in my country that are basically shop-sized vending machines. And I heard that Japan has places where there is huge number of individual vending machines selling all kinds of stuff Mateusz Konieczny (talk) 13:00, 14 November 2022 (UTC)
You know, I was actually looking at those earlier and the few websites I could parse through referred to them as stores, not vending machines. I'd be interested to know where the line is between an automated shop and a vending machine though. I'm not going to claim to know where it is. Japan definitely has their own unique thing going with vending machines and I wouldn't be surprised if frozen pizzas was one of the items they vend. But it wouldn't be the norm and like Kovposch said Tag:vending=pizza has already been described as usually hot. Not hot in every single case. The question is should the vending tag be completely re-jiggered based on the few exceptions just so it can be shoehorned into this proposal and in turn used for street vendors. Personally, I say no. --Adamant1 (talk) 13:25, 14 November 2022 (UTC)
Yes, frozen food vending machines have been growing. They are intended to be sold to customers who take them back home for preparing their next meals. This is an alternative to staffed shops to save cost, while expanding presence and hours.
Some of them are vending machines in front of their staffed shop. Some are the usual setting of vending machines in other random locations. For your question, there are indeed vending machines installed alone in a shelter for the sole purpose of selling its content.
But they are not the same as the recent trend of automated shops. Those have open shelves. They are paid at a counter, or automatically checked-out when you exit with them.
What Mateusz could be thinking about:
You are correct to expect frozen pizzas. There even seems to be as many of them as frozen bread.
Maybe off-topic, but this shows the effect of changing vending=* in amenity=vending_machine. (also an excuse for me to write about and promote this niche)
--- Kovposch (talk) 14:50, 14 November 2022 (UTC)
"You know, I was actually looking at those earlier and the few websites I could parse through referred to them as stores, not vending machines" - yes, functionally these are stores Mateusz Konieczny (talk) 16:24, 14 November 2022 (UTC)
"Yes, frozen food vending machines have been growing." It's an interesting use case I guess, just not something that I think is ubiquitous enough yet to justify completely re-working the meaning of the tag to include street vendors. Although, admittedly I've kind of lost what the point in the discussion is. As well as how vending machines providing people with frozen food relates to it. Like to go back to my original point, vending=cafe is still nonsensical even if there are vending machines for frozen pizza out there. As well as if the vending=pizza tag presumes it's ready to eat or not. Maybe that's just me though. Although I will grant that it's an interesting side topic, but does mainly serve to derail discussion of the wider point that I was making in my original comment none the less.
"Yes, functionally these are stores." So they are "functionally" stores, but still vending machines? Interesting. Totally irrelevant, but I've been increasingly feeling like tagging and really OSM more generally is going through a post-modern, destructionist phase lately where everything is relative and nothing has any objective meaning. First it doesn't matter that vending=* is meant for tagging products dispensed by vending machines and can also be used for services. Now places that are "functionally" stores are vending machines. Next it will probably be something like a vending machine that dispenses frozen pizza is a restaurant or one of those vending machines that serves hot coco is a cafe. Sigh. --Adamant1 (talk) 02:32, 15 November 2022 (UTC)
@Adamant1: I want to use "going through a post-modern, destructionist phase" in a changeset comment sometime. That's amazing. Only slightly more seriously, Papa Murphy's is a large "take-and-bake" pizza chain in the U.S., and it's being tagged as amenity=fast_food cuisine=pizza takeaway=only, where "fast" apparently refers to the speed at which they take your money. – Minh Nguyễn 💬 03:38, 15 November 2022 (UTC)
  • Deconstructionist. Probably a Freudian slip, but they have the same meaning and either one would be a pretty funny changeset comment lmao. I forgot about how Papa Murphy's are tagged. I could have sworn there was a discussion about that on the Name Suggestion Index's issue tracker at one point but I can't find it. Either way, IMO Papa Murphy's isn't really fast food since you still have to take it home and cook it.
For something to be fast food the food has a short preparation and serving time. It doesn't really have anything to do with how quickly the place takes your order. Like I wouldn't tag a place that specializes in selling pre-prepped, uncooked pies as amenity=fast_food because you still have to take the pie home, cook it for 45 minutes, and it has to cool off before being served. It doesn't magically become fast food just because it's pre-made, I'm the only one in line, and it takes 2 seconds to pay with my debt card and leave the pie shop since there's still an inordinate amount of time involved on my end before the food can be eaten. --Adamant1 (talk) 04:27, 15 November 2022 (UTC)
@Adamant1: oh, I definitely tagged it as shop - see https://www.openstreetmap.org/node/1786556278 (though ideally "you need to install an app to shop there" would be somehow captured) Mateusz Konieczny (talk) 15:20, 15 November 2022 (UTC)
OK. If nothing else it will be interesting to see how mappers and tagging adapt to all these new fangled hybrid things that are coming out as the technology advances. I could see the merits of creating new tagging schemes for mapping things like "stores that are vending machines" or whatever, but figuring out where the line is and what tags to use is definitely complicated. --Adamant1 (talk) 04:29, 16 November 2022 (UTC)

Current usage of vending tag

The current usage and definition of vending=* and it's sub keys where determined through an approved proposal and explicitly relate to vending machines. Obviously, for a number of reasons it would create massive problems if the definition/usage was expanded beyond that to include street vendors. One reason being that someone looking for a soda vending machine is look for exactly that, a soda vending machine. Not a street vendor who "vends" soda. Also, once you divorce the term "vending" from vending machines it becomes rather generic, to the point of being meaningless. Sure, you could technically define it as "A person or company offering something for sale, especially a trader in the street" (which is how it would have to be defined if used on street vendors), but then that definition could apply to literally anything having to do with the sale of goods. I'm not sure how you can reconcile those things either. It looks like "vendor=whatever" has 19 uses. That might be an option instead of co-opting the main vending tag. But again, the word isn't well defined. --Adamant1 (talk) 13:39, 12 November 2022 (UTC)

@Adamant1: vending=* requires (not implies) amenity=vending_machine as per Wiki page. Any consumer who does not check for amenity=vending_machine on a node with vending=drinks has an undefined behavior problem already to begin with. I don't know about the history of vending=*, but if it was meant exclusively for amenity=vending_machine, it should better haven been vending_machine:vending=*. But since vending=* does not imply amenity=vending_machine, the possibility for future application to other top-level tags was built in. I don't understand your comment "Also, once you divorce the term "vending" from vending machines it becomes rather generic, to the point of being meaningless. Sure, you could technically define it as "A person or company offering something for sale, especially a trader in the street" (which is how it would have to be defined if used on street vendors), but then that definition could apply to literally anything having to do with the sale of goods.". vending=* describes the goods and services being sold, not the seller.
--Freetz (talk) 19:03, 13 November 2022 (UTC)
amenity=street_vendor + street_vendor=* might have been mentioned somewhere before vending=* is publicized here. You point out a problem in reverse. Adding vending=* services prevent them from being used on machines selling such items. In Japan, there are vending machines established by shops to sell their hair oil, conditioner, conditioner, scalp treatment, and shampoo (vending=hairstyling?); nail oil and nail strips (vending=manicure?), aroma oils (so suitable for vending=massage?); and perhaps more. By doing so, this would require a self-redundant vending=*_supplies as found in shop=* and trade=*.
If anyone is interested:
--- Kovposch (talk) 14:19, 12 November 2022 (UTC)
@Kovposch: The machines in your pictures, I would tag with vending=soaps or vending=cosmetics. If it's really important for a particular POI, I could maybe understand if a mapper chose vending=shampoo and vending=nailpolish. But going down the rabbit hole to conditioner and nail oil would the pico-mapping IMO that is not useful IMO. We cannot map every tray in a vending machine or on a street vendor cart, but should limit ourselves to what's predominatly sold and tag that in a reasonably generic fashion. Should reasonable examples exist, I don't see immediately a problem with vending=*_supplies, and I could well imagine street_vendor=* + vending=massage;massage_supplies. I'm not proposing to define those vending=*_supplies, but one could and they'd make sense - if reasonably applied.
--Freetz (talk) 19:21, 13 November 2022 (UTC)
Redefining vending=* for service, then re-adding vending=*_supplies for what it suppose to sell is unacceptable. The words chosen don't make it clear they are services either. If you want to try your luck, you could even do the reverse of vending=service or vending=*_service. (I still won't agree with it) --- Kovposch (talk) 11:21, 14 November 2022 (UTC)
Is someone drawing pictures vending=art? --- Kovposch (talk) 11:24, 14 November 2022 (UTC)
"Redefining vending=* for service." I was going to say that vending=* has nothing to do with services. "Specifies the type of items dispensed by a amenity=vending_machine" makes it pretty clear that the tag is purely for mapping what items are sold by a vending machine. That's it. Maybe you could extend that specifying the types of items sold by a street vendor, but as I've said extending it should be done in a separate proposal and it still wouldn't work for "services" anyway. This would be where my whole "once you divorce the term "vending" from vending machines it becomes rather generic" comment comes in. If a take tag like shop=* and expand it to include offices, you divorce it from the original intent and meaning behind it. Which makes it extremely generic and essentially worthless as a tag. Same goes for this, the tag is meant for items. You make it also usable for "services" and it essentially loses it's meaning and usefulness. You can chalk that up to consumers having undefined behavioral problems already to begin with or whatever, but it doesn't negate the fact that tags have specific ways they are used that can't just be extended into completely separate categories of objects or concepts. At least not without a lot of forethought, planning, and discussion happening first. In this case, vending=* would be essentially worthless in it's current usage if it was expanded to include services provided by street vendors. --Adamant1 (talk) 12:33, 14 November 2022 (UTC)

Seating

The photos that this proposal uses to illustrate vending=fastfood happen to omit a very common feature of outdoor food vendors. There should be at least one example of what to do when the vendor sets out tables and chairs. In Vietnam's large cities, mobile street food vendors outnumber indoor restaurants, and many set out substantial seating areas that do indeed serve as navigational landmarks. Many will seat more customers than a cramped indoor restaurant. As the "Additional tags" list indicates, outdoor_seating=yes would apply, but should the more substantial seating (beyond "bar seating") be mapped as a separate leisure=outdoor_seating? These tables are just as ephemeral as the food stand, but hopefully no one is going to map them as vending=seating! ;^)

  • Ho Chi Minh City: tables and chairs

    Ho Chi Minh City: tables and chairs

  • Huế: bar seating

    Huế: bar seating

  • Mexico City: tables and chairs

    Mexico City: tables and chairs

  • Mexico City: bar seating

    Mexico City: bar seating

Meanwhile, near me, there's a taco truck that packs up and leaves every night. However, they've erected a prominent sign and a picnic shelter on the same plot of land. It even has a signposted address. [1] The sign and shelter itself can't be moved, but they do remove the food truck and picnic benches and lock the gates every night. I suppose this is a clever workaround for the stringent building and health codes in my area.

 – Minh Nguyễn 💬 01:44, 13 November 2022 (UTC)

On-premises food truck

Some Mexican restaurants in my area also run food trucks as part of an industrial catering service. They'll park one of their food trucks right outside their restaurant and operate both at the same time: if you want sit-down service, you go inside; if you're in a hurry, you grab something from the food truck. At a glance, this would fall under the "mobile stand where a seller offers goods or services just outside their shop" case, but if I can't tag that as an amenity=street_vendor, would I tag it as an amenity=fast_food right outside the amenity=restaurant? The food truck typically stays in the same location when closed, but there's no guarantee. There's one around the corner from me that has been parked in the same location for years, except on rare occasions, when you can just go inside for the same service. [2] – Minh Nguyễn 💬 01:44, 13 November 2022 (UTC)

I haven't noticed such restaurants in my area yet, so I'm not quite sure if I'd map them with amenity=restaurant + takeaway=yes on the restaurant or amenity=street_vendor + vending=fast_food on the truck. Yes, at first glance it sounds as if "A mobile stand where a seller offers goods or services just outside their shop is not a street vendor" would apply? I personally might not tag the trucks separately, in particular if they sell the same stuff an inside the restaurant, or if the food is even prepared inside, just to have not too many POIs for the same thing. But I could see these trucks being mapped either way, depends on the very restaurant and truck, and the mappers preference. It might be unrealistic that everybody follows any given rule in this particular case as they would need to excatly know whats written on the Wiki, which frankly, most mappers don't. The bottom line, yes, if separately, then amenity=street_vendor. Maybe I need to clarify that a stand just outside a shop should not be mapped separately but is part of the shop. Thanks!
--Freetz (talk) 17:43, 13 November 2022 (UTC)
@Freetz: I agree there's no requirement to map the food truck as a separate feature, at least as a first pass. However, we've needed to micromap the ones around here because the food truck is only open during busy times. In the Mapillary image above, the food truck is closed but the restaurant is open. You can get takeout service from the restaurant if needed. I realize this same situation can happen with a drive-through window or walk-up window, giving rise to subkeys like opening_hours:drive_through=* and opening_hours:kitchen=*, but a physically separate food truck means mappers might want to tag other aspects too, such as height=*. I like this approach of saying that amenity=street_vendor can be a form of micromapping. (This contrasts with the markets I mentioned above, where such vendors are the norm.) – Minh Nguyễn 💬 18:52, 13 November 2022 (UTC)

Radius

Is the 15-metre (49 ft) radius a rule of thumb, or is there a particular reason the threshold for mappability isn't shorter or longer? – Minh Nguyễn 💬 01:45, 13 November 2022 (UTC)

As written above: I'm not fix on that. I think 15 meters seems somewhat reasonable to me in as "most of the time the street vendor can be spotted from 15 meters away". 50 meter, on a straight emtpy street, okay. But not in crowed downtown? What are other opinions? In any case it's a rule of thumb or course, nobody is expected to map with a laser distance meter :)
--Freetz (talk) 17:47, 13 November 2022 (UTC)
@Freetz: Oh, I missed that discussion, sorry. I suggest noting it as a rule of thumb and explain the reasoning you used. Otherwise, over time, some mappers will lawyer about numbers they see in tagging guidelines as if they're fixed laws of nature. :^) Some related guideline pages might need to be updated as well, such as Key:visibility and Good practice. – Minh Nguyễn 💬 18:44, 13 November 2022 (UTC)

Incompatible vending values

There are a couple of values listed for vending=* that contradict the already existing tags, e.g. 'candies' instead of 'sweets' or 'breads' instead of 'bread'. --Mueschel (talk) 09:48, 14 November 2022 (UTC)


Proposal abandoned

I've been what "how did I contribute?" calls a "Heavy Mapper (Very Active)" for a decade. A great portion of my mapping activities went into mapping all kinds of retail businesses, from initial mapping to updating, in several different regions across the world where I've spent significant amounts of times. Recently, I had the idea of getting more involved in the Wiki because of various things that bugged me.

I wrote this proposal because I was really shocked when I came across street_vendor=yes. I don't remember that I have ever seen a tag that felt more wrong than this one. So I thought about how to retire this tag (before it becomes popular) while preserving its idea and still include street vendors on OSM. While I knew my proposal wasn't finished and may even have had minor inconsistencies, I was looking forward to some great suggestions on here to help polishing the proposal. I'm actually pretty disillusioned by the reactions and dynamics on this talk page now. Most comments just criticize and don't suggest improvements or alternatives. Some people get caught up in details that really don't matter at this stage of a proposal where it's not even clear if there is support for the fundamental ideas in this proposal:

  1. include street vendors in OSM
  2. tag them separately in their own top-level tag
  3. tag them by the things they offer with a multi-value list rather than by single category shop values

I wonder why some people keep repeating I wanted to re-create the shop infrastructure when I'm actually criticizing the shop tag and propose something different. Maybe I didn't explain my idea well enough? I wonder why nobody who criticizes 3. answers how they would prefer to tag a street vendor who sells both meat and cheese. I wonder why not distinguishing services from goods seems to be a pet peeve for some, and why they even keep arguing long after I wrote I'd be fine with putting services in a separate tag. How do they end up at things like vending=cafe and vending=bicycling? I also wonder why some people do get insulting based on their belief "vending" couldn't be applied to "actions" ("gerund" to be more grammatically accurate btw, as I'm sure the real fluent english speaker knows, that describes a paid service in this case). Do they see the problem in "vending", or would they also have a problem with "selling"? What about "offering"? And shouldn't their literacy enable them to suggest wording that is acceptable for them? I mean, they obviously get the idea of what is being tried to express. But perhaps that's not what they are interested in or have in their skill set. Oh, and why did we discuss cold pizza here in lengths? I also find it strange that people (on the mailing list) accuse me of imposing allegedly European concepts of shopping on other parts of the world while they themselves make questionable statements that could be read as if the use of buildings rather depended on climate than on wealth.

If it was just one or two people who are more destroying than supporting, I wouldn't bother, but it somehow seems to be a pattern among many contributors here in this very proposal page - although not everybody and I appreciate and I'm grateful for the input of those. Yet I find this environment overall unproductive and unpleasing. That said, I will not put any more efforts into this proposal. I still think it is good in its major aspects and I hope that mappers will adopt it in one way or the other. If anyone likes the spirit of this proposal and would like to develop it further, please do so.

-- Freetz (talk) 07:37, 15 November 2022 (UTC)

Lol. --Adamant1 (talk) 10:47, 15 November 2022 (UTC)

@Adamant1: That's not a very helpful response. Whatever your take on the merits of this proposal, Freetz's frustration is one that others share about the proposal process too. I appreciate them taking the time to explain why they abandoned the proposal. Most proposals get abandoned without even saying so, leaving future mappers to wonder forever.

All I can suggest as an antidote is that we could encourage future proposals to be more of a wiki-style collaboration than an adversarial review process, at least initially. But from what I've seen with successful collaborative proposals in the past, there first has to be an agreement about the problem being solved. That's why I focused on that aspect the other day. A strong enough problem statement would be able to overcome skepticism about the tagging particulars; commenters would be more motivated to suggest alternatives.

Personally, I came around to seeing that maybe something could be improved about how street vendors are tagged to minimize end-user surprises, but it's unfortunate that by then the discussion had already gone down other rabbit holes. If we could start over from scratch with a brand-new proposal process, I would prefer baking in an initial phase where we collaboratively put together a requirements document before floating a possible solution. Some of the people involved on this page have been quite heavily involved in the proposal process; maybe they have ideas on how to make that a reality.

 – Minh Nguyễn 💬 17:52, 15 November 2022 (UTC)

+1, that response was not useful in any way Mateusz Konieczny (talk) 18:10, 15 November 2022 (UTC)
@Minh Nguyen: and @Mateusz Konieczny: My comment was mainly in response to the whole thing Freetz said about the frozen pizza thing semi-derailing the proposal. Which I found funny because the issue of conversations getting side tracked with super pandemic side points is something I've gone off on other people about before, but totally participated in this time. The comment had nothing to do with Freetz or the proposal in general though. But I'll agree that it probably wasn't useful without the context. I had actually a much longer, more serious response that addressed some of the points Freetz made but it was lost because I keep getting logged out of the Wiki when I go to save messages for some reason. Quick messages like "Lol" just happened to be what it would allow me to post at the time. Again though, it didn't really have anything to do with Freetz or the proposal. Just that it partially got derailed over frozen pizza. --Adamant1 (talk) 04:20, 16 November 2022 (UTC)
"I wonder why some people keep repeating I wanted to re-create the shop infrastructure when I'm actually criticizing the shop tag and propose something different" - because doing that something different requires a new way to tag the same info (what type of things or services is being sold by given business) Mateusz Konieczny (talk) 18:12, 15 November 2022 (UTC)
"I don't remember that I have ever seen a tag that felt more wrong than this one." + "tag them separately in their own top-level tag" - maybe starting thread at https://community.openstreetmap.org/ "should we consider street vendors as a shop or a separate entity" would make sense? I am myself curious what is the general opinion of people and whether I used "shop" in some unusual/broken/Engrish way (I am not a native speaker) @Freetz: Mateusz Konieczny (talk) 18:16, 15 November 2022 (UTC)
"How do they end up at things like vending=cafe?" The reason I "ended up at vending=cafe" is because there are street vendors who sell beverages including coffee, which I don't think vending=cafe would work for, and I wanted to know what tag you would propose as an alternative since it's your proposal and your the one saying people should use vending=* on street vendors instead of amenity=*. At the end of the day it's your job as the person who created the proposal to address people's concerns about it and provide clarification on things when someone isn't sure about something. I really don't see what's complicated about that or why it would be an issue for me to ask what you would use instead of vending=cafe to map street vendors that sell beverages. Again, your the one proposing people should use vending=*. At the bare minimum you should be able to say when and how to use it, or the alternatives.
"Would they also have a problem with "selling"? What about "offering"?" I was going to suggest using sales=*, one of the many namespace alternatives, or possibly one of the various iD presets out there that sort of cover this kind of thing. I decided not to though because none of the have any kind of wider support anywhere or consensus. Plus, I just think they fit well. So, I didn't suggest them. There are alternatives to vending=* though. You just have to weigh their various pros, cons, and figure out how to get the community behind whatever tag you pick. IMO getting the communities support behind a single tagging scheme is the main issue. But that's on you to figure to parse through if you feel like it. Really though, you should have figured what alternatives existed before you did the proposal. Usually it's extremely important to have all the ducks in the row pre-proposal if you want it to have even a half chance of passing. You can't really expect random users to do the leg for you during the RfC phase though. That's not really what it or they are for. --Adamant1 (talk) 04:53, 16 November 2022 (UTC)
First of all, I’m sorry to see that you found this an “unpleasing” experience. I think this should not happen in a collaborative project, and it’s probably not your sole fault. I take my share of responsibility. If I can try to give some constructive feedback, trying to explain a bit the result:
  • You tried to tackle too many different topics in the same proposal, with a pretty complex solution affecting other existing tags. This made many people coming to raise a lot of different issues.
  • Your proposal was already complete when you started asking for feedback. It was very difficult to make any modification else than minor fine-tuning.
  • Personally, I found the tone and some sentences contained in your original proposal sounding too aggressive/patronising (sorry for the terms, I’m trying to be honest about how I perceived it). Things like “As such, tagging them with shop=* is wrong” (I see you removed it later), “This is absurd” or “is incompatible with the commonly accepted meaning of data in OSM” does not set others in the best mood to write nice and friendly feedback. And when I saw the comments and your replies in this discussing page, this mood didn't get any better.
  • Of course, it’s easier to criticise the weaknesses and side effects of a proposal than building something better. If you make a proposal, I think it’s normal that the most urgent thing for others is to raise the alarm about its potential problems before it’s approved.
  • On top of that, I still think that this proposal tried to address a very little or non-existing problem. Probably, you didn’t find anybody supporting this enthusiastically, because nobody has a real issue with the existing solution. If you had an idea to improve shop=* maybe you should have started there, because I think we all have problems tagging shops…
Overall, I would like to remark the positive side of all of this: There are lots of people thinking in doing OSM better. Maybe this time we were not able to find a solution, but perhaps next time... --Barahona (talk) 20:48, 21 November 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Street_vendors&oldid=2667842"