Talk:Key:duration

From OpenStreetMap Wiki
Jump to navigation Jump to search

We should depreciate the "mm" format.

As the simple "mm" format can be quite ambiguous (could just as well be hours), we should recommend "hh:mm". That format also aligns better with the iso standard. --Gorm 15:47, 30 June 2012 (BST)

OSMR

This tag is recognized at http://map.project-osrm.org/ for ferries. At least the hh:mm format is supported. Proper tagging of duration on ferries ensures that they are chosen where this is natural, instead of choosing a long detour to avoid the ferry.

The OSRM router uses a very conservative speed of 5km/t for vehicle ferries. It is not unusual for large conventional vehicle ferries to have a normal speed of 10-15km/t or more.

OSRM is now supporting ISO8601 format. source:https://github.com/Project-OSRM/osrm-backend/commit/7e00a86bb47dce69913bf27588b73d9a96dce254 Kerosin (talk) 17:25, 2 March 2015 (UTC)

Time format

I don't like the format hh:mm because this conflicts with the format for the time of day as used by other keys like opening_hours=* or conditional=*. In order to be consistent, it would be better to use the same format for a duration as specified for maxstay=*. So instead of using <duration=08:00> it would be better to write:

This would even make it possible to use the easily readable 'Time and date' condition, e.g.:

(And no, I don't think using ISO 8601 is a good idea. I suppose that my example in ISO 8601 format would be written like this <duration:conditional=PT5M @ (08:00/18:00); PT7M @ (18:00/19:00)>. The precision is the same but it took me more than 5 minutes to figure this out. My conclusion is that ISO 8601 is not intuitive enough.) --Biff (talk) 23:52, 2 June 2016 (UTC)

The ISO 8601 is nice because it's non-ambiguous, but ya, at first glance it looks too intimidating and is hard to read. I don't like the ambiguous x:y format because it could be HH:MM or MM:SS. I like the idea of a hybrid ISO8601 standard which would use lower case units for the time (ie h,m,s for hour,minute,second) then the 'T' can be removed. So like 1 day 3:40:30 would look like 1D 3h40m30s. And there could be spaces between for readability. But point is I don't think there should be a single format so long as it's unambiguous. Make the parser conform to the contributors, not the reverse. The linux date and sleep commands are awesome like that. The other point is to make it very fast an intuitive to understand the format just by looking at the table of examples (which as it stands is most certainly not). DFyson (talk) 03:58, 21 March 2017 (UTC)

x:y means x hours y minutes. The Linux date format is just a nightmare due to localization. The ISO format on the other hand is simple and readable. Yes you need to get used to. Once. But like for opening_hours with http://projets.pavie.info/yohours/, programs can be added to give a user friendly interface. D is English for Day. Not T for Tag or J for Jour. ISO format is international and already user friendly for Asia where DDDD-MM-JJ is common. When based on a norm, you have tools to parse the duration into a duration in the wanted language and you just pass the initial duration or even the ISO string to a duration picker which enable you to display and possibly update the duration in a user friendly manner as you would do with a date (you can type a date or pickup a date). Please don't change a norm into a non sense preventing proper UI in 99% of the tools, ask for better editors!
--Nospam2005 (talk) 20:11, 21 March 2017 (UTC)

ISO 8601 standard

I think the 'P' suffix should be dropped because it adds more confusion and complexity and it's redundant because it's implied by the fact it's a value of the duration tag. I can understand in other cases it would be important where it's not clear if it might be a time or a duration. DFyson (talk) 03:58, 21 March 2017 (UTC)

No! Without P it means a time, not a duration! Keep the norm, otherwise it's a unparsable stuff in the sens that it would need extra work for the machine and wouldn't be obvious to the human either. A human being can read and understand a norm. Not 75 because you don't like a letter which is not necessary if you create a specific norm just for duration in OpenStreetMap.
--Nospam2005 (talk) 19:57, 21 March 2017 (UTC)
But duration is implied so it's impossible to have any confusion. Having a time in the duration tag wouldn't make any sense. I think extra work for the machine should be encouraged if it means simplicity for the user (quality being equal). I'm not suggesting replacing the ISO 8601 standard but to document both to accommodate the occasional user. Another point to consider is peoples editing habits. I guarantee you people will omit the 'P' because they either forgot, or haven't read this and doing whatever is intuitive to them. So I think the best option is to adapt reasonably well to people's intuition so long as there is no ambiguity and it's still machine readable. If we did a poll, I bet you duration='5m' would universally understood whereas duration='PT5M' would create plenty of confusion except for those savvy to the ISO 8601 standard.
DFyson (talk) 18:10, 22 March 2017 (UTC)
You're making a hypothesis which IMHO should be wrong: editing a period with a text editor.
Back to the 80s, it would have been fine ;-). Nowadays only geeks prefer this kind of UI and can deal with ISO format.
On the other hands most users prefer a user friendly user interface like this one:
FR-fr PeriodPicker.png
Intentionally in a foreign language. Here on the top you've the user friendly textual description (Toutes les 2 semaines = every second week). and with the circles you edit the period (1/2/3... on the left) and the unit (here daily, weekly, monthly).
The textual output clarifies if biweekly or every second week is meant.
Because ISO 8601 is a standard, you can search for let say "javascript duration picker" and you find ready to use UI. Very simple for the guy making an editor on OSM data using a duration as key. Very simple to check validity also (not less than 3 ready to use duration modules on NodeJS). If you set a specific duration format you need every body (including non English speakers) to deal with a specific textual representation. Even if your previous time format proposal is a good way to deal with textual representation, it remains a non user friendly way to enter a duration - long to type, error prone for non English speakers. If you say "duration values are ISO8601 durations" you defines unambiguously what you expect and editors can easily provide support for that.
With a half human readable representation you make the validation much harder (understand: reinvent the wheel - here for instance add a P if not present then parse as ISO8601) and more error prone.
IMHO, everywhere there is a wide accepted norm, and ISO 8601 is such a format, it should be used. "Home made" formats should be used only in other cases.
5 meters for a duration, that's strange ;-) (remember, in OSM the default unit is meter and m is the abbreviation for meter (min is for minutes, except with hms related formats).
--Nospam2005 (talk) 20:45, 22 March 2017 (UTC)
Ya that's a good point about the editors especially with different languages. You've convinced me to stick to a strict ISO standard in the OSM database. It makes sense to keep the database standardized and move the burden of human readability to the human interface. However I'm using JOSM, ID, and Vespucci and all of them are raw text entry. So I suspect there will still be problems with people putting in what is intuitive for them unless they read the wiki. Thus someone will likely need to create a cleanup script for the duration=* tags.
DFyson (talk) 21:50, 22 March 2017 (UTC)
You just proved the impact of a picture compared to a text. I never said it was so simple. But a direction to take. If we consider JOSM, ID, Vespucci, maps.me and other variants they are all based on Java or Javascript (Potlatch is written in flash which has a JavaScript API), so if we say we should accept any PT* form of the ISO 8601, we should be able to edit / display those durations properly.
For the existing values, I guess JOSM has a checker for validation, others probably too, if not they should, so any valid representation should be parsed into an internal representation and outputted as ISO 8601 string.
That's very similar to the behavior of http://projets.pavie.info/yohours/: if you feed it with a too complex value, it just checks for validity and says it can't turn it into a graphical representation but that it is a valid representation (or not). For instance http://projets.pavie.info/yohours/?oh=Mo-Fr%2007:30-20:30%2022:00-23:00;%20Sa,Su%2016:00-20:30;%20PH%20off.
If we decide to stick to ISO 8601, then we can propose this migration path to the main editors maintainers and publish the proposal including the migration path (in order to avoid conflicts similar to the one that happened with the transport schemes).
--Nospam2005 (talk) 22:26, 22 March 2017 (UTC)
I would have been convinced without the picture, but it can help. What really got me is the idea of keeping the database standard and transitioning the human readability (which includes language support) to the user interface side. It seems more logical, beneficial and pretty universally standard for other databases. Previously I was convinced the database entries should contain human readable content because most of the editors directly edit that value and don't have an interface to translate it to something more human readable. And I'm still fine with people putting whatever they want in the tag if it's not obvious or don't know any better. It just means potentially cleaning it up later and apps which have strict parsers might have unusable data until it is cleaned up. None of the editors validate it either. I think really it just comes down to deciding on a philosophy for data management and sticking with it. Just for future reference, I've opened tickets for iD, Vespucci, JOSM, and JOSM OpeningHoursEditor plugin.
DFyson (talk) 23:47, 22 March 2017 (UTC)

maximum, minimum or avarage?

