-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow changing building type from house number quest #1121
Comments
How can you determine the type of the building by its tag? There are maybe buildings tagged with building=greenhouse and SC does not know what kind of building this is... |
Well… it could just skip these cases and fall back to the old behaviour. From a user's point of view, I like this idea. |
This is actually already happening. When I say has no house number, SC says it is currently determined as appartments, is it right? - No, leave note. (A bit simplified by myself and roughly translated from German to English). But it already parses that information.
Are the allowed building types for house number quest white or black listed? I thought it is a whitelist. Then this shouldn't happen. But maybe I'm wrong. |
Yeah, true... That was a bad example... |
I briefly thought about implementing it, but discarded this as being too much effort to implement. |
Ok. Too bad. I imagined it would be easy after the building type quest has landed. But I don't know much about the internals of the app, so I guess you are right. As it has been requested several times to accomplish such a task, maybe leave it open for someone who will implement this some day? It might be beneficial if you briefly outline what obstacles are currently present and what needs to be done. |
Why not just have option "current building value is wrong" and selecting it would set building=* to building=yes? It should trigger building type quest and even if someone would not answer it building=yes is still better than building key with wrong tag value. |
Because there is the danger of this going back and forth. If it already has been mistagged as something it is not, maybe it would so again for those edge-cases where it is likely that a mistagging would occur. My assumption is that whenever buildings are tagged as something they are not, it is due to the fact that they look very much alike that something or more-or-less are something like this. In this case, it is better to discuss the details in a note. |
In my experience mistagged buildings are very easy to fix while on survey and I prefer to do that rather than generate flood of notes, but in that case I will just change it in my version without making a PR. |
I got the feeling that such wrong tagging mostly happens because the person who draw the buildings from aerial imagery just tagged everything the same, e.g. everything in a residential area as
One could argue that the description field that got introduced for the building type quest serves exactly the purpose of explaining such things. E.g. "includes metro stations" or something like this. But it's of course up to you. If you think this would make things worse... |
One more thing
if someone answers "building type of this object is wrong" then retagging to building=yes is not loss of information, it is removing of false information |
Hm true, but not in the case I was thinking of - those cases where the building type is debatable. |
It probably depends on area what is more popular. |
Most buildings are created with building=yes. Please also allow house number quest for building=yes or . |
This is definitely not planned and will never be implemented... The reason for that is that for buildings with building=yes can be any building, so before asking for the house number the app has to know what kind of building it is. This is also why the building type quest shows up before the house number quest. As an example: for a building tagged as building=yes which should be a garage in reality the app should not ask for a house number because the kind of the building is undetermined... |
Getting back to the actual issue…
If you say so, and I can think it is arguable, but well… why not just leave it away, i.e. implement it like this: (user flow)
Now, I guess, I see the hard part: In step 3 or maybe even 2, you may want to pre-select the current building type or house number. (or ask the user) Sorry for repeating this, I just had to recap this whole issue… So that's why it has been proposed to tag |
Yeah, this is more or less what I proposed. :) With the difference that I had the "is this really ... (e.g. apartments)" question before handing over to building type quest while you want to preselect it. Now you say this might be the difficult part, and this was worried about earlier in this issue. But I still don't see why this is the difficult part. I admit I have little knowledge about the internal workings of this app but the current building type is already interpreted when answering "has no house number" (before leaving a note). It then asks if this "is really ... (e.g. apartments)". So what I proposed is already happening :D the final action is just leaving a note instead of handing over to building type quest. (What I don't get is what you want to do with the house number in this sentence. There is no current house number, otherwise the quest wouldn't have shown up.) |
Ah, yes, forgot this. Then it may actually be easy™. |
The issue here is that the user has no way of knowing the currently tagged building type. You'd be assuming that they understand how tagging/quests work and can infer that the building type must be wrong if the house number quest is shown.
So yeah, you'd definitely need to ask them or somehow show the current type first. |
The type is "trandlated" into a user-friendly string such as "Garage"? Do you really think users don't know what that means? |
Sorry, I have to interject here. What are guys talking about, are you even using the app?? It has been long implemented that on clicking "has no house number", a dialog pops up that shows the currently tagged building type with icon, text and description, asking whether it is correctly tagged as this. TBH, any discussion beyond #1121 (comment) is missing the point. |
Okay, so what could be implemented theoretically is that the house number quest somehow passes off to the building type quest in this case instead of requiring the user to or reimplements the whole of the building type quest itself. |
This was already part of the conversations in #351 and #767 but apparently did not get implemented so far. Now that we have a great building type quest, it would be awesome to have the ability to change the building type when it is wrong, and hence the house number quest is unanswerable.
This would finally make the house number quest great again. Currently I have it disabled because it almost always is a garage and I don't want to leave tons of notes (which I would have to clean up afterwards). Despite I consider the house number quest really important.
The text was updated successfully, but these errors were encountered: