Thorsten, please - can we leave this "ego-thing" - this leads to nothing...
Sorry, from where I stand, I have given things a fair try but it doesn't work for me.
After pages of discussion, I'm not even clear on what exactly it is you want to do except somehow alter the way winds work. At some point it revolved about making an offline semi-random model for high altitude winds. Then you changed to averaging METARs. Then it was getting a better model of low altitude winds and terrain effects, Fourier-transforming the terrain. Then you wanted a weather map usable for flight planning. Basically, every time we have some conversation, your goal has subtly changed.
At the same time, I don't get the impression you're actually interested in my arguments, I get the impression you're just interested in making yours. When I say 'the problem discussed here is about low altitude winds' your response was 'but people are interested in predictable winds in any case'. Sorry, but that gives me the distinct impression you don't care what problem we're discussing, you want to make your point anyway - whether it fits the occasion or not.
You don't deal well with me not agreeing 100%. Even a mild
As I said earlier, I can readily see that pushing real aloft winds improves things, but not that swapping one workaround model for another workaround model does. gets me a response like
I did some research and have some ideas to make it better - but without any effect, as it seems... . Note that I didn't say that what you're doing is wrong, I didn't say that what you are doing is not better, I didn't say this shouldn't be done - all I said is that
I can't see this readily. I intentionally phrased it that way, because the wording keeps the possibility open that the fault may be entirely mine for not seeing something which you see but didn't explain.
Contrast this with the interaction with KL-666 in this thread. There's an actual problem which is well described and argued (for vectoring, ATC needs to be reasonably sure that all approaching planes feel something close to the wind reported by METAR during approach). There's an identified reason (the way data is interpolated), there's a clear path to explore (the interpolation weight) a pointer to the relevant code and some experimental changes. And two bugs found on the way. It's a purely professional interaction in addition - no 'this is so bad' and such like. So it's a win-win.
I have limited time at the moment, my coding focus is not on weather but on an improvement to the tree rendering C++ and GLSL code, and you make the time I spend discussing weather rather unpleasant for me.
Since my time is limited, I'll just grab one aspect and explain it in depth.
For instance, you make strong statements here.
And who is not able to have a look into the code, has no possibility to determine the wind above or under the actual altitude - and actually no one between the stations.
I am frankly baffled. How do you imagine, say, an airspeed indicator works? Do you really think the weather system should generate the reading of the airspeed indicator?
Of course not! The weather system talks to the FDM via a set of interface points - in fact
any FG weather system talks to the FDM through interface points. The airspeed indicator code picks up what it wants to know from there and computes the indicated airspeed itself. The weather system talks to the rendering framework similarly via a different set of interface points.
Likewise, the weather system doesn't draw a map in the GUI - its purpose is to supply the information to whatever instrument wants to draw a map. Now, since here we're not passing values but functions, the interface is more complicated - there has to be a layer querying what weather system is running for starters. But - AW actually supplies all that's needed - you can query whether it is running, you can query which wind model is running, and you can call local_weather.wind_interpolation(lat, lon, alt) to get the wind the simulation thinks is at an arbitrary point in the world (of course, the farther you are from the plane, the more pointless that value will be). You could call this function in a windsock Nasal to make it show the ground wind rather than the wind at the location of the plane for instance.
And you get to do all that with less than 5 lines of Nasal. So rather than not supplying the capability, AW has very much all that's needed. And it's all nicely modularized. The data to be interpolated is separately from the way you generate the data (so you can put any winds you fancy at the simple expense of calling the set_wind_ipoint function), you have a well-defined function call to get wind at
any position (note that the whole setup was designed that way, it never was supposed to give you wind at the aircraft position only),...
After yet, after spending a few weeks with the code looking at winds, you can write flat-out:
no one (has the possibility to determine winds) between the stations. You phrase this as certainty and criticism - not as something you're unsure of, not as a question or suggestion - for you it's a fact. Except you're completely wrong of course.
You may believe this is down to some ego problem, but I think there's quite genuine problems in the communication here. Sorry, but I don't have the time or energy to sort that out at any cost. I don't want to spend my time explaining how AW works every time you missed the existence of a function and feel you need to criticize AW when you could have simply looked it up. I don't want to spend half an hour assembling an argument to be told by you 'This is not right.'
Please sleep over it, maybe you can appreciate it then.