Proposal:Proposal to Document the Key "addr:parentstreet"
| Proposal to Document the Key "addr:parentstreet" | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | PeterPan99 |
| Tagging: | addr:parentstreet=* |
| Statistics: |
|
| Draft started: | 2021-01-16 |
| RFC start: | 2021-01-20 |
Proposal
It is proposed to document the use of the Key "addr:parentstreet", which is already in use over 5,600 times, but currently undocumented.
Rationale
There are some buildings that have 2 street names in their address. e.g. 1 Rose Cottages, Green Lane, Smallville. There may be other properties close by with addresses on the "senior" of these 2 streets, using the same housenumbers. e.g. "1 Green Lane, Smallville". There is a need to distinguish these from one another.
Documenting the de facto use of addr:parentstreet should assist mappers in using a key, which is already in use, rather than invent a new one. Increased use of a consistent key should encourage renderers and other consumers to support that key.
Tagging
Tagging to be Documented
| Key | Value(s) |
|---|---|
| addr:parentstreet | user defined |
Meaning: Part of the address of one or more buildings. The senior (larger, more important) of 2 streets, both of which are used in the address of each of one or more buildings.
Elements Tagged:
Nodes used to give the address of a property.
Closed ways that define a building that has a single address.
Relations that group buildings that share a single address. These might be relation:type=site, or relation:type=multipolygon.
Current Usage:
addr:parentstreet
Current Usage of Alternative Keys
addr:parent_street
addr:dependentstreet
addr:dependent_street
Examples
Case 1. Parallel, or Coaxial, Streets.
A group of (i.e. 2 or more) buildings, lying along a street, may share a name, which forms a part of their address and is, in effect, a sub-division of the street. They may be in a terrace, semi-detached, or separate buildings.
There may be other small streets with the same name in the same area, making inclusion of the parent street essential for disambiguation and to aid navigation.
For example:
These properties should be tagged as follows (moving left to right across the diagram):
addr:housenumber=1; addr:street=Green Lane
addr:housenumber=2; addr:street=Green Lane
addr:housenumber=1; addr:street=Rose Cottages; addr:parentstreet=Green Lane
addr:housenumber=2: addr:street=Rose Cottages; addr:parentstreet=Green Lane
addr:housenumber=3; addr:street=Green Lane
A real-world example: A co-axial, or parallel street.
Case 2. Orthogonal Streets.
A small street may lie orthogonal to a larger street and all properties in the smaller street may have the larger street included in their recognised address.
There may be other small streets with the same name in the same area, making inclusion of the parent street essential for disambiguation and to aid navigation.
Tagging would follow the same pattern as for Case 1, with the properties on Red Lane being tagged:
addr:housenumber=<n>; addr:street=Red Lane; addr:parentstreet=Blue Street
A real-world example: An orthogonal street
Case 3. Blocks of Flats / Apartments (a single building).
Many cases of flats (or apartments, or suites) within a single building may be tagged quite satisfactorily without using "addr:parentstreet". This can be done by using:
addr:housenumber <--> the number of the building within the street
addr:housename <--> the name of the building
addr:street <--> the street that building stands in
addr:flats <--> the list (or range) of the flat numbers within.
However, if individual flats are mapped and if the block has a unique name (but not a house number) within the street, then each flat could be tagged as follows:
addr:housenumber <--> the number of the flat
addr:housename <--> the name of the flat
addr:street <--> the name of the block
addr:parentstreet <--> the street that the block is on.
No doubt there will be some rare cases where this scheme will not allow the full address of every flat to be tagged as separate data items and the mapper will have to fall back on "addr:full=*", but there comes a point at which the search for 100% perfection would prevent the use of a scheme that covers 99.9% of cases.
Case 4. Group of Buildings With a Single Address
If a single owner occupies a group of buildings and uses a single address for all of them, this could be tagged by grouping the buildings in a site relation and tagging the relation with the address. If that single address includes 2 street names, addr:parentstreet could be used in tagging the relation. An example might be a business occupying several light industrial units, as shown in the diagram.
In the example in the diagram, each unit could be mapped as a separate building and the buildings could then be grouped in a site relation, tagged as:
name=G Brown & Sons
addr:housenumber=1-3
addr:street=Little Lane
addr:parentstreet=Main Street
addr:city=Mytown
addr:postcode=MY1 2ZZ
Real-world example: Buildings grouped by a relation
Parent Street v. Dependent Street
Why Not Use addr:dependentstreet (or addr:dependent_street)?
Royal Mail (RM) has data items "Street" and "Dependent Street" in the PAF. It is tempting to copy this structure, but if a data consumer is not aware of the "Dependent Street" concept, or data item, they would associate the housenumber with the "Street".
In the example in Case 1 above, if 1 Rose Cottages, Green Lane were tagged as:
addr:housenumber=1
addr:dependentstreet=Rose Cottages
addr:street=Green Lane
a consumer unaware of the use of "addr:dependentstreet", would retrieve its address as "1 Green Lane", which would be incorrect (there is already a 1 Green Lane, further along).
There are currently 3 uses of "addr:dependent_street=*" and NIL uses of "addr:dependentstreet" in the OSM database.
Why Use addr:parentstreet?
The concept of addr:parentstreet, which is already in use in OSM, is a "fail safe" option.
In the example in Case 1 above, if 1 Rose Cottages, Green Lane were tagged as:
addr:housenumber=1
addr:street=Rose Cottages
addr:parentstreet=Green Lane
its address would be retrieved by a consumer aware of addr:parentstreet as "1 Rose Cottages, Green Lane", which is correct, whilst its address would be retrieved by an unaware consumer as "1 Rose Cottages", which would be incomplete, but would avoid the error of retrieval as "1 Green Lane" and, combined with the Post Code, would still allow it to be located.
There are currently over 3,600 uses of "addr:parentstreet" in the OSM database. This proposal is to document the existing tagging, not to change it.
Rendering
No changes to rendering are expected.
Features/Pages affected
Map_Features. Add a line to the table of address sub-keys to document addr:parentstreet. This should automatically populate the table in the Page "Key:addr"
| Key | Value | Element | Comment | Rendering | Photo |
|---|---|---|---|---|---|
| addr:parentstreet | user defined |    |
Where a building has 2 street names in its address, use addr:parentstreet for the "parent" (more senior / larger / more important) street and use addr:street for the "child" (junior / smaller / less important) street. Comparing to UK Royal Mail addressing, OSM <--> RM addr:street <--> Dependent Thoroughfare addr:parentstreet <--> Thoroughfare. How NOT to use "addr:parentstreet". You should not use "addr:parentstreet" to add routing information that is not part of the normal / official address of a house (or other building). |
External discussions & documentation
- Blog post "Housing Terraces in Wales : a minor addressing conundrum " by User:SK53 providing examples of the issue from Wales
Comments
Please comment on the discussion page.