KML error with non-earth ellipsoid #6176
Comments
|
Thanks @tamarmot! While we do support non-earth ellipsoids, it's one of the areas that is least tested because most of our users are using WGS84. As a workaround, setting |
|
Now that is a clever hack ... er ... workaround! Thanks!
…On Thu, Feb 1, 2018 at 12:18 PM, Hannah ***@***.***> wrote:
Thanks @tamarmot <https://github.com/tamarmot>! While we do support
non-earth ellipsoids, it's one of the areas that is least tested because
most of our users are using WGS84.
If you find any more issues, let us know!
As a workaround, setting Cesium.Ellipsoid.WGS84 = new Cesium.Ellipsoid(x,
y, z) should fix most problems
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6176 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFgK8Kg8rcuSqfdWJw2IDTY2EAPnKxQGks5tQhv7gaJpZM4R2MwY>
.
|
hpinkos
changed the title
|
For the record, making that change does not correct this issue ... |
|
... because it is hardcoded in Cartesian3: maybe not so flexible ... |
|
Ah yeah. We had to do that because the If you have time, we'd be happy to review a PR with the KML fix! |
|
Just wanted to stop in and say hi, @tamarmot! But now that I'm here, that's definitely a bug (KmlDataSource should not be using |
|
Thanks guys! I just pushed some code in my fork to fix it -- I will do a
little testing and then a pull request.
WHILE YOU ARE LOOKING AT THIS, @mramato, what I'm really working on is
polar stereographic projection on the moon:
https://groups.google.com/forum/#!topic/cesium-dev/e_osjMgHD4E
I know this is off topic but if you have a chance to make suggestions that
would be very helpful. Once I solve this I would love to contribute it.
I've done what I thought was the "hard part", namely the projecting
to/from, but the bounds of my tiles are drawing in the wrong place.
Thanks! I'm having so much fun with Cesium.
Tamar
p.s. and my fix does not refactor your dependency on
Cartesian3.fromDegrees, just passes along the ellipsoid.
…On Thu, Feb 1, 2018 at 12:37 PM, Matthew Amato ***@***.***> wrote:
Just wanted to stop in and say hi, @tamarmot <https://github.com/tamarmot>
!
But now that I'm here, that's definitely a bug (KmlDataSource should not
be using Cartesian3.fromDegrees, or any of our internal code for that
matter). We have those hardcoded values purely because it lets us provide
that helper function for end users, but internally it's a no go.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6176 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFgK8JFTCzN142o-TYKzu9bGTqVBcerDks5tQiCigaJpZM4R2MwY>
.
|
|
Are there instructions somewhere for doing a development npm build?
Doing this (from my fork):
npm install git+https://[email protected]/xgds/cesium.git
completely broke my webpack process, which works when I use the regularly
released npm cesium.
Thanks
Tamar
…On Thu, Feb 1, 2018 at 12:51 PM, Tamar Cohen ***@***.***> wrote:
Thanks guys! I just pushed some code in my fork to fix it -- I will do a
little testing and then a pull request.
WHILE YOU ARE LOOKING AT THIS, @mramato, what I'm really working on is
polar stereographic projection on the moon:
https://groups.google.com/forum/#!topic/cesium-dev/e_osjMgHD4E
I know this is off topic but if you have a chance to make suggestions that
would be very helpful. Once I solve this I would love to contribute it.
I've done what I thought was the "hard part", namely the projecting
to/from, but the bounds of my tiles are drawing in the wrong place.
Thanks! I'm having so much fun with Cesium.
Tamar
p.s. and my fix does not refactor your dependency on
Cartesian3.fromDegrees, just passes along the ellipsoid.
On Thu, Feb 1, 2018 at 12:37 PM, Matthew Amato ***@***.***>
wrote:
> Just wanted to stop in and say hi, @tamarmot
> <https://github.com/tamarmot>!
>
> But now that I'm here, that's definitely a bug (KmlDataSource should not
> be using Cartesian3.fromDegrees, or any of our internal code for that
> matter). We have those hardcoded values purely because it lets us provide
> that helper function for end users, but internally it's a no go.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6176 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFgK8JFTCzN142o-TYKzu9bGTqVBcerDks5tQiCigaJpZM4R2MwY>
> .
>
|
|
Hi @tamarmot, we just pushed an npm fix about half an hour ago - https://www.npmjs.com/package/cesium I'm running the build right now with our recommended webpack configuration to see if that is working. |
|
Thanks Gabby!
…On Thu, Feb 1, 2018 at 1:31 PM, Gabby Getz ***@***.***> wrote:
Hi @tamarmot <https://github.com/tamarmot>, we just pushed an npm fix
about half an hour ago - https://www.npmjs.com/package/cesium
I'm running the build right now with our webpack configuration
<https://github.com/AnalyticalGraphicsInc/cesium-webpack-example> to see
if that is working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6176 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFgK8JVkquWvrCoQ6M3H0haxqJXSrAflks5tQi1OgaJpZM4R2MwY>
.
|
|
Sorry -- that didn't answer my question -- is there documentation for how I
can take my fork and npm-ify it so I can test it in my environment before I
do a pull request?
Thanks
Tamar
…On Thu, Feb 1, 2018 at 1:32 PM, Tamar Cohen ***@***.***> wrote:
Thanks Gabby!
On Thu, Feb 1, 2018 at 1:31 PM, Gabby Getz ***@***.***>
wrote:
> Hi @tamarmot <https://github.com/tamarmot>, we just pushed an npm fix
> about half an hour ago - https://www.npmjs.com/package/cesium
>
> I'm running the build right now with our webpack configuration
> <https://github.com/AnalyticalGraphicsInc/cesium-webpack-example> to see
> if that is working.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6176 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFgK8JVkquWvrCoQ6M3H0haxqJXSrAflks5tQi1OgaJpZM4R2MwY>
> .
>
|
|
Looking forward to your PR @tamarmot! You can find a bunch of contributor documentation here: https://github.com/AnalyticalGraphicsInc/cesium/tree/master/Documentation/Contributors To run the tests, run |
|
fixed by my pull request ... |
|
Congratulations on closing the issue! I found these Cesium forum links in the comments above: https://groups.google.com/forum/#!topic/cesium-dev/e_osjMgHD4E If this issue affects any of these threads, please post a comment like the following:
I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome. 🌍 🌎 🌏 |
I am loading some KML to render on my moon ellipsoid. When I look at the coordinate conversion in KmlDataSource, I see that it is not using any ellipsoid to calculate the coordinates.
For example, with:
longitude: 24.070617695061806
latitude:87.90173269295278
I get coordinates:
Cartesian3 {x: 213935.5635247161, y: 95566.36983235707, z: 6352461.425213023}
instead of lunar coordinates:
Cartesian3 {x: 58080.7702560248, y: 25945.04756005268, z: 1736235.0758562544}
I suggest the constructor for a KmlDataSource takes an option for an ellipsoid, which is then used for every single Cartesian3.fromDegrees call.
The text was updated successfully, but these errors were encountered: