Ameliorate address quest (needed for India)

[letypequividelespoubelles]

Use case
In India, a lot of addresses (at least where I live) are tagged with addr:housenumber=Letter-XXX & addr:place=* but no addr:street=*

It's really a pain to add addresses there (via the address overlay) because :

1. we can't do "+1" at each incrementation of housenumber because the housenumber doesn't contain only number (like C-245 for exemple)
2. as there is no street tag, we need to add via addr:place=* tag, so need to "select other", and then write the name of the place.

Proposed Solution

1. it should be possible to do +1 / -1 for housenumber like C-246, it'll be faster.
2. a) streetcomplete should remember that we tag addr:place= instead of addr:street=
   b) streetcomplete should remember the name of the place, so that we don't write it everytime
   c) SC should propose name of nearby place when starting to write the name of the place to avoid errors

PS : for 2) it should be the same for the "What is the streetname of this housenumber" quest.

Thanks !

[westnordost]

All three should be possible. I'll mark it as an enhancement, so anybody interested can implement this.

[Helium314]

@letypequividelespoubelles is <letter>-<number> the only format you have issues with, or are there other (common) ones?

@westnordost is something like Helium314@965c06e ok for 2. a)?
It will put the form in place-mode if the previous answer was a place. Switching back from place to street needs to be done using the spinner.

I won't work on the other parts of 2. as I guess b) is might be too much work for me (currently), and c) as well, plus I don't see how it would work realistically, as I found areas where almost 1000 m search radius would be necessary.
But you can work around this by using the address overlay.

[letypequividelespoubelles]

@Helium314 Thanks

is <letter>-<number> the only format you have issues with, or are there other (common) ones?

I don't know any other common ones in India so it should be enough (but India is huge).

It will put the form in place-mode if the previous answer was a place. Switching back from place to street needs to be done using the spinner.

Perfect. That way, will it be possible to add street and place tag ? (because some roads have name, so address is mainly place, but adding street in addition is better)

b) is might be too much work for me

SC already remember street name, can't we implement the same for place ?

c) as well, plus I don't see how it would work realistically, as I found areas where almost 1000 m search radius would be necessary.

If 1), 2)a)b) are already implemented, c) is only the cherry on the cake so no need to spend too much time on this

[Helium314]

Perfect. That way, will it be possible to add street and place tag ? (because some roads have name, so address is mainly place, but adding street in addition is better)

No change here, it's still the same place or street

SC already remember street name, can't we implement the same for place ?

I don't really understand. SC does not remember the street name in the address quest, only in the overlay. But the overlay remembers place name already.

[westnordost]

@westnordost is something like Helium314@965c06e ok for 2. a)?

Looks like an improvement.

Something that will have a much larger impact on the overall productivity with the housenumbers layer would be the following feature which is indicated a bit in b) / c):

• get all elements in a certain radius around the current position with a housenumber
• if the street field is not filled in by the user yet: after each change to the housenumber field (either by typing or pushing the +/-), check the addr:streetname of any neighbouring housenumber and fill it in

This in most cases makes tapping on the street to fill in the street name or even typing it unnecessary. Some safeguards and edge cases need to be treated (e.g. user types in "4" first which matches with one street, but that types in "1" so it becomes "41" so it matches with another; or he types in "4" and this actually matches two streets).

And the same as above but for place names.

[letypequividelespoubelles]

But the overlay remembers place name already.

Are you sure ? It doesn't for me, just tried with v 50.2 from fdroid

[Helium314]

Oh... looks like that part has been broken somehow, and was accidentally fixed in Helium314@965c06e, even though it was not touched.

get all elements in a certain radius around the current position with a housenumber

Right, that's vastly more efficient than looking for place

[Helium314]

In #4753 we concluded that "it should be possible to do +1 / -1 for housenumber like C-246, it'll be faster." should rather be solved by allowing to enter addr:block.
This could be done by allowing to switch to the Japanese address UI, and using block instead of block_number.

[letypequividelespoubelles]

Yes, thank you @Helium314 and @westnordost .
To summarize, for India, in address overlay,

1. not needed anymore
2. a) : done
   b) : done
   c) cherry on the cake. Useful but not as strongly needed as 3) and 2) a & b. But would minimize name error.
3. SC should allow the user to add these 4 address tags :

• addr:housenumber
• addr:block (optionnal)
• addr:street and/or addr:place (it's possible to have both street and place)

[letypequividelespoubelles]

@Helium314 Do you plan to implement it or not ?

[Helium314]

Currently I have not plans to do so. I tried a month ago, and and found it to be much more work than #4751, as I first need more understanding in the code related to addresses.