Plat and Plong in statistics

[dpastorgalan]

Gday Mathijs,

I got a request from Eric Font that I have considered possible (I think I can try to program it since it is pretty simple, but for you it will be about a minute). They asked me why in the statistic portal the table does not print the pole lat and long in addition to the pole statistics. Obviously that is implemented in the Geography portal (where if two sites are combined you get an averaged geographic lat-long) but I agree with Eric that getting that directly in the table makes the process simpler (and cost nothing). Obviously if data has not geographic coordinates those fields will end up blank. I think it is decent idea, it is data we already calculate so why not printing it too?

He had another suggestion, that I am not sure if it is so interesting and at least harder to do. It is the possibility of plotting the VGP both centered in the pole and at its virtual geographic position in a stereonet with shortcut to cycle it (e.g. number 9). I told him that he can get the average and error from the geographic portal, but he is interested in specimen level distribution. I am not sure if this makes sense for anybody else, and if that is easy or not to add, but definitely I am sure I cannot do that.

[Jollyfant]

I agree with your first idea, it should be there when available.

For the second, I like the idea too. But for now, maybe they can get the pole latitude, longitude and plot then in the APWP module? There should be a stereonet there.. I don't know if its perfect.

[dpastorgalan]

The APWP module is what I suggested, because it does it properly. But it plots 'only' (because it is what is should in that portal) the pole average and A95. Eric said that he like the idea of plotting the VGP in its place with all the specimens. Again, not sure how hard it is and not sure if many people will use it, but it is true that in our discussion on the shape of A95 and bootstrapping getting that plot would have helped...

[Jollyfant]

It would make sense to put this information on the statistics mean tab. Meanwhile, one "problem" I discovered with the code is that for calculating the VGP distribution I am using an arbitrary site at longitude, latitude 0, 0. This doesn't matter as long as all samples come from roughly the same location. Another approach would be to use the individual specimen locations. The first approach is how Cor did it, and implicitly assumes all data comes from the same "site".

What do you think?

[dpastorgalan]

Well, I remembered that we had this conversation in the very first development. In general most times people will merge only samples from the same site or from relatively nearby sites, which probably won't affect the result. But it is true that sometimes you may want to merge specimen level data from the same plate and age to see the VGP distribution, but maybe several degrees apart (I am thinking north and south France for example). And then an important bias will start showing up. Definitely, the best approach is using each specimen coordinates. But then there will be a problem if some specimens do not have the complete metadata. Perhaps we should use the coordinates if all specimens contain the metadata and if not keep on the assumption of 0,0? But if that is the case, I guess we need some sort of disclaimer somewhere. If we are including plat and plon in the table that data will be empty if the metadata is not present, and the disclaimer might included there (perhaps with an asterisk and a pop-up thingy if you click similar to the one that comes out when you click on the "save" colection??).

[Jollyfant]

Yeah it gets complicated when you have to make decisions for users on what you assume they want. I think for now I'll just leave it using (0, 0) and add a disclaimer. I agree the best solution would be to use specimen locations when they are available, and when one is missing default back to (0, 0). But all this is very opaque and mysterious to the user and I want calculations to be as transparent as possible. One "problem" I foresee is that it will change all VGP Distribution figures. Albeit not the distribution itself, but in an unimportant way (e.g. rotate them).

[Jollyfant]

This also affects the cutoff procedure, as it also assumes a shared site for all directions (0, 0).

[dpastorgalan]

Another option might be cycle it (?). Just like the specimen/geo/tecto we could go from VGP centered in North at 0,0; Centered in North at true coordinates; and showing its true locations on a Stereonet.

Obviously the second and third option won't show up if coordinates are not present (and mostly all users of paleomagnetism.org know that you need the coordinates to obtain a VGP).

I agree the shape won't change (only rotate) unless you add-up sites that are quite far away, and that should not be a problem for the cut-off if samples come from relatively near. But the rotation of the VGP might be sometimes confusing too, because elongation in E-W in principle should indicate some sort of inclination shallowing, but in other direction it might indicate vertical axis rotations or deformation...

[Jollyfant]

Hmm.. maybe the least complicated solution is to keep it this way and recommend users to create sites from geographically adjacent specimens. If you want to compare north and south of France, perhaps stick them in two collections and look at the difference in the mean VGP. Too many options and conditions really bloat the software, one of the nice things of pmag.org is the simplicity that can be used by anyone.

[dpastorgalan]

Then that is the solution! But giving the plat and plong in the table is still a good idea :-)

[Jollyfant]

Downloadable table or above?

[dpastorgalan]

I am happy if it goes in the downloadable table. But I am not sure if it is better to show it in the printed one on scree too. I leave that decision to you. Usually I download the table and use it almost as is.

[Jollyfant]

Yeah no space on the screen, I will put it in the download. It's been too long.. two approaches:

1. calculate mean direction and calculate VGP from there.
2. calculate individual poles and calculate mean VGP from there.

I am using number 2 which I suppose is right..

[Jollyfant]

Pushed change to beta. Wanna check? :)

[dpastorgalan]

I guess this can be close. Everything works.