Sure, this could be an easy extra format/keyword for the speed parameter.
I assume km/h is not a good unit for vertical speed, google says ft/min is used, do you know any other commonly used units? I’d have said meters/min for metric but apparently aviation uses only feet (aka imperial) for some reason.
Also a quick technical question: your attached gpx has 2 separate tracks with identical times and locations but slightly different altitudes. This is not a big issue but Shotcut (this filter) will just silently discard the 2nd track (it only accepts strictly increasing times).
So for the first track of the gpx, a quick test shows something like 2-3km/h top vertical speed (or around 100-200ft/min). Is this around the expected range for your recording?
Great to hear it would be an easy extra
About the vertical speed unit, in air sports such as paragliding, where thermal flows are used, vertical speed can vary greatly, and m/s is the most appropriate unit (ft/s for imperial). In motorized aviation, with longer, more stable flights, the unit of time tends to be the minute.
The standard file format is also not gpx but IGC (FAI Gliding Commission), I converted the sample using GPS Babel, which seems to duplicate tracks. The vertical speed you got from the first file is ok, here is also another sample, from a flight with increased vertical speed variation (track is also duplicated). vertical speed sample gpx 2.txt (468.2 KB)
@daniel47 Hello.
I tested the new cadence and grade_percentage fields added version 23.08.16, with road bike data (tcx). Great.
For grade %, I chose GPS_smoothing: 7. For my use, this seems to be the most accurate setting.
Compared with DashWare (from GoPro), the values are fairly similar on the flat and climb. At the start of a downhill, the values seem overestimated and then stabilize. (Maybe speed x3 or x4?)
For info, my GPS computer (Sigma) and DashWare underestimate the negative percentage.
I’ve reported a minor bug concerning the undisplaying of new fields.
Many thanks for your work on this filter.
Probably Dashware is doing a lot more filtering and processing, every time the movement starts or stops the values will inherently be wrong because both 2D position and the altitude will have a bit of error and delay which entirely depend on the receiver’s signal and processing power.
To fix this, in my code there is some error handling (smoothing, outlier elimination, low speed cutoffs) but I did not want to do anything massively complicated mosly because the entire processing has to happen fast but also because more advanced processing is, well, too complicated and I ran out of ideas (and time).
I also did not want to have some very hard limits on accuracy because on the first “version” of the filter a rather slow and hard hike .gpx I had around for testing would be 90% ignored for inaccuracy and I did not like that tradeoff.
For now I think this version will have to do (unless there’s a big error in a case I did not think of).
My compliments for these two gps filters, they are very useful. I tried to apply them to my motorbike logger (custom arduino system) and it work with a good level of customization.
I created a gps/acceleration logger at 10 Hz that writes .gpx file. Interpolation from 1 to more sample returns weird speed, only with “raw” data speed is real, but in this case data are dispalyed almost at 1 Hz.
Is there something I cannot set in the right way or there is a limitation?
As future implementation I will add some extra field to this gpx, as gear, engine speed, wheel temperature, ecc… Actually I’m using other recognized fields to show other data (ex gears), but in short time I will overcome their number. In future is there a possibility to read custom fields from gpx writing the name of the field on the filter?
I tried to analyze sources to contribute by myself, but I’m not so expert in qt and in shotcut structure.
Can you share the gpx file (or a snippet of it) so I can have a look? Setting interpolation to 0 (raw_data) should read the data at the same frequency that is stored in the file unless the Update speed value is left at 1 sec (default), try to set it at 30 (or what your project framerate is).
This is not impossible but not that easy with the current implementation. The filter has to know what fields to read at the very begining of the file load and store them in memory, there’s also extra processing depending on data type (speed has to be eventually converted from m/s to km/h or mi/h, grade has to be between certain values and discarded if suddenly changes etc).
In the current implementation any extra field will increase RAM usage for everyone even if the file doesn’t contain them (there’s a fixed structure that holds all the data) so I am wary about adding custom stuff. Of course, this could be solved by using some dynamically allocated data only when needed.
If you’re a programmer and want to implement this (or someone else sees this thread and wants to do it), a rough idea that might simplify the work is this:
instead of any random word as a custom field, decide on some specific pattern like “custom_integer_XX” or “custom_float_XX” (where XX would be a number)
extend the gps_point_raw and gps_point_proc structures with a void* pointer (or a pointer to a structure you decide to use)
on file load (inside qxml_parse_file ) run through the file’s tags to see if/how many of these custom fields you have; current implementation uses QXmlStreamReader() calls, not sure how easy would be to do pattern matching here. or
(alternatively but less efficient) decide on having exactly 10 extra fields and in the current while() loop where we read the other fields try to see if the 10 individually custom fields exist “custom_float_00” … “custom_float_09” and if they do, read them into your new structure
for every entry add these to the raw structure by dynamically allocating the necessary data to the void* pointer or struct* from step 2
go through the gps_parser.cpp code and deal with the new data where you think it’s needed (probably the interpolation part if you don’t just need the raw values)
go through the filter_gpstext.cpp code and add the printing part (this one should be easy as long as you properly set pointer values to NULL so you don’t mistakenly print garbage)
Overall with the restrictions set on the pattern this shouldn’t be too difficult, but I don’t plan to work on this anytime soon as it would still be plenty of hours of coding for a niche usage quite far from the intial GPS intention of the filter.
Overlaying GPS Data in Shotcut with GPS Text Filter (Version 21.08)
Shotcut’s GPS Text filter, introduced in version 21.08, empowers users to enhance their videos by overlaying GPS-related information seamlessly.
Synchronization Workflow and Useful Tips
Navigating the synchronization process entails adjusting for potential challenges like timezones and varying metadata from different devices. Shotcut provides convenient buttons within the filter panel to address common issues, such as timezone discrepancies and incorrect video durations. Users are encouraged to record a clock during filming to simplify the synchronization process later.
