Should we make topo order explicit instead of automatic?

[brendanheywood]

Two slightly overlapping topics here:

• I've been thinking and experimenting and playing a lot with #859 which is how we interleave the topos into the routes. I think I've come up with a ok-ish algorithm but I'm starting to think that I'm over thinking it, and perhaps the best solutions is to just make topos like other nodes in the child list like annotations, routes and areas. I've found a couple examples where human judgement will always triumph. If we do this, we'd simple bake the current interleaving order into the current mix and then let people evolve it from there, reorder using the existing re-order process. I see lots of pros and cons for this and just wanted to gauge others feelings on it. I think for most people, the way it works now is kinda voodoo. If we go with this then we won't mess with the order of nodes in the templates like we are now. I'm coming up against this now in my list of test cases where I'm shuffling certain types of topos to the top of the list, like area topos, but the list of rules and edges cases is getting overwhelming and starting to smell like it's not tenable any more.

• In theory it shouldn't happen much but where routes and areas are mixed, we'd need to show them as-is eg:

  http://dev.thecrag.com/climbing/australia/arapiles/king-rat-area/area/11962291

If we go ahead then this becomes a data issue not a code one. We could do a report to highlight the areas with intermingled types to clean up manually.

I'd like a bit of direction for this, because if we're planning on doing this eventually I think I'll hold off on the client side solution, and just stick with the existing server side impl for now.