Fix parsing of duration tag for hh:mm:ss format. #514
Conversation
According to http://wiki.openstreetmap.org/wiki/Key:duration there is no dd:hh:mm format, instead this format needs to be interpreted as hh:mm:ss
| * This method parses a string ala "00:00" (hours and minutes) or "0:00:00" (days, hours and | ||
| * minutes). | ||
| * This method parses a string ala 'hh:mm', format for hours and minutes 'mm', 'hh:mm' or 'hh:mm:ss' | ||
| * FIXME: Add support for ISO_8601 |
There was a problem hiding this comment.
The problem is not that it can't be added. The problem are several wrongly mapped duration tags. I think that it was like mixing minute stuff with month, although it is stated in the wiki: duration=PT71M - A duration of 71 minutes. This is not the same as P71M which denotes 71 months.
There was a problem hiding this comment.
In the meantime I have added support for ISO_8601 and intended to add it as separte pull request. I don't think that it is a good idea to just say that it is often filled out in a wrong way and even document in a comment a example of way with a wrong usage. First I would fix this way.
Shouldn't it be possible to add a simple plausability check based on the distance, when it comes to the decision if to consider the value of the duration tag? In case that the calulated speed is less then some value e.g. 0.1 km/h we could ignore it and use the calculated duration based on an the assumed ferry speed instead.
There was a problem hiding this comment.
100% agree - nice idea! Thanks & looking forward to the PR!
There was a problem hiding this comment.
Maybe we can log these mismatches and create a blog post with these entries so that we or mappers could fix them (e.g. creating OSM notes)
There was a problem hiding this comment.
The idea with the logging and the blogpost is very good. Maybe somebody might be willing to turn the result into a "Wochenaufgabe".
Fix parsing of duration tag for hh:mm:ss format.
This change is the result from a discussion of PR graphhopper#514: Now we are supporting the ISO 8601 format of the duration tag. In case that errors of the tag values are detected, the respective OSMWay ID and the duration tag value gets logged.
This change is the result from a discussion of PR graphhopper#514: Now we are supporting the ISO 8601 format of the duration tag. In case that errors of the tag values are detected, the respective OSMWay ID and the duration tag value gets logged.
This change is the result from a discussion of PR graphhopper#514: Now we are supporting the ISO 8601 format of the duration tag. In case that errors of the tag values are detected, the respective OSMWay ID and the duration tag value gets logged.
This change is the result from a discussion of PR graphhopper#514: Now we are supporting the ISO 8601 format of the duration tag. In case that errors of the tag values are detected, the respective OSMWay ID,the duration tag value and its interpretation in minutes gets logged. During the discussion in PR#519 the duration tag parsing was moved into reader: Now we perform the duration parsing during reading in order to avoid ISO8601 XML usage within the flag encoders and convert the value into a graphhopper specific "duration:seconds" tag. The "P2M" test had to be relaxed because on tarvis the openjdk7 obviously returns a slightly different result.
This change is the result from a discussion of PR graphhopper#514: Now we are supporting the ISO 8601 format of the duration tag. In case that errors of the tag values are detected, the respective OSMWay ID,the duration tag value and its interpretation in minutes gets logged. During the discussion in PR#519 the duration tag parsing was moved into reader: Now we perform the duration parsing during reading in order to avoid ISO8601 XML usage within the flag encoders and convert the value into a graphhopper specific "duration:seconds" tag. The "P2M" test had to be relaxed because on tarvis the openjdk7 obviously returns a slightly different result.
According to http://wiki.openstreetmap.org/wiki/Key:duration there is no dd:hh:mm format, instead this format needs to be interpreted as hh:mm:ss
The modification also fixes issue #501