Re: [Tagging] Feature Proposal – RFC – place=peninsula

[Michael Patrick]

> Is there an upper cut-off where things stop being a peninsula?

Hmmm ... not really. And it doesn't have to be the same body of water
either - the Upper and Lower Peninsula of Michigan State are isolated by
the collective waters of the Great Lakes. The Iberian Peninsula in Europe,
the Korean Peninsula, Florida, are also quite large. Not to get to fractal,
but peninsula can have peninsula. The 'base' which connects also is quite
varied, sometimes a river, a piedmont, or the ridge line of a major
drainage.

Local here, we have Camano Island, which is really a peninsula. IMHO,
anyways

Michael
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Dave Swarthout]

"top up" is commonly used in Thailand for adding money to a cell phone
balance. My bank's website, Kasikorn Bank, uses that exact term and offers
a way to "top up" your phone online.

On Thu, Dec 27, 2018 at 7:54 AM Tom Pfeifer  wrote:

> On 26.12.2018 19:05, bkil wrote:
> > Please don't confuse top ups with refilling:
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink
>
> No I don't confuse it. The refilling proposal is about refills without
> additional charge.
> To top-up a drink is purchasing a new one without wasting another clean
> glass.
>
> > I think "top up" is standard terminology in the UK for increasing the
> balance of prepaid mobile
> > phone accounts.
>
> By which standard? I think it is marketing slang, as it makes no sense
> semantically.
>
> > top_up:credit_card:‹brand›=yes;no
>
> As said, if the amount is pre-paid, it is not a credit card. It might be a
> debit card because you
> have to have the money in advance.
>
> tom
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

[Stefan Keller]

bkil,

On We, 26. Dez. 2018 at 20:05 bkil  wrote in
thread "[Tagging] Feature Proposal - RFC - Top up":
> Stefan, I think most of us here do not fully understand your hard arguments, 
> but if you could please elaborate a bit more or give some more examples, 
> maybe we could better address your concerns.
> Anyway, this question sounds a bit orthogonal to the proposal at hand. Could 
> anyone please link to a previous discussion with arguments in this topic? I'm 
> absolutely sure

Thanks for asking. I'm opening a new thread here.

I'm also sure and I know that somebody took the time to write up a
matrix of pro's and con's of the options, but can't remember for now.

> Getting back to the proposal at hand, how would you map this place?
>
> top_up:phone:Vodafone=yes
> top_up:phone:Telekom=yes
> top_up:phone:Telenor=yes
> top_up:phone:Blue_mobile=no
> top_up:transport=yes
>
> Which one would cut it instead in your opinion?
> top_up:phone=Vodafone;Telekom;Telenor
> top_up:transport=yes

I can't follow what "transport" means here, but yes: the latter would
be one alternative.

This misuse of prefixes is called "over-namespacing" [1]. Read the
fifth sentence in the intro [1] and let me summarize the troubles of
over-namespacing:

1. it is bad to tag/key reuse and
2. it disseminates the data scheme.

Given the bad example of "service:bicycle:*" the value "retail" in
"service:bicycle:retail=yes" may be potentially used also in other
shops.

A proper scheme would be "service=*" (or at least
"bicycle_service=*"), having key "service" and values
"retail,repair,second_hand;...". I know that semicolons are not easy
to process, but:

Putting values in keys in the form "subkey:value1=yes/no;
subkey:value2=yes/no" instead of "subkey=value1;value2" is worse: it's
detrimental to any data management from capturing to analysis.

So, I tend to call this "prefix-fooling".

It's really turning processing of key-values (or key-value pairs KVP,
entity-attribute-values EAV, dictionnaries, associative arrays, map
collections, Hash stores/hstores) ad absurdum. In addition to the
troubles of over-namespacing mentioned above there are following
consequences of prefix-fooling - among others (sticking at the example
"service:bicycle:retail=yes;service:bicycle:repair=yes;"):

* Existing code to validate and cleanup values is in vain: One can't
check with usual functions if a value is in range
"retail,repair,second_hand".
* Existing code to match is in vain too: Prefix-fooled keys pretend to
have mixed cases (which they should'nt).
* Worse, users still extend "yes/no" values to arbitrary values (which
again makes processing unnecessarily complicated).
* Even worse, users are encouraged to invent new sparsely used keys
(which we can't prevent, but it's less harmful in the values).
* Source code is flooded by boolean expressions (which would else be a
single function) and need to be predefined in the code (instead of
being put in values).
* Values in namespaces/prefixes/suffixes are hard or impossible to
search, match, count or group in computer languages, including SQL.

This list is incomplete but let me exemplify the points above in
specific example [2] where's currently p.ex.
"service:bicycle:Mobiler_Servive=yes": Here someone at least has
written "yes" correctly, but he 1. used a mix of upper case and "_",
2. typed "Servive" wrongly and 3. invented some german key (which
would be OK to me if the user would have invented "service=Mobile").

As a consequence OSM Wiki tends to be flooded by Wiki-Key pages (one
"service:bicycle:retail", one for "service:bicycle:second_hand",
etc.), one can't search for partial key names (like "service") in
Wiki, Editor Presets [3] or Overpass (regex "*service*" is an error in
Overpass), etc...

To conclude: I consider values in namespaces/prefixes/suffixes harmful
and I hope this thread helps to avoid and correct over-namespacing and
prefix-fooling.

:Stefan

[1] https://wiki.openstreetmap.org/wiki/Namespace
[2] https://www.openstreetmap.org/node/4672943370
[3] 
https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/

Am Mi., 26. Dez. 2018 um 20:05 Uhr schrieb bkil :
>
> Stefan, I think most of us here do not fully understand your hard arguments, 
> but if you could please elaborate a bit more or give some more examples, 
> maybe we could better address your concerns. Anyway, this question sounds a 
> bit orthogonal to the proposal at hand. Could anyone please link to a 
> previous discussion with arguments in this topic? I'm absolutely sure that it 
> comes up annually around here, but I'm newbie here, so I can't tell from the 
> top of my head.
>
> On our local list, this argument usually comes up in the other way around: I 
> usually want to endorse a way to use as much semicolons as possible to ease 
> the work of mappers, while everyone else lists counter arguments that boolean 
> alternatives are the upcoming norm.
>
> The socket key grew up from power_supply, 

Re: [Tagging] Feature Proposal - RFC - Top up

[Tom Pfeifer]

On 26.12.2018 19:05, bkil wrote:

Please don't confuse top ups with refilling:
https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink


No I don't confuse it. The refilling proposal is about refills without 
additional charge.
To top-up a drink is purchasing a new one without wasting another clean glass.

I think "top up" is standard terminology in the UK for increasing the balance of prepaid mobile 
phone accounts.


By which standard? I think it is marketing slang, as it makes no sense 
semantically.


top_up:credit_card:‹brand›=yes;no


As said, if the amount is pre-paid, it is not a credit card. It might be a debit card because you 
have to have the money in advance.


tom

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal – RFC – place=peninsula

[Graeme Fitzpatrick]

I would also think natural= is a "nicer" approach :-)

Under the list of examples given on the proposal

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:place%3Dpeninsula

I was quite surprised to see India listed as a peninsula?
https://www.openstreetmap.org/node/4869234021#map=4/17.85/78.18

I guess it is, as it's a (big!) lump of land sticking out into the water,
but I have always seen it referred to as the Indian Sub-Continent? Is there
an upper cut-off where things stop being a peninsula?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal – RFC – place=peninsula

[Dave Swarthout]

I would not disagree with the reasoning fur the use of either tag but have
used natural=peninsula extensively in my Alaska mapping so I prefer going
forward with that one.

Dave

On Thu, Dec 27, 2018 at 2:02 AM Markus  wrote:

> On Wed, 26 Dec 2018 at 19:23, Martin Koppenhoefer
>  wrote:
> >
> > Being this about a landform I would tend to prefer the natural key for
> it, although the use of place isn’t defacto limited to man made places
> (particularly locality) either.
>
> A peninsula is a land form, on the other hand, we're also using
> place=* for islands, islets and continents (as well as oceans and
> seas), which are also land forms.
>
> But i were fine with natural=peninsula too. The main thing for me is
> that we can agree on one tag.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Paul Allen]

On Wed, 26 Dec 2018 at 21:48, bkil  wrote:

> Yes, it would be more comfortable to tag the PayPoint service itself in a
> certain way instead of all the individual services.
>
> It is also better maintainable, as when a new provider registers with
> PayPoint, we don't need to amend all previously tagged places with a mass
> import.
>

As I already mentioned, I couldn't find an authoritative, definitive list.
They claim to route payments to
over 300 companies and showed over 30 logos (most of which I could
identify).  I think from a user
perspective, you already know if you can use PayPoint to complete whichever
transaction you have in
mind and so you just need to find a shop with a PayPoint terminal in
whatever location you happen to
be.

In order to properly fill payment:*=*, I once started to gather the kind of
> POS terminals and payment processors in Hungary and the type of cards
> accepted at each place, but the list was not pretty. Basically each shop
> accepts a random subset of 5-10 card issuers depending on the payment
> processor/terminal provider.
>

Sounds about right unless your country has a large payment processor like
PayPoint.  They accept
all major credit/debit/bank cards (I have a vague memory they don't accept
American Express or
Diner's Club).  And, of course, you can pay by cash.

Noting all accepted cards precisely for every shop is exhaustive, so it is
> not being done around here (I myself simply use debit_cards=yes instead).
>

Again, in the UK, we have all our shit in one sock (mostly).  If a shop has
EPOS then it accepts all
major credit/debit/bank cards (American Express and Diner's Club are
exceptions).  Payment processors
in the UK generally accept all major cards.  And so do ATMs.  Our banks
talk to each other.  EPOS is
how the shop accepts payments for its own goods/services, PayPoint is how
it allows customers to
pay others.

It would also carry a high maintenance burden later on. However, if we
> simply mapped the payment processor/terminal provider instead of the
> individual card combinations accepted, it could be done much more
> effectively, but then we needed an external lookup table very similar to
> what you propose, that may be edited on a machine readable wiki page for
> example.
>

Depends on the country, I suppose.  In the UK you know if you have a card
that is usable in any
card reader or if it's only useful in a very limited number of outlets.


> Although I'm not from the UK, I think this is where the term "top up"
> originated from and what the of the world identifies it as:

https://en.wikipedia.org/wiki/Top_up
>

That looks about right, although I expect the term originally derives by
analogy with topping up your
petrol tank.  It's pretty much the same situation with PAYG phones.  Well,
was, because what some
major operators here are now pushing as PAYG isn't.  But it used to be.
You put some "minutes" in your
phone's "tank" and could continue to use it until it went dry.  At any
point you could top it up, even if it
wasn't close to empty.

I think (my memory isn't that good and I wasn't paying much attention at
the time) that PayPoint started
out as a way of topping up mobiles but has now expanded into many other
sorts of payments.  But it's
still where you go for top-ups.  In much the same way, we still talk about
dialling somebody's phone
number even though very few of us have a phone with a rotary dial.

So if you see a potential for confusion with the future use of the term
> "top up", please help us come up with a better one that can still be
> understood and translated internationally.
>

PayPoint, at least, covers all types of payment.  Prepayment for phones,
electricity keys, TV licence.
Regular payments.  Bill payments.  Payment by arrangement if you can't pay
your full gas bill in one
go.  Etc.  In other countries it may well be different, although in the
future they may find similar
payment systems appear (because there's a demand for them).

I can't think of a good term to cover it, except how PayPoint describe what
they offer: payment
services.  I'm not particularly happy with that, but it describes what they
do better than "top ups."

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[bkil]

Yes, it would be more comfortable to tag the PayPoint service itself in a
certain way instead of all the individual services.

It is also better maintainable, as when a new provider registers with
PayPoint, we don't need to amend all previously tagged places with a mass
import.

>From a perspective of policy, I guess we may allow such shorthand for
specific exceptional cases when end users can easily identify the brand and
what it implicates. Keep in mind that machine processing will suffer unless
we store such mapping on the wiki.

In order to properly fill payment:*=*, I once started to gather the kind of
POS terminals and payment processors in Hungary and the type of cards
accepted at each place, but the list was not pretty. Basically each shop
accepts a random subset of 5-10 card issuers depending on the payment
processor/terminal provider. Noting all accepted cards precisely for every
shop is exhaustive, so it is not being done around here (I myself simply
use debit_cards=yes instead). It would also carry a high maintenance burden
later on. However, if we simply mapped the payment processor/terminal
provider instead of the individual card combinations accepted, it could be
done much more effectively, but then we needed an external lookup table
very similar to what you propose, that may be edited on a machine readable
wiki page for example. I find that this very same issue pops up pretty
often when we are trying to extend and redesign OSM related data models and
processes, so it would be nice to arrive at a universal solution for this.

Here are some examples at the end of this thread if you are interested:
https://groups.google.com/forum/#!topic/openstreetmap-hungary/0ufRoNmw25U

Although I'm not from the UK, I think this is where the term "top up"
originated from and what the of the world identifies it as:
https://en.wikipedia.org/wiki/Top_up

However, I can see where you are coming from:
https://en.wiktionary.org/wiki/top-up#Noun
https://en.wiktionary.org/wiki/top_up#Verb

In Hungary, it doesn't make sense to say "topping up" (roughly translated
as "filling up your balance") your bills - we always use the word "pay" or
"settle" (the latter roughly translated as equilibrate) in context of debts
and invoices. Although the words for refilling coffee (the waiter roughly
asks whether they can pour/fill some more coffee for you) and topping up
balance (you roughly say that you are "charging" some balance or money on
the card similar to charging or filling up a battery completely) are pretty
close indeed.

So if you see a potential for confusion with the future use of the term
"top up", please help us come up with a better one that can still be
understood and translated internationally.

On Wed, Dec 26, 2018 at 9:18 PM Paul Allen  wrote:

> On Wed, 26 Dec 2018 at 18:07, bkil wrote:
>
>> Please don't confuse top ups with refilling:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink
>>
>> I think "top up" is standard terminology in the UK for increasing the
>> balance of prepaid mobile phone accounts.
>>
>
> That, amongst other things.  Even when, strictly speaking, they're
> payments rather than top-ups.
> Because language mutates that way, and what started out as being purely
> for topping things up
> ended up also handling bill payments.
>
> Since you mentioned the UK, then just to complicate matters...
>
> A large number of outlets offer the services of PayPoint.  With this
> system I can top up my phone
> account with the UK's four main mobile network operators (and possibly
> some of the virtual operators),
> pay some or part of my gas bill, top up my electricity meter key, pay some
> or part of my water bill, pay
> some or part of my TV licence (those outside the UK may have no idea what
> that is or why we have one)
> and pay many other different things.
>
> I'd like to be able to point you at a list of everything that can be
> paid/topped up using PayPoint.  I really
> would.  Because, if I saw the list I might spot some other thing it would
> be preferable[1] for me to pay
> that way.  But PayPoint's website appears not to have such a list.  I
> might be able to find such a list
> from the sitemap, but that is broken.  So all I can do is give you this
> link and you can play
> "guess the logo" for the 30+ logos of the claimed 300+ companies that can
> be paid this way:
> https://corporate.paypoint.com/our-proposition/whatwedo
>
> There's a hell of a lot of things that can be paid/topped up that way.  I
> suspect it might be better (at least
> in the UK) to tag it topup:payment_network=paypoint or some such rather
> than have 300+
> topup:phone:ee=yes + topup:electricy:sse=yes + topup:water:dwr_cymru=yes +
> topup:gas:eon=yes + topup:tv_licence=yes +...
>
> [1]Why would I ever find it preferable to pay anything (other than top up
> my electricity meter key) this
> way?  My bank has a scheme to encourage people to use online banking,
> whereby certain businesses

Re: [Tagging] Feature Proposal - RFC - Top up

[Philip Barnes]

I don't use these systems but would agree with Paul on this, there will be 
hundreds of things that can be paid at these terminals. 

Beyond what has so far been mentioned you can pay road tolls or buy tickets for 
my local bus and probably many other local bus companies. Although I can 
imagine some confusion if I was in London asking for a bus ticket between Wem 
and Shrewsbury even though the machine will be exactly the same as the one in 
my local shop.

Phil (trigpoint) 

On 26 December 2018 20:16:46 GMT, Paul Allen  wrote:
>On Wed, 26 Dec 2018 at 18:07, bkil  wrote:
>
>> Please don't confuse top ups with refilling:
>>
>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink
>>
>> I think "top up" is standard terminology in the UK for increasing the
>> balance of prepaid mobile phone accounts.
>>
>
>That, amongst other things.  Even when, strictly speaking, they're
>payments
>rather than top-ups.
>Because language mutates that way, and what started out as being purely
>for
>topping things up
>ended up also handling bill payments.
>
>Since you mentioned the UK, then just to complicate matters...
>
>A large number of outlets offer the services of PayPoint.  With this
>system
>I can top up my phone
>account with the UK's four main mobile network operators (and possibly
>some
>of the virtual operators),
>pay some or part of my gas bill, top up my electricity meter key, pay
>some
>or part of my water bill, pay
>some or part of my TV licence (those outside the UK may have no idea
>what
>that is or why we have one)
>and pay many other different things.
>
>I'd like to be able to point you at a list of everything that can be
>paid/topped up using PayPoint.  I really
>would.  Because, if I saw the list I might spot some other thing it
>would
>be preferable[1] for me to pay
>that way.  But PayPoint's website appears not to have such a list.  I
>might
>be able to find such a list
>from the sitemap, but that is broken.  So all I can do is give you this
>link and you can play
>"guess the logo" for the 30+ logos of the claimed 300+ companies that
>can
>be paid this way:
>https://corporate.paypoint.com/our-proposition/whatwedo
>
>There's a hell of a lot of things that can be paid/topped up that way. 
>I
>suspect it might be better (at least
>in the UK) to tag it topup:payment_network=paypoint or some such rather
>than have 300+
>topup:phone:ee=yes + topup:electricy:sse=yes +
>topup:water:dwr_cymru=yes +
>topup:gas:eon=yes + topup:tv_licence=yes +...
>
>[1]Why would I ever find it preferable to pay anything (other than top
>up
>my electricity meter key) this
>way?  My bank has a scheme to encourage people to use online banking,
>whereby certain businesses
>offer discounts (if you use online banking to select a particular
>discount
>currently on offer).  One of the
>shops near me with a PayPoint terminal is part of a franchise that
>offers
>me a 5% discount every 3 or
>4 months.  It's supposed to entice me to buy their big-brand-only,
>sold-at
>higher-than-anybody-else's
>prices merchandise.  I use it purely for PayPoint purchases where the
>price
>is exactly the same as I'd
>pay anywhere else.  I even get 5% off cashback under that discount
>scheme!
>
>-- 
>Paul

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Paul Allen]

On Wed, 26 Dec 2018 at 18:07, bkil  wrote:

> Please don't confuse top ups with refilling:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink
>
> I think "top up" is standard terminology in the UK for increasing the
> balance of prepaid mobile phone accounts.
>

That, amongst other things.  Even when, strictly speaking, they're payments
rather than top-ups.
Because language mutates that way, and what started out as being purely for
topping things up
ended up also handling bill payments.

Since you mentioned the UK, then just to complicate matters...

A large number of outlets offer the services of PayPoint.  With this system
I can top up my phone
account with the UK's four main mobile network operators (and possibly some
of the virtual operators),
pay some or part of my gas bill, top up my electricity meter key, pay some
or part of my water bill, pay
some or part of my TV licence (those outside the UK may have no idea what
that is or why we have one)
and pay many other different things.

I'd like to be able to point you at a list of everything that can be
paid/topped up using PayPoint.  I really
would.  Because, if I saw the list I might spot some other thing it would
be preferable[1] for me to pay
that way.  But PayPoint's website appears not to have such a list.  I might
be able to find such a list
from the sitemap, but that is broken.  So all I can do is give you this
link and you can play
"guess the logo" for the 30+ logos of the claimed 300+ companies that can
be paid this way:
https://corporate.paypoint.com/our-proposition/whatwedo

There's a hell of a lot of things that can be paid/topped up that way.  I
suspect it might be better (at least
in the UK) to tag it topup:payment_network=paypoint or some such rather
than have 300+
topup:phone:ee=yes + topup:electricy:sse=yes + topup:water:dwr_cymru=yes +
topup:gas:eon=yes + topup:tv_licence=yes +...

[1]Why would I ever find it preferable to pay anything (other than top up
my electricity meter key) this
way?  My bank has a scheme to encourage people to use online banking,
whereby certain businesses
offer discounts (if you use online banking to select a particular discount
currently on offer).  One of the
shops near me with a PayPoint terminal is part of a franchise that offers
me a 5% discount every 3 or
4 months.  It's supposed to entice me to buy their big-brand-only, sold-at
higher-than-anybody-else's
prices merchandise.  I use it purely for PayPoint purchases where the price
is exactly the same as I'd
pay anywhere else.  I even get 5% off cashback under that discount scheme!

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[bkil]

Stefan, I think most of us here do not fully understand your hard
arguments, but if you could please elaborate a bit more or give some more
examples, maybe we could better address your concerns. Anyway, this
question sounds a bit orthogonal to the proposal at hand. Could anyone
please link to a previous discussion with arguments in this topic? I'm
absolutely sure that it comes up annually around here, but I'm newbie here,
so I can't tell from the top of my head.

On our local list, this argument usually comes up in the other way around:
I usually want to endorse a way to use as much semicolons as possible to
ease the work of mappers, while everyone else lists counter arguments that
boolean alternatives are the upcoming norm.

The socket key grew up from power_supply, check how they use that in
taginfo. Consider the following example:
socket:cee_17_blue=2
socket:cee_7_3=yes

It indicates that we have 2 sockets of the first, and they also have some
of the second kind, but we don't know how many. Perhaps it came from an
import, from memory, or there was simply not enough time to count them all.
How else would you tag this?

Getting back to the proposal at hand, how would you map this place?

top_up:phone:Vodafone=yes
top_up:phone:Telekom=yes
top_up:phone:Telenor=yes
top_up:phone:Blue_mobile=no
top_up:transport=yes

Which one would cut it instead in your opinion?
top_up:phone=Vodafone;Telekom;Telenor
top_up:transport=yes

Or this one:
top_up=phone:Vodafone;phone:Telekom;phone:Telenor;transport

Or try to translate this example:
top_up:phone=yes
top_up:transport=yes

Would it correspond to this?
top_up=phone:transport

Given proper presets & UI, a mapper simply ticks some boxes and be done
with it - no typing needed. And anyway, I use the contact:* schema
extensively and I do not feel that to slow me down - it's just a matter of
learning to touch type or using proper autocompletion.

>From a performance perspective, if one has a Telenor card and wants to top
up, geolocating a place is as simple as looking up top_up:phone:Telenor=yes
in the granular case using a DB index/map (key-value based bigdata storage
also shines here). If we crammed everything into the same top_up or
top_up:phone field, we would need regexp lookups that are much less
efficient. Although, if this was the only drawback, we would have the
option to build an intermediate shadow database from the master OSM just
for the purpose of efficient lookups (basically normalizing to the same
form as seen above).

Actually the best solution would be to combine the advantages of both. It
would not be really difficult to come up with an editor in which you could
enter top_up:phone=Telenor,Vodafone,Telekom and it would automatically
expand to the above form on pressing enter (including the missing entries
defaulting to *=no!). Namespacing has the added benefit of sorting the keys
alphabetically putting them nearby (the same advantage for contact:*=*),
although an interface could choose to compress these as they wish.

Full disclosure: up to now, I was happy to use semicolons in cuisine=*, as
I don't expect people to do lookups for these and there's sometimes a dozen
of them, but this does cause sleepless night. Fortunately, editors support
checkboxes for this field in this scheme.

On Wed, Dec 26, 2018 at 6:03 PM Stefan Keller  wrote:

> Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
> :
> > For practical reason, I would expect a scheme
> > characteristic_I_need_to_know=yes/no
> >
> > much easier to evaluate than one like:
> > some_services=foo;characteristic_I_need_to_know;bar
>
> No it's not easier. The following
> some_services_foo=yes/no
> some_services_characteristic_I_need_to_know=yes/no
> some_services_bar=yes/no
>
> is three times more to read and write for humans, as compared to
> some_services=foo;characteristic_I_need_to_know;bar
>
> and - again:
>
> The form "detail:value:sub_value(:...)=?"
> (1.) breaks fundamental(!) assumptions in OSM (assuming tags as a key
> and value(s)).
> And (2) it breaks programming principles (requiring a attribute-name
> having value(s)).
>
> So it's obvious why the Wiki and taginfo and you name it can't cope
> with it. I'm sorry, but it's hard to be more clear and explicit than
> that.
>
> And I hope for OSM that it's not becoming common - even given there
> are other bad examples like recycling or service:bicycle [1].
>
> :Stefan
>
> P.S. Note that it's the fact that there are alternatives especially to
> the boolean yes/no/unkown case and that tagging schemes like "socket"
> [2] is acceptable since it's still about a value in the key=value
> pair.
>
> [1] https://taginfo.openstreetmap.org/search?q=service%3Abicycle
> [2] https://wiki.openstreetmap.org/wiki/Key:socket
>
> Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
> :
> >
> >
> >
> > sent from a phone
> >
> > > On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
> > >
> > > Tag-proposals in the form
> > > :[:]=yes/no should be
> > 

