anybody working on a trajectory plugin?
-
@rittels I told my fellow balloonists about that plugin (we have a whatsapp group for winter Alps crossings) and they really like it!
the following suggestions came up:
(1) place a marker at fixed time intervals so you can tell where you'd be by then
maybe make the time per interval dependent on duration, like 15min, 30min, 1hr - I think a total of say 3-6 marks should do (have a look at the meteoblue example above, they mark hourly - good enough for a start)
(2) what I really wish I could do: take the forecast/s of a given point in time, and AFTER the flight overlay it with the actual track - but I guess going back in time is not realistic in windy
an almost as good solution would be to export the trajectories as gpx or kml/z, so they can be re-imported later together with the actual track
-
@stitch I played around with TS trajectories today
would you suggest FL140/180/240 are realistic altitudes for thunderstorms (IANAM - I am not a meteorologist :-)
this image from today would suggest roughly FL100-140 for best fit (6hrs, TS over Carnian Alps):
-
@mhaberler
https://community.windy.com/topic/7888/anybody-working-on-a-trajectory-plugin/11
IMHO, 700 hPa (FL100) winds are representative to actual tstms movement in most cases.
Maybe, because at this height is located the center of gravity of a typical 30,000 ft high tstm. -
@rittels I only now discovered the feature where clicking trajectory segments reveals the start time of each segment - great!
I'm trying to understand the segment duration logic - I made a short screen video for a 12hr trajectory to show where I stumble
this trajectory has 5 segments with the following durations:
- first segment: 1hr
- segments 2,3,4: 3hrs
- last segment: 2hrs
it seems to me segments #2 and #5 definitely are polylines, but select as a single segment ?
NB: just trying to understand - not nitpicking ;-)
-
que es lo que quieres saber
-
@mhaberler said in anybody working on a trajectory plugin?:
this trajectory has 5 segments with the following durations:
first segment: 1hr
segments 2,3,4: 3hrs
last segment: 2hrsit seems to me segments #2 and #5 definitely are polylines, but select as a single segment ?
NB: just trying to understand - not nitpicking ;-)que es lo que quieres saber
-
@erisyardas point taken
How do I get onto hourly location increments?
-
@rittels
I can not load 0.1.4 (the one with color picker).
I can only load 0.1.3
Am I doing something wrong?@TomSlavkovsky
https://community.windy.com/topic/7574/available-windy-plugins
Q: windy-plugin-traj@0.1.4 is not (yet) available? -
@Gkikas-LGPZ which browser+OS?
edit: playing with Safari, Firefox, Brave, Chrome - all currently get stuck during segment generation
looks like a temporary network or server issue
edit #2: all working again
-
Stuck again, lol. CORS error. We are overloading their servers???
The polyline segments represent 3 hour segments, as provided by the pluginDataLoader. Starting 90 minutes past 2400 (GMT).
I added markers at the hour points. Should hopefully work once the server is responding again.I can add a facility to download and save trajectories, as .gpx.
Will do so later...
-
@Gkikas-LGPZ 0.1.5 latest. Will load 0.1.6 with markers, as soon as server active.
-
@rittels perfect!!
I see - the marks coming from the data import - makes sense nowgpx: really any format is fine
I am very curious to overlay forecast and actual tracks - have done so in the past with a ADS-B track from flightradar24 and trajectories from Meteoblue exported as GPX, eg last slide in http://static.mah.priv.at/public/alpenfahrt-vortrag+folien.pdf
-
@rittels works perfectly!
-
Hi Michael. Should all the trajectories on the map be bundled in 1 gpx file, or would it be better to download each trajectory separately?
-
@rittels I looked at what meteoblue does when you export a bundle of trajectories as gpx, this is what I got:
meteoblue trajectories downloaded as gpx
now I imported this gpx into Google Earth and it is evidently possible to extract separate tagged tracks from this single gpx, so sticking to the same method would do just fine IMO:
-
download trajectories with : windy-plugin-traj@0.1.8
-
traj 0.1.9 feedback:
the traj generated gpx: http://static.mah.priv.at/public/trajectory__2019-07-04T17_15_00.gpx
for comparison, a gpx cut out of a 'real' Garmin 695 tracklog: http://static.mah.priv.at/public/20190630-stiwoll-waldstein.gpximport traj gpx directly into macOS Google Earth (fat UI), using import option 'Use KML-LineStrings': very nice UI, clicking the arrows gives detail at current point:
for comparison: import gps695 gpx directly into GE UI (NB: dumb naming, traj much better):
(NB: the GE GPX display code seems to be a bit buggy: de- and then re-selecting a track makes the selectable arrows vanish for both the traj and Garmin695 gpx files)
traj gpx does not import as gpsvisualizer.com Atlas - not sure why: https://gpsvisualizer.com/atlas/map?url=http%3A//static.mah.priv.at/public/trajectory__2019-07-04T17_15_00.gpx
gps 695 gpx imports fine as gpsvisualizer.com Atlas: https://gpsvisualizer.com/atlas/map?url=http%3A//static.mah.priv.at/public/20190630-stiwoll-waldstein.gpx&c=47.165141,15.293064&z=12&bg=osm
interestingly, both files properly import into the gpsvisualizer leaflet and displays: https://www.gpsvisualizer.com/map_input?form=leaflet and https://www.gpsvisualizer.com/draw/ - one would think its the same import code. No biggy.
In all cases the colors conveyed by the Garmin gpxx:DisplayColor tag are ignored. But they are in the gpx file and can be extracted somehow if needed, so no reason to jump extra hoops in the plugin code.
Exporting the elevation with the tag works fine, it's exactly the same as Garmin device exports it.
other than traj 0.1.8 gpx files, the 0.1.9 gpx files now properly import into JGPSTrackEdit.
to sum it up: I think the gpx export works good enough for now - everything from here on really is rearranging deck chairs IMO
I'm pretty happy with it and can do any extra hoops for say super-polished presentations with standard tools like gpsbabel, XML transform and gpsvisualizer.com which I use most
IMHO: milestone reached - good for the masses!
-
like @Gkikas-LGPZ , I generally refer to 700hpa/600hpa as a mean steering wind. But then in northern Aust the summer Tstorms top out in the mid 30k ft to mid 40k ft levels.
With respect to southern Aust winter Tstorms, then I generally lower the TS tops to mid 20k to 30k ft level and would then look a the 800hpa and 700hpa levels.
You can see what the forecast CB tops are using "Cloud tops" (just ensure the model is highlighting cellular based clouds and not layered clouds like cirrostratus/altostratus etc).
I see you have used the radar/lightning window to correlate the Tstorm speed/motion to a wind height field - this is what I would do as well.
Be wary though of Tstorms that move/turn towards a different directions opposing the mean or normal Tstorm tracks (these anomalous movers could potentially turn into the severe variety of Tstorm).There is no steadfast rule....just trial an error.
All the best with your forecasting ..... @mhaberler
-
@stitch thanks, really helpful!
once in a while we have a TS nearby at an event and it is unclear wether we can go for a launch or not; the traj feature helps narrow down the question
-
@rittels 0.2.0 feedback:
exported trajs now carry over a color - great!
the gpsvisualizer.com Atlas import snag is gone.
here is a traj gpx export example, warped into kml with these gpsvisualiser KML settings :
I think export is just fine now.
Since my birthday's coming up... how hard would it be to play traj's from different models?