Default coordinates for driving directions?

If I search for “Golden Gate Canyon State Park, Gilpin County, Colorado, United States”, the map centers at the (presumably) geographic center of the park. If I then ask for driving directions to the park, it routes via some VERY unimproved roads, coming in from the undeveloped top end of the park, trying to get me as close as possible to that geographic center. Specifically, it routes nowhere near any primary park feature.

Were I a visiting foreigner, this would’ve been an incredibly frustrating experience. But since I’m from the area, I knew enough to improvise.

As a second test, I just tried getting directions to Arches National Park, Grand County, Utah, United States. The problem isn’t as bad in that case because the best way to the geographic center of the park is through the main entrance. However, the directions abruptly end along a road, at the closest point to the geographic center. As with the prior case, I’d expect a traveler searching for Arches would expect directions to the park to be to the visitor center.

One could argue that when someone asks for driving directions to a large geographic area, she usually won’t want the geographic center, but instead some feature: an “entrance”, “visitor center”, “main gate”, etc.

Does OSM offer some kind of a “driving target feature” tag that, in the case for Golden Gate Canyon State Park, could be tied to the park visitor center? If not, I’d expect it to be a significant change; what sorts of problems would be introduced?

I should point out that maps.google.com makes the same navigational choice. However, a search for the park pulls up a list of suggested targets (areas & features), with “visitor center” being near the top. So, an uninformed user gets steered to the correct choice.

This is partly a matter for the applications using the data.

I tried searching for “Parque Nacional Sierra Nevada” in two apps on my phone. Organic Maps shows the visitor centre as the second option (screenshot), and OsmAnd shows the visitor centre first, before the centre of the park.

Routing to large areas is tricky and maybe there are improvements that can be made to the data, but it’s not just about the data.

1 Like

Ref Specify an entrance to an airport
Better routing to the Airport destinations · Issue #6096 · organicmaps/organicmaps · GitHub
information=office or =ranger_station would be a specific solution for =national_park etc. information=visitor_centre is fewer, not widely implemented, and not discussed much. In general, =parking would be one of the solutions for all features for driving.
Both cases mentioned are only building= , requiring interpretation of name=

  1. Way: ‪Golden Gate Canyon State Park Visitor Center‬ (‪572742705‬) | OpenStreetMap : Does have =parking next to it
  2. Way: ‪Centro de Visitantes Parque Nacional de Sierra Nevada‬ (‪328259487‬) | OpenStreetMap : No name:en= for English keywords, meaning this actually relies on being named after the =national_park , or multilingual support would be needed

Just for info, openstreetmap.org is certainly not intended as a consumer mapping site for driving directions. It’s essentially the “project site” for contributors and a demonstration of the completeness (or otherwise) of the map. The routing capability is provided to help debug connectivity issues and as a proof of concept, but I don’t think anyone is claiming you should use it for day-to-day routing.

Rather, the idea is that you would use one of the many third-party apps/sites that build on OSM data. OSM data has a commanding presence in walking and cycling directions, but not so much in driving, largely because good driving directions rely on real-time congestion/speed data which isn’t something OSM collects.

On the specific point of routing to an entrance node, these are the relevant technical discussions:

5 Likes

The “place” backend systems that power e.g. Google Maps, Apple Maps, Uber, Lyft, etc. have two different concepts that help solve this problem:

  1. Sub Places are separate places that exist within a parent place. A departures area at an airport, a visitor center at a national park, or an individual store inside a mall are all examples.

    If someone wants to visit a store inside a shopping mall the search software could actually direct the nav software to go to the entrance of the mall that contains the store. Or if someone is navigating to the airport, the software could ask which part of the airport they want to get routed to.

  2. A place might have a navigation point that is stored alongside the display point or label point. The nav point is what is used when someone wants to navigate to the place in question. A state park’s primary visitor center entrance would be an example of this.

    When a user searches for “example state park”, a basic implementation will navigate you to the centroid of the state park boundary, but if the nav software knows to look for a navigation point, it could navigate to that point instead.

OSM can support both of these, but it takes quite a bit of work in the software that uses the OSM data to take advantage of it. (Edited to add: and Richard has linked to examples of OSM data consumers trying to work through this)

3 Likes

Thanks much, folks. Both Magic Earth & Organic Maps show the visitor center near the top (#3 & #2 respectively). My problem was that I was pre-planning our trip using openstreetmap.org from my desktop. If I had used a navigation app instead as @Richard suggests, I could’ve saved us all some churn.

Anyway, thanks for your time! :slight_smile:

1 Like