Site Improvements

Improving the database

We have received many, much appreciated, reports of errors in the database, and members who would like to moderate crags. A big thanks to everyone who has offered their help, and apologies for underestimating the time it would take us to provide the moderators access.

We have today added a new functionality, which allows you to report a spelling mistake of a route. This is a first step to (finally) involve all 8a members, while we wait for the moderator access to be ready. The button is on the top right on every route page. The suggestions will end up in the database, and if it gets approved, it will go live within approx. two weeks. When in one crag, two routes have the same name and the same grade, we merge them as well. Thus, this is a fairly quick way of cleaning up a crag, and getting rid of spelling errors in your logbook without having to create a new route. Once the individual crags have fewer duplicates, our algorithms are prepared to catch duplicate crags and merge them.

If we get spelling suggestions that we cannot decide on, I will post them in the forum to get more opinions, or directly email members who have offered to moderate the relevant area.

Our priority with regards to the database until now has been on two things: facilitate as much as possible adding ascents and searching routes, to avoid further creation of duplicates, and fixing "obvious" duplicates using algorithms. The fewer duplicates there are, the easier it gets, so we tried to start with the low-hanging fruit. In doing so, over 280'000 duplicates have been removed since the relaunch. If identifying and removing a duplicate takes a human even just 10 seconds, that is more than 750 hours of manual work. Time we all would like to spend climbing :)

The duplicates that remain have for one reason or another been considered too risky to be a false positive for us too merge, so now receiving spelling mistake reports will help us carry on with improvements.

Thanks a lot to everyone who has been in touch with feedback and comments, it’s appreciated. 

If you have any comments on the spelling suggestions feature, please get in touch with me directly (ben@vertical-life.info) or write here.

Cheers


Hi Ben. What if duplicate route names were not merged?!? For example, crag 'Galerie', route 'Abstauber'. This is duplicated, one in sector 'Wand im Wald' (correct), the other in sector 'Wald' (as it is sometimes also called). Cheers, Marcel

Hi Marcel, Abstauber was not merged until now because 1) both routes in the db have many ascents and 2) the algorithm doesn't know which sector should win because none of them is in the "unknown sector". It'll be merged Wednesday. In general, these duplicates will have to wait until we have the moderator tool. Thanks!

Hi Ben. Thanks for the quick reply. I understand the issue with the sectors. Actually, that's quite a big mess. Whereas there is mostly a unique name for a route, this is already less obvious for crags (different topo editors may call entire crags with different names) and it is even worse with sectors. In the case of Galerie, this is definitely the case, there has never been an agreement for "official" sector names. In this particular case, "Wand im Wald" and "Wald" are the same (i.e. the Abstauber problem exists for a few more routes). It remains unclear which of the two is the correct nomenclature. However, it's actually even more complicated, since this sector which is in the forest itself can be subdivided into 3 subsectors. But if you do so, there's even less clarity about how these should be named and for some routes, such subsector nomenclature already exists (e.g. Wald links). After all it boils down to the problem what a sector resp. a subsector is and the database currently has completely different granularities (e.g. also for Hauptsektor, for which e.g. Matrosen, Ikarus and a few more are present as subsector names). Hope this helps you in setting up the process of having a clean database. I fear that without clear definitions of what a crag and a sector is, it's hard to clean up consistently.

Why there are multiple routes in the same crag with the same name and grade in the route database? For instance Sivnica; Košutnik direkt; 6b (the same goes for Spaceman)...

Ben Lepesant
In reply to Martin Bombac

Two Sivnica crags were just merged today, so in that case, I think that the route merge was not done yet - it will be done when the next changes go live.

Hi Thank you very much for the new implementations! I would like to point out the case of Finale (Italy) which includes a large cluster with 2876 ascents and 1380 climbing routes all attributed to the "Finale" area which contains routes referring to Unknown Crag and Unknown Sector. Same thing for "Arco" with 3787 ascents and 2503 ascents. Probably you already know :-)

Ben Lepesant
In reply to mde

Hi Marcel, Thanks for your thoughts! The structure (Country-[Area]-Crag-Sector-Route) of 8a comes with its challenges for sure. There is probably no one-fits-all solution. But discussing these matters is definitely a good idea.

About the '1 thing - many names' issue: We intend to allow more than one name for an entity for when the moderator tool is there. So you could merge the sectors 'Wald' and 'Wand im Wald', and have two names in the database, a primary one, and a secondary one. This would solve the issue you are describing, right? Re. your comment about the subsectors, do you think that adding a subsector between Route and Sector would be helpful? My first intuition would be that this would only be useful if subsectors added valuable information. Even for sectors, when they are really needed to know which route you speak of / where a route is, they should often actually be crags (E.g. Ötztal, a 'false' crag that has sectors that are actually crags -> instead of introducing subsectors, the way to go in my opinion would be to make Ötztal an area, things like Niederthai a crag (instead of sector) and Steiler Block a sector.) But maybe there are examples where subsectors would make sense? 

The "crag" entity is the most 'visible/useful' entity on 8a - it's the only entity with Description / Access / Coordinates that members can provide without being moderators. In this context, it might make sense to say that as a general guideline, when in doubt, something should be a crag, until there is a clearly better place for it. We can fairly easily merge crags or turn them into areas to avoid having huge crags with hundreds of sectors that are km apart. It would be good to have a community discussion about the areas, because defining them is tricky (which is why we haven't done much there yet). 

The current way of searching the website and adding ascents doesn't really depend on the sector/crag/area structure. At least that is the goal. The idea was that the "clearest" object is a route/boulder name (+ if needed crag / area for more precision), and so if this is known, knowledge of the often very "organic" structure above should not be required to find something. The issue with the duplicates is most relevant for legacy data that was created when it was easier to create a new sector and a new route than it was to find the existing match. Hopefully that is now not the case anymore! 

We would like to allow local moderators to set up a sector structure in a crag once we have the moderator tool, and then merge the routes and put them in the right sector. I agree, we definitely need some guidelines for these procedures to have a good structure in the end. But I think that the primary goal should always be that 1) adding ascents is fast and requires as little knowledge about the area/crag/sector name of the route as possible, and 2) when creating new routes it is easy to put them in the right place and not unintentionally create duplicates. This is what will impact the future state of 8a the most. If you have ideas on how to improve these things, please let us know!

Ben Lepesant
In reply to Luca Ghiardo

Hi Luca, yes, emptying the unknown crag / unknown sector is (high) on the list! For now, the best thing to do would be create a new route in the correct crag and sector, rather than ticking the unknown crag route - this would allow us to merge the two routes in the correct place.

Hi Ben

I really miss the "sort routes by index" from the old page while looking at new areas. It somehow included all the other criteria (stars, ascents,...?) it was perfect to find the popular and good routes and sectors. Sorting by stars I only find 100 % 5-star-rated routes... with one ascent. Thanks!

Hi Simon, it's indeed pretty useless to sort by stars in most crags... We have considered coming up with a more complex "quality" sorting, and I am sure there are many ideas on how to do this, which I would be happy to hear about. However in many crags, the routes most people would look for (high quality, "convenient" style and grading, accessible, safe) are also the routes that have most ascents in that grade range - which is why we feel like it was difficult to make a significant improvement from allowing filtering for a grade range, and sorting by number of ascent, for many cases at least.