Feature Proposal - RFC - Top up

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - RFC - Top up

danysan95
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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Markus-5
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 <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

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

On Wed, 26 Dec 2018 at 09:59, Warin <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://lists.openstreetmap.org/listinfo/tagging
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

dieterdreist


sent from a phone

> On 26. Dec 2018, at 10:11, Markus <[hidden email]> wrote:
>
> I don't see a problem that would prevent using the proposed tags
> top_up:<type>[:<brand>]=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:<brand>=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:<brand> could be more obvious to data users and more consistent with the current data, so +1 to this.


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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:<type>[:<brand>]=yes/no 

On Wed, Dec 26, 2018 at 12:35 PM Martin Koppenhoefer <[hidden email]> wrote:


sent from a phone

> On 26. Dec 2018, at 10:11, Markus <[hidden email]> wrote:
>
> I don't see a problem that would prevent using the proposed tags
> top_up:<type>[:<brand>]=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:<brand>=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:<brand> could be more obvious to data users and more consistent with the current data, so +1 to this.


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

danysan95
In reply to this post by danysan95
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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Tom Pfeifer
In reply to this post by dieterdreist
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:<brand>=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:<brand> could be more obvious to data users and more consistent with the current data, so +1 to this.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Stefan Keller
In reply to this post by Markus-5
Hi,

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

Tag-proposals in the form
<tag_attr_name>:<type_value->[:<subtype_value>]=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, "<tag_attr_name>:<type_value->[:<subtype_value>] = 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 <[hidden email]>:

>
> I don't see a problem that would prevent using the proposed tags
> top_up:<type>[:<brand>]=yes/no for vending machines, ATMs, convenience
> stores, kiosks etc. too.
> On Wed, 26 Dec 2018 at 09:59, Warin <[hidden email]> 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 <[hidden email]> 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
> > >> [hidden email]
> > >> https://lists.openstreetmap.org/listinfo/tagging
> > > _______________________________________________
> > > Tagging mailing list
> > > [hidden email]
> > > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

danysan95
In reply to this post by danysan95
(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:<type>=<brand>? <type>_top_up:<brand>=yes/no? <type>_top_up:brand=<brand>?

Il giorno mer 26 dic 2018 alle ore 15:09 <[hidden email]> ha scritto:
Hi,

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

Tag-proposals in the form
<tag_attr_name>:<type_value->[:<subtype_value>]=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, "<tag_attr_name>:<type_value->[:<subtype_value>] = 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 <[hidden email]>:
>
> I don't see a problem that would prevent using the proposed tags
> top_up:<type>[:<brand>]=yes/no for vending machines, ATMs, convenience
> stores, kiosks etc. too.
> On Wed, 26 Dec 2018 at 09:59, Warin <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Markus-5
In reply to this post by Stefan Keller
On Wed, 26 Dec 2018 at 15:10, Stefan Keller <[hidden email]> wrote:

>
> Tag-proposals in the form
> <tag_attr_name>:<type_value->[:<subtype_value>]=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:<material>=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=<types> +
top_up:<type>=<brands>?

Regards
Markus

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

dieterdreist
In reply to this post by Stefan Keller


sent from a phone

> On 26. Dec 2018, at 15:08, Stefan Keller <[hidden email]> wrote:
>
> Tag-proposals in the form
> <tag_attr_name>:<type_value->[:<subtype_value>]=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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Stefan Keller
Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
<[hidden email]>:
> 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
<[hidden email]>:

>
>
>
> sent from a phone
>
> > On 26. Dec 2018, at 15:08, Stefan Keller <[hidden email]> wrote:
> >
> > Tag-proposals in the form
> > <tag_attr_name>:<type_value->[:<subtype_value>]=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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

bkil
In reply to this post by Tom Pfeifer
Please don't confuse top ups with refilling:

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 <[hidden email]> 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:<brand>=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:<brand> could be more obvious to data users and more consistent with the current data, so +1 to this.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

bkil
In reply to this post by Stefan Keller
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 <[hidden email]> wrote:
Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
<[hidden email]>:
> 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
<[hidden email]>:
>
>
>
> sent from a phone
>
> > On 26. Dec 2018, at 15:08, Stefan Keller <[hidden email]> wrote:
> >
> > Tag-proposals in the form
> > <tag_attr_name>:<type_value->[:<subtype_value>]=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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Paul Allen
In reply to this post by bkil
On Wed, 26 Dec 2018 at 18:07, bkil <bkil.hu+[hidden email]> wrote:
Please don't confuse top ups with refilling:

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:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
On Wed, 26 Dec 2018 at 18:07, bkil <bkil.hu+[hidden email]> wrote:
Please don't confuse top ups with refilling:

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:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

bkil
In reply to this post by Paul Allen
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:

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:

However, I can see where you are coming from:

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 <[hidden email]> wrote:
On Wed, 26 Dec 2018 at 18:07, bkil wrote:
Please don't confuse top ups with refilling:

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:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Paul Allen
On Wed, 26 Dec 2018 at 21:48, bkil <bkil.hu+[hidden email]> 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:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Top up

Tom Pfeifer
In reply to this post by bkil
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234