User:Impiaaa/Hierarchical access

This page is some notes on what could become a new relation type to describe complex access relationships. Read the examples to get an idea of what this could apply to.

Tags

Key	Value	Explanation
type	access (conflicting with existing usage! TODO find a better name)	This is an access relation
access	*	Used to describe access restrictions only if it cannot be described in the tags of either member

Members

Way or Node	Role	Recurrence?	Explanation
	accessfrom	one	The object that describes prerequisite access
	accessto	one or more	The object that requires access from the accessfrom

Examples

Picture	English description	Tags	Benefits over current schema
Link	ATM inside a bank inside a grocery store inside a shopping mall	ATM amenity=atm Role accessto in relation #1 Relation #1 type=access ATM as accessto Bank as acessfrom Bank amenity=bank Role acessfrom in relation #1 Role accessto in relation #2 Relation #2 type=access Bank as accessto Grocery store as accessfrom Grocery store shop=supermarket Role accessfrom in relation #2 Role accessto in relation #3 Relation #3 type=access Grocery store as accessto Shopping mall as accessfrom Shopping mall shop=mall Role accessfrom in relation #3	No need to specify opening_hours=* on all 4 objects No need to indoor-map for correct routing
	Post drop box accessible when the enclosing post office is closed	Mailbox amenity=post_box opening_hours=24/7 Post office amenity=post_office opening_hours=* No additional relations, or type=access access=always ATM as accessto Post office as accessfrom	The mailbox can be a node within an area for the post office building. Geometry-based access checking would fail without mapping the post office indoor area separately, or displacing the mailbox node.
Link	Customer-only parking	Parking amenity=parking access=customer Role accessto in relation Relation type=access Parking as accessto Shop as accessfrom Shop shop=* Role accessfrom in relation	The mentioned "customer" is obvious--routing and searching can act appropriately, depending on user intent.
	Shops behind security checkpoint in airport	Shop shop=* Role accessto in relation Relation type=access Shop as accessto Security checkpoint as accessfrom Security checkpoint barrier=checkpoint Role accessfrom in relation	No need for indoor mapping, or re-appropriating access=permit.

Prior art

Relations/Proposed/Provides feature

Undocumented, seems to cover the same cases, but specifically for roads

Misspelling

Undocumented, conflicting name, seems to be a "group" relation, to apply access tags to all members

Tag:amenity=cafe#Cafes inside other shops / amenities

Rationale

All of the examples above can be expressed in the current schema, but only in a limited way. Currently, in order to communicate the relationship in the first example, all 4 objects would have to be indoor-mapped with corridors and appropriate entrances, no overlapping areas, and opening_hours=* on all 4. Without successively shorter opening_hours=*, a search engine wishing to filter out currently inaccessible locations would have to include a full routing engine to make that determination. Alternatively, a search engine could check for enclosed geometry, but this requires a geometry processing step that is out-of-scope for a search engine, and would fail for the postbox example. This proposal communicates complicated object relationships in a straightforward way and without needing to do complex mapping.