Talk:Key:addr:place
- In Sofia, Bulgaria, many buildings have a number that relates not to a street, but to a neighbourhood. So, addr:place is adequate, I think. These buildings often however also include in their address the street that they're on, for convenience. It's not necessary, it's not canonical, but it's widely used by people in the city. So we have buildings that I think legitimately carry both addr:place and addr:street (with addr:place being the "main" one, not that this is indicated in the tagging). Saintam1 (talk) 16:11, 6 July 2017 (UTC)
addr:place & addr:street on same object
The text currently states "Don’t use addr:place=* if the building belongs to a street". In Denmark where all adresses were imported, we chose to import addr:place in addition to addr:street details, because this makes it easy to determine which adresses is officially considered part of which place (village,town, suburb). This is why in Denmark there are lots of objects with both addr:place & addr:street tags. Those 2 tags simply serve different functions. --Hjart (talk) 09:00, 6 August 2019 (UTC)
- Please do not confuse addr:place and addr:city, the latter is used for all kind of places, like hamlets, villages, towns and cities. Addr:place is a special tag reserved for addresses that do not refer to a street. I don’t recall an address import in Denmark, but if it has used addr:place for what should have been addr:city, it is an issue that you should solve. —Dieterdreist (talk) 12:18, 6 August 2019 (UTC)
- Danish addresses were first imported in 2009, then by AWSbot, then AutoAWS. In imported danish addresses address addr:city always referred to the name of the postcode (which apart from a main village/town can cover smaller villages and hamlets in an area), while addr:place always referred to those "subareas". Example of an address in the hamlet Hjerting near Rødding: 972123072
972123072. In a danish context this makes perfect sense. --Hjart (talk) 13:37, 6 August 2019 (UTC)
- There are 2 tags that might apply, addr:hamlet and addr:suburb, but addr:place would be (is) a misuse in this context and should be fixed. —Dieterdreist (talk) 13:55, 6 August 2019 (UTC)
- Please note that addr:place in this context were always used as a generic tag. I wasn't involved in the original decision, but fail to see the harm in using it this way --Hjart (talk) 14:07, 6 August 2019 (UTC)
- The harm I see is that it should only be used for addresses where no street names exist and the address (often including the addr:housenumber) refers to a place name. If you use it differently you are creating ambiguity and on the long run are blurring the meaning of the tag. —Dieterdreist (talk) 14:15, 6 August 2019 (UTC)
- What I'm getting from reading Key:addr:place is that it's in practice is a fallback for when there's no valid addr:street and that using both on the same object is in practice pretty harmless (despite claims to the opposite). Can you give examples of exactly where it might create problems? --Hjart (talk) 14:46, 6 August 2019 (UTC)
- Using a tag against its definition is always harmful because it blurs the tag, and this discussion proves it (just reread your initial statement, which asks for a change in the definition because of your local diverging usage). The page says under „tagging“: Use addr:place instead of addr:street=* for buildings whose number belongs not to a street, but to some other object. It is okay to have both addr:place=* and addr:city=* with the same value on the same object. Your addresses are ambiguous because I cannot see whether the housenumbers refer to the street or the place.—Dieterdreist (talk) 15:45, 6 August 2019 (UTC)
- As already mentioned I see addr:place as practically just a fallback to addr:street, so in practice there's no real ambigousness here. Data users would try to read addr:street first and only if that fails, addr:place. So again, as far as I can see, there's minimal harm in using both --Hjart (talk) 16:01, 6 August 2019 (UTC)
- I'll also stress that as I'm reading the definition, we are not using addr:place against it at all, but merely despite the text "Don’t use addr:place=* if the building belongs to a street", which really isn't part of the definition. --Hjart (talk) 16:07, 6 August 2019 (UTC)
- By misusing addr:place=* you’re breaking the search in Nominatim and other geocoding software since addr:place=* means this address does not belong to a street; instead, it is directly addressable by it’s house number and place only. If you give me an example of a Danish address you’re talking about I’ll show you. --Andrew Shadura 16:10, 6 August 2019 (UTC)
- There is an example in the text above --Hjart (talk) 16:15, 6 August 2019 (UTC)
- I never experienced any problems with those adresses in any software I've used BTW --Hjart (talk) 16:18, 6 August 2019 (UTC)
- As this inconsistency has been introduced by a sloppy import rather than by inexperienced mappers, I would suggest to revert/remove these addr:place tags from the import(s). —Dieterdreist (talk) 21:25, 6 August 2019 (UTC)
- After you explain exactly what harm they do. --Hjart (talk) 22:08, 6 August 2019 (UTC)
- It is already written and repeated above.—Dieterdreist (talk) 23:21, 6 August 2019 (UTC)
- Several times today I have asked you to give examples of exactly what harm they do and so far you have failed to do so. I have repeatedly tried to explain why they do no harm and so far you have ignored that. My initial statement doesn't even ask for a redefinition (despite your claim). I'm just noticing that "Don’t use addr:place=* if the building belongs to a street", may not actually be all that reasonable. Please note that we've been using addr:place & addr:street on the same objects for 10 years in Denmark and never experienced any problems. --Hjart (talk) 23:39, 6 August 2019 (UTC)
- I tried to explain that using a tag differently than how it is defined poses a problem for the global meaning of the tag, it is blurring the meaning. This doesn’t mean you would necessarily run into problems locally, e.g. if you applied the tag consistently different from the definition in the whole of Denmark. —Dieterdreist (talk) 23:57, 6 August 2019 (UTC)
- I've tried to explain that while we may have used this tag in a slightly different way than originally intended, we have in fact not used this tag in a different way from how it's defined. My initial intention here was merely noticing that there's no real reason why addr:street & addr:place should not be used on the same objects. --Hjart (talk) 00:08, 7 August 2019 (UTC)
- I tried to explain that using a tag differently than how it is defined poses a problem for the global meaning of the tag, it is blurring the meaning. This doesn’t mean you would necessarily run into problems locally, e.g. if you applied the tag consistently different from the definition in the whole of Denmark. —Dieterdreist (talk) 23:57, 6 August 2019 (UTC)
- Several times today I have asked you to give examples of exactly what harm they do and so far you have failed to do so. I have repeatedly tried to explain why they do no harm and so far you have ignored that. My initial statement doesn't even ask for a redefinition (despite your claim). I'm just noticing that "Don’t use addr:place=* if the building belongs to a street", may not actually be all that reasonable. Please note that we've been using addr:place & addr:street on the same objects for 10 years in Denmark and never experienced any problems. --Hjart (talk) 23:39, 6 August 2019 (UTC)
- It is already written and repeated above.—Dieterdreist (talk) 23:21, 6 August 2019 (UTC)
- After you explain exactly what harm they do. --Hjart (talk) 22:08, 6 August 2019 (UTC)
- As this inconsistency has been introduced by a sloppy import rather than by inexperienced mappers, I would suggest to revert/remove these addr:place tags from the import(s). —Dieterdreist (talk) 21:25, 6 August 2019 (UTC)
- Using a tag against its definition is always harmful because it blurs the tag, and this discussion proves it (just reread your initial statement, which asks for a change in the definition because of your local diverging usage). The page says under „tagging“: Use addr:place instead of addr:street=* for buildings whose number belongs not to a street, but to some other object. It is okay to have both addr:place=* and addr:city=* with the same value on the same object. Your addresses are ambiguous because I cannot see whether the housenumbers refer to the street or the place.—Dieterdreist (talk) 15:45, 6 August 2019 (UTC)
- What I'm getting from reading Key:addr:place is that it's in practice is a fallback for when there's no valid addr:street and that using both on the same object is in practice pretty harmless (despite claims to the opposite). Can you give examples of exactly where it might create problems? --Hjart (talk) 14:46, 6 August 2019 (UTC)
- The harm I see is that it should only be used for addresses where no street names exist and the address (often including the addr:housenumber) refers to a place name. If you use it differently you are creating ambiguity and on the long run are blurring the meaning of the tag. —Dieterdreist (talk) 14:15, 6 August 2019 (UTC)
- Please note that addr:place in this context were always used as a generic tag. I wasn't involved in the original decision, but fail to see the harm in using it this way --Hjart (talk) 14:07, 6 August 2019 (UTC)
- There are 2 tags that might apply, addr:hamlet and addr:suburb, but addr:place would be (is) a misuse in this context and should be fixed. —Dieterdreist (talk) 13:55, 6 August 2019 (UTC)
- Danish addresses were first imported in 2009, then by AWSbot, then AutoAWS. In imported danish addresses address addr:city always referred to the name of the postcode (which apart from a main village/town can cover smaller villages and hamlets in an area), while addr:place always referred to those "subareas". Example of an address in the hamlet Hjerting near Rødding: 972123072
Squares
Could someone please clarify whether squares with names on street signs should go into addr:street=* or addr:place=*? --Oreg2 (talk) 15:07, 7 November 2022 (UTC)
- In Poland squares are treated as special type of street, not as a special type of settlement so we use addr:street=* Mateusz Konieczny (talk) 15:34, 7 November 2022 (UTC)
- Makes sense to me. Thank you, Mateusz. Any other opinions? --Oreg2 (talk) 14:44, 11 November 2022 (UTC)
- You may get more answers on https://community.openstreetmap.org/ or tagging mailing list Mateusz Konieczny (talk) 22:54, 11 November 2022 (UTC)
- Makes sense to me. Thank you, Mateusz. Any other opinions? --Oreg2 (talk) 14:44, 11 November 2022 (UTC)
addr:place and addr:city with the same value on the same object and clarification on use of addr:place on hierarchically high objects
Wiki states that "it is okay to have both addr:place=* and addr:city=* with the same value on the same object", but on imports mailing list [1] I'm told that "addr:place and addr:city may appear together when they refer to different places which both would appear in the postal address. Do not duplicate them when they refer to the same place or datausers will interpret the address wrong". How is this supposed to be?
Also, is it supposed to have addr:place tag on all addresses not having a street name no matter the type of the next object above in hierarchy even if it is a subdistrict or district (were other objects referred by addr:place (e.g., villages and towns) can be located)? In Latvia, it is common for house names (without street name) to belong directly to subdistrict (before July 1, 2021 even to district in case there was no subdistrict). E.g., 982174951
982174951.
--Dāvis Kļaviņš (talk) 06:29, 9 January 2023 (UTC)
Remove Examples category
The majority of the Examples are in Russian. Given this is the English language page, it's very confusing for newcomers . The examples are on the Russian page. The others appear to not be places. I proposed to remove this section to make it clearer. The wiki should follow the KISS principle.--DaveF63 (talk) 21:45, 30 July 2023 (UTC)
- Russia is also being mapped. Can you give English language equivalents? If yes, feel free to replace them. If some are unique to non-English speaking countries then removing them only for not being in English is weird Mateusz Konieczny (talk) 05:22, 31 July 2023 (UTC)