How to data model and filter Fontainebleau style boulder circuits

[scd]

From a user...

I started checking it on theCrag and there is a problem: Bleau “works” with circuits.

This creates a non easy structuring senario with, in my opinion, three main issues:

• naming
• topos
• changing circuit

1) The first one is a little bit a matter of taste / how you boulder in Bleau. Currently there are two main “conventions” on the crag database:

• “boulder_name" / (AKA) “color_number” https://www.thecrag.com/climbing/france/fontainebleau/route/514756050
• “color_number” - - “boulder_name” https://www.thecrag.com/climbing/france/fontainebleau/route/1007511162

The second one is the one adopted by damien.ralet which is currently doing a lot of the development on the node (I already contacted him to discuss these points). The main reasons behind it are that it is the “natural” way if you climb following circuits, and the fact that many problems have no name (this is especially true for easy one).

I would personally use the first one if a name is available and the “colour_number” if not.

2) The topos issue is a little bit more tricky. It is caused by the fact that problems on the same boulder usually belong to different circuits. For this reason all the topos are in the parent page and not in the children one (i.e. the circuits) as an example: https://www.thecrag.com/climbing/france/fontainebleau/area/455503098

This creates several connected issues. The following are maybe the most relevant:

• ugly/confusing (and quite useless as it is) to see all the topos in the main area page (imagine an area with 50 boulders).
• when you are in the circuit page there is no way to know which problems have topos
• different problems on the same boulder might have the same number (e.g. third topos, two number 4, one in the blue and the other in the yellow circuit)

Some possible solutions/idea:

• remove the topos from the parent node
• add a topos counter (in the parents node page) for the children
• add the possibility to see which problems have a topo while in the children page

3) It looks like circuits change with time and especially recently they are redrawing some of them. This creates an old vs new situation (some problems are “lost” in the new version and the number, and sometime colour, of others might change).

For the moment damien.ralet decided to keep both version (e.g. https://www.thecrag.com/climbing/france/fontainebleau/area/14018635) which is a little confusing and creates duplicates.

I realise that these are most likely Bleau-only problems and fixing them probably requires a lot of work. A general solution (for all the issues, but I am not sure if the optimal one) might be to create a node in each area with all the boulders and then have some function ("similar" to the current circuit) which allow you to create a circuit simply linking already present problems.

[scd]

TODO

• [ ] rework topo algorithm for when to display topos. They should be shown in the area where they are linked to routes. At the moment they show on the area they are parented in.
• [ ] what is happening when circuits are re-done. I am just not sure of the process that is being undertaken here, so it would be good to get a summary. It sounds a little bit like a gym. Does red #4 become yellow #6 in a later version, for example.
• [ ] Do we need archiving as we have them in gyms?
• [ ] assess whether the wishlist concept (#1318) can help here. We are going to take aspirational ascents out of the tick lists and merge with another unused concept call, coincidently, circuits. This is a list of routes from anywhere. If we use this concept, we will build the index normally, based on geo boundaries and boulders, but link in the circuits, so it will be the best of both worlds.

[birgander2]

1) I was probably the one who entered many boulders in the “boulder_name" / (AKA) “color_number” scheme, i.e. using the colour number as alternative name. Even though this is very unconfortable to enter (no alternative name field in the multiple route page), I consider this as the natural way of naming and following the circuits is still no problem, but another solution is also fine. Anyway, consistency would be good and taking into account the number of boulders in Bleau one should not start too late.

2) The topo situation is indeed a mess. I was trying various things and none of them was good. An ideal solution in my opinion is that topos are displayed at their original position (let's say within the blue circuit node) and also at all the other places needed (e.g. also in the red circuit if such a boulder is drawn on it). In that case, one could have a "off-circuit" node for all the non-circuit boulders and no boulders / topos at the main level.

3) Yes, this seem to happen. Here, probably locals are needed. Some boulders disappear, some new boulders are added and many of them stay the same but change their circuit number. In-depth knowledge is needed to track this correctly.

Additional points: 4) Which boulders use Bleau traverse grades and which use normal Bleau grades? This is not entirely clear. TheCrag introduced "Traverse" style, but this is not a good solution. One should have the choice between the two grading system used and call both of them boulders.

