Problem dealing with overviewing topos

[Dwstr]

I like to make overviewing topos combined with smaller sections of topos to easier to find the route. But the way the topos are sorted makes this workflow just more confusing and messy.

If you have a topo with route 1-3 and a topo with route 1-10. Then the topo image with route 1-3 and topo image with 1-10 below and then followed by all the routes below both topo images. And if you have another topo with route 6-7, this topo comes in beteween the route list. Often the overview is just enough to find the route, and then all the smaller topos are in the way making it harder to navigate. And some times the 1-3 topo comes before 1-10 topo, which makes it even more confusing.

When I am at the crag I tend to go into editing mode just because the structure is much better there. You see the topo and then all the associated routes below every topo which is much mor logical.

Example url(s) to reproduce the problem: https://www.thecrag.com/climbing/sweden/stockholm/area/3209257350 https://www.thecrag.com/climbing/sweden/gaseborg/area/14196601

The problem:

How I think it should look:

Even worse problem:

[Mdemaillard]

seems very related to #3027, if not a full duplicate. see also #1190

[Mdemaillard]

Hi @Dwstr as you can see that topic has been around and thought about a few times. That is not to say it is resolved :-) The overview staying first on top is a valid improvement that still hasn't received a solution, if multiple topos list the route Nr1.

Concerning your proposal, i think the biggest drawback would be that the same route could appear multiple times. I wouldnt want the index to be even more extended by route duplicates than it gets already by lots of topos.

In my view, the current solution causes issues mostly for areas which are overly rich with topos, in which case a solution could be to pick and choose which ones to use, or maybe have better pictures taken to limit overlap. Or other edge cases really.

[Dwstr]

Ah, I see. I prefer better logic and structure over short scrolling though. I'm used to 27 crags, but the big differens there is that you just see one topo at the time, and then it is maybe makes more sense to show the route multiple times.

As it is for now it feels kinda useless to upload both overview and close up, but I don't know what is preferred though. You have to scroll forever to see the route names and you wont get the overviewing feeling as supposed. I think the optimal solution would be both. If you could choose "Sort by route", then the index shows as today and "Sort by topo" and then you get the topos as groups like in editing mode.

One big reason why you need the close up pictures is due to the aggressive image compression. That is the biggest reason you can't rely on just overviewing topos of larger areas, because you won't see much when you zoom.

As I see it, it is better to have fewer images that covers lager areas than multiple close up images of small areas. But that is not possible due to image compression, therefore I think both is needed. But uploading both causes trouble.

[Dwstr]

Hi @Dwstr as you can see that topic has been around and thought about a few times. That is not to say it is resolved :-) The overview staying first on top is a valid improvement that still hasn't received a solution, if multiple topos list the route Nr1.

Concerning your proposal, i think the biggest drawback would be that the same route could appear multiple times. I wouldnt want the index to be even more extended by route duplicates than it gets already by lots of topos.

In my view, the current solution causes issues mostly for areas which are overly rich with topos, in which case a solution could be to pick and choose which ones to use, or maybe have better pictures taken to limit overlap. Or other edge cases really.

I think it would be perfect if it was possible to hide "child topos" from the index page, but on the route page all images related to the route is shown. A small camera icon beside the route could indicate that there are more images related to the route.

[Mdemaillard]

This last suggestion is close to #2947 of adding a "hide topos" toggle in index That would help for quite a few user cases

[georg-d]

As I see it, it is better to have fewer images that covers lager areas than multiple close up images of small areas. But that is not possible due to image compression, therefore I think both is needed. But uploading both causes trouble.

Not only due to strong compression, in an ideal route information site, you'd want two types of pictures: A wide panoramic view is very helpful for the overview & orientation, but will not allow to reliably locate all routes, e.g. where you've vegetation (hiding parts of the rock) or the rock is not a plane but e.g. a zigzag (many different angles so from any point of view, something is badly recognizable). Close ups allow to reliably find single routes, but must be quite narrow angled and thus quite fragmented for a zigzag shaped cliff because between 2 edges, only few routes fit in - hence, these pics alone don't help much for orientation. Similar for more dense vegetation. Solution ideas that come to my mind:

• Explicitly let users tell apart those two types of photo topo, e.g. via tag or radio button. Then, allow to toggle them on/off in routes listing, resulting in 4 possible states (no topos like desired in #2947, only overview topos, only detail, both). That's my favorite approach beacuse it solves the problem yet seems easy.
• EDIT: In routes list, allow to collapse/unfold topos by 1 click so a currently irrelevant topo "tearing apart" the routes can be reduced to just 1 line of text. For example in 1st image of original post, if you wanna climb route 10 you'd collapse topos between routes 3+4 and 6+7 to have both topos for route 10 near to each other and the route's text.
• EDIT: In routes list, each route gets a small toggle button to move all relevant topos to appear directly next to that route", so it does re-arrange the web page such that all topos showing a certain route will be moved from their initial position to the route, and when the button is clicked again, they move back to the initial position. For example in 1st image of original post, if you wanna climb route 11 you'd press the button and 1st and 5th topo move below route 10, pressing the button again moves the topos up again. This will be too demanding to realize in PDF guide for the possible benefit (most PDF readers do not fully support scripting in PDFs and after a PDF printed on paper won't execute any scripts), but for HTML, it kind of switches between the two approaches "topos arragend inline routes list, i.e. topo listed above 1st contained route" and "routes arranged inline topos list, i.e. routes listed below a topo" (while avoiding to show a route several times which 1. may confuse users and 2. will increase scrolling a lot for topo-rich crags and 3. is a source of quite a lot of programming for edge cases like e.g. 1 route shown 2 times and both checkboxes ticked and "merge routes" selected) .
• In topo view: Allow photo topos to be sorted/arranged, so it's easy to recognize neighbours in the topo overview. This makes overview topos less desired but does not at all make them redundand.
• Allow to link adjacent close up photo topos and to navigate / move between them in "nearly full screen", so a little like Google Street View. This makes overview topos redundant but is quite an effort. This would be an alternative, upside-down approach to the current approach, because the current one has routes listing as 1st class citizens and topos are child objects, which are initially small and can only be zoomed in, but stay part of the route listing. The new alternative approach I have in mind has topo photos as 1st class citizens, shows one at a time in "zoomed in state" (nearly full screen), and offers to navigate between them using arrows (left+right and up+down and maybe also 45° diagonally). The navigation may even work across sectors if it makes sense because they are direct horizontal/vertical neighbours like at Gueberschwihr. Routes shown in the visible topo photo are initially small child objects that can be expanded, e.g. from route name+grade to current route listing with icons, descriptions, etc.

[georg-d]

The overview staying first on top is a valid improvement that still hasn't received a solution, if multiple topos list the route Nr1.

By co-incidence, I found a workaround: If you want the overview image for sure above the detail topo for route 1, assign the overview topo to the first sub area (sector or the like) which has the same parent as the routes (i.e. do not move the routes into that sub area but let the routes and sub sectors be siblings). If there are such sub areas anyway like in Muggendorf, it's IMHO an OK workaround, if there are none, I'd prefer to use annotations because these do not create an empty container element XOR endless hierarchy levels with each having only 2-10 routes like sub areas do (Harzloch as an example). See sandpit > #3674 annotations for an example with annotations you can play around with, and sandpit > #3674 sectors with area types (sectors) - e.g. if you unlink area "overview" from overview topo, the overview topo moves down and you cannot control whether it's above or below the other detail topo.

[rouletout]

Another example: https://www.thecrag.com/climbing/austria/hochschwab/area/3801875409

The topo here should be on top but as it also includes routes from further down in the list and thus is inserted too low.

[rouletout]

See also https://github.com/theCrag/website/issues/3746