User:Minh Nguyen/Navigating between entrances

This is a proposal for how search engines, routing engines, and navigation applications could interpret established OpenStreetMap tagging to improve the user experience navigating from and to entrances within large sites that have multiple entrances. It does not propose a novel tagging scheme.

Problem

A typical navigation application coordinates a search engine and a routing engine. Once the user selects a point of interest, the application calculates a route between the current location and the destination. The routing engine receives the two locations as point features, usually representing the centroid of a building, and snaps either coordinate pair to the nearest point on the road network. (Depending on the routing engine, private roads near the origin and destination may or may not be considered during the snapping process.)

With this naïve approach, the snapped origin and destination may not be optimal for finding a building's entrance:

• If a rectangular building is surrounded on all sides by streets, the snapped coordinate is essentially a tossup.
• A house may have a generous setback from the street and a street may pass closer to the back door, even if the house is inaccessible from the backstreet.

One workaround is to map the POI as a point and shift it toward the nearest entrance to bias the snapping. However, different use cases may call for different entrances, and the user's intent may not be obvious to the application:

• A customer may want to park in front of a supermarket, but a delivery person might want to take a back road to get to the loading dock.
• An airport's international terminal may be a significant distance from its domestic terminal, to say nothing of its economy parking lot or employee entrance.

While consumer-drivers may be able to resolve an imprecise route on their own, for door-to-door delivery use cases, even small distances between destinations may add up significantly.

Solution

Sophisticated navigation applications, such as Apple Maps and Google Maps, solve this problem by presenting the user with a menu of specific entrances before navigating to a large destination or defaulting to the most appropriate entrance for a given user profile. The OpenStreetMap-powered Mapbox Navigation SDK doesn't feature this menu. However, it is designed to work with the Mapbox Geocoding API, which includes "routable points": for search results from OpenAddresses.io, the routable point is biased toward the street whose name matches the street address. (Here calls this functionality "access points", while TomTom calls it "entry points".)

In OpenStreetMap, established tags already make it possible to enter the data necessary for a menu or defaults similar to the behavior in Google Maps. However, data consumers still need some heuristics to associate the entrances with the parent points of interest. For example:

• Suppose the user selects this search result. Nominatim identifies 131562 131562 as the POI, so it would be pretty simple for a data consumer to run this query to get the main building entrance.
• Suppose the Nominatim result is a landuse area rather than a building, which would tend to be the case for school campuses and airports. This search result identifies 34229193 34229193 as a landuse area, and this query gets all the main entrances to the buildings within that area.
• Suppose the user selects this stadium. The stadium's off-site parking lots are part of the site relation 14507813 14507813. The data consumer can query for the site relation's parking lots to offer to the user as destinations.

An application could perform further heuristics based on the tags on these entrances or the areas that intersect with them. These examples use Overpass queries for demonstration purposes, but it would be more efficient for a search engine to index the entrances as subfeatures of POIs using spatial queries.

Destinations by POI

This list includes the kinds of destinations that might be presented to the user when selecting a POI. Destinations that an application would route to by default are listed in bold. The list excludes destinations within the POIs that the user would search for by name, or indoor features that would use a common building entrance, or fixtures that a user would easily find on foot after reaching a destination by other means. An important criteria for inclusion is that the destination can be labeled unambiguously in as few words as possible.

• Airport
  • Terminal doors
  • Short-term parking lots – amenity=parking maxstay=≤ 1 day fee=yes
  • Long-term parking lots – amenity=parking maxstay=≥ 1 day
  • Cell phone waiting lot – amenity=parking maxstay=≤ 1 hour fee=no plus something to indicate that the vehicle must be attended at all times?
  • Rental car return
  • Employee entrance – amenity=parking access=private
  • General aviation hangar area (fixed-base operators)
• Apartment complex
  • Gated entrances
  • Leasing office – office=apartments
• College or university
  • Visitor parking lot – amenity=parking without access=private or parking:condition=*
  • Visitor center – tourism=information information=office
  • Stadiums – leisure=stadium
• Construction site
  • Construction office – craft=builder or office=construction
• Factory or other industrial building
  • Customer parking lot – amenity=parking access=customers on a site relation
  • Employee parking lot – amenity=parking access=private on a site relation
  • Loading docks – amenity=loading_dock
• Golf club community
  • Clubhouse – amenity=clubhouse
  • Clubhouse parking lot – amenity=parking access=customers on a site relation
  • Resident entrance – barrier=gate access=private leading into the landuse=residential
  • Deliveries entrance – barrier=gate access=delivery
• Hospital
  • Main entrance – entrance=main
  • Emergency entrance – entrance=* emergency=designated or emergency=emergency_ward_entrance
• Park or sports complex
  • Visitor center – tourism=information information=office
  • Largest parking lot – amenity=parking
  • Named trailheads – highway=trailhead name=*
• Parking garage
  • Entrances – amenity=parking_entrance
• Residential subdivision
  • Gated entrances
  • Model home / construction office – building=show_house or office=construction_company
• River
  • Public landings – leisure=slipway without access=private
  • Viewpoints – tourism=viewpoint or role viewpoint in a site relation?
• Self-storage facility
  • Front office – office=*
• School
  • Main entrance – entrance=main
  • Student parking lot – amenity=parking parking:condition=students?
  • Visitor / parent parking lot – amenity=parking access=customers
  • Faculty parking lot – amenity=parking access=private
  • Loading dock – amenity=loading_dock
• Shopping mall
  • Mall entrances – entrance=main
  • Department store entrances – entrance=main on a shop=department_store
  • Parking garages – amenity=parking parking=multi-storey
• Stadium
  • Parking lots – amenity=parking or role parking on a site relation
  • Doors – entrance=*
  • Box office – shop=ticket
• Subway station
  • Parking lot – amenity=parking on a public_transport=stop_area relation
  • Subway entrances – railway=subway_entrance on a public_transport=stop_area relation
• Supermarket
  • Main entrance – entrance=main
  • Pharmacy drive-through window – amenity=pharmacy drive_through=yes
  • Loading dock – amenity=loading_dock
• Zoo
  • Visitor entrance – entrance=main
  • Visitor parking lot – amenity=parking access=customers
  • Employee parking lot – amenity=parking access=private

Labeling destinations

In general, destinations should only be listed if they're named, but some features aren't tagged with a name because the name would be redundant to other tags. In these cases, the application could fall back to a short description of the destination (e.g., "Main Entrance"). In cases where a POI has multiple destinations of the same kind, such as a parking garage with multiple entrances, the application could label each one with the name of a nearby street ("Elm Street Entrance").

External links

• Request for Pelias to return alternative entrance points
• Request for Nominatim to return site relations
• Request for Nominatim to return entrance points
• Request for OsmAnd to route to entrance points
• Request for Organic Maps to route to entrance points