I copied the draft note to a wiki page ... to facilitate the discussion regarding per key last update date meta data.
https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap Best regards, Stuart On Mon, 6 Apr 2020 at 11:56, European Water Project < europeanwaterproj...@gmail.com> wrote: > Dear Martin, > > A date uses 3-4 bytes of memory. Just for brainstorming purposes, what > would be the total database size inflation if all keys on all nodes, ways > and relations in OpenStreetMap had 4 extra bytes of date meta data ? > > Best regards, > > Stuart > > On Mon, 6 Apr 2020 at 11:42, Martin Koppenhoefer <dieterdre...@gmail.com> > wrote: > >> Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm < >> frede...@remote.org>: >> >>> 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 agree that the last survey date approach where "ordinary" tags are set, >> are crazy. On the other hand, it seems to be a topic that a significant >> number of contributors are interested in (currently ~710.000 tags for >> this). To do it better, maybe it could be stored in parallel? There is this >> long wish list for API 0.7 in the wiki ;-) >> https://wiki.openstreetmap.org/wiki/API_v0.7 >> Likely it would not be something to be implemented in the next 10 years >> or so, but at least it could be kept track of the idea and people could be >> pointed to it... >> >> There could be another table which stores for every tag on every object a >> confirmation date (by explicit request, i.e. it would only be set when a >> contributor explicitly sets it on a tag on an object, and when objects are >> split these would have to be split as well). This would imply that no new >> object version is created for simple property confirmations that do not >> alter the object. >> >> >> >> >>> >>> 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. >> >> >> >> yes, the last survey confirmations would have to be stored on tag level, >> not on object level. >> >> Cheers >> Martin >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
