Skip to content

Conversation

@johannesvollmer
Copy link

This took me 1 day to find out. I assumed the toRadians() was needed, but it must be removed.

@johannesvollmer
Copy link
Author

Please help, I somehow cannot run the scripts. I have installed the ocular-dev-tools but it throws an error.

PS C:\Users\JohannesVollmer\Documents\Github\mathgl> npm run lint fix

> lint
> ocular-lint fix

The filename, directory name, or volume label syntax is incorrect.

@johannesvollmer johannesvollmer changed the title Fixed documentation (it said radians, but code uses degrees) Fix documentation: It said radians, but code uses degrees! Aug 13, 2025
@chrisgervang chrisgervang self-assigned this Aug 26, 2025
@chrisgervang
Copy link

ocular-dev-tools is published as @vis.gl/dev-tools on NPM now (the old bin names were kept to avoid breaking things), and its included in package.json. yarn bootstrap && yarn lint fix should do it

Copy link

@chrisgervang chrisgervang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for catching this. Tagged the others to sanity check this since using radians vs degrees incorrectly is usually noticeable.. I'm surprised it changed but didn't get documented

@johannesvollmer
Copy link
Author

johannesvollmer commented Aug 27, 2025

Thanks! :)
I have a test prototyped for making sure it's degrees :) I could push it too once I get it to run

@johannesvollmer
Copy link
Author

johannesvollmer commented Aug 27, 2025

I can't get it to run:

Github\mathgl> yarn lint fix
yarn run v1.22.22
$ ocular-lint fix
The filename, directory name, or volume label syntax is incorrect.
error Command failed with exit code 1.

I can see the ocular-lint.cmd file in node_modules/bin, but apparently my machine can't for some reason, or something else is wrong. Unfortunately, the error message is not very helpful, so it's hard for me to pinpoint the problem

Tried inside PowerShell and WSL Ubuntu.

@johannesvollmer
Copy link
Author

johannesvollmer commented Aug 27, 2025

This integration test should prove it (I placed it inside geospatial/test/ellispoid.spec.ts)

test('Ellipsoid WGS84 east north up matches expected distance between two known points', (t) => {
  const berlinGateLocation = [13.377683495290393, 52.516333017115834, 93]; // this is the real degrees location
  const berlinMuseum = [13.381635343814912, 52.51696824798868, 93]; // this is the real degrees location
  const expectedEastMetersFromGateToMuseum = 263; // this is the real measured east difference (approximately)
  const expectedNorthMetersFromGateToMuseum = 55; // this is the real measured north difference (approximately)

  const originEcef = Ellipsoid.WGS84.cartographicToCartesian(berlinGateLocation);
  const targetEcef = Ellipsoid.WGS84.cartographicToCartesian(berlinMuseum);
  const enuToEcef = Ellipsoid.WGS84.eastNorthUpToFixedFrame(originEcef, new Matrix4());
  const ecefToEnu = enuToEcef.invert();

  const [east, north, up,] = targetEcef.clone().transformAsPoint(ecefToEnu);
  tapeEqualsEpsilon(t, east, expectedEastMetersFromGateToMuseum, 10);
  tapeEqualsEpsilon(t, north, expectedNorthMetersFromGateToMuseum, 10);
  tapeEqualsEpsilon(t, up, 0, 1);
  t.end();
});

I did not run this one (so it might not pass first time due to inaccuracies in the measurements), but the same code works in my current project without problems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants