juftin / camply

camply, the campsite finder ⛺️ - a tool to find campsites at sold out campgrounds through sites like recreation.gov
https://juftin.com/camply/
MIT License
464 stars 89 forks source link

campsite geolocation #300

Closed zdwolfe closed 11 months ago

zdwolfe commented 11 months ago

Is your feature request related to a problem? Please describe.

As an admin of an application in the local travel space, when my application receives a webhook notification I want to access the geo location of a campsite (falling back to the campsite's campground location, facility location, or null) so I can calculate travel distance to the site.

Describe the solution you'd like

The webhook response, and/or a general feature, should have alocation blob with lat/lon.

{
    "campsites":  [{
            "campsite_id": 76540,
            "facility_name": "Silver Falls Group Site",
            "facility_id": 233998,
            "...": "...",
            "location": {
                "latitude": -100.6421897,
                "longitude": 39.2557981
            }
    }]
}

Describe alternatives you've considered Using a geocoding API such as google maps or bing maps, querying the facility_name and recreation_area is close, but often wrong, expensive, and requires lots of network IO. Additionally, it looks like the information is available from many providers already.

Additional context Add any other context or screenshots about the feature request here.

juftin commented 11 months ago

We could expose this via the core AvailableCampsite data object that gets passed around - ultimately to the webhook notification provider. AFAIK we currently get Longitude/Latitude from UseDirect and RecreationDotGov - there's a lot of un-documented response models for GoingToCamp so it's probably available to grab somewhere.

This type of information probably isn't useful to our other notification providers so we'll want to make sure to exclude it from their composed responses.

jeff-breece commented 11 months ago

What about a Google Maps API integration that is passed the name of the location (for state and national parks/forests) and a parsing of the return for coordinates?

zdwolfe commented 11 months ago

What about a Google Maps API integration that is passed the name of the location (for state and national parks/forests) and a parsing of the return for coordinates?

I thought of GMaps idea, and tried a few common geocoding providers. Of the campsites I tested on, several of them were either not found or quite wrong (eg: GMaps would respond with a park rather than the campsite, which can be 30m away or more). Here's the sample code

I think if the data is available directly from the provider, that data should be returned. If it isn't available, then by returning a null or sentinel "unknown" to the webhook, the webhook can opt to use a geocoding tool.

juftin commented 11 months ago

This is a pretty easy one. I'd like to source all the data we need from the providers themselves. They should all supply it somewhere.

It was easy for RecDotGov and UseDirect. We get latitude/longitude per campsite/campground. How do we feel about something like this (location would be null if the provider doesn't give us that info).

{
  "campsites": [
    {
      "campsite_id": 46203,
      "booking_date": "2023-10-19T00:00:00",
      "booking_end_date": "2023-10-20T00:00:00",
      "booking_nights": 1,
      "campsite_site_name": "Campsite #08",
      "campsite_loop_name": null,
      "campsite_type": "Camping",
      "campsite_occupancy": [
        0,
        1
      ],
      "campsite_use_type": "Campsite",
      "availability_status": "Available",
      "recreation_area": "Sunset SB",
      "recreation_area_id": 726,
      "facility_name": "South Camp (sites 1-37)",
      "facility_id": 737,
      "booking_url": "https://www.reservecalifornia.com/Web/Default.aspx#!park/726/737",
      "location": {
        "latitude": 36.8848514805999,
        "longitude": -121.827403446999
      },
      "permitted_equipment": null,
      "campsite_attributes": null
    }
  ],
  "timestamp": "2023-09-23T06:28:00.766444+00:00"
}
zdwolfe commented 11 months ago

Looks great! I agree the location blob being null if the provider doesn't have it will be clear enough.

juftin commented 11 months ago

:tada: This issue has been resolved in version 0.31.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: