Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map Maintenance with StreetComplete #1998

Closed
westnordost opened this issue Aug 5, 2020 · 46 comments · Fixed by #2060
Closed

Map Maintenance with StreetComplete #1998

westnordost opened this issue Aug 5, 2020 · 46 comments · Fixed by #2060

Comments

@westnordost
Copy link
Member

westnordost commented Aug 5, 2020

This ticket shall serve as a FAQ and discussion hub for what is implemented for the feature Map Maintenance with StreetComplete.

None of the below is set in stone yet.

Any information your are missing here?

Project information

Time Frame

It is aimed to go live with this feature by the end of August 2020 but no guarantee.

Milestones

  1. ✅ (~1 week:) Extend StreetComplete's own (overpass-wizard-like) element filter syntax to enable to write queries like
    nodes, ways with opening_hours older 1.5 years
    and implement transpilation to OverpassQL. Further, provide utility functions to handle understanding and updating the check_date tags. (Feedback on the syntax is welcome)
  2. ✅ (~1 week:) Changing the queries of all the eligible quest types to be resurveyed every X years/months and changing the implementation to set the correct check_date tags where applicable. (See Proposed Resurvey Intervals)
  3. ✅ (~2 days:) Add and respect option in the settings
  4. 👨‍💻(variable) Testing
  5. ✅ (if enough time: ) finish and merge resurveying opening hours pull-request by @matkoniecz
  6. ✅(if enough time: ) Also build a quest specifically for for cycleway infrastructure that display the previously selected value because these two are the quest types that take most time to answer (~10 taps for collection times, ~5 taps for cycleway infrastructure)

FAQ

How will the things be marked as surveyed?

If the thing (f.e. opening hours) has changed, then simply the new opening hours will be tagged and nothing else. After discussion on the tagging mailing list, many people expressed the preference of not adding more tags that are absolutely necessary to support a re-survey like this.

If the thing hasn't changed, check_date:[key]=[current date] (f.e. check_date:opening_hours=2020-08-05) will be used to mark the opening hours as checked at that date.
On the mentioned discussion on the mailing list, there was a slight preference towards [key]:check_date because it is displayed right next to the key it references to so it is more likely people will keep it up to date. However, later during implementation, I noticed that [key]:check_date could collide with other : namespaces and thus make it more difficult or introduce bugs for other software. So, not a problem for humans to understand, but for software, for example: recycling:check_date (= you can recycle check_dates here?), cycleway:check_date (= a cycleway on the "check_date" side?)

While StreetComplete will set the mentioned tag, it will also understand and correctly process at least check_date:[key], lastcheck:[key] and [key]:lastcheck. Other "this has been surveyed at..." tags don't seem to be used much on a per-tag level.

As an outlook, all those "this has been surveyed at..." tags may become obsolete if the OSM database and API is extended to include this information in the metadata. When this happens, StreetComplete will also be extended to use this metadata in the future rather than the tags.

What are the intervals in which quests are asked again? For which quests is it enabled?

This will depend on the quest type. Only a fraction of quest types is eligible to be asked again. Housenumbers and building types for example are never asked again. Those that are are sorted into categories like "related to a business" and those categories are assigned rough average life times on which the intervals are based.

Also, specifically the maxspeed quest, will not be asked again, explanation here: #1998 (comment)

You can contribute to finding the best intervals by writing your experience and making suggestions here: Proposed Resurvey Intervals

Also, you will be able to select in the settings to be asked less (/2) or to be asked more often (x2) about resurvey.

Will resurvey-quests be specially indicated in any way on the map?

No.

This would be substantially more effort while I do not see any useful use case for it.

The user doesn't need to know whether he is contributing new information or updating information. I reckon there might be the notion that it is better to first "complete" the map and then proceed to maintaining it, maybe because of the fear that there may be too few contributors to be able to complete the map when one cannot keep up maintaining it.
The case against this notion is exactly what I wrote in the last sentence actually: If there are not enough people who can maintain the map up-to-date at the current level of detail, then adding even more details will make it even worse. When is the Wikipedia complete? We have to live with the fact that there will always be something new that could be added to the map, our limit is (only) our manpower and our ability to maintain it.

Someone in the forum, I forgot who, had a memorable signature, it went something like

On the tombstone of OSM, there will be written "because more was never enough"

If one contributes volatile information (f.e. opening hours), it goes without saying that its value deteriorates over time and must be refreshed regularly. It is up to each individual to decide if he or she wants to contribute this kind of information and subsequently also be asked to refresh it or not, it is possible to disable certain quest types in the settings.

Will the resurvey-intervals be shown in the app per quest type?

Probably not. It wouldn't be much effort, but then again I see no reason to expose such information to the users in the app, especially if they have no way of seeing whether a quest they are answering is a re-survey quest or not.
I think this is information that may well go into the wiki.

How will the interface for resurvey quest look like?

In most cases, the interface will be exactly the same as if the question has never been answered before. In most cases, the user will not be asked first if the thing (for example, "Is the surface of this road still asphalt?") is still correct and if not, be prompted to select the new value in a second step. There are several reasons for that:

  1. It would be substantially more implementation effort: StreetComplete would need to know which (set of) tags maps to which UI option and would need to be able to present this to the user for all the quest types
  2. It would be substantially more effort for translators because possibly every quest that can be resurveyed needs to have additional strings
  3. Of the 36 quests that are eligible for re-survey, 18 are already solvable with one tap (yes/no), and 14 are with ~two taps (select image and tap ok, or insert a number and enter). For these (88%), it might actually even be a slight hinderance if first a dialog that asks whether information X is still correct is shown because it adds one tap in case the data did change.
  4. For the remaining 4 quest types (cycleway, max speed, postbox collection times, opening hours) that have a more complex form, it might indeed be an improvement to first ask if the current data is up-to-date. Especially for opening hours, as it is by far the most complex form. This is why @matkoniecz started implementing it in resurveying opening hours #1676 which I aim to finish. If there is time, I will also do the same for postbox collection times and cycleways. For max speed it is not planned because it is by default disabled.
@westnordost westnordost pinned this issue Aug 5, 2020
@cyclingcat

This comment has been minimized.

@westnordost

This comment has been minimized.

@peternewman

This comment has been minimized.

@westnordost

This comment has been minimized.

@westnordost

This comment has been minimized.

@westnordost
Copy link
Member Author

westnordost commented Aug 10, 2020

Extended element filter syntax

I generified the syntax a bit. Following queries are now valid:

  • nodes with opening_date > today - opening_date tag value is in the future
  • nodes with check_date <= 2011-11-11 - check_date tag value is a date older than the given one
  • nodes with check_date >= 2011-11 - leaving the day out is fine too
  • nodes with check_date < today - 0.5 years - check_date tag value is older than half a year
  • nodes with surface newer today - 5 days - the tag surface has been checked within the last five days
  • nodes with smoothness older today - 4 weeks - the tag surface has not been checked for 4 weeks
  • nodes with surface older 2011-11-11 - the tag surface hasn't been checked at least since the given date
  • nodes with leisure = playground newer 2011-11-11 - the playground was changed after 2011-11-11
  • nodes with addr:housenumber older today -2 years - the housenumber node was not changed for at least 2 years

I wanted to use the same date / relative date format for both the comparison operator (check_date < ...) and for the older/newer operator (opening_hours older ...). So the syntax of this is now either a fixed date 2000-10-10 or a relative date from today today + 2 weeks. So this syntax is the most flexible but not the best readable. Still I think it is better to have one consistent syntax than to adapt the syntax depending on where it is used and/or adapt it too much to English language (6 days ago / in 6 days / today vs today +/- 6 days).

@westnordost
Copy link
Member Author

westnordost commented Aug 14, 2020

Status update

Untested, but most quests that should be resurveyable are now implemented.

However, from the original list in the wiki, I removed AddBikeParkingType, AddBenchBackrest and AddCrossingType because these will usually only change if the whole object is removed or replaced. So it would be better to have (in the future) quest types that specifically ask and only ask if "object x still here?". There are many more objects for which such a thing could be asked, like phone boxes, traffic lights, bins, benches, well, etc etc. But to enable that, StreetComplete would first need to learn how to remove elements so this is out of scope for now.

The remaining quests to do are AddRecyclingContainerMaterials, AddRailwayCrossingBarrier, AddOpeningHours (PR), AddCycleway, AddMaxSpeed and AddTactilePavingCrosswalk. For a few of them, there are some open questions:

  1. AddMaxSpeed: The question is which check_date tag to use for maxspeed, because sometimes maxspeed is not even tagged but just maxspeed:type. So if the tag the check_date refers to is missing, this might be problematic. StreetComplete itself also tags maxspeed:type but so far leaves alone any roads previously tagged with source:maxspeed and the other alternatives. Now as this value should be recorded not once but continuously in certain intervals, so the app needs to deal with previous values somehow. Should StreetComplete ...:
    1. never ask again and ignore roads tagged with anything else than maxspeed or maxspeed:type?
    2. ask again also for source:maxspeed etc. and update the tag to maxspeed:type?
    3. ask again also for source:maxspeed etc. but update whatever key there was before?
      Will not be implemented, see Map Maintenance with StreetComplete #1998 (comment)
  2. AddCyleway: Which check date key to use for this property - because almost always, several tags are changed. For example cycleway:left and cycleway:right and sometimes also cycleway:left:line and more. Maybe check_date:cycleway because what tags in the namespace exactly are used differ somewhat?
  3. AddRecyclingContainerMaterials: Same problem with this. There is not one tag updated, but a familiy of tags - recycling:paper = yes, recycling:plastic = no, ... - so, which check_date tag to use?

@matkoniecz
Copy link
Member

check_date:cycleway check_date:recycling seems fine to me.

ad maxspeed - all seem acceptable and all have different benefits

@kmpoppe

This comment has been minimized.

@westnordost

This comment has been minimized.

@westnordost

This comment has been minimized.

@westnordost
Copy link
Member Author

westnordost commented Aug 17, 2020

Here is a good reason for using check_date:recycling rather than recycling:check_date: It collides with the recycling:* namespace. "So you can recycle check_dates here?"

@kmpoppe
Copy link
Collaborator

kmpoppe commented Aug 17, 2020

Here is another good reason for using check_date:recycling rather than recycling:check_date: It collides with the recycling:* namespace. "So you can recycle check_dates here?"

Yep, I guess having check_date:* might work better and - I THINK - follows what the wiki says. I can follow the alphabetical order argumentation only slightly as it's just a thing of the data consumer. The database will not care.

@westnordost

This comment has been minimized.

@westnordost
Copy link
Member Author

westnordost commented Aug 19, 2020

No re-survey for maxspeed

Unfortunately, I will not make the maxspeed quest into a re-survey quest, even though this would be a very helpful and meaningful quest. Short explanation: It is impossible to implement a re-survey without creating conflict with tagging practices, because there are many competing ones, each locally established, but none globally. Also, none of the current tagging practices for implicit speed limits are actually eligible to be used globally.

Long explanation: The current tagging scheme(s), it is both very complex to do in order to be conservative with current tagging practices and even then, I don't see a way how it could be implemented without stirring conflict. I fear the current tagging schemes are gridlocked in a way where no software implementation that tries to handle and update the values can account for all the different ways how implicit speed limits are tagged. Point by point:

  1. (complexity) in order to not simply overwrite previous taggings with for example maxspeed:type, the app would need to understand and treat correctly all of source:maxspeed, maxspeed:type, zone:maxspeed, zone:traffic and depending on which tag is already set on the road, specifically update this value with the surveyed value.

  2. (complexity/conflict) moreover on point 1, it is only common to set sign as a value for source:maxspeed and maxspeed:type and not so for zone:maxspeed, zone:traffic, so it is not clear what to tag when the user selected that there is a speed limit sign now (maxspeed=40) and before there was none (tagged with zone:traffic=DE:urban or zone:maxspeed=DE:urban) to denote that the maxspeed is derived from an actual sign. Probably removing zone:traffic and replacing it with maxspeed:type=sign (but only if it was zone:traffic or zone:maxspeed, not if it was source:maxspeed etc) would be okay, but this is another chain of conditionals and it is unclear if mappers preferring zone:maxspeed over the others would be okay with that since each of those keys claim to reign supreme over implicit speed limit tagging.

  3. (conflict) source:maxspeed (etc.) being somewhat of a tag with a free-form value because obviously the legislation with its breakdown of roads into speed-limit-categories and the definitions theirof is different from country to country, state to state, overwriting existing values (such as the one given in the first link) with a standard pattern of [ISO-country code]:[urban/rural] (f.e. DE:rural) can already in itself lead to a loss of information. (There are less bizarre examples as given in the first link.) To do this correctly, the app would need to know every single road category of the legislation of every country in the world and know which tag to use for that (for example, US-WI:rustic_road, US-NJ:suburban_residential??). Obviously, these are not defined at all and as the author of an editor like StreetComplete, I do not have the authority to just make up some tags, nor would it make sense, because that tagging scheme is inherently jinxed.

  4. (complexity) In the rare case that before a road was tagged with a normal speed limit and now there is an advisory speed limit, each all the tags referring to the old limit must be removed. The same vice versa. Also, point 1 and 2 are of course also valid for advisory speed limits

  5. (complexity/conflict) Users can select that a road is actually signed as a living street, which changes the highway to living_street and doesn't tag any further maxspeed related tag because in a living street, it is clear that it is implicit. So when this answer is given in a re-survey, probably all maxspeed-related tags should be removed. But then, it might already have been tagged with for example maxspeed=walk (Germany) or maxspeed=20 (Russia), so removing this could upset people that the app is destroying information. On the other hand, if it doesn't remove the maxspeed information, there could likely be contradictory information. To solve this issue in a way that would be maximally wary in not removing any information (even if it can be derived implicitly), the app would need to know the currently valid speed limits for living streets in all countries in the world and not remove maxspeed if it is already set and equal to the speed limit known for living streets.

  6. (complexity/conflict) More on point 5 - unfortunately, this is not the end. Some people find it very important to tag source:maxspeed=RU:living_street on every highway=living_street (or living_street=yes). StreetComplete doesn't do that, which is fine for everyone, but it wouldn't be fine for everyone if the app removed this tag automatically when re-tagging to highway=living_street. This is of course also a rare case, because roads not tagged as highway=living_street (or living_street=yes) are not that likely to have that tag. On the other hand, for example in Russia, for certain roads ("courtyard roads"), the same speed limit as for living street applies without it being explicitly signed. So it might not be entirely rare.

  7. (conflict)

    1. A short introduction is inevitable: It used to be common practice to only tag maxspeed. source:maxspeed etc. were invented later to make it verifiable better where the maxspeed information is coming from and more future-proof in case the law changes the default speed limits. Now, many people tag only the source:maxspeed( or zone:maxspeed, etc) tag in case there is no sign because maxspeed is then a superfluous and potentially conflicting information which can be derived from the other tag. StreetComplete also tags like that. However, there are still evangelists for all three variants (only maxspeed, both, only source:maxspeed or another) around because there is no approved tagging scheme with a clear accepted recommendations anywhere, so everyone just does his own thing which seems to be fine as long as there are local consensuses on which method to use and no software dares to push any particular of the three.
    2. When StreetComplete starts to let users re-survey the speed limits and the user selects that there is no sign, thus an implicit speed limit applies, it will inevitably have to deal with previously tagged implicit speed limits (of all three possible variants). So, if StreetComplete would in that case remove the explicitly tagged maxspeed, it will upset people that StreetComplete is removing information. If StreetComplete would instead not remove maxspeed but leave it as it is, it will instead potentially create conflicting information, upsetting other (or the same) people. So, unless StreetComplete knows the default speed limits for all the maxspeed road categories for all countries and states in the world (see point 3) and would therefore be able to derive and update the maxspeed value in case it was given explicitly before and otherwise leave it out, it is inevitable to clash with any of the evangelists. To have this knowledge in the app is impossible, because the tags for that are not even defined nor ever will be (see point 3 again)

I know, the conflict-parts of this can be solved by having a reasonable discussion and deciding on something, but since these schemes are so badly defined while also each trying to reign supreme over implicit maxspeed tagging, there will always be people who take offence how StreetComplete would solve this dilemma and mediate between the competing keys that mostly declare the same information and the competing ways to declare implicit speed limits (with or without maxspeed).
Even now still, there are people who take offense over the decision that StreetComplete uses the tag maxspeed:type instead of the (in Germany) more popular source:maxspeed, even though none of the 4 alternatives is neither approved nor deprecated and all basically declare the same information. So, this would be the least of the complaints if StreetComplete would try go offer a re-survey of the said data.

Possible solution

Basically, to make it simple and straightforward to record the speed limit, we just need to separate the information "to what legal maxspeed category of road does this road belong" and "is there a speed limit sign or not?". The former requires someone adept at the local legislation, the latter requires someone on-site. These are two distinct informations and quite possibly two different groups of people.
Currently, there is no way of just recording if there is no speed limit sign for a given piece of road.

If there was, for example maxspeed:signed=yes/no, analogous to opening_hours:signed etc., a surveyor would be able to record the speed limit if it was signed and otherwise just record that there is no speed limit and that's it.

Then, possibly later, more information could be recorded that will help to determine what is the implicit speed limit for a given piece of road. One usually doesn't need to be on-site to be able to determine that if a road is outside city limits and there is no sign, it is a rural road and thus implicit speed limits for rural roads apply. So, this information can later be added by remote mappers which are experts on which legal road categories in terms of speed limits exist.
The classic source:maxspeed=XX:xxxxx tags can be used for that, or better as far as possible locally verifiable tags like lit (in UK, lit roads count as urban), bicycle_road (bicycle roads are signed, thus locally verifiable and have an implicit speed limit that is not given on the sign), living_street or lanes (in Germany, rural roads with 2 or more lanes in each direction do only have an advisory speed limit of 130 kph, doesn't need to be classified as a motorway).

Of course, this is a solution I can propose here in the comment, but I can not simply start using this solution without an accepted proposal and I will not create a proposal myself for this. I have little hope for it passing anyway, because there are far too many people that do not recognize the issue and don't want an additional tag on each and every piece of highway, but this is what it would lead to.

@tordans
Copy link

tordans commented Aug 20, 2020

However, from the original list in the wiki, I removed AddBikeParkingType, AddBenchBackrest and AddCrossingType because these will usually only change if the whole object is removed or replaced. So it would be better to have (in the future) quest types that specifically ask and only ask if "object x still here?".

Just to connect two dots here, I saw the idea of using check_date:existence by @joostschouppe over at pietervdvn/MapComplete#68. (Taginfo: 48 uses)

@westnordost
Copy link
Member Author

StreetComplete currently lacks the ability to remove elements, this is mainly what blocks these kind of quests. Regarding check_date:existence, I would think that check_date is already used for the existance of a thing. Or would you expect that if there is a check_date on a shop, it means that a surveyor checked each and every tag tagged on the shop? Certain properties are only verifiable on-site, other properties are only verifiable from other sources/online (website, phone, email, operator, ...). But anyway, this is becoming off topic now anyway.

@joostschouppe
Copy link

Yes, check_date:existence=* is basically just the same as check_date=*. I thought it would be useful to make that more explicit, especially since the wiki gives a counter intuitive example:

check_date=* used with highway=construction and opening_date=* documents the last time, when the expected opening date was checked or updated.

@dieterdreist
Copy link

dieterdreist commented Aug 20, 2020

Here are my comments, tried to post them on the list but it was too long:
Here are your points with comments:

(complexity) in order to not simply overwrite previous taggings with for example maxspeed:type, the app would need to understand and treat correctly all of source:maxspeed, maxspeed:type, zone:maxspeed, zone:traffic and depending on which tag is already set on the road, specifically update this value with the surveyed value.

There is no real argument: you simply should keep what is there, if it is correct (yes, you would have to evaluate all of these 4 keys) or change the maxspeed to a signed value and remove the implicit tag

(complexity/conflict) moreover on point 1, it is only common to set sign as a value for source:maxspeed and maxspeed:typeand not so for zone:maxspeed, zone:traffic,

clearly yes, because zones already either imply an implicit limit or a position inside a builtup area. Again, do not remove any of these tags which are not wrong

so it is not clear what to tag when the user selected that there is a speed limit sign now (maxspeed=40) and before there was none (tagged with zone:traffic=DE:urban or zone:maxspeed=DE:urban) to denote that the maxspeed is derived from an actual sign.

in a German zone (20/30) there cannot be explicit signs. If on the other hand the zone tags denote a builtup area, the tags should be kept

Probably removing zone:trafficand replacing it with maxspeed:type=sign(but only if it was zone:traffic or zone:maxspeed, not if it was source:maxspeed etc) would be okay, but this is another chain of conditionals and it is unclear if mappers preferring zone:maxspeed over the others would be okay with that since each of those keys claim to reign supreme over implicit speed limit tagging.

no, zone:traffic is, as far as I can see, used to indicate position inside or outside a settlement, so this should not be changed unless it is wrong, and should never be removed unless there will be general agreement that it is not the solution that we want

(conflict) source:maxspeed (etc.) being somewhat of a tag with a free-form valuebecause obviously the legislation with its breakdown of roads into speed-limit-categories and the definitions theirof is different from country to country, state to state, overwriting existing values (such as the one given in the first link) with a standard pattern of [ISO-country code]:[urban/rural] (f.e. DE:rural) can already in itself lead to a loss of information. (There are less bizarre examples as given in the first link.)

do not remove or modify these tags, let the users decide whether they are correct (keep) or wrong (modify)

To do this correctly, the app would need to know every single road category of the legislation of every country in the world and know which tag to use for that (for example, US-WI:rustic_road, US-NJ:suburban_residential??). Obviously, these are not defined at all and as the author of an editor like StreetComplete, I do not have the authority to just make up some tags, nor would it make sense, because that tagging scheme is inherently jinxed.

You could get the suitable values for a jurisdiction by looking at the values used for a specific country code before the colon (and a threshold) Admittedly someone in the US has torpedoed the system by omitting the country codes.

(complexity) In the rare case that before a road was tagged with a normal speed limit and now there is an advisory speed limit, each all the tags referring to the old limit must be removed. The same vice versa. Also, point 1 and 2 are of course also valid for advisory speed limits

the maxspeed is either correctly tagged (same as on the ground) or not. maxspeed is not for advisory speed limits, is it?

(complexity/conflict) Users can select that a road is actually signed as a living street, which changes the highway to living_street and doesn't tag any further maxspeed related tag because in a living street, it is clear that it is implicit. So when this answer is given in a re-survey, probablyall maxspeed-related tags should be removed.

this depends which tags you consider maxspeed related, those tags referring to zones for example are somehow related but should not be removed. It is not “clear” that walking speed is implicit for a living street, as soon as you leave Germany.

But then, it might already have been tagged with for example maxspeed=walk (Germany) or maxspeed=20 (Russia), so removing this could upset people that the app is destroying information. On the other hand, if it doesn't remove the maxspeed information, there could likely be contradictory information. To solve this issue in a way that would be maximally wary in not removing any information (even if it can be derived implicitly), the app would need to know the currently valid speed limits for living streets in all countries in the world and not remove maxspeed if it is already set and equal to the speed limit known for living streets.

or explicitly ask people to check it.

(complexity/conflict) More on point 5 - unfortunately, this is not the end. Some people find it very important to tag source:maxspeed=RU:living_street on every highway=living_street (or living_street=yes). StreetComplete doesn't do that, which is fine for everyone, but it wouldn't be fine for everyone if the app removed this tag automatically when re-tagging to highway=living_street. This is of course also a rare case, because roads not tagged as highway=living_street (or living_street=yes) are not that likely to have that tag. On the other hand, for example in Russia, for certain roads ("courtyard roads"), the same speed limit as for living street applies without it being explicitly signed. So it might not be entirely rare.

again, don’t automatically remove these tags, but ask mapper whether to keep or remove

(conflict)

A short introduction is inevitable: It used to be common practice to only tag maxspeed. source:maxspeed etc. were invented later to make it verifiable better where the maxspeedinformation is coming from and more future-proof in case the law changes the default speed limits. Now, many people tag only the source:maxspeed( or zone:maxspeed, etc) tag in case there is no sign because maxspeed is then a superfluous and potentially conflicting information which can be derived from the other tag.

this is clearly wrong, at least for source:maxspeed. The documentation always asked to explicitly tag “maxspeed” values. Potentially conflicting information is ok because it can be automatically detected and fixed, much easier than plain wrong non-conflicting tagging.

StreetComplete also tags like that. However, there are still evangelists for all three variants (only maxspeed, both, only source:maxspeed or another) around because there is no approved tagging scheme with a clear accepted recommendations anywhere, so everyone just does his own thing which seems to be fine as long as there are local consensuses on which method to use and no software dares to push any particular of the three.
When StreetComplete starts to let users re-survey the speed limits and the user selects that there is no sign, thus an implicit speed limit applies, it will inevitably have to deal with previously tagged implicit speed limits (of all three possible variants). So, if StreetComplete would in that case remove the explicitly tagged maxspeed, it will upset people that StreetComplete is removing information.

indeed. You should rather ask: what is the maxspeed? And as a secondary question whether there is a sign or it is an implicit limit. Thereby you can then find all potential problems (maxspeed not correlated to the implicit indication), or someone else can do it.

If StreetComplete would instead not remove maxspeed but leave it as it is, it will instead potentially create conflicting information, upsetting other (or the same) people.

encourage the users to fix the maxspeed by checking and eventually modifying its value

So, unless StreetComplete knows the default speed limits for all the maxspeed road categories for all countries and states in the world (see point 3) and would therefore be able to derive and update the maxspeed value in case it was given explicitly before and otherwise leave it out, it is inevitable to clash with any of the evangelists. To have this knowledge in the app is impossible, because the tags for that are not even defined nor ever will be (see point 3 again)

just let the users check both values, the implicit /source and the explicit values. They must know the locally used values, not you. For you it is sufficient to know all used values (with some usage, to exclude typos)

Cheers Martin

@westnordost

This comment has been minimized.

@westnordost
Copy link
Member Author

westnordost commented Aug 20, 2020

Answers on your answers. I've taken the liberty to sum up my statements and your answers each in one sentence in a chat-like manner because otherwise it's going to be so much text that noone will be able to follow:

  1. [there are 4 different keys for the same information, adds complexity]

[Yes, but it should be handled]

Yes, it just adds complexity.

  1. [there is no zone:maxspeed=sign, should I replace the tag with maxspeed:type=sign if user answers that there is a sign now?]

[zone:maxspeed and zone:traffic denote the traffic zone independent of the presence of a speed limit sign]

Okay, this is not how I understand the wiki but I would totally be in favour of it being defined this way. Your interpretation also adds ambiguity: zone:maxspeed=FR:rural + maxspeed=90 - it's a rural road alright, but is it 90 kph because there is a sign there, or is it 90 kph because the maxspeedhasn't been updated yet since France changed their default speed limits on rural roads?

  1. [possible loss of information when overwriting a source:maxspeed value with standard pattern of f.e. DE:rural]

[don't overwrite automatically but show it to users and let them decide}

Sure, you can say that this is a prerequisite, but StreetComplete never shows raw tags to its users because it should not be a prerequisite for surveying for OpenStreetMap to know all the tags and maxspeed legislations. This (point 3) is one of the main problems why this information cannot be re-surveyed using StreetComplete - it requires either the user or the software itself to know all about the different legal maxspeed road categories and the tag value to use for them. The former is nothing that StreetComplete would impose upon its users, the latter is impossible for the reasons given. Furthermore, the mentioned legal maxspeed road categories are not even defined anywhere for every country and also never will be.

  1. [complexity when changing a maxspeed limit to an advisory speed limit]

[Yes, so what?]

Yes, it just adds complexity.

5./6. [re-tagging to living street: there are different opinions about whether maxspeed (and other related tags) should always be tagged explicitly on living streets or not]

[zone:maxspeed=XX:living_street and the like should not be removed if it is there. (Better) don't remove maxspeed but let the user check.]

Fair enough, the first part would be doable albeit it adds more complexity, the second part is point 3 again. How will the user be able to check if a certain displayed speed limit is correct for a living street if the speed limit is not specified explicitly on the living street sign? - in Germany for example it isnt. -> Only by knowing the legal situation in the country he is mapping in currently OR if the app would know it in the user's stead. The former is nothing that StreetComplete imposes on its users, the latter is probably doable, but adds even more complexity.

  1. [there are three different opinions about how implicit speed limits should be tagged: maxspeed only, source:maxspeed (etc) only or both. The app would need to impose one which it can't without stepping on people's toes]

[Clearly, only tagging both source:maxspeed and maxspeed is correct. Also, the app should just ask about the valid maxspeed and only in a second step from where this information is derived.]

Right, here we are, I see you belong to the third group and like advocates of any of these groupes, you claim that your method must reign supreme. But this doesn't really change anything on the situation though.

On the second point: The app asks only its users on-site verifiable information that do not require the surveyors to have any specialist knowledge. It's point 3 again. Let's say you are in France, on a rural road, there are no signs. Answering it correctly with "80 kph" requires you to know exactly the legal maxspeed road categories valid in the country you are currently in. So instead, what the app (should) ask is "Is there a sign? If yes, what's written on it?" but it can't because there is no tag for "there is no sign here".

So in a nutshell, my reply is: It would be quite easy implementation-wise to write a tool that lets craft mappers that know about the maxspeed traffic rules re-survey the speed limits. But StreetComplete isn't that tool because it does not require its users to have specialist knowledge (in this case: for example a drivers license in the country they are in currently).
You are implictly dismissing this with the statement that it is then up to only these craft mappers to map and maintain the speed limits world-wide.
Well fine, so be it, but abstaining on the help on maxspeed-maintenance by non-speed-limit-law experts is a huge loss, and we see it doesn't work that well, just look at how incomplete, fragmentary and outdated this data is.

Edit: But anyway, thank you for reading and responding on every point of that long explanation

@westnordost
Copy link
Member Author

westnordost commented Aug 20, 2020

Summary of all re-survey enabled quests with intervals, element selection and notes what is tagged

Manual review of these is very very welcome! Any bugs or issues found now will not pop up later in the beta phase

In the the table below, you can expand the fields "Asked for Elements..." and "Overpass Query" by clicking on that arrow. If the former is available, the latter is actually just an automatic tranpilation into Overpass QL, so it is easier to understand if you just look at "Asked for Elements...".

Following the remarks expressed on the tagging mailing list, all quests below only add or update a check_date:* tag if the value(s) it refers to weren't actually changed after the survey. If any value was changed, no check_date:* is set and any previous check_date:* tags removed.
Note that this will unfortunately lead to properties practically never asked again for elements that are touched often to change other things. However, to have the bare minimum of additional check_date tags to make this work seems to the preference uttered in the tagging mailing list.

Whenever adding, updating or deleting a check_date:*, any other known check date tags (*:check_date, *:lastcheck, *:last_checked, check_date:*, lastcheck:*, last_checked:*) referring to the same tag are deleted.

AddRecyclingContainerMaterials

  • tags check_date:recycling on recycling containers
  • will only be asked if again if all previously given recycling:* = yes tags are tags that are actually selectable in the app
  • will only be asked for containers not too close to other containers
  • asked every 2 years
  • on updating the recycling:* values, it will not touch any recycling:* = no taggings of recycling types the app does not know but remove those that it knows and were not selected by the user
Overpass Query
[bbox:{{bbox}}];
node[amenity = recycling][recycling_type = container] -> .all;

node.all[~"^recycling:.*$" ~ "yes"] -> .with_recycling;
(.all; - .with_recycling;) -> .without_recycling;

node.with_recycling[~"^(recycling:glass_bottles|recycling:paper|recycling:plastic|recycling:plastic_packaging|recycling:plastic_bottles|recycling:cans|recycling:scrap_metal|recycling:clothes|recycling:shoes|recycling:small_electrical_appliances|recycling:batteries|recycling:green_waste|recycling:cooking_oil|recycling:engine_oil)$" ~ "yes" ] -> .with_known_recycling;
(.with_recycling; - .with_known_recycling;) -> .with_unknown_recycling;

node.all(if: date(timestamp()) < date('2018-08-21') || date(t['recycling:check_date']) < date('2018-08-21') || date(t['check_date:recycling']) < date('2018-08-21') || date(t['recycling:lastcheck']) < date('2018-08-21') || date(t['lastcheck:recycling']) < date('2018-08-21') || date(t['recycling:last_checked']) < date('2018-08-21') || date(t['last_checked:recycling']) < date('2018-08-21')) -> .old;

(.without_recycling; (.old; - .with_unknown_recycling;);) -> .recyclings;

foreach .recyclings (
    node[amenity = recycling][recycling_type = container](around: 20);
    node._(if:count(nodes) == 1);
    out meta geom;
);

AddRoadSurface

  • tags check_date:surface on roads
  • asked every 4 years for unpaved roads
  • otherwise asked every 12 years
Asked For Elements...
ways with highway ~ primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|unclassified|residential|living_street|pedestrian|track|road
 and (
   !surface
   or surface ~ unpaved|compacted|gravel|fine_gravel|pebblestone|grass_paver|ground|earth|dirt|grass|sand|mud|ice|salt|snow|woodchips and surface older today -4.0 years
   or surface older today -12.0 years
 )
 and (access !~ private|no or (foot and foot !~ private|no))
Overpass Query
[bbox:{{bbox}}];
way[highway ~ '^(primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|unclassified|residential|living_street|pedestrian|track|road)$'] -> .w1;
way.w1[!surface] -> .w2;
way.w1[surface ~ '^(unpaved|compacted|gravel|fine_gravel|pebblestone|grass_paver|ground|earth|dirt|grass|sand|mud|ice|salt|snow|woodchips)$'][surface](if: date(timestamp()) < date('2016-08-20') || date(t['surface:check_date']) < date('2016-08-20') || date(t['check_date:surface']) < date('2016-08-20') || date(t['surface:lastcheck']) < date('2016-08-20') || date(t['lastcheck:surface']) < date('2016-08-20') || date(t['surface:last_checked']) < date('2016-08-20') || date(t['last_checked:surface']) < date('2016-08-20')) -> .w3;
way.w1[surface](if: date(timestamp()) < date('2012-08-20') || date(t['surface:check_date']) < date('2012-08-20') || date(t['check_date:surface']) < date('2012-08-20') || date(t['surface:lastcheck']) < date('2012-08-20') || date(t['lastcheck:surface']) < date('2012-08-20') || date(t['surface:last_checked']) < date('2012-08-20') || date(t['last_checked:surface']) < date('2012-08-20')) -> .w4;
(.w2; .w3; .w4;) -> .w1;
way.w1[access !~ '^(private|no)$'] -> .w5;
way.w1[foot][foot !~ '^(private|no)$'] -> .w6;
(.w5; .w6;);
out meta geom;

AddRailwayCrossingBarrier

  • tags check_date:crossing:barrier on railway crossings
  • asked every 8 years
Overpass Query
[bbox:{{bbox}}];

way[highway][access ~ '^(private|no)$']; node(w) -> .private_road_nodes;
way[railway ~ '^(tram|abandoned)$']; node(w) -> .excluded_railways_nodes;
(.private_road_nodes; .excluded_railways_nodes;) -> .excluded;

node[railway = level_crossing] -> .crossings;

node.crossings[!'crossing:barrier'] -> .crossings_with_unknown_barrier;
node.crossings(if: date(timestamp()) < date('2012-08-22') || date(t['crossing:barrier:check_date']) < date('2012-08-22') || date(t['check_date:crossing:barrier']) < date('2012-08-22') || date(t['crossing:barrier:lastcheck']) < date('2012-08-22') || date(t['lastcheck:crossing:barrier']) < date('2012-08-22') || date(t['crossing:barrier:last_checked']) < date('2012-08-22') || date(t['last_checked:crossing:barrier']) < date('2012-08-22')) -> .crossings_with_old_barrier;

((.crossings_with_unknown_barrier; .crossings_with_old_barrier;); - .excluded;);

out meta geom;

AddPostboxCollectionTimes

  • tags check_date:collection_times on postboxes
  • never asked again if it was previously tagged as not signed
  • otherwise every two years
Asked For Elements...
nodes with amenity = post_box
and access !~ private|no
and collection_times:signed != no
and (!collection_times or collection_times older today -2.0 years)
Overpass Query
[bbox:{{bbox}}];
node[amenity = post_box][access !~ '^(private|no)$']['collection_times:signed' != no] -> .n1;
node.n1[!collection_times] -> .n2;
node.n1[collection_times](if: date(timestamp()) < date('2018-08-21') || date(t['collection_times:check_date']) < date('2018-08-21') || date(t['check_date:collection_times']) < date('2018-08-21') || date(t['collection_times:lastcheck']) < date('2018-08-21') || date(t['lastcheck:collection_times']) < date('2018-08-21') || date(t['collection_times:last_checked']) < date('2018-08-21') || date(t['last_checked:collection_times']) < date('2018-08-21')) -> .n3;
(.n2; .n3;);
out meta geom;

AddBikeParkingCapacity

  • tags check_date:capacity on bicycle parkings
  • asked every 4 years and only if the parking type is stands or wall_loops
Asked For Elements...
nodes, ways with amenity = bicycle_parking
 and access !~ private|no
 and (
   !capacity
   or bicycle_parking ~ stands|wall_loops and capacity older today -4.0 years
 )
Overpass Query
[bbox:{{bbox}}];
nw[amenity = bicycle_parking][access !~ '^(private|no)$'] -> .e1;
nw.e1[!capacity] -> .e2;
nw.e1[bicycle_parking ~ '^(stands|wall_loops)$'][capacity](if: date(timestamp()) < date('2016-08-20') || date(t['capacity:check_date']) < date('2016-08-20') || date(t['check_date:capacity']) < date('2016-08-20') || date(t['capacity:lastcheck']) < date('2016-08-20') || date(t['lastcheck:capacity']) < date('2016-08-20') || date(t['capacity:last_checked']) < date('2016-08-20') || date(t['last_checked:capacity']) < date('2016-08-20')) -> .e3;
(.e2; .e3;);
out meta geom;

AddCrossingType

  • tags check_date:crossing on crossings
  • asked every 8 years
  • if it was tagged as zebra before, will not re-tag to uncontrolled if the user selected that it is an uncontrolled crossing but leave it as it is
  • if it was tagged as marked before, will not re-tag to uncontrolled if the user selected that it is an uncontrolled crossing but leave it as it is
Asked For Elements...
nodes with highway = crossing
  and foot != no
  and (
    !crossing
    or crossing ~ island|unknown|yes
    or (
      crossing ~ traffic_signals|uncontrolled|zebra|marked|unmarked
      and crossing older today -8.0 years
    )
  )
Overpass Query
[bbox:{{bbox}}];
node[highway = crossing][foot != no] -> .n1;
node.n1[!crossing] -> .n2;
node.n1[crossing ~ '^(island|unknown|yes)$'] -> .n3;
node.n1[crossing ~ '^(traffic_signals|uncontrolled|zebra|marked|unmarked)$'][crossing](if: date(timestamp()) < date('2012-08-20') || date(t['crossing:check_date']) < date('2012-08-20') || date(t['check_date:crossing']) < date('2012-08-20') || date(t['crossing:lastcheck']) < date('2012-08-20') || date(t['lastcheck:crossing']) < date('2012-08-20') || date(t['crossing:last_checked']) < date('2012-08-20') || date(t['last_checked:crossing']) < date('2012-08-20')) -> .n4;
(.n2; .n3; .n4;);
out meta geom;

AddBusStopShelter

  • tags check_date:shelter on bus and tram stops
  • asked every 4 years
  • never asked again if it is covered
Asked For Elements...
nodes with 
(
  (public_transport = platform and ~bus|trolleybus|tram ~ yes)
  or
  (highway = bus_stop and public_transport != stop_position)
)
and physically_present != no and naptan:BusStopType != HAR
and !covered and (!shelter or shelter older today -4.0 years)
Overpass Query
[bbox:{{bbox}}];
node[public_transport = platform][~'^(bus|trolleybus|tram)$' ~ '^(yes)$'] -> .n2;
node[highway = bus_stop][public_transport != stop_position] -> .n3;
(.n2; .n3;) -> .n1;
node.n1[physically_present != no]['naptan:BusStopType' != HAR][!covered] -> .n1;
node.n1[!shelter] -> .n4;
node.n1[shelter](if: date(timestamp()) < date('2016-08-20') || date(t['shelter:check_date']) < date('2016-08-20') || date(t['check_date:shelter']) < date('2016-08-20') || date(t['shelter:lastcheck']) < date('2016-08-20') || date(t['lastcheck:shelter']) < date('2016-08-20') || date(t['shelter:last_checked']) < date('2016-08-20') || date(t['last_checked:shelter']) < date('2016-08-20')) -> .n5;
(.n4; .n5;);
out meta geom;

AddVegetarian

  • tags check_date:diet:vegetarian on restaurants etc
  • only asked if it did not offer exclusively vegetarian meals, every 2 years
Asked For Elements...
nodes, ways with amenity ~ restaurant|cafe|fast_food
and name and (
  !diet:vegetarian 
  or diet:vegetarian != only and diet:vegetarian older today -2.0 years
)
Overpass Query
[bbox:{{bbox}}];
nw[amenity ~ '^(restaurant|cafe|fast_food)$'][name] -> .e1;
nw.e1[!'diet:vegetarian'] -> .e2;
nw.e1['diet:vegetarian' != only]['diet:vegetarian'](if: date(timestamp()) < date('2018-08-21') || date(t['diet:vegetarian:check_date']) < date('2018-08-21') || date(t['check_date:diet:vegetarian']) < date('2018-08-21') || date(t['diet:vegetarian:lastcheck']) < date('2018-08-21') || date(t['lastcheck:diet:vegetarian']) < date('2018-08-21') || date(t['diet:vegetarian:last_checked']) < date('2018-08-21') || date(t['last_checked:diet:vegetarian']) < date('2018-08-21')) -> .e3;
(.e2; .e3;);
out meta geom;

AddVegan

  • tags check_date:diet:vegan on restaurants etc
  • only asked if it did not offer exclusively vegan meals, every 2 years
Asked For Elements...
nodes, ways with 
(
  amenity ~ restaurant|cafe|fast_food and diet:vegetarian ~ yes|only 
  or amenity = ice_cream
)
and name and (
  !diet:vegan 
  or diet:vegan != only and diet:vegan older today -2.0 years
)
Overpass Query
[bbox:{{bbox}}];
nw[amenity ~ '^(restaurant|cafe|fast_food)$']['diet:vegetarian' ~ '^(yes|only)$'] -> .e2;
nw[amenity = ice_cream] -> .e3;
(.e2; .e3;) -> .e1;
nw.e1[name] -> .e1;
nw.e1[!'diet:vegan'] -> .e4;
nw.e1['diet:vegan' != only]['diet:vegan'](if: date(timestamp()) < date('2018-08-21') || date(t['diet:vegan:check_date']) < date('2018-08-21') || date(t['check_date:diet:vegan']) < date('2018-08-21') || date(t['diet:vegan:lastcheck']) < date('2018-08-21') || date(t['lastcheck:diet:vegan']) < date('2018-08-21') || date(t['diet:vegan:last_checked']) < date('2018-08-21') || date(t['last_checked:diet:vegan']) < date('2018-08-21')) -> .e5;
(.e4; .e5;);
out meta geom;

AddInternetAccess

  • tags check_date:internet_access on certain businesses
  • asked every 2 years
Asked For Elements...
nodes, ways, relations with
(
  amenity ~ library|community_centre|youth_centre
  or tourism ~ hotel|guest_house|motel|hostel|alpine_hut|apartment|resort|camp_site|caravan_site|chalet
)
and name
and (
  !internet_access
  or internet_access = yes
  or internet_access older today -2.0 years
)
Overpass Query
[bbox:{{bbox}}];
nwr[amenity ~ '^(library|community_centre|youth_centre)$'] -> .e2;
nwr[tourism ~ '^(hotel|guest_house|motel|hostel|alpine_hut|apartment|resort|camp_site|caravan_site|chalet)$'] -> .e3;
(.e2; .e3;) -> .e1;
nwr.e1[name] -> .e1;
nwr.e1[!internet_access] -> .e4;
nwr.e1[internet_access = yes] -> .e5;
nwr.e1[internet_access](if: date(timestamp()) < date('2018-08-21') || date(t['internet_access:check_date']) < date('2018-08-21') || date(t['check_date:internet_access']) < date('2018-08-21') || date(t['internet_access:lastcheck']) < date('2018-08-21') || date(t['lastcheck:internet_access']) < date('2018-08-21') || date(t['internet_access:last_checked']) < date('2018-08-21') || date(t['last_checked:internet_access']) < date('2018-08-21')) -> .e6;
(.e4; .e5; .e6;);
out meta geom;

AddParkingFee

  • tags check_date:fee on parkings
  • asked every 8 years
Asked For Elements...
nodes, ways, relations with amenity = parking
and access ~ yes|customers|public
and (
    !fee and !fee:conditional
    or fee older today -8.0 years
)
Overpass Query
[bbox:{{bbox}}];
nwr[amenity = parking][access ~ '^(yes|customers|public)$'] -> .e1;
nwr.e1[!fee][!'fee:conditional'] -> .e2;
nwr.e1[fee](if: date(timestamp()) < date('2012-08-20') || date(t['fee:check_date']) < date('2012-08-20') || date(t['check_date:fee']) < date('2012-08-20') || date(t['fee:lastcheck']) < date('2012-08-20') || date(t['lastcheck:fee']) < date('2012-08-20') || date(t['fee:last_checked']) < date('2012-08-20') || date(t['last_checked:fee']) < date('2012-08-20')) -> .e3;
(.e2; .e3;);
out meta geom;

AddMotorcycleParkingCapacity

  • tags check_date:capacity on motorcycle parkings
  • asked every 4 years
Asked For Elements...
nodes, ways with amenity = motorcycle_parking 
 and access !~ private|no
 and (!capacity or capacity older today -4.0 years)
Overpass Query
[bbox:{{bbox}}];
nw[amenity = motorcycle_parking][access !~ '^(private|no)$'] -> .e1;
nw.e1[!capacity] -> .e2;
nw.e1[capacity](if: date(timestamp()) < date('2016-08-20') || date(t['capacity:check_date']) < date('2016-08-20') || date(t['check_date:capacity']) < date('2016-08-20') || date(t['capacity:lastcheck']) < date('2016-08-20') || date(t['lastcheck:capacity']) < date('2016-08-20') || date(t['capacity:last_checked']) < date('2016-08-20') || date(t['last_checked:capacity']) < date('2016-08-20')) -> .e3;
(.e2; .e3;);
out meta geom;

AddPathSurface

  • tags check_date:surface on footways, cycleways and other paths
  • asked every 4 years for unpaved surfaces
  • asked every 8 years otherwise
Asked For Elements...
ways with highway ~ path|footway|cycleway|bridleway|steps
and segregated != yes
and access !~ private|no
and (!conveying or conveying = no) and (!indoor or indoor = no)
and (
  !surface
  or surface ~ unpaved|compacted|gravel|fine_gravel|pebblestone|grass_paver|ground|earth|dirt|grass|sand|mud|ice|salt|snow|woodchips and surface older today -4.0 years
  or surface older today -8.0 years
)
Overpass Query
[bbox:{{bbox}}];
way[highway ~ '^(path|footway|cycleway|bridleway|steps)$'][segregated != yes][access !~ '^(private|no)$'] -> .w1;
way.w1[!conveying] -> .w2;
way.w1[conveying = no] -> .w3;
(.w2; .w3;) -> .w1;
way.w1[!indoor] -> .w4;
way.w1[indoor = no] -> .w5;
(.w4; .w5;) -> .w1;
way.w1[!surface] -> .w6;
way.w1[surface ~ '^(unpaved|compacted|gravel|fine_gravel|pebblestone|grass_paver|ground|earth|dirt|grass|sand|mud|ice|salt|snow|woodchips)$'][surface](if: date(timestamp()) < date('2016-08-20') || date(t['surface:check_date']) < date('2016-08-20') || date(t['check_date:surface']) < date('2016-08-20') || date(t['surface:lastcheck']) < date('2016-08-20') || date(t['lastcheck:surface']) < date('2016-08-20') || date(t['surface:last_checked']) < date('2016-08-20') || date(t['last_checked:surface']) < date('2016-08-20')) -> .w7;
way.w1[surface](if: date(timestamp()) < date('2012-08-20') || date(t['surface:check_date']) < date('2012-08-20') || date(t['check_date:surface']) < date('2012-08-20') || date(t['surface:lastcheck']) < date('2012-08-20') || date(t['lastcheck:surface']) < date('2012-08-20') || date(t['surface:last_checked']) < date('2012-08-20') || date(t['last_checked:surface']) < date('2012-08-20')) -> .w8;
(.w6; .w7; .w8;);
out meta geom;

AddTracktype

  • tags check_date:tracktype on tracks
  • asked every 4 years if it is not grade1
  • asked every 4 years if it does not have a paved surface
  • asked every 8 years otherwise
Asked For Elements...
ways with highway = track
and (
  !tracktype
  or tracktype != grade1 and tracktype older today -4.0 years
  or surface ~ unpaved|compacted|gravel|fine_gravel|pebblestone|grass_paver|ground|earth|dirt|grass|sand|mud|ice|salt|snow|woodchips and tracktype older today -${r * 4} years
  or tracktype older today -8.0 years
)
and (access !~ private|no or (foot and foot !~ private|no))
Overpass Query
[bbox:{{bbox}}];
way[highway = track] -> .w1;
way.w1[!tracktype] -> .w2;
way.w1[tracktype != grade1][tracktype](if: date(timestamp()) < date('2016-08-20') || date(t['tracktype:check_date']) < date('2016-08-20') || date(t['check_date:tracktype']) < date('2016-08-20') || date(t['tracktype:lastcheck']) < date('2016-08-20') || date(t['lastcheck:tracktype']) < date('2016-08-20') || date(t['tracktype:last_checked']) < date('2016-08-20') || date(t['last_checked:tracktype']) < date('2016-08-20')) -> .w3;
way.w1[tracktype](if: date(timestamp()) < date('2012-08-20') || date(t['tracktype:check_date']) < date('2012-08-20') || date(t['check_date:tracktype']) < date('2012-08-20') || date(t['tracktype:lastcheck']) < date('2012-08-20') || date(t['lastcheck:tracktype']) < date('2012-08-20') || date(t['tracktype:last_checked']) < date('2012-08-20') || date(t['last_checked:tracktype']) < date('2012-08-20')) -> .w4;
(.w2; .w3; .w4;) -> .w1;
way.w1[access !~ '^(private|no)$'] -> .w5;
way.w1[foot][foot !~ '^(private|no)$'] -> .w6;
(.w5; .w6;);
out meta geom;

AddWheelchairAccessToilets

  • tags check_date:wheelchair on public toilets
  • asked every 4 years if it is not wheelchair accessible yet
  • asked every 8 years otherwise
Asked For Elements...
nodes, ways with amenity = toilets 
 and access !~ private|customers
 and (
   !wheelchair
   or wheelchair != yes and wheelchair older today -4.0 years
   or wheelchair older today -8.0 years
 )
Overpass Query
[bbox:{{bbox}}];
nw[amenity = toilets][access !~ '^(private|customers)$'] -> .e1;
nw.e1[!wheelchair] -> .e2;
nw.e1[wheelchair != yes][wheelchair](if: date(timestamp()) < date('2016-08-20') || date(t['wheelchair:check_date']) < date('2016-08-20') || date(t['check_date:wheelchair']) < date('2016-08-20') || date(t['wheelchair:lastcheck']) < date('2016-08-20') || date(t['lastcheck:wheelchair']) < date('2016-08-20') || date(t['wheelchair:last_checked']) < date('2016-08-20') || date(t['last_checked:wheelchair']) < date('2016-08-20')) -> .e3;
nw.e1[wheelchair](if: date(timestamp()) < date('2012-08-20') || date(t['wheelchair:check_date']) < date('2012-08-20') || date(t['check_date:wheelchair']) < date('2012-08-20') || date(t['wheelchair:lastcheck']) < date('2012-08-20') || date(t['lastcheck:wheelchair']) < date('2012-08-20') || date(t['wheelchair:last_checked']) < date('2012-08-20') || date(t['last_checked:wheelchair']) < date('2012-08-20')) -> .e4;
(.e2; .e3; .e4;);
out meta geom;

AddWayLit

  • tags check_date:lit on certain paths and streets
  • asked every 8 years if it is not lit yet
  • asked every 16 years otherwise
Asked For Elements...
ways with
(
  (
    (
      highway ~ residential|living_street|pedestrian
      or highway ~ primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|unclassified|service and
      (
        sidewalk ~ both|left|right|yes|separate
        or ~source:maxspeed|maxspeed:type|zone:maxspeed|zone:traffic ~ .+urban|.+zone
      )
      or highway ~ footway|cycleway|steps
      or highway = path and (foot = designated or bicycle = designated)
    )
    and !lit
  )
  or highway and lit = no and lit older today -8.0 years
  or highway and lit older today -16.0 years
)
and (access !~ private|no or (foot and foot !~ private|no))
Overpass Query
[bbox:{{bbox}}];
way[highway ~ '^(residential|living_street|pedestrian)$'] -> .w3;
way[highway ~ '^(primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|unclassified|service)$'] -> .w4;
way.w4[sidewalk ~ '^(both|left|right|yes|separate)$'] -> .w5;
way.w4[~'^(source:maxspeed|maxspeed:type|zone:maxspeed|zone:traffic)$' ~ '^(.+urban|.+zone)$'] -> .w6;
(.w5; .w6;) -> .w4;
way[highway ~ '^(footway|cycleway|steps)$'] -> .w7;
way[highway = path] -> .w8;
way.w8[foot = designated] -> .w9;
way.w8[bicycle = designated] -> .w10;
(.w9; .w10;) -> .w8;
(.w3; .w4; .w7; .w8;) -> .w2;
way.w2[!lit] -> .w2;
way[highway][lit = no][lit](if: date(timestamp()) < date('2012-08-20') || date(t['lit:check_date']) < date('2012-08-20') || date(t['check_date:lit']) < date('2012-08-20') || date(t['lit:lastcheck']) < date('2012-08-20') || date(t['lastcheck:lit']) < date('2012-08-20') || date(t['lit:last_checked']) < date('2012-08-20') || date(t['last_checked:lit']) < date('2012-08-20')) -> .w11;
way[highway][lit](if: date(timestamp()) < date('2004-08-20') || date(t['lit:check_date']) < date('2004-08-20') || date(t['check_date:lit']) < date('2004-08-20') || date(t['lit:lastcheck']) < date('2004-08-20') || date(t['lastcheck:lit']) < date('2004-08-20') || date(t['lit:last_checked']) < date('2004-08-20') || date(t['last_checked:lit']) < date('2004-08-20')) -> .w12;
(.w2; .w11; .w12;) -> .w1;
way.w1[access !~ '^(private|no)$'] -> .w13;
way.w1[foot][foot !~ '^(private|no)$'] -> .w14;
(.w13; .w14;);
out meta geom;

AddTactilePavingCrosswalk

  • tags check_date:tactile_paving on crosswalks
  • asked every 4 years if it is does not have tactile paving yet
  • asked every 8 years otherwise
Overpass Query
[bbox:{{bbox}}];

way[highway = cycleway][foot !~ '^(yes|designated)$']; node(w) -> .exclusive_cycleway_nodes;
way[highway][access ~ '^(private|no)$']; node(w) -> .private_road_nodes;
(.exclusive_cycleway_nodes; .private_road_nodes;) -> .excluded;

node[highway = crossing][foot != no] -> .crossings;

node.crossings[!tactile_paving] -> .crossings_with_unknown_tactile_paving;
node.crossings[tactile_paving = no](if: date(timestamp()) < date('2016-08-21') || date(t['tactile_paving:check_date']) < date('2016-08-21') || date(t['check_date:tactile_paving']) < date('2016-08-21') || date(t['tactile_paving:lastcheck']) < date('2016-08-21') || date(t['lastcheck:tactile_paving']) < date('2016-08-21') || date(t['tactile_paving:last_checked']) < date('2016-08-21') || date(t['last_checked:tactile_paving']) < date('2016-08-21')) -> .old_crossings_without_tactile_paving;
node.crossings(if: date(timestamp()) < date('2012-08-22') || date(t['tactile_paving:check_date']) < date('2012-08-22') || date(t['check_date:tactile_paving']) < date('2012-08-22') || date(t['tactile_paving:lastcheck']) < date('2012-08-22') || date(t['lastcheck:tactile_paving']) < date('2012-08-22') || date(t['tactile_paving:last_checked']) < date('2012-08-22') || date(t['last_checked:tactile_paving']) < date('2012-08-22')) -> .very_old_crossings;

(
    (
        .crossings_with_unknown_tactile_paving;
        .old_crossings_without_tactile_paving;
        .very_old_crossings;
    ); 
- .excluded;
);

out meta geom;

AddTrafficSignalsSound

  • tags check_date:traffic_signals:sound
  • asked every 4 years if it is does not have sound yet
  • asked every 8 years otherwise
Asked For Elements...
nodes with highway = crossing and crossing = traffic_signals
and (
  !traffic_signals:sound
  or traffic_signals:sound = no and traffic_signals:sound older today -4.0 years
  or traffic_signals:sound older today -8.0 years
)
Overpass Query
[bbox:{{bbox}}];
node[highway = crossing][crossing = traffic_signals] -> .n1;
node.n1[!'traffic_signals:sound'] -> .n2;
node.n1['traffic_signals:sound' = no]['traffic_signals:sound'](if: date(timestamp()) < date('2016-08-20') || date(t['traffic_signals:sound:check_date']) < date('2016-08-20') || date(t['check_date:traffic_signals:sound']) < date('2016-08-20') || date(t['traffic_signals:sound:lastcheck']) < date('2016-08-20') || date(t['lastcheck:traffic_signals:sound']) < date('2016-08-20') || date(t['traffic_signals:sound:last_checked']) < date('2016-08-20') || date(t['last_checked:traffic_signals:sound']) < date('2016-08-20')) -> .n3;
node.n1['traffic_signals:sound'](if: date(timestamp()) < date('2012-08-20') || date(t['traffic_signals:sound:check_date']) < date('2012-08-20') || date(t['check_date:traffic_signals:sound']) < date('2012-08-20') || date(t['traffic_signals:sound:lastcheck']) < date('2012-08-20') || date(t['lastcheck:traffic_signals:sound']) < date('2012-08-20') || date(t['traffic_signals:sound:last_checked']) < date('2012-08-20') || date(t['last_checked:traffic_signals:sound']) < date('2012-08-20')) -> .n4;
(.n2; .n3; .n4;);
out meta geom;

AddWheelchairAccessPublicTransport

  • tags check_date:wheelchair
  • asked every 4 years if it is not wheelchair accessible yet
  • asked every 8 years otherwise
Asked For Elements...
nodes, ways, relations with (amenity = bus_station or railway ~ station|subway_entrance)
and (
  !wheelchair
  or wheelchair != yes and wheelchair older today -4.0 years
  or wheelchair older today -8.0 years
)
Overpass Query
[bbox:{{bbox}}];
nwr[amenity = bus_station] -> .e2;
nwr[railway ~ '^(station|subway_entrance)$'] -> .e3;
(.e2; .e3;) -> .e1;
nwr.e1[!wheelchair] -> .e4;
nwr.e1[wheelchair != yes][wheelchair](if: date(timestamp()) < date('2016-08-20') || date(t['wheelchair:check_date']) < date('2016-08-20') || date(t['check_date:wheelchair']) < date('2016-08-20') || date(t['wheelchair:lastcheck']) < date('2016-08-20') || date(t['lastcheck:wheelchair']) < date('2016-08-20') || date(t['wheelchair:last_checked']) < date('2016-08-20') || date(t['last_checked:wheelchair']) < date('2016-08-20')) -> .e5;
nwr.e1[wheelchair](if: date(timestamp()) < date('2012-08-20') || date(t['wheelchair:check_date']) < date('2012-08-20') || date(t['check_date:wheelchair']) < date('2012-08-20') || date(t['wheelchair:lastcheck']) < date('2012-08-20') || date(t['lastcheck:wheelchair']) < date('2012-08-20') || date(t['wheelchair:last_checked']) < date('2012-08-20') || date(t['last_checked:wheelchair']) < date('2012-08-20')) -> .e6;
(.e4; .e5; .e6;);
out meta geom;

AddWheelchairAccessOutside

  • tags check_date:wheelchair
  • asked every 8 years
Asked For Elements...
nodes, ways, relations with leisure = dog_park
 and (!wheelchair or wheelchair older today -8.0 years)
Overpass Query
[bbox:{{bbox}}];
nwr[leisure = dog_park] -> .e1;
nwr.e1[!wheelchair] -> .e2;
nwr.e1[wheelchair](if: date(timestamp()) < date('2012-08-20') || date(t['wheelchair:check_date']) < date('2012-08-20') || date(t['check_date:wheelchair']) < date('2012-08-20') || date(t['wheelchair:lastcheck']) < date('2012-08-20') || date(t['lastcheck:wheelchair']) < date('2012-08-20') || date(t['wheelchair:last_checked']) < date('2012-08-20') || date(t['last_checked:wheelchair']) < date('2012-08-20')) -> .e3;
(.e2; .e3;);
out meta geom;

AddTactilePavingBusStop

  • tags check_date:tactile_paving for bus stops
  • asked every 4 years if the bus stop does not have tactile paving yet
  • asked every 8 years otherwise
Asked For Elements...
nodes, ways with
(
  (public_transport = platform and (bus = yes or trolleybus = yes or tram = yes)) 
  or 
  (highway = bus_stop and public_transport != stop_position)
)
and physically_present != no and naptan:BusStopType != HAR
and (
  !tactile_paving
  or tactile_paving = no and tactile_paving older today -4.0 years
  or tactile_paving older today -8.0 years
)
Overpass Query
[bbox:{{bbox}}];
nw[public_transport = platform] -> .e2;
nw.e2[bus = yes] -> .e3;
nw.e2[trolleybus = yes] -> .e4;
nw.e2[tram = yes] -> .e5;
(.e3; .e4; .e5;) -> .e2;
nw[highway = bus_stop][public_transport != stop_position] -> .e6;
(.e2; .e6;) -> .e1;
nw.e1[physically_present != no]['naptan:BusStopType' != HAR] -> .e1;
nw.e1[!tactile_paving] -> .e7;
nw.e1[tactile_paving = no][tactile_paving](if: date(timestamp()) < date('2016-08-20') || date(t['tactile_paving:check_date']) < date('2016-08-20') || date(t['check_date:tactile_paving']) < date('2016-08-20') || date(t['tactile_paving:lastcheck']) < date('2016-08-20') || date(t['lastcheck:tactile_paving']) < date('2016-08-20') || date(t['tactile_paving:last_checked']) < date('2016-08-20') || date(t['last_checked:tactile_paving']) < date('2016-08-20')) -> .e8;
nw.e1[tactile_paving](if: date(timestamp()) < date('2012-08-20') || date(t['tactile_paving:check_date']) < date('2012-08-20') || date(t['check_date:tactile_paving']) < date('2012-08-20') || date(t['tactile_paving:lastcheck']) < date('2012-08-20') || date(t['lastcheck:tactile_paving']) < date('2012-08-20') || date(t['tactile_paving:last_checked']) < date('2012-08-20') || date(t['last_checked:tactile_paving']) < date('2012-08-20')) -> .e9;
(.e7; .e8; .e9;);
out meta geom;

AddCyclewaySegregation

  • tags check_date:segregated for shared foot and bike paths
  • asked every 8 years
Asked For Elements...
ways with
(
  (highway = path and bicycle = designated and foot = designated)
  or (highway = footway and bicycle = designated)
  or (highway = cycleway and foot ~ designated|yes)
)
and surface ~ paved|asphalt|cobblestone|cobblestone:flattened|sett|concrete|concrete:lanes|concrete:plates|paving_stones|metal|wood|unhewn_cobblestone
and area != yes
and (!segregated or segregated older today -8.0 years)
Overpass Query
[bbox:{{bbox}}];
way[highway = path][bicycle = designated][foot = designated] -> .w2;
way[highway = footway][bicycle = designated] -> .w3;
way[highway = cycleway][foot ~ '^(designated|yes)$'] -> .w4;
(.w2; .w3; .w4;) -> .w1;
way.w1[surface ~ '^(paved|asphalt|cobblestone|cobblestone:flattened|sett|concrete|concrete:lanes|concrete:plates|paving_stones|metal|wood|unhewn_cobblestone)$'][area != yes] -> .w1;
way.w1[!segregated] -> .w5;
way.w1[segregated](if: date(timestamp()) < date('2012-08-20') || date(t['segregated:check_date']) < date('2012-08-20') || date(t['check_date:segregated']) < date('2012-08-20') || date(t['segregated:lastcheck']) < date('2012-08-20') || date(t['lastcheck:segregated']) < date('2012-08-20') || date(t['segregated:last_checked']) < date('2012-08-20') || date(t['last_checked:segregated']) < date('2012-08-20')) -> .w6;
(.w5; .w6;);
out meta geom;

AddHandrail

  • tags check_date:handrail for stairs
  • asked every 4 years if the stairs do not have a handrail yet
  • otherwise asked every 8 years
Asked For Elements...
ways with highway = steps
 and access !~ private|no
 and (!conveying or conveying = no)
 and (
   !handrail
   or handrail = no and handrail older today -4.0 years
   or handrail older today -8.0 years
 )
Overpass Query
[bbox:{{bbox}}];
way[highway = steps][access !~ '^(private|no)$'] -> .w1;
way.w1[!conveying] -> .w2;
way.w1[conveying = no] -> .w3;
(.w2; .w3;) -> .w1;
way.w1[!handrail] -> .w4;
way.w1[handrail = no][handrail](if: date(timestamp()) < date('2016-08-20') || date(t['handrail:check_date']) < date('2016-08-20') || date(t['check_date:handrail']) < date('2016-08-20') || date(t['handrail:lastcheck']) < date('2016-08-20') || date(t['lastcheck:handrail']) < date('2016-08-20') || date(t['handrail:last_checked']) < date('2016-08-20') || date(t['last_checked:handrail']) < date('2016-08-20')) -> .w5;
way.w1[handrail](if: date(timestamp()) < date('2012-08-20') || date(t['handrail:check_date']) < date('2012-08-20') || date(t['check_date:handrail']) < date('2012-08-20') || date(t['handrail:lastcheck']) < date('2012-08-20') || date(t['lastcheck:handrail']) < date('2012-08-20') || date(t['handrail:last_checked']) < date('2012-08-20') || date(t['last_checked:handrail']) < date('2012-08-20')) -> .w6;
(.w4; .w5; .w6;);
out meta geom;

AddCyclewayPartSurface

  • tags check_date:cycleway:surface for segregated cycleways/paths
  • asked every 8 years
Asked For Elements...
ways with
(
  highway = cycleway 
  or (highway ~ path|footway and bicycle != no)
  or (highway = bridleway and bicycle ~ designated|yes)
)
and segregated = yes
and (!cycleway:surface or cycleway:surface older today -8.0 years)
Overpass Query
[bbox:{{bbox}}];
way[highway = cycleway] -> .w2;
way[highway ~ '^(path|footway)$'][bicycle != no] -> .w3;
way[highway = bridleway][bicycle ~ '^(designated|yes)$'] -> .w4;
(.w2; .w3; .w4;) -> .w1;
way.w1[segregated = yes] -> .w1;
way.w1[!'cycleway:surface'] -> .w5;
way.w1['cycleway:surface'](if: date(timestamp()) < date('2012-08-20') || date(t['cycleway:surface:check_date']) < date('2012-08-20') || date(t['check_date:cycleway:surface']) < date('2012-08-20') || date(t['cycleway:surface:lastcheck']) < date('2012-08-20') || date(t['lastcheck:cycleway:surface']) < date('2012-08-20') || date(t['cycleway:surface:last_checked']) < date('2012-08-20') || date(t['last_checked:cycleway:surface']) < date('2012-08-20')) -> .w6;
(.w5; .w6;);
out meta geom;

AddFootwayPartSurface

  • tags check_date:footway:surface for segregated footways/paths
  • asked every 8 years
Asked For Elements...
ways with
(
  highway = footway 
  or (highway ~ path|cycleway|bridleway and foot != no)
)
and segregated = yes
and (!footway:surface or footway:surface older today -8.0 years)
Overpass Query
[bbox:{{bbox}}];
way[highway = footway] -> .w2;
way[highway ~ '^(path|cycleway|bridleway)$'][foot != no] -> .w3;
(.w2; .w3;) -> .w1;
way.w1[segregated = yes] -> .w1;
way.w1[!'footway:surface'] -> .w4;
way.w1['footway:surface'](if: date(timestamp()) < date('2012-08-20') || date(t['footway:surface:check_date']) < date('2012-08-20') || date(t['check_date:footway:surface']) < date('2012-08-20') || date(t['footway:surface:lastcheck']) < date('2012-08-20') || date(t['lastcheck:footway:surface']) < date('2012-08-20') || date(t['footway:surface:last_checked']) < date('2012-08-20') || date(t['last_checked:footway:surface']) < date('2012-08-20')) -> .w5;
(.w4; .w5;);
out meta geom;

AddWheelchairAccessToiletsPart

  • tags check_date:toilets:wheelchair
  • asked every 4 years if there wasn't any wheelchair accessible toilet before
  • otherwise asked every 8 years
Asked For Elements...
nodes, ways, relations with name and toilets = yes
 and (
   !toilets:wheelchair
   or toilets:wheelchair != yes and toilets:wheelchair older today -4.0 years
   or toilets:wheelchair older today -8.0 years
 )
Overpass Query
[bbox:{{bbox}}];
nwr[name][toilets = yes] -> .e1;
nwr.e1[!'toilets:wheelchair'] -> .e2;
nwr.e1['toilets:wheelchair' != yes]['toilets:wheelchair'](if: date(timestamp()) < date('2016-08-20') || date(t['toilets:wheelchair:check_date']) < date('2016-08-20') || date(t['check_date:toilets:wheelchair']) < date('2016-08-20') || date(t['toilets:wheelchair:lastcheck']) < date('2016-08-20') || date(t['lastcheck:toilets:wheelchair']) < date('2016-08-20') || date(t['toilets:wheelchair:last_checked']) < date('2016-08-20') || date(t['last_checked:toilets:wheelchair']) < date('2016-08-20')) -> .e3;
nwr.e1['toilets:wheelchair'](if: date(timestamp()) < date('2012-08-20') || date(t['toilets:wheelchair:check_date']) < date('2012-08-20') || date(t['check_date:toilets:wheelchair']) < date('2012-08-20') || date(t['toilets:wheelchair:lastcheck']) < date('2012-08-20') || date(t['lastcheck:toilets:wheelchair']) < date('2012-08-20') || date(t['toilets:wheelchair:last_checked']) < date('2012-08-20') || date(t['last_checked:toilets:wheelchair']) < date('2012-08-20')) -> .e4;
(.e2; .e3; .e4;);
out meta geom;

@kmpoppe
Copy link
Collaborator

kmpoppe commented Aug 21, 2020

@westnordost Am I missing something or is and opening_hours resurvey no longer part of the maintenance concept?

@westnordost
Copy link
Member Author

It's still work in progress, that is why it is not in the list.

@matkoniecz
Copy link
Member

matkoniecz commented Aug 23, 2020

Order by importance/how sure I am.

AddRoadSurface
tags check_date:surface on roads
asked every 4 years for unpaved roads
otherwise asked every 8 years

Asking for surface=asphalt every 8 years seems dubious to me.

Asking about surface=asphalt on tracks and footways may make sense, but why ever ask about highway=primary surface=asphalt? What are the chances that it was replaced by something else?

AddTracktype

I it possible to ask quicker if it conflicts with surface?

surface=sand tracktype=grade1 type of thing

AddPostboxCollectionTimes (...) otherwise every two years

Is it showing what was tagged?

I noticed that in some regions all postboxes are tagged with the same hour.

Two years seems a bit too often for me.

AddRecyclingContainerMaterials asked every 2 years

Seems significantly too frequent to me.

AddHandrail

I would ask once 16 years if tagged as with handrail

@thibaultmol
Copy link

Asking about surface=asphalt on tracks and footways may make sense, but why ever ask about highway=primary surface=asphalt? What are the chances that it was replaced by something else?

Because a concrete road might turn into an asphalt road at some point.
A paving_stones road might turn into asphalt or the other way around.
Things like this T-junction might happen where they put paving_stones stones all of a sudden:
image

I don't see the problem with 8 years. It's a really long time.

I would ask once 16 years if tagged as with handrail

Again, I think the suggested hours by @westnordost are fair. A lot of things can happen in 4 or even 8 years!

@matkoniecz
Copy link
Member

matkoniecz commented Aug 23, 2020

A paving_stones road might turn into asphalt or the other way around.

I think that chances of surface=asphalt changing to something else with major* roads are extremely small

*other than pedestrian/living_street/service

@westnordost westnordost reopened this Aug 31, 2020
@dbf256
Copy link

dbf256 commented Sep 1, 2020

Sorry if I got something wrong, but is there a quest that will ask is POI (mostly like shop/cafe that open/closes frequently) is still in place? I had issue with OSM maps several times spending my time to walk to the shop and it was closed already for a long time.
I think it could be useful.

@westnordost
Copy link
Member Author

No, it will not. StreetComplete currently lacks the ability to delete POIs, by I intend to add this later - not as part of the "Map Maintenance with StreetComplete" project sponsored by the OSMF though.

If you are thinking about a new quest where the app would tag a vacant shop as shop=vacant instead, this may be possible already but we'd have to discuss it in more detail in a separate ticket.

@westnordost
Copy link
Member Author

Anyone interested in testing the new StreetComplete version with the map maintainance (resurvey) feature? I just released an alpha. you can simply install the APK linked here over your Google Play install:

https://github.com/westnordost/StreetComplete/releases/tag/v23.0-alpha1

(If you got the app from F-Droid, you need to uninstall it first)

@mmd-osm
Copy link

mmd-osm commented Sep 5, 2020

Quick comment on the overpass queries: it would probably make sense to use is_date to make sure that a tag value contains a valid timestamp. Otherwise a date comparison may behave in unexpected ways for garbage input data.

@westnordost
Copy link
Member Author

Noted, thank you. Though I think I'll leave it as it is because I see no reason to exclude objects from resurvey forever because someone supplied the check date in an invalid format. If garbage data leads to the quest being asked again, the better. The best would be if it was asked especially if it is in an unparsable format, but I didn't find a way to express this in a compact query.

@mmd-osm
Copy link

mmd-osm commented Sep 6, 2020

You don’t need to exclude invalid ones, just make sure that the date comparison is meaningful:

( !is_date( t[ ...]) || date(t['cycleway:surface:check_date']) < date('2012-08-20'))

@westnordost
Copy link
Member Author

Does !is_date(t['a_tag_that_is_not_set']) not always evaluate to true?

@mmd-osm
Copy link

mmd-osm commented Sep 6, 2020

I haven’t tested it but is_tag() should be able to cover this case.

@matkoniecz matkoniecz unpinned this issue Sep 9, 2020
@matkoniecz matkoniecz pinned this issue Sep 9, 2020
@westnordost
Copy link
Member Author

This is the final report for the OSMF: https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Map_Maintenance_with_StreetComplete/Report

@RubenKelevra
Copy link
Contributor

I created a draft to propose a change in the tagging of implicit maxspeed values to fix this issue:

https://wiki.openstreetmap.org/wiki/Proposed_features/implicit_maxspeed

@westnordost
Copy link
Member Author

I answered in the discussion section. The Proposal as it is will not solve the issue.

@dieterdreist
Copy link

dieterdreist commented Sep 7, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.