Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Thu, Jul 30, 2020 at 12:40:58PM +0200, Martin Koppenhoefer wrote: > > > On 30. Jul 2020, at 10:39, ael wrote: > > > > often without survey, and then do not update the source, so > > that tag becomes completely misleading. > > that’s what happens all the time. When I edit things that already have a > source tag (generally source=Bing) I am removing it, as it is not valid any > more. I thought it was established practice that sources belong to edits and > not to objects Only because, as you say, the source tag is misused. I admit that extending tags is not very widely done, and some people seem to have trouble parsing ";" which I use as a separator. But my tags generally look like source=first;second;... when appropriate. I only delete sections of the source when the original corresponding data has been completely revised. That is quite common in the UK where some origianl rough & ready mapping was done from old maps (NPR, etc). When that has been completely reworked, then the original source=NPR; component can be deleted. > There’s a reason why source tags on objects are discouraged. To make sense of > them you have to dig into the object history anyway. Too many people just > keep/ignore the source tags regardless of their own edits. Surely it is better to educate people who perhaps don't realise how to extend or modify tags? Mind you, I would always want people to check history in any nontrivial cases. Easy in josm: I don't know about other editors. Perhaps we mean "source_history" instead of "source"? ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
sent from a phone > On 30. Jul 2020, at 10:39, ael wrote: > > often without survey, and then do not update the source, so > that tag becomes completely misleading. that’s what happens all the time. When I edit things that already have a source tag (generally source=Bing) I am removing it, as it is not valid any more. I thought it was established practice that sources belong to edits and not to objects There’s a reason why source tags on objects are discouraged. To make sense of them you have to dig into the object history anyway. Too many people just keep/ignore the source tags regardless of their own edits. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Thu, Jul 30, 2020 at 01:55:45AM +0200, Martin Koppenhoefer wrote: > > > On 26. Jul 2020, at 23:58, ael wrote: > > > > Adding such source tags to a changeset seldom makes sense. > > Most of my changesets are a mixture of local knowledge, surveys, gps, > > photographic and video. I even occasionally use satellite imagery... > > So the source data needs to be fine grained on the elements themselves. > > maybe you should upload more often and less things at a time. I sometimes add > several sources like aerial imagery and survey to the same changeset. FWIW, I > believe the most relevant information is: di you know the area (local > knowledge or not) and have you been there to gather the information you are > adding or is it based on aerial imagery. When I am mapping new areas, it is often simple, but when updating (almost always from gps surveys) things get complex. I often notice adjoing ways & features are missing, poorly mapped or whatever, so there I may use imagery as an interim measure. Likewise for inaccessible places. For existing elements I almost always check the history to see what sort of status the existing information has. A changeset comment listing all the various sources isn't going to help unless I have a new changeset for almost every way. The source tag solves the problem. > > Furthermore, when updating an element, I can see any source tags right > > there. > > and what are you doing with them when you modify the object? Do you keep > them, remove them, amend them, change them? Amend and expand. It annoys me when other mappers come along and change data, often without survey, and then do not update the source, so that tag becomes completely misleading. These are the same sort of mappers who replace high quality surveyed data with armchair guesses, downgrading the map:-( ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
sent from a phone > On 26. Jul 2020, at 23:58, ael wrote: > > Adding such source tags to a changeset seldom makes sense. > Most of my changesets are a mixture of local knowledge, surveys, gps, > photographic and video. I even occasionally use satellite imagery... > So the source data needs to be fine grained on the elements themselves. maybe you should upload more often and less things at a time. I sometimes add several sources like aerial imagery and survey to the same changeset. FWIW, I believe the most relevant information is: di you know the area (local knowledge or not) and have you been there to gather the information you are adding or is it based on aerial imagery. > > Furthermore, when updating an element, I can see any source tags right > there. and what are you doing with them when you modify the object? Do you keep them, remove them, amend them, change them? Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
The problem is that someone actively mapping in a given area would be irritated by completely pointless checks and repeated checks of the same objects. Jul 29, 2020, 12:34 by luke.mar...@viacesi.fr: > Due to some concerns expressed in here (bloatness, discrepancies), I've been > wondering... > Wouldn't it be enough to ask randomly about some properties to be checked? > > For example, let's say I'm using SC to do some mapping, and from a 100 > quests, I get whatever proportions of maintenance quests selected randomly. > While this wouldn't provide information that I did check to OSM database (if > data is accurate), it still ensures that the DB is correct. > > As someone stated, with a proper number of users, the concepts of having a > last date of check might be obsolete, so having people do random checks > (could still be prioritized based on actual element) on top of filling new > stuff might be enough in the long run. > > > > De :> ael > > Envoyé :> dimanche 26 juillet 2020 23:56 > > À :> tagging@openstreetmap.org > > Objet :> Re: [Tagging] Map maintenance with StreetComplete - Preferred > tagging> > > On Sun, Jul 26, 2020 at 10:03:17PM +0100, Cj Malone wrote: > > On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote: > > > > > > So in a nutshell, the topic of how to find things based on old > > > sources is also very relevant for remote mappers. > > > > Technically there is survey:date and source:date that may be on the > > object, or (preferred now?) the changeset. So a quality assurance tool > > Adding such source tags to a changeset seldom makes sense. > Most of my changesets are a mixture of local knowledge, surveys, gps, > photographic and video. I even occasionally use satellite imagery... > So the source data needs to be fine grained on the elements themselves. > > Furthermore, when updating an element, I can see any source tags right > there. I am not normally going to all the faff of looking up the > history, finding the changesets and consulting those except for unusual > cases. > > Of course, changesets need to have some overall source infomation, but > that is necessarily coarse except for small cahnges perhaps. > > ael > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Due to some concerns expressed in here (bloatness, discrepancies), I've been wondering... Wouldn't it be enough to ask randomly about some properties to be checked? For example, let's say I'm using SC to do some mapping, and from a 100 quests, I get whatever proportions of maintenance quests selected randomly. While this wouldn't provide information that I did check to OSM database (if data is accurate), it still ensures that the DB is correct. As someone stated, with a proper number of users, the concepts of having a last date of check might be obsolete, so having people do random checks (could still be prioritized based on actual element) on top of filling new stuff might be enough in the long run. De : ael Envoyé : dimanche 26 juillet 2020 23:56 À : tagging@openstreetmap.org Objet : Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging On Sun, Jul 26, 2020 at 10:03:17PM +0100, Cj Malone wrote: > On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote: > > > > So in a nutshell, the topic of how to find things based on old > > sources is also very relevant for remote mappers. > > Technically there is survey:date and source:date that may be on the > object, or (preferred now?) the changeset. So a quality assurance tool Adding such source tags to a changeset seldom makes sense. Most of my changesets are a mixture of local knowledge, surveys, gps, photographic and video. I even occasionally use satellite imagery... So the source data needs to be fine grained on the elements themselves. Furthermore, when updating an element, I can see any source tags right there. I am not normally going to all the faff of looking up the history, finding the changesets and consulting those except for unusual cases. Of course, changesets need to have some overall source infomation, but that is necessarily coarse except for small cahnges perhaps. ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Sun, Jul 26, 2020 at 10:03:17PM +0100, Cj Malone wrote: > On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote: > > > > So in a nutshell, the topic of how to find things based on old > > sources is also very relevant for remote mappers. > > Technically there is survey:date and source:date that may be on the > object, or (preferred now?) the changeset. So a quality assurance tool Adding such source tags to a changeset seldom makes sense. Most of my changesets are a mixture of local knowledge, surveys, gps, photographic and video. I even occasionally use satellite imagery... So the source data needs to be fine grained on the elements themselves. Furthermore, when updating an element, I can see any source tags right there. I am not normally going to all the faff of looking up the history, finding the changesets and consulting those except for unusual cases. Of course, changesets need to have some overall source infomation, but that is necessarily coarse except for small cahnges perhaps. ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote: > If the date + *source* of the last change made on (the geometry of > an) element was readily available, through the API or another meta- > tag (source=bing, anyone? ;-) ), this would help to identify areas > that should be updated because a new more current and/or detailed > source became available. > > In Hamburg, we are lucky that the public authority provides us with > really detailed up-to-date satellite imagery that are far beyond bing > but there is no easy way to see which buildings and road geometries > have still been mapped on the basis of bing and which are already > using the better source. > > So in a nutshell, the topic of how to find things based on old > sources is also very relevant for remote mappers. Technically there is survey:date and source:date that may be on the object, or (preferred now?) the changeset. So a quality assurance tool could check that, however in practice they aren't nearly in use enough, (editors using them by default would help), and there often isn't a date attached to satellite imagery. I also think they'd have to do multiple api calls to work it out, so it could definitely be streamlined with a new api endpoint. Cj ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Hi Tobias, I've been giving this some thought. My conclusion is that user validation of tags shouldn't be stored in the same database table as the tags themselves. It's clear that as the map data ages, tag validation is going to be a task with parallel and equal importance to tagging itself, but with its own workflows and complexities. The validation will have its own history separate from the tagging history, and I believe it would be best to design the data model accordingly. Using nodes as an example for the moment, I'd like to consider the creation of a new table alongside node_tags, perhaps called node_tag_validation. I imagine the fields would be: - node_id - user_id - tag key - current node version (to identify the current tag value being validated -- or maybe just a copy of the current tag value, if that's too cumbersome) - validation result (valid/invalid/unsure) - optional comment - timestamp This would allow a map validator to: - confirm a tag or subset of tags, rather than the state of the entire element - record agreement without updating the element - record unverifiability/disagreement/skepticism without changing or deleting a tag (since sometimes there's middle ground between confirming a certain tag and knowing that it's incorrect.) - weigh in on the validity/invalidity of the *absence* of a particular tag, which can be just as important as evaluating the tags that are there. It would also allow easy query of various users' judgement of a particular tag over time, which would allow for more informed survey and QA. This design would eliminate some of the potential problems that have come up in this thread: - check date tags getting out of sync with tag values - overcrowding elements with check date tags, and the verifiability of these tags (the validation history can have looser verifiability requirements than the map data) - resistance to changesets that make no actual changes but simply update a timestamp (and increment the version) to indicate new validation - debate over correct implementation of namespaces (eg check_date:smoothness or smoothness:check_date) Note that this table (or these tables, presuming one each for node/way/relation) would not actually need to reside in the OSM database itself, although that would make it easier if the goal were to share among multiple QA projects, not just StreetComplete. Thanks for your work! Jason ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
> I think it would help with community acceptance of a potentially large > number of meta tags if you're somewhat frugal when it comes to adding > new ones. [...] > > In practice, this could mean ... > > * ... not adding key:check_date when the key is first added, or when the > value is changed as opposed to confirmed. (But update check_date tags > that already exist on the object, of course.) > * ... only using check_date where regular re-survey is plausible and > useful. This ties in with your observations on re-check intervals. For > example, there should be an opening_hours:check_date, but probably no > building:levels:check_date. I think the same. Basically, I only brought this up as a question directed at the mailing list at all because in the linked github issue [1] someone argued for always adding a check_date. He makes some good points [1], also regarding the reliability of the "timestamp" (last date changed) attribute of an element. But so far, the voices here on the mailing list were mostly arguing for frugal use of such meta-tags, so if no other voices that make a conclusive point for being less frugal with such meta tags come up, I will take the measures that you mentioned. [1] https://github.com/westnordost/StreetComplete/issues/1836 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
> adding check timestamps as string tags for every single tag seems a lot of > bloat. One tag per object for me would be acceptable because it is indeed a > valuable information when something was last verified and no changes were > necessary. Definitely it has the potential for that. And as Mateusz noted in another branch, check_date tags themselves could become out-of-date if successive editors do not update the tag together with the tag it refers to. On the other hand, at least at this time I do not see the danger of this [=every single tag is accompanied by a meta-tag] happening, neither through individual usage of such meta tags nor by being set by StreetComplete automatically because only a small fraction of tags are likely to change in a timeframe of some years or below. In other words, only for a small fraction of tags it makes sense to attach a check_date to. A good example of things that change more frequently would be smoothness or opening hours. For example one surveyor may check on-site the smoothness and surface of a road, but not check if the width is still correct because he doesn't have anything with him to measure it. Also, he doesn't want to check if the speed limit is still correct because that would require him to go up the road at least until the next big intersection to find a speed limit sign (or not). He may also not want to check whether all(?!) the bus routes are still correct. Generally, some information tagged on an element is also not verifiable on-site. What this example should illustrate is that it is illusory to assume that a mapper is both able and willing to check everything at once for a certain element. (Basically, StreetComplete is founded on the idea that surveyors don't have to tag and check "everything" at once for any given element but add/update the information bit by bit.) --- On the topic of map maintenance, there is another information that is currently missing (from the API) which would be helpful to maintain an up-to-date map. It is a bit off topic because this topic is mostly about StreetComplete / on-site map maintenance but I would like to still touch on it shortly: If the date + *source* of the last change made on (the geometry of an) element was readily available, through the API or another meta-tag (source=bing, anyone? ;-) ), this would help to identify areas that should be updated because a new more current and/or detailed source became available. In Hamburg, we are lucky that the public authority provides us with really detailed up-to-date satellite imagery that are far beyond bing but there is no easy way to see which buildings and road geometries have still been mapped on the basis of bing and which are already using the better source. So in a nutshell, the topic of how to find things based on old sources is also very relevant for remote mappers. Cheers Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Thanks! > Secondly, I think having to evaluate the history is a challenge. But do > you have to? No, I don't have to, thanks to such tags as check_date. But then again, check_date, survey:date etc. only came to be invented because API support was missing. It would be better to have somthing like that in the API itself. I would welcome it. > In comparable cases (non-OSM, but comparible checking schemes), I do not > record the date it has been checked, I record the future date when it > should be checked (again). Interesting approach, but what tag do you use for that? It sounds like you use check_date for that, but check_date is documented as "The tag is intended to document the last date, when an object as a whole or specific tags of the object were checked and verified". Cheers Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
> It is completely possible to add this functionality to the API in a > backwards compatible fashion, at the cost of a long per tag in the > current table (assuming that we don't need the information for historic > object versions, so at a reasonable cost space wise. There are a couple > of semantic issues that need to be considered but definitely not rocket > science. Where the big effort is likely adapting the internal tools > (database dumps etc), cgi-map and in the end migrating the database. > > If I can find some time over the next months I might prototype this, but > if somebody can do it earlier pls be my guest. I am happy that through this topic, the topic of API support for recording and getting the last checked date gained traction (again). We,... well, we probably could, but we shouldn't always rely on tags like check_date etc.. As Mateusz Konieczny rightfully noted in another branch, meta-tags as opposed to API support has the potential to become out of date if successive editors forget to update the check_date tag when they update the object or tag it is referring to. So, all the more I say it is pretty awesome that you plan to conceive a plan for this. Whatever comes out of it, in any case thank you for taking an initiative, Simon! Such a feature would also open up much more room for comprehensive analyzing and QA tools focussed on map maintenance, a topic that is or at least is becoming more and more important in my opinion. The endorsements there were so far for the map maintenance in StreetComplete indicate that the topic has become to take precedence in the minds of many mappers, also of those usually not that involved in discussions in the established channels. Regarding changes to the API, it would then probably look like this? Thinking a little bit about it, it would not be a 1:1 replacement of some_tag:check_date=2019-09-04 because check_date is usually used for when something has been checked on-site (survey). A timestamp on a tag just records "a" change. That could have been a mechanical edit, like for example the recent change of http:// urls to https:// urls where possible. Though I guess this would be good enough, it may be worth a thought whether to also include the source field of the linked changeset in the tag xml. I reckon a difficulty for implementing something like this would be the issue of "touching" elements in order to update their timestamp. I think this may be possible already with the current API, but what is really missing would be the possibility to "touch" certain tags only - only the tags that one checked but didn't change because there was no change required. Cheers Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Am 25.07.2020 um 03:45 schrieb Jarek Piórkowski: > > 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. > No this wouldn't be useful, because what you -actually- want is the information when the tags have stayed the same, because they have validated/surveyed, by definition this cannot be determined from historic objects. It is completely possible to add this functionality to the API in a backwards compatible fashion, at the cost of a long per tag in the current table (assuming that we don't need the information for historic object versions, so at a reasonable cost space wise. There are a couple of semantic issues that need to be considered but definitely not rocket science. Where the big effort is likely adapting the internal tools (database dumps etc), cgi-map and in the end migrating the database. If I can find some time over the next months I might prototype this, but if somebody can do it earlier pls be my guest. Simon PS: we just had this discussion on tagging btw in case nobody noticed. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Fri, 24 Jul 2020 at 21:28, Jmapb 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. --Jarek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
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. The history API will only tell you when tags change. The tag validation from the wizard you described two posts above -- there's no way to record that validation. Except maybe to shoehorn it into the info tags on the changeset itself. My preference is to avoid updating a element if all info is complete and nothing has changed. I suppose a single datetime field for last survey might be workable, but I fear it will lead to giant bogus "survey" changesets changing nothing but the "last survey" field. I don't think the field would ultimately be trustworthy because it isn't verifiable. Jason ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Fri, 2020-07-24 at 17:48 -0500, Shawn K. Quinn wrote: > On 7/24/20 17:20, Cj Malone wrote: > > Alternatively if each storing when each tag has been validated is a > > direction OSM wants to go, maybe it should be in the API. A client > > like > > StreetComplete could "touch" a tag to rev it's edited timestamp > > without > > actually changing the value. > > 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. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On 7/24/20 17:20, Cj Malone wrote: > Alternatively if each storing when each tag has been validated is a > direction OSM wants to go, maybe it should be in the API. A client like > StreetComplete could "touch" a tag to rev it's edited timestamp without > actually changing the value. 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. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On Fri, 2020-07-24 at 16:13 +0100, Jez Nicholson wrote: > There must have been a long discussion on this, and I don't want to > rehash it, but i'm surprised there was a positive response to adding > check_date for individual attributesI can understand a check_date > for a whole feature (as with the construction site), so for example a > bus stop, I might be asked to check all the attributes (is there a > seat? is there a bin? is there still a shelter?) and flag the whole > bus stop as 'checked'. > Could StreetComplete quests be built for confirming all attributes of > an object, or are they limited to one (and hence your need to flag > individual attribute checked dates)? +1 Doubling (or near enough) the amount of tags on a given nwr seems a bit excessive. StreetComplete could do a kind of wizard where is shows each tag and asks the user to validate it, and only once all the tags are shown to the user is an nwr considered confirmed, and adds a tag to say it was surveyed or checked. Alternatively if each storing when each tag has been validated is a direction OSM wants to go, maybe it should be in the API. A client like StreetComplete could "touch" a tag to rev it's edited timestamp without actually changing the value. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
OpenStreetMap is a shared database - you generally shouldn’t annotate POI with tags for your own use. Tags should correspond to ground truth - hence they need to pass the verifiability. If I resurvey the POI, will I conclude the same future todo_check_date=* that you have previously added? What if the tolerance between the two of us don’t match, and I conclude that it needs to be resurveyed in 1 year, while you would be sure that it needs to be resurveyed in 1 month? This sounds a bit like if we started adding fixme=update on everything, and that is something that we should avoid at all cost (everything is fixme and needs updating on OSM by definition). I think everyone should maintain their own todo list on their own devices and/or in some critical cases in the form of map notes if they need help from the community. Viewing from a different perspective: the choice of survey priority should be decided in situ locally by the mapper who has capacity to do regular verification. If people adding new POI overburden maintainers with too short deadlines, all POI will show up as expired. However, maintainers only have a finite amount of free time, so they will need to prioritize their mapping activities by the cost to benefit ratio. Hence they will probably sort by when a POI was last surveyed, rendering todo_check_date=* redundant at best. By the way, if a proper amount of people were actually using OSM data and their applications supported an easy feedback mechanism, such legwork would be obsolete. For example, if one navigates to a POI that they find closed, why couldn't they just report it? Or even better, couldn't we use data mining to get this information from their location and interaction traces as others do (subject to consent)? And on the positive side: when a user checks into a venue with their social application of choice (be it Diaspora or Friendica) or if the respective wifi network name shows up on a scan nearby, couldn't we consider these as affirming signs? On Fri, Jul 24, 2020 at 11:39 PM Peter Elderson wrote: > > Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr : >> >> On 24.07.20 14:13, Peter Elderson wrote: >> > In comparable cases (non-OSM, but comparible checking schemes), I do not >> > record the date it has been checked, I record the future date when it >> > should be checked (again). >> >> When it should be checked is opinion-based, though. > > > True, and the opinion is the user's opinion at the time of the survey. You > can suggest a default re-check date for the type of feature (might also be > empty) and leave it up to the user to accept or change that. > > >> >> The date when you last checked a shop's opening hours it is a fact. But >> opinions on how often one should revisit a shop to check the opening >> hours again may vary a lot between mappers. So I think the former is >> more suitable to be added to the OSM database. > > > It's a historic fact, but it doesn't drive any plan. > >> >> There are some comparatively rare cases where you know in advance that >> something will change (e.g. with construction that is scheduled to be >> finished by a particular date), but imo that's more the domain of >> opening_date or temporary tags. >> >> > The routine is then, ask if check_date is absent OR when the current >> > date is past the check_date. >> >> I don't think this is a big benefit compared to "... OR when the current >> date is X months past the check_date". > > > I think you are thinking code in the app, not maintaining a bunch of features > such as 35000 routes or all the Stolpersteine in the area > > The difference is the determination of X. It's feature and opinion-dependent. > Checking/displaying due checks is very simple, and doesn't have to know > anything, just compare the tag with the date, and all pop up. > >> >> Also, I tend to prefer making software a little more complicated if it >> lightens mappers' manual workload, so making at least some use of >> history (e.g. so that no check_date needs to be set when a tag is first >> added) seems reasonable to me. > > > As a maintaining mapper, I would set the future check_date at entry time. > > Your plan sounds fine, but it will not be of much use to me. I still have to > maintain an agenda and listst for checks in the future. If a future check > mechanism were in place, I'd simply display a check map, just like a map > showing all notes or all fixme's. >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
sent from a phone > On 24. Jul 2020, at 22:53, Tobias Knerr wrote: > > The date when you last checked a shop's opening hours it is a fact. But > opinions on how often one should revisit a shop to check the opening > hours again may vary a lot between mappers. on the other hand the check date is already implicit (more or less) in the changeset timestamp. you probably wouldn’t add this kind of information months after the survey... adding check timestamps as string tags for every single tag seems a lot of bloat. One tag per object for me would be acceptable because it is indeed a valuable information when something was last verified and no changes were necessary. It could still lead to history bloat, imagine people verifying their housenumber every day. Technically it would be better to keep it separate (e.g. an additional table in the db without versions). I can’t see an issue with splits, as the newly created objects would have a more current date anyway. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On 7/24/20 15:51, Tobias Knerr wrote: > The date when you last checked a shop's opening hours it is a fact. But > opinions on how often one should revisit a shop to check the opening > hours again may vary a lot between mappers. So I think the former is > more suitable to be added to the OSM database. There are places that change their hours seasonally, and remove all traces of the off-season hours when they do. Laser Quest comes to mind; as I remember it they tied it to about when the local school year starts and ends, something not easy to do with opening_hours syntax as we now have it. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr : > On 24.07.20 14:13, Peter Elderson wrote: > > In comparable cases (non-OSM, but comparible checking schemes), I do not > > record the date it has been checked, I record the future date when it > > should be checked (again). > > When it should be checked is opinion-based, though. > True, and the opinion is the user's opinion at the time of the survey. You can suggest a default re-check date for the type of feature (might also be empty) and leave it up to the user to accept or change that. > The date when you last checked a shop's opening hours it is a fact. But > opinions on how often one should revisit a shop to check the opening > hours again may vary a lot between mappers. So I think the former is > more suitable to be added to the OSM database. > It's a historic fact, but it doesn't drive any plan. > There are some comparatively rare cases where you know in advance that > something will change (e.g. with construction that is scheduled to be > finished by a particular date), but imo that's more the domain of > opening_date or temporary tags. > > > The routine is then, ask if check_date is absent OR when the current > > date is past the check_date. > > I don't think this is a big benefit compared to "... OR when the current > date is X months past the check_date". > I think you are thinking code in the app, not maintaining a bunch of features such as 35000 routes or all the Stolpersteine in the area The difference is the determination of X. It's feature and opinion-dependent. Checking/displaying due checks is very simple, and doesn't have to know anything, just compare the tag with the date, and all pop up. > Also, I tend to prefer making software a little more complicated if it > lightens mappers' manual workload, so making at least some use of > history (e.g. so that no check_date needs to be set when a tag is first > added) seems reasonable to me. > As a maintaining mapper, I would set the future check_date at entry time. Your plan sounds fine, but it will not be of much use to me. I still have to maintain an agenda and listst for checks in the future. If a future check mechanism were in place, I'd simply display a check map, just like a map showing all notes or all fixme's. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Hi Tobias, congratulations on your successful microgrant proposal! :) Maintenance of existing data is a growing concern as OSM matures, so it's important that we explore workflows for it. On 23.07.20 18:06, Tobias Zwick wrote: > 2. Always record check_date or avoid tagging it where not absolutely > necessary? I think it would help with community acceptance of a potentially large number of meta tags if you're somewhat frugal when it comes to adding new ones. There is some cost in mappers feeling obligated to update a "companion tag" every time they update a regular tag, as well as in visual clutter. These downsides will both be lessened with better tooling, but as of today that isn't widely available yet. In practice, this could mean ... * ... not adding key:check_date when the key is first added, or when the value is changed as opposed to confirmed. (But update check_date tags that already exist on the object, of course.) * ... only using check_date where regular re-survey is plausible and useful. This ties in with your observations on re-check intervals. For example, there should be an opening_hours:check_date, but probably no building:levels:check_date. I don't have any strong opinions on this, and you seem to have given this a lot of thought already. Just adding my gut feeling to the wisdom of the crowd here. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
On 24.07.20 14:13, Peter Elderson wrote: > In comparable cases (non-OSM, but comparible checking schemes), I do not > record the date it has been checked, I record the future date when it > should be checked (again). When it should be checked is opinion-based, though. The date when you last checked a shop's opening hours it is a fact. But opinions on how often one should revisit a shop to check the opening hours again may vary a lot between mappers. So I think the former is more suitable to be added to the OSM database. There are some comparatively rare cases where you know in advance that something will change (e.g. with construction that is scheduled to be finished by a particular date), but imo that's more the domain of opening_date or temporary tags. > The routine is then, ask if check_date is absent OR when the current > date is past the check_date. I don't think this is a big benefit compared to "... OR when the current date is X months past the check_date". Also, I tend to prefer making software a little more complicated if it lightens mappers' manual workload, so making at least some use of history (e.g. so that no check_date needs to be set when a tag is first added) seems reasonable to me. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
There must have been a long discussion on this, and I don't want to rehash it, but i'm surprised there was a positive response to adding check_date for individual attributesI can understand a check_date for a whole feature (as with the construction site), so for example a bus stop, I might be asked to check all the attributes (is there a seat? is there a bin? is there still a shelter?) and flag the whole bus stop as 'checked'. Could StreetComplete quests be built for confirming all attributes of an object, or are they limited to one (and hence your need to flag individual attribute checked dates)? On Fri, Jul 24, 2020 at 1:16 PM Peter Elderson wrote: > Firstly, I think this kind of application is very important for the > maintenance of the map. The thing has become too complicated for regular > people. So, kudo's! > > Secondly, I think having to evaluate the history is a challenge. But do > you have to? > In comparable cases (non-OSM, but comparible checking schemes), I do not > record the date it has been checked, I record the future date when it > should be checked (again). > > The routine is then, ask if check_date is absent OR when the current date > is past the check_date. > > You can vary check_date according to the feature. You could ask the user > to confirm the suggested future check_date or enter a better one. > > Easy overpass queries can find objects past the check_date. Easy maps can > show objects past the check_date. It's all much simpler than searching > possibly complex history. > > Vr gr Peter Elderson > > > Op do 23 jul. 2020 om 18:08 schreef Tobias Zwick : > >> Hello everyone >> >> As you may or may not know, my microgrant proposal "Map maintenance with >> StreetComplete" [1] was selected to be funded by the OSMF. So, I am >> happy to have the oppurtunity to invest the time extending the app, >> hoping that it will help to keep the map up-to-date and unburden people >> and communities invested in that topic. >> >> I am pitching this here because there are three details on which I would >> like to hear your input. Two of these are about tagging. >> >> But first, how will it work? >> >> >> So, what StreetComplete will do is to scan the map for whether certain >> properties (tags) of map features haven't been surveyed for a certain >> time. If this is the case, users will be prompted to answer the question >> for that property again. For example, if the app ascertained that the >> smoothness of a road hasn't been changed for 5 years, it would ask users >> again about the smoothness of the road. >> >> Challenges >> -- >> >> Now, you might imagine that this is not so straightforward to implement, >> and you would be right, for several reasons: >> >> Firstly, the OSM API has no notion about when a particular property of >> an element has last been changed, only for when the whole element has >> last been changed. But elements are changed all the time for various >> reasons. Roads for example tend to be changed especially often, splitted >> up to accomodate bus routes, turn restrictions, when detailing >> intersections, etc. >> >> Secondly, there is only the date of the last change, but that doesn't >> mean that is the date of the last survey. Even though that would be the >> information we are interested in: when has the element last been checked >> on-site? >> >> Thirdly, the OSM API does not offer users to record solely that they >> checked something and that it is still up to date. Any new record in OSM >> must always come with a tagging change. >> >> Solutions >> - >> >> In the absence of direct API support, fortunately the community came up >> with a solution: Add the check_date tag to the element that has been >> checked on a survey - or with the namespace if it concerns only a >> certain tag of a map feature. >> >> This works well and is actually already used by Streetcomplete in the >> "Is this construction site finished?"-quest: >> If the element as a whole hasn't been changed for 6 months *or* the >> check_date key is present and its value is older than 6 months, the >> quest is eligible to be asked again. When the user answers the question, >> the check_date is set to current date. >> >> Your input >> == >> >> Now here is where I would like your input: >> >> 1. Use check_date:smoothness or smoothness:check_date? >> -- >> check_date with a namespace isn't used all that often yet, both variants >> are used and thus there is no real winner yet. What variant do you >> prefer and why? And most importantly, which variant would be most >> consistent with existing tagging practices? >> >> 2. Always record check_date or avoid tagging it where not absolutely >> necessary? >> >> --- >> If something is resurveyed and it is acknowledged that nothing changed, >> it is absolutely necessary to tag check_date.
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Firstly, I think this kind of application is very important for the maintenance of the map. The thing has become too complicated for regular people. So, kudo's! Secondly, I think having to evaluate the history is a challenge. But do you have to? In comparable cases (non-OSM, but comparible checking schemes), I do not record the date it has been checked, I record the future date when it should be checked (again). The routine is then, ask if check_date is absent OR when the current date is past the check_date. You can vary check_date according to the feature. You could ask the user to confirm the suggested future check_date or enter a better one. Easy overpass queries can find objects past the check_date. Easy maps can show objects past the check_date. It's all much simpler than searching possibly complex history. Vr gr Peter Elderson Op do 23 jul. 2020 om 18:08 schreef Tobias Zwick : > Hello everyone > > As you may or may not know, my microgrant proposal "Map maintenance with > StreetComplete" [1] was selected to be funded by the OSMF. So, I am > happy to have the oppurtunity to invest the time extending the app, > hoping that it will help to keep the map up-to-date and unburden people > and communities invested in that topic. > > I am pitching this here because there are three details on which I would > like to hear your input. Two of these are about tagging. > > But first, how will it work? > > > So, what StreetComplete will do is to scan the map for whether certain > properties (tags) of map features haven't been surveyed for a certain > time. If this is the case, users will be prompted to answer the question > for that property again. For example, if the app ascertained that the > smoothness of a road hasn't been changed for 5 years, it would ask users > again about the smoothness of the road. > > Challenges > -- > > Now, you might imagine that this is not so straightforward to implement, > and you would be right, for several reasons: > > Firstly, the OSM API has no notion about when a particular property of > an element has last been changed, only for when the whole element has > last been changed. But elements are changed all the time for various > reasons. Roads for example tend to be changed especially often, splitted > up to accomodate bus routes, turn restrictions, when detailing > intersections, etc. > > Secondly, there is only the date of the last change, but that doesn't > mean that is the date of the last survey. Even though that would be the > information we are interested in: when has the element last been checked > on-site? > > Thirdly, the OSM API does not offer users to record solely that they > checked something and that it is still up to date. Any new record in OSM > must always come with a tagging change. > > Solutions > - > > In the absence of direct API support, fortunately the community came up > with a solution: Add the check_date tag to the element that has been > checked on a survey - or with the namespace if it concerns only a > certain tag of a map feature. > > This works well and is actually already used by Streetcomplete in the > "Is this construction site finished?"-quest: > If the element as a whole hasn't been changed for 6 months *or* the > check_date key is present and its value is older than 6 months, the > quest is eligible to be asked again. When the user answers the question, > the check_date is set to current date. > > Your input > == > > Now here is where I would like your input: > > 1. Use check_date:smoothness or smoothness:check_date? > -- > check_date with a namespace isn't used all that often yet, both variants > are used and thus there is no real winner yet. What variant do you > prefer and why? And most importantly, which variant would be most > consistent with existing tagging practices? > > 2. Always record check_date or avoid tagging it where not absolutely > necessary? > > --- > If something is resurveyed and it is acknowledged that nothing changed, > it is absolutely necessary to tag check_date. If something changed, it > is not strictly necessary because that the element changed as a whole is > itself also recorded. > But as already mentioned, elements can and do change all the time. One > can not assume that if an element has been changed that it has been > checked on-site. And even if one could, maybe not all the things were > checked but for example only the bus route relation, or maybe only the > presence of a sidewalk, or someone made the way a little more detailed etc. > > The topic whether StreetComplete should only tag the minimum of what is > necessary to ensure functionality or always tag check_date (at least for > properties that are eligible for re-survey) was already subject to > discussion in the issue tracker here: >
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
Jul 23, 2020, 18:06 by o...@westnordost.de: > 1. Use check_date:smoothness or smoothness:check_date? > Both have some benefits, I am perfectly fine with both variants. One gets check_date tags out of the way, one keeps tag and its check date close to each other. In case of tie second seems slightly preferable. EDIT: surface:check_date would reduce risk of it getting out of sync, it seems preferable to me, but check_date:surface also seems fine > 2. Always record check_date or avoid tagging it where not absolutely > necessary? > Slight preference toward "avoid". It is useful/necessary in some cases, but if it possible to avoid it then it should be avoided. In the same way as note/description is not used to record note="this is perfectly normal segment of motorway, nothing special here" > Maybe it is obvious that my opinion is that StreetComplete should always > tag check_date as it also adds valuable information for other surveyors > that do not use StreetComplete. Nevertheless, in the GitHub ticket > linked above, I played a bit of a devils advocate for the other point of > view - for being frugal with such meta-tags. > I see no big benefit, and it could double list of tags on objects. In general, I imagine ideal StreetComplete behavior as mimicking what human would do, without requiring human to be aware of tags, tagging schemes and how OSM data us structured. Note that in case of changed tags other mappers can look at object history and see when tag was changed (note, I use JOSM with great history window - though in iD such extra tags would be hidden anyay). Note that unlike changeset history such tags may get out of sync, for example as result of iD mapper editing and not being aware of them. So relying on object history seems preferable whenever possible. > So, I'd like to collect what are the advantages and drawabacks of adding > check_date to all the tags surveyed on-site, with your help. > advantages: (1) survives way splits disadvantages: (1) iD mappers will edits tags without updating check date, JOSM/Vespuci mappers may decide to not update them (2) more cruft in tag list (3) StreetComplete behaves unusually, and produces unusual tagging Adding *:check_date because something was resurveyed makes sense and such resurvey is a great idea, but even that is unusual. I think that *:check_date for every single added tag is an overkill. > Long story short, not all quests [2] would be eligible for re-survey and > those who are will have different intervals, partly also based on how > they are tagged now. I could use your input on how long these intervals > should be. The issue was already discussed in a GitHub ticket [3], but > now prepared a wiki page here in which further discussion could take place: > > https://wiki.openstreetmap.org/wiki/User:Westnordost/Proposed_Resurvey_Intervals > I would convert it to sections, table is a bit confusing to edit. And maybe move to talk page to make clear that random comments are welcomed. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging
This should be more applicable in case the person walked by the said object in person: https://wiki.openstreetmap.org/wiki/Key:survey:date Also, I'd like to stay neutral in this question as of now, but I think it would be possible to implement heuristic algorithms to reconstruct the history of a way even if it was split and to walk backwards on changesets to check where "survey" was also mentioned as a "source". We had a talk about just this on our local list some years ago. A little preprocessing could go a long way, and such data structures could be generated weekly or even less often - as the issue itself is that a long time has already passed since the said objects were updated. There's no need to extend the API just for this. On Thu, Jul 23, 2020 at 6:08 PM Tobias Zwick wrote: > > Hello everyone > > As you may or may not know, my microgrant proposal "Map maintenance with > StreetComplete" [1] was selected to be funded by the OSMF. So, I am > happy to have the oppurtunity to invest the time extending the app, > hoping that it will help to keep the map up-to-date and unburden people > and communities invested in that topic. > > I am pitching this here because there are three details on which I would > like to hear your input. Two of these are about tagging. > > But first, how will it work? > > > So, what StreetComplete will do is to scan the map for whether certain > properties (tags) of map features haven't been surveyed for a certain > time. If this is the case, users will be prompted to answer the question > for that property again. For example, if the app ascertained that the > smoothness of a road hasn't been changed for 5 years, it would ask users > again about the smoothness of the road. > > Challenges > -- > > Now, you might imagine that this is not so straightforward to implement, > and you would be right, for several reasons: > > Firstly, the OSM API has no notion about when a particular property of > an element has last been changed, only for when the whole element has > last been changed. But elements are changed all the time for various > reasons. Roads for example tend to be changed especially often, splitted > up to accomodate bus routes, turn restrictions, when detailing > intersections, etc. > > Secondly, there is only the date of the last change, but that doesn't > mean that is the date of the last survey. Even though that would be the > information we are interested in: when has the element last been checked > on-site? > > Thirdly, the OSM API does not offer users to record solely that they > checked something and that it is still up to date. Any new record in OSM > must always come with a tagging change. > > Solutions > - > > In the absence of direct API support, fortunately the community came up > with a solution: Add the check_date tag to the element that has been > checked on a survey - or with the namespace if it concerns only a > certain tag of a map feature. > > This works well and is actually already used by Streetcomplete in the > "Is this construction site finished?"-quest: > If the element as a whole hasn't been changed for 6 months *or* the > check_date key is present and its value is older than 6 months, the > quest is eligible to be asked again. When the user answers the question, > the check_date is set to current date. > > Your input > == > > Now here is where I would like your input: > > 1. Use check_date:smoothness or smoothness:check_date? > -- > check_date with a namespace isn't used all that often yet, both variants > are used and thus there is no real winner yet. What variant do you > prefer and why? And most importantly, which variant would be most > consistent with existing tagging practices? > > 2. Always record check_date or avoid tagging it where not absolutely > necessary? > --- > If something is resurveyed and it is acknowledged that nothing changed, > it is absolutely necessary to tag check_date. If something changed, it > is not strictly necessary because that the element changed as a whole is > itself also recorded. > But as already mentioned, elements can and do change all the time. One > can not assume that if an element has been changed that it has been > checked on-site. And even if one could, maybe not all the things were > checked but for example only the bus route relation, or maybe only the > presence of a sidewalk, or someone made the way a little more detailed etc. > > The topic whether StreetComplete should only tag the minimum of what is > necessary to ensure functionality or always tag check_date (at least for > properties that are eligible for re-survey) was already subject to > discussion in the issue tracker here: > https://github.com/westnordost/StreetComplete/issues/1836 > > Maybe it is obvious that my opinion is that StreetComplete should always > tag
