How about limiting the list to product categories, according to an agreed taxonomy? Particularly categories which help to distinguish one shop from another. For example supermarkets might be expected to sell frozen food, but occasionally they might not. So frozen food would be a candidate for a product category. Some sell electrical goods, but not all of them. Another candidate for a category I think.
The category level has to be high enough that it will be stable and not change frequently, but low enough that it has some value in deciding whether a shop is worth visiting. Striking this balance is something we are not always good at, as the discussion easily gets polarised and the outcome (if there is a clear outcome) is often a design-by-committee Frankenstein's monster of a tagging scheme... There has been a proposal in the last few days to redesign our highway tagging. Clearly this is not going to make it (because we have already a very well-established tagging scheme for this), but it does illustrate that a somewhat scientific approach to these tagging taxonomies, including some objective criteria to classify against, may have great value in the future. So in the context of shops, there must be an existing taxonomy somewhere that we could leverage. Possibly within the business itself (how do Tesco/Walmart classify their shops? What attributes do they store?) or industry organisations or statistical bodies (anything they provide statistics on, like "how many shops sell childrens clothes?" is a hint for a product category). I would suggest that a category-based tagging scheme would be "OSM-Core" but of course anyone can extend this scheme to include lower-level data such as individual products as required, while staying within the core category scheme (i.e. not duplicating it or competing with it). //colin On 2016-03-07 09:45, Warin wrote: > On 7/03/2016 6:56 PM, Frederik Ramm wrote: Hi, > > On 03/07/2016 07:54 AM, Mateusz Konieczny wrote: Just imagine what would > happen if > someone took it upon them to actually list all the products sold at a > supermarket. And update that once a week. I see no problem with that except > that anybody would quickly give up and > overall waste time. It is possible that some supermarkets would make their list of products available electronically and thus provide an incentive for a clever hacker to simply convert that to OSM. Once we say we accept a list of products for a supermarket, few would make the distinction of "surveyed list = ok, imported list = not ok"... Such an automatic import would practically be the only way to keep a list of products current. > But I see no significant negative effects extending to other people > (shop element would be hard to edit for some time until somebody would > remove outdated data would be the largest problem what is not really > significant). A typical grocery store would carry about 30.000 different products. Even assuming it would be possible to encode each in a 15-character string, the "sells" tag would half a megabyte long - for each store. And update once a week. If this were done for many stores, the impact on the size of the planet file, the daily diffs, or even the small download you make to edit an area, would be noticeable. That is a good point. How to do both? Have the detail without too much change/bandwidth? Guide the use of the 'sells' tag that it should be used for items that are available and predicted to be available for the next year? That may reduce frequent updates? There could be default values that could cover the basics ... like pub sells beer? _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging