Removed climb / historical description tag

[brendanheywood]

Not sure if there is already a way to flag this? Was thinking of a new tag 'No longer possible'. Could be used for banned routes, routes that no longer exist etc. I don't think we need finer grained tags for each case. It could also re-use or inherit from the Legality > Closed / Illegal area tag.

Would render something like this:

Also because of the way the tags are separate to the node editing process, it's quite hidden to edit a route's tag from list view. We really should merge the tags into the bulk edit #826 as part of this and the other new tag work for Nicky #1241

[scd]

Good idea.

[brendanheywood]

Just found this and this is possibly consistent with the gym archive stuff? see #1489

only difference I can see is that archived routes outside may be shown 'for historical reasons' but inside we'd filter them by default.

[scd]

I think it is more complex then this. If you do a route faceted search at the world level, we would want to pick up the routes which are there for historical reasons (this issue) but not pickup routes that have been archived in a gym. If we overloaded this flag then this would be very difficult.

In summary this flag seems easy to implement because it just effects the UI, however the archive flag effects the the db calls as well.

[brendanheywood]

Conceptually they are the same, so I think the underlying data model should be the same and it's only how we treat it in the UI which changes. I thought about this too but I don't think it will be an issue, for a few reasons. First gym routes are excluded by default for routes searching so will almost never turn up. Secondly because the default facets applied are already different, ie routes in QLD don't show gyms routes, but routes in RockIT do, then we can easily add more different default facets, ie inside gyms we show artificial routes and also ignore removed routes, and outside we ignore artificial routes and do show removed routes. In either case you can remove, or add back in this facet if you want. This would get cleaned up more in #1179

The only thing I don't like about using the history table is that it is an extra join, and in the case of gyms the number of archived routes will over time far exceed current routes so this needs to be quick. This leans towards a flag instead of a join, but this same argument can be made to removed routes on a crag, so this still makes me think the data model should be the same, regardless of flag or history record. Perhaps the best is to use the history, but the internally set the flag based on the history just for query speed. But this is the dreaded premature optimisation so I think we can ignore this for the time being, or test and see.

[scd]

I have already put an 'archive' flag in the node table so it will be implemented as a flag.

Your explanation on route faceted search may be reasonable.

What about stats? Do we have different rollup rules for depending on the context of the routes?

What about template data when navigating - does the backend need to work out the context of the routes?

The only functional thing I see with historical outdoor routes is an icon on the UI. Maybe it is better suited as a route tag.

[brendanheywood]

I have already put an 'archive' flag in the node table so it will be implemented as a flag.

I'm cool with that. Do we care that we don't know when an artificial route was removed?

What about stats? Do we have different rollup rules for depending on the context of the routes?

Yes, don't we already? Artificial don't roll up to outside the gym, but do rollup inside the gym.

What about template data when navigating - does the backend need to work out the context of the routes?

Yes, and again, aren't we already doing this? the gym templates get different data from the normal nodes. So yes the backend should filter out the removed gym routes before passing to the gym templates.

The only functional thing I see with historical outdoor routes is an icon on the UI. Maybe it is better suited as a route tag.

If the flag is already implemented then why not use it for both? If I'm looking through a search of routes inside a gym, including removed routes, I think using the same red 'not ticking' icon would work perfectly in both cases.

[scd]

I have already put an 'archive' flag in the node table so it will be implemented as a flag.
I'm cool with that. Do we care that we don't know when an artificial route was removed?

We have last update date. Once a route is archived it probably will not be updated again. The only use case I can think of is gyms looking at unarchiving, in which case last update date would do.

What about stats? Do we have different rollup rules for depending on the context of the routes?
Yes, don't we already? Artificial don't roll up to outside the gym, but do rollup inside the gym.

Not exactly. Artificial ascents have their own count which rolls up to world node. In gyms, we could treat archiving like deleting as far as stats are concerned, so there would be very little stats work to do. However if we wanted to treat this differently outside gyms then I would have to create a new stat 'archiveCount'. You may be able to convince me that the stats could be treated the same inside and outside the gym, so a cliff with three normal routes and one archive route would have a route count of 3 (I think this is reasonable because the ghost route is not climbable and could be greyed out to indicate such).

What about template data when navigating - does the backend need to work out the context of the routes?
Yes, and again, aren't we already doing this? the gym templates get different data from the normal nodes. So yes the backend should filter out the removed gym routes before passing to the gym templates.

Yup I could easily do this at the template level, but I was thinking more about doing it at the database level, then it would be consistent with the API. That being said I could still do it at the database level and just switch the flag on/off depending on the context.

The only functional thing I see with historical outdoor routes is an icon on the UI. Maybe it is better suited as a route tag.
If the flag is already implemented then why not use it for both? If I'm looking through a search of routes inside a gym, including removed routes, I think using the same red 'not ticking' icon would work perfectly in both cases.

If we can commit to the only contextual difference being that outside a gym archived routes are greyed out and inside they are not visible then I could come at that. This means stats treatment and faceted search have the same functionality. Don't forget all the special context dependant work I did for gym ascents was a lot of work, there were dozens of specials and issues popping up all over the place.

I think there is benefit in having the same UI mechanism for updating the routes - simplify for users. Depending on the functionality we decide, it could be more work for me.

[brendanheywood]

Ok I'll leave it up to you, implementing the same style in the front end is little work compared to backend stuff

[lordyavin]

@brendanheywood Thanks for pointing me to this issue. I did a search before raising #1950 but for some reason I didn't find.

So, any schedule changes for this feature?

BTW: I like the sample rendering.

[scd]

not on my radar right now

[brendanheywood]

I just had a random thought for a quick workaround: just copy this Unicode char into the title: 🚫

A little hacky but should look ok and give use something to search on to find if we do implement it properly.

Please give it a go @lordyavin and paste the URL of the example into this issue

[lordyavin]

Oops. I did something wrong. Now the route I added the Unicode char can't be edited anymore and the sign isn't displayed.

Cannot continue process: could not get cache record for node '249626985' State: 18544 Error Code: 2 CodeReference: CIDS::Process::SupplyInformation::BulkEdit, /opt/CIDS/perllib/CIDS/Process/SupplyInformation/BulkEdit.pm, 677

Modified the route 'Lauf der Dinge' in this area: http://www.thecrag.com/climbing/germany/schwaebische-alb/area/249625830

[scd]

bug in code which failed if route had blank name. Normally route should not have blank name but I am guessing another bug has allowed this. I have restored the route

[scd]

It turns out there were four issues here. Three were easy to fix but the core issue is a significant piece of work. It turns out that our MYSQL utf collation set uses 3 byte collation not the full 4 byte. This means that some unicode charaters will not be accepted. Doh.

There is a different utf8 collation set we can use which will fix the issue - utf8mb4 but a major piece of work to upgrade.

https://mathiasbynens.be/notes/mysql-utf8mb4

[scd]

see #1968

[scd]

@lordyavin this looks like it is going to take a fair while to fix properly.

If you hash tag the route (in the description field) with something that you will remember then in a couple of months when the functionality is ready you can do a search for that hash tag and update the routes properly.

For example

archive

I know it is sub-optimal, but it means you can get the data entry out of your head for a while.

[brendanheywood]

@scd it seems adding new structured tags is pretty easy in the grand scheme of things, how about instead we implement this as a new structured tag, probably under 'Condition' and then I can do all the rest in the template to convert that to the red circle.

'archive' isn't quite the right word, this mostly needs to cover rockfalls mostly to distinguish it from merely forbidden which we already have. Something like 'destroyed' or 'ruined'. 'Unclimbable' might suggest that it's just really hard.

[scd]

Sounds good. We can get different tags for different reasons.

[scd]

@lordyavin do you want to do a bit of thinking as to what structured tags you want and under what grouping. I think we will put them in route character. Note that they can be area and/or route tags.

This is better than the archive tag because archiving has specific functionality which would have to be turned off, which requires a fair bit of analysis.

Doing it as structured tags is now a small and manageable. I await your input.

[brendanheywood]

Well I think the 80% use case is a climb that has been damaged beyond recognition or removed like a fallen pillar. Suggested: destroyed

The next use case I'd say is a sport route while not nesesarily badly bolted (ie over a crack) has been removed for whatever reason and cannot be trad climbed. Suggested: chopped

Then I think we get into much more edge case stuff, like a route buried by mud after a flood (seen it), or flooded by daming. Note sure how much we care, these are functionary still destroyed but could conceivably come back later, and the details are best in the text or an annotation anyway.

[lordyavin]

I agree with Brendans proposals. Destroyed and chopped are good tags. But I hope that these tags are going to be reflected in the route list of a crag. Like the stop sign we tried ;-) Additionally destroyed routes should not be listed in PDF guides or the Crag Guru.

Maybe we need a new tag group like "condition".

[scd]

If Brendan is happy with the group 'Condition' we could go with that. The problem I have with the word condition is that it should have all ranges of tags including good condition. So maybe we need a group that implies only exception tags are used.

What about areas, are their similar tags (eg a cliff face collapses).

There is no rush to get all the functionality in place, but the tags is a start. As soon as we all agree on a heirachy (group and list of tags) for both routes and areas I will make the database config change. There is room for icons associated with tags, so that is just a process we have to go through.

[lordyavin]

Oh I see we already have a "condition" group as child of "route character". We should be careful not to mix it up. I understand your point about "good" conditions. I think without a "condition" tag the crag/route is implicitly climbable.

Maybe the destroyed tag fits into the access tags. If a route or a crag is destroyed it is not accessible any more.

[brendanheywood]

Additionally destroyed routes should not be listed in PDF guides or the Crag Guru.

I think we should leave this for the time being for the PDF's, many guides include them on purpose and I think the index and the pdf's should at least be the same. Crag guru I agree should not suggest them, but I'm ok with leaving that for round 2, we need to make sure that query stays super fast for normal crags with nothing removed.

[brendanheywood]

I think since the last update we implemented the archive flag for gym routes which could be repurposed here.

But I think another alternate and superior implementation would be that we have another type of historical event in the same vein as set / fa / ffa / maintained (see #1865) ie 'removed' - this appeals to me as it covers the whole cradle to grave life-cycle of a route using the same data model. It's better than a tag as it has an optional partial date for when the route was destroyed, and you can also put in who destroyed it (if that makes sense) and other comments. It also means we get a few things for free like sorting a list of routes by important historical date. We don't yet validate that ticks are after the FA date, but when we do the logic for validating that it is also before the removed date would be consistent too.

[lordyavin]

Hey there. Anything I can test? I'm still missing the sign in the route/area list for closed/prohibited climbs and areas.

[lordyavin]

BTW it is still not possible to use the proposed unicode character in the title. After saving the title is empty.

[scd]

yeh I know, sorry

[brendanheywood]

• [ ] https://www.thecrag.com/discussion/1244807922/cohiba--cohiba-development

[brendanheywood]

+1 from support email re:

• [ ] https://www.thecrag.com/climbing/australia/grampians/mt-william/area/12999151

Apparently this area is not so much 'removed' as just the fires turned it into a pile of choss. So whatever we do for removed routes could do with a softer variant for simply degraded routes. Thinking about stars and grades there is some overlap the route history issue (https://github.com/theCrag/website/issues/1865) because we might reset the stars or grade so that a once popular but now choss route doesn't show up in icons or quality searches

[brendanheywood]

• [ ] https://www.thecrag.com/climbing/australia/mountain-quarry/area/12141613#n2561209239

[rouletout]

Currently we use "closed" for this along with a description why which seems to work fine, closing