Proposal talk:Addr:interval

From OpenStreetMap Wiki
Jump to navigation Jump to search

Range

addr:range=* is the wrong (dictionary) term for what you are describing. It should be addr:interval=*. Also, there is no need for even and odd as these are redundant. It should simply be an interval of "2". I would also recommend a default interval of "1" if not otherwise specified. This also makes it simpler for data consumers in that they can simply use the interval number. So to update your example:

Even numbers:

Means 190-10, 190-12, ...

Odd numbers:

Means 123,125,127,129

The "from" and "to" versions seem fine, if you really must have two different ways to specify it.

--ZeLonewolf (talk) 04:41, 26 December 2020 (UTC)


Typos or maybe I'm missing something

  • The proposal says "addr:range=even would indicate it contains every other number (i.e. 40, 42, 44, 46, 48) (you can use addr:range=odd for ranges of odd numbers e.g. 41-18)". Should that be "41-48"?
  • Similarly "addr:range=all would indicate every housenumber is contained (i.e. 40, 41, 41, ...)" - shouldn't it be "40, 41, 42,..."?

I'd change them, but in the former in particular I'm wary in case I'm missing something. --ChrisHodgesUK (talk) 11:49, 3 January 2021 (UTC)

Differentiation between the proposed approach and addr:interpolation

--Tux67 11:31, 4 January 2021 (CET)

  • As I understand it: interpolation is for temporary tagging of address range that will be replaced by individual addresses. This is for tagging that for example specific apartment has addresses 1, 2, 3, 4, 5, 6, 7 at Strawberry Street - that are not taggable in more detail. It would also specifying that say Wrocławska 1-3 is a single housenumber, not an address range Mateusz Konieczny (talk) 11:26, 4 January 2021 (UTC)
  • Also addr:interpolation=* is only to be used on interpolation ways - open ways connecting two address nodes. This proposal includes - for example - apartment buildings which contain only odd-numbered apartments. The guidance for addr:interpolation excludes these cases and there is no current way to tag them (that is supported by anything in the wiki). (spiregrain) 12:01, 4 January 2021 (UTC)

Alternatives to the vertical bar

The vertical bar is currently used in tagging schemes like turn:lanes=* and connectivity=* to delimit discrete items in an ordered list. Option 1 would repurpose that operator for interpolation to avoid the ambiguity of a bare hyphen. But there are other options:

  •  to  is widely used as a range delimiter in grades=*, height:range=*, building:age=*, building:foundation_height=*, and occasionally addr:housenumber=*.
  • Technically, the typographically correct range delimiter would be an em dash (–). We can pretty much count on good Unicode support from data consumers at this point, but the limiting factor would be that not enough mappers would be familiar with the key combination to input an en dash and might not be able to readily discern one from a hyphen.

I think  to  would be a better alternative to the vertical bar. While there's little chance of ever needing to tag addr:range:lanes=*, it helps to keep the meaning of each operator consistent across keys, for the same reasons that homonymous keys are to be avoided.

 – Minh Nguyễn 💬 11:20, 4 January 2021 (UTC)

Alternative one-tag solution with hyphens, quotes and parentheses

The usual character for a range is the hyphen. Anything else will lead to mapper errors, mixed use and other things causing uncertainty what was meant, hence guessing/extra processing at the data user side.

Irregular numberings with missing numbers, lettered subranges within ranges, I think for special cases you can only enumerate or map separate addresses.

Any solution should leave current database as intact as possible. No-one wants mass retagging.

What is the problem? I think: 1. That the interval needs to be specified, 2. Hyphens can be part of the numbers without specifying an interval 3. Irregular ranges.

I think a range format is needed with format options. If all the options are left out, it's a simple range. It will need parsing, but a data use that doesn't parse is no worse off than now.

Quote <from> and <to> if they contain a hyphen Specify that <start> and <end> may always be quoted strings. For a simple range quotes are allowed but not necessary; if start or end contain a hyphen you better add quotes if you want it processed as a range. Within the quoted <from> and <to> strings, the part up to and including the hyphen should be equal. It's a prefix.

Irregular ranges: enumerate with comma as separator Semicolon would be fine too. In Nederland we would use a comma in this type of list. You could easily support both.

Interval: default interval=1 I think default of 2 is not wise. The even/odd system applies mainly to streets, where every building has its own number and one side is even, the other is odd, but I think these simply should get there own address tag. Ranges apply to larger building and blocks, for which the even/odd numbering often doesn't apply.

Intervals higher than 1: append in parentheses e.g. (2) It could be a separate tag, but since you are formatting/parsing anyway, I would choose to have it as a part of the range string.

  • Maybe make spaces optional for readability?
  • Odd/even is clear from the format.
  • This fits in the regular housenumber tag. A single housenumber is a range of 1.

Examples
15 (single house number)
15-20 = 15,16,17,18,19,20 (simple range)
15-25 (2) = 15,17,19,21,23,25 (simple range with interval 2)
'123-15'-'123-21' = 123-15,123-16,123-17,123-18,123-19,123-20,123-21 (quoted range)
'123-15'-'123-21' (2) = 123-15,123-17,123-19,123-21 (quoted range with interval 2)
10,11a,11b,11c,12,14 (enumeration)

Instructions

  • 0. Use m-n for a simple range m up to n with interval 1
  • 1. Append (2) if the interval is 2 | append (n) if the interval is n
  • 2. quote <start> and <end> separately if they contain a hyphen;
  • 3. For irregular not too long ranges (max ?), enumerate all using comma or semicolon separation
  • 4. Else no range spec is possible.

--Peter Elderson (talk) 07:01, 5 January 2021 (UTC)

Option3

"addr:housenumber:range" - is it supposed to be boolean yes/no, or is it supposed to contain range? Mateusz Konieczny (talk) 15:33, 6 January 2021 (UTC)

Useful comment

https://lists.openstreetmap.org/pipermail/tagging/2021-January/058197.html - from Nominatim maintainer Mateusz Konieczny (talk) 16:38, 12 February 2021 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Addr:interval&oldid=2511611"