+10e99
To be honest I have never really understood why OSM seems so allergic to
the idea of leveraging (how I hate that word...) existing standards. I
can only guess that anything that smells of formal ontologies is thought
to limit or restrict the creative freedom of mappers to invent new
values and introduces the concept that values can now be demonstrably
"wrong" or "illegal". So we do whatever we like, until someone notices
and objects.
On 2019-02-20 01:45, Andrew Errington wrote:
> Already handled by ISO8601:
>
> https://en.m.wikipedia.org/wiki/ISO_8601#Durations
>
> I think any discussion of dates and times should start by asking if we could
> apply ISO8601 to the problem at hand. For example the other thread about
> start date variants.
>
> Andrew
>
> On Wed, Feb 20, 2019, 12:48 Warin <61sundow...@gmail.com wrote:
>
> On 20/02/19 10:32, Paul Allen wrote:
>
> On Tue, 19 Feb 2019 at 23:16, Warin <61sundow...@gmail.com> wrote:
>
> On 19/02/19 22:03, Paul Allen wrote:
>
> On Tue, 19 Feb 2019 at 03:48, Warin <61sundow...@gmail.com> wrote:
> Nothing I could see on the wiki for this. So some guidance would be good.
>
> Units.
>
> I added a maxstay a few weeks ago and I found info about units at
> https://wiki.openstreetmap.org/wiki/Key:maxstay
>
> Units are not explicitly defined, but there are several examples. Units in
> those examples
> are minutes, hours, and days. I expect that weeks, months and years would
> also be
> acceptable for long-stay parking. Maybe even decades and centuries, should
> they be
> needed. Seconds are too small to be practicable.
No information on default units.
True. But the examples show which units are permissible and how they
should be
specified.
> There are some numerical values in the data base without units ... from those
> values I would guess hours, but they could be days.
Or minutes, depending on actual value. One place near me says waiting
is limited to 90 minutes.
But 90 days is close to 3 months. Could be either if units aren't
given.
> As there is no documentation 'we' could make a decision.
>
> No information on abbreviations.
>From the examples, unit names are spelled out in full.
So the choice is between:
1) Spelling units in full (as per the examples) and specifying which
unit is the default.
2) Coming up with abbreviations and specifying which unit is the
default.
I'd go with 1). Firstly, somebody (like me) may have specified units
that way already.
Secondly, different languages may have different names for those units
of time. We can
agree to (mostly) use SI units for mass and length because those are
applicable in much
of the world and have standard abbreviations. Common time units like
minute, hour and
month probably have different abbreviations in different parts of the
world. Less error
prone if an editor drop-down has minutes/hours/days than m/h/d if "d" is
the abbreviation
for a period of 3600 seconds in some language. Thirdly, minutes and
months (m and m).
Looks good to me. See what others think.
On default units ..
Possibly specify the smallest unit as that will cause the least amount
of harm with already entered values?
By that I mean a value of '60' if taken as days would be more harmful to
the user (fines, tow away) than if taken as minutes.
Not convinced on this, but it is a thought.
_______________________________________________
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
