switching from velocity to displacement does not keep min/max scale

[falkamelung]

When you change from velocity to displacement display, and vice-vera, the min/max is supposed to change so that the colors remain roughly unchanged. This can be achieved by multiplying with the time period duration . For example, if we have a [-4 4] cm/yr velocity scale over 1.5 years, then we should have [-6 6] cm displacement over this period. However, currently the conversion factor is not right. If you change the scale gets wrongly adjusted. Switching back should bring you back to (nearly) the same scale, but this is currently not happening.

https://user-images.githubusercontent.com/11162588/183275525-2a0d74af-03b0-4ff2-8b1a-4cf29dc0d6df.mov

[stackTom]

We actually had it like this at one point. But, we decided at one point to use permissible values... Here is the email you sent. If we don't use these permissible values, then the coloring doesn't change:

Amelung, Falk C famelung@rsmas.miami.edu Tue, Oct 9, 2018, 2:06 PM to me

Hi Alfredo, there is another minor issue. When you display one data set, the default color scale is always between -2 and 2 cm/yr, which is not practical for large deformation. It would be preferred to extract the minimum and maximum and then take 50% of the highest or lowest value. Lets do 50% now but possible change if the initial display is not good (examples below). There should be some rounding, so that we don’t end up with a scale between -3.71 and +3.71 ). Possible permissible values are also below. So I would suggest to do max(data)/5 and select teh closest value.

Thank you! Falk

Min(data)=-5 Max(data)=20 —> colorscale [-10,10]

Min(data)=-6 Max(data)=2 —> colorscale [-3,3]

Permissible values:

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.5 2 3 4 5 6 7 8 9 10 15 20 30 40 50 60 70 80 90 100 150 200 300 400 500 600 700 800 900 1000 -----------------------end email-------------------------------------------- Any ideas?

[stackTom]

Or are these permissible values only for the initial load of the dataset, and then are not to be used when changing from displacement to velocity (and vice versa)?

[falkamelung]

I see. Yes, I remember this. Only permissible values is certainly better. There is no need to exactly get back to what you have earlier, but similar. So I suspect there is a rounding issue. maybe you are always running down city should round up in some occasions? I am on travel at the moment. I will look at it in detail when I am back (Sunday eve).

[falkamelung]

To respond to your second point: No. We always should just use permissible values. It looks ugly if you have e.g. 7.89 limit in the color bar.

[stackTom]

Here is the code which gets the values. Maybe you can suggest what we should differently?:

https://github.com/geodesymiami/insarmaps/blob/tileserverDevelopment/public/js/mainMap.js#L788

[falkamelung]

Testing some more I see that there are factor of 2 errors in the conversions.

Velocity to displacement For data covering 1 year, it converts 10 cm/yr-->5 cm but it should be 10 cm. For data covering 2 years, it converts 10 cm/yr-->10 cm but it should be 20 cm.

Displacements to velocity For data covering 1 year, it converts 10 cm-->5 cm/yr but it should be 10 cm/yr. For data covering 2 years, it converts 10 cm-->2 cm/yr but it should be 5 cm/yr.

I hope you can find this. If not I can dig into the code.

[stackTom]

Can you give me an example link I can test.

[falkamelung]

Here for 1 year: Velocity: https://insarmaps.miami.edu/start/19.5128/-155.5242/10.0522?flyToDatasetCenter=false&startDataset=CSK_SM_091_0000_20180916_XXXXXXXX_N19368_N19540_W155666_W155481&pointLat=19.45318&pointLon=-155.57221&minScale=-10&maxScale=10&startDate=20180916&endDate=20190919&colorscale=velocity

Displacement: https://insarmaps.miami.edu/start/19.5128/-155.5242/10.0522?flyToDatasetCenter=false&startDataset=CSK_SM_091_0000_20180916_XXXXXXXX_N19368_N19540_W155666_W155481&pointLat=19.45318&pointLon=-155.57221&minScale=-10&maxScale=10&startDate=20180916&endDate=20190919&colorscale=displacement

Here for two-years: https://insarmaps.miami.edu/start/19.5128/-155.5242/10.0522?flyToDatasetCenter=false&startDataset=CSK_SM_091_0000_20180916_XXXXXXXX_N19368_N19540_W155666_W155481&pointLat=19.45318&pointLon=-155.57221&minScale=-10&maxScale=10&startDate=20180916&endDate=20200921&colorscale=velocity

[stackTom]

I see why it is rounding down by 50%. This what you said in your original email (see above) - to take 50% of the lowest or highest value. Do we not want this anymore?

[falkamelung]

I am not sure I understand. The 50% off in my 2018 email above refers to calculating the max/min of the color scale for the display based on the data limits. It should be only done the first time, not when you converted from velocity to displacement and vice versa. If you are sure there is no issue with the length of the time period, then this might be it.

A common mistake is to use a rounding function that always rounds down round(2.9)=2, round(2.1)=2. If you are using a function that does this you have to add 0.5 to get the desired result: round(2.9+0.5)=3, round(2.1+0.5)=2

[stackTom]

I think that fixed it. Now, I only take the 50% off the first time, not on subsequent conversions from velocity to displacement and vice versa.

Please check, and we can close the issue if it's okay.

[falkamelung]

Yes, this works!. With this fix and the fixes for the time period selection is got really easy to look at time periods of interest. Thank you! I am closing it.