Unit Identifier Available on House Number Quest/Address Overlay

[malleyeno]

Use case

In my area of Regina, Saskatchewan, there are quite a number of buildings that have both a house number and a unit number as part of their address. This can occur for a few reasons, such as the property being part of a community block (so every resident has the same address pointing to the block, but they get a more specific unit number to their home.) or because they are in a row house or business park arrangement, or because their home is split into A and B addresses. In any case, house number and street address is not enough to disambiguate where they are located, you would need the unit address.

So far, I have been addressing these units with the show/edit tags feature and adding the addr:unit tag (or making a map note and doing it later on desktop.) I feel like this is a good candidate for addition to the address entry form.

There is an option within the triple-dot menu for "it is within a block" that does add a prefix address before the house number. But this convention appears to be specific to Japanese addressing. It also would not address the use case since unit numbers aren't always prefixes to house numbers, and unit numbers may exist without blocks. Units may also be either numbers (ex. Unit 100) or letters (A, B, C)

Proposed Solution

(Please excuse how bad my mockups look, I'm making them with my phone's photo tool)

My idea is to add a field (perhaps added with a toggle in the UI/quest settings) to the address entry form that allows numbers or letters that would modify the addr:unit tag.

Another idea is to have an option in the triple-dot menu (similar to the block number option) that reads "it has a unit identifier."

[Helium314]

I think it makes sense, but why only for SCEE and not for StreetComplete?

In practice the unit number is often mixed into the house number, so for now you could also do the same.

[malleyeno]

I think it makes sense, but why only for SCEE and not for StreetComplete?

I put it here only cuz I use SCEE. If you feel like it should be part of StreetComplete, I'd be happy to copy this issue over to there.

Though there may be an argument for having this feature be on SCEE due to audience. Putting a unit identifier field on a form could imply to an inexperienced user that it should always be filled out for all addresses (since street name and house # are almost always filled, so why not this third field that's next to them?) Since the users of SCEE are expected to have experience, they would be more likely to know that not all addresses have units.

In practice the unit number is often mixed into the house number, so for now you could also do the same.

That's fair, and it's something I do on occasion. I'll note down what the common house number is in a map note, but then fill in unit addresses for the house numbers. Then when I'm home, I'll move them all to addr:unit in JOSM and paste over the house number from the note.

[Helium314]

I put it here only cuz I use SCEE. If you feel like it should be part of StreetComplete, I'd be happy to copy this issue over to there.

Looks like this was discussed and is not going to be added to SC: streetcomplete#4196 (comment)

[mnalis]

• also related: House number quest & unit streetcomplete/StreetComplete#1860

[Helium314]

In case anyone is interested in implementing this: quest forms will move to compose not too far in the future, so maybe better wait until this is complete.
Implementing this in compose might also be easier than in "normal" Android view system.

[malleyeno]

I wouldn't mind giving this a try once the change to compose happens. This would be my first attempt at anything in Kotlin though so totally understandable if you would prefer someone else takes this on.

[mnalis]

Implementing this in compose might also be easier than in "normal" Android view system.

• ref. upstream : Migrate to Jetpack Compose (master) streetcomplete/StreetComplete#5616 (or is there more precise ticket for just the quest-compose part)?

I wouldn't mind giving this a try once the change to compose happens

Thanks, that sounds great! We have CONTRIBUTING_A_NEW_QUEST.md but most of that change would be related to familiarizing yourself with Compose I think.

This would be my first attempt at anything in Kotlin though so totally understandable if you would prefer someone else takes this on.

If someone else expresses their desire to work on it, they'll chime in and leave a comment. If not, when compose is implemented upstream and you think you're ready to try, let us know and we can assign the issue to you!

[Helium314]

(or is there more precise ticket for just the quest-compose part)?

Not a ticket, but a PR for migrating a first quest form: streetcomplete#6022