Numbering of routes starts with 2

killakalle commented 4 years ago

What happened? The actually first route in a crag is now listed as 2. Thus the counting starts at 2 instead of at 1.

Example url(s) to reproduce the problem: https://www.thecrag.com/en/climbing/spain/valencia-cuenca-area/area/2561079678

Ideally also provide screenshots:

What you expected:

[ ] Route count starts at 1

scd commented 4 years ago

We have had to fall back to internal index numbering where annotations are included.

If it gets confusing then we will add the number on annotations.

On Tue., 1 Sep. 2020, 5:41 am killakalle, notifications@github.com wrote:

What happened? The actually first route in a crag is now listed as 2. Thus the counting starts at 2 instead of at 1.

Example url(s) to reproduce the problem:

https://www.thecrag.com/en/climbing/spain/valencia-cuenca-area/area/2561079678

Ideally also provide screenshots: [image: image] https://user-images.githubusercontent.com/30682796/91759770-84174b00-ebd2-11ea-9bc1-67ea89cc8c0f.png

What you expected:

Route count starts at 1

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/3753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC3CQVMOW3GXM47QUIA3W3SDP4FTANCNFSM4QQ3YZYQ .

killakalle commented 4 years ago

To me, it's a little confusing. What do you think when you see a list that starts at 2? Given that sometimes not all routes are drawn on topos, as a user I might be thinking that route 1 has not been drawn and start looking for it

Adding that "missing" number to the annotation probably does not help. To me, annotations are like headings. They are bold and are of a different type than routes. If annotations are numbered, then they should be consistently numbered within their type.

e.g. Routes follow one numbering, annotations follow their own numbering (or don't have numbering)

1 Long

2 Route A 3 Route B 4 Route C

5 Section Short

6 Route D

vs

1 Long

1 Route A 2 Route B 3 Route C

2 Section Short

4 Route D

I'm just giving feedback as a user who is not aware of how you deal with these numbers in the background. Just saying that it looks odd. Well, it's not anything urgent as no actual information is missing. However, it seems that this is quite a visible issue that strikes instantly.

scd commented 4 years ago

I have had to make a simplification in order to progress the code base. The core simplification was to move the numbering back from being dynamically created in the template to being server generated. The old way of doing the numbering had become a complete blocker for several issues. For example:

Preparation for topo data being shared in an app development
Re-establish PDFs
Remove a serious issue with having to keep multiple topo algorithms in sync.
Remove the requirement for topo render template to have access to the database

Internally the system works using an index of nodes with a parent/child relationship where a node can be a route, area or annotation. These have a sibling order stored in the database. The old way of doing things calculated the topo route number based on annotations being excluded for counting, but routes and areas being included.

If there were no annotations then the sibling order matched the topo numbering. So I made a pragmatic decision to use the sibling order as topo numbers. This is a small regression but save's a whole lot of new code base being introduced.

The alternative was to use to introduce a new database field. However there is a huge amount of work keeping this in sync with reordering, reparenting, deleting and merging. The existing field is already managed to keep in sync.

This is not something that is going to be undone as it is completely necessary. We do not have the dev resources to keep the numbering as before. Maybe long term we can, but not in the short term.

We can put a number on the annotations so it is less confusing.

scd commented 4 years ago

@killakalle I think it is worthwhile explaining the background to the change because you are doing such extensive issue logging and testing on the site. I want you to understand the nature of the regression. I agree with your sentiment, but there is deeper context to this change.

georg-d commented 4 years ago

I also stumbled several times across the list starting with 2 instead 1. Thanks for sharing background info; I understand and see the potential benefits clearly outwight the current issue.

+1 for the quick fix to show numbers on all elements as that would avoid users are confused or assume lost/invisible data. For my feelings, it's neither elegant nor ugly/bad, so I could also live well with it in the long run - maybe with the slight adjustment to rename the table heading from "Routes" to "Child elements" or "Contained elements" because it's not only routes but also annotations, sectors etc

For a more elegant solution in the long run: How much effort would it be to show the numbering as @killakalle suggested by either

adding front side code that takes the current technical numbering from the backend as a base but transforms it into a semantical numbering (only used for display purpose not for communication with backend), i.e. iterating all child elements, for each element increment the numbering counter for that element type (annotation, route, area). Drawback: Needs to be done in each client, so redundand coding & testing work and possible differences in behaviour of different clients.
changing backend code that it delivers not only the current technical id but also/additionally an semantical id for presentation / UI (would a new field be ignored by unchanged front ends i.e. not cause errors?). So we had two fields, just like in HTML you have
```
<select name="Pizza">
  <option value="P101">Pizza Napoli</option>
  <option value="P102">Pizza Funghi</option>
  <option value="P103">Pizza Mare</option>
</select>
```

killakalle commented 4 years ago

@scd thanks for the explanation. I can live with how it is.

Though, it seems there is more broken with the numbering. At least annotations do not explain this case, that I've just stumbled across. There are no annotations in this sector and the route numbers go:

2, 3, 5, 7, 9, 11, 12, 15, 16, 17, 18, 19

Mestre de melodies

Also here: L'Horta vertical

PS:

because you are doing such extensive issue logging and testing on the site

I was wondering whether this had a positive or a negative connotation?

scd commented 4 years ago

Positive connotations.

There looks like a bug with this area. I suspect merging 'el wisionario' with 'la herboristérica' has left a gap in the numbering. The system should be reorganising itself after a merge, but it looks like it has not. Nice find.

scd commented 4 years ago

I have fixed the merge bug and corrected the index sequence. Please let me know if you find other examples with numbering not right and no annotations.

killakalle commented 4 years ago

@scd Here is another example. I've noticed this after doing some restructuring (adding new sector, moving routes to other sector, ...) https://www.thecrag.com/en/climbing/spain/chulilla/area/611534493

Numbering starts at 9

scd commented 4 years ago

Do you know which operation left the numbering behind?

For example next time you move routes from the beginning of the list please take note on what is left.

On Wed., 7 Oct. 2020, 7:49 am killakalle, notifications@github.com wrote:

@scd https://github.com/scd Here is another example. I've noticed this after doing some restructuring (adding new sector, moving routes to other sector, ...) https://www.thecrag.com/en/climbing/spain/chulilla/area/611534493

Numbering starts at 9 [image: image] https://user-images.githubusercontent.com/30682796/95258448-1344fd80-0826-11eb-8ee7-bb9639baca4f.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/3753#issuecomment-704544767, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC3CQRXFPHYW5WXIIXNF23SJN7GLANCNFSM4QQ3YZYQ .

killakalle commented 4 years ago

To be honest, hard to tell this time. It was a strange combination of actions:

I believe I carried out the following actions on the affected sector:

Move the first 8 routes from Sex shop to Tierra de Nadie. Not sure if related, but the routes were drawn on topos like this:

Route 1 - Not drawn Route 2-7 - Drawn on Topo A Route 8 - Drawn on Topo B

Topo A was copied with the routes to Tierra de Nadie and looked all fine. When I checked Sex shop the topo was missing and I was already afraid that I had messed up something. Route 8 was part of Topo B and the only route moved to Tierra de Nadie.

Luckily I found Topo B again when going into the Topo admin of Sex Shop. I then reparented Topo B to Sex shop and it was visible again. However, all the numbers in the boxes at the start of the routes were messed up - not just like wrong numbering, e.g. starting from 9, but really messed up, so that it didn't make sense at all, and that I couldn't read it. Unfortunately, I don't have a screenshot for it.

I then decided to remove Route 8 from Topo B because I anyhow had moved it to the other sector (Tierra de Nadie). That then "fixed" the topo numbering and showed normal numbers - just starting from 9 instead of 1.

So, here's your summary. I am not a 100% sure everything was done exactly like described, but more or less like this.

PS: Just noticing that 'Topo B' is not mentioned as updated in the stream event. It's missing: https://www.thecrag.com/event/3900364062

Topo A: https://www.thecrag.com/en/climbing/spain/chulilla/area/3900832614/topo#t2289667641

Topo B: https://www.thecrag.com/en/climbing/spain/chulilla/area/611534493/topo

killakalle commented 4 years ago

@scd Just discovered the following topo. The numbering in the topo image looks quite similar to the last issue I described in my previous post above. Is the numbering intended, e.g because the routes in the topo are from different sectors?

https://www.thecrag.com/es/escalar/spain/valencia/area/260450256/topo#t3080431704

scd commented 4 years ago

The ? in the numbering is because the routes are in a different sector. We are currently not sure how to number routes in topos from different sectors and we are not sure that it is a valid use case to have routes in a topo from a different sector. We need some valid use cases to work with to get through this issue.

In this case I think the topo should just be moved to the correct sector.

quaestor commented 3 years ago

This is especially bad with respect to #2960. "Deleted" annotations nevertheless increase the numbering of the routes. You can add an arbitrary number of annotations, then "delete" them again and in this way create a totally random numbering scheme.

killakalle commented 3 years ago

@scd

Found another example https://www.thecrag.com/es/escalar/spain/bellus/sector-verano

I've just inverted the sequence of the routes using the "Invert" button on the Reorder view. Can't say for sure whether this caused the issue, as I was not paying attention before.

rouletout commented 1 year ago

theCrag / website