Here are just a few questions, and two development ideas regarding presenting tags and their metadata in the different editors in OSM.
For reference, I personally mostly use JOSM but do occasionally fire up iD for simple and quick fixes. I have no idea how the other editors work or even look like. Therefore I assume that the ideas below might apply to all editors (and maybe even to the tag-listings in the info-boxes accessible through the Map Data overlay). I also do program for fun in a few languages, but do not possess the prowess to actually provide any code either to JOSM or iD myself.
I often find myself wondering when a specific tag was added to (or last edited in) an element. To that end, I now have to check the entire history of the element. I do have a nagging feeling that I’ve just missed something really trivial!
I was wondering how difficult it would be to add some easier and way to immediately see, when a specific tag was last changed (maybe just as a small mouse hover-over field). And this is a genuine question! I’d assume that the database has immediate access to timestamps also on a per-tag basis, but I have no idea whether this really is the case.
Lastly, just as a note on this point, I do realize that it may be a niche request. In fact, on most tags the edit (or create date) indeed is not important nor interesting. For example, highways rarely change classification from =primary to =tertiary, but checking the date of a surface= or smoothness= tag can be useful in assessing whether a check-up would be a good idea, especially if I know that a bit of that road was recently under construction.
Please, feel free to comment and educate me on any aspects on these points and questions!
I check history in JOSM very, very often to see when a particular tag or value was set. It takes up a lot of time when manually bulk processing data from a source. A mouseover tooltip with the latest change date of the tag would certainly help speed things up. I’m not sure it would be worth an automatic API call for every tag mouseover, though.
Thank you kindly to @Peter_Elderson and @Map_HeRo for your replies! Good to know that I’m not the only one e.g. browsing the element history frequently.
And @Peter_Elderson s point about calling the API every mouseover hover is a good one! It would indeed be more reasonable to get the timestamps of every tag when fetching the data. However, this is precisely one of the reasons that makes me think such an amendment might be far from a trivial thing to code, even though the idea seems very simple. Presumably one would have to change the API calls themselves?
What do you think would be the best way to go forward?
Before I started this thread, I did consider just opening a ticket to JOSM. I didn’t do that because, firstly, I wanted to feel out whether there was any interest to the points in the community. Secondly, and more importantly, the points would concern other editors as well, and the Map Data infoboxes on the website. But maybe it would be good to start just with JOSM and see how things go from there?
Is there a Discourse forum/Dischord server/IRC channel/whatever operating sub rosa where one could submit such general enhancement/development ideas?
It is one of the more annoying things in our current API/data model that it doesn’t have any meta information on the individual tags. You -can- go back in time and find out when a tag was first added, or when it’s value was modified, but this requires going back through the objects versions which is fairly expensive as these things go. You still don’t get any information if a tag was updated/confirmed with the same value even then.
That’s why we are currently stuck with crutches if we want to record such information aka check_date tags. I did outline what a solution could look like a couple of years back on one of the mailing lists.
Ah! Thank you very much for furnishing that info! I had a feeling that might be the case.
I know just enough (though relatively little) about programming to get why that kind of operation might be computationally very expensive. Although, that is, it’s a relatively easy Gestalt-like task for a human to quickly spot the differences & relative changes in the element-history listing between each tag (though as @Peter_Elderson notes, it is somewhat slow and cumbersome task to unearth the element history itself).
I detest the current hype on the so-called “AI”, but maybe this would be a task well suited for it (i.e., do the computationally expensive stuff outside of the database )
This is a fair point as well! It indeed is impossible to directly infer from the database metadata if a tag was intentionally left unchanged simply because there was nothing to change in it. Unless we really start to add per-tag-notes to all tags…
…which brings me to point 1 in my original post. That might be a possible (& I’d imagine a much easier) development idea? The two points are indeed connected to each other. The tag-specific notes could be used more directly to give such specific info (or “metadata”) to other mappers!
It doesn’t really more than a per-tag flag that the editor can furnish (“actually updated”), not saying that would be a good implementation, but it is information that in the end only the editor can determine.
Oh! Right, sure! Such a flag might indeed suffice! At any rate, it would be lot less hassle than managing (multiple) prefixed notes, or adding an entirely new data field concomitant to each tag.
The change-flag would certainly be an improvement to the status quo. Though I would imagine adding a new flag to every instance in the database is not an easy proposition either.
Also, I would imagine that it would be impossible to indicate—only with such a flag—that a tag value was left intentionally unchanged? I mean, even if i do edit the value of a tag to the same value it had before (so not really change it), I’d imagine the changeset actually sent to the server would only contain the differences made to the data already present in the database? Not that this would be a fatal problem, though!
[EDIT:] Unless of course if you meant a flag that the user could also set manually to indicate that they had checked (but not altered) some tag! Again, an interesting idea!
(JOSM specific)
On the quick and easy side (I think): Most of the time I want to know the date of first occurrence of the specific tag (key+value). Currently, I look at the From column to see the version, then at the versions list to see the date. If the From column gave the date, one glance would be enough for me for most of my processing: the When.
Sometimes I want to know the Who, the Why or the Editor tool used, but usually that is to track an error or peculiarity, and then I will do whatever it takes, which usually means use the changeset(s). So for that purpose I’m fine as it is.
What might help to implement a tooltip mechanism, is caching the history, together with downloading “history sets” for a selection of objects (rule based, policy based or user choice). If I’m not mistaken, currently the history is downloaded fresh every time I click the History button, for one object, and discarded when I close the History panel.
There is a script for Tampermonkey/Violentmonkey which makes a few adjustments to the visual interface of the OSM website. One of them is showing tags diff.
)