Re: [Tagging] Feature Proposal – RFC – place=peninsula

[Markus]

On Wed, 26 Dec 2018 at 19:23, Martin Koppenhoefer
 wrote:
>
> Being this about a landform I would tend to prefer the natural key for it, 
> although the use of place isn’t defacto limited to man made places 
> (particularly locality) either.

A peninsula is a land form, on the other hand, we're also using
place=* for islands, islets and continents (as well as oceans and
seas), which are also land forms.

But i were fine with natural=peninsula too. The main thing for me is
that we can agree on one tag.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal – RFC – place=peninsula

[Martin Koppenhoefer]

sent from a phone

> On 26. Dec 2018, at 17:39, Markus  wrote:
> 
> I'm proposing the tag place=peninsula for mapping named peninsulas.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:place%3Dpeninsula


While the tag natural=peninsula was rejected by voting in 2008, it is still 
used as much as place.
https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dpeninsula

Being this about a landform I would tend to prefer the natural key for it, 
although the use of place isn’t defacto limited to man made places 
(particularly locality) either.


Cheers, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[bkil]

Please don't confuse top ups with refilling:
https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink

I think "top up" is standard terminology in the UK for increasing the
balance of prepaid mobile phone accounts.

The author has since updated the wiki page for the proposal, so now it
reads:

top_up:phone=yes;no -> This shop sells telephone recharge vouchers or
over-the-air credit top-up
top_up:transport=yes;no -> This shop sells public transport card top-up
top_up:credit_card=yes;no -> This shop sells credit card top up
top_up:phone:‹brand›=yes;no
top_up:transport:‹brand›=yes;no
top_up:credit_card:‹brand›=yes;no

This is not the same wording as discussed above, but I still like this one.

On Wed, Dec 26, 2018 at 2:11 PM Tom Pfeifer  wrote:

> I find "top_up" alone highly misleading and unspecific.
>
> I encountered the term in filling stations, where you would order either
> "5 gallons" or "top up",
> i.e. to fully fill the tank. Or when pre-paying the fuel, you would either
> pay "fuel for $20", or
> leave your credit card with the cashier to allow "top up".
>
> In the same sense, you could ask the bar keeper to "top up" your cocktail
> glass.
>
> In the context of pre-paying credits for phone or transport, there is no
> such "top", no upper limit,
> you could buy any amount you want. Thus this marketing slang is misleading.
>
> It is unspecific to be used in OSM since it does not indicate which
> service is being paid for.
> Using it on the object tagged with amenity=bar it gets absolutely
> confusing what is getting topped up.
>
> Thus, I'd not use the term "top_up" at all, and as Martin proposed,
> indicate the type of service
> first, e.g.:
> phone_credits=yes
> transport_credits=yes
> cocktail_glasses_topped_up=yes
>
> Even 'credits' seem problematic, since what you pre-pay is not a credit.
> tom
>
>
> On 25.12.2018 21:03, Daniele Santini wrote:> Hi, I propose to introduce
> the top_up=* key to specify
> whether a shop/amenity sells top-ups (mobile
>  > phone credit recharge vouchers,  over-the-air credit top up and/or
> public transport credit recharge
>  > vouchers).
>
> On 26.12.2018 12:33, Martin Koppenhoefer wrote:
> > +1, I was proposing on talk-it a very similar
> > phone_top_up=yes/no
> > phone_top_up:=yes/ no
> >
> > but given that top_up=yes already has some uses (mainly for public
> transport it seems), a more general scheme top_up:phone: could be
> more obvious to data users and more consistent with the current data, so +1
> to this.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Stefan Keller]

Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
:
> For practical reason, I would expect a scheme
> characteristic_I_need_to_know=yes/no
>
> much easier to evaluate than one like:
> some_services=foo;characteristic_I_need_to_know;bar

No it's not easier. The following
some_services_foo=yes/no
some_services_characteristic_I_need_to_know=yes/no
some_services_bar=yes/no

is three times more to read and write for humans, as compared to
some_services=foo;characteristic_I_need_to_know;bar

and - again:

The form "detail:value:sub_value(:...)=?"
(1.) breaks fundamental(!) assumptions in OSM (assuming tags as a key
and value(s)).
And (2) it breaks programming principles (requiring a attribute-name
having value(s)).

So it's obvious why the Wiki and taginfo and you name it can't cope
with it. I'm sorry, but it's hard to be more clear and explicit than
that.

And I hope for OSM that it's not becoming common - even given there
are other bad examples like recycling or service:bicycle [1].

:Stefan

P.S. Note that it's the fact that there are alternatives especially to
the boolean yes/no/unkown case and that tagging schemes like "socket"
[2] is acceptable since it's still about a value in the key=value
pair.

[1] https://taginfo.openstreetmap.org/search?q=service%3Abicycle
[2] https://wiki.openstreetmap.org/wiki/Key:socket

Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
:
>
>
>
> sent from a phone
>
> > On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
> >
> > Tag-proposals in the form
> > :[:]=yes/no should be
> > avoided. It's shifting values to attribute names!
>
>
> it’s not a value, it‘s a property ;-)
> it depends on your interpretation, e.g. motorroad=yes
> oneway=yes
>
> aren’t these values and we should tag them
> road_restrictions=motorroad;oneway?
>
>
> top_up:phone=yes
> means: provides phone top up.
> For practical reason, I would expect a scheme
> characteristic_I_need_to_know=yes/no
>
> much easier to evaluate than one like:
> some_services=foo;characteristic_I_need_to_know;bar
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal – RFC – place=peninsula

[Markus]

Hello,

I'm proposing the tag place=peninsula for mapping named peninsulas.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:place%3Dpeninsula

Regards

Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Martin Koppenhoefer]

sent from a phone

> On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
> 
> Tag-proposals in the form
> :[:]=yes/no should be
> avoided. It's shifting values to attribute names!


it’s not a value, it‘s a property ;-)
it depends on your interpretation, e.g. motorroad=yes 
oneway=yes

aren’t these values and we should tag them 
road_restrictions=motorroad;oneway?


top_up:phone=yes
means: provides phone top up.
For practical reason, I would expect a scheme 
characteristic_I_need_to_know=yes/no

much easier to evaluate than one like:
some_services=foo;characteristic_I_need_to_know;bar


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Markus]

On Wed, 26 Dec 2018 at 15:10, Stefan Keller  wrote:
>
> Tag-proposals in the form
> :[:]=yes/no should be
> avoided. It's shifting values to attribute names!
>
> This detracts processing - given we/OSM already have a non-relational
> key-value schema. Specifically it makes processing with presets and
> any key-value analysis very hard.
>
> And by saying hard I don't mean it's because some programmers may be
> lazy. It's because having a value as part of an attribute-name is
> really a wrong data structure.
>
> [...]
>
> There are so many tagging alternatives - like the usual tag scheme.

Sorry for asking, but what do you understand by 'usual tag scheme'?
The proposed scheme seems to be quite common, e.g. see
recycling:=yes/no. Besides i thought that semicolons should
be avoided, because, among other things, you can't specify that a
feature or service isn't available (e.g. that you can't top up public
transport cards at a specific place).

How would your top_up tagging scheme look like? top_up= +
top_up:=?

Regards
Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Daniele Santini]

(I am resending this mail because the first time I forgot to change the
object from "Digest". Sorry for the double mail!)
So what's your suggestion?
top_up:=? _top_up:=yes/no?
_top_up:brand=?

Il giorno mer 26 dic 2018 alle ore 15:09 
ha scritto:

> Hi,
>
> Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus <
> selfishseaho...@gmail.com>:
> > I don't see a problem that would prevent using the proposed tags
> > top_up:[:]=yes/no for vending machines, ATMs, convenience
>
> Tag-proposals in the form
> :[:]=yes/no should be
> avoided. It's shifting values to attribute names!
>
> This detracts processing - given we/OSM already have a non-relational
> key-value schema. Specifically it makes processing with presets and
> any key-value analysis very hard.
>
> And by saying hard I don't mean it's because some programmers may be
> lazy. It's because having a value as part of an attribute-name is
> really a wrong data structure.
>
> In fact, ":[:] = boolean"
> has to be officially considered harmful!
>
> There are so many tagging alternatives - like the usual tag scheme.
>
> :Stefan
>
> [1]
> https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/
>
>
> Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus <
> selfishseaho...@gmail.com>:
> >
> > I don't see a problem that would prevent using the proposed tags
> > top_up:[:]=yes/no for vending machines, ATMs, convenience
> > stores, kiosks etc. too.
> > On Wed, 26 Dec 2018 at 09:59, Warin <61sundow...@gmail.com> wrote:
> > >
> > > There are some vending machines that offer 'top up' ... how are these
> to be tagged? Together with a payment tag too.
> > >
> > > There are some convenience stores that offer 'top up' services .. how
> are these to be tagged?
> > >
> > >
> > > On 26/12/18 19:31, Markus wrote:
> > > > Hi Daniele,
> > > >
> > > >  From the proposal page:
> > > >
> > > >> It's possible to specify which brand/carrier vouchers are sold with
> the key brand=*.
> > > >>
> > > >> A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes
> + brand=vodafone
> > > > The brand=* key specifies the brand of the main tag, here
> amenity=bar.
> > > > In your example, this would mean that it's a Vodafone bar.
> > > >
> > > > Furthermore, top_up=yes doesn't say whether you can top up mobile
> > > > phones, public transport cards or something else, for example prepaid
> > > > credit cards.
> > > >
> > > > Therefore i would suggest someting like:
> > > >
> > > > top_up:mobile_phone=yes/no
> > > > top_up:mobile_phone:vodafone=yes/no
> > > > top_up:mobile_phone:lycamobile=yes/no
> > > >
> > > > top_up:public_transport=yes/no
> > > > top_up:public_transport:oyster=yes/no
> > > > top_up:public_transport:opal=yes/no
> > > >
> > > > top_up:credit_card=yes/no
> > > > top_up:credit_card:ok=yes/no
> > > >
> > > > Regards
> > > > Markus
> > > >
> > > > On Wed, 26 Dec 2018 at 02:45, Daniele Santini 
> wrote:
> > > >> Link of the proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> > > >> Hi, I propose to introduce the top_up=* key to specify whether a
> shop/amenity sells top-ups (mobile phone credit recharge vouchers,
> over-the-air credit top up and/or public transport credit recharge
> vouchers).
> > > >> Kind regards
> > > >> --
> > > >> Daniele Santini
> > > >> http://www.dsantini.it
>

-- 
Daniele Santini
http://www.dsantini.it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Stefan Keller]

Hi,

Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus :
> I don't see a problem that would prevent using the proposed tags
> top_up:[:]=yes/no for vending machines, ATMs, convenience

Tag-proposals in the form
:[:]=yes/no should be
avoided. It's shifting values to attribute names!

This detracts processing - given we/OSM already have a non-relational
key-value schema. Specifically it makes processing with presets and
any key-value analysis very hard.

And by saying hard I don't mean it's because some programmers may be
lazy. It's because having a value as part of an attribute-name is
really a wrong data structure.

In fact, ":[:] = boolean"
has to be officially considered harmful!

There are so many tagging alternatives - like the usual tag scheme.

:Stefan

[1] 
https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/


Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus :
>
> I don't see a problem that would prevent using the proposed tags
> top_up:[:]=yes/no for vending machines, ATMs, convenience
> stores, kiosks etc. too.
> On Wed, 26 Dec 2018 at 09:59, Warin <61sundow...@gmail.com> wrote:
> >
> > There are some vending machines that offer 'top up' ... how are these to be 
> > tagged? Together with a payment tag too.
> >
> > There are some convenience stores that offer 'top up' services .. how are 
> > these to be tagged?
> >
> >
> > On 26/12/18 19:31, Markus wrote:
> > > Hi Daniele,
> > >
> > >  From the proposal page:
> > >
> > >> It's possible to specify which brand/carrier vouchers are sold with the 
> > >> key brand=*.
> > >>
> > >> A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes + 
> > >> brand=vodafone
> > > The brand=* key specifies the brand of the main tag, here amenity=bar.
> > > In your example, this would mean that it's a Vodafone bar.
> > >
> > > Furthermore, top_up=yes doesn't say whether you can top up mobile
> > > phones, public transport cards or something else, for example prepaid
> > > credit cards.
> > >
> > > Therefore i would suggest someting like:
> > >
> > > top_up:mobile_phone=yes/no
> > > top_up:mobile_phone:vodafone=yes/no
> > > top_up:mobile_phone:lycamobile=yes/no
> > >
> > > top_up:public_transport=yes/no
> > > top_up:public_transport:oyster=yes/no
> > > top_up:public_transport:opal=yes/no
> > >
> > > top_up:credit_card=yes/no
> > > top_up:credit_card:ok=yes/no
> > >
> > > Regards
> > > Markus
> > >
> > > On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:
> > >> Link of the proposal: 
> > >> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> > >> Hi, I propose to introduce the top_up=* key to specify whether a 
> > >> shop/amenity sells top-ups (mobile phone credit recharge vouchers,  
> > >> over-the-air credit top up and/or public transport credit recharge 
> > >> vouchers).
> > >> Kind regards
> > >> --
> > >> Daniele Santini
> > >> http://www.dsantini.it
> > >> ___
> > >> Tagging mailing list
> > >> Tagging@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/tagging
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Tom Pfeifer]

I find "top_up" alone highly misleading and unspecific.

I encountered the term in filling stations, where you would order either "5 gallons" or "top up", 
i.e. to fully fill the tank. Or when pre-paying the fuel, you would either pay "fuel for $20", or 
leave your credit card with the cashier to allow "top up".


In the same sense, you could ask the bar keeper to "top up" your cocktail glass.

In the context of pre-paying credits for phone or transport, there is no such "top", no upper limit, 
you could buy any amount you want. Thus this marketing slang is misleading.


It is unspecific to be used in OSM since it does not indicate which service is 
being paid for.
Using it on the object tagged with amenity=bar it gets absolutely confusing 
what is getting topped up.

Thus, I'd not use the term "top_up" at all, and as Martin proposed, indicate the type of service 
first, e.g.:

phone_credits=yes
transport_credits=yes
cocktail_glasses_topped_up=yes

Even 'credits' seem problematic, since what you pre-pay is not a credit.
tom


On 25.12.2018 21:03, Daniele Santini wrote:> Hi, I propose to introduce the top_up=* key to specify 
whether a shop/amenity sells top-ups (mobile

> phone credit recharge vouchers,  over-the-air credit top up and/or public 
transport credit recharge
> vouchers).

On 26.12.2018 12:33, Martin Koppenhoefer wrote:

+1, I was proposing on talk-it a very similar
phone_top_up=yes/no
phone_top_up:=yes/ no

but given that top_up=yes already has some uses (mainly for public transport it 
seems), a more general scheme top_up:phone: could be more obvious to 
data users and more consistent with the current data, so +1 to this.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Daniele Santini]

This seems right. I updated the proposal page, check it out:
https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up

Il giorno mer 26 dic 2018 alle ore 12:42 
ha scritto:

> Hi Daniele,
>
> >From the proposal page:
>
> > It's possible to specify which brand/carrier vouchers are sold with the
> key brand=*.
> >
> > A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes +
> brand=vodafone
>
> The brand=* key specifies the brand of the main tag, here amenity=bar.
> In your example, this would mean that it's a Vodafone bar.
>
> Furthermore, top_up=yes doesn't say whether you can top up mobile
> phones, public transport cards or something else, for example prepaid
> credit cards.
>
> Therefore i would suggest someting like:
>
> top_up:mobile_phone=yes/no
> top_up:mobile_phone:vodafone=yes/no
> top_up:mobile_phone:lycamobile=yes/no
>
> top_up:public_transport=yes/no
> top_up:public_transport:oyster=yes/no
> top_up:public_transport:opal=yes/no
>
> top_up:credit_card=yes/no
> top_up:credit_card:ok=yes/no
>
> Regards
> Markus
>
> On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:
> >
> > Link of the proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> > Hi, I propose to introduce the top_up=* key to specify whether a
> shop/amenity sells top-ups (mobile phone credit recharge vouchers,
> over-the-air credit top up and/or public transport credit recharge
> vouchers).
> > Kind regards
> > --
> > Daniele Santini
> > http://www.dsantini.it
>
>
-- 
Daniele Santini
http://www.dsantini.it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Glamping

[bkil]

There are a few sites around here that come to mind, although we generally
view them to be a kind of camping site.

http://www.opusztaszerimenes.hu/en/jurtaszallas-en/
http://www.dobogokojurta.hu/en
http://gyulatermalkemping.hu/en/
http://www.alpokaljamotel.hu/hu/kemping/

Some also try to sell them as "motels", because parking outside in the
woods is easy and they are very inexpensive. Although I think those who are
pushing it are overdoing it.

I may not be grasping the exact concept of glamping and the borderline
between glamping and camping, as this term is not widely known in Hungary.
Most of the non-free, commercial, but basic camping sites around here
provide all those amenities listed in Wikipedia, including electricity,
Wi-Fi, drinking water, bathing, kitchen, washing machines, warden service
and in many cases flush toilets too, otherwise people would not be willing
to pay for them.

Many such camping sites also offer a few guest_house/motel-style rooms in
wooden or brick structures greatly enhanced compared to simple cabins, and
even a restaurant or pub. I usually add a separate POI per function in such
cases following best practice.

What is the criteria for determining when to use cabins=* instead of adding
a separate motel/guest_house POI, what is the definition of a cabin?
https://en.wikipedia.org/wiki/Log_cabin
https://en.wikipedia.org/wiki/Cottage
https://en.wikipedia.org/wiki/Chalet

On Fri, Dec 21, 2018 at 12:18 PM Volker Schmidt  wrote:

> I think I could tag "my" glamping place as amenity=camp_site by extending
> the tags for camp site
> 
> I notice that it has tagging for static caravans and cabins, but not for
> static tents, which is a frequent feature anyway at many camp sites (e.g.
> in the UK). It is also lacking the possibility to give the capacity for
> these categories in numbers, it only shows yes/no as options.
> The luxury of the place can be tagged with camp_site=deluxe
>
> So we would have something like
> amenity=camp_site
> camp_site=deluxe
> static_tents=4
> beds=xx
> tents=no
> caravans=no
> static_caravans=no
> cabins=no
>
> One could use also
> camp_site:type=glamping
>
>
> Volker
>
>
>
>
>
>
>
> On 21 Dec 2018 10:36 am, "Martin Koppenhoefer" 
> wrote:
>
> Am Fr., 21. Dez. 2018 um 01:29 Uhr schrieb Nelson A. de Oliveira <
> nao...@gmail.com>:
>
>> Maybe stars https://wiki.openstreetmap.org/wiki/Key:stars#Camp_sites
>> could be used to distinguish the different camping sites classes?
>
>
>
>
> the stars we are using for hotels are not arbitrarily chosen by us, but
> (at least in Europe) are those assigned by the hotelstars association.
> If we were to use such generic classes for camp sites they will have to be
> verifiable. I'd prefer describing what distinguishes the places, rather
> than summing it up in a 1-5 category.
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[bkil]

I support the scheme outline by Markus, please update your proposal. I've
already proposed the exactly same scheme on our local mailing list some
time ago, so it is very intuitive:

top_up:[:]=yes/no

On Wed, Dec 26, 2018 at 12:35 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 26. Dec 2018, at 10:11, Markus  wrote:
> >
> > I don't see a problem that would prevent using the proposed tags
> > top_up:[:]=yes/no for vending machines, ATMs, convenience
> > stores, kiosks etc. too.
>
>
> +1, I was proposing on talk-it a very similar
> phone_top_up=yes/no
> phone_top_up:=yes/ no
>
> but given that top_up=yes already has some uses (mainly for public
> transport it seems), a more general scheme top_up:phone: could be
> more obvious to data users and more consistent with the current data, so +1
> to this.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Martin Koppenhoefer]

sent from a phone

> On 26. Dec 2018, at 10:11, Markus  wrote:
> 
> I don't see a problem that would prevent using the proposed tags
> top_up:[:]=yes/no for vending machines, ATMs, convenience
> stores, kiosks etc. too.


+1, I was proposing on talk-it a very similar 
phone_top_up=yes/no
phone_top_up:=yes/ no

but given that top_up=yes already has some uses (mainly for public transport it 
seems), a more general scheme top_up:phone: could be more obvious to 
data users and more consistent with the current data, so +1 to this.


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Markus]

I don't see a problem that would prevent using the proposed tags
top_up:[:]=yes/no for vending machines, ATMs, convenience
stores, kiosks etc. too.

On Wed, 26 Dec 2018 at 09:59, Warin <61sundow...@gmail.com> wrote:
>
> There are some vending machines that offer 'top up' ... how are these to be 
> tagged? Together with a payment tag too.
>
> There are some convenience stores that offer 'top up' services .. how are 
> these to be tagged?
>
>
> On 26/12/18 19:31, Markus wrote:
> > Hi Daniele,
> >
> >  From the proposal page:
> >
> >> It's possible to specify which brand/carrier vouchers are sold with the 
> >> key brand=*.
> >>
> >> A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes + 
> >> brand=vodafone
> > The brand=* key specifies the brand of the main tag, here amenity=bar.
> > In your example, this would mean that it's a Vodafone bar.
> >
> > Furthermore, top_up=yes doesn't say whether you can top up mobile
> > phones, public transport cards or something else, for example prepaid
> > credit cards.
> >
> > Therefore i would suggest someting like:
> >
> > top_up:mobile_phone=yes/no
> > top_up:mobile_phone:vodafone=yes/no
> > top_up:mobile_phone:lycamobile=yes/no
> >
> > top_up:public_transport=yes/no
> > top_up:public_transport:oyster=yes/no
> > top_up:public_transport:opal=yes/no
> >
> > top_up:credit_card=yes/no
> > top_up:credit_card:ok=yes/no
> >
> > Regards
> > Markus
> >
> > On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:
> >> Link of the proposal: 
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> >> Hi, I propose to introduce the top_up=* key to specify whether a 
> >> shop/amenity sells top-ups (mobile phone credit recharge vouchers,  
> >> over-the-air credit top up and/or public transport credit recharge 
> >> vouchers).
> >> Kind regards
> >> --
> >> Daniele Santini
> >> http://www.dsantini.it
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Warin]

There are some vending machines that offer 'top up' ... how are these to be 
tagged? Together with a payment tag too.

There are some convenience stores that offer 'top up' services .. how are these 
to be tagged?


On 26/12/18 19:31, Markus wrote:

Hi Daniele,

 From the proposal page:


It's possible to specify which brand/carrier vouchers are sold with the key 
brand=*.

A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes + 
brand=vodafone

The brand=* key specifies the brand of the main tag, here amenity=bar.
In your example, this would mean that it's a Vodafone bar.

Furthermore, top_up=yes doesn't say whether you can top up mobile
phones, public transport cards or something else, for example prepaid
credit cards.

Therefore i would suggest someting like:

top_up:mobile_phone=yes/no
top_up:mobile_phone:vodafone=yes/no
top_up:mobile_phone:lycamobile=yes/no

top_up:public_transport=yes/no
top_up:public_transport:oyster=yes/no
top_up:public_transport:opal=yes/no

top_up:credit_card=yes/no
top_up:credit_card:ok=yes/no

Regards
Markus

On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:

Link of the proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
Hi, I propose to introduce the top_up=* key to specify whether a shop/amenity 
sells top-ups (mobile phone credit recharge vouchers,  over-the-air credit top 
up and/or public transport credit recharge vouchers).
Kind regards
--
Daniele Santini
http://www.dsantini.it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Top up

[Markus]

Hi Daniele,

From the proposal page:

> It's possible to specify which brand/carrier vouchers are sold with the key 
> brand=*.
>
> A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes + 
> brand=vodafone

The brand=* key specifies the brand of the main tag, here amenity=bar.
In your example, this would mean that it's a Vodafone bar.

Furthermore, top_up=yes doesn't say whether you can top up mobile
phones, public transport cards or something else, for example prepaid
credit cards.

Therefore i would suggest someting like:

top_up:mobile_phone=yes/no
top_up:mobile_phone:vodafone=yes/no
top_up:mobile_phone:lycamobile=yes/no

top_up:public_transport=yes/no
top_up:public_transport:oyster=yes/no
top_up:public_transport:opal=yes/no

top_up:credit_card=yes/no
top_up:credit_card:ok=yes/no

Regards
Markus

On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:
>
> Link of the proposal: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> Hi, I propose to introduce the top_up=* key to specify whether a shop/amenity 
> sells top-ups (mobile phone credit recharge vouchers,  over-the-air credit 
> top up and/or public transport credit recharge vouchers).
> Kind regards
> --
> Daniele Santini
> http://www.dsantini.it
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging