From OpenStreetMap Wiki
Jump to navigation Jump to search

Interpolation on both sides?

The interpolation description doesn’t tell me how to handle the way most streets in USA are done, with even numbers on one side and odd numbers on the other.—Preceding unsigned comment added by Happy Hobo (talkcontribs) 2021-02-21T06:35:51‎

What about ? And yes, there would be two ways. One with addr:interpolation=odd and one with addr:interpolation=even Mateusz Konieczny (talk) 08:20, 21 February 2021 (UTC)

Street tag on an interpolation way

Currently, the wiki page says "Additional tags such as addr:street=* are still added to the objects with the addr:housenumber=* tag"

Why are we saying that?

  • Putting the addr:street on the interpolation also works. is an example -- the search for 96 The Sunny Road finds it
  • An interpolation, almost by definition, is unlikely to involve more than a single street. Therefore it's more logical to put it in the interpolation than in the individual house nodes
  • It's easier for the editor, because the street only has to be defined in one place rather than in many places
  • It reduces database space, because the street only has to be defined in one place rather than in many places

I'm not suggesting that we should ban putting the street on the housenumber node altogether, or start doing global replacements, but it works, and therefore putting it on the interpolation ought to be permitted and encouraged for future mapping.

So, maybe the text should be changed:

"Additional tags such as addr:street=* can be added either to the interpolation way or to the individual objects with the addr:housenumber=* tag"

--Harg (talk) 10:57, 25 September 2020 (UTC)

Main problem that I see with this is that addr:interpolation=* is a temporary tagging that should be migrated to proper mapping of all addr:housenumber=*. So the end state will be that there are addr:housenumber=* (with addr:street=* if located on a named street). Mapping addr:street=* on addr:interpolation=* instead would make it more complicated and require extra steps during final removal of addr:interpolation=* line. Mateusz Konieczny (talk) 11:25, 25 September 2020 (UTC)
Note that OSM wiki talk pages have relatively low traffic - if you want plenty of responses posting on tagging mailing list may be a good idea to get more diverse responses Mateusz Konieczny (talk) 11:25, 25 September 2020 (UTC)
"It's easier for the editor, because the street only has to be defined in one place rather than in many places" - and it is harder because addr:street=* may become placed in even more places.... Mateusz Konieczny (talk) 11:25, 25 September 2020 (UTC)
"It reduces database space" - I would not care too much about this, savings are minimal and temporary anyway. I would care far more about making mapping easy for mappers. Mateusz Konieczny (talk) 11:25, 25 September 2020 (UTC)

Addr tags on site perimeters

Sometimes, a site (I'm thinking of a farm, a factory or a school) consists of multiple buildings, but has only one address. Often, it's not even clear what the main building is. In those cases, I suggest that we can add the address tags to the perimeter of the site, or to the site relation. I will edit the wiki, as I think it's a trivial extension. --Sanderd17 09:10, 31 October 2012 (UTC)

Yes, this could also be applied to a lot of smaller sites (although they are usually not mapped precisely enough yet and may never be). I am thinking about buildings with (back)yards, dedicated parking slots etc., but IIRC there was some agreement to not do this - I can't remember why though. The main question with this is "What is identified by an/this address?". In practice it can mean the area inside a perimeter (and defined by a catastre) as you propose, it can mean a single mailbox, it can mean an entrance etc. --Stefanct 10:25, 28 November 2012 (UTC)
Yes, that problem (call it the "site problem") is not uncommon, and it applies not only to addresses, but also to other tags (such as, where do you put the amenity=school tag for a school). The consus, AFAIK, is to add the tag to the object representing the site as a whole (i.e. to the area of the site, or to the site relation as applicable). The alternative is to simply tag the _entrance_ of the building where the house number is displayed - but that is usually only done for buildings with multiple house numbers, i.e. pretty much the opposite case of a site with a single house number.
It's four years later but I decided to add this point. In Iceland (and some other countries), technically it's the lots (or sites) which are assigned addresses, not buildings. Now the state authority has started an effort to record the coordinates of the outlines into a database and are publishing it under their own (fairly open) licence. At least when it comes to addresses of lots, it might be important for software using OSM data to support and utilise this addressing method. It's not just about this specific import, but for the future time when defining addresses of areas is a generally feasible option. -Svavar Kjarrval (talk) 11:27, 22 August 2016 (UTC)

Missing housenumbers

Analog to noname=* which is for missing street names there should be something documenting missing house numbers and names. I will use noaddress=* so far to document this. I think noaddress=* is a better choice than something more specific, because addr:housenumber=* and addr:housename=* are orthogonal. noaddress=* is for both.

Similar tags are: noaddr:housenumber=*, noaddr:housename=*, noaddr=*, no_addr=*, no_address=*

This tag is necessary, because otherwise we are not able to document whether we already surveyed a missing house number or whether we did not survey at that place.

This scheme should fit at Germany - maybe somebody can tell about other countries. --Cracklinrain (talk) 20:45, 11 September 2013 (UTC)

Semicolon as separator

 $ wget
 # Number of different values
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' |  wc -l
 # Number of different values with comma
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' | grep \, | wc -l
 # Number of different values with semicolon
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' | grep \; | wc -l

I would recommend to use comma instead of semicolon. ;-) --Andi 00:49, 8 February 2014 (UTC)

