Hello,
How about the global approach with emulating double-precision webGL
shown in Double precision on WebGL for mapping centimetric points #54.

Hi @kkdd.
Yeh, double precision in WebGL would be a better solution overall as it would give high precision for the whole map. Although, I don't know enough about shaders to do this, also it might affect the performance of the plugin as a lot more computation is being done in the shader.

The solution in this pull request doesn't change the shaders in any way and will have a negligible impact on performance as it is only changing a few lines of code. It should be enough for most use cases.

Whatever the case, this is what I am using to plot high precision points, so thought I'd share it with the group.

Hello, RayLarone. Thank you for your comment.
I see that the performance should also be important factor, as you mentioned.

This PR breaks unit tests. Could you fix those, and commit? Then I can merge.

Hi @robertleeplummerjr. Sure, although apologies, I'm a data analyst not a programmer so maybe I'm not fully understanding the unit testing. What do you mean by this pull request breaks unit tests?

When I clone this branch, run npm i and then yarn test I get the message:

Test Suites: 11 passed, 11 total
Tests:       249 passed, 249 total
Snapshots:   0 total
Time:        5.696 s
Ran all test suites.
Done in 6.85s.

How can I see which unit tests need addressing so I can fix the issues?

Perhaps I had a premature failure when I tested it. I'm away this week but next I'll look into merging.

@robertleeplummerjr please look into merging again :)

The build and tests run without errors for me.

If the map is initialised at [0, 0], for example, rendered with glify, and then panTo the shapes at [50, 0] far from [0, 0], the mapCenterPixels won't be updated and the polygons will be distorted. Are we sure map.getCenter() is the right way, if glify won't update and re-render? For optimisation, If any shapes are visible in the map, the centre point should be close to the shapes themselves.

@shenzhuxi Yes, you are correct. I suggested this method with the assumption it is unlikely people would need centimetre precision for layers spanning multiple countries/continents (although it's not out of the question). And having the the origin at map.getCentre() was better than where it was by default. A better approach would probably be to have a different origin at the centre of each layer so layers plotted in different parts of the world will retain a local precision.

I have subsequently found out that deck gl has identified a similar problem and includes a solution with different coordinate systems like "lnglat_offsets" (https://deck.gl/docs/developer-guide/coordinate-systems) where you are required to input the "coordinateOrigin" yourself. Maybe something to model this off.

@RayLarone We tested using each shape's centre point instead of map.getCenter() and it seems work fine.
https://github.com/Highway-Data-Systems/hds.glify/tree/fix/shape-project-center
We can create a PR, If that's a reasonable salutation.

@shenzhuxi
It sounds great.
Is it better than the global approach with emulating double-precision webGL, which I have mentioned?

@RayLarone We tested using each shape's centre point instead of map.getCenter() and it seems work fine.
https://github.com/Highway-Data-Systems/hds.glify/tree/fix/shape-project-center
We can create a PR, If that's a reasonable salutation.