-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter campsites for goingtocamp #288
Comments
🤔 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: camply/camply/providers/going_to_camp/going_to_camp_provider.py Lines 174 to 193 in 383617a
There is a data object, camply/camply/containers/data_containers.py Lines 97 to 98 in 383617a
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: #86 and here: #63 |
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 |
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 😄 I don't believe there's any set of unified filter IDs that work across instances. |
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.
(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,
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.
The text was updated successfully, but these errors were encountered: