Pictures from parent area get shown in child

[CocoisBuggy]

Steps to Reproduce

Go to https://openbeta.io/crag/09d17d69-188c-5bff-9fa7-2a21be8d25c8 you will see

These two images are tagged to the parent https://openbeta.io/crag/4ed6c976-ee02-564a-801e-20ccc10e6e26 and should probably not be assumed to all children.

Expected Behavior

If tagged to an area, it should only be shown when browsing that area rather than being drilled through the hierarchy

[vnugent]

I think it's useful to show crag level photos at the climb level in case multiple climbs are visible. Since the 2 photos in questions are cropped very tight, don't you think it's more appropriate to tag the problem the climber is on instead?

Maybe we can label crag level photos as such to reduce confusion. I'm not sure how that would look.

[CocoisBuggy]

When two climbs are visible, they can both be tagged to the climb (A photo already supports multiple tags)
In the case of these two particular images, they were taken in the area but I don't recall what climbs they are.

More broadly my feeling is that if an area gets tagged with media there has to be a limit to how far down the child hierarchy it gets passed. My worry is that photos that are totally valid for an Area (Landmarks, for example) get passed down 4 or 5 areas and become totally context-divorced.

Area Context

I think as a guidebook user I would like to see photos of the "Area" while I'm browsing through the available information. It is arguably not appropriate for the dataset because it's not directly related to a physical climb, but I would say personally that this kind of image helps to contextualize things - especially for areas I've never been to.

Consider the following use-cases for tagging images to areas rather than with the climbs visible in the picture itself.

Area with navigation beta

This feature doesn't belong to an actual climb, but is arguably still a part of the beta for this area, because you need to go through it to access the base of the crag.

This kind of thing should appear in the beta markdown content, but I'd also want to see it tagged

Landmarks

There are NO routes on this feature (at the time of writing) meaning that if you tagged it to an area now it will show up in all children even though there are no climbs on it. BUT it is a landmark that the area is named after, and my feeling is that the beta for the area should include things like that.

You could also have photos in an area where the photographer doesn't recall the exact name or location of the photo but would still like to tag it

Photos useful up the hierarchy, but not down

The two pictures above are not on named routes, one of them isn't even on a named boulder (pretty sure the climbers are just warming up...) but I think for someone clicking on the Campground, Rocklands area it's good to have a nicely fleshed out bank of images for them to click through to get an impression of rock quality and overall vibe of the area.

There's definitely nuance here - because too much vagueness won't help us either - but I'm just thinking about how many areas have no photos on theCrag, and a non-specific climbing image taken in the area is still more useful than no image at all

Conclusion

I think there may ultimately be a suite of features that could address aspects of each of these media use-cases, but my main point is that we need to be flexible because there may be hundreds of Areas with something specific about them that warrants tagging a picture of something that is not necessarily relevant to the areas children.

Maybe tags should have a flag that signals whether or not child-areas can show the media? That way when users notice photos showing up where they're causing visual noise there is a path to perform housecleaning

[vnugent]

The backend query responsible for area data + photos:

https://github.com/OpenBeta/openbeta-graphql/blob/develop/src/model/AreaDataSource.ts#L149-L156

Is there a case where an area needs to inherit its ancestors' photos?

we can either eliminate case #2 completely or make it optional via a query param.

[musoke]

I can't think of any cases where inheriting ancestor's photos is needed, but of course could be missing something. I would tend towards just tagging the photo with the child if it is a photo of the child.

[bghull]

I also think ancestor photo inheritance causes more confusion than it solves. It is relatively easy to tag approach/location-setting photos with just the parent area, leaving the children area/climb pages to show only the most relevant media.

[bradleyDean]

The backend query responsible for area data + photos:

https://github.com/OpenBeta/openbeta-graphql/blob/develop/src/model/AreaDataSource.ts#L149-L156

Is there a case where an area needs to inherit its ancestors' photos?

we can either eliminate case #2 completely or make it optional via a query param.

Are you sure that you linked to the part that should be removed? It looks to me like we need to remove case 1.
Am I misunderstanding something?

[vnugent]

Are you sure that you linked to the part that should be removed? It looks to me like we need to remove case 1. Am I misunderstanding something?

Nice catch! I got the 2 mixed up. Yes, we need to remove case 1.

[vnugent]

This is fixed in OpenBeta/openbeta-graphql#282

[vnugent]

Let me know if this is still an issue. Page no longer shows photos https://openbeta.io/crag/09d17d69-188c-5bff-9fa7-2a21be8d25c8. You'll have to navigate up to its ancestor Rocklands

[musoke]

I looked at a couple other areas and it all _looks_ good to me.

…

On Wed, May 10, 2023, 08:16 Viet Nguyen ***@***.***> wrote: Let me know if this is still an issue. Page no longer shows photos https://openbeta.io/crag/09d17d69-188c-5bff-9fa7-2a21be8d25c8. You'll have to navigate up to its ancestor Rocklands <https://openbeta.io/crag/4ed6c976-ee02-564a-801e-20ccc10e6e26> — Reply to this email directly, view it on GitHub <#748 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7ET7A6YYXXWZFFWMNVJCLXFOBJNANCNFSM6AAAAAAWE2E7TA> . You are receiving this because you commented.Message ID: ***@***.***>