Here I give my experience.
Maybe we can get somewhere.
· The boats data has to be complete. If there are missing boats you lose critical info. All boats should carry a GPS.
Personally I don't see the fact that some boats sail without a GPS receiver as a problem worth considering. GPS loggers are become more and more available and even for rather low costs due to GPS route planners. My GPS logger stores 10.000 data points and costed 150 Euro's some 3 years ago. Past season we used several of these during club races. The hardware is not the real problem. And I would accept a good numbers of GPS carrying boats as acceptable. I think all F16 sailors in NL have a personal GPS logger already.
What I'm saying here is that this is not a technical problem.
· The data has to be coherent. I’m not sure if different GPS makes or models are able to store the log data with the same accuracy. It is sure that different models will use different algorithms to extrapolate or to log dynamically.
Our experience is that the accuracy of a GPS logger on the water is typically 3 to 9 meters. Most loggers can log once a second. That is very accurate when measured on the overall size of the course. It is quite easy to see the windshifts etc in the tracks. Again, this is the result using 100-150 Euro GPS loggers.
The data itself can and should be pre-processed by a different application before it is fed into a viewer. Even I can program that. In this pre-processing an intepolation routine can be used to bridge gaps or even correct for reduced accuracy. Again I got the skills to do that; had been doing that in my previous job. My skills however are lacking in the display field.
Logger do sometimes miss a few logging instances but even extremely simple lineair intepolation routines work rather well here.
· Origin data. I assume time is sychronized on all GPS units, not sure the same can be said for x and y coordinates.
The GPS can not function without a universally synchronized clock. Hence the clocks of the individual clocks are automatically synchronized with a the satelites themselfs. Of course the coordinates are calibrated as well otherwise the GPS would not be a GPS (Global positioning system).
From experience I can tell you that two boats 10 meters apart will show themselfs exactly like that in the tracks. Therefor these points are not an issue.
· Extra data is needed. GPS reading for all marks, pin and RC boat. GPS reading of Start time.
The boat we'll be using for the racing has a build in GPS navigator. Shouldn't be to hard to store waypoints for these items.
In the past I just loaded all the tracks of individual boats into one view and the location of the marks and line is rather visible by the shape of the tracks. The last may not be most accurate but it did work rather well.
It is surprising how much can be learned from the tracks alone. All these things can be done in the pre-processing phase even logging by the committee boat fails. A little human inspection of the tracks can go a long way. It really helps that this is not real time.
Only problem: how to paint the boat… we know the location. The problem is with the orientation, GPS info gives no clue how the boat is oriented. We can assume that is oriented like its speed but that would produce funny results when the boat stops or go backwards.
You are correct in principe, but not really in practice. This viewing of GPS data will be in playback mode and not real time mode. So the direction of the boats can be found by looking at the next waypoint (or even more future way points). If future waypoints are inconclusive then look at a few past waypoints.At the time of plotting all waypoints of the entire race are known. This info can feed a simple routine that determines direction. But I think it to be better to have the pre-processing phase do these actions and just expand the data with direction info. That makes displaying both easier and faster.
Can this go wrong in some instances ? Probably, but if these are limited in number than that is quite acceptable. Further more I'm thinking about a simple routine that keeps boats always pointing "upwind" on a upwind leg and on downwind legs you don't have this problem of sailing backwards.
A guestimate of cost (assuming the data is OK and accepting the previos remark about orientation): 8 programming hours, 4 for test and 4 more for packaging and webalizing.
When I programmed I always multiplied my best guess by 3. But then again I'm not a fast programmer.
A nice extra…. Data can be feed on-line, if GPS unit can rely the data to a ground station…
That is much more difficult ! And way beyond anything I would consider building or asking anybody to build.
: Live feed to Intenet of a running real regatta. And that for free. (I’m not counting the hardware and integration costs for a on-board GPS and signal unit).
Well, I'm not saying we have a big budget but I'm not saying it must be for free either.
I feel confident that I can get the data file right by pre-prosessing raw GPS logger data. Including the marks and start-line and the direction of the boats travelling.
The only question I have is whether multiple tracks can be easily displayed using a program like Tacticat. And if so; whether the amount of effort required would make it too expensive or otherwise impossible.
You may have guessed by now that this is not an idea that just popped up in my head. I actually did work on it occasionally over the past years but I always hung up on the graphical display part. I can program processing routines and such but graphical user interfaces is really not my sport.
Also before I let anybody do any interface work, I (or a few of us) will first proof the pre-processing part by actually doing it.
Wouter