Should it be maximum, minimum or average duration? maro21 21:20, 29 April 2021 (UTC)

Good question, https://www.openstreetmap.org/way/820303479 uses a value 00:45-01:00 to indicate a range, though it's not documented so broke my processing code but it seems reasonable for routes that have a large range. --Aharvey (talk) 03:45, 17 August 2021 (UTC)

Duration longer than 24 hours

Long hiking routes have durations of several days.
It can't be expressed with time formats (00:00 or 00:00:00).

So we must use ISO 8601 standard [ ISO 8601 Durations]?

Duration Value
1 year P1Y
2 months P2M
3 weeks P3W
4 days P4D
5 hours PT5H
6 minutes PT6M
7 seconds PT7S
8 days and 9 hours P8DT9H

--Pyrog (talk) 17:34, 4 January 2022 (UTC)

"P3W" or "P8DT9H" is not readable or understandable at all. And for example 4 days can be expressed perfectly fine as 96:00. https://www.openstreetmap.org/way/672506453 is even linked already in the article... Mateusz Konieczny (talk) 20:11, 4 January 2022 (UTC)
How are they " not readable or understandable"? 4 days doesn't necessarily mean exactly 96hours. ---- Kovposch (talk) 06:00, 5 January 2022 (UTC)
I expect that typical mapper will fail to interpret or guess meaning of P8DT9H Mateusz Konieczny (talk) 07:57, 5 January 2022 (UTC)
8D and 9H are quite fine. You only need to teach prefixing periods with P, interfixing time with T. P-prefix is discussed in Talk:Key:duration#ISO_8601_standard above. T-interfix is already used by ISO8601 time pointin 2022-01-05T09:34:55Z. It's not as complicated as the full opening_hours=* syntax either, where there are editing software helping with entering it aside from directly tagging. ---- Kovposch (talk) 09:37, 5 January 2022 (UTC)
Does a typical mapper understand 504:00 ?
As said before, apps should display durations in a human readable form.

Also, values should be checked. Currently some values aren't understandable for computers, for humans and sometime for both.
--Pyrog (talk) 07:40, 6 January 2022 (UTC)
I expect that far more mappers will understand and able to enter 504:00 than ISO 8601 equivalent, whatever it is. Mateusz Konieczny (talk) 10:55, 6 January 2022 (UTC)
You have to do arithmetic, difficult enough. Eg in incline=* and many other attributes you are allowed to enter the original units. It's not the original meaning either (days and nights required doesn't equal to exact hours spent, will overestimate the time period). This will be misunderstood by everyone. ---- Kovposch (talk) 13:26, 6 January 2022 (UTC)

Wo could understand all subtilities of opening_hours format?
Contributors use a specific editor and users read opening hours in apps.

I suggest to use prefered format and apps decode all.
Personnaly I prefer ISO 8601 because there is no ambiguity.
--Pyrog (talk) 13:38, 6 January 2022 (UTC)
Using ISO 8601 looks like a reasonable option. There are only a few symbols there and it is certainly easier to understand than e.g. 201:00. "P8DT9H" is easy to read, just omit "P" and "T" = 8 Days, 9 Hours".
Pyrog: looks like Graphhopper doesn't take the "duration" tag into account at all, looking at your example with the ferry from Perth. maro21 14:33, 6 January 2022 (UTC)

Duration on dual use relations

Has anybody attempted to tag duration= on relations with dual use (eg. on a designated bridleway)? Should duration be based on foot / bicycle / horse users in this case, or is there an alternative suggestion that could include all three modes of transport? Thanks --Olivia.ragone (talk) 12:26, 1 April 2024 (GMT)

Aren't these modelled as distinct relations, one for each mode of transport? --Dieterdreist (talk) 10:48, 2 April 2024 (UTC)
That's referring to the semicolon multival, of which there are ~700 https://taginfo.openstreetmap.org/keys/route#values
—— Kovposch (talk) 11:24, 2 April 2024 (UTC)
You could make it duration:foot=* etc. But ideally best if able to separate.
—— Kovposch (talk) 11:25, 2 April 2024 (UTC)
IMHO if you want to tag at this level of detail, you better make distinct relations for each mode of transport. There are literally no "duration:foot" or similar tags which would distinguish on a tag level: https://taginfo.openstreetmap.org/search?q=duration#keys --Dieterdreist (talk) 11:41, 2 April 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:duration&oldid=2688121"