Switch from pointID to lat long ?

[falkamelung]

The pointID is different from dataset to dataset. Could we switch to lat and long? The idea was to use exactly the same command but just replace Dataset or startDate and endDate and get very comparable plots. As you see below, if I do this using pointID it produces time series for different locations

https://insarmaps.miami.edu/start/19.6646/-155.1007/8.5285?flyToDatasetCenter=false&startDataset=S1_IW12_087_0527_0531_20180902_XXXXXXXX&pointID=716685&minScale=-7.5&maxScale=7.5&startDate=20181228&endDate=20201208

https://insarmaps.miami.edu/start/19.6646/-155.1007/8.5285?flyToDatasetCenter=false&startDataset=S1_IW23_124_0060_0062_20150106_XXXXXXXX&pointID=716685&minScale=-7.5&maxScale=7.5

[stackTom]

Do we need urls to just be reproducible (produce the same results every time once a url has been generated by the website), or do we need the ability to allow users to edit the url? I initially tried with lat and long, but the reason I did point id's is that mapbox renders each point with a small error in the true lat and long every time. So the logic required to figure out the true lat and long from a given lat and long would be complicated. It would lead to not reproducible results when I made it with lat and long.

For example: if you visit the same link multiple times, although the website would show you the point essentially at the lat and long in the url (we are talking small error of 0.00001 lat and long degrees or even less...) you would not get the same exact time series plot every time you loaded the website. Because each pointID is stored in the point, it is constant between page loads and doesnt suffer from this error.

I can try doing it with lat and long, but not sure if it worth the development effort. If our goal is simply to send users a link so they can see exactly what we see, it is not worth it. If our goal is that users can modify things in the url, then it would be necessary. I assume you want it so that users can edit urls (since you asked me to make the start and end dates more human friendly).

[falkamelung]

Hmmm... The main idea was to send other users a link to see the same as we see. This is accomplished.

The thing is that 'pointID' is not very scientific.... Scientists want to to understand what they are looking at. Are you really looking at the point you think you are looking at ? That was the same with the dates.

The other idea is to display for multiple datasets the same point (e.g. top of a volcano) by changing the dataset name in the URL. Finding the same point is otherwise difficult. It does not need to be exactly the same point. A few tens of meters off (e.g. 0.0001 degree or even larger) would be fine.

The lat/long of a point is given in the lower right (see image). So I don't understand why it is difficult? If too complicated lets shelve it for now. The map display using the URL was the high priority.

[stackTom]

I see, I can give it another go and see how far I get.

Yes, finding a lat and long on the map is no issue. The issue is that a long lat, x,y wont give the exact same point each time the page is loaded. The points are so closely laid together that an x, y is still describing the same physical area pretty much. But the problem is the inconsistencies. If you are displaying a certain plot with velocity of z, visiting the same link will not display the same exact point nor the same exact velocity of z (obviously, it will be similar as it is a point less than 0.0001 or more of lat long degree difference, but it wont be exactly the same).

[stackTom]

Okay, I am glad you wanted this. I re-read the mapbox api and they have added some new functions that have made this easier now than in earlier mapbox versions. We can do lat and long for the point in the url instead of the pointID.

The only thing is - do we need to only limit it to 4 decimal places like for the lat and long of the map and the zoom of the map? If we do this, then it's impossible to guarantee that the link you send someone is the same point that you are seeing. Simply put - we need as much accuracy as we can get since these datasets are so dense and there are many points with very similar lats and longs. I recommend as much accuracy as javascript allows, such as 9.219932556160614 for the point lat and long (the zoom and map lat and long can remain with 4 decimal places).

[falkamelung]

Great that this is possible.

Regarding decimals, hmmmm.....

Just 4 decimals or max 5 would be preferred. Our pixel size is 20 meters which corresponds to 0.0002 degrees. It looks weired if you give lat/long with a precision we don't have.

How much is it off? If it is off by 1-3 pixels that is not a problem. A simple geolocation error.

[stackTom]

Great news. 5 decimal points produces reproducible results. Not sure if it is reproducible for every dataset and every point on the website, but if our pixel size is constant of 20 meters for every dataset, then 5 decimal places should produce reproducible results for all datasets. Pushing the code and closing this.