Proposal talk:AddrN (2015)

(Early vote moved here from proposal page. --Fkv (talk) 11:50, 15 January 2015 (UTC))

• I oppose this proposal. There are better solutions already used in such places, like placing multiple address nodes within the building, and they are already supported by software because they don't introduce any new tags. The example with a conscription number doesn't need addr2: either as conscription numbers are also already supported by Nominatim, for example. Andrew Shadura 11:19, 15 January 2015 (UTC)

The first paragraph of the proposal explains why address nodes won't always work: They cannot be associated with shop nodes etc.

Conscription numbers may be already supported by Nominatim, but this proposal is NOT about conscription numbers, it's about combining multiple addresses one of which may be a conscription number. The given example cannot be tagged with addr:city=Kaltenleutgeben + addr:street=Wilhelms-Straße + addr:housenumber=4 + addr:conscriptionnumber=263, because the address containing the conscription number must not include a street. If you send a letter to an address containing street and conscription number, it will certainly be returned as undeliverable.

--Fkv (talk) 11:50, 15 January 2015 (UTC)

This argument isn't valid, as they already work with shops etc. An address node inside a building can be extrapolated to the whole building, and addresses of shops can be derived from it; as far as I know Nominatim does precisely this thing. --Andrew Shadura 16:22, 15 January 2015 (UTC)

Extrapolating and then deriving is much more complex than taking the attributes from the feature directly. Ironically, the more complex approach is less precise. It's a "best guess" approach. An address node has no defined scope. It may be valid for the whole building, or for part of the building. Applications can just look up nearby nodes and guess that they may belong together. That's what Nominatim does with place nodes. Maybe it does the same for address nodes. That does not mean that this is a satisfying approach. It's just a hack to cope with poor data. --Fkv (talk) 20:50, 15 January 2015 (UTC)

Also, it's not true what you're saying regarding the conscription number. It is possible to use both street and conscription number in an address, this actually works. --Andrew Shadura 16:24, 15 January 2015 (UTC)

Maybe it works in your country. I can tell you that it does not work in my country. I worked at a postal office for some months. --Fkv (talk) 20:50, 15 January 2015 (UTC)

I think there needs to be some support for multiple addresses, particularly in the common scenario of a business preferring a PO Box for mail (or, in my use case, veterinary mail related to disease testing), and that of houses turned into apartments. Valerietheblonde (talk) 18:44, 28 June 2016 (UTC)

is there real difference between this and previous proposal?

Old proposal located here AddrN. Xxzme (talk) 14:11, 15 January 2015 (UTC)

No real difference in content. The difference is that the 2 old proposals are just drafts, and nobody cared to finish them, and nobody replied to my comments on the talk pages. I don't want to take over half-done work of someone who does not respond. That's why I started a new proposal. --Fkv (talk) 20:20, 15 January 2015 (UTC)

okay, just don't forget to set |=status to abandoned/obsolete/... in old proposals, otherwise it will be confusing. Xxzme (talk) 20:53, 15 January 2015 (UTC)

I don't know if that's necessary. If you believe it is, why don't you do it? --Fkv (talk) 21:48, 15 January 2015 (UTC)

We should, if nobody cares to update them Proposal#Abandoned.2C_Canceled.2C_Obsoleted.2C_Undefined. I didn't because I don't know if Proposed_Features/addrN will be accepted or rejected. So we have to set different status (Abandoned vs Obsoleted) based on new proposal results. Xxzme (talk) 21:53, 15 January 2015 (UTC)

Field inheritance

