An organicmaps user has reported that navigating to Cork Airport takes him to an inaccessible entrance. I reproduced the problem on OSRM on desktop. The airport is way 275974967. No roads intersect with the aerodrome area, so I guess the routing algorithm just brings you to the closest point on a public road. But this point is a few kilometers away from the actual entrance!
The airport has just one valid entrance for the public. Is there some way to mark one node on the aerodrome way as the entrance, or the point to route to?
Thanks guys. It’s a particularly bad problem in this case as the point it routes to is so far from the entrance a driver might not even see road signs for the terminal. The problem is present on Organic Maps, GraphHopper, OSRM & Valhalla.
What are the options for a workaround? For a start I could make sure the possible destinations at the airport have “Cork Airport” in the description. I’ve already made the terminal “Cork Airport Terminal”. I could add “Cork Airport short-term-parking”, “Cork Airport car hire return” etc. That might attract some more users who search for “Cork Airport” and stop them selecting the aerodrome, which will route them wrongly.
A more radical option is to remove the name “Cork Airport” from the aerodrome and just leave it on the terminal and car parks. But that doesn’t seem right either.
Routing engines such as GraphHopper, OSRM, and Valhalla are behaving correctly. Their role is to take raw coordinate pairs as input and show how to get there quite literally. They lack context about what determined the coordinates (usually a search result from an independent geocoder) and lack any data about points of interest.
A geocoder such as Nominatim or Pelias can help by providing likely access points as part of each search result that can then serve as better input to a router. This is a common solution among proprietary search APIs.
End-user applications such as Organic Maps and OsmAnd are in a much better position to orchestrate a solution to this issue. An application can present the user with options to refine their search to a specific terminal or departure door on the airport grounds.
A workaround that contradicts the on-the-ground rule probably won’t last very long in OSM. I think what you’ve done so far is just about the best we can do while we wait for a solution on the software side. At least users will see more than one result for “Cork Airport” in the same vicinity, encouraging them to pause for a moment and consider the more precise results.
From the Github page that Mateusz linked I saw that there is a tag routing:entrance=main which should do what we want. I added this to a point on the aerodrome way near the actual entrance. It does not seem to be widely used, but maybe in the future routing applications will use it.
From the suggestions in Minh’s comment and whitepaper, I’ve created or renamed the terminal, car parks, car hire return, set-down area with “Cork Airport” in the title, to encourage users to pick a more specific destination when they search for “Cork Airport”.
routing:entrance=* appears many times in the database, but it’s almost all from one prolific mapper in one city. (Last year they unilaterally edited the wiki to limit entrance=* to just physical passageways, which is at odds with how that key has tended to be used in the database. After all, deemphasizing doorways was one of the reasons why building=entrance was deprecated in favor of entrance=*.)
That said, entrance=* needs to be objectively verifiable somehow, whether as a physical passageway or via a sign or commonly used name. routing:entrance=* might be a reasonable choice if you think of that key as merely a temporary workaround and assume that every instance can be bulk-removed once there’s better software support for navigable points. I just happen to expect that this key is unlikely to be supported at all in the meantime.
In this case, it probably hasn’t helped that someone reduced the airport area to exclude half the terminal, hangar, fire station, car parks, etc., thereby moving the centre of gravity of the airport away from the bulk of human activity. Excluding the business park is probably fair game.
I would suggest keeping the routing:entrance tag active until there is a better way to do this, because we use it extensively and a lot of people were happy to be able to use such tag to distingish between a physical entrance and a routing entrance that should be used for routing access (as an origin or destination). Relations have been suggested but they are complicated to create and most osm contributors would not use it. A simple, clean and short routing:entrance tag does the job wonderfully and is easy to implement/analyse in any software. I can change the description to explain that this should be used for routing and to select the main entrance in a building/compound with multiple main entrances. The minimum would have been to ask me for my input, isn’t it? If you guys decide to remove it from the wiki altogether, at least do not suggest to bulk remove it from osm, because it would break many of the analysis/simulation modelling we do with the transit agencies and ministry of transportation here in Quebec. This would have serious implications.
If I’m not mistaken, the revert didn’t eliminate the routing:entrance=* documentation, just the passage in the entrance=* documentation. It seemed to suggest that entrance=* could only be used if there’s a passage through a barrier of some sort. But plenty of entrances don’t interrupt a barrier – and yet aren’t abstract routing access points either.
For example, most of the named entrances to Acadia National Park in Maine technically aren’t tied to a particular object, but we can conveniently associate them with strategically placed swing gates. These gates, which are normally open, don’t have any fence around them, because they only serve to keep cars out at certain times. (It isn’t possible to place them precisely on the road and along the park boundary at the same time, so I’ve resorted to a site relation. Otherwise, a simple entrance=* node would’ve been sufficient.)
I think these entrances are very different than the ones that you’ve focused on mapping, like this park entrance that happens to have a sign, unlike the park’s other entrances; this tennis court gate, which somehow differs from the other gate a few steps away; this playground access, which is the only possible way in; or this beach access that seemingly exists to route motorists to the parking lot instead of the more direct service road on the other end. These all seem like acts of curation, which probably do deserve a tag distinct from the more objective ones that are normally tagged as entrance=*. The point that @aSalmon added is probably closer to the purpose of routing:entrance=*, so there’s no problem.
How about we restore a mention of routing:entrance=* to the page, but with a more accurate explanation of when to use it? I wouldn’t worry about a sudden mass deletion. That would require a discussion beforehand, and we’d have to be confident that it wouldn’t cause disruption to existing data consumers.
For now, I’m pretty sure you’re the only consumer of this key. I don’t think router:entrance=* offers navigation software an easier path to solving the access point problem than heuristics such as “the entrance door(s) of the terminal building(s) of the airport”. Still, these nodes also aren’t doing any harm and, as you point out, they may be of interest for analysis purposes.
I absolutely support everything you said. Thanks! I will update the routing:entrance link in the entrance page accordingly. We add these as the exact POI location for all kind of POI areas. People were using centroids before and it caused incorrect routing in our simulations for medium/large areas. We now use it also with small area for consistency. Thanks!
So, Node: 3132249521 | OpenStreetMap had routing:entrance=yes added 7 days ago. The three native journey planners are still pointing to the wrong place. While those services often take some time to adjust, I’m wondering if routing:entrance=yes has been added correctly and if the chosen location (goods loading bay) is appropriate. It is currently a node on both the airport and airport terminal. However, this seems incorrect, as the terminal is well within the airport site.
I agree this should be sorted out, but the solution should also allow for more complex situations, where several entrances are available to the public, as often occurs with airports (several terminals) or bigger train stations (and many more features, also shopping malls, …).