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 <o...@westnordost.de>: > 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 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. > > 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. > > 3. At what intervals should questions be asked? > ----------------------------------------------- > Certain properties can be expected to usually not change in tangible > amount of time. For example, properties such as the structure of a > bridge, the levels and roof shape of buildings, street names and > housenumbers don't or change so infrequently that it is not worth > sending users every once in a blue moon to re-check the data. Others > will change more frequently, such as the smoothness of roads and ways or > anything related to businesses as they close and other shops open in > their place. Sometimes, it is also dependent on how it is currently > tagged whether it is likely that it changes within a number of years: If > a road already has a paved surface such as asphalt, it is less likely to > change than if it was just a compacted road. Same with facilities for > the blind or other things that "upgrade" infrastructure. The issue was > already d > > 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 > > ----- > > So, that's all for now. Looking forward to read your constructive input! > > Cheers > Tobias > > [1] > > https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Map_Maintenance_with_StreetComplete > [2] https://wiki.openstreetmap.org/wiki/StreetComplete/Quests > [3] https://github.com/westnordost/StreetComplete/issues/1766 > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
