Scale on speed map changes with degree of Zoom

[isomemo]

Scale on speed map changes with degree of Zoom. This is an old previously reported bug. Perhaps a fix is readily available?

I used this dataset:
rice spread.xlsx

These settings were used: Date type interval (Start.Date... and Finish.Date... as field inputs), Longitude & Latitude as coordinate fields, Min estimate, 0.05% quantile, uniform full width distribution, and remaining default options.

See this video for illustration: https://youtu.be/qDOJMUOOFLQ

[mgross]

On the speed, we use a different method compared to the paper. I give an example how the high speeds occur (and how the "bug" occurs):

We have an observation in western Borneo and in southern Sulawesi where we have similar estimated minima times. Between them there are no observations. Now, speed is: (distance) / (time estimate difference). If both time estimates are very similar and thus the time estimate difference between both locations, the model assumes that rice spread very fast between these points. To me this seems the right answer and I am not sure what to improve here. (if the denominator gets small, the overall estimate gets large).This also has to do with lack of data in these regions, which make the speed estimate quite uncertain. If you zoom in you get more points estimated per sq-km and that causes the bug as small denominator changes can cause large differences in the estimates.

[isomemo]

Ok! I also got different estimates by moving the graph (no zoom). Thus, the scale reflects the range for the visible area? If so, can this also change for the average map?

[arunge]

@isomemo Here, the same as for #27 (comment).
I mentioned this bug in the new task list and I shift it to the next project:

[isomemo]

Ok!

[arunge]

@isomemo I checked the video and the answer of @mgross seems to solve the issue.

Is there any interface issue to be fixed here? Or is there only the open question to @mgross left here?

[isomemo]

@arunge @mgross I tested this again and the scale still changes with map movements/zoom.

[arunge]

@isomemo I think you wanted to ask the question in this issue:

@arunge @mgross Marcus, I just want to be certain that the speed calculations vary due to pixel size. Is this correct? This would solve the issue since Antonia will add to the results pixel size.

[arunge]

@mgross can you confirm the above?

[isomemo]

@mgross @arunge another point that I just realized. We have a slider to set the resolution. I had assumed that this was fixed. So how is the end pixel size defined given zoom/resolution slider options?

[arunge]

@isomemo regarding from above:

@mgross @arunge another point that I just realized. We have a slider to set the resolution. I had assumed that this was fixed. So how is the end pixel size defined given zoom/resolution slider options?

This question was related to the following feature that was added last month to the iso-app beta:

• Version 23.06.4: Feat/169 pixel size #170

Additionally, is the question from #80 (comment)

@arunge @mgross Marcus, I just want to be certain that the speed calculations vary due to pixel size. Is this correct? This would solve the issue since Antonia will add to the results pixel size.

answered now? Can we close here?

[arunge]

Here, there are two open issues:

• change the UI: by default always show the caption text and have an option to show / hide it
• why are the grid lengths not equal / asymmetric? -> see below

[arunge]

Regarding:

• why are the grid lengths not equal / asymmetric?

Grid length is inferred from the latitudes and longitudes vectors that are defined for the predictions. This definition depends on the resolution value. A larger resolution equally increases the number of latitudes and longitudes for which predictions are calculated:

• rangex is the range of longitudes in the data
• rangey is the range of latitudes in the data
  https://github.com/Pandora-IsoMemo/iso-app/blob/4210970bc52848d19f5f586a19b453e152a5675c/R/01-plotMap.R#L167-L171

From the vectors longitudes and latitudes the grid length is inferred by

• extracting the difference between latitudes or longitudes
  https://github.com/Pandora-IsoMemo/iso-app/blob/4210970bc52848d19f5f586a19b453e152a5675c/R/02-modules-modelResultHelpers.R#L183-L188
• and multiplying this value with 111
  https://github.com/Pandora-IsoMemo/iso-app/blob/4210970bc52848d19f5f586a19b453e152a5675c/R/02-modules-modelResultHelpers.R#L97-L101

This works fine for latitudes. But possibly, this is the issue for longitudes since the distance between longitudes in km becomes smaller coming closer to the poles.

@isomemo Could this explain the asymmetry?

Maybe I could use the following function which I am already applying for the jitter in the interactive map to calculate km from longitude:
https://github.com/Pandora-IsoMemo/iso-app/blob/4210970bc52848d19f5f586a19b453e152a5675c/R/01-jitter-latlong.R#L44-L52

@isomemo Would this work?

[arunge]

@isomemo

I checked the code that is used to generate the plot for the map. Following is happening when the zoom changes, and that is why the z-scale also is changing:

• the c(zoom, upperLeftLongitude, upperLeftLatitude) do determine parameters c(rangex, rangey) which are used in the plot function
• rangex, rangey and the "Plot resolution (px)" input determine c(longitudes, latitudes) that are used to create predictions:
  https://github.com/Pandora-IsoMemo/iso-app/blob/f549072ddfb8bcd9ed7dfc1ac7144c5c41d01c97/R/01-plotMap.R#L167-L171
• XPred is an input for the predict() function which is used dependent on the type of model:
  • https://github.com/Pandora-IsoMemo/iso-app/blob/f549072ddfb8bcd9ed7dfc1ac7144c5c41d01c97/R/01-plotMap.R#L227-L228
  • https://github.com/Pandora-IsoMemo/iso-app/blob/f549072ddfb8bcd9ed7dfc1ac7144c5c41d01c97/R/01-plotMap.R#L294-L295
  • https://github.com/Pandora-IsoMemo/iso-app/blob/f549072ddfb8bcd9ed7dfc1ac7144c5c41d01c97/R/01-plotMap.R#L338-L339

That means, each time when the zoom changes, a new prediction is made with updated lat/long vectors. The z-scale is taken from the prediction, thus, it will be updated, also:
https://github.com/Pandora-IsoMemo/iso-app/blob/f549072ddfb8bcd9ed7dfc1ac7144c5c41d01c97/R/01-plotMap.R#L793

@mgross also tried to explain why the values are changing from a modelling perspective:

On the speed, we use a different method compared to the paper. I give an example how the high speeds occur (and how the "bug" occurs):

We have an observation in western Borneo and in southern Sulawesi where we have similar estimated minima times. Between them there are no observations. Now, speed is: (distance) / (time estimate difference). If both time estimates are very similar and thus the time estimate difference between both locations, the model assumes that rice spread very fast between these points. To me this seems the right answer and I am not sure what to improve here. (if the denominator gets small, the overall estimate gets large).This also has to do with lack of data in these regions, which make the speed estimate quite uncertain. If you zoom in you get more points estimated per sq-km and that causes the bug as small denominator changes can cause large differences in the estimates.

@isomemo Could you please give more details about the behavior you would expect when the zoom is changing?

[arunge]

Note from today's meeting: the expectation was that zooming is only a graphical issue. However, this is not the case since the prediction is triggered when a different zoom is applied.

A solution might be to fix the scale. This option is already available for other modelling tabs.

• I will check what is needed to apply the option on the speed map.

[isomemo]

@arunge just to clarify "fixing" the scale means that the scale will have fixed ranges when users zoom in/out, right?