[Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Paul Allen]

On Wed, Nov 21, 2018 at 4:04 PM marc marc <marc_marc_irc at hotmail.com> wrote:

I already have trouble imagining that there are mobile apps so badly
> made that it asks the user to transcribe the parking ref instead
> of finding it by geolocation
>

Then you have not tried as many badly-designed apps as I have.  None of
them were for parking,
but they were all badly designed.  Anyway, a parking app might offer
alternatives to geolocation for
those with stupid phones rather than smart phones.  And for people who
prefer not to face a parking
fine because bad weather meant they couldn't get a GPS lock.

but for those apps, it seems more convenient to me to use
> payment:<appname>=<the number the app need>
>

That's one possibility.  It is better than ref=12345 and  you have to guess
whether or not that
ref is an SMS payment number, and whether you send an SMS to 12345 or you
send an SMS to
some other number quoting 12345 in the body.

<about a different ref for each payment method>
> > ALL of them might be possible
>
> might ? of course ! but does this situation exist or it's it's purely
> fictional ?
>

All of them might be possible because older technology hangs around.  And
some people don't
adopt new technology.  So it may be possible to pay by SMS because that was
set up years ago
and some people don't have phones capable of anything better.  It may be
possible to pay by app,
but some people may not have the app installed and the signal may be too
weak to install it at that
moment.  It may be possible to pay by NFC, but not everyone has a phone
with that capability.  So
all of those alternatives might be possible at the same car park, along
with machines accepting coins
and debit cards.  Coin payments are likely to go away in the future because
they're a temptation to
break into the vending machines but other payment methods will hang around
a lot longer.

of course we can put several ref:<target1> ref:<target2> on all parking
> of the planet just in case another entity would designate this parking
> lot with another ref... but if the majority of car parks have only one
> reference, their operator's ref, it seems to me to bring no advantage to
> use several ref:*=* over using ref=* without suffix and add suffixes
> only when necessary.
>

I wasn't suggesting tagging every possible option in advance.  Just
anticipating what might happen
in the future by not overloading the already-overloaded ref=*.  Operators
do have unique references
for car parks.  Several payment options may be available.  Using ref=* on a
first-come, first-served
basis is not helpful ("Of course it means the SMS number because I mapped
that first and added
NFC later.")  If we're going to have ref:*=* for other payment methods it
makes no sense to
appropriate ref=* for just one of those methods, especially when ref=* is
better reserved for the
operator's unique reference for the car park (if there is one).  We
shouldn't have to GUESS what
a bare ref=* means for any particular car park, which is what you appear to
be suggesting.

In this case, the suffix should be the same between the payment key
> and the ref key like payment:sms=yes with ref:sms=*
> not payment:sms=yes with ref:payement-by-sms=*
>

That seems sensible.  What I wouldn't want to see is "ref=12345 means the
pay-by-sms reference
UNLESS it means the operator's unique reference and you'll have to guess
which it is."  Nor do I
want to see "ref=12345 is the pay-by-sms reference but ref:nfc is the
pay-by-nfc reference because
we didn't anticipate future needs and anyway a foolish consistency is the
hobgoblin of little minds."

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181121/c62fdf54/attachment.html>