Talk:Addresses

From OpenStreetMap Wiki
Jump to navigation Jump to search
Talk:Addresses - Other languages

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 (talk • contribs) 2021-02-21T06:35:51‎

What about https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation ? 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)
Resolved: Mateusz Konieczny (talk) 13:57, 17 November 2023 (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. https://www.openstreetmap.org/way/350655164 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 http://taginfo.openstreetmap.org/api/4/key/values?key=addr:housenumber
 # Number of different values
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' |  wc -l
   481357 
 # Number of different values with comma
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' | grep \, | wc -l
  47704 
 # Number of different values with semicolon
 $ cat values\?key\=addr\:housenumber | jq '.data[].value' | grep \; | wc -l
   4294

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)
Resolved: It is now discussed at the page Mateusz Konieczny (talk) 13:57, 17 November 2023 (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 https://www.bankatcnb.bank/about-location-holly-lake-branch.htm area 488988898), and sometimes it's listed as Hawkins (see http://dratco.com/holly-lake-office 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)

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 (https://taginfo.geofabrik.de/asia/pakistan/keys/addr%3Asector) 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)

Addresses: on the ground situation vs authoritative datasets

I propose to add a following section: "Addresses: on the ground situation vs authoritative datasets" with following content

There are sometimes conflicts between signed addresses and ones that are in some official dataset

  • the best case: reality and official dataset matches
  • addresses that are officially existing but are not signed and not used in any way (addresses of planned building, currently there is a field or forest or wetland there)
  • signed but you cannot deliver anything there (ruins or demolished building), is in official database
  • address is signed and used but is not present in official dataset
  • official dataset has some clear glitches (single address repeated 20 times, 50 addresses from the entire villages assigned to the single house, no address elsewhere)

There are some claims that if given country has address dataset self-described as authoritative, then addresses not listed there should be deleted as invalid - even ones signed and used. This would negate on the ground strategy typical to OSM editing, but some people argued that it should be preferred.

Mateusz Konieczny (talk) 13:06, 17 June 2023 (UTC)

Using interpolation "For a summary of this section, see"

Why this is linked?

Selected answer has "I don't know about interpolation but I find the JOSM plugin HouseNumberTaggingTool very helpful when tagging multiple addresses."

Next answer is longer than our section.

If this section needs summary at start it can be added to wiki directly

@Eteb3:

Mateusz Konieczny (talk) 07:26, 8 August 2023 (UTC)

I don't know why it's linked. I moved it from the bottom of that section to the top (it was called "see also") because the help answer is, to my mind, vastly clearer than this section - which I found completely impenetrable. Honestly I would rather replace this section with the help answer, but I didn't want to do too much. eteb3 (talk) 08:04, 8 August 2023 (UTC)
Oh I see, I didn't really know about "selected answers". The bit that was helpful to me (ie, was readable!) is jmapb's answer. eteb3 (talk) 08:06, 8 August 2023 (UTC)
Feel free to edit that section based on what jmapb wrote! Mateusz Konieczny (talk) 10:23, 8 August 2023 (UTC)
Thanks. Just done. Feel free to clean up the formatting. eteb3 (talk) 11:28, 8 August 2023 (UTC)

Buildings with multiple house numbers - is there really no consensus?

Which areas, if any, consider addr:housenumber=11,13,15 or addr:housenumber=11;13;15 as preferable over mapping multiple address nodes in cases when multiple address nodes can be tagged? Mateusz Konieczny (talk) 13:55, 17 November 2023 (UTC)

Putting address grid ticks back on the map

I'm thinking up ideas about "putting address grid ticks back on the map". Jidanni (talk) 08:07, 4 December 2023 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Addresses&oldid=2626248"