units and notations for maxstay

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

units and notations for maxstay

Warin
Nothing I could see on the wiki for this. So some guidance would be good.

Units.

On tag info there are values with no units... they could be hours,
minute or days.

I would suggest the default unit of hours.

Abbreviations?

h for hours

m for minutes

mos for months

Notations?

For infinite maximum stay time;

24/7?

unlimilted - ?

no_limit?

I would reject the following notations;

load/unload - not a stay but an access,

long_stay (how long?)

free (? no fee?)

private (that is an access tag)

multi_day (how many?)

--------------
thoughts?


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

Re: units and notations for maxstay

Graeme Fitzpatrick


On Tue, 19 Feb 2019 at 13:48, Warin <[hidden email]> wrote:
Units.

On tag info there are values with no units... they could be hours,
minute or days.

I would suggest the default unit of hours.

Abbreviations?

h for hours

m for minutes

mos for months

d for days

w for weeks
 

Notations?

For infinite maximum stay time;

24/7?

unlimilted - ?

no_limit?

Doubt you'd have any of those options on anything with a maxstay mentioned (car park, rest stop / camping ground etc)?
 
Thanks

Graeme

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

Re: units and notations for maxstay

Paul Allen
In reply to this post by Warin
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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

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.

--
Paul


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

Re: units and notations for maxstay

marc marc
In reply to this post by Warin
Le 19.02.19 à 04:47, Warin a écrit :
> For infinite maximum stay time;
> 24/7?
> unlimilted - ?
> no_limit?

the first not-numérical value is "no"
https://taginfo.openstreetmap.org/tags/maxstay=no
that look like good (no maxstay = unlimited)
I dislike 0 : not allowed to stay at all or unlimited ?)
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Warin
On 19/02/19 22:11, marc marc wrote:

> Le 19.02.19 à 04:47, Warin a écrit :
>> For infinite maximum stay time;
>> 24/7?
>> unlimilted - ?
>> no_limit?
> the first not-numérical value is "no"
> https://taginfo.openstreetmap.org/tags/maxstay=no
> that look like good (no maxstay = unlimited)
> I dislike 0 : not allowed to stay at all or unlimited ?)

I dislike 'no', same reason : not allowed to stay at all or unlimited ?

24/7 is used for opening hours - so for consistency I would tend to go for that.

There are other values that occur in the data base.. I selected these as making the most sense.


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

Re: units and notations for maxstay

Warin
In reply to this post by Paul Allen
On 19/02/19 22:03, Paul Allen wrote:
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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

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.
There are some numerical values in the data base without units ... from those values I would guess hours, but they could be days.
As there is no documentation 'we' could make a decision.

No information on abbreviations.

There is also no 'time' entry on the units page https://wiki.openstreetmap.org/wiki/Map_Features/Units .

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

Re: units and notations for maxstay

Paul Allen
On Tue, 19 Feb 2019 at 23:16, Warin <[hidden email]> wrote:
On 19/02/19 22:03, Paul Allen wrote:
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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

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).

--
Paul


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

Re: units and notations for maxstay

Warin
On 20/02/19 10:32, Paul Allen wrote:
On Tue, 19 Feb 2019 at 23:16, Warin <[hidden email]> wrote:
On 19/02/19 22:03, Paul Allen wrote:
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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

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

Re: units and notations for maxstay

Andrew Errington
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 <[hidden email] wrote:
On 20/02/19 10:32, Paul Allen wrote:
On Tue, 19 Feb 2019 at 23:16, Warin <[hidden email]> wrote:
On 19/02/19 22:03, Paul Allen wrote:
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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

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
[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: units and notations for maxstay

Sergio Manzi
+1 this!

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


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Colin Smale
In reply to this post by Andrew Errington

+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 <[hidden email] wrote:
On 20/02/19 10:32, Paul Allen wrote:
On Tue, 19 Feb 2019 at 23:16, Warin <[hidden email]> wrote:
On 19/02/19 22:03, Paul Allen wrote:
On Tue, 19 Feb 2019 at 03:48, Warin <[hidden email]> 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
 
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
[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: units and notations for maxstay

marc marc
Le 20.02.19 à 11:40, Colin Smale a écrit :
> so allergic to the idea of leveraging (how I hate that word...) existing
> standards

I wonder if it will soon be necessary to do an IQ test to contribute
to osm.
if a app says "encode the duration in ISO_8601 format", I wonder if 1%
of contributors are able to encode it without first reading the doc.
but if a app says "duration wihout any abreviation", filling "2 hours"
seems possible to everyone without error.
especially since the maximum duration for a parking is rarely 1 year 3
months 4 days 7 hours 17 min 24sec which eliminates a little bit the
interest of an iso designed for the most extreme situations
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Colin Smale

On 2019-02-20 12:10, marc marc wrote:

Le 20.02.19 à 11:40, Colin Smale a écrit :
so allergic to the idea of leveraging (how I hate that word...) existing
standards

I wonder if it will soon be necessary to do an IQ test to contribute
to osm.
if a app says "encode the duration in ISO_8601 format", I wonder if 1%
of contributors are able to encode it without first reading the doc.
but if a app says "duration wihout any abreviation", filling "2 hours"
seems possible to everyone without error.
especially since the maximum duration for a parking is rarely 1 year 3
months 4 days 7 hours 17 min 24sec which eliminates a little bit the
interest of an iso designed for the most extreme situations

The ISO standard allows irrelevant parts to be omitted, while also allowing for the most complex cases (a balance which OSM often has trouble with). So we say that the value of maxstay is of type "duration" (aka "interval") with syntax defined by ISO8601. A value can be as simple as "PT2H" for 2 hours. The "P" prefix is pretty redundant if we don't need to disambiguate with timestamps , so "T2H" could be enough. What's the minimum IQ required to understand "T2H", "T30M" or "5D"?
 

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

Re: units and notations for maxstay

marc marc
Le 20.02.19 à 12:39, Colin Smale a écrit :
> "T2H" could be enough. What's the minimum IQ required to understand
> "T2H", "T30M" or "5D"?

ask other mapper how to tag "2 hours" in the iso form.
I doubt that 1% 'll reply "T2H" without first reading the doc.
it not only the IQ, it's also the use of user-not-friendly value.
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Sergio Manzi
And so? I'm also quite sure that less than 1% of mappers will spontaneously encode opening_hours=* according to what we prescribe in the wiki [1], but nonethelss that's what we expect they should do.

What's your point?

Sergio

[1] https://wiki.openstreetmap.org/wiki/Key:opening_hours

On 2019-02-20 13:06, marc marc wrote:
> ...
> ask other mapper how to tag "2 hours" in the iso form.
> I doubt that 1% 'll reply "T2H" without first reading the doc.
> it not only the IQ, it's also the use of user-not-friendly value.


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Paul Allen
In reply to this post by marc marc
On Wed, 20 Feb 2019 at 12:08, marc marc <[hidden email]> wrote:
Le 20.02.19 à 12:39, Colin Smale a écrit :
> "T2H" could be enough. What's the minimum IQ required to understand
> "T2H", "T30M" or "5D"?

ask other mapper how to tag "2 hours" in the iso form.
I doubt that 1% 'll reply "T2H" without first reading the doc.
it not only the IQ, it's also the use of user-not-friendly value.

You might get some mappers prepared to use the ISO format.  Good luck with ordinary
consumers using the query tool of standard carto: the results of that are intimidating
enough without requiring them to read an ISO document to interpret the results.

One day we're going to have to decide whether OSM is about masturbation or sex.  Either
we're doing this for ourselves alone or we're trying to produce something that will be
appreciated and used by non-mappers.  If we're masturbating then T2H30M is fine.  If
we're trying to have sex then 2.5 hours is the way to go.

--
PPaul


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

Re: units and notations for maxstay

Colin Smale

On 2019-02-20 13:29, Paul Allen wrote:

On Wed, 20 Feb 2019 at 12:08, marc marc <[hidden email]> wrote:
Le 20.02.19 à 12:39, Colin Smale a écrit :
> "T2H" could be enough. What's the minimum IQ required to understand
> "T2H", "T30M" or "5D"?

ask other mapper how to tag "2 hours" in the iso form.
I doubt that 1% 'll reply "T2H" without first reading the doc.
it not only the IQ, it's also the use of user-not-friendly value.
 
You might get some mappers prepared to use the ISO format.  Good luck with ordinary
consumers using the query tool of standard carto: the results of that are intimidating
enough without requiring them to read an ISO document to interpret the results.
 
One day we're going to have to decide whether OSM is about masturbation or sex.  Either
we're doing this for ourselves alone or we're trying to produce something that will be
appreciated and used by non-mappers.  If we're masturbating then T2H30M is fine.  If
we're trying to have sex then 2.5 hours is the way to go.
 
Even in this case, we should take the trouble to define the syntax for a duration, in such a way that the definition is reusable and extensible. Should it be 2.5 hours, or should it be 2 hours 30 minutes? Using only fractional hours will be problematic to encode 17 minutes, for example; and unwieldy to encode 6 months. Lets be clear, the storage format can (and should) be decoupled from the display format. What is stored in the database can easily (assuming it is sufficiently standardised!!!) be translated for human consumption, and the inverse can be done when storing. It happens in just about every computer program ever. Storing the value as an ISO string assures machine-readability and editors, browsers etc can use standard libraries to format it for humans, in whatever language you like.
 
Among the advantages of using the ISO standard include that all that thinking has already been done, and the documentation of the syntax is available freely in millions of languages.
 

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

Re: units and notations for maxstay

Paul Allen
On Wed, 20 Feb 2019 at 12:44, Colin Smale <[hidden email]> wrote:

Even in this case, we should take the trouble to define the syntax for a duration, in such a way that the definition is reusable and extensible. Should it be 2.5 hours, or should it be 2 hours 30 minutes? Using only fractional hours will be problematic to encode 17 minutes, for example; and unwieldy to encode 6 months.

You seem to be assuming, contrary to all the preceding discussions in this thread, that only one
unit is allowed.  All preceding discussions mentioned minutes, hours, days and months.  2.5 hours
or 90 minutes.
 
Lets be clear, the storage format can (and should) be decoupled from the display format. What is stored in the database can easily (assuming it is sufficiently standardised!!!) be translated for human consumption, and the inverse can be done when storing. It happens in just about every computer program ever. Storing the value as an ISO string assures machine-readability and editors, browsers etc can use standard libraries to format it for humans, in whatever language you like.

You are living in an ideal world that does not exist.  Go to the standard carto.  Use the query tool.
All the translation mechanisms you posit do not exist.  If you are prepared to produce a changeset
for the standard carto to do that, AND manage to get it incorporated, then you'd have a point.  Well,
if you could guarantee that ALL data consumers would implement it, you'd have a point.  Well,
provided all the editors also incorporate it.  If you can achieve all of that then you have my support.
Actually, you wouldn't have my support.  Because if you can achieve all of that we can encode
durations as seconds rather than strings that have to be parsed.

Among the advantages of using the ISO standard include that all that thinking has already been done, and the documentation of the syntax is available freely in millions of languages.

And read by almost no data consumer.  And, unlike the simpler forms of opening hours,
it's less likely to be understood by a data consumer.

--
Paul


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

Re: units and notations for maxstay

Sergio Manzi
In reply to this post by Colin Smale
Perfect!

NIH syndrome [1] anybody?

[1] https://en.wikipedia.org/wiki/Not_invented_here


On 2019-02-20 13:42, Colin Smale wrote:
> Lets be clear, the storage format can (and should) be decoupled from the display format. What is stored in the database can easily (assuming it is sufficiently standardised!!!) be translated for human consumption, and the inverse can be done when storing.
...
>  Among the advantages of using the ISO standard include that all that thinking has already been done, and the documentation of the syntax is available freely in millions of languages.


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: units and notations for maxstay

Paul Allen
On Wed, 20 Feb 2019 at 12:59, Sergio Manzi <[hidden email]> wrote:
Perfect!

NIH syndrome [1] anybody?

[1] https://en.wikipedia.org/wiki/Not_invented_here

More like "Somebody has already invented the hammer so there's no need for that new
screwdriver thing, just hammer the screws in."

Fitness for purpose trumps "already invented."

--
Paul


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