Hi, as we get ready to start our new season here in southwestern Ohio, I am updating our club app which imports the JSON data from SailWave. Last year I only used part of the JSON data because I could not understand all of the abbreviations.
It appears that the exported JSON has the following objects:
“header”
“globals”
“ui-recs”
“prizes”
“competitors”
“races”
“results”
“columns”
In the “competitors” object, I can figure out some of these but do you all have something that explains the abbreviations? I assume the “57” for example is a competitor key for an object that has 12 key value pairs? Is this key used elsewhere for race results?
In the “races” object I cannot make heads or tails of what this is representing? Can anyone shed some light on this?
In the “results” object, some of these I can guess but does anyone have more information about the abbreviations and what they represent?
I checked in the user manual but was unable to find this information.
thanks in advance!
Bob Taylor Flutter Mobile App Developer
Hi Bob,
The 57 in your example is the Handle for that competitor
So in this example, Stephen Cook has a Handle of 57
His total points are 199
his net points are 94
his rank is 15
his SailNo is 289
his class in Montgomery 15
he is not excluded
he is not an alias
his rating is 108.2
Then the races are, race handle 1 is race one (racerank) and it has been sailed
It has one start which is recorded by default as Place ( you would be better off by setting the default to either elapsed or finish time) but your example is showing Place
In this example, Race handle 1 is race 1 and Race handle 2 is race 2 but this is not always the case
For the results
The example shows comHandle 57 so this is our Stephen Cook
racHandle is 1 so this is Race 1
His points were 5
His position was 5
His corrected time was 0:30:17
His Result type was 2 (1 = position 2 = timed 3 = code)
His recorded elapsed time was 00:32:46
He would have needed to have sailed 04:53 faster to have won the race
or his rating would have had to be 127.125 to have won the race
Hope that helps
Jon
Just as an aside; the idea was that there are three main object types: Races, Competitors and Results. Races and Competitors have numeric ‘handles’ to identify them and those handles are independent of any sailing data. Handles never change. For example a Race may have a handle of 3 but a rank of 5. Each Result has a pointer to a Race and a Competitor via their handles. Immutable handles like this are useful if you move a race ‘right’ for example - it’s rank changes but you don’t have to relink all the associated results.
I can’t remember if I gave results handles as well, but if so they are just to ease some aspect of the implementation and not needed conceptually. I think they could probably be removed from the JSON unless I’m overlooking something.
The JSON was generated with the same code that generated the .blw file and I wanted to be able to change the .blw file as needed - so I didn’t document it - as a deterrent 
It’s moot whether or not the JSON should have more inertia and be more formally documented; but what about new features for example. I could never resolve that in my head so I took the easy route
Thanks, this is just what I needed!
Bob