Add clarifications / details for quests

[Helium314]

There are many situations where I am/was not sure how to answer. Often it was possible to find an answer here on github or in the OSM wiki, sometimes not. Since I see I am not the only one who sometimes doesn't know how to answer (example: #1889), I think it would be beneficial to have answers for relatively common situations provided directly in the app, behind some sort of "details" button (or maybe a link to the corresponding page in the OSM wiki, but often this is not particularly helpful). Some of the questions/problems might not have a clear answer, but for those that have this "details" button could help.

I gathered a bunch of examples where I was not sure and looked up the answer, or where I still don't know how to handle it correctly. For some of them the answer seems rather obvious to me now, but initially it wasn't.

• lit (mostly when light is coming from nearby streets)
  • how bright does it need to be to be count as lit: see other people? be able to spot dog droppings on the ground? read a plan?
  • does it have to be lit full width?
  • when does a sports field neet to be lit to answer yes?
• surfaces
  • ~difference between paving stones and sett~ (better with the updated images)
  • what surfaces are tiles / natural stones (#3189, #616)
  • how precise should I be when splitting a path?
    • e.g. 2 m sett driveway on asphalt pavement?
    • e.g. 30 cm concrete speed bump on asphalt road?
    • what about crossing streets/paths with different surfaces?
  • different surfaces across the road
    • ~e.g. one lane concrete, one lane asphalt~
    • ~e.g. asphalt with paving stone patterns~
    • should just be paved, which forces adding a note (which is rather tedious for long roads with many segments)
• building type
  • detached house: simply defined by no contact to other houses?
  • semi-detached: should the halves be similar? What about top/bottom separation (#2685)
  • ~apartment building: what is the difference to a house?~ (single family in description should be sufficient)
  • "changed" buildings
    • e.g. old apartment building containing only offices
    • e.g. old industrial building containing apartments
    • there were issues about that, but it's not mentioned in the app
  • what kind of building is
    • container, driveway to underground parking, staircase, elevator, "cage with roof and walls" (often containing garbage/recycling containers or bicycle parking)
    • bus stop shelter: public transport or roof? (probably should be amenity=shelter)
    • subway/metro: public transport or train station?
• building levels
  • what is the lowest level (unclear semi-undergroud levels)
    • windows above ground, but no entrance
    • door with immediate steps down (steps outside or inside the building)
    • driveway/ramp to a garage in the cellar
  • how do levels on the roof count
    • e.g. flat roof with some small "building"
  • what if one part has x levels and 1 in the roof, other part has x+1 levels and none in the roof?
  • when does a level count as "in the roof"?
    • especially unclear for flat roofs where the top level is often smaller than the others
• roof shape
  • what to use for "half" roofs (half gabled exists as skillion, others have no equivalent)
  • what if the two ends are different? common for gabled and hipped
  • gabled roof at a corner: is this already hipped?
  • for questions/discussions: having names of the shapes would help!
• name of place
  • do generic names like information, butcher, exchange count as names?
  • should "type names" be included? The type-name combination often feels like the "correct" name for small shops, e.g. "Hair Salon Herbert", or "Cosmetics Anna"
• wheelchair
  • when is a kiosk accessible? Doe it depend on height of counter?
  • is there some minimum door width?
  • height limits for that one step for partial access? OSM wiki mentions 7 cm
  • what if there is a button/doorbell to get assistance?
  • no direct obstacle, but steep paths with bad surfaces (grass, compacted,...)
  • the current descrition is focused on indoor. Answering no even if a reastaurant has accessible outdoor seating is corect according to description, but feels wrong
  • what if the feature is accessible, but the path is not (e.g toilets with wheelchair sign, but the pavement is not wheelchair-compatible)
• pavement
  • what counts as a pavement? The intuitive understanding seems to vary across languages (even for sidewalk and pavement I would answer differently)
  • multi-lane roads: should I add the pavement for each lane, or only the closest one?
  • often there are roads "embedded" in a square - there is no pavement directly at those roads, and it is not mapped separately, but the square has pavements.
  • pavement separated from the road by grass or trees: does it still count as pavement of that road?
  • separate path on one side only, but pavement on both sides - what to answer? (I think change if the sidewalk quest for this is already planned)
• tactile pavings: is it really no if there is a tactile paving along the crossing, but not at the end?
• bridges: names and a short description of each type would sometimes be very helpful, as many bridges seem to be "between" two of the provided images (often a very slight arch only, almost like a beam bridge)
• who is allowed to park here: what if only specific vehicles, e.g. buses?

I don't need the answers here, this is only about whether such clarifications should be added to the app... at least the ones that fit in one or two sentences.

[matkoniecz]

I was just now thinking how to help people confused by surface=paving_stones

For some cases it was done already, see say #917

I wonder whatever @westnordost would prefer to split this issue into smaller fixable parts.

[Helium314]

Yes, maybe it can be split...

In some cases the "other answers" could be used/expanded, here the only question is what should/could be added.

When there are many answers (like for surfaces or bridges) it would be more helpful to have some additional information for each answer. Here there is the additional question of how to provide the additional text (e.g. button in image or long press)

[smichel17]

It seems like the main value of noting there are many different quests with the same issue, is that it might make sense to add a standard UI element (eg, a ℹ️ button) for opening a clarification dialog, in cases where it is hard to fit all the nuance into the regular dialog.

It might also be a good idea to have a nearby UI component for sending feedback that a quest is unclear. Along the lines of a "Get clarification about this quest" action. I think that could lead to a lot of good information about which quests are confusing that we didn't realize before. Possible concern: it might generate too much support work if it were just delivered as an email (or osm pm?) to @westnordost or something. Is it possible to create new GitHub issues from email?

As for what clarifying information to add, I think that's probably easier to handle per-quest as confusion arises. Otherwise this issue will get looong.

[westnordost]

Most of the things you mention though are insecurities that are caused by a lax definition of the tag itself in OSM (in the wiki).

For some others you mention, there are simply no defined tags in OSM. So, the best action here is actually to leave a note, choose the next best thing or don't solve it.

The idea with the ℹ️ button is good, it could be shown left of the question in the question-bubble. Much information currently in small text and some "other answers..." within the answer-bubble could be moved into the dialog that pops up when clicking that button.

[matkoniecz]

Most of the things you mention though are insecurities that are caused by a lax definition of the tag itself in OSM (in the wiki).

And for some there is no clear agreement at all, for example I raised issue of

lit (mostly when light is coming from nearby streets)

on the mailing list and answers were contradictory, proposing very weird ideas or were misunderstanding the problem. And I decided that keeping definition vague and unclear is the best solution given alternatives.

[smichel17]

It might also be a good idea to have a nearby UI component for sending feedback that a quest is unclear.

I suppose we already have a method for this: Adding notes ("I'm not sure how to tag this because XYZ"). So really this is only about steering people towards notes a little more strongly. Note: I personally often forget or don't think to add notes — I end up just leaving the quest unanswered or hiding it instead. I'm not sure how much this is a personal problem or common among other people.

[Helium314]

Most of the things you mention though are insecurities that are caused by a lax definition of the tag itself in OSM (in the wiki).

This is why I hestitated to submit this issue (which I actually had half finished more than a month ago)... But then I remembered how frustrated I was initially about these unclear definitions and left many quests open. Now I sometimes catch myself going like "yeah, whatever. at least it's not wrong" when giving some answer I am not really certain about, and I think this is not how mapping should be done... so I'm trying to improve things at least a little bit.

[matkoniecz]

And even in cases where tag in unclearly defined it may be useful to have "do not worry too much about borderline issues" advise.

[peternewman]

It might also be a good idea to have a nearby UI component for sending feedback that a quest is unclear.

I suppose we already have a method for this: Adding notes ("I'm not sure how to tag this because XYZ"). So really this is only about steering people towards notes a little more strongly.

For some, like paving stone/sett and changed buildings, the wiki is quite clear, it's just a case of exposing that to people in a simple way within the app.

[peternewman]

Most of the things you mention though are insecurities that are caused by a lax definition of the tag itself in OSM (in the wiki).

The idea with the information_source button is good, it could be shown left of the question in the question-bubble.

Given (as I spotted by accident in the code), there is already a documentation link on the profile bubble view of our quest progress which links to the relevant wiki article, as a first step would it be worth just adding a link to that, perhaps explaining this is the wiki and it might not help (or something more friendly)? Given it requires no work in writing or translating anything and might provide some initial benefit?

[Helium314]

Sorry for not replying earlier... didn't have enough time for this.

So if the [I] button should be added, it could contain an explanatory text similar to what is found in the OSM wiki (and maybe a link to the relevant page in the wiki) for some quests:

• building type: https://wiki.openstreetmap.org/wiki/Key:building#Values
• bridge: https://wiki.openstreetmap.org/wiki/Key:bridge#Values
• surface: https://wiki.openstreetmap.org/wiki/Key:surface
• track firmness: https://wiki.openstreetmap.org/wiki/Key:tracktype
• wheelchair (partial): https://wiki.openstreetmap.org/wiki/Key:wheelchair#wheelchair.3Dlimited

[Echolon]

Just confirming that elevator buildings are also not being recognised or able to tag

[Vinnl]

Additional item that could use clarification:

• Is this stretch of way lit - I only selected "Yes" when there was an actual street lamp on the stretch of way, but it turns out that I should've said Yes when it was lit by a street lamp on a nearby stretch of way as well.

(Thought that this was probably a better place to log this than an entire new issue.)

[matkoniecz]

@Helium314

difference between paving stones and sett

Is it still a problem? Some changes were made, also with intention of clarifying it.

[Helium314]

Is it still a problem? Some changes were made, also with intention of clarifying it.

There is the new image, right? I think it's better now. Not 100% sure if I would say it's not a problem any more... When I wrote this list I tried to remember questions and problems I had initially (just using the app, not knowing about OSM wiki). So it's hard to say whether having the new image would have helped, but I lean towards yes. Ideally I should erase my memory and try starting again.

(actually I think more than just this is solved now. I will take some time and update the initial post)

[matkoniecz]

I will take some time and update the initial post

That would be helpful! There was also attempt to resolve/reduce other issues, partially motivated by this list so it would be interesting to see where it was succesfull.

Not sure what @westnordost thinks about this but maybe it would be more digestible as separate issues.

[westnordost]

I think this issue is about introducing such a "more info" button (in a well-reusable fashion) in the first place

[smichel17]

Refining https://github.com/streetcomplete/StreetComplete/issues/2322#issuecomment-735022016, I suggest:

• Rename the "More options" menu to "Can't say", always with the same 3 options:
  • Hide this quest ⇒ does the same thing as current | More options > Can't say > No, just hide
  • Leave a note instead ⇒ same thing as current | More options > Can't say > Ok
  • More info ⇒ Shows FAQ, with answers to the questions above, and optionally a link to the OSM wiki. It could appear as a dialog, new page, in the form itself (below the answers), etc.
• Move extra information (e.g. building type ⇒ "It has multiple purposes") into the FAQ
• Move uncommon answers (e.g. street name ⇒ "It has no name") into the main body of each form

Most of the work would be adapting forms to include uncommon answers, since each form is different.

[HaasJona]

The biggest tagging problem in my experience here is the "is lit" quests for bus stops. Bus stops are rarely lit themselves (except in some cases small utility lights that allow you to read the departure times and map at night, but not enough to feel safe) but on the other hand, the road itself is usually lit bright enough.

In such cases I'd probably answer that yes,it's lit but some guidance would be good.

[Helium314]

I've been going through this once more, and still think such an :information_source: button would be very helpful for several (definitely not all) quests.

But there is no single place where I would put that button. In most cases it would go next to the question, but sometimes it's actually some of the answers where additional information would help (e.g. surfaces or bridge types). In the latter case, no button is needed: if the answer is selected, there could just be additonal text inserted, see the badly edited example picture: (asphalt picture was available, even though this surface doesn't need a special description)

For the :information_source: next to the question, the current description text could simply be extended (or added of there is none).

[bash-git]

Maybe for a first fix it would be enough to add a ?-button so the related OSM-Wiki-page. Additional information in the question would be really helpfull but it is a lot of work. Sometimes the OSM-entry is enough.

[matkoniecz]

Note that description of tags on OSM Wiki often offers no clue how user should answer in SC or is very distantly and unclearly related. For example no single page at OSM Wiki will help how to answer cycleway quest (#4410)

[smichel17]

It seems like a good first step would be to start compiling the relevant information/links into an FAQ style page, organized by quest. It can be split up into multiple pages or incorporated directly into the app later, but none of that is really realistic without first having a concise list of which information should be surfaced.

If I remember correctly, there is already a general "StreetComplete FAQ" page on the OSM wiki, so I suggest either adding to that or adding a new page alongside it. Alternatively, the GitHub wiki here could be (re?)enabled, or we could use a text/markdown file in the repo.

[matkoniecz]

I was kind of doing something related - for example recently (and not so recently) I spend a lot of time on improving documentation of surface tags on OSM Wiki, to match actual use. This also reduced or removed divergence between OSM Wiki claims and StreetComplete use of tags.

[riQQ]

There are now links to tags in the undo history (see #4419). It's a start but in my opinion there should an option to get more information before answering like proposed in https://github.com/streetcomplete/StreetComplete/issues/1913#issuecomment-648845579.

[westnordost]

I think the best way to implement this would be in the AbstractQuestForm, i.e. have a protected fun setHintLayout(resourceId: Int) (or protected open val hintLayoutResId: Int? = null?) or similar and if it is non-null, a toggle-info-button is shown that shows/hides the additional info. So this can then be a text, or also text with images, etc.

As a matter of fact, for many quests, such info text is already displayed, but, always. For experienced users, who have already read that hint, it would also make the overall look and feel more clean to because they hint is only displayed when one taps on the hint button.

[westnordost]

Even better or at least restricting to a more consistent UI and making it easier to define these for (new) quests - to QuestType interface, add:

val hintText: Int? = null
val hintImages: List<Int?> = emptyList()

If any of the two are specified, an ℹ️ button is shown, allowing you to expand (and retract) the hint text plus images.

This has not the highest priority for me, though if a few people are found who would like to work together on this, I'd be more motivated to provide the framework for this. Motivation for me to work on this mostly stems from the prospect of having a consistent API for such hints and thus also reducing the number of custom layouts in quests (i.e. reduce layout code).