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
