Use the biggest/smallest address as appropriate when using the address +/- buttons

[peternewman]

Use case
If you tag a pair of semi detached houses or a terrace with multiple house numbers (e.g. 12-14 or 21,19,17), currently it just appears to take the first (or last) number it parses when you press +/- to number the next property.

Proposed Solution
Store the biggest (14/21) and smallest (12/17) values separately from the parsed house numbers and use the appropriate ones to suggest the next house i.e. 11/16 for - or 15/22 for + in my examples.

[smichel17]

Complication: 12-14 might be the full address, not "houses twelve through fourteen". In New York City, the first number often indicates which street/avenue it is between (example). So in that case, I'd rather if 12-14 were incremented to 12-15.

I don't think there's a way to do the right thing in all situations, so just let's pick the one that does the best overall.

[westnordost]

Can not reproduce.

[westnordost]

Please provide some examples addr:housenumber for which it does not work.

[peternewman]

Complication: 12-14 might be the full address, not "houses twelve through fourteen". In New York City, the first number often indicates which street/avenue it is between (example). So in that case, I'd rather if 12-14 were incremented to 12-15.

Yeah I just gave that as an example (which admittedly I didn't test), I know I'd seen the issue, but couldn't remember exactly where.

Personally I try and avoid it due to the ambiguity, especially if I actually mean 12 and 14 but not 13.

I don't think there's a way to do the right thing in all situations, so just let's pick the one that does the best overall.

👍

I do accept if you were tagging both sides of the street at once (with odds/evens split) then in some circumstances, this behaviour may be useful, but only if the numbers aren't clockwise around a cul-de-sac and are equally offset.

Please provide some examples addr:housenumber for which it does not work.

Tag 12,10
Hit + on the next house
Get 11

Tag 12,10
Hit - on the next house
Get 11!

10,12 works correctly incrementing and decrementing as does 12-14.

With my second made up original example, I get an even more unusual behaviour:
Tag 21,19,17
Hit + on the next house
Get 18

Tag 21,19,17
Hit - on the next house
Get 20!

Likewise with 21-17.

FWIW, I do this where it matches the order of the houses (from left to right as that's how English is written).

[westnordost]

Can you explain why one would tag housenumber ranges in descending order? I never did that and I am not sure if such tagging should be expected.

[peternewman]

Can you explain why one would tag housenumber ranges in descending order?

FWIW, I do this where it matches the order of the houses (from left to right as that's how English is written).

So given houses numbered like this in a terrace:
21 19 17 15
I would tag them as:
21,19,17,15

To give you a hint which end of the block the number you want may be, like a basic version of interpolation.

Also in particularly long runs of numbers, it's far easier and less risk of errors inputting them as I walk along (if I'm walking the right way).

I never did that and I am not sure if such tagging should be expected.

I didn't spot anything in the wiki recommending it, or equally advising against it.

There are 19 instances of 3,1 across at least 4 countries:
https://taginfo.openstreetmap.org/tags/addr%3Ahousenumber=3%2C1

Versus 1084 of 1,3:
https://taginfo.openstreetmap.org/tags/addr%3Ahousenumber=1%2C3

Or 11 of 5,3,1:
https://taginfo.openstreetmap.org/tags/addr%3Ahousenumber=5,3,1

In my experience there are generally many fewer numbered that way than the other way round anyway.

[westnordost]

Okay, that was much more effort than expected... wouldn't have done it if I knew before. But now, it works with any weird combination:

21/4, 4c +: 22 -: 3
18a-12d, 2, 6-8 +: 19 -: 1
etc

[westnordost]

Actually, I changed it so that reverse ranges (f.e. 16-2) are interpreted to mean basically the same as 16/2.

So

21/2, 4c +: 22 -: 3
(and not +: 22, -: 1)

[peternewman]

Okay, that was much more effort than expected... wouldn't have done it if I knew before. But now, it works with any weird combination:

Thanks for that @westnordost and sorry for finding an awkward one!

Actually, I changed it so that reverse ranges (f.e. 16-2) are interpreted to mean basically the same as 16/2.

Ah cool, I was a bit confused about one test case, but I guess that makes sense from what @smichel17 said.

From looking at the tests, I'd think these should also be true:
4<4c
4c<5

But I appreciate you might not want to deal with that level of complexity!

[westnordost]

Also, it's not relevant, as +: 5 and -: 3 for all of 4c, 4, 4-1, 4/7, 4/a

…

On 11 August 2021 15:50:39 CEST, Peter Newman ***@***.***> wrote: > Okay, that was much more effort than expected... wouldn't have done it if I knew before. But now, it works with any weird combination: Thanks for that @westnordost and sorry for finding an awkward one! > Actually, I changed it so that reverse ranges (f.e. `16-2`) are interpreted to mean basically the same as `16/2`. Ah cool, I was a bit confused about one test case, but I guess that makes sense from what @smichel17 said. From looking at the tests, I'd think these should also be true: 4<4c 4c<5 But I appreciate you might not want to deal with that level of complexity! -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #3149 (comment)

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[peternewman]

Very true, I didn't know if it would upset the sorting/max stuff if the values weren't comparable and if it might just discard them?

e.g. 2, 4, 6A, 6B should give +7, -1

[westnordost]

e.g. 2, 4, 6A, 6B should give +7, -1

yes