Closed danrademacher closed 6 years ago
I see others in this same vein: Playgrounds, Tennis, Covered Picnic Tables, ...
https://www.caliparks.org/activity/covered_picnic_tables https://www.caliparks.org/activity/playground https://www.caliparks.org/activity/tennis
I've traced back to the activities table, and see that some activities (Basketball, Ball Fields, the 3 others predicted above, etc.) were not coded consistently with other activities, e.g. "Playground" is not "playground" and "covered picnic tables" is not "Covered picnic tables"
28613 | {Basketball,Playground}
10147 | {biking,fishing,hiking,swimming,camping,boating,dogs,"Ball fields",Basketball,"Covered picnic tables",Playground,Tennis}
10942 | {biking,hiking,wildlifewatching,dogs,"Ball fields",Basketball,Playground,Tennis}
5954 | {biking,hiking,dogs,"Ball fields",Basketball}
3837 | {biking,hiking,dogs,"Ball fields",Basketball,Playground,Tennis}
11189 | {biking,hiking,dogs,Basketball,Playground,Tennis}
5429 | {dogs,"Ball fields",Basketball,Playground,Tennis}
30221 | {biking,hiking,historicalsite,dogs,"Ball fields",Basketball,Playground,Tennis}
31530 | {biking,fishing,hiking,kayakingcanoeing,swimming,wildlifewatching,camping,boating,dogs,"Ball fields",Basketball,Tennis}
30220 | {Basketball,Playground}
The nature of the query is all-lowercase terms: fishing, hiking, swimming. As such, the terms not corrected would match 0 records: Basketball, Playground, Tennis, Ball fields, Covered picnic tables.
I will see about further confirming that this is the root cause, then about either standardizing the terms used in the activities table, and/or adjusting the search to become case-insensitive.
Confirmed this to be the case for only the following activity entries:
Confirmed that in all cases, the diff is the first letter, and only the first letter being uppercase. Confirmed that a string replacement could be inserted into getParksForActivity()
to patch around this: when tennis or basketball is requested, converting to "Basketball" or "Tennis" for the query.
aff8778 -- fix for the issue as noted
Added a switch
to rewrite the first letter as uppercase, and confirmed that this fixes the issue as noted.
2e1c6e1 -- getActivitiesList() now gives consistent capitalization
I don't see that this query is exposed nor used anyplace at all, but if it were to serve as a data endpoint, it would benefit from the consistency of returning activity names in consistent capitalization.
65c3f53 -- activity caps fix refactor
Refactored the caps-fix into a function correctActivityName()
and have this applied equally to both listParksWithActivity()
and getParksForActivity()
I know these worked at one point, but yeesh who knows how long ago that was...
I noticed that these two are empty: https://www.caliparks.org/activity/ball_fields https://www.caliparks.org/activity/basketball
I'm certain they were not always empty, but not sure when they broke.
I vaguely recall that we might have filtered out parks without Instagram photos. If so, then #665 flip to Flickr would be a cause and we should remove that filter altogether, and just show all parks regardless of photo count (since Flickr is such a smaller sample).
Or did this happen when we updated CPAD in the fall and no one noticed? Also possible, but hard to believe it would totally zero out these two categories, which would imply every superunit id in them changed.
Hmm, but maybe there's some other cause.
The queries appear to be here: https://github.com/GreenInfo-Network/caliparks.org/blob/250a781e5ed98a3e1f39e71394f3d1c79a6fcb06/app/server/services/queries/activities.js#L39
And I don't see any photo related limit.