Pilot name is not unique.

[philderbeast]

In the *.fsdb the <FsParticipant id="8" name="Gordon Rigg"/> is not unique by FsParticipant/@name, see https://github.com/kuaka/fsdb_igc/issues/2.

airscore/data/tracks
└── 2017
    └── forfla17_5
        ├── t1_20171230
        │   ├── gordon_rigg_2017-12-30_01.igc

Please add a test to ensure we can have two pilots with the same name in a airScore comp and that we can import from *.fsdb and upload tracklogs from an FS comp that has two such pilots.

[kuaka]

ok. we can't expect that all filenames have an ID number in them just to avoid the extremely rare case that there are 2 pilots with the same name. (what was the case here? jnr & snr?). It would inconvenience many for the benefit of the few. I think that the best we could do it check if there are more than one pilot with the same name and then not import files based solely on name automatically. Leave it for the scorekeeper. @biuti thoughts?

[biuti]

IMHO pilot.ID should become mandatory, as it is in all events. Even if it's not on gliders or known by pilots, in every comp you get an ID as you are confirmed in the event. This makes it extremely easier even for track recognising, as xxxx.[INT].igc will be the ID and would be no necessary any other check on name. (xcontest is another story but it is already coded, works well and will be disabled for FAI). So, the idea is that pilots list will be mainly imported through FSDB or excel file, either will have ID. pilots imported with no ID will get first free number over 100, scorer gets a notification and can change it if willing to do so. This would be easy and probably will also simplify all recognising tracks code we made to cover all possible tracks name combinations.

Also, when importing tracks, created filename would be name.date.index.ID.igc, so unique names wouldn't be an issue here. I think this could be fast, but I always think it would be. Let me know. At the moment I'm testing FSDB importing than scoring, and I still have to think how to cope with classifications.

[kuaka]

Making ID mandatory would solve for duplicate names. I think it is the only number that can be enforced mandatory as not all pilots have CIVL ID etc. Is it mandatory in FS? if not we can't expect to be able to import using that.

When importing tracks however, I would be against making it mandatory in the filename. When bulk importing, it usually means that the files have come from another system and we can't enforce what those other systems do. To ask a scorer to rename each file defeats the purpose of the bulk import. I will add the pattern name_name_id.igc to defines.py and modify my script fsdb_igc to create this format unless id is missing.

[biuti]

FS is using ID to identify pilots, so it is always there. But in general each comp have pilots ID.

The code to detect tracks is already there and working quite well, but compcheck, FS and Flymaster live use that format, so I guess that having ID mandatory and making that check for first, most of the time will result correct.

I think the pattern is already there, as used by most of sources.

[kuaka]

Just to be clear, if it is made mandatory it will have to be autogenerated as you say if not provided. The last thing we want is more friction for the organizer. If there is a fun comp and they haven't thought about assigning ids it needs to be generated in the background.

I have added the pattern name_name_id https://github.com/FAI-CIVL/FAI-Airscore/commit/0d6bfe6f4595cf458df45e7af7cbe706f65504b4 Question: what does the import prioritize? is it name or id? so if we have 2 tracks: joe.bloggs_123.igc and joe_bloggs_456.igc will it be guaranteed that the tracks go to the correct pilots or will it use the name and find the wrong pilot?

[kuaka]

I think I have answered my own question. the tracks that had 3 part names like "

	Jon Durand Snr

" still are not imported. If it was using id first it would have been imported and the name ignored.

[kuaka]

reading the code, it wants to use id if possible and falls back to name. but it also wants the number of elements to be as specified so a 3 part name is the issue.

[biuti]

I pushed a commit that makes ID always present and unique, https://github.com/FAI-CIVL/FAI-Airscore/commit/a9fc79bab89f1408fb0b97f82cf37015a8ff11e7 Basically it lets you add pilots even with ID empty or string or present, it will check and if not valid, will assign the first available number after 101. The same happens in mass_insert. I still need to avoid user to be able to edit pilot and assign an already present ID. I did not touch anything in tracks recognising as it should already work quite well using ID. probably we could optimise giving ID for granted, and surely would be clever to add ID as last info in ice filename Airscore creates for its track repository.

As soon as I add the check on pilot update I'll put this on test. @kuaka Let me know if you agree to add ID to filename.

[kuaka]

I thought Id was already the last part of a standard airscore filename but I guess it can't have been if it was not a mandatory field. I think it should be added. make sure to add the pattern to the defines.py.

I am curious as to why you have made IDs start from 102. What is the reasoning there?

[biuti]

In some events low IDs are for ranked pilots, es. in PWCA who was not in the superfinal can choose only numbers over 200, while the other have their superfinal result as ID for the next season. Seemed reasonable to me to not assign number 1 randomly, but surely not a strong point here, we can chose any number to start from.

[kuaka]

Ok but ranked pilots will have a number specified not an auto-generated number. Usually any big event will be coming from something like airtribune and will already have IDs. Auto-generated will be mainly for smaller events so to me it would make sense to start from 1 but it doesn't really matter as these events will probably ignore pilot id anyway. It will be in the system but not used much outside the system.

[biuti]

No, it autogenerates only if is empty / invalid / already assigned, otherwise takes the given one. I added javascript check to modals in page (https://github.com/FAI-CIVL/FAI-Airscore/commit/916dd7f9f41afc20ee90de3169ddd87e28e27279), now it should be checked everywhere, as in FSDB and excel they are present by default. In excel they could be repeated, or invalid, I'm not sure I dealt with it. I made some tests, but it would be nice if you have a go.