Proposal talk:Proposal to Document the Key "addr:parentstreet"
To start (but, I hope, minimise the length of) the discussion, I have attempted to summarise some of the comments made previously in the discussion groups linked to under "External discussions". I have not attributed them, as my editing could lead to some misrepresentation.
| Comment / Suggestion | Response |
|---|---|
| We could store the additional information in "addr:housenumber" or "addr:housename". e.g. "addr:housenumber=1 Rose Cottages"; "addr:street=Green Lane" or "addr:housename=Rose Cottages 1"; "addr:street=Green Lane" |
The main objection to this is that "1 Rose Cottages" is not a name, or a number. Whilst this "fix" might allow retrieval of the full address in the correct form (so long as it was entered as "1 Rose Cottages" and not the other way round), it would not allow a search for "addr:housenumber=1", to find the property. |
| We could use "addr:housenumber" for the number, but use "addr:place", or "addr:suburb" for "the rest". | "addr:place" and "addr:suburb" are not appropriate. According to the Wiki page for "addr:place", " This is part of an address which refers to the name of some territorial zone (usually a place=* like island, square or very small village) instead of a street (highway=*). Should not be used together with addr:street=*." |
| street/substreet would seem to be a better match to thoroughfare/dependent thoroughfare.
|
As the respondent themselves said, it is a 2-level hierarchy, so it is not important which way it is modelled. However, if we were to map a Post Office Address to OSM as: In the example in the Proposal, a house with the address "1 Rose Cottages, Green Lane" would be tagged as and would be recovered as "1 Green Lane". |
| Case 1 and 4 are really examples where you have two streets in the address. addr:street + addr:parentstreet sounds about right.
Case 2 and 3, on the other hand, now have a building name in the addr:street tag. This is incompatible with the standing definition of the key in OSM. The UK mailing list had the suggestion to add an additional addr:terrace for the cases 2 and 3. I really think that is the best way to go here, although I would suggest the more generic addr:building. So in total we'd end up with four forms of addresses:
(classic street address)
(address without street)
(address with 2 streets)
(address with housenumbers referring to terraces or buildings) |
Thank you very much for your contribution to the debate.
However, I regret that I am a little confused. Cases 2 and 4. I would have thought that Cases 2 and 4 were the most clear cut, because there is an actual second road (Red Lane in Case 2 and Little Lane in Case 4.) Did you mean to say "Cases 2 and 4 are really examples where..."? Case 1. 1 Rose Cottages and 2 Rose Cottages are not really on a separate road, so the use of "addr:street=Rose Cottages" is a bit of an artifice, but then they are also not a terrace. They are detached from one another, where a terrace is a row of houses (>2 houses in my dictionary, as 2 are "semi-detached") that are joined to one another, with shared walls. In any case, I cannot find any documentation for "addr:terrace=*" in the wiki and according to Taginfo, it is used only 244 times. I regret that I am not skilled enough to analyse the existing 3,600 uses of "addr:parentstreet=*" to find out how many instances there are of each of the 4 cases that I have documented. I regret that am not (currently) prepared to add "addr:terrace" to this proposal, as none of my 4 cases shows a terrace and including it would take the focus away from "addr:parentstreet". In defence of my proposal for Case 1, "Rose Cottages" has several attributes of a street. There is a row of houses, all using "Rose Cottages" in the address, where it follows either a sequential number, or a housename. Case 3. I included Case 3 to canvass opinion on it. It was suggested in the Tagging discussion, where someone said, "The third major category is tower blocks. I suspect many mappers have used addr:housename for the name of the tower block itself and addr:housenumber for the number of the dwelling within the block. Which sort of works, but means addr:housename has a different meaning (it would fail if anyone within the block named their dwelling)." I agree that using "addr:housename" for the name of the block, or building is NOT appropriate to apply to a single apartment within the block. It would be duplicated on all the apartments and (as the poster said) one of the apartments might have a different "addr:housename". So what else to use? "addr:building* (addr:building; addr:buildingname; addr:buildingnumber; etc.) has just over 350 uses, but I cannot find it documented. I did find a proposal from 2012 https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates that included the use of "addr:building" for the name of a block of apartments, but this was in the section "Counter Proposals" and did not specify whether this was to be tagged on the block, or on the apartments within the block. "adrr:block" is documented at: https://wiki.openstreetmap.org/wiki/Key:addr#Detailed_subkeys ...but there is refers to a "city block" (i.e. section of a street between consecutive side streets), so I do not think it can be applicable here.. So, I do not see any existing, "approved" alternative for this case. As with "addr:terrace", I regret that I am not (currently) prepared to add "addr:building", to this proposal. If Case 3 is rejected by others, I will remove it from the proposal. |
| I see many contributors adding the name of the main road to service roads. I am afraid that we are going to have a high rate of routing information with this tag (to get to my house, take street foo before arriving at my street) | Clearly, this would be undesirable, but I am not sure how big a risk it is. What reason would mappers have to add extra information like this? Perhaps I should add some words to the proposal, saying that "addr:street; addr:parentstreet" should only be used where both street names are part of the normal / official address of the property? |
| what is the difference with
addr:housename (the name of the building) + addr:unit (the number inside this building) ? |
I assume that this refers to my Case 3; a block of flats / apartments. As I understand it, "addr:housename" is used for the name of a single dwelling (a single house, or a single apartment) and NOT for the whole building. If we use "addr:housename" for the name of the building, we cannot use it again for the name of a single apartment within it.
My understanding (from the Wiki) is that "addr:unit" does not refer to the whole building, nor to a single apartment within it, but to a section of the building (e.g "The West Wing"). I do not believe that is is directly relevant here. |
| This is common in Ireland and the U.K where what a house is named and called doesn't follow the number and street structure. Since building on a house happened in sections with a few getting added with their own naming, they tend to follow Name and the Mews, Terrace, Way, Villas, Cottages, Court, and many more. One solution that is already used is housename, like this here, for 1 Ellerslie Villas, Bray, Sidmonton road. Which even though the number is second in the tagging, still comes up on a search in. So when you said in your first response that it wouldn't come up in a search, can you give an example.
Otherwise we have to use some general name housedesignation. Another problem in Ireland anyway is that modern collections of houses called Houses Esatates have a name, but the road built for them don't have a name or one like L123456 and the houses can go onto other streets, like Corke Abbey. Or it can be that way when roads get realigned like in Corduff Cottages. A Housing Estate and can have a overall name like Connawood, but is broken down into subsections all whose numbering begin from 1. The sheer madness of building naming in Ireland can be seen here, with the area Ballywalyrim having, Heights, Cottages, Close and then Glenthorn, Sugerloaf apartments, which are on opposite sides of the same street. Overall street is not a flexible tool for chaotic way addresses can be used. |
Text |
Please add any further comments or suggestions below here:-
Vietnam
Just wanted to note that, while this key may be suitable for some countries, it's inadequate for Vietnam, where the address structure allows for a deeply nested hierarchy of streets. For example, this address is on alley 22 off of alley 23 off of alley 16 off of alley 103 off of Chiến lược street. By convention, mappers have been tagging something along the lines of addr:street=103/16/23/22 Chiến lược or addr:street=Hẻm 103/16/23/22 Chiến lược, and the nearby street is given a matching name=*. It's less structured than what's being proposed here, but it closely matches the standard address format. I think there are diminishing returns to putting these more deeply nested addresses in a formal tagging structure, so mappers in Vietnam will probably have to ignore addr:parentstreet=* even though the concept exists in that country. – Minh Nguyễn 💬 09:46, 1 February 2021 (UTC)
- Have seen addr:alley=* or something in Taiwan. Otherwise alley street addresses are directly tagged on the road name=* in full. (and I don't like using highway=service for the sake of its service=alley). ---- Kovposch (talk) 10:31, 20 January 2022 (UTC)
hierarchical information / expectations
For complicated and non strictly hierarchical addresses there is already addr:full=*. So instead of using that, what would be the expectation for this tag to be used by data consumers? There needs to be a ruleset how the parentstreet would be needed to be formatted in the final address. What would be the expectation for hierarchical searches etc etc. Flohoff (talk) 20:32, 5 February 2021 (UTC)
use with addr:place?
Would it make sense to use addr:parentstreet with addr:place? I come back to the example of terraces but also big old houses that have been split in two or had a house built in the grounds, now named 1 Mount View etc. It resolves the ambiguity about which element of the address the house number goes with. Or maybe once again I should try and get over the meaning of street! TrekClimbing (talk) 08:32, 9 April 2021 (UTC)
As you'll have seen on talk-gb I still think combining addr:parentstreet with addr:place makes sense when the smaller part is not a highway, and this makes it compatible with nominatim. For example a building on a hospital site near me: addr:housename=Field House addr:place=Bradford Royal Infirmary addr:parentstreet=Duckworth Lane Would you be willing to add that to this proposal?
TrekClimbing (talk) 08:44, 19 January 2022 (UTC)
Redefining standard concept and tag
"House-number" and addr:housenumber=* are supposed to be related to a street (or village), in both real world and OSM. It is not any number assigned to a building. Case 1 addr:street=Rose Cottages (not a street) + addr:housenumber=1 (not a "house-number") would express a wrong representation, not merely "incomplete" before it is supported. Unless there is really a street section named with a "Cottages" suffix, they are just a group of buildings. A "sub-division" on a street doesn't mean it has to be a "street" as well. Whoever's terming this part of the address as "dependent street" is only taking some liberties in the hierarchy for convenience.
Cf "Terrace", where indeed there are often roads and pathways named as such, but not always.
I don't see addr:unit=* being discussed here. What's discussed in Addresses_in_the_United_Kingdom#When_to_use_addr:unit? is in fact more like addr:door=*, which is not mentioned in either page. It's an unfortunate naming causing expected misunderstanding in both keys. The addition of such an overlapping definition in Key:addr#Detailed_subkeys (flat, or office/shop "unit" in everyday usage) is at odds with the original scope Proposed_features/addr_keys_(2011-04)#addr:unit (basically a sub-building).
While addr:dependentstreet=* on its own doesn't work, neither would re-using addr:housenumber=* be correct. You should find something below addr:housenumber=* altogether.
--- Kovposch (talk) 23:09, 20 January 2022 (UTC)
Ok I see your response above, and Case 3 is even worse. That's abusing this low er part of the address by extending to any arbitrary component below. Not to mention now you are further throwing away the building's "house-number", which is what addr:housenumber=* is for.
I disagree a addr:house*=* should be interpreted as for a individual building (or a "house" ). Like how there can be no house-numbers, there can also be only a single house-number for a site with multiple "main" buildings. {{tag|addr:house*}] should be understood along the actual "street". addr:building=* would be perfect for the building itself. Only Case 2 and 4 are valid in using addr:parentstreet=*.
--- Kovposch (talk) 23:48, 20 January 2022 (UTC)