examples: interactive earthquakes

[pared]

Please:

• Make the pull requests (PRs) atomic (fix one issue at a time). Multiple relevant issues that must be fixed together? Make atomic commits so we can easily review each issue.
• Provide a concise title as a semantic commit message (e.g. "fix: correctly handle undefined properties") so we can easily copy it to the release note.
  • Use imperative mood and present tense.
• Mention relevant issues in the description (e.g., Fixes #1 / Fixes part of #1).
• Lint and test (Run yarn test).
• If you send a pull request from a fork, make sure that GitHub actions run successfully. Make sure to add a GH_PAT secret for a personal access token with public repository permissions.
• Review your changes before sending the PR (to ensure code quality).
• For new features:
  • Add new unit tests.
  • Update the documentation under site/docs/ + add examples.

Tips:

• https://medium.com/@greenberg/writing-pull-requests-your-coworkers-might-enjoy-reading-9d0307e93da3 is a nice article about writing a nice PR.
• Use draft PR for work in progress PRs / when you want early feedback (https://github.blog/2019-02-14-introducing-draft-pull-requests/).

Related to #1486.
Reimplementing the earthquakes example in vega-lite.
I did not find it in existing examples.
I would like to ask for some feedback, as I have a problem with scaling the earthquakeSize, I am unable to find an option that would allow me to control the pointRadius from the projection using the magnitude obtained from datapoints properties. I have been playing around with standard circle mark but in that case it seems that points have priority over earth projection making the image unclear.

I would love some feedback how to progress with this one, as I could not find vega-lite example touching similar problem.

[pared]

Sorry, I intended to make it draft PR, but did not do that in the end. Should close this one and open a new one?

[mattijn]

Related: #3396

pointRadius is not supported yet in VL.

If using mark_circle you'll need to filter the bubbles based lat/lon. For rotate0 this is (rotate0 * -1) - 90 < datum.lon && datum.lon < (rotate0 * -1) + 90.

See also observablehq variant (edit cell to see the VL) https://observablehq.com/@domoritz/earthquakes-in-vega-lite

And altair created-variant: https://deploy-preview-1--spontaneous-sorbet-49ed10.netlify.app/user_guide/marks/geoshape.html#expression

[domoritz]

I converted it to a draft.

[pared]

I spent some time trying to make the scale similar to the original vega plot. The results are in the current version of the branch.

[domoritz]

Looks great otherwise.

[pared]

Thanks, @domoritz. if i want to contribute more, should I go for more examples or start looking at the issues?

[domoritz]

I think looking at issues would be great. Feel free to ask questions on the issues or on slack.

[github-actions]

🚀 PR was released in v5.3.0-next.4 🚀

[mattijn]

side-note: I was wondering how you'd done the rotate1 expression, since I couldn't get it to work in all edge-cases. I notice you run into the same issues as I did when I was experimenting with this (and therefor I did not include rotate1).

Observe the west coast of north america in this animated gif:

Open the Chart in the Vega Editor

Still a nice example though!

[pared]

@mattijn I was playing around with it but I guess I did not get into this edge case. I should probably give it a little bit more though.

EDIT:
I will spend some time and try to figure out how to fix this.

[pared]

So I tried fixing this issue by trying to calculate the angle from which the "observer" looks at the map. Longitude and latitude are just angles projected to 2d panes. If we were able to determine a single 3D angle from the (0,0) axis, knowing from what angle the observer looks at the earth (thanks to rotation values), we could filter which data points should be visible.

The problem with this approach is that when I try to work it out using trigonometry, I end up with a quadratic equation, basically allowing for 2 angles to be a solution (one per "visible" and "hidden" half of the sphere), making my solution worthless. Not sure if my calculations are relevant here, if someone needs them I can try to prepare some notes.

If someone has an idea of how to approach this problem, I would love to pursue this further.

[jwoLondon]

I am not convinced that attempting to filter points based on manual calculation of the projection view is the way to go. As well as the edge cases highlighted above, it makes it rather fragile being dependent on the particular projection used. The more robust general solution is to rely on normal projection clipping where we can (as the original Vega example did).

It should be noted that pointRadius has been available since VL5 so there are possibilities there. Here, is a simple example that allows two-axis rotation and global setting of symbol size. It uses the original geoJSON representation of earthquake sites rather than extracting the long/lat point coordinates.

The problem is that unlike Vega, it is not possible to include data-driven parameterisation in expressions, so using this approach doesn't additionally scale symbols by magnitude.

However, you can encode the magnitude data with other aspects of the point symbolisation including colour. While size encoding doesn't work, strokeWidth does, so it is possible to set a data driven point size while representing earthquake sites as geoJSON. Here is an example. It is not perfect because as stroke width is reduced, symbol size tends towards a constant, but perhaps worth considering as an alternative.

And as a cartographic aside, I am personally not convinced of the effectiveness of an orthographic projection for these kinds of data. Why not show the whole globe at once, for example with an equalEarth projection:

[pared]

Thanks @jwoLondon! I guess i got fixated on filtering. Ill get back to projection.