website icon indicating copy to clipboard operation
website copied to clipboard

Messy topo order

Open Arzorth opened this issue 2 years ago • 1 comments

I'm editing rather complex series of topos and the behaviour regarding the order in which they are shown is not as expected.

Parent view

https://www.thecrag.com/en/climbing/spain/patones/area/350653239 image

The expected order is:

  1. TOPO #4452844545
  2. TOPO #4452844539
  3. TOPO #4452840900

While the first one is kind of obvious (it contains the lowest indexes of the sub-areas of both first and second current-level-areas), the second and the third are not that obvious, the reason they should be in this order is because they start with the same sub-areas (both 'Repisa del Stradivarius' [1.10] and 'Gominolas Central' [2.4]) but TOPO #4452844539 finishes first (with 'Viejo Charlie' [1.13]) while TOPO #4452840900 finishes later (with 'Perejil' [1.15])

Children views

https://www.thecrag.com/en/climbing/spain/patones/area/6407394459 image

In this case, the order is as expected (as mentioned previously) but both TOPO #4452844539 and TOPO #4452840900 should appear on top of the sector 'Repisa del Stradivarius' and not in the upper most part of the page as they are being shown currently.

https://www.thecrag.com/en/climbing/spain/patones/area/6407399862 image

In this other case, the problem is the same, both TOPO #4452844539 and TOPO #4452840900 should appear on top of the sector 'Gominolas central' and not on top of the page.

Conclusions

✅The system should take into account the current-level-areas to position and order the topos. ❌In case of having the same current-level-areas, the system should check the sub-areas to order the topos, if no sub-area is present it should order by an arbitrary criteria such as topo ID or randomly. ❌The system should ignore the upper-level-areas and cousin-areas to order and position the topos.

Regards!

JositoGG

Arzorth avatar Aug 08 '22 07:08 Arzorth