Many explicit values would be duplicated but they could be inferred when omitted. For example, in nearly all cases, addr:state and addr2:state will have identical values. Consider inheriting tags which are less precise than those explicitly defined. Precision order: country, state, city, zip, street, house number, apartment (I know the list isn't compete, but it could be made compete). Example with inheritance:

• addr:state=ME
• addr:city=Portland
• addr:street=Congress
• addr:housenumber=1
• addr:unit=A
• addr2:unit=B (inherits 4 tags)
• addr3:housenumber=2 (inherits 3 tags)

Reason: allows for less manual typing. I'm suggesting that inheritance be supported but not required (explicitly duplicating field would be ok). Blackboxlogic (talk) 09:09, 13 April 2021 (UTC)

There are houses in Austria that have old addresses with addr:place=* (or addr:hamlet=*=) + addr:conscriptionnumber (or addr:housenumber) on one hand and new addresses with addr:street=* + addr:housenumber=* (differing from the old housenumber) on the other hand. addr:street should be omitted in the old address and addr:place in the new address, respectively, in order to avoid ambiguity. You obviously can't omit an address part if all address parts are automatically inherited from the first address. However, I think there is nothing wrong in inheriting address tags like addr:country from surrounding country/state/city/postcode polygons. --Fkv (talk) 12:51, 13 April 2021 (UTC)

If allowing inheritance improves the average case, but has bad effect on corner cases, then I would look at how to address corner cases (like the one you mentioned). Two options I can think of:

* The address which should not inherit a default tag must override it `addr2:street=` (an empty string)

* To prevent inheritance, don't provide a default address (see topic "When there is no default address" below)

Blackboxlogic (talk) 13:26, 14 April 2021 (UTC)

The list can't be made complete while also being consistent. For example, zip codes are point clouds, not areas: a single code may be present in multiple cities, and a single city may have multiple codes. --Carnildo (talk) 18:35, 13 April 2021 (UTC)

If the zip codes differ, then supply each value. I am well aware of the nature of zip codes, but I don't see how it conflicts with inheritance. Maybe provide an example (fabricated if needed)? Blackboxlogic (talk) 13:19, 14 April 2021 (UTC)

Hypothetical situation: a shipping company builds its headquarters and central warehouse next to each other, in the city of Anytown. The headquarters gets enough mail that it's assigned its own zip code. Later, additional construction results in the two buildings merging, resulting in a structure with two addresses, each with a distinct zip code. Also in the area is a bar from the Prohibition era that straddles the boundary between Anytown and Wheresville, with a door and address in each. Since Anytown and Wheresville aren't very large, the Post Office uses the same zip code for both.

Which building needs to have its addresses fully specified, and which one inherits? You're going to need to fully specify the ordering; you can't just say "more precise" (and then you have to hope that everyone pays attention to the ordering).

Going outside the United States, you get other situations where there isn't a strict hierarchy. In the United States, an urban area that straddles a state line is always two cities, one in each state. Other subnational divisions don't have this requirement (a single addr:city can span two addr:provinces). --Carnildo (talk) 18:33, 14 April 2021 (UTC)

When it's complicated or unclear, add the full tags for each address (don't use inheritance).

I'm more inclined to abandon the idea because it won't be intuitive to humans looking at the tags. What if inheritance were opt-in instead of opt-out. Example:

addr:street=Maine Street, addr:housenumber=5, addr[2]:housenumber=7 (two addresses, no inheritance)

addr*:street=Maine Street, addr:housenumber=5, addr[2]:housenumber=7 (two addresses, street inherited, indicated by *)Blackboxlogic (talk) 20:09, 14 April 2021 (UTC)

I think inheritance is simply too complicated for the rare cases where it'll be useful. Almost all the time, housenumber and street will need to be specified; almost all the time, city, state/province, and country can be deduced from geometry just like they are for regular addresses. --Carnildo (talk) 05:41, 15 April 2021 (UTC)

I might have a skewed sample? I routinely map areas where addr:city would be wrong if inferred by municipal boundary polygons, so I always explicitly include the tag. Blackboxlogic (talk) 14:53, 15 April 2021 (UTC)

When there is no "default" address

