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.

Rationale

This proposal was inspired by wanting to map an ATM, that's inside a bank, that's inside a supermarket, that's inside a shopping mall. A search engine might want to display the opening_hours=* or the wheelchair=* accessibility of the ATM. With current OpenStreetMap tags, to express the relationship between the objects, they could be mapped two ways. First, all 4 objects could be indoor-mapped with corridors and appropriate entrances. This would theoretically allow a search engine to see that the route to the ATM is blocked by the "outer" features, but routing is outside the scope of a search engine, and indoor mapping is not trivial. Second, successively shorter opening_hours=* and wheelchair=* could be mapped on all four features, but this adds maintenance burden, and is only verifiable by secondary information. A third possible solution would be to map each "outer" object as overlapping areas, so a search engine could check for enclosed geometry, but this is again not trivial to map, it requires a geometry processing step that is out-of-scope for a search engine, and it would fail for cases like the postbox example below. This proposal communicates complicated object relationships in a straightforward way and without needing to do complex mapping.

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

type=site Apparently used to map e.g. parking lots at large venues like stadiums.