Skip to content
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

Closed
exploide opened this issue Jul 7, 2018 · 22 comments
Closed

Allow changing building type from house number quest #1121

exploide opened this issue Jul 7, 2018 · 22 comments

Comments

@exploide
Copy link
Member

exploide commented Jul 7, 2018

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.

  • What is the house number of this building?
  • Other answers
  • Has no house number
  • Is it really apartments?
  • No
  • What was this building constructed as?
  • Garages

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.

@ENT8R
Copy link
Contributor

ENT8R commented Jul 7, 2018

Is it really apartments?

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...

@rugk
Copy link
Contributor

rugk commented Jul 7, 2018

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.
It may just be a little hard to implement, because you need this (translated) list of tags and ask the user with them.

@exploide
Copy link
Member Author

exploide commented Jul 7, 2018

How can you determine the type of the building by its tag?

It may just be a little hard to implement, because you need this (translated) list of tags and ask the user with them.

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.

There are maybe buildings tagged with building=greenhouse and SC does not know what kind of building this is...

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.

@ENT8R
Copy link
Contributor

ENT8R commented Jul 7, 2018

Are the allowed building types for house number quest white or black listed? I thought it is a whitelist.

Yeah, true... That was a bad example...

@westnordost
Copy link
Member

I briefly thought about implementing it, but discarded this as being too much effort to implement.

@exploide
Copy link
Member Author

exploide commented Jul 7, 2018

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.

@matkoniecz
Copy link
Member

matkoniecz commented Jul 8, 2018

I briefly thought about implementing it, but discarded this as being too much effort to implement.

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.

@westnordost
Copy link
Member

westnordost commented Jul 8, 2018

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.
For example, I was recently asked for the housenumber of this metro station because it is tagged as a train station. Then, I answered that it is indeed a train station but simply has no housenumber. Someone else might have answered that it is not a train station but something else, a metro station. If the app would have just retagged it to building=yes, it would have been a loss of information and additionally, the next guy that comes by there might tag this again as a train station ... and so on.

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.

@matkoniecz
Copy link
Member

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.

@exploide
Copy link
Member Author

exploide commented Jul 9, 2018

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.

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 building=house or building=apartments. This produces all the wrongly tagged garages.

Someone else might have answered that it is not a train station but something else, a metro station.

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...

@matkoniecz
Copy link
Member

One more thing

If the app would have just retagged it to building=yes, it would have been a loss of information

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

@westnordost
Copy link
Member

Hm true, but not in the case I was thinking of - those cases where the building type is debatable.

@matkoniecz
Copy link
Member

It probably depends on area what is more popular.

@gitka
Copy link

gitka commented Aug 19, 2018

Most buildings are created with building=yes. Please also allow house number quest for building=yes or .

@ENT8R
Copy link
Contributor

ENT8R commented Aug 19, 2018

Please also allow house number quest for building=yes

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...

@rugk
Copy link
Contributor

rugk commented Aug 19, 2018

Getting back to the actual issue…

If the app would have just retagged it to building=yes, it would have been a loss of information

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)

  1. User opens house number quest.
  2. More answers -> has no house number -> Has different building type
  3. Show building type quest as if it was new. Do not remove any tags. Now the user just – as usual – selects any building type or leaves a note, if they don't know.

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 building=yes and intuitively I'd say no. Don't do this. In case it turns out the user is wrong, you have an information loss.
So either implement nothing or everything, here…

@exploide
Copy link
Member Author

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)

  1. User opens house number quest.
  2. More answers -> has no house number -> Has different building type
  3. Show building type quest as if it was new. Do not remove any tags. Now the user just – as usual – selects any building type or leaves a note, if they don't know.

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)

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.)

@rugk
Copy link
Contributor

rugk commented Aug 19, 2018

Ah, yes, forgot this. Then it may actually be easy™.

@kymckay
Copy link

kymckay commented Aug 29, 2018

User opens house number quest.
More answers -> has no house number -> Has different building type
Show building type quest as if it was new. Do not remove any tags. Now the user just – as usual – selects any building type or leaves a note, if they don't know.

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.

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)

So yeah, you'd definitely need to ask them or somehow show the current type first.

@rugk
Copy link
Contributor

rugk commented Aug 29, 2018

currently tagged building type

The type is "trandlated" into a user-friendly string such as "Garage"? Do you really think users don't know what that means?

@westnordost
Copy link
Member

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.

@westnordost
Copy link
Member

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.
I triaged both solutions, and for both, the gain somewhat outweighs the effort, so I will close this. As said, the user can leave a note in the case that the tagged building type does not coincide with reality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants