[Tagging] Feature Proposal - RFC - All You Can Eat
fernando.trebien at gmail.com
Mon Feb 17 18:04:51 UTC 2014
I'm not sure I understood everything you said, John, specially about
"interval". Would you update your proposal and send it to us the way
you think it should be?
I suggested "serving system" because that's how Wikipedia describes
it. I think I know English well, but since I'm not a native speaker,
I'd rather suggest something said or written by a native.
I also think that using accents in tags and tag values (except in real
names) creates unnecessary complexity for non-Brazilian developers
(and even for the Brazilians themselves). If "rodizio" is enough, then
stick with simplicity.
I still think that "opening_hours" as a subtag would be an unnecessary
specialization that would only be needed rarely. Can you provide an
example in which you would not be able to represent that information
in a different way? (such as using two or more geometric objects)
On Sat, Feb 15, 2014 at 11:11 PM, John Packer <john.packer7 at gmail.com> wrote:
> I sincerely don't think it's length is a problem. There are longer accepted
> tags(like parking:condition:right:time_interval), and to shorten it would
> make it harder to remember and recognize (i.e. humans would be the ones
> paying the price). Tags like addr:* and ele are okay to abbreviate because
> they are used more frequently, but the others not so much.
> I do think this particular pricing scheme(all_you_can_eat) is useful.
> However I do agree that perhaps it would be better to include other pricing
> The problem is, I have no idea how they are called, or what they are. For
> example, what is this daily menu you speak of?
> Also, one place may have more than one pricing scheme, so I'm not sure the
> additional complexity is worth it.
> I still think all_you_can_eat=yes/no/only is a good idea.
> I understand there is some resistance to all_you_can_eat:opening_hours, but
> I do think it's genuinely useful, as long as it is only used when it is
> meant to be used(it is not a replacement of opening_hours). I gave one
> example of use of all_you_can_eat:opening_hours=* in my previous message.
> Another example is a restaurant that only offers all-you-can-eat options
> during lunch, and not during breakfast or dinner.
> But due to it's complexity(and the small number of cases), perhaps I should
> add a new value called "interval" to all_you_can_eat, which would mean "this
> option is not available at all times". I believe this would be enough to
> "kill" all_you_can_eat:opening_hours.
> I actually was having the same idea of ftrebien: splitting
> all_you_can_eat:type into a new tag. Because to describe the way the food is
> served is one of my main purposes for creating this proposal. I was thinking
> of serving_style, but serving_system is also good.
> (each of the above values links to it's wikipedia article; you can see each
> style's peculiarities)
> It seems there are others, that's why it's important to leave this as an
> open set.
> The main reason I thought of splitting it into a new tag is because serving
> styles like buffet and conveyor belt does not necessarily means
> 2014-02-15 22:13 GMT-02:00 Fernando Trebien <fernando.trebien at gmail.com>:
>> +1 for pricing_scheme, +1 against the :opening_hours subtag
>> What nounours77 proposes is simpler, easier to map, easier to
>> understand and easier to consume in applications.
>> I also suggest another tag:
>> serving_system=buffet/smorgasbord/a_la_carte/table_d_hote (read up
>> that Wikipedia link I've sent previously)
>> In extreme cases (e.g. two services with completely different
>> characteristics - different serving systems, pricing schemes and
>> cuisines - offered at the same time of the day), if you're really
>> picky, the best you can do is replicate the mapping of the same
>> restaurant for each kind of service it offers, each instance with its
>> own tags. (However, the usual recommendation is to choose the
>> "primary" values for each tag.)
>> I think it's absolutely ok to abbreviate all-you-can-eat by ayce, even
>> though this is more common in tag names (such as hgv, psv, addr, hov
>> and ele) than in tag values in OSM. Casual editors (using iD or
>> Potlatch) would rarely use the tag directly (they can easily get a
>> friendly named preset or option box, as they do for many tags today)
>> and advanced users should read the wiki at least once anyway, even for
>> tags that look deceptively obvious when ignoring the OSM context (e.g.
>> highway=track, understood differently in many places mainly due to
>> inexact translation).
>> On Sat, Feb 15, 2014 at 6:40 PM, nounours77
>> <kuessemondtaeglich at gmail.com> wrote:
>> > Hi John,
>> > I do not understand why this is useful.
>> > The suggest tag is too long, to specific.
>> > I do not understand the need for a special all_you_can_eat:opening_hours
>> >> The problem with "cuisine=all_you_can_eat" is that "All you can eat" is
>> >> a pricing scheme,
>> > If you really think the information about the pricing scheme is relevant
>> > (which I don't), why not make a general tag:
>> > Pricing_scheme=all_you_can_eat
>> > Pricing_scheme=daily_menu
>> > greetings,
>> > nounours77
>> > _______________________________________________
>> > Tagging mailing list
>> > Tagging at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>> Fernando Trebien
>> +55 (51) 9962-5409
>> "The speed of computer chips doubles every 18 months." (Moore's law)
>> "The speed of software halves every 18 months." (Gates' law)
>> Tagging mailing list
>> Tagging at openstreetmap.org
> Tagging mailing list
> Tagging at openstreetmap.org
+55 (51) 9962-5409
"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)
More information about the Tagging