On Mon, 6 Apr 2020 at 10:14, Frederik Ramm <frede...@remote.org> wrote:
> Dear Frederick, > > may I suggest that you choose a personal email address for participating > in mailing lists. It feels really strange to address a message to > "europeanwaterproject". I don't want to talk with "a project", I want to > talk with a person. > I am a person not a robot :) Thank you for the suggestion. > > On 06.04.20 09:31, European Water Project wrote: > > Please find attached a draft note for a feature proposal, which I have > > no idea if is even technically possible, for automatically adding a last > > verified date/creation date to specific keys. Maybe there is a > > better/more efficient way ? > > There are several issues here. > > Firstly, I don't know what you mean by "automatically adding". After all > you need a person to manually confirm that the object is unchanged > before a tag is added, so which part of this is automatic? Surely you > are not saying that you want to add a tag to every object that simply > duplicates the last-edit timestamp already stored? > You are right. It would be ludicrous to add a datestamp tag to ever object key, but having access to last changed/verified meta data for particular key tags would be useful. > > Secondly, this is a problem shared by all the "last survey" approaches: > You're standing the logic on its head. You're essentially saying: "If > the object has NOT changed in reality, please DO change it in OSM" (by > updating the last-checked tag). This means that we're being asked to > switch from mapping changes to mapping non-changes, with a potentially > huge data inflation in OSM (in theory I could update the "last survey" > of my local supermarket every time I shop there...). Your idea to > identify potentially fast-changing things and concentrate on these > softens the impact but still, we'd be churning out new versions of > objects like crazy just to confirm they are still there. (Everytime you > make a little change to one of the object's 10 tags, a full copy of the > object is created in OSM.) > I am not "saying" anything. I am brainstorming about whether or not storing updated meta data for a key being verified can be maintained without the OSM object being modified. > > Thirdly, also shared by many "last survey" approaches: If you tag a > restaurant with a last survey date then exactly what have you surveyed? > Just that it is still there? That is still has these opening hours? Or > that it still gives you free water? There's potential from confusion here. > The draft proposal was on the key level not the object level for just this reason. > > The topic of staleness has been attacked by scientists in the past, > trying statistical approaches along the lines of "if there's a decent > number of detailed edits by different people in this area, then there is > a high probability of data being up to date". This of course doesn't > give you the same reliability but perhaps it delivers some results > without being the massively invasive concept you're proposing. > I believe there will be better data quality for high use observable/verifiable data than rarely used data or data that cannot be observed at all (ie third party sourced data, the presence of a café in a small town with few visitors, or the name of the author of an artwork). > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
