[poll] present "opening_hours", "opening_hours:url", "check_date:opening_hours" together

In the Maps’ list of tags and in ID editor the following three are displayed at various locations:

Frequently, they have to be checked together. So it would be helpful if at least in id-editor they were presented together, especially if “opening_hours” is displayed, also the other two should appear.

To display them together in the general list of tags, I guess it would need to be “opening_hours:check_date”, but it might be too late to change that.

What do you think?

“opening_hours:url” in Id-editor

  • Display with “opening_hours”
  • Leave as is
  • Don’t care
  • Other option (see my comments below)
0 voters

“check_date:opening_hours” in Id-editor

  • Display with “opening_hours”
  • Leave as is
  • Don’t care
  • Other option (see my comments below)
0 voters

Change the key “check_date:opening_hours” to “opening_hours:check_date”

  • Change “check_date:opening_hours” to “opening_hours:check_date”
  • Leave as is
  • Don’t care
  • Other option (see my comments below)
0 voters

Sorry, don’t understand the question?

4 Likes

This would probably be more suited for an issue in the iD repository.

3 Likes

The general list of tags is sorted alphabetically. This makes searching through it easy.
That is also the strength of the check_date:* over *:check_date: If I have a tag and want to find its last check date (if any), I go to check_date: and search alphabetically. Fast. If I want to see all the tags for which there is a check_date, I do the same.
If it was reversed, the latter would become much more non-local. A simple query like “how many check_date:* are there?” would have to check every tag if it has the :check_date suffix.

All this to say, I don’t think changing the syntax would be worth the effort even if it might be possible, which at this point, it’s not.

1 Like

It doesn’t really matter to me where this is placed in iD, because I don’t use the individual input fields; I use the source editor. What matters more is that I find it of limited value to include opening hours in a POI at all. You can’t rely on them, and you still have to check the website yourself.

I agree with you that “check_date:opening_hours” isn’t ideal, but for a different reason. In principle, you would want a check date for every key, yet that would double the number of keys in use and make the editing screen even less readable than it is now. If I update only a few of the many keys in a POI, I make things easier for myself by listing only the keys I actually changed in check_date:tags=name;website;description, along with the check_date itself. Not ideal, but it seemed more convenient.

No. The namespace was designed as it is now. “check_date”:<key> to record when the value of that key was checked….