5) Currently, one cannot tick an entire circuit. However, this is what many people do, and for what the circuits where originally made. The circuit itself has a grade (D+, ED- etc.), and all boulders need to be done the same day.

[brendanheywood]

Some general quick thoughts about the ideal end game:

• for the purposes of index structure we temporarily ignore the presence of circuits completely, so we have areas which contain boulders / annotations which contain routes. Topos are drawn where they should be at the lowest practical level.
• on top of this we overlay a circuit (aka list) concept. A route can be in multiple lists, lists are ordered and have names. As new lists come we can keep different histories of them. Different guidebooks will have different circuits we can reference. This is all planned and covered in #1318
• taming the complexity that comes with names: ideally names are not linked in any way to circuit but where they are unnamed this creates an issue. Once solution could be that when you add a route to a circuit you can optionally provide an alternate name. Or perhaps the list itself can emphasize that it is merely the "3rd route in the blue circuit" and it's real name could be hidden or de-emphasized
• we have a concept of colors for a route in gyms but it's a mistake to use this here, colors should be linked with circuits not routes. The same route can have different colors in two circuits even in the same guidebook
• we should probably have a new higher level concept of a grouping of lists. ie Guidebook X uses the lists "Red, white, blue". When viewing the index there should be a default grouping, and if there are multiple groupings you can swap to another one. When viewing in the context of a grouping we would show which list(s) each route is in, and most of the time these lists within a grouping would be mutually exclusive. On top of this you can additionally filter to a single list.

Right now, I think the best interim workaround until we can implement the wishlists stuff is to:

• where practical make larger areas with more boulders represented by annotations instead of sub-boulders
• all routes should be listed in boulder by boulder order left to right or right to left, not circuit order
• topo and routes are side by side as they should be
• names are whatever is easiest without causing duplicates, making the circuit color obvious

[birgander2]

Hehe, cross-posting (see above)

[birgander2]

Brendan, I think what you propose is nice, but unnecessarily complex. At least for Bleau. The only real problem is the placement of topos, everything else can be solved with the current system. If you find a solution to show topos in all the index lists of which they contain boulders, I believe everybody is happy. People clearly talk about red circuit problems, off-circuit problems, etc. and most people don't really follow the circuits, so the current organisation seems quite reasonable. The Bleau reference site bleau.info does it in the same way. Don't make yourself more work than necessary.

make larger areas with more boulders:

I tried, not practical, in Bleau you'll usually have lists of several hundreds of boulders.

boulder by boulder:

Impossible in a chaotic field of boulders & needs in-depth knowledge where is what. Lines can even cross boulders, sometimes with jumping.

topo and routes are side by side as they should be:

Agree, but that requires showing topos at multiple places.

names are whatever is easiest:

Agree, we only need consensus.

[DamianRalet]

Hi all, Just to add some information, especially on the TODO list posted higher up.

The circuit are constantly moving in Bleau. Maybe every 5 years or so. When a new circuit is open, there is a reshuffling of the route. For example, the red 2 from an old circuit can be included in a the new circuit tracing blue 1. I think a type of archiving is good. I saw people that were sometime referring to a route from a old circuit, and still climb it. I am not familiar with the concept of wishlist.... So I cannot really say if it is helpfull or not.

As mention in an other post, the number of route in Bleau is huge. And I am trying to fill missing after visiting the area. So I think we (I) should start with a common way to fill the database. I think the best would be to create a large list of route in the parent of the nodes. Then, make a grouping of the routes according to the circuit. When a new circuit is open, we should (difficult if you are not local and following the Bleau history) rename some of the route if they have no name (red 2 --> red 3, aka Old Red 2). To make this, the grouping feature is missing (to my knowledge at least).

Concerning the topo, I cannot pronounce myself on the best way to go. Maybe a grouping according to circuit with a common boulder database would be good?

[brendanheywood]

4) Which boulders use Bleau traverse grades and which use normal Bleau grades? This is not entirely clear. TheCrag introduced "Traverse" style, but this is not a good solution. One should have the choice between the two grading system used and call both of them boulders.

Yeah the 'traverse' grade we didn't properly understand at the time and we need to rethink it. How often is the traverse grade actually used? If it is fringe even within font I'd prefer to just remove it. If it has enough continued traction in real life then we need to make this it's own grade system which isn't reliant on the new type of 'traverse' as opposed to boulder, but this isn't trivial.

5. Currently, one cannot tick an entire circuit. However, this is what many people do, and for what the circuits where originally made. The circuit itself has a grade (D+, ED- etc.), and all boulders need to be done the same day.

How much is this actually done in practice? This isn't something I'd even consider until we has the lists concept in place.

As a reasonably low effort alternate / interim solution to the lists idea, another suggestion is to leverage the hash tags for represent circuits. So take Rocher du Potala as an example, it currently has 4 circuits, 3 old circuits, and 1 off route. 311 problems but really only 177 without duplicates which is perfectly fine as a single node with all the problems and topos together. Then on top of that we would tag each route with tags like "#2016-red" or "#1995-blue". I would suggest that there is never just "#red", it always has a year prefix / suffix so you don't need to change it later, and for the same reason you never use "#oldred".

Then we could implement a quite simple tag based filter, where you get presented with a selector at the top of the page like:

2016: All (177) | yellow (48) | orange (41) | blue (30) | red (57) | none (1) 1995: All (177) | yellow (36) | orange (48) | blue (50) | none (43)

If you select one then the page instantly hides all the rest and you are left with just what you are after. It would hide any routes which aren't in tagged with what is selected, and also hides any topos which do not contain any tagged routes. Routes in the topos which are not tagged would not be removed completely, but would be grayed out.

Usability wise this is about as simple and useful as I think we'll get and almost identical to what I had in mind for the lists concept filter. Implementation wise this is not that much work and is mostly front end with no new database modeling. I reckon I could knock this off in a few hours. And on top of this it is also generally transferable into other crags for purposes other than circuits, eg you could just as easily use this for filtering on whatever other hash tags have been used.

If there is general consensus that this might work, or at least is worth a trial, then I think we should pick a single area in font and give it a try. It should be an area big enough to be causing issues and require circuits to help make sense, but not too big that the trial is not onerous. Rocher du Potala is probably as good as any other area. All of the data entry and route merging etc can be done right now without any development effort from us, and then once we have a good example area we have our perfect test case for the tag based filtering.

This would mean a task list something like:

• [ ] locals: merging all problems into one area, merging duplicated problems properly as you go
• [ ] locals: all routes are listed in the most sane order possible, best effort here
• [ ] locals: all topos are side by side with the problem in them, no duplicated topos
• [ ] locals: agree on common standard of tag names / years and tag all routes
• [ ] Brendan: implement the tag based filter

The main downside to the tags vs the more complex lists concept is that there is no ordering with the tags, where as if and when we implemented the lists we would also be able to use the order of problems in the list rather than the natural index order. If and when we implement the lists is would be easier to migrate from tags to lists, as the bulk of the de-duplicate etc is already done. Also the list concept would be required for anything more structured, eg the additional things like a circuit color, multiple language support, and the circuit ticking grade concept

[birgander2]

5) How much is this actually done in practice?

Well, quite a lot I assume. But this is easy to solve, one could just add additionally the entire circuit with its grade as a climb. Not perfect, but ok, taking into account the low number of Bleausards on thecrag

If there is general consensus that this might work, or at least is worth a trial

I tried that in one of the sectors and honestly I found it not handy at all. The list is just too long and complex, you search for ages to locate the boulder you've done. It would possibly make sense if people draw an overhead topo and split the sector in several small subsectors. Btw, in case of Rocher du Potala, very likely 50-100 additional off-circuit problems are existing.

And finally, it seems there is only one active local at the moment, Damian Ralet ;-) This needs to be considered, too.

I still like the "show topo at multiple places" most. Maybe just in case of a new special feature "circuit"? But I understand if this is not wanted. Maybe it's also too complex to implement.

[DamianRalet]

I think the TAG solution is worth trying. It would be good to use COLOR+YEAR e.g. BLUE-2016. It required a lot of work for each area, but might be easier to use than the actual version. An off-circtuit tag need to be added too. The boulder ordering is difficult. Alphabetical order could be the easiest to find a problem. But tricky for filling the data base. Or maybe best to group routes that are on the same rock? This could add clarity when topo will be added. The rocher potalas has no TOPO yet. So we might not be able to test this features. I will see if I manage to go there and start a TOPO.

The difficulty task might be to merge all the problem (old circuit vs new one). This need careful check of bibliography.

The name: the best (for circuit and off-circuit routes) would be to refer to them by there name. If no name exists, the best would be color+year of the circuit.

[brendanheywood]

I think the TAG solution is worth trying. It would be good to use COLOR+YEAR e.g. BLUE-2016. It required a lot of work for each area, but might be easier to use than the actual version. An off-circtuit tag need to be added too.

I don't think 'off circuit' is needed, because we can automatically add a 'none' or 'other' filter like in the example I gave above, so that saves a little bit of work.

The boulder ordering is difficult. Alphabetical order could be the easiest to find a problem. But tricky for filling the data base. Or maybe best to group routes that are on the same rock? This could add clarity when topo will be added.

I would group them according to the most sane 'natural' order, but this is always going to be subjective. If there are distinct boulders then definitely group them by boulder, and list the routes in a consistent order left to right or right to left around them. This is the same as other bouldering areas without a circuit concept. If most of the circuits roughly follow a similar path through the area then this would be great but I doubt this will always be the case. ie in most areas a good rule of thumb is order from closest to the car park to furthest.

Note that this is a main drawback to the idea of using tags vs using the lists concept. Lists will have their own ordering, and potentially even allow duplicates (I think from memory there was even some circuits that doubled back onto themselves and included the same route twice??). If and when we implement the lists concept later I full expect we'd update font to use the lists instead of tags.

The rocher potalas has no TOPO yet. So we might not be able to test this features. I will see if I manage to go there and start a TOPO.

I think having the topos would be fairly important to seeing how the tags concept works, so it would be good to either create topos for this whole area, or to find another area to use for the trial. Can you suggest a better area?

The difficulty task might be to merge all the problem (old circuit vs new one). This need careful check of bibliography.

It's not critical that the merging is done for the trial, we can do this afterwards if everyone is happy with how the tags method is working.

The name: the best (for circuit and off-circuit routes) would be to refer to them by there name. If no name exists, the best would be color+year of the circuit.

Sounds good to me, but I'll defer to local concensus

[DamianRalet]

As a local, I could give a try on rocher du Potalas for the tag.

If it is validated, I propose to apply it as well on Dampierre-Maincourt area (https://www.thecrag.com/climbing/france/fontainebleau/area/455503098) for which I made a topo. It is not complete, but it would provide a good starting point, and a good test case. And there is a high change that I will go there to finish the topo, so this could be a good test-case. Even if this area is not so well-known...

I could give it a try a some point this week, or later next week-end. If there some type of consensus? At the moment, I might not have the right to change the parent node in Bleau. Could someone grant me this right?

[brendanheywood]

As a local, I could give a try on rocher du Potalas for the tag.

Great! I've just upgraded your permissions for font. I think it makes more sense to work on Dampierre-Maincourt area as the first test area instead. That way there is no risk of messing up anyone's ticks as I think you are the only person to tick there so far, and consensus isn't so important. For me it is a better test as it has all the topos

[DamianRalet]

Thanks for the permission. I just gave a try and I am not sure I can change the node of a route within a circuit. I probably do not find the proper feature.

[DamianRalet]

Sorry, I found it. I will let you know once the work is done.

[brendanheywood]

You can do them in batches, so you should only need to do this once for each circuit to merge them into the parent area.

[nclementel]

Hi, sorry to start this mess and then disappear.

My plan is to go to Bleau coming weekend and I hope to have a better idea about the situation after that.

I am going with some people which often go to Bleau so I will ask them their opinions about these issues. I don't know yet which areas we will go, but anyway I will try to take as many pictures for topos as possible.

Brandan, may you upgrade my permission for Bleau?

[brendanheywood]

Sure, what is your username on thecrag?

[nclementel]

@ nacl

[brendanheywood]

done

[birgander2]

Maybe, as a start, let's agree at least on how to enter the route names in future. I used the name of the boulder and it's circuit color number as alternative name. Example: "Science friction" aka "Red 34", or, if name was not existing, only the circuit color number. Damian did it a bit differently, and there are few others with more notations. I'm open, on what should we agree?

In any case, entering alternative names is not possible when using the add 10/20/30 routes page. One needs a second round through the bulk edit. Would it be possible to add this field?

[birgander2]

When trying a tag-based representation, I propose to order the boulders by grade. As long as there is nothing better, this is the only natural order and can help at least a bit to find your boulder in the looong list. Bleau.info does it like that, together with a filtering for circuits. We should probably do it similarly. However, I still believe the listings get too long. Imagine what happens when descriptions are added.

[nclementel]

The Dampierre-Maincourt area https://www.thecrag.com/climbing/france/fontainebleau/area/455503098 is "ready" for the tag testing.

• All the problems are in the parent node

• Naming updated to the form “boulder_name" / (AKA) “color_number”

• The problems are, at the moment, in no particular order beside the fact that the one with topos come first

• Blue and red circuits have tags for all the problems, yellow and orange only one problem. I think this should be enough for same initial tests and to figure out if tags are a viable option

Brendan, is the current structure of the node what you wanted?

[nclementel]

I propose to order the boulders by grade.

I agree this is a nice way to list the problems, especially when you are logging them since the chance is high that most of the problems you want to log are around similar grades. It is already possible to list by grade using the "grade search" button, the only problem it is that then you loose the ability of logging multiple problems in one go.

[brendanheywood]

When trying a tag-based representation, I propose to order the boulders by grade.

I'm actually not a fan of this at all, if you want to view things by grade then you can do that via the search. Please order it by boulder, left to right / right to left, in the rough order of the circuits (if they all are roughly the same).

Yes you cannot log in the search page but we will fix that shortly so we shouldn't use that as a reason to mess up the index order. Please remember right now the purpose of the trial area is to try and do things in the most idea way which then exposes the problems with the platform which we then need to go and fix. I want to avoid 'workarounds' at this point.

Maybe, as a start, let's agree at least on how to enter the route names in future. I used the name of the boulder and it's circuit color number as alternative name. Example: "Science friction" aka "Red 34", or, if name was not existing, only the circuit color number. Damian did it a bit differently, and there are few others with more notations. I'm open, on what should we agree?

Each name should be an alternate, not many names combined into a single name. If there is a name like "Science friction" then it should be the primary name. The only thing that worries me aka names like "Red 34" is when there are old and new circuits, so maybe this should mirror the tags and be "Red 34 - 2012". Even better would be either "2012 Red 34" or "34 Red 2012" because then you could easily search for all "2012 Red" or "Red 2012" across all of font in one go.

In any case, entering alternative names is not possible when using the add 10/20/30 routes page. One needs a second round through the bulk edit. Would it be possible to add this field?

This is already logged in github in a couple places but a bit further down the priority list #1892 & #635. Right now for the trial it shouldn't matter though as we are just moving routes around and not making new ones.

[DamianRalet]

I could add that the order from boulder to boulder (not the grade order) provide a easier way to read the topos. At least, this is my feeling from the test made so far on the Dampierre-Maincourt area.

[Drazhar]

Just out of curiosity: isn't it recommended to create an "boulder" area for each block to sort it somehow? If there is a single page, containing 100 boulder problems from 20 different blocks, it is kinda confusing even with topo images.

Generally I build boulder areas like this for example https://www.thecrag.com/climbing/switzerland/chironico/area/1040861712 The problem, that ticking boulders from different blocks is to much work, is the only downside in my opinion. Parcours could be searched if each boulder problem from it is tagged I think, so they shouldn't have an influence on how to setup an area.

But if the general opinion about how to add a boulder to TheCrag is different, then I could change the way I do it in the future. Because consistency should be the highest priority.

Ps.: The most people I know bouldering in Bleau (no locals) don't bother the parcours. They just go there like to every other bouldering spot, wandering from block to block and try/project stuff. Probably for warming up, they are doing an easy parcour. But on the other hand, I just read that Nalle has done the hardest parcour from Bleau in one day, so they sure matter. But do they matter that much, that the order of the problems should be done by the parcours instead of the location?

[brendanheywood]

There are two main ways the structure an area, using sub-nodes, or just all together optionally with 'annotations'. If you haven't seen annotations before they look like this:

And they also automatically create a table of contents like this at the top of the index which helps navigating through larger areas:

See that example here: https://www.thecrag.com/climbing/australia/frog-buttress/east

This is used a lot to break up large routes especially when it's a long single cliff line.

One big reason to use sub-boulders is that you can locate each boulder. You cannot currently locate an 'annotation' but this is on the todo list. You can also create area level topos and link to the sub nodes in them, but you cannot do this with annotations (it's also on the todo list). Annotations are a newer feature and once these two tasks above are done then I think for many situations it's preferable. Most users prefer to see an area in one larger page and don't like navigating in and out of lots of little pages each with only a couple of problems.

So my rule of thumb is if the boulders are spread out a little and the location is more important, then make each boulder a sub node. If it's just a compact chaotic mess, usually because there is lots of walls that curve around and merge together rather than distinct boulders, then use annotations. There is no one size fits all solution.

[brendanheywood]

btw @Drazhar I think what you've done with Chironico is good and the way I would have done it. The boulders are spread out and having each located is great.

[Drazhar]

Ok, I think a mix of both is probably the best. Chironico and Cresciano are kinda spread, or lets say the most boulders are seperated at least. But in Magic Wood this is a bit more complicated, because the blocks sometimes are at top of each other.

[birgander2]

Yes you cannot log in the search page but we will fix that shortly

• [ ] When you do so, please also fix that the alternative name is not shown in the search page. Otherwise this is a showstopper, as you cannot identify the boulders with name by their circuit number anymore.

this should mirror the tags and be "Red 34 - 2012"

I see the point, but this looks really ugly as a name.

isn't it recommended to create an "boulder" area for each block to sort it somehow

That's the ideal solution, but I fear totally not very practical in the more complex block fields of Bleau. Maybe it works in Dampierre-Maincourt, but in Apremont? When searching for the best solution I think we should consider the man power available. Certainly there are very nice solutions, but they require the full work of a guidebook author. Honestly, I don't see this happen. We have to make trade-offs.

[Drazhar]

When searching for the best solution I think we should consider the man power available. Certainly there are very nice solutions, but they require the full work of a guidebook author. Honestly, I don't see this happen. We have to make trade-offs.

Well there you are 100% correct.

[johtso]

With a tag based approach wouldn't the tag need to be something like #2016-red-12 seeing as the circuit colour and number can be specific to a certain year?

[brendanheywood]

The tag based approach is only an interim prototype thing, and if we want to do filtering of a single circuit then it is much easier if all the problems have the same tag. So it's best not to include the number, just the year and color. When we implement the full wishlist / circuit concept then we will also get the proper ordering of routes within each circuit.

@nclementel this is enough of an example to get the tag filtering idea up and running. I'll get to this in the next couple weeks

[johtso]

The tagging solution is useful for allowing filtering given current functionality, but I think we need a little more in order to properly describe the circuit number based names of a route.

The issue is that circuit colour and circuit number are specific to a given "circuit setting".

I've begun updating the blue circuit in the 95.2 area. Some of the routes previously existed as part of a different coloured circuit.. or they had a different circuit number. Here's a PDF of the latest blue circuit setting, and how the route numbers changed: https://archive.org/download/FontainebleauClimbingTopologies/95_2-2016-blue_circuit.pdf.

As you can see, I've been using alternative names for the circuit colour and number, and I've been using the form "year colour number". This seems to work quite well, conveys all the relevant information, and makes it easy to tell that, for example, a route that is now "Blue 21" was previously "Red 14".

There are a couple of issues.

1. Not being able to control ordering, so the list display is confusing, with the historical circuit number sometimes appearing before the current one. This could possibly be solved my either allowing explicit control of alternative name order when editing a route, or by making historical names appear after non historical names?
2. Not possible to filter routes by name (unless I'm missing something). If this was possible, then in theory you could filter an areas routes by something like "2016 Blue" and see just the current Blue circuit routes, without any need for tags.

To summarise:

The tags are a great idea to allow circuits to be relatively usable in the interim without any extra development needed.

I suggest that a route's alternative circuit number names be of the format "year colour number", and historical route "colour/number"s are kept as historical alternative names.

[brendanheywood]

Not being able to control ordering

Yes this is expected and the only way to solve it is with the full "wishlist" / "circuit" concept, which we want to do but it's a fair bit of work and is a little down the list of priorities.

Not possible to filter routes by name (unless I'm missing something). If this was possible, then in theory you could filter an areas routes by something like "2016 Blue" and see just the current Blue circuit routes, without any need for tags.

You can search by name elsewhere, but the quick interim approach was do a quick scan through all the tags used in the current area and automatically build a tag based filter which you can just click on without typing anything. This is why a tag approach is better than just searching on the name. Also we only want to turn this on in certain areas, and to detect this automatically. We can do this by looking at all the tags and if there is say > 75% of routes use tags and most tags are used more than 5% of routes then build the tag filter menu. This is much harder to do with names which are very free form.

The tag based idea is only a few hours work and I hope to get onto this in the next few weeks and I will be using this area as the prototype (thanks @nclementel):

https://www.thecrag.com/climbing/france/fontainebleau/area/455503098

[johtso]

That all makes a lot of sense. Any thoughts on the naming format I've been using with years?

[nclementel]

This might be useful to have, and eventually link somewhere when in a final form, for people adding problems in Bleau (the part in red is dependent on how the TAG system works).

Feel free to add/change/comment: https://docs.google.com/document/d/1re5b5hFZaYM4R_4wcyrYznR_UaZVapA0SnSjjm_nGko/edit?usp=sharing

@johtso I am not sure it is a solution. In my opinion something like this

Le Chasse-Pied / 2016 Blue 21 / 1980 Blue 19 / Kansas City Boulder

is a little bit ugly and confusing (the existence of the "Number bis/tris" is already creating the situation that Blue 21 is actually number 23 on theCrag indexing).

Besides that I am still thinking about, if we accept the fact that the circuits in the forest are a changing entity, what is the importance of keeping track that in was number 19 in the 1980 blue circuit:

• If someone is climbing it now on the rock and in principle on a new guidebook (here the power of something like theCrag!) it is Blue 21

• If someone log it in the past I don't really see the issue that the name changed from Blue 19 to Blue 21

• In this case there is no confusion since the problem has a "Name": Le Chasse-Pied

The only two situations I can think in which it might be important are:

1. you want to log an ascent from the past and only remember the "Color Number" name;

2. a problem which has only a "Color Number" name is not included in any new circuits and therefore becomes a 'off-circuits' problem.

[johtso]

I believe it is important not to throw away information about previous route numbers, and to also be explicit about what circuit setting data is referring to.

On the importance of not throwing away previous route numbers, given the fact that the colour and number is often all that is used to refer to a given route, it is an important piece of information. People will use these ephemeral names when posting images and videos online. When a circuit is updated, it shouldn't mean that all references to that route become lost.

On the point of being explicit about circuit versions, it really muddies the waters to not include that information. When updating circuits, you need to be able to distinguish between old/stale data, and data that has been updated to the latest circuit setting.

Another example of the use of having the historical circuit numbers. If I went and ticked a whole circuit last year, I should be able to go to that circuit on thecrag and see that I ticked all the routes on the 1980 circuit, even though the routes have now changed.

Saying all that..

All the issues of "messiness" and display of names wont be an issue once route lists/circuits are implemented, and there can just be multiple lists for the different years, and the lists can contain the route "numbers".

This is just a temporary measure after all, and I feel that explicitness, clarity and data preservation are the most important things at this point.

Things will look nice when we have route lists, we shouldn't be throwing away information just so they can look nicer now.

I'm also sure there are small tweaks that could be made to the ui to make things a little less cluttered in the interim, such as hiding historical type alternative names from the list view.

[birgander2]

I would like to bring up an old proposal again, which (I think) should be very easy to implement: Currently, when a route is drawn on a topo, it gets a black number marker. But only if this topo is placed on the same node. It would be very helpful, if these black markers are also set if the topo is placed somewhere else. This directly indicates that a topo will be shown when you click on the route / boulder. Or put this small number of topos besides, like it is done in the sector listing.

As now, I find it inconsistent: you see only a gray marker, but when you click on the route, the description surprisingly might show a topo. Generally, I would prefer to show such topos at multiple nodes, but I understood that this is not the way you want it to be.

I'm also a bit concerned about the (mobile) download times, when a whole Bleau sector is stored in a single node with possibly 100++ topo images. On bleau.info for example I can get a quick listing of all problems, with a small icon behind if a photo / topo is included. So probably I have to download only 1 or 2 of those.

[brendanheywood]

@birgander2 I've split that off into it's own issue https://github.com/theCrag/website/issues/2731

[brendanheywood]

Ok I've just had a very quick go at this, the very rough work so far is here as an example:

https://dev.thecrag.com/climbing/australia/gara-gorge/upper-gara-gorge/area/715232124

There is all sorts of bugs going on, and things which don't work yet but it should be enough to give people a feel for how this would work. If grinds through all the tags and presents them as a filter like this:

You click on a filter and then it hides all route except ones with that tag. Things it doesn't do yet is also hide topos which no longer contain any visible routes, and also doing the same for the annotations.

[nclementel]

I checked the result at the test area:

https://dev.thecrag.com/climbing/france/fontainebleau/area/455503098

Thanks Brendan, I think it is a good starting point!

Here some idea for discussion:

• put more recent year first

• in topo tooltip for problems remove the info "Boulder" (not really useful imho) and add the aka-name if present

• (as already pointed out by Brendan) hide the topo for boulders without problems in the circuit

• if a topo has also problems that are not in the circuit, keep them but make it clear visually

[lordyavin]

Just a side note: Why not enabling "circuits" again? This feature matches the requirements, doesn't it?

[scd]

Yup it is on the list.

[oni303]

As far as I understood "circuits" so far, I think they would meet the basic requirements.

For a more solution that is separated form the "lists", I was thinking of some sort of a virtual area which contains all the routes in the circuit. It would be like a second parent for these routes. By this the topos could be assigned the normal way to the actual boulders and the routes could also be listed in the correct order for the circuit.

If a circuit changes over time, the virtual areas could be named with a year.

I guess it would be a lot of work. Are routes with multiple parents possible in the current database design?

[brendanheywood]

No we currently do not allow multiple parents. We have considered this, eg other databases with a stronger emphasis on mountaineering require this because a range or peak quite often straddles a border of 2 or even 3 countries or regions. This is fairly low on our priority list though and would be a fairly major task.

The 'lists' concept we will definitely tackle first before we try to solve this circuit concept as it has a much broader use, and there is a lot of overlap so they may end up being an ok solution here. Lists will be able to span multiple areas / bouldes, will have their own order, and when a circuit changes you could just clone it to a new list and have them both for histories sake.

[birgander2]

I totally forgot about this old discussion we had. So closing #3423 and continuing here:

Understood, it's not a bug, it's a feature :wink:

Yes, what I did was a (test-)hack. However, I don't see a proper solution on the horizon. Even with a circuit data model, I fear that many listings would appear very cluttered, just image 200+ off-circuit problems with a topo each. Also, properly maintaining the circuits would require a bunch of active locals. Re-associating problems without names (i.e. red-14, red-15) after a circuit has been repainted is almost impossible without in-depth knowledge of the sector. The currently practiced hack to reparent outdated circuits to "historic circuits" is not such a bad solution. Anyway, I still think, that a specialised node "topos", plus a photo symbol in the description, is at least the best solution for the moment.

[rouletout]

With release 92 the concept of lists was introduced to replace circuits. This feature allows for many of the topics raised above. Please comment here what you miss re circuits in FB and we will create separate issues to make that endless issue easier to manage :-).