Comments (12)
Alright @jonoff / @acaloiaro I've got what I believe is the solution to this problem with #293.
It's important to note that there is a user behavior change here. When you click on the booking link now and click reserve
it'll tell you that you need to select your equipment before reserving. So you then need to go up, select your equipment, and refresh the page. What do you think about this? Does that seem annoying? We could keep the equipmentCategoryId
on the booking URL and it would be right most of the time without needing to re-select your equipment.
Edit: I actually kept the booking URL the same. We're setting equipment ID on it since the user experience is a little better
from camply.
I'm guessing the dataset is different for this rec area, should there be an enum
to describe availability around this line:
from camply.
A potentially unrelated issue, this rec area's equipment (https://reservation.pc.gc.ca/api/equipment) isn't displayed correctly, due to the equipment category at index 1 not 0:
camply/camply/providers/going_to_camp/going_to_camp_provider.py
Lines 472 to 474 in 383617a
from camply.
Thanks for the great information @jonoff, this one looks to be a legit bug. Full disclosure, I didn't originally write the GoingToCamp provider so this will take me a bit of time to dig into and clean up. I'll follow back up once I've had some time to dig in
from camply.
Okay. Following up here. There are two different issues that cause this campsite not to show. As of writing this comment there is only one campsite available @ Banff - Tunnel Mountain Village 2 - and that's spot A18, (AKA Site ID # -2147474345).
When we look at that's site availability, it comes back with 5
{
"-2147474345": [
{
"availability": 5,
"remainingQuota": null
}
]
}
This line of code says it should be 0
to be considered available:
I also see a campsite with a 4
in there that's not available - so maybe 0
and 5
are the enum values that are acceptable? 🤷 I wonder how I could confirm this.
The next issue that this campsite returned - that ultimately prevented it from showing up as available was its minCapacity
. See the campsite API response here:
{
"maxStayIsAggregate": null,
"minCapacity": null,
"maxCapacity": 6,
"mapId": -2147483610
}
And here is where we exclude that:
camply/camply/search/search_going_to_camp.py
Lines 174 to 180 in 383617a
So after allowing the enum values of 0
and 5
- and also allowing for sites where minCapacity
is null
- the issue is resolved and camply finds our one available campsite. I can open up a PR but I'm a bit uncertain if there will be any downstream consequences.
@acaloiaro might have have some more background on whether this was an actual zero capacity site. The sight seems to think it's legit:
And lol, that A18 campsite just got booked as I was finishing up writing this.
Here's the related code for above: https://github.com/juftin/camply/compare/fix/going_to_camp_missing_sites
from camply.
@juftin a big part of my process for figuring out the meaning of certain enums and values in the API was by seeing how the GTC's web interface presents those values.
If we continue down that path, we should assume that availability = 5
and minCapacity = null
are considered available.
I was simply never presented with those values in my testing with specific GTC instnaces. I would consider adding a new constant for true availabilities, e.g. AVAILABLE_AVAILABILITIES = [0, 5]
so we can check for availability_details[0]["availability"] in AVAILABLE_AVAILABILITIES
(or something similar/naming things is hard).
Similar for minCapacity
.
Speculation: I suspect that GTC has an admin interface that lets administrators create all manner of enums, and possibly even the semantics for those enums. E.g. in this case 5
probably has a nice availability name in that admin interface; perhaps something like A_CUSTOMER_WANTS_TO_RESERVE_BUT_HAS_NOT_YET_PAID
. Such a status should be "available", but might be a way to keep things "on hold" when customers call to make reservations. Pure speculation, of course. But I do know through observation that there are many enums that are instance-specific. So either there's an admin interface that allows hosts to control some of the enums (and their semantics), or GTC sets these up on a per-instance basis during customer onboarding.
from camply.
Ah, confirmed. These enums line up with the "Availability Legend"
I was able to find this snippet deep within the sites Javascript for https://reservation.pc.gc.ca/
return (i = t || (t = {}))[i.Available = 0] = "Available",
i[i.Unavailable = 1] = "Unavailable",
i[i.NotOperating = 2] = "NotOperating",
i[i.NonReservable = 3] = "NonReservable",
i[i.Closed = 4] = "Closed",
i[i.Invalid = 5] = "Invalid",
i[i.InvalidBookingCategory = 6] = "InvalidBookingCategory",
i[i.PartiallyAvailable = 7] = "PartiallyAvailable",
i[i.Held = 8] = "Held",
Here's the same info for https://washington.goingtocamp.com/
return (i = t || (t = {}))[i.Available = 0] = "Available",
i[i.Unavailable = 1] = "Unavailable",
i[i.NotOperating = 2] = "NotOperating",
i[i.NonReservable = 3] = "NonReservable",
i[i.Closed = 4] = "Closed",
i[i.Invalid = 5] = "Invalid",
i[i.InvalidBookingCategory = 6] = "InvalidBookingCategory",
i[i.PartiallyAvailable = 7] = "PartiallyAvailable",
i[i.Held = 8] = "Held",
This all seems-ish to line up with those enums we're seeing across providers. It seems like we're currently doing the right thing - what do you think @acaloiaro / @jonoff? Should we be using enum values other than 0?
from camply.
It seems like we shouldn't use anything but 0
according to this code.
From jon's original issue:
The two sites marked "availability":5 are indeed available and lit up green in the web UI
This leaves me with one question. It showed up, but were they actually bookable? It's possible that was a frontend bug, and if the user tried booking, perhaps the backend would have failed, since 5
is supposed to be Invalid
.
I found this comment in the search code and now I remember writing it
# Some rec areas have zero-capacity sites, which should not
# be viable for camping. Skip all zero-capacity sites.
if (
not site_details["minCapacity"]
or not site_details["maxCapacity"]
):
I recall writing that because min/max capacity was coming back as 0
for some "sites", and those should almost certainly be filtered out. At the time, I recall thinking that min/maxCapacity = False
must mean the same thing -- but that may not have been accurate. Hence, this code filters both min/maxCapacity = 0 and False.
I recall that some instances in CA list things like picnic pavilions as "sites" with a capacity of 0
, so I think we should continue skipping those, but perhaps False
deserves further investigation.
from camply.
This leaves me with one question. It showed up, but were they actually bookable? It's possible that was a frontend bug, and if the user tried booking, perhaps the backend would have failed, since 5 is supposed to be Invalid.
While I didn't book the above example sites, I was able to complete booking for a different site.
Here's a current example I randomly found:
Green site showing available via tooltip on site 723
"-2147475829":[{"availability":5,"remainingQuota":null}]
And since no sites are showing up as "0", I'm not sure we reached a conclusion for this part of the issue.
For the other part, this site has the same capacity details (https://reservation.pc.gc.ca/api/resource/details?resourceId=-2147475829):
minCapacity":null,"maxCapacity":6,
Another guess is that minCapacity is optional, and some admins only set max? If so, changing the OR into an AND could work for this line:
not site_details["minCapacity"] or not site_details["maxCapacity"]
I recall that some instances in CA list things like picnic pavilions as "sites" with a capacity of 0, so I think we should continue skipping those, but perhaps False deserves further investigation.
We could verify those types of sites set both max and min capacity to 0 vs. only one of the values (to distinguish 0/false from null).
from camply.
So I think what's actually happening is an equipment mismatch. I realized that the 5
enum represents available sites that don't match the user's equipment selection
So take a look at this booking URL: https://reservation.pc.gc.ca/create-booking/results?mapId=-2147483624&bookingCategoryId=0&equipmentCategoryId=-32768&startDate=2023-09-07&endDate=2023-09-08&getDailyAvailability=false&isReserving=true&partySize=1
We can see that there are "Restricted" sites, but they're bookable. Here's the corresponding API Result:
https://reservation.pc.gc.ca/api/availability/map?mapId=-2147483624&bookingCategoryId=0&equipmentCategoryId=-32768&startDate=2023-09-07&endDate=2023-09-08&getDailyAvailability=false&isReserving=true&partySize=1
It has a number of 5
enum values because we're asking it to filter on equipmentCategoryId=-32768
When we remove that equipmentCategoryId
param entirely from the endpoint, all of our 5
s turn to 0
s:
https://reservation.pc.gc.ca/api/availability/map?mapId=-2147483624&bookingCategoryId=0&startDate=2023-09-07&endDate=2023-09-08&getDailyAvailability=false&isReserving=true&partySize=1
Here's where we apply all those search params:
camply/camply/providers/going_to_camp/going_to_camp_provider.py
Lines 506 to 518 in 383617a
I believe that we should only provide a equipmentCategoryId
when the subEquipmentCategoryId
is also specified. @jonoff in your example above the booking link subEquipmentCategoryId
doesn't match the API subEquipmentCategoryId
- if we remove them entirely from the API response our 5s turn to 0s
from camply.
Good find, "5" does look like it refers to site available but not matching current criteria. I wasn't making sure equipment and sub-equipment IDs were accurate in my API calls and when I originally tried to search I couldn't identify which ID(s) to pass due to #291 (comment), this line may not be the same for each rec-area
and it seems
subEquipmentCategoryId
is not properly supported
from camply.
The equipment category/sub-category code is likely to be some of the shoddiest in the GTC implementation. I had a feeling it wouldn't be correct for 100% of GTC rec areas, but also didn't want to agonize over making it correct for 100% of rec areas at the time of implementation.
Equipment is another thing that can be defined on a rec-area by rec-area basis (or perhaps it's instance-wide i.e. per subdomain). An example of this is that one rec area might list "Travel Trailers up to 25'" as a category, but a different rec area might have "Travel Travelers up to 27'".
I made little effort to dig into the category/sub-category functionality since rec-areas can define their own categories. As a result, I can't say with any confidence what sub-equipment is.
But as @juftin found out, it's clear now that "availability" can be linked to equipment choices.
I'm happy to lend a better hand at some point in mid September. Currently I have a busy holiday schedule in Switzerland and all these mountain bike trails won't ride themselves :)
from camply.
Related Issues (20)
- Provider for site specific backcountry permits on nps.gov
- GoingToCamp midnrreservations.com ConnectionError HOT 3
- --start-date argument not getting respected HOT 5
- 403 Client Error - ReserveCalifornia blocked on cloud hosting providers HOT 13
- "No campgrounds found to search" when using valid campground # HOT 4
- ReserveAmerica.com HOT 3
- Provider Request: add support for `freecampsites.net` HOT 1
- SearchAlabamaStateParks returns 404 HOT 1
- Is there a way to track event ticket? HOT 2
- GoingToCamp fails for WA HOT 4
- ReserveCalifornia cancellations are locked HOT 1
- Allow searching across multiple providers by allowing multiple YAML files in same query (Enhancement Suggestion)
- ReserveCalifornia does not detect available campsites HOT 3
- Sonoma County, CA Regional Parks Addition HOT 2
- RecreatDotGov campsites search returns false positives HOT 2
- Scanning Yellowstone crashes with "AttributeError: 'list' object has no attribute 'items' HOT 5
- Yellowstone Availability before start date? HOT 1
- Pushover Out of Credits HOT 4
- Start and End Date Windows do not behave as expected HOT 1
- Continuous Search not working with YAML file HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from camply.