UKC

At the top of all logbook pages (i.e. My Logbook, or a crag) you can use a powerful new search feature to find routes or crags. The unified search box allows filtering of routes based on multiple criteria.

Read more

Great stuff, should be very useful.

The pink text on grey background (dark mode) is very hard to read though. Poor colour contrast, especially from an accessibility perspective. Hopefully that can be adjusted so people with impaired vision (and others!) are able to read the details.

This is well cool! New favourite search

leonidio |soft| 8a

sweet !

This is an excellent feature, thanks for adding. 

Can you define the regular expressions in some sort of help page as people who aren't into computing won't know what they can and can't use.

Tautology

To be honest, as a self taught developer, RegEx took quite a while before it wasn't mumbo jumbo anymore. This site helped me learn a lot: https://regex101.com/r/eYVxP9/1

As mentioned though, we don't offer pure-RegEx queries. We'll try and put some more examples in the help text.

Thanks, we'll sort that out ASAP.

Looks good.

The text in dark mode is a bit hard to read.

No comment, but that screenshot’s a corker of a ticklist.

Even when you're good at it, a nicely crafted efficient regex becomes mumbo jumbo 6 months later.

Bit of a feature request, but I think it would be cool if there was a search results page rather than having to rely on the drop-down. The new search makes it super easy to find a range of climbs (e.g. *** vs-hvs on Burbage) but it's then tricky to explore more than one at a time as you lose your search when you click on one of them.

Good call! We'll look into that next week.

That's great, sounds very powerful. I just want to add a comment of how I'm always getting confused and always clicking on the grey button (if dark mode) 'Advanced Crag Search" (underneath search bar if on mobile) by accident after I've typed search terms in the search bar as I automatically think the grey button represents Enter to search for the terms I just typed in, but it instead takes you to an Advanced search page and also clears the search terms you just typed in. I understand you're supposed to just click on the search result when it comes up in dropdown but I keep forgetting and automatically clicking on grey button. Would be interested to know how many other people get confused by this?

That's great. Expect it to crash in the next few hours with everyone trying to fool it!!!

Are you sure you have tested this properly?

I keep putting in "Three Pebble Slab VS 4c" and it's not coming back with anything?

Love it!

I'm pretty sure we've tested it yes. There are always little things to be ironed out with new features of course. Can you link to the route you're expecting to find and we'll look into it. 

I think he's just pulling your leg, the joke being the never ending grade debate about three pebble slab.

Does this not work for routes prior to them being checked by moderators?

I have searched for a route I added a few weeks ago and it fails to appear.

Ah right. Went way over my head that one

The search happens in a sidecar database which has to be synced with the main one. Most likely the cronjob that does the syncing isn't working because we've never verified that. I'll have a look and get it fixed. 

Nice, looks like a lot of work has gone into this. How have you implemented the search, out of curiosity? 

How can you distinguish between grades? ie VS brings up both VS and HVS as does "VS"

likewise searching 8a/"8a" = 8a 8a+ 8A and 8A+

also 8a -"+" or 8a -"8a+"doesn't seem to remove them?

There's a big difference between soft 8a and soft 8A+!

Grades get treated a bit differently to stars. If you type **, it gets translated to a star-value, so it only checks that field. Grades only get translated to grade-values inside a grade range, so to get what you want you'd have to enter "8a-8a", which is perhaps not that obvious. Plus I never documented it anywhere...

This was a conscious choice (although I'm not married to it). Because there are so many grades I didn't want to create unexpected side effects. Eg Aussie grades are just numbers, like 23 or whatever. Translating any token that matches any grade into a grade-value would mean that you'd not be able to search for eg "levitation 29" without quoting it, which I decided was more confusing than having to write a grade range with the same grade twice. 
 

Currently I stand by that trade off, but I'm open to persuasion. 
 

I'd considered the fact that bouldering uses capital letters but is otherwise the same as French grading. I could add some logic to detect "8A" or whatever, then only match that against boulder problems, but I think the simplest way is to include a route-type token in your search like "sport" or "bouldering". People would still expect "8a" to match a boulder problem, so again it's a trade-off. 
 

As an aside, why anyone would design a new grading system and use the same tokens as an existing one is beyond me, but this is far from the only example. 

It's a fairly standard postgres db with a node api in front of it that parses the query and generates the sql used to fetch the matching rows.

The fast-ish performance comes from carefully chosen indexes and a caching layer that means when you type eg "stanage" then expand it to "stanage plantation", the second search will only search within the subset of routes/crags already matched by the first search. This can in many cases dramatically improve searches from taking a couple of hundred milliseconds to single-digit milliseconds.

There are some other optimisations around using heuristics to decide if the query is really vague, ie would return many many matches, and if considered vague then try first limiting the searched fields to a subset with the most obvious ones (name, area etc). I've got some ideas about improving this further but not got round to it yet. 

This is great.  Particularly enjoying browsing lists of first ascents by typing in names of friends and/or heroes.  Very minor thing but associated question; is there a trick to limit the search to the 'FA' field?  Seems to be working really well as is but, for example, if you search 'Dawes' you get most/all(?) of Johnny's FAs listed but also routes/problems with dawes in the title (of which there are quite a number).  Obviously filters well if you search 'Johnny Dawes' but then maybe you'd miss routes listed as FA by 'J Dawes' or potentially typo'd entries like 'Jonny Dawes'?

Also think Remus' results page feature request would make it even better.

Currently there isn't but it'd be easy to add. We'd just need a decent syntax for it. 

{J.Dawes} 

{J*.Dawes} 

{Jo*.Dawes}

{Dawes} 

ignoring case of course

We've added some new syntax to allow this type of thing.

The design allows you to restrict tokens to certain fields. These only affect routes, searching for crags works as before. If you use any of these new syntaxes you will be restricting your search to routes implicitly. The possibilities are:

• fa(littlejohn) restricts the match to the first ascent field

combining multiples of these creates a logical OR, eg 'fa(littlejohn) fa(harrison)' means it will return routes whose fa matches either of these tokens. I might add the possibility to create ANDs using a comma, but that's more complicated eg 'fa(littlejohn, harrison)'.

• c(curbar) restricts the match to the crag name field. Again, multiples make ORs.

• r(brave new world) restricts the match to the route name field. Note that this creates one token, much like double quoting "brave new world", but now it will only match the route name. Multiples create ORs again.

• g(8a) restrict the match to the route grade. Multiples create ORs. The match has to be exact (ignoring case), so 'g(8a)' will not match a route graded 8a+, nor will it match a font 8A because these have the notation f8A, so if you want that you'd type g(f8a).

I don't really foresee much need for crag name and route name but who knows. This hasn't been heavily tested so please let me know of any issues.

Edited to add: you can also negate any of these, eg 'fa(littlejohn) -fa(harrison)'

Ah that's great, a brief kick of the tyres suggests it's working perfectly.

Nice one, thanks for taking the time to reply. I was wondering if you had used Elasticsearch/OpenSearch

Those things are pretty heavy duty and not that easy to set up. But they also work better for searching freeform text, rather than creating a very targeted search like we've got here.

They handle synonyms and suffixes I think, eg 'climbing' will match 'climb' and 'climber' too, and mis-spellings, but we specifically don't want that for route names which can have purposefully odd spellings.

Someone else mentioned mis-spellings above asking for it to be added, but it's not something I'm keen on here. I prefer to deal with things you're not quite sure of the spelling of by only entering a fragment of the word, eg if you're not sure if it's 'dawes' or 'daws' just write 'daw' and fine tune based on the results you get.

That doesn't help if the data has been entered incorrectly as 'doors' or whatever in the db, but like everything with search it's a tradeoff, and I prefer a search that returns what I'm asking for than one that guesses what I want.