[Tagging] Map maintenance with StreetComplete - Preferred tagging

Jarek PiĆ³rkowski jarek at piorkowski.ca
Sat Jul 25 01:45:41 UTC 2020

On Fri, 24 Jul 2020 at 21:28, Jmapb <jmapb at gmx.com> wrote:
> On 7/24/2020 7:12 PM, Cj Malone wrote:
> >> OSM does not store edit timestamps for individual tags, only for the
> >> object as a whole. Finding out when a tag was changed requires a
> >> review of the entire history. I had to do this once when I saw a
> >> clear highway=motorway_link tagged as highway=motorway, with me as
> >> the last user to edit that road segment. Turns out the original
> >> mapper was the one to make the tagging mistake, not yours truly, but
> >> I only found this once reviewing the history.
> >
> > Yeah, that option would require a new API and work done on the OSM
> > server to both calculate the last time a tag was edited, serve it and
> > store the timestamp when "touched" or updated. But once that's done
> > it's done for multiple clients, not just StreetComplete.
> >
> > Otherwise StreetComplete would need to use the History API one each
> > individual nwr and try to calculate the age of a tag.
> It sounds to me like what you're describing would require not just a new
> API but a change to the database schema to add a datetime field to each
> tag. Otherwise there would be no way to encode the timestamp of the
> confirmation of an existing tag that does not need changing.

That would be essentially the same thing as what's being proposed with
check_date-like tags, except at a lower level of abstraction. Might be
faster and available to more apps/for more purposes. But on the flip
side, of course new API versions and database fields are a much more
major change than a new tag scheme.

> The history API will only tell you when tags change.

Well, a new API endpoint _could_ automatically read through the entire
history of a node and note which tags changed when. It would
essentially be doing what I do when I open the node history in JOSM
and look when tags changed - only automated. That might well be faster
in the API, where database accesses and data processing is faster. It
would be slower than a dedicated database field, but would not require
the database migration.


More information about the Tagging mailing list