- 1 User related
- 1.1 I cannot login via OAuth!
- 1.2 Do I need to be an OpenStreetMap expert to use it?
- 1.3 Why does StreetComplete show so few quests when I first start the app?
- 1.4 How can I hide a type of quest? or How to prefer some types of quests?
- 1.5 I did a mistake. What to do?
- 1.6 Why can't I disable/change the order of the notes quest ()?
- 2 Technical
I cannot login via OAuth!
Are you using LineageOS with the default browser (Jelly)? Use another one for authorization. This issue is bug in Jelly and is tracked in BUGBASH-1393.
Do I need to be an OpenStreetMap expert to use it?
Absolutely no, the app is designed to be usable by anyone, this includes people who have never heard about OpenStreetMap. It, however, also eases editing for OSM experts.
So spread the word! Anyone can use the app.
Why does StreetComplete show so few quests when I first start the app?
SteetComplete heavily relies on Overpass to gather its data. The app limits its own queries to Overpass to avoid putting an excessive load on the server. Thus, even if you manually download the quests, it will only download the most common quest types. You can circumvent this restriction by clicking download again after the first download process finished, but it is better to disable the quest types you are not interested in in the settings. The app will then only download the remaining quest types.
Please note that quests are downloaded per quest, i.e. it does not and cannot download all quests for the area where you currently are, at once. With multiple requests you will see how some new quest types “pop up” over time.
How can I hide a type of quest? or How to prefer some types of quests?
In the settings at the bottom, you can find a button, which will take you to a list of all quests ordered by the priority they are downloaded and appear on the map. There, you can also disable or enable quest to hide, respectively show, them on the map.
I did a mistake. What to do?
In the top right, you can revert the change. If you already solved other quests in the meantime, this may however be inconvenient. In such a case, just use another editor (e.g. to openstreetmap.org), login and revert your change there. If you don't know what exactly StreetComplete changed you can or have a look at the quest type you solved in the quest list.
A note is there to indicate a problem with the data there, so it indicates that "something is wrong with this element", so no quests for this should be created. For example if someone answered "This shop does not exist anymore", then, of course, the app cannot use the current data as it is in the OSM database as a base for creating a quest, because one thing or another might be incorrect now.
Especially notes that have been created with StreetComplete (via the "Other answers…" menu) thus "block" other quests from showing up. This makes sure that once a StreetComplete user cannot answer a quest, the quest is not shown again to other users.
How does the app handle uploads?
By default, the app uploads each answer the user gives immediately. If there is no connection, it stores the change on the phone and tries again later.
For each different type of quest, it creates an own changeset. This changeset will have a short message what it is about, i.e. "Add street surfaces", and set the tags for created_by and source. Example.
The changeset is kept open while the user subsequently adds information on his survey. If the user erred and undoes already uploaded changes, the reverts (and the subsequent corrections) are also added to the same changeset. After the user did not add anything to the changeset for more than 20 minutes, the app closes it. If there is no connection then or the phone is off, the changeset will latest be closed after one hour (because that is the timeout of the API).
If during upload of the changes, it turns out that the changeset has been closed already, the app will simply create a new changeset and add the changes there.
How does the app handle conflicts?
In a nutshell, the app tries to solve conflicts automatically, and if one is not solvable, drops the conflicting change made by the user silently and subsequently refreshes the data for the user in the vicinity of where the conflict happened.
Each answer to a quest only modifies exactly one element and each of these answers are uploaded separately. So, when conflicts arise, they arise for single elements separately. This makes it simple to solve them automatically. Divide and conquer.
First, the app downloads the newest version of the element for which the conflict occurred. Then, it checks whether the quest type for which the answer was given still applies to the new version of the element. I.e. if a previously unnamed street now has a name, the AddRoadName quest does not apply anymore to that element.
If that check succeeded, the change is again applied to the element (like a diff/patch). If applying the change went without conflict, the modified element is then uploaded.
Thus, a conflict is considered as not automatically solvable, if any tag that the app meant to add/change/delete on the element in question has been added/changed/deleted in the meantime. Other parallel changes on the same element are handles with no problem.
How does StreetComplete select the to be modified data and what exactly does it tag?
There is an extensive list in the wiki with all that information. See StreetComplete/Quests.
Why does StreetComplete often tag the absence of features?
You probably heard that if a feature is not tagged, the assumption is of course, that it is not there. I.e. if it is not tagged whether a street is lit, it means that it is not. However, this is an assumption the data consumer has to make when it is dealing with incomplete data. The absence of a tag is in no way equivalent to any value - it is what it is - unspecified.
So the reason why StreetComplete tags also the absence of features is to indicate that a user surveyed the place and determined that the feature is indeed absent, i.e. a street is not lit. The distinction of whether a feature has been surveyed or whether it is simply unspecified is an important information for other surveyors and thus for the maintainability of the map.
That being said, the app takes great care to limit the amount of quests where the answer can be assumed to always be the same (i.e. “no”) with a relative certainty.
As an example, the cycleway quest is only shown for a certain subset of roads which additionally do not have any cycleway tagging in any form (including separately mapped cycleways), which don't have a speed limit set to 30 km/h and below and are not unpaved. Additionally, the quest is only shown in certain countries, where it can be assumed that (sometimes) dedicated bicycle infrastructure is present in the first place.