Should we make topo order explicit instead of automatic?

[brendanheywood]

Two slightly overlapping topics here:

• I've been thinking and experimenting and playing a lot with #859 which is how we interleave the topos into the routes. I think I've come up with a ok-ish algorithm but I'm starting to think that I'm over thinking it, and perhaps the best solutions is to just make topos like other nodes in the child list like annotations, routes and areas. I've found a couple examples where human judgement will always triumph. If we do this, we'd simple bake the current interleaving order into the current mix and then let people evolve it from there, reorder using the existing re-order process. I see lots of pros and cons for this and just wanted to gauge others feelings on it. I think for most people, the way it works now is kinda voodoo. If we go with this then we won't mess with the order of nodes in the templates like we are now. I'm coming up against this now in my list of test cases where I'm shuffling certain types of topos to the top of the list, like area topos, but the list of rules and edges cases is getting overwhelming and starting to smell like it's not tenable any more.

• In theory it shouldn't happen much but where routes and areas are mixed, we'd need to show them as-is eg:

  http://dev.thecrag.com/climbing/australia/arapiles/king-rat-area/area/11962291

If we go ahead then this becomes a data issue not a code one. We could do a report to highlight the areas with intermingled types to clean up manually.

I'd like a bit of direction for this, because if we're planning on doing this eventually I think I'll hold off on the client side solution, and just stick with the existing server side impl for now.

[scd]

I agree with the direction on both topics.

• RE TOPO: This will possibly take some time to implement, and at the very least I should put some heavy neurons into working out what processes will be effected. At one stage there was an issue which required a topo to be connected to two nodes (did a search, but could not find it). In principle I agree with this, however it is a very commiting change so I think we should sit on it for some time first. My recommendation is to make this a post topo release issue.
• RE AREA ORDER: Yup, just do it- don't wait for any scripts for me to work out areas with manual changes. I can write the script at any time as it does not have to be associated with a release. Assuming you are going to make the change we need to think about the REORDER button.

[brendanheywood]

Ok cool. I'll go ahead and re-do the topo interleaving with the new list view server side. This will be a fair bit simpler that we currently have and I'll document the new rules in #859. I'll leave this issue open which will become just the topo re-order and I'll put it into 'long term issues'

[brendanheywood]

Another test case for this:

http://www.thecrag.com/climbing/australia/nowra/area/351405501

Makes we wonder whether I should re-enable the idea that once a route has been shown in any topo, it shouldn't get counted again for future topos.

[brendanheywood]

A few extra thoughts if we keep as automatic which I'm slightly still leaning towards because it works for the majority of use cases and is less work overall, we just need a good way to manage the edge cases for the power users

• [ ] we need to be able to link to annotations and other topos: #1693
• [ ] there is a need for 'overview' topos which sit at the top eg @DaneEvans just opened a duplicate #2484. An easy workaround for this would be to simply treat topos with no linked routes as 'overview' topos and float them to the top like we do for the area topos, instead of to the bottom. This would also make 'dud' topos sit at the top of the page and be in your face and make you want to fix them or delete them and so overall improve the topo quality. Downside is we probably do want to link to nodes in these overhead topos
• [ ] Or we could instead utilize the 'overhead' flag we added ages ago but never ended up using - but rename it to something like 'overview' instead and make it clear that this will force the topo to the top of the page.

This also isn't dependent on, but interacts with the new sticky topo header concept in #2461

[DaneEvans]

• I'd prefer to be able to link to routes and still have it appear first, that way you can click on the route in the overview topo to jump to the route and surrounding lines

• The overhead flag would work fine (Actually I was worried that it did just that, and I'd never tried to use it) maybe limit it to 1 or 2 per area. If you need more than that it could be split into sub areas

Duds on top would be nice for us, but might affect usability for the general user

(I suspect it would be a lot of work, but we could have a user level control that allows you to chose an 'editor' role that helps highlight orphan topos, unlocated nodes, and other such things)

[brendanheywood]

@DaneEvans it's a bit hidden but you can already do some of that including

eg searching for topos which are missing data:

https://www.thecrag.com/climbing/australia/victoria/topos/missing/all-data/?sortby=at,asc

[georg-d]

In Altvogelbach, the upper topo only contains routes with higher numbers (13,14,15) than the lower topo (12,...). Hence, the upper topo appears "one route and one annotation too high" and I have no clue how to correct that. Screenshot:

[rouletout]

ordering is done since a while, also annotations are abvailable on topos, closing

[brendanheywood]

This is not yet done, at least not in current production. Topos do not appear in the Reorder process

[rouletout]

Yup, as this is automated - there will be no manual option.

[brendanheywood]

This issue is explicitly about making it manual instead of automatic, or a better hybrid where is starts automatic but you can optionally override the order. I have tons of topos which are in the wrong order because the automatic algorithm can never be 100% perfect and I'd dearly love to make them explicit in these cases. This is simply not done yet and it should be reopened

[rouletout]

The decision was made to leave that automatic. Can you add examples here so we can see why this wouldn't work? Otherwise close again.

[brendanheywood]

The current algorithm works really well with linear cliffs and topos interspersed along it and where if a topo position is off by a route or two because multiple topos cover the sames routes then it doesn't matter. There are few use cases I've found where it does sub optimal or outright buggy things:

1) You have an area with an annotation and then say 10 routes, and a topo for them but the topo only covers say routes 3-10 but otherwise is a complete topo for that entire section of cliff / annotation. In many cases it can look and read better if the topo is ordered directly under the annotation and then all the routes after it rather than the topo splitting the list if 10 routes.

2) a large boulder covered in problem where it is useful to have shot of a boulder from all angles, and each topo overlaps by 1 or 2 routes with the adjacent topos in a loop. The last topo overlaps with the first topo as you have completed the circle, but if you link in the first route which overlaps then this topo gets moved right back up next to the first topo when it should be the last topo.

3) In a similar situation as above but also in the background of some of the topos are other problems on different boulders which are either different nodes or under a different annotation. It can be very useful to show the adjacent problems to help orint yourself in a complex boulder field. By linking it to these 'off boulder' problems the whole topo can get moved up into the other boulders annotation if it is ordered earlier so the topo is completely in the wrong place.

4) similar to above but showing its not restricted to bouldering, you have a multipitch crag with ledges and each ledge is an annotation and you have a topo for each ledge / annotation. But you also want to mark the beginning or end of other routes which are on the edge of the topo so you have continuity with the other topos, but by adding them the topos get moved to the incorrect annotation.

Whenever I've hit these examples I've removed the extra linked routes so they are not messed up so I don't have any live examples, but I'd still want this capability. I'd guess around 95% of topos I've made work well with the automatic ordering, but that remaining 5% can end up really screwy. I'd want to keep the automatic ordering for almost all, but want an override option to just say 'topo X goes before route N'. Example 1 above is a small improvement, the type of thing a professional book designer would do. The last 3 examples are proper bugs, and I can't see any way of improving the algorithm to work in all these cases at the same time.

There was a hacky workaround (not sure if still present) which worked in some of these cases where you could link unrelated routes to a topo but not actually draw them on. The algorithm looked at which routes where linked not which ones were drawn, and so you could make the algorithm pull the topo up to an earlier position. But this only allowed you to position them earlier, but not later in the overall order.

[killakalle]

Here's an example where the automatic topo order that is not ideal and I haven't figured out how to change it.

https://www.thecrag.com/es/escalar/spain/bellus/area/402609570

Topo 2 contains all the routes of the sector and should be the first topo. Topo 1 contains only routes 1 and 2 and should be in the second place. (I have just not gotten around to draw all the routes).

The "hacky workaround" mentioned above does not work for that example, because Topo 1 should contain the first route of the crag and I don't want to remove it from that topo.

[georg-d]

Can you add examples here so we can see why this wouldn't work? Otherwise close again.

My above mentioned example Altvogelbach is still showing topo with routes 15+16+17 between 12+13. I would understand that if route 12 or 13 was already depicted in the topo, but these are still missing there.

[georg-d]

Can you add examples here so we can see why this wouldn't work? Otherwise close again.

https://www.thecrag.com/en/climbing/italy/finale-ligure/caprazoppa/area/1441686498 first shows detail topos of just 2 routes, then the topo of the whole sector, then again detail topos of few routes. On a small screen like a mobile, it's easy to miss that the overview topo exists at all – in fact, I created an[other] overview topo and afterwards realized it was redundant work 😕

The workaround to add an empty, elsewise useless annotation before route #1 and refer this annotation in the topo just to enforce the overview topo appears forst, well, feels like a bad, hacky idea. And it's not stable because an empty annotation is likely being removed without noticing the side-effect on topo sequence.

https://github.com/theCrag/website/issues/4108#issuecomment-1732616884 names an idea IMHO worthwhile to reflect: If two topos share the first route, place first the topo with highest last route index