In cases when all addresses are equal (there isn't one that is "default"), maybe allow for omission of the default address tags and "start" with addr1. Blackboxlogic (talk) 09:14, 13 April 2021 (UTC)

Do you know any real-world example for all-equal addresses? --Fkv (talk) 12:37, 13 April 2021 (UTC)

While processing an address import, I had multiple addresses land within buildings with no way to know which one is more prominent, and it would be irresponsible to "guess". In these case, I kept them as separated nodes, which is what this proposal is trying to deprecate. Blackboxlogic (talk) 13:31, 13 April 2021 (UTC)

Sounds like a lack of local knowledge rather than all-equal addresses. Maybe you can find out the primary addresses by checking open government data, use map notes to ask other mappers, or look up the adresses in phone books. If companies reside in these building, you probably find their primary addresses on their websites. Another option is to make an educated guess (e.g. take the address that relates to the biggest adjacent road) and maybe add a fixme=* tag. If you really have no idea (or your script is too dumb to make an educated guess), you can order the addresses randomly and add a fixme=* tag. Anyway, I think that the sort order of the addresses is not THAT important. There has never been a sort order for address nodes, and nobody has ever complained. --Fkv (talk) 14:14, 13 April 2021 (UTC)

I wonder how many addresses are added mechanically vs manually (with local knowledge). I'd suggest: if 95% (my guess) of the data is added in a context where this level of local knowledge isn't available, then the tagging scheme should probably support it.

The rules for imports forbid adding fixme tags to everything, for good reason. Then the only question is "how important is order". It has value. Blackboxlogic (talk) 13:35, 14 April 2021 (UTC)

I never ever heard of a rule that forbids fixme tags on imports. If imported data needs to be fixed, it should have a fixme tag. That's what the fixme tag is meant for, isn't it? The biggest import in Austria resulted in fixme="check import" on all created objects. A more specific tag value such as "check priority of addresses" would be more helpful for sure. --Fkv (talk) 14:26, 14 April 2021 (UTC)

I went looking for where I got that idea and was surprised that it isn't on the import guidelines wiki page. I suppose I got the idea from https://wiki.openstreetmap.org/wiki/Key:fixme#This_is_not_a_tag_for_robots_nor_for_any_automated_edits Blackboxlogic (talk) 14:39, 14 April 2021 (UTC)

extend to > 9 addresses

There is at least one house with 13 addresses in Estonia: https://t.me/ruosm/377360

Can you please provide:

1. Those 13 addresses in a readable format

2. The OSM ID of that house

--Fkv (talk) 22:19, 11 June 2023 (UTC)

Found another house with 14 addresses OSM.

batyrmastyr 07:45, 12 June 2023 (UTC)

But the addresses listed on [1], namely...

- Jämejala pst 24

- Pargi tee 2, 6, 8, 10, 12, 14, 18, 22 and 28

- Saariku tee 6, 8, 13 and 14

...can't all be right. Pargi tee and Jämejala pst are nowhere near that building, and some of the addresses belong to other buildings, e.g. Pargi tee 6 is 229142008 229142008.

--Fkv (talk) 06:01, 15 June 2023 (UTC)

It seems you are right in most crucial part: looks like estonian officials added other houses with respective addresses to database, but forgot to remove excessive addresses from this record. It can be checked by visiting their maamet map and pasting 89801:001:0502 in search field.

Though requiring Pargi tee to be near house is not right: I've seen several cases in my city when houses were on some street and there were no road with respective name at all. Literally: all roads in 1 km distance had other names.

By the way, do you have plan to run voting to make addrN officially recognized?

batyrmastyr 10:42, 08 July 2023 (UTC)

Not sure about voting. Previous comments here (see early voting) and in mailing lists have indicated that people will be going to vote this proposal down without even reading it. I've seen reasons like "addresses like that don't exist in my country" or "I've always used address nodes, that's why they're good". The modern way to approve a proposal seems to be to just set it to approved with a reference to the number of already existing instances. --Fkv (talk) 11:19, 8 July 2023 (UTC)