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
468 stars 90 forks source link

Filter campsites for goingtocamp #288

Open rpdids opened 1 year ago

rpdids commented 1 year ago

Is your feature request related to a problem? Please describe. On top of the basic search parameters (campsite, date, equipment) goingtocamp uses filters to help users narrow down results to exactly what they're looking for. I would go so far as to say that they rely on these filters to allow campers to find the sites that they need. At the moment, camply doesn't seem to support passing filter values, which can result in lots of results returned that don't actually fit the camper's needs. The most useful I can think of is the site service type (Basic/None, Electric, Water, etc) and electrical service type (15amp, 30amp, 50amp).

The solution might be tricky, as it seems like the various goingtocamp rec areas are unique.

Describe the solution you'd like To me, if we could query the rec area to get the list of filters, then use that as part of the campsite search, that would be the ideal solution.

camply filters --provider goingtocamp --rec-area 15
CAMPLY   camply, the campsite finder ⛺️
Using Camply Provider: "GoingToCamp"
Service Type (#-00001)
  No Preference
  Basic
  Electric
  Electric/Water
  Full
Electrical Service (#-00002)
  15 Amps
  20 Amps
  ...
Site Privacy (#-00003)
  No Preference
  Private
  ...
...

(example filters are from the Manitoba goingtocamp since I'm most familiar with those)

Then, when someone wants to search a campsite, they would pass the filter argument as a pair,

camply campsites --provider goingtocamp --rec-area 15 --campground -2147483635 --start-date 2023-08-25 --end-date 2023-08-27 --filter -00001 Electric

Describe alternatives you've considered

Additional context Full disclosure, haven't investigated if it's even a possibility to ge the filter value's programatically. If not then this would be a bust since it would require camply to store too much hardcoded info for every provider that could change anytime. I will do some investigating.

juftin commented 1 year ago

🤔 I'm wondering if we can make this more general to all providers - I don't believe that we are passing through this type of data as campsite attributes, but I think we may be able to.

See here where we grab some extra metadata about the campsite: https://github.com/juftin/camply/blob/383617aab2591c56f8ae5f3a558a187de29d4a20/camply/providers/going_to_camp/going_to_camp_provider.py#L174-L193

There is a data object, AvailableCampsite, that allows for the capturing of extra metadata: https://github.com/juftin/camply/blob/383617aab2591c56f8ae5f3a558a187de29d4a20/camply/containers/data_containers.py#L97-L98

We're not currently doing anything with this data yet, but we do capture it in a couple different providers. There is an existing issue for it here: https://github.com/juftin/camply/issues/86 and here: https://github.com/juftin/camply/discussions/63

rpdids commented 1 year ago

Yeah thinking a bit harder about it, no reason why it shouldn't be a feature for all providers. Will wind up being a bigger chunk of work obviously, but filters are so crucial when trying to find the right campsite and I think would make the tool that much more useful for users. I've been pretty busy with camping myself lately, but I'm hoping to spend some evenings peeking around

acaloiaro commented 1 year ago

I think this is a great request.

My best recollection of why I didn't implement filters originally is that they are instance-specific, e.g. Washington State Parks may have a filter called "has water" and BC Parks might have a filter called "Has water and electric", and there wasn't a clear way to turn a user filter/query of "wants water" into "has water" for Washing State Parks and "has water and electric" for BC Parks.

Of course, this is only from my memory, and the example I give above is perhaps not the best. But the point is, I think it may be a hard problem. Though perhaps not for a greater mind @juftin :smile:

I don't believe there's any set of unified filter IDs that work across instances.