Confusing markings on way lit overlay about streetcomplete HOT 8 CLOSED

In the end, I chose a similar solution as for the building overlay. Unsupported values are displayed specifically as such. Using a different color, and when tapping on it, the selected entry is titled Specific lit status that is not selectable in this app.

from streetcomplete.

In my opinion, the root issue is that lit mixes physical presence of lanterns with whether it is actually lit.

I would expect it to cover is it actually lit.

Isn't it a bit of a troll-tag, though?

As someone who invented this term: no. Troll tag would something like lit=yes not_actually_lit=yes - extra tag inverting or changing tagging of more general tags - rather than clarifying them or adding extra detail.

(in either case #5571 (comment) works well)

from streetcomplete.

Hm, to summarize, there is no good solution to this.

In my opinion, the root issue is that lit mixes physical presence of lanterns with whether it is actually lit. Given the mere presence of the more uncommon values, it looks like the tag is about whether and when the lanterns are lit, on the other hand, yes and no values absolutely dominate the space with almost 99% of usages (while sunset-sunrise is used more than 100x less than yes) which is a strong indicator that the absolute majority of mappers see lit being about the physical presence, rather than the times when the lanterns are on. At the very least, we can say that there are different competing tagging practices.

StreetComplete somewhat leans to only supporting the tagging of physical presence, because this is the tagging that is actually surveyable on-site with reasonable effort. For the "lit-times" tagging, one has to theoretically be on-site at various hours during the night to even just determine whether it is lit for the whole night. At the same time, we take care not to destroy the data captured with the "lit-times"-tagging, which is why we support the more popular tags like automatic and 24/7 and treat unsupported values the same as yes for display because any value should indicate that there is lighting, but it is limited in one way or another (after all, according to the wiki, one may enter any kind of opening hours last time I checked).

disused falls right into the divide between these two interpretations of lit, as it would be yes to the physical presence (what the user sees during day), but no to it actually being lit. Isn't it a bit of a troll-tag, though? Wouldn't it be better to use lifecycle prefix in this case?

(As you see) I ran this again through my brain, but I am still at a loss of a good solution.

• not including ways tagged with an unsupported value at all would feel like a bug
• including ways tagged with an unsupported value but not allowing them to be edited would feel like a bug
• using a different color but displaying them as "yes" when tapping on them would definitely feel like a bug
• leaving it as-is may destroy disused data, at least when mappers use the overlay during night

from streetcomplete.

I agree... Looking at:

it seems that current behaviour is that UNSUPPORTED values (like limited & disused) are colored the same as lit=yes (with LIME), and you can edit them, but if you choose answer YES it will not actually change the value to lit=yes but will leave it at whatever it was (and only update the check_date). Choosing other values will set them normally though (e.g. if Unlit is chosen, lit=no will be tagged normally)

While I get what why it was done (prevent damaging existing data), I find such magical behaviour totally unexpected. (and also, disused

I would prefer (better options at top) that either:

• LitStatus.UNSUPPORTED values should not be editable in Lit overlay at all (and also thus probably should not be colored either); or
• if they remain semi-editable like now, at least UNSUPPORTED should have different color from YES (and other values) to reduce confusion. Maybe ORANGE or CYAN?
  

  StreetComplete/app/src/main/java/de/westnordost/streetcomplete/overlays/way_lit/WayLitOverlay.kt

  Lines 50 to 57 in 3633fe5

  	private val LitStatus?.color get() = when (this) {
  	LitStatus.YES,
  	LitStatus.UNSUPPORTED -> Color.LIME
  	LitStatus.NIGHT_AND_DAY -> Color.AQUAMARINE
  	LitStatus.AUTOMATIC -> Color.SKY
  	LitStatus.NO -> Color.BLACK
  	null -> Color.DATA_REQUESTED
  	}

• as a least preferable option, disused should be used as a synonym for no, not yes. But as such "fix" would not address confusion issue with limited and other rare values; I'd really prefer one of the above solutions instead.
• one might theoretically support each of limited, disused, interval etc. directly, but question with so many answers would then likely overwhelm the users (and we'd run out of colorblind-friendly colors); so probably not really great solution either

from streetcomplete.

if they remain semi-editable like now, at least UNSUPPORTED should have different color from YES (and other values) to reduce confusion. Maybe ORANGE or CYAN?

that would not remove confusion as they would be described exactly like yes when tapped

from streetcomplete.

I agree that showing disused is problematic, as both coloring it like "yes" or "no" would be confusing. At the same time I don't want to promote this pretty rare tag by directly supporting it. On the other hand, disallowing users to edit such roads and not marking them with any color at all will 100% lead to confusion and users thinking this is a bug.

from streetcomplete.

disused seems to be safe to show as no?

(unless you are likely to get cases where you have street lights which appear to be in good order but are not switched on anyway during night?)

from streetcomplete.

No. During day, disused can look exactly like yes.

from streetcomplete.