<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/3/2021 2:03 PM, Kevin Kenny wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALREZe81pbtVB-0Gi1j9mA+=YeNqYYg9zw_dcZfk1hbh9wnMog@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>The only significant use of hyphenated housenumbers that
I'm aware of is in the Borough of Queens, New York City,
where almost all addresses are XXX-YY, where XXX is the
number of the cross street and YY is the housenumber on the
block. In that specific case, there's already been a
comprehensive import of building footprints, with their
addresses, so it's pretty much a non-problem there -
there's no need for address interpolation. For that reason,
I don't think there's a real need for interpolation between
already-hyphenated housenumbers. Nevertheless, we need to
avoid misinterpreting each of the tens of thousands of
hyphenated housenumbers in that borough as ranges. As long
as there's a separate indication that the number is an
interval, and it doesn't default to being an interval just
because there's a hyphen, then I have no objection. <br>
</div>
</div>
</div>
</blockquote>
<p>Another wrinkle in the case of Queens (and possibly anywhere else
that uses the hyphen as a column separator) is that people
sometimes use the unhyphenated version of the address
interchangeably. The addresses that were imported with the
building footprints use the hyphenated form, but many locals write
the address without it.</p>
<p>Eg:<br>
<a class="moz-txt-link-freetext"
href="https://www.openstreetmap.org/node/5559802016"
moz-do-not-send="true">https://www.openstreetmap.org/node/5559802016</a>
addr:housenumber=57-44, website says 57-44<br>
<a class="moz-txt-link-freetext"
href="https://www.openstreetmap.org/node/5557465669"
moz-do-not-send="true">https://www.openstreetmap.org/node/5557465669</a>
addr:housenumber=58-10, website says 5810<br>
</p>
<p>And the reverse can be true as well, eg <a
class="moz-txt-link-freetext"
href="https://www.openstreetmap.org/node/6389090010"
moz-do-not-send="true">https://www.openstreetmap.org/node/6389090010</a>
gives its housenumber as 16-23 even though the official imported
building address is 1623.</p>
<p>I've seen this inconsistency with physical housenumber signs as
well, and on mail.<br>
</p>
<p>So an effective geocoder for Queens needs to know to search for
58-10 when 5810 is requested, and vice versa. And in spoken
language the hyphen is often silent, so this has speech
recognition implications as well. <br>
</p>
<p>A tag like addr:range/interval=no (mechanically added to tens of
thousands of Queens addresses!) would allow a geocoder to index
these housenumbers in both forms, or to index just the digit form
and then strip hyphens from a search.</p>
<p>Alternatives offhand would be adding a digit-only duplicate
address node inside each Queens building way, or inventing a tag
like addr:alt_housenumber=, or a location-based hack (ie when
looking for a 3+ digit housenumber in Queens, also search with a
hyphen inserted before the final two digits) incorporated into
every geocoding library. None of those ideas thrill me.<br>
</p>
<p>My personal feeling is that the "real" address is just the
digits, and that the hyphen is a typographic convention, like
using "," (or "." in Europe) as a thousands separator. Akin to how
we can give pronunciation hints to a text-to-speech engine using
*:ipa=, we could invent a tag to give typographical hints on how
addresses should be formatted for display. But that won't stop
people from manually mapping using the hyphen (because that's what
listed on most physical address signs) so it's probably not a
viable solution.</p>
<p>Jason<br>
</p>
</body>
</html>