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.
4 hour to
1.5 hr to
30 min to
30 Days to
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.
Do you also intend to clean up variations of this key, such as
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.
I’m 99% sure the author of that page was only thinking of whole numbers
If numbers between 0 and 1 are contentious, I could just use different units to make full numbers. Then you’ll get changes like
0.5 hr to
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
I noticed that
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.
Help and comments are always welcome.
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.
but there is link in Changeset: 144266924 | OpenStreetMap
Me bad , never look at CS tags
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
no limit /
without limit /
unbegrenzt / … that mean exactly the same as
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
access:conditional tags or in rare cases simply meaningless, like
maxstay=Private on parking that already had
Relevant changesets: 144465519, 144465594, 144465616
I did my best to keep the meanings of all tags the same, like
I made a start with the cleanup of
maxstay:conditional. It’s a much slower process than the cleanup of
Changesets: 144477758, 144477878, 144478037