Index entrances from interior features or site relations

[1ec5]

#3807 exposed entrance=* and routing:entrance=* coordinates in a search result’s entrance properties. The entrance=* support will help routers avoid sending users to the back of large buildings, such as the loading docks of supermarkets. Unfortunately, a router wouldn’t be able to take advantage of entrance in many other cases where users would expect more precise routing. For example:

• At a commercial airport such as SFO or SJC, the ideal entry points for routers would be somewhere inside or outside the area, depending on the mode of transportation, but not directly on its edge. Even if we curate a set of passenger-friendly routing:entrance=* points along the airport perimeter, those points will still mislead the driver or cut short the route before important decision points, depending on which direction they’re coming from.
• At a zoo, amusement park, or stadium, such as Levi’s Stadium, the entrance=* nodes correspond to gates, but before the user can get there, they likely have to choose a parking lot corresponding to their ticket type. The way and its vertices don’t contain enough information to make these inferences.

A couple potential approaches could help to mitigate this problem:

• Index features that lie within the main feature. For example, for an airport, the most important features are the terminal doors – the entrance=main nodes of aeroway=terminal areas that intersect the airport perimeter.
• Consider any site relation the feature is a part of, then look for members with certain roles like entrance, terminal, and parking.¹

A while back, I put together a list of possible heuristics that a geocoder could consider in the absence of explicit site relations (handwaving about complexity).

Footnotes

1. Relations of type=site won't be found by Nominatim #463 requests returning site relations as features in their own right, which would make this heuristic that much more attractive. ↩

[1ec5]

I get that routing:entrance=* was straightforward to support by analogy to entrance=*, but note that it’s extremely rare outside of one city in Canada (click Execute, then Map View):

By comparison, entrance members on site relations are almost as common and much more globally distributed:

Of course, entrance=* nodes on aeroway=terminal areas within aeroway=aerodrome areas are common everywhere:

[emlove]

I will say that aerodromes was a use case I originally had in mind with this work, but decided to leave out of scope. I think those use cases would be better to handle in the routing software itself. So for example, if the routing software sees you're navigating to an aerodrome, it loads related terminals, parking lots, etc. and offers them as more specific destinations, each with their own tagged entrances.

[lonvia]

I'd lean towards supporting members with 'entrance' roles for relations. Entrance nodes on containing ways might be ambiguous because they can be inside the feature (maybe looking at role 'inner'/'outer' would work, too). Looking for entrances inside a feature is not technically feasible and would imho lead to too many false positives.

Current entrance members are mainly on 'site' relations, which is an entire different beast to support first. So, low prio right now.

[1ec5]

I will say that aerodromes was a use case I originally had in mind with this work, but decided to leave out of scope. I think those use cases would be better to handle in the routing software itself. So for example, if the routing software sees you're navigating to an aerodrome, it loads related terminals, parking lots, etc. and offers them as more specific destinations, each with their own tagged entrances.

I totally understand the need to keep the scope limited. What you’ve implemented is a great start! To be clear, a router calculates a route between two or more coordinate pairs without any context about what these coordinates represent. A navigation client would likely be responsible for orchestrating both a geocoder and a router. As it is, an application would now be able to present the user with a list of entrances to select from, as in openstreetmap/openstreetmap-website#6369. The suggestion here is to add more sophisticated heuristics for discovering and returning more entrances. I understand that this might be more challenging. However, it would be even more challenging for a low-level router. It would start to resemble a geocoder, and maybe we’d have to revisit the architectural distinction between the two types of services. 😬

Entrance nodes on containing ways might be ambiguous because they can be inside the feature (maybe looking at role 'inner'/'outer' would work, too).

Ah, right, iD strongly encourages mappers to add entrance nodes to the doors to courtyards. If Nominatim filters on or exposes access=private, that could mitigate the problem somewhat.

Looking for entrances inside a feature is not technically feasible and would imho lead to too many false positives.

Agreed. In the airport case, this would only work hierarchically: first you have to identify a reasonable building before going down a level to entrances. (But even routing toward the building would probably be an improvement in most cases.)

[lonvia]

Agreed. In the airport case, this would only work hierarchically: first you have to identify a reasonable building before going down a level to entrances. (But even routing toward the building would probably be an improvement in most cases.)

That's an even bigger can of worms called "indexing complex objects". It is on the roadmap but needs some very long and quiet winter nights.

[andrewharvey]

For example this hospital is mapped as the whole campus containing multiple buildings, but when you search for the hospital you might expect the list of entrances to include:

1. The emergency=emergency_ward_entrance at node/5052914931.
2. The main entrances of each of the buildings within the site:
   a. Acute Services Building's main entry
   b. Clinical Services Building's main entry
3. The car park entrances, eg. node/4963495389

Though it's hard to know order to list the buildings.

I can see this getting out of hand on a campus with a lot of buildings like a university. If the campus has clear entry points or entry gates, they would be tagged as entrance nodes on the campus outline which is supported, so I think you'd only want to consider the building entrances if there are no campus outline entrance nodes.

[wolfbert]

An additional use case are covered entrances to buildings.

I.e. the ground floor of the building (e.g. shop area) is smaller than the floors above (e.g. apartments), creating covered entrances. In 2D mapping, the entrance isn't part of the building outline (as seen from above), but within (in 3D mapping, the entrance is on the outline of the ground floor).

Seen together with addr:unit support (#587 ), this makes tagging and search for entrances to apartment buildings and malls rather tricky. Note that the problem cannot be solved by moving the entrance to the 2D building outline as this would either lead to incorrect layout of paths or an incorrect final routing instruction (wrong turn).

[kaligrafy]

Yes, see this example: the main entrance with the restaurant and faculty POIs near it is inside the building polygon, not on its countour: A lot of buildings have a roof with layer 1 on top of the main entrance and we usually map these inside the building polygon.

[wolfbert]

I'm trying to sum up from a mappers perspective (sorry if I'm restating the obvious, I've read the research in the first post).

Spatially, a (logical) routing target can be outside, on the boundary or inside an area. Centroid is default. Outside could be a member in a site relation, on is currently covered with entrance and routing:entrance (should include multipolygon outlines), and inside is discussed here.

routing:entrance should not be limited to outlines (and entrances, therefore maybe better named "routing:target"), but work on nodes in all these scenarios. Essentially it says, in the absence of more specific information, use this).

The routing target could be determined like:

1. specific location selected (e.g. visitor parking lot)
2. routing:entrance (non-router-obvious main access to premise)
3. tagged entrances (main, yes, or other)
4. centroid

As usual, the devil is in the details (what if the selected car park has a routing:target, as it probably will). But first steps have been made.

Nominatim support would go a long way to establish tagging and motivate mappers (and navigation software developers), but getting tagging documentation and recommendations to mappers is key (and needs to be discussed not just here, may requires a proposal, not so much for new tags but to clarify application).

[lonvia]

This really is a discussion that should go into the OSM community forum because it is mostly a tagging discussion right now. There is a sub-topic there to get a better definition what site relations are, when they should be used and what they should include, that needs to be sorted first.