Hi all. I noticed maxstay=* has a clear guideline for units, but the actual tagging (Taginfo) is super inconsistent. I propose to mass edit obvious inconsistencies to the tag values with the same meaning but with units that follow the documented guideline.
Examples:
maxstay=4 hr, 4h and 4 hour to 4 hours
1.5 hr to 1.5 hours
0h30, 00:30, 30min and 30 min to 30 minutes
24h to 24 hours
30 Days to 30 days
I do not plan to edit values without units, because it’s not always clear whether they should be minutes or days.
I am not realy sure why we include the plural form of units in the database. There is no additional information in it and it is just more complicated.
But as this is the documented situation and it is also matching the real use I say: Go ahead and clean it up.
How do you plan to edit values between 0 and 1 (for example 0.5 hour or 0.5 hours)? According to the wiki the unit should be in “plural form when the number is above one”. But normal language would be to use the plural for values between 0 and 1. As there are only something like 50 database entrys with values like this (search here for “0.”) this question is not that important but if you do the work to do an automatic clean up, it should be as good as possible.
I haven’t looked into those tags yet. I don’t mind doing that, but I prefer to keep my mass edits thematically simple, because edits on a global scale are complex enough for me and for people who review them even without the complexity of conditional tags.
For now I would already be satisfied if I could get community support for a large edit of maxstay and I can execute it without major unforeseen circumstances.
The job is done in changeset 144266924. That definitely took a good few hours. This changeset contains ~10% of all maxstay tags in OSM and well over 400 unique tag values.
What’s left in the maxstay=* key is a mix of good data, questionable data, things that required a closer inspection than I could do in this edit and mistaggings of maxstay:conditional=*.
I noticed that fee=* and charge=* are a big mess. I’m not about to clean those up, but I can probably manage a partial cleanup of maxstay tags which should be maxstay:conditional as well as some poorly formatted maxstay:conditional and related tags.
Not objecting to this needing to be done, BUT, don’t get it, for all the procedures to follow, not even a link in the CS to this discussion. 4965 ways were revised… that’s a biggy!
It’s the same with reverts, the number that don’t have the CS reference of what’s being reverted or if whole or part, is countless. You know, but the viewer that looks and sees this popping up in the current CS history view and was not part of the conversation doesn’t.
There are about a dozen different maxstay tags that all indicate no limit on the maximum stay time. The Wiki documentation says the following: “It is permitted to stay for an unlimited period. This can be indicated with maxstay=no or maxstay=unlimited.” Does that mean I can retag all the other tags like maxstay=Unlimited / no limit / without limit / unbegrenzt / … that mean exactly the same as maxstay=unlimited?
I just uploaded an edit in which I moved maxstay tags with an @ in the value to maxstay:conditional: changeset 144410552
I fixed most of the formatting issues, but some tags don’t have units and others are better edited in a changeset that focuses on formatting of maxstay:conditional=* tags specifically.
I made a few changesets to edit/fix some poorly formatted maxstay=* tags that started with a letter. Some were variations of maxstay=no/unlimited, others were mistagged maxstay:conditional or access:conditional tags or in rare cases simply meaningless, like maxstay=Private on parking that already had access=private.
, never look at CS tags