Better geocoding for large parks

graue commented 2 years ago

Large parks seem to geocode to the centroid of the park, not to a reasonable guess of a park entrance that you may want. This leads to bad directions.

For example, right now, if I geocode Wildcat Canyon Regional Park via BikeHopper's Photon instance, here's the relevant result:

{
    "type" : "Feature",
    "properties" : {
      "osm_value" : "protected_area",
      "osm_type" : "R",
      "type" : "locality",
      "city" : "Richmond",
      "countrycode" : "US",
      "street" : "McBryde Ave",
      "country" : "United States",
      "osm_id" : 8421626,
      "state" : "CA",
      "housenumber" : "5755",
      "postcode" : "94806",
      "extent" : [
          -122.3244358,
          37.960035,
          -122.261997,
          37.9187401
      ],
      "name" : "Wildcat Canyon Regional Park",
      "osm_key" : "boundary"
    },
    "geometry" : {
      "coordinates" : [
          -122.288175308693,
          37.9393072
      ],
      "type" : "Point"
    }
}

The point in geometry.coordinates is not the entrance to the park, but apparently the centroid of the region or something. Here are walking directions from what GMaps geocodes "Wildcat Canyon Regional Park" to (essentially the park's main entrance) to what we geocode it to:

I tried some other big parks: Presidio of San Francisco, John McLaren Park, San Pedro Valley County Park, San Bruno Mountain State Park, Vargas Plateau, Garin Regional Park, Golden Gate Park. In all cases it seems to be routing to the centroid. This doesn't always fail to generate useful routes as badly as it does in the case of Wildcat Canyon, but it's basically never what you would want.

For me, biking to a hike is a major use case of BikeHopper, so I'd like to think of a way to improve this, which might include any or all of:

Adding relevant tags into OSM (e.g. "trailhead" point features, which don't seem to exist at several Bay Area park trailheads that I checked right now)
Forking and changing how Photon works
Adding new UI: suppose after you pick "San Bruno Mountain State Park," we see that several trailheads and parking lots are associated with that park and ask you: do you want the Crocker Gate trailhead, do you want the main parking lot, etc?

graue commented 1 year ago

This problem also applies to long ways. Case in point: user report of bad routing to this hiking trail, because it's routing to the middle of the trail, and trying to bike the entire way.

graue commented 10 months ago

I've been trying to figure out a way to, given a park (for example https://www.openstreetmap.org/relation/13070397), find a list of its entrances (entrance=*) and/or trailheads (highway=trailhead), and I don't see any way to do this using Nominatim. Nominatim search docs say that:

When bounded=1 is given and the viewbox is small enough, then an amenity-only search is allowed. Give the special keyword for the amenity in square brackets, e.g. [pub] and a selection of objects of this type is returned. There is no guarantee that the result returns all objects in the area.

But trailheads and entrances do not fit the amenity=* pattern

And even for things that do, like amenity=drinking_water and amenity=bicycle_parking, I'm not getting results even though I can see such amenities mapped inside San Bruno Mountain State Park

bikehopper / bikehopper-ui

Better geocoding for large parks #156