Proposal:AssociatedAddress
| associatedAddress | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | flaimo |
| Tagging: | type=associatedAddress |
| Applies to: | 
|
| Definition: | A way to connect multiple POIs to one address object |
| Statistics: |
|
| Rendered as: | none |
| Draft started: | 2011-04-23 |
| RFC start: | 2011-04-24 |
Outline
An address should preferably only exist once in OSM to avoid redundancy and eliminate possible pitfalls for routing programs. Under some circumstances it is currently not possible to associate an object tagged with an address with other POI objects. To solve this problem of such (rare) corner cases this proposal introduces a new type of relation tagged with type=associatedAddress.
Mapping situations solvable WITHOUT a relation
Before addressing the case where a relation is needed, here is a list of mapping situations that can be solved without a relation:
One address object with one POI
This is the simplest constellation. A single node or area is tagged with POI data as well as an address. No problems there.
One building with one address, multiple POIs inside
This one is also solvable without a relation. The individual POIs don't have the address information tagged to them. It can be determinated by the boundaries of the surrounding building which has an address tagged on to it.
Multiple POIs with individual addresses in one building
In case a building has multiple entrances with one address assigned to each entrance and there is only one POI for each address, the POIs/address can be mapped on to each building entrance.
One POI object, multiple addresses inside
Sometimes POIs are very big (industrial areas for example) and have multiple buildings on them, each with its own address. This situation is also solvable. In case you know the address, a check for the surrounding boundaries can be done to determinate the POI. Also, the other way around, all address data can be determinated if you only have the POI information.
Mapping situations ONLY solvable with a relation
Sometimes there are situations where a building can have multiple addresses, not necessarily assigned to specific entrances. Further there are multiple POIs inside the building, each associated with one of the addresses. For example, this often can be the case for shopping malls. For situations like that, there isn't enough information available, which would allow to directly connect a specific POI to a specific address. This proposal tries to solve this, by using a relation.
Relation associatedAddress
To solve this problem a new relation has to be created with the tag type=associatedAddress. The object tagged with the address, as also all POI elements that should be associated with the address are added to the relation.
- There can be only one object with an address inside a associatedAddress relation.
- An address object can only be part of one associatedAddress relation.
- POI objects without an address information can be part of multiple associatedAddress relations.
- A relation should only be used if the address cannot be made unique though another addr:=* tags. For example if all objects have the same street number, but different door numbers you could use addr:doornumber=* instead of the relation. (addr:doornumber=* isn't official, it's just used as an example here)
- Note that there is also a proposal for associated Entrance. While that proposal tries to associate physical entrances to POI objects, this proposal here, is for address data, which does not necessarily have to be mapped to entrances. There will be cases where both kind of relations need to be used.
illustration on how associatedStreet, associatedAddress and associatedEntrance work together:
Editors
- Editors could provide a function, where the user selects the address object as also all relevant POI objects and then clicks a button to automatically create a relation with all the selected elements in it.
- If the user enters an address as a destination, the program could then offer all the POIs associated with the address to directly route the user to the POI instead of only the address object
- If the user chooses a POI close to him, the associated address could easily be determinated.