Proposal:Associated Entrance
| Relation:type=associated_entrance | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | Schlauchboot |
| Tagging: | type=associated_entrance |
| Applies to: | 
|
| Definition: | Relation to associate objects with entrances of a building |
| Statistics: |
|
| Rendered as: | undetermined |
| Draft started: | 2011-04-23 |
| RFC start: | 2011-04-23 |
Proposal
The relation of type associated_entrance may be used to associate any kind of object with one or more entrances of a building.
The relation should be used, if the association between object and entrance(s) cannot be inferred by other means.
The relation need not be used, if the association between object and entrance(s) can be inferred by other means.
The relation of type associated_entrance has no further qualification. It implies exactly the same meaning as the association between object and entrance(s) has in cases where it can be inferred implicitly.
Object may be any kind of element, e.g. a node, way, area, or relation representing any kind of entity, e.g. a shop, an office, a pub or café, etc.
The relation of type associated_entrance can be used whenever the entrances of a building are explicitly modeled, which implies that the building itself is represented by
- a closed polygon, or
- a relation of type building.
In the first case an entrance of the building is modeled as an entrance node. In the second case an entrance may be modeled as a node or an area, cf. building.
The proposal for relations of type building suggests to use the role contains for members representing POIs inside of a building and states explicitly that
- If you have detailed information of such POI (separate entrance, different address or something like that), you should better build a separate building relation for each POI and then put this relations as members in right here.
To model one building as a couple of relations of type building may be doubtfull, inadequate or even impossible in some cases. Here the relation of type associated_entrance will come in handy. In any case, the relation of type associated_entrance provides a unique way to associate objects with entrances.
Rational
Objects like shops, offices, pubs, or cafés located inside of a building can be entered through one or more entrances of this building. This defines an association between object and entrance. In most cases this association is defined implicitly.
A building may be modeled as a closed polygon. If one or more shops, offices, pubs, and/or cafés are modeled as nodes and placed inside of the polygon, they are implicitly associated with all entrances of the building. If the building contains only one of these objects, the polygon itself may carry the attributes of this object.
A building may also be modeled as a relation of type building. In this case, all members in the role contains are implicitly associated with all members in the role entrance.
In some cases, however, the association between object and entrance cannot be modeled in this way. A building may have more than one entrance and each shop, office, pub, and café located in this building can only be entered through one particular entrance. In this case, the association needs to be modeled explicitly. The relation of type associated_entrance provides a simple solution uniquely applicable to both models of buildings, i.e. closed polygons (areas) and relations of type building. (The modeling of buildings with relations is more involved and at the time of this writing quite negligible.)
The association between object and entrance may support routing. A person trying to reach an object may not only be directed to the right building but even to the right entrance. This may be particularly helpfull to disabled persons.
The association between object and entrance may also be usefull to avoid redundancy in the definition of addresses. If some entrances of a building have a separate housenumber, one may model addresses as follows:
- (Some) Entrances carry housenumbers, i.e. have an attribute addr:housenumber.
- Addresses are defined according to the Karlsruher Schema through a relation of type associatedStreet carrying attributes like addr:city, addr:country, and addr:postcode. The relation has members in the role street and entrances with housenumbers in the role house.
- Objects like shops, offices, pubs, and cafés are associated with an address through a relation of type associated_entrance, which should contain one entrance with a housenumber.
Examples
The relation of type associated_entrance may be used, if a building has more than one entrance and
- some entrances have a separate housenumber, and/or
- some objects located inside of the building, e.g. shops, offices, pubs, and cafés, can only be reached through some entrance(s) of the building.
Tagging
| Key | Value | Discussion |
|---|---|---|
| type | associated_entrance | mandatory |
Members
| Way, Node, Area, or Relation | Role | Recurrence? | Discussion |
|---|---|---|---|
  |
entrance | one or more | Node or area defining one particular entrance of a building. For areas see building. The specification of more than one entrance is allowed, if all objects are associated with all entrances specified. |
 |
none | one or more | Any object you want to associate with the specified entrances of a building, e.g. shops, offices, pubs, cafés etc. |
Rendering
The relation of type associated_entrance defines a logical relationship between objects. It has no apparent effect on the rendering of these objects.
Features/pages affected
The modeling of entrances through nodes of a building polygon, c.f. entrance, or as members of a relation of type building and all pages referring to objects that one might associate with an entrance and/or an address.
Comments
Comments should be added on the Discussion page.