[Tagging] Map maintenance with StreetComplete - Preferred tagging

Fri Jul 24 15:13:40 UTC 2020

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 attributes....I 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 <pelderson at gmail.com> 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 <osm at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200724/937a3f8c/attachment.htm>