Looking at house numbers in isolation is not a good idea when the main argument for semicolons is consistency with other tags. After all, the semi-colon value separator is a general convention in OSM. --Tordanik 06:46, 8 March 2014 (UTC)

Better documentation needed

Better documentation, with examples, is needed to make entry and editing of address information easier. For several years, one of the big complaints about databases being exported to smartphones and handheld GPS units is that entry of a specific street address might get one to the geometric midpoint of a street or road, but that may be many miles or kilometres from one's intended destination. From comments I've read on the Web, I gather this is a particularly severe problem outside of Europe. As the article currently stands, it lacks concrete examples of how address information can be added to a street such that not every house number is added, but by inserting the house numbers at the ends of city blocks or at road intersections, the software can calculate approximate locations and get one closer to the actual location sought. I've read the article as it now stands and am unable to make any sense of it. It would be better to define it in a "how-to" section than to leave it up to volunteer editors to try to experiment with data entry and produce a big mess that would need to be cleaned up later. — User8192T @ 20:53, 5 January 2015 (UTC)

Well, the information is there: Addresses#Using_interpolation. In short, the known addresses (f.e. the corner addresses) are mapped as nodes, with addr:housenumber=*, addr:street=* and all other tags you'd expect there. Then, there's a way drawn that connects the know addresses from low to high (note that intermediate points may also be addresses, or they may be non-tagged nodes just to define the form of the interpolation line). Then the interpolation line is tagged with addr:interpolation=even/odd/all to define the type of interpolation. In Mapnik, the housenumbers are rendered like normal, but interpolation lines show a thin black line. --Sanderd17 (talk) 15:30, 8 January 2015 (UTC)
Resolved: Seems to require no action Mateusz Konieczny (talk) 11:27, 25 September 2020 (UTC)

House numbers odd/even with the same letter

I wonder if addr:interpolation=alphabetic is the correct way to label the initial and final nodes in the path interpolation for different numbers but with the same letter.

For example, even numbers with letter A (100A-198A) | odd numbers with letter A (101A-199A) --Mweper (talk) 22:34, 20 February 2016 (UTC)

No, addr:interpolation=alphabetic is for the opposite case, i.e. different letters with the same number. For example, 10A-10F would be alphabetic. --Tordanik 16:44, 23 February 2016 (UTC)
So what label value is correct? Some example I have in my city are: 100A-198A and 101A-199A; 100B-198B and 101B-199B; 100 Bis-198 Bis and 101 Bis-199 Bis --Mweper (talk)
I don't think there's any support for numeric interpolation (in ranges of odd numbers only, or ranges of even numbers only, or continuous ranges of integers) if all these numbers also need a common letter suffix.
I don't think these case are so frequent that ranges will be usable. So interpolate only numbers, or only letters at the same number. For other cases (notably with "bis") you'll need to create individual address nodes to get predictable results.
Verdy_p (talk) 05:22, 11 March 2017 (UTC)

Which address are we mapping: postal or physical ?

As some buildings have access from different streets, the street access to the building may be different from the street name in the postal address so for the streetname, are we using the one the building is on (i.e. accessed from) or the one listed by the postal service ?

Personally, I'd prefer the physical streetname - but then the postcode/zipcode may not tally with the streetname. Your thoughts please!

pmailkeey 2016:6:30

In my humble opinion: for POIs, tag the objects having geometry (nodes, or closed ways for landuse-areas or for buildings, or multipolygon relations) with their physical address, independantly of residents at these points, using "addr:*" tags. If the residents have "contact" addresses at other place (including for P.O. boxes or special delivery by a remote service), these should not use "addr:*=*" fields but "contact:*=*" (There should not be any P.O. box in "addr:*" tags, only in "contact:*").
Verdy_p (talk) 05:00, 11 March 2017 (UTC)

I have the same question, but different reasoning. I'm working on mapping businesses in Holly Lake Ranch TX, and sometimes I find the address is listed on their website as Holly Lake Ranch (see area 488988898), and sometimes it's listed as Hawkins (see area 490181847). In this particular case, these businesses are in the same building. Should I see if my local post office can solve this issue, or what? I also want to mention that Holly Lake Ranch does share a Zip code and post office with Hawkins. --UltimateRiff (talk) 04:01, 15 May 2017 (UTC)

Addresses are physical (streets, numbers/housenames, and city/town) and related to official local administration.
However postal codes are often linked to a post office, which may be located in another city, so postal addresses may occasionnaly give the name of the city where the post office is located, and not the local adminsitrative city where it is located, and frequently businesses are advertizing their location using the name of a larger city nearby.
Post offices usually can work with either city names (provided mails are specifying the correct postal code/zip code). But addresses are not reserved only for postal use. When there are diffrences for mails (different distribution area from another post office, or using a postal box or special delivery for mails or products (possibly via another postal service than the public post office, that service having offices located elsewhere), this should be in the "contact:*" tags instead of "addr:*" tags. — Verdy_p (talk) 10:53, 15 May 2017 (UTC)
Fair point, although one thing I should have mentioned above is that Holly Lake Ranch is an unincorporated community, not an actual, incorporated city, so as far as I can tell, there is no official local administration, unless you count the local home owner's association or the county. If it helps, here's a link to Holly Lake Ranch, Texas on Wikipedia.
--UltimateRiff (talk) 00:56, 17 May 2017 (UTC)
I suppose that only Hawkins is incorporated and the post office is located there. But the incorporated city does not include that ranch area (and posibly other surrounding ranches in that county), so even the post office of Hawkins covering the whole country (or a large part of it) will need to redirect the mails with more precise addresses than just the city name.
Some companies in your ranch may have a dedicated post office box in Hawkins and will give "Hawkins" in their address, others will need to specify the name of the ranch area and mails will be delivered to a local private office managing the ranch, and finaly delivering the mails to their residents.
In summary, the distinction is in the kind of **postal** address used (in "contact:*" tags). But the actual physical location (in "addr:*" tag) requires giving the name of the ranch (instead of an incorporated city name: Hawkins is incorrect here if it does not include the area) and the "Wood County" name (plus the state "TX").
I think there should be also specific zip codes for the ranch itself; if you can delimit its borders you may still assign it a place name and an admin_level=8 even if it's not incorporated (the effective status of cities/towns shoud not be relevant), and specify that zip code to the area, so that you won't need to specify it in adress nodes, where you'll just list the streetnames (or road number) and housenumbers (or housename).
Those businesses that have their mails delivered in Hawkins and not in the ranch itself will need "contact:* tags, but they still keep their physical address in addr:* fields (and you don't need to specify the city name and the default zip code applicable to the ranch will apply by default except for businesses or people using PO boxes in Hawkins). If residents have their mail delivered through their local private ranch office, their "contact:*" address will be the official address of the ranch office (which may be also located in Hawkins, I don't know...) even if they still have their own physical address in "addr:*" (which should be precisely geolocated). — Verdy_p (talk) 01:56, 17 May 2017 (UTC)

Buildings with multiple postcodes

How to tag buildings which have more than one postcode ? -- pmailkeey 2016:6:30

Exactly the same way you can have buildings with multiple house numbers in streets ! Create as many address nodes as needed, don't tag the buildings themselves with addresses ! — Verdy_p (talk) 05:15, 11 March 2017 (UTC)
Resolved: Seems to require no action, it is documented on the page Mateusz Konieczny (talk) 11:27, 25 September 2020 (UTC)

2 companys/places one address?????

Tried to drag the two comp./places on the address, but it combined all the tags so it was inpossible to relate different tags to eachother eg. name and type of place. Tried to use relations, but idk the role the companies/places should use in the relation or what i should tag the relation. (sorry for bad eng.) --unsigned comment by: Sssandum, 10 March 2017, 17:47‎ (UTC)

Usually the simplest solution is to place two nodes at very close locations on the same building, so that you can tag each POI separately (also separately from the address node which would contain only the housenumber/housename; and the street name if there's no associatedStreet where that address node would be a member with role "house"). You don't need to repeat the address on the 2 POIs for companies.
Using relations seems overkill, but it's possible:
  • You'll need one separate relation per company/POI, containing the same address node or building way as its single member.
  • Don't tag the address node for describing any one of the 2 companies/POIs, the address node will only have addr:housenumber/name (and "addr:street=*" if not part of an associatedStreet relation, plus posibly "addr:city=*" if this is ambiguous for the same street name split between or separating two cities).
  • But tag the two separate relations to give their company names, or contact name/phone, opening hours, or type of activity, but don't tag its location address (which is already indicated by their member node or way containing "addr:*=*" tags).
  • Note that some POIs won't be recognized in some renderers if they are tagged as relations (the same renderers have also problems sometimes with addresses using closed ways or multipolygon-relations for buildings instead of single nodes, but we should not be limited here by tagging for specific renderers, including non-graphical renderers such as plain text search tools like Nominatim). — Verdy_p (talk) 04:52, 11 March 2017 (UTC)
Adding the same address properties to several features is not a problem. You'd rather have to do it in some places, where addresses cannot be expressed well with polygons. E.g. in Italy you usually get a housenumber for every possible entrance (even if it is not used currently). This leads to many shops being accessible via several address nodes (but often they do not use all of them as a range, but specify the one that is their main entrance). On the other hand, and this is applying to your question, doctors tend to be in the upper floors, i.e. mostly accessible via the stairs and the same entrance, so they have the same address even if they are different businesses in different apartments/offices, different floors, etc. The easiest solution to the problem is repeating the address property on every feature and interpret the address as a property of the feature (and not as a feature of it's own as it is also often done)--Dieterdreist (talk) 16:40, 15 May 2017 (UTC)
Resolved: Seems to require no action, it is documented on the page Mateusz Konieczny (talk) 11:28, 25 September 2020 (UTC)

U.S. conventions

What are the conventions in the U.S.?

@Rsterbal: - addr:housenumber=*, addr:street=*, addr:unit=*, addr:city=*, addr:state=*, addr:postcode=* are used, though note that addr:city=* is tricky to get right. For survey on the ground getting just addr:housenumber=*, addr:street=* is usually sufficient (I asked US mappers on Slack).Mateusz Konieczny (talk) 12:07, 25 September 2020 (UTC)
This JSON file in the iD codebase is a good reference for address tags in each country, laid out roughly in the order that one would write them on an envelope. Not every field is relevant in every case, and the less specific fields are less common. – Minh Nguyễn 💬 22:58, 25 September 2020 (UTC)

Addresses with sector numbers

Urban addresses in Pakistan often include a sector number. This is different from a postcode, district, subdistrict, block, street number, or house number. Is there any existing scheme that is well suited for this?

According to Taginfo Pakistan the two most common existing ways these have been tagged are:

There are two alternatives I am considering:

  • addr:sector=*; This has only 3 uses so far in Pakistan ( but about ~2000 uses in Guatemala according to global Taginfo.
  • addr:quarter=*; This is primarily used in Japan which actually seems to have somewhat similar urban addresses to Pakistan in that they can have city quarters (presumably similar to sectors), block numbers, street names, and neighborhood/place names in them all at once. It is only documented on the Japanese wiki at the moment though and I am unsure if it has implications I am unaware of.

At the moment, I am leaning towards recommending addr:sector=* if only because it is the least surprising option. It would be clear what part of a full written address that corresponds to as sector is the existing terminology, whereas quarter may be confused for something else even though it seems like a comparable concept. I am curious if anyone else has thoughts on how to approach this, any feedback would be appreciated. --Bgo eiu (talk) 21:44, 12 May 2022 (UTC)