Streetcomplete: Questions about the AddHousenumber Quest

[tordans]

The answers might be obvious to people who use the app more than I can (iOS…) – but it might also be a Bug, that why I post it here.

A user created this changeset recently https://www.openstreetmap.org/changeset/90140367 / https://osmcha.org/changesets/90140367/

There are two questions here:

a. For one building, the full address was missing. I added it as an address node in https://www.openstreetmap.org/changeset/90303327 to have it consistent to all other addresses in the district.
Question: Why did SC only ask for the number, if the full address is missing here? Is this a Bug or a feature?

b. For one building, the full address was present as a address node which is "inside" the building-area. I removed the SC-added housenumber again in https://www.openstreetmap.org/changeset/90304049.
Questions: Since we don't have hundreds of those changes in Neukölln, I guess SC usually knows about address-nodes and only asks if none is found (like (a)), so why did it in this case?

[matkoniecz]

Question: Why did SC only ask for the number, if the full address is missing here? Is this a Bug or a feature?

It will ask also about street, but for technical reasons it is sadly not done immediately.

For one building, the full address was present as a address node which is "inside" the building-area. I removed the SC-added housenumber again in https://www.openstreetmap.org/changeset/90304049.

It is a bit weird. SC should not create quest in case of address node within building outline, but it is created anyway in this specific case. It sounds like a bug or a stale/broken overpass data.

[matkoniecz]

http://overpass-turbo.eu/s/XEd - address node is indexed by Overpass

http://overpass-turbo.eu/s/XEe - building outline is in Overpass

node is within building outline

http://overpass-turbo.eu/s/XEf - it has addr:housenumber (I checked as I suspected broken tags with invisible characters)

I have no idea what went wrong here.

[tordans]

Thanks for explaining and investigating!

IMO we can close this, since it's just one report / incident and therefore IMO not worth the debugging effort. We could reopen it later if needed.

[Helium314]

I just had a look, and I get the house number quest for Böhmische Straße 23. The house number (from the node) is displayed on the map, but still asked for the building.
Since SC still/again displays this quest, someone will add the house number sooner or later, and you will have to remove it again...

I also get the quest for Bartastraße 14, but here the reason is because the node is just outside the building.

Edit:
I also found Briesestraße 30 and Richardstraße 104, here the house number is inside the building, but SC still asks.
So this occurs more than just for one building...

[westnordost]

I analyzed the issue.

Each housenumber node is assumed to be only within one building. During download, for each building without a housenumber, a housenumber node is "consumed" for preventing that a quest is created for a building, which is fine because buildings do not overlap.

The issue is triggered by that node 1587307715 is detected to be inside way 218917749 by LatLon.isInMultipolygon in SphericalEarthMath.kt, then for the building with house number 23, that housenumber node is not there anymore to prevent creation of a quest.
That the node is detected to be inside the building with house number 24 is obviously wrong. LatLon.isInPolygon also returns true, so it can't have anything to do with the orientation of the way.

I've added a test that contains exactly the data from node 1587307715 and way 218917749, I believe, but the test actually runs through successfully. So it looks like as if the implementation works on Java (tests are run locally with Java), but not on Android - which... can't really be. So at the moment, I am out of ideas.

[westnordost]

Maybe someone else has an idea what next to check. Possible next steps:

• check if the data in the tests really is 100% the real data of that way
• try executing the test as an Android test to see if it is at least reproducible as an Android test
• If all fails, go step by step through the isInPolygon function with the given data.

[westnordost]

Ok, found and fixed the issue. It has been there since the housenumber quest was first implemented.

[b-r-u]

@westnordost Thanks for finding this tricky floating point problem!
And also thanks to @tordans for linking to this issue from the changeset.