Closed opeeters closed 4 years ago
@opeeters done
All is well for resolution=rioifdm
.
Something is still going wrong for resolution=rio4x4
and resolution=rio1x1
. These maps are already available at about '25 and '30 past the hour. The rioifdm layers are only ready by '54 past the hour..
In the case of e.g. resolution=rio4x4
, https://www.irceline.be/air/time_hmean_rio4x4_json.php is correctly fetched, but the WMS calls go to the time as returned by https://www.irceline.be/air/time_hmean_rioifdm_json.php
I think i have found what is going on:
I think that the issue you are mentioning was already existent in the code (separate from this enhancement), but now you found it (so it's a separate issue). The consequence is that sometimes not the last possible update was shown on the map.
What is happening:
The lastupdate format is specified for example as time =
"2020-01-09T14:00:00+01:00"
but when you call moment(time).toISOString()
, (what we do in the _timeformats.js ), moment.jsadjusts the zone to +00:00, which turns the clock 1 hour back, which is unwanted in our case.
See: https://jsfiddle.net/htdk5e3w/1/ (i take moment() and then turn it to an ISOString() )
Still reading up on how to solve this.
So i thought i had found it, but i don't think it's that. Could you ellaborate what the problem is? If the .php returns a time of lastupdate, i presume this is the last update right? And this doesn't seem the case? for example, now it is 18u42 and the php for rio4x4 gives 17h +1. Which is not the latestupdate it seems, because the latest update is from 18h +1 no? Maybe i'm wrong, please ellaborate...
By the way: there is no mechanism in the page to update the correct time of latest update. So if that's not present, we have to assume that the first time we get the latest update is the latest update (as long as there is no refresh).
Dear @opeeters and @stevenvdbosch,
regarding the forwardHour
button, I have amended the behavior slightly within #7 to disable the button instead of hiding it. This prevents layout changes within the time control so the user does not have to move the mouse to follow the button.
With kind regards, Andreas.
Thanks @amotl I merged the code into the issue3_refine_region_parameter branch.
The added feature for changing the time with the arrow keys and ctrl + shift is a nice addition: But it introduces 3 'problems' if you use the arrow keys,:
Dear @stevenvdbosch,
With kind regards, Andreas.
@amotl I use chrome mainly. In firefox it works indeed
I added documentation about this to the readme. This is an advanced user
feature for the time-being, but I was planning to add some documentation pop-up in the future.
When the data on the map is the latest data available, it should not be possible to go to the future. I solved this elsewhere with something like this:
And in
$('#backHour').click(function()
and$('#forwardHour').click(function()
something like this: