<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div>Nominatim interprets its as a single number (literal), as I understand from<br></div><div><a href="https://github.com/osm-search/Nominatim/issues/565#issuecomment-272725116">https://github.com/osm-search/Nominatim/issues/565#issuecomment-272725116</a><br></div><div><br></div><div>It is used in actual tagging for both, sometimes with addr:interpolation on nodes<br></div><div>to indicate range (what is ignored by at least Nominatim)<br></div><div><br></div><div>Jan 8, 2021, 07:48 by pelderson@gmail.com:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div dir="ltr"><div>I did some overpass scans in my neighbourhood. Within a 10 Km radius from my home leaving out the hyphen and/or spaces would get you many errors.<br></div><div><div>I think any range solution should leave the housenumber strings intact. Adding special punctuation characters for added functionality should work, if it includes an easy escape for situations where reserved character is part of the number string.<br></div><div><br></div><div>I still like to know how eg addr:housenumber=10-15 is generally interpreted now: single number (literal), range, or a mix of interpretations (aka chaos). <br></div><div><div><br></div><div><div data-smartmail="gmail_signature" class="" dir="ltr">Peter Elderson<br></div></div><div><br></div></div></div></div><div><br></div><div class=""><div class="" dir="ltr">Op vr 8 jan. 2021 om 00:23 schreef Jmapb <<a href="mailto:jmapb@gmx.com" rel="noopener noreferrer" target="_blank">jmapb@gmx.com</a>>:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=""><div>On 1/7/2021 2:41 PM, Jmapb wrote:<br></div><div> <br></div><div> > Would it also be advantageous to assert that a range-like address is<br></div><div> > not a range? I'd hope that, knowing that any hyphens found in a<br></div><div> > housenumber are just for formatting, a geocoder could then index the<br></div><div> > housenumber without hyphens. This would allow digit-only address<br></div><div> > searches to work in Queens without requiring the correct hyphen<br></div><div> > placement. Which would be good because it's not uncommon for<br></div><div> > Queensians to omit the hyphen in both speech and writing. (This<br></div><div> > currently works in Apple, Google, Here, and Bing maps, by the way.)<br></div><div> ><br></div><div> Been rethinking this and checking over the data. The suggestion (my<br></div><div> suggestion) that geocoders index a de-hyphenated version of all<br></div><div> non-range hyphenated addresses does not hold up under scrutiny.<br></div><div> <br></div><div> First of all, just looking in Queens, the hyphenated addresses are not<br></div><div> all in the XX-YY or XXX-YY format. You'll see XX-Y or XXX-Y at start of<br></div><div> some blocks. It looks like addresses where the post-hyphen portion is<br></div><div> less than ten were padded with a zero when the addresses were applied to<br></div><div> an entire imported building way, but not when the addresses were<br></div><div> imported as a nodes, which was how multiple-address buildings were done.<br></div><div> <br></div><div> Eg, 65-1 174th Street <a target="_blank" rel="noopener noreferrer" href="https://www.openstreetmap.org/node/2552890712">https://www.openstreetmap.org/node/2552890712</a><br></div><div> versus 65-04 174th Street <a target="_blank" rel="noopener noreferrer" href="https://www.openstreetmap.org/way/248516462">https://www.openstreetmap.org/way/248516462</a><br></div><div> <br></div><div> In this context, indexing 65-04 as 6504 makes sense, indexing 65-1 as<br></div><div> 651 does not. In fact I think 65-1 and similar are probably errors, but<br></div><div> that's going to take some more investigation.<br></div><div> <br></div><div> Second, scanning through the world beyond Queens, I see that it's not at<br></div><div> all uncommon to have an address with a hyphenated numeric suffix. It's<br></div><div> very common in the Netherlands. Here's an example, Utrechtseweg 13-9 in<br></div><div> Hilvesum: <a target="_blank" rel="noopener noreferrer" href="https://www.openstreetmap.org/node/2878703055">https://www.openstreetmap.org/node/2878703055</a><br></div><div> It's not a range (obviously) but I seriously doubt that it would be<br></div><div> correct to index it as Utrechtseweg 139 -- especially since Utrechtseweg<br></div><div> 139 is down here: <a target="_blank" rel="noopener noreferrer" href="https://www.openstreetmap.org/node/2878370113">https://www.openstreetmap.org/node/2878370113</a><br></div><div> <br></div><div> I still feel it's a serious compromise in map usability to require<br></div><div> correct hyphen placement to search Queens addresses (and apparently<br></div><div> Apple, Google, Here, and Bing agree) but I don't know how best to crack<br></div><div> this nut. The addr:interval proposal is a related issue, but it's not a<br></div><div> complete solution.<br></div><div> <br></div><div> Jason<br></div><div> <br></div><div> <br></div><div> _______________________________________________<br></div><div> Tagging mailing list<br></div><div> <a target="_blank" href="mailto:Tagging@openstreetmap.org" rel="noopener noreferrer">Tagging@openstreetmap.org</a><br></div><div> <a target="_blank" rel="noopener noreferrer" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a><br></div></blockquote></div></blockquote><div><br></div> </body>
</html>