[Tagging] Map maintenance with StreetComplete - Preferred tagging

Peter Elderson pelderson at gmail.com
Fri Jul 24 12:13:54 UTC 2020


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200724/c8960f25/attachment-0001.htm>


More information about the Tagging mailing list