Just because things could be improved further, doesn’t mean that something needs to be wrong now.
Flowx is my favorite app by far, and works great the way it is now.
Eaven for the best of the best, there will always be ways of making details better. That is how you stay the best.
Taping is not necessarily better than swiping!
I’m NOT thinking in therms of tap vs. svipe.
Tap is so far a non utalized posebility that is not used for anything. It could be used for something, and this something could improve the user experience further.
I understand and agree with the mentality of @duane that effort spent at features that later will be dropped should be minimized, but not eliminated entirely. Some experimentation is a healthy and important part of innovation and improving development.
@duane thanks so much for implementing this!
This brings this app to yet a next level!
And with the signature swipe user interface of Flowx it is by far the best app for displaying weather forecast, and now with radar as overlay it stands out as a unique forecast/radar/swipe-app!
Keep it up the great work!
Ps.
I’ve noticed that radar disappears when zooming out “too far”. I could guess that this is by design to prevent lag due to too much data to process, and a temporary fix while wating for implementation of a better way of handling the radar images from the whole world. (Am I right?)
Update:
When zoomed out all the way to world view the radar returns. So it is only diapering in a mid zoom region.
Update #2: Just, wait longer, and then it comes.
makes me glad I don’t have a new device no issues on android 6 or 7.
There is double tap to open compare single to select product to load from compare single tap on current time after swiping returns time-line to current time tap in the menu’s. I understand improvements are necessary but couldn’t understand the big deal with tapping.
Yeah, if I wait longer the radar comes.
The pattorn is that first the count down for downloading the data for the new zoom level reaches 0, then a short while after the phone have processed how to animate the forecast, and a little while after that (depending on zoom-level, timescale, and what other apps are using the phone cpu in the background, I guess) then the radar animation apers on top of the animation.
So solution #1, just more patience to to the user.
And #2 for @duane to put some sort of additional progress bar, or countdown for the time until the data is processed for displaying the animation, or just an old hour glas symbol, or spinning arrows or something, indicating that the app is still processing something, though all data is already downloaded.
I did see that when I do zoom I have always just waited cause it takes time to update.
@duane
Just a question:
Will the
be added to the list of possible data input for the graphs?
It would make the compare mode so much more useful for determining which dataset is most accurate at predicting rain at the given location.
Radar uses a new method to store data. It compresses data on the server to save space and stores it on the phone in compressed form. I think, but not sure, the decompression is adding the delay.
Possible, but maybe the solution is to fix the delay.
There are two ways I can think, store decompressed data on the phone or reduce the tile sizes, currently, they are 500x500 pixels, maybe I should try 250x250 pixels. This will download more tiles and be longer to download but be faster to load maybe??
Yes, the best indicator that the app is doing something with the image that is being displayed is of course to see that something is being done with the image that is being displayed.
It sounds so much more obvious when stated like that.
Could something be done in line with first downloading the pixels closest to the selected place, and than work out to the edges. Or that is perhaps how it is done now?
Or could the radar image first be downloaded with bigger fewer pixels, and then over time transition to more and more, smaller and smaller pixels.
That’s what’s done now but the tiles are so big you don’t notice it, i.e., only two tiles span the screen. You cannot choose which pixels to download, just tiles.
Good idea, and I’ve pondered this, but damn hard. Even google maps don’t do this and they have static data.
How about doing a 2D FFT on the data, sending the FT parameters starting with the lowest frequencies and rebuildimg the radar image in the phone as the parameters stream in?
I happen to have read a Master in acoustical engenering, so for the programming of the signal analysis and processing is where my programming skills might be most useful for this project.
Edit:
Since time can be considered a dimension, the radar data is perhaps even better compressed usin a 3d FFT.
Some links for anyone who wants to read up upon about
“Two-Dimensional Fourier Transform”.
The math:
http://fourier.eng.hmc.edu/e101/lectures/Image_Processing/node6.html
Programing it in for example matlab (or octave):
I used 2D FFT’s quite a bit in my Master’s thesis. FFT’s are computationally expensive. I’ll have to transform them on the server and on the phone.
Streaming and rendering at the same time really doesn’t sound simple. This is a “months” project to implement on the servers and in the app. It’ll suck to put in all this time only to find it we save no time because the inverse FFT takes too long. It’ll come with a lot of bugs too.
I had one of these instances last year. I downloaded the tiles and split them into individual images for each time step. There we hundreds of image files per tile. Awesome, it was easy to find a specific list of time steps, load them and render them - awesome. This took probably a week of work. Then added the code to purge old data because there were thousands of files in the directories, it took ages to purge. Every now and then, you’ll open the app and it’ll hang for 20-30 seconds while it deleted the files. 1-2 weeks of work down the drain.
The issue here is that it takes a while for the radar tile to show. This is due to two reasons:
These are simple to do and will give us a 4-8x speed-up, i.e., if it takes 2 seconds to download a tile, it’ll take 250-500ms - at these levels, latency starts to dominate. If it takes 2 seconds to load, then we should be able to load a tile in 250ms-500ms - but comes at a cost of rendering up to 4x more tiles.
Keep it simple I say.
, I agree!
