Closed rhhsm closed 2 months ago
matkoniecz
commented
2 months ago quest_address_unusualHousenumber_confirmation_description quest_streetName_nameWithAbbreviations_confirmation_description are these commonly appearing in your regular editing? This is supposed to appear rarely and help catch typos.
(quest_split_way_many_splits_confirmation_description is on the other side, now that you mention it: I would love to not see it again)
rhhsm
commented
2 months ago
quest_address_unusualHousenumber_confirmation_descriptionquest_streetName_nameWithAbbreviations_confirmation_descriptionare these commonly appearing in your regular editing? This is supposed to appear rarely and help catch typos.
These are Bulgaria-specific: block numbers are entered in the House Number field, preceded by "бл. " (which SC finds "unusual") and words such as Булевард (boulevard) and Площад (square) are abbreviated in street names (Улица=street is completely omitted). I can live with these popups, unless it's easy to make an exception for Bulgaria?
matkoniecz
commented
2 months ago These are Bulgaria-specific: block numbers are entered in the House Number field, preceded by "бл. " (which SC finds "unusual") and words such as Булевард (boulevard) and Площад (square) are abbreviated in street names (Улица=street is completely omitted). I can live with these popups, unless it's easy to make an exception for Bulgaria?
We have https://github.com/streetcomplete/countrymetadata/blob/master/data/additionalValidHousenumberRegex.yml entirely to prevent spurious quest_address_unusualHousenumber_confirmation_description
rhhsm
commented
2 months ago These are Bulgaria-specific: block numbers are entered in the House Number field, preceded by "бл. " (which SC finds "unusual") and words such as Булевард (boulevard) and Площад (square) are abbreviated in street names (Улица=street is completely omitted). I can live with these popups, unless it's easy to make an exception for Bulgaria?
We have https://github.com/streetcomplete/countrymetadata/blob/master/data/additionalValidHousenumberRegex.yml entirely to prevent spurious
quest_address_unusualHousenumber_confirmation_description
So it's easy to add that Housenumber in Bulgaria can contain the string "бл." (with or without a space following it)?
The use of abbreviations such as бул. in street names is documented here https://wiki.openstreetmap.org/wiki/Bg:WikiProject_Bulgaria#%D0%98%D0%BC%D0%B5%D0%BD%D0%B0_%D0%BD%D0%B0_%D1%83%D0%BB%D0%B8%D1%86%D0%B8_%D0%B8_%D0%B1%D1%83%D0%BB%D0%B5%D0%B2%D0%B0%D1%80%D0%B4%D0%B8 and the use of бл. in addr:housenumber in the header below (which also states that addr:place can contain abbreviations).
mnalis
commented
2 months ago So it's easy to add that Housenumber in Bulgaria can contain the string "бл." (with or without a space following it)?
As easy as writing any regex :smile_cat:
e.g. (бл\.\s?)?\p{N}{1,4}\p{L}{0,2} should match 42, 42a, бл.12, бл. 1234, бл.321ал.
But I don't know if there are other valid housenumbers in Bulgaria - e.g. quick check in Sofia finds things like 93 бл. 3, 115 вх. Б, 164, бл.3, 54-56-58 etc.; are some of those valid too or should they produce warnings?)
rhhsm
commented
2 months ago As easy as writing any regex 😸
We're going a bit off topic... I will put this question on the Bulgaria forum
matkoniecz
commented
2 months ago Please, put link back here when you do so or when discussion will complete!
(or in a separate issue that will be linked here if Bulgarian address format will be split into own issue - as this is a bit distinct topic...)
Anyway, nice that it was revealed because this specific confirmation spam was not supposed to happen for locally valid formats.
rhhsm
commented
2 months ago Please, put link back here when you do so or when discussion will complete!
With help from @Dimitar5555 , I think it will be sufficient to allow, in addition to plain numbers, the following possibilities for Bulgarian
addr:housenumbervalues:
Anything else is suspicious. The most common one is “вх.1” ("entr.1") which should be ref=1 on a staircase entrance node. 93 бл. 3, 115 вх. Б, 164, бл.3 and бл.321ал that @mnalis found are wrong (some apartment blocks have both a street+number and a block number + place address, but these data should go in different fields).
matkoniecz
commented
2 months ago numbers separated by hyphens (such as "2-4", "2-4-6")
What this one means? Is it a single address of such code, addresses 2 and 4 and 6 or something else?
Is 1-2-3-4-5-6-7-8-9 also valid one?
What about 222-4444 ?
numbers preceded by "бл.", optionally separated by a space, and optionally followed by one Cyrillic letter directly or separated by a space or hyphen
Is that "бл." having any meaning? Is it documented anywhere on any English wiki page? (so people implementing support for addresses in OSM data have at least in theory chance to understand what is going on)
(this is not required for fix in SC but would be a really good idea to do)
rhhsm
commented
2 months ago numbers separated by hyphens (such as "2-4", "2-4-6")
What this one means? Is it a single address of such code, addresses 2 and 4 and 6 or something else?
It typically occurs where 3 detached houses with numbers 2, 4 and 6 were demolished and replaced by one apartment block. That block may get the number 2 (and the next one 8), 2-6 or 2-4-6.
Is 1-2-3-4-5-6-7-8-9 also valid one?
What about 222-4444 ?
They are typically series of either odd or even numbers, but I don't think it's necessary to filter for them.
numbers preceded by "бл.", optionally separated by a space, and optionally followed by one Cyrillic letter directly or separated by a space or hyphen
Is that "бл." having any meaning? Is it documented anywhere on any English wiki page? (so people implementing support for addresses in OSM data have at least in theory chance to understand what is going on)
Bulgarian addresses can be of 2 types: the usual street + house number system, and one where apartment blocks get a block number preceded by "бл." (блок=block) + the name of the neighbourhood (which goes into
addr:place=*). So бл.474, ж.к. Младост 4 is tagged withaddr:housenumber=бл.474andaddr:place=ж.к. Младост 4. Some blocks have 2 addresses according to both systems, where the block number address should go on the building outline and the street+number address on a node inside the building. I'll see if I can document this somewhere. Where would be a good place?
matkoniecz
commented
2 months ago I'll see if I can document this somewhere. Where would be a good place?
https://wiki.openstreetmap.org/wiki/Addresses#Country_specific_rules_and_sources
mnalis
commented
2 months ago @rhhsm I've written a regex for Bulgarian housenumber in https://github.com/streetcomplete/countrymetadata/pull/26, so I'll hide my comments regarding that part of the issue as resolved to clean up this issue (@matkoniecz and @rhhsm may want to do the same to make the rest of this issue more readable; except https://github.com/streetcomplete/StreetComplete/issues/5683#issuecomment-2163488046); further discussion regarding Bulgarian housenumbers can take place in that PR if needed.
mnalis
commented
2 months ago As for the original issue, I'd really like to avoid locking away features behind accomplishments. It is extremely annoying, and gives unhealthy incentive to provide potentially incorrect data fast just to unlock the wanted feature.
So, I'd recommend either:
rhhsm
commented
2 months ago As for the original issue, I'd really like to avoid locking away features behind accomplishments. It is extremely annoying, and gives unhealthy incentive to provide potentially incorrect data fast just to unlock the wanted feature.
The reward could be hidden, i.e. not mentioned beforehand so there is no temptation to cheat to reach it, but when reached, it will be a pleasant surprise and a confidence boost ("now I'm no longer a newbie and they trust that I know how to solve these quests").
- if they know how
I wouldn't know how... I think it would give an unfair advantage to IT-savvy users.
westnordost
commented
2 months ago I'll close this as fixed by @mnalis. The other things suggested I don't like.
rhhsm
commented
2 months ago The other things suggested I don't like.
What is it you don't like about it? Do they have certain disadvantages? Or is it a matter of too much effort?
westnordost
commented
2 months ago More complex UI / more settings + implementation effort
El 17 de junio de 2024 14:20:55 CEST, Richard @.***> escribió:
The other things suggested I don't like.
What is it you don't like about it? Do they have certain disadvantages? Or is it a matter of too much effort?
-- Reply to this email directly or view it on GitHub: https://github.com/streetcomplete/StreetComplete/issues/5683#issuecomment-2173251531 You are receiving this because you modified the open/close state.
Message ID: @.***>
mnalis
commented
2 months ago @rhhsm you can try suggesting that feature in SCEE, as it should take much less issue with few extra preferences for skipping warnings...
(although there is still implementation effort required, and especially with all the MapLibre / iOS stuff in progress, I guess it is quite likely that enhancement requests will take a back seat for a while, unless someone else is willing to implement them of course)
rhhsm
commented
2 months ago More complex UI / more settings
My UI would be considerably simpler if I didn't have to confirm "Did you check at the ends of the street? If there are no signs along the whole street which apply for the highlighted section, default speed limits apply." for the 7282nd time the next time I solve a maxspeed quest (a.o.) :) Since there is a very good UI for undoing mistakes when answering quests, I think there is no need for the many confirmation dialogues there are now except for helping new users on their way. There is no need for a new setting item: I don't think a user would ever be sorry for not being asked for confirmations any more. If necessary, the "Restore hidden quests" option in the settings could be expanded to "Restore hidden quests and confirmation dialogues".
- implementation effort
I have great respect for the efforts you and others put into developing this app, and every time I start an issue, I feel ashamed for not being able to contribute to a solution for it. Unfortunately I can only contribute with my user experience... but I do hope that one day, someone more capable will find the time to implement this.
matkoniecz
commented
2 months ago More complex UI / more settings
Maybe split way tutorial can disappear on its own when someone solved >1000 quests?
mnalis
commented
2 months ago Maybe split way tutorial can disappear on its own when someone solved >1000 quests?
or better >10 splits?
(e.g. One could have solved e.g. 1000+ house type quests or similar without ever encountering "split way" functionality)
matkoniecz
commented
2 months ago That is where technical costs raise its ugly head. We would need to start tracking split count and synch it across devices.
With 1000 quests it is vanishingly unlikely they have not seen split tool yet, I think
mnalis
commented
2 months ago or better >10 splits?
That is where technical costs raise its ugly head. We would need to start tracking split count and synch it across devices.
Yeah, but it could be unsynched per-device (per-app) count, which should be easier... I think majority of users do not use multiple devices with same username to map with StreetComplete, and even if they did, the message would disappear after only 9 more splits on new device, so not a huge deal.
With 1000 quests it is vanishingly unlikely they have not seen split tool yet, I think
I guess it depends on the type of quests they're choosing to solve; but my main point is that I absolutely hate UX of locking away features behind accomplishments, and find it way too dangerous (regarding data quality) compared to potential benefits.
Even that "do 9 more splits for this dialog to go away" is on the verge of usability IMHO, but it is rather small number and potential damage is just in slight performance degradation (i.e. some road now exists in 10 pieces instead of 1, but all data remains correct).
With "solve 999 more quests for this annoying dialog to go away" it is both hugely more annoying to the user and (even more importantly) problematic for data quality. I've seen gamers grinding, and do not want to see results of it applied to OSM data.
If one insist on using synced status; changing it to the input that user can not easily game-out (i.e. "remove introductions after at least 365 SC mapping days") might help a little on one side (user somewhat less likely to input lots on unverified data to "unlock achievement"), but would IMHO still be still horrible UX.
Perhaps, the instructions how to use "split way" could only be shown first time when it is used, and settings could have "reactivate all helpful first-use tips" menu entry, for people who missed it / clicked it away. Disadvantage is that is not very discoverable if you happen to dismiss instructions by mistake :man_shrugging:
(note that all 3 ideas mentioned in this comment would apply of course only for "Split way" introduction instructions, and not for all the other actual warnings mentioned in the original issue (which many users might prefer to keep); so if those warning were to become optional, they would have to be changeable by manual preferences/settings in any case.)
rhhsm
commented
2 months ago Maybe split way tutorial can disappear on its own when someone solved >1000 quests?
Maybe all confirmation popups could disappear after solving 10,000 quests/365 activity days/100 achievement levels/whatever is easy to code ? Let's keep it simple
mnalis
commented
2 months ago Maybe all confirmation popups could disappear after solving 10,000 quests/365 activity days/100 achievement levels/whatever is easy to code ? Let's keep it simple
I don't know if I read this correctly, but such unconditional loss of all safety functionality I personally wouldn't like at all. Even if I am prolific StreetComplete user, which more than qualifies for all example thresholds mentioned above, I have found most of those warning popups to be very useful[^1] -- i.e. they prevented me from making unintentional mistakes way more often then they were incorrect. I'm just human after all :man_shrugging:
As I said earlier, that might be OK solution for introductory instructions like "split way tutorial" (although probably at much lower threshold), but IMHO definitely not for actual warnings.
To draw a parable (again: if I'm interpreting your suggestion correctly) it sounds akin to "when the car knows you have driven more than 20 000km or more than 365 days, it should unconditionally disable airbags, safety belts and parking sensors, without the option to enable them back on, because their inadvertent activation might result in annoying beeping sometimes".
Or _"your office suite deciding that it has been warning you to save your documents so often, and you've been using it more than a year, so it should just disable those warnings and lose your work if you forgot to save beforehand, because, you should've learned to save before closing by then. Oh, and there is no way to turn those warnings back on to give you a chance to save your data. Touch-move! Good luck!"_ :sweat_smile:
I can see your point if your false positive ratio for some of those warning is more like 99.9% instead of more like 5% for me; but then perhaps some of those warnings might be tuned up instead of disabling them automatically?
Just like maybe your car parking sensor becomes dislodged and incorrectly beeps all the time, and the correct path is to fix the sensor, instead of disabling all car safety features for everyone who had drivers license longer then a year during their car annual checkup.
So perhaps the problematic SC warning should be handled the same way?
If I were you @rhhsm, I would open one specific feature request issue for the one specific warning which has biggest number of false positives (i.e. triggering a warning when there is absolutely no reason to trigger), notice how often it triggers incorrectly, add few examples where it happened, and perhaps (but not absolutely necessary) try to guess why is that warning overtriggering in Bulgaria. Than that specific issue can be analyzed in more detail, and hopefully produce better / less annoying code (if possible to do with reasonable amount of work) ; just like we (hopefully) managed to improve situation with Bulgarian housenumbers in https://github.com/streetcomplete/countrymetadata/pull/26. And when that one is resolved, you can suggest another! etc.
While that isn't exactly what you asked for here (see XY problem) it might result in equally good or even better results, and not just for yourself, but for everybody else too.
[^1]: one notable exception perhaps being warning about "are you sure" for street sizes. There I had experience of overtriggering. But that specific one is not on mistaken SC being incorrectly surprised at data claiming that "this 3m wide street really isn't oneway", but instead on local municipality for some crazy reason believing that "it's indeed just fine for a two-way street to be just 3m wide, so let's have the car drivers sort the issue out when they meet in the middle". But even there, I actually prefer to be warned, even if catches actual user error in less than 20% of the cases for Zagreb. Admittedly, if it were happening 100 times a day instead of 10 times a year, I might consider turning that specific warning off manually if I had a chance (but even then not turning off all the warnings, and especially not all warnings turning off automatically without a way for me to turn them back on again).
Use case I've been active in SC for quite some time (1000+ activity days) and still have to click away a number of "Are you sure?" and similar popups. I've stopped reading them long ago so they are not useful, and sometimes irritating.
Proposed Solution Allow experienced users to shorten dialogues and get rid of confirmation popups by adding a checkbox "Get rid of this message for ever" to such popups.
I'm open to suggestions on how to define an "experienced user". We could set a limit for number of quests solved (minimum "Surveyor" level), minimum activity days, etc. It could be nice to enable it as a final "reward" to the rewards awarded to beginning users (it's been some time ago since I went through them so I don't remember what it was like), with a message something like "You are now no longer a beginner, so we trust that you've read these popup messages and are taking them into account. You can now get rid of them by clicking the checkbox if you want." Maybe there should be a possibility to re-enable them (from settings?)?
Popups that could have this checkbox include the ones that call
quest_generic_confirmation_title,quest_openingHours_24_7_confirmation,quest_name_answer_noName_confirmation_title,quest_streetName_answer_noName_confirmation_description,quest_streetName_nameWithAbbreviations_confirmation_description,quest_address_unusualHousenumber_confirmation_description,quest_maxspeed_answer_noSign_confirmation,quest_split_way_many_splits_confirmation_description,quest_source_dialog_title(it can now be disabled for a session, but would ne nice to disable it forever). There may be others...