Add a 'Machine' field

[kimble4]

Adds support for a 'Machine' field to CrossMgr, SeriesMgr and CrossMgrVideo, for sports with an engineering aspect to the competition. (See #50.) I've used 'Machine' as it seemed like the broadest term that would encompass bikes, trikes, velomobiles, pedal cars, wheelchairs, soapbox racers, skateboards, etc.

In CrossMgr this is a single line of code :) All it does is allow a 'Machine' field to be imported from Excel, and displayed / outputted as appropriate.

The changes to SeriesMgr are a lot more involved. The field is handled broadly like 'Team', with its own aliases and so on. Where a rider uses more than one machine over the course of a series, they are ranked in order of frequency and pretty-printed in an appropriate manner.

CrossMgrVideo accepts the 'Machine' data from CrossMgr and stores it in the list of triggers (this is particularly useful in HPV racing where the design of the machines is the primary identifying feature). It's also added to exported photos, when present.

[esitarski]

This code will crash running on an existing database.
There needs to be a check if the "machine" field exists, and to do an "ALTER TABLE" command if it doesn't. Something like:

if 'machine' not in col_names:
    self.conn.execute( 'ALTER TABLE trigger ADD COLUMN machine TEXT DEFAULT ""' )

I understand the use case for Machine, but it is not important to most cycling race users.
Unconditionally including it increases complexity, possible confusion and takes up screen space.
There should be a way for the user to select/sequence what fields are shown in the display.
"machine".
Controlling the display fields would be help the existing interface as some of the current fields are not used even for all cycling applications.

[kimble4]

Ach! Good point about the CrossMgrVideo database. I didn't think to test that.

I had wondered about column bloat, particularly in SeriesMgr where things can already get very wide. We don't use the 'License' field, and are only currently using 'Team' to store the machine name, so it would be nice to be able to hide those too.

CrossMgr's 'Results' page only shows columns for which data actually exists, which works well enough (during the race you only really care about 'Pos' and 'Bib', anyway). But being able to selectively hide or unhide columns would be even better. CrossMgrVideo in particular has several columns that might contain data but not be of interest at a given time, in a relatively small amount of screen estate.

I'll add the database check and have a play with hiding columns...

[kimble4]

Only done CrossMgrVideo so far, but that gives a popup menu when you right-click on the headers to toggle the columns on and off. As wx.ListCtrl doesn't have a more elegant way of doing this, it's just setting the column width to zero, which avoids having to re-calculate the contents (I'm thinking that could be slow in SeriesMgr). Column state is saved in the config file.

[kimble4]

A bit different in SeriesMgr: wx.Grid supports hiding and showing columns, which makes this simpler to implement. I've provided the same type of popup menu to manually toggle columns. More elegantly, I've made it hide any empty columns by default after refreshing the Results, which is nearly always going to be the Right Thing. You can hide any of the columns if you want to (eg. to save scrolling on a small screen) , but persisting a hidden race results column could be confusing, so the state isn't saved and they'll reappear when the results are refreshed. Similarly, Team Results now allows columns to be hidden, but they also reappear when refreshed.

I've moved all the SeriesMgr aliases settings tabs to a sub-group, which cuts down the horizontal tab bloat. Name aliases are now handled in AliasesName.py, for consistency.

I've added simple toggling of columns to the labelGrid in the CrossMgr results page too, but I'm not sure if this is particularly useful...

[esitarski]

I spent a significant amount of time reviewing these changes but I have not merged them yet.

I am having second thoughts about including this feature into the general release.

Can you explain how an additional Machine attribute solves the scoring problems for HPV?
Why doesn't the existing Category field work?
I read the International HPV standards. The categories appear to be somewhat similar to ParaCycling.
What am I missing?

I admit that I don't know much about HPV, and I respect that it defines itself as "not cycling".
However, I need to consider the needs of 1,000s of CrossMgr users in cycling.
I can't think of a use for a Machine attribute in cycling or Para-cycling (which uses Categories to accomplish this).
Can you help me here?

Para-cycling goes further with Ability Factors that allow combining categories into an overall result (Ability Factors are supported by CrossMgr).
Would this be of interest to HPV?

[kimble4]

CustomCategories do everything we currently need for the scoring, tbh. In scoring terms it's mostly about freeing up the 'Team' field for future use.

Scoring aside, our participants are generally interested to see what people are riding in the results. (I can't vouch for other nations' HPV organisations, but the BHPC is a cycle enthusiasts' club with pockets of competitiveness - apart from a few riders at the sharp end of our Open, Unfaired and Arm-powered classes, most of us are more interested in our own performance, or simply having fun, than where we place in the championship.) Having the machine shown in historical results makes it easier to compare a given rider's performance over the same course on different machines, that sort of thing...

We're currently abusing 'team' to display the machine name, which is fine in CrossMgr's output, but SeriesMgr only shows the rider's last team (you can see I've made it list all the machines where more than one is present).

Frankly this feature was always a nice-to-have, and I didn't expect to spend nearly as much time on it as I did. (Hiding and showing columns was a rabbit-hole, but I'd hoped a useful one - there must be plenty of smaller organisations who aren't using the 'team' or 'licence' fields, and I'd hoped this could be developed further to make columns selectable on the fly in the SeriesMgr HTML output.) I've learned a lot about wx and data structures in Python, anyway.

As for the use of a machine field in conventional cycling competition, the late Mike Burrows (famed cycle designer, founding member of the BHPC, and never known to be short of an Opinion) would probably say something to the effect that racing cyclists have long since forgotten that their job is to sell bicycles :)

[tjsr]

FYI - I know this is a very old issue now, though it didn't seem to be merged to master yet.
The term we would often use in both motorsport across the world and HPV racing in Australia to cover this is 'Class', which is more sport-agnostic. For example, a race might be for Entrants in the HPV and Hybrid, whereas the Class might be HPVA, HPVB etc. In Hybrid racing in Australia (HPV racing using multiple energy sources, including petrol, electric, regenerative etc), they would have classes for those kinds of things.

In Motorsport an example might be that you have a Category of 'Formula Ford'/'FFORD', whereas the Class is FF1600/FF1800/FF2000 for the different engine capacities, or 'Formula Libre' where the Class is 'Formula Vee', 'Formula Ford', 'Formula Holden' etc, or 'Sports Sedans' as the Category, and then you then have 'Group A', 'Group B', '2 Litre' etc for the class.

In cycling, the main use has been in UCI events where Under 23s might be classified as Elite and don't get their own category, but we still want to denote them on the results. Similarly in events where we only offer 'Open' as the category, we might still use 'Class' as their eligibility category (eg, Masters 1, Under 23).
We have also used it in a way such as the Category being 'Adaptive', but within that you might have various conditions for the class - but it's not so common in cycling to be used this way. At times we've also used it in 6hr/24hr racing for things like 'Teams', where the Class is then a further breakdown that perhaps we don't recognise as its own race/classification but is nice to know (eg, Pairs/Triples, perhaps Men/Mixed/Women or more specific Junior categories where you might only recognise Junior, but still want to provide that as informational only). Para would be another use-case for Class.

Hope this helps.