Modify

Opened 22 months ago

Last modified 22 months ago

#22816 new enhancement

Check for check_date:xxxx if tag xxxx is updated (and offer to fix it)

Reported by: mnalis Owned by: team
Priority: normal Milestone:
Component: Core validator Version:
Keywords: Cc:

Description

check_date:xxxx is often used (for example by apps like StreetComplete or Every Door or others) to mark when some element has been updated.

For example, if surface=gravel which was added few year ago is still surface=gravel as verified by user on the ground, they might add check_date:surface=2023-03-14. Or, if opening_hours=* of the shop were confirmed as not have changed since last time element was updated, they'd add check_date:opening_hours=2023-03-14.

That is useful information, as it allows QA "staleness" tools (as well as those editors intended for on-the-ground verification of data which check for staleness among other things) to ask only about things which are likely to have changed (and skip those which were recently checked)


Now, when JOSM user edits those OSM elements, they might change for example surface=* tag, but do not notice nor update check_data:surface=* tag. That leads to incorrect data. What would be great addition, IMHO, is if JOSM could check for such cases.

  • In most bare application, on upload JOSM could check if any modified element has check_date or check_date:* tags, and warn about it. That would help in itself (as user can ignore those that are vetted), and I guess at least that option is quite easy to add.
  • If more advanced way is possible, JOSM should skip said warning if ALL of those check_date / check_date:* tags were added or updated by current editing session (as it means user has taken them into account and updated them). But I don't know if that is possible (i.e. does JOSM known which tags have changed, and not only which OSM elements have changed?)
  • If even more advanced was is possible, JOSM would ideally warn for each unmodified check_date:xxxx tag only if xxxx=* was modified, and offer to fix (by removing check_date:xxxx) if users chooses Fix. e.g.
    • if there is check_date:surface=2020-01-01 but surface=* wasn't modified, ignore it
    • if both check_date:surface=2023-03-14 and surface=* were modified, ignore it
    • if there is old unmodified check_date:surface=2020-01-01 tag and surface=* was modified, warn and offer to remove check_date:surface
    • if any tag has been modified and there is old unmodified check_date=2020-01-01 tag, warn about check_date
    • if any tag has been modified and check_date=2023-03-14 tag has also been modified, ignore it

(of course each element can have multiple check_date:* tags, e.g. check_date:surface, check_date:lit etc.)

(inspired by this forum discussion: https://community.openstreetmap.org/t/streetcomplete-setzt-check-date-surface/96687)

Attachments (0)

Change History (4)

comment:1 by GerdP, 22 months ago

and I guess at least that option is quite easy to add.

I think this is nearly impossible with the current implementation as JOSM doesn't know how an object was changed nor what the old state is. On upload, all elements are checked for the flag "modified", if set, they are uploaded. JOSM doesn't store the properties of the original element. It does something like that for the undo/redo handler, but not per element.

comment:2 by mnalis, 22 months ago

@GerdP I understand your comment as pertaining to 2nd and 3rd suggestion - if JOSM Validator indeed can not distinguish which of the tags inside modified elements have been changed, that would eliminate them as possibilities.

However, 1st option should still be easily implemented I think:

In most bare application, on upload JOSM could check if any modified element has check_date or check_date:* tags, and warn about it. That would help in itself (as user can ignore those that are vetted), and I guess at least that option is quite easy to add.

For that suggestion, validator doesn't need to know anything expect whether current element to be uploaded has check_date or check_date:* tags. So it would basically work like upper part of this validator: https://josm.openstreetmap.de/wiki/Rules/SourceObjectTag (but for check_date & friends, instead of source tag), right?

in reply to:  2 comment:3 by skyper, 22 months ago

Replying to mnalis:

In most bare application, on upload JOSM could check if any modified element has check_date or check_date:* tags, and warn about it. That would help in itself (as user can ignore those that are vetted), and I guess at least that option is quite easy to add.

For that suggestion, validator doesn't need to know anything expect whether current element to be uploaded has check_date or check_date:* tags. So it would basically work like upper part of this validator: https://josm.openstreetmap.de/wiki/Rules/SourceObjectTag (but for check_date & friends, instead of source tag), right?

Yes, that might work for check_date but not for check_date:* as you would get lots of false positives which disqualifies it to be part of JOSM core at least as "normal" warning and most of the users have informational warnings disabled on upload if they have enabled them at all.

comment:4 by GerdP, 22 months ago

A general warning might still be a good idea to alarm users about this kind of meta information. I think of these tags as a marker that says something like "don't touch this object unless you can proof that you use an online app". I hope I am wrong with this way of thinking...

Last edited 22 months ago by GerdP (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to mnalis.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.