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 (Add "stone" option for surface quests #3189, further surface type: tiles #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.)