You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fonction turf/ellipse has the good behavior when plotting small ellipses at low lattitudes.
However when plotting "big ellipses" close to the poles, the earth curvature is poorly taken into account, leading to problems with the resulting geometry.
const p = turf.point(
[0., 60.]
);
const c = turf.polygon(turf.circle(p, 2000).geometry.coordinates, {fill: '#0FF'});
const e = turf.polygon(turf.ellipse(p, 2000, 2000).geometry.coordinates, {fill: '#ff0000'});;
return turf.featureCollection([c, e]);
The two geometries should be exactly superimposed. Furthermore, taking the projection into account would mean having a “wider” ellipse on this projection near the pole than near the equator, which is not the case. This is due to the use of rhubDestination instead of destination (which uses the Harvesine formula), which leads to an incorrect calculation of the coordinates of the points of the ellipse.
This second example shows an other issue :
const p = turf.point(
[0., 60.]
);
const c = turf.polygon(turf.ellipse(p, 2000, 2000, {angle: 0}).geometry.coordinates, {fill: '#0FF'});
const e = turf.polygon(turf.ellipse(p, 2000, 2000, {angle: 90}).geometry.coordinates, {fill: '#ff0000'});;
return turf.featureCollection([c, e]);
Once more, both geometry should be exactly superimposed. This time, the imprecision is due to the fact that the geometry is rotated once being completly calculated. This leads to bad behavior because it does not respect the projection.
The text was updated successfully, but these errors were encountered:
Thanks for raising this @hadbn. Did a quick and dirty replacement using destination() instead of rhumbDestination() and got the below (blue - circle, red - 7.1.0 ellipse, yellow - my ellipse)
Different, though still not correct. So there might be a bit more going on.
Ok, think I've got it. Below are two ellipses (1000x2000) with origins at [0, 0] and [0, 60].
It looks like ellipse() generates the points as if the x and y coordinate were uniform, like on grid paper. Except x and y are actually degrees longitude and latitude, meaning as you get further North each longitude grid division gets narrower. This is why the Northern ellipse squashes toward the top.
What do you think? Would that explain it? I'm not sure though why it's bigger overall than the equatorial one.
I agree with your interpretation. Changing from rhumbDestination to destination was needed yet it was not the only problem.
I'm not sure though why it's bigger overall than the equatorial one.
-> According to me, both x and y are streched when going North or South from the equator. So two circles having the same radius will not look the same on the projection we use, when one is closer to the pole than the other.
For instance :
const c = turf.polygon(turf.circle([0., 0.], 2000).geometry.coordinates, {fill: '#0FF'});
const e = turf.polygon(turf.circle([0., 60.], 2000).geometry.coordinates, {fill: '#ff0000'});;
return turf.featureCollection([c, e]);
will result in :
I opened a pull request with all the changes that are -in my opinion- necessary to resolve this issue : #2739
The fonction turf/ellipse has the good behavior when plotting small ellipses at low lattitudes.
However when plotting "big ellipses" close to the poles, the earth curvature is poorly taken into account, leading to problems with the resulting geometry.
Reproduced with Turf version 7.1 running at https://turf-sandbox.netlify.app/ with the following code :
The two geometries should be exactly superimposed. Furthermore, taking the projection into account would mean having a “wider” ellipse on this projection near the pole than near the equator, which is not the case. This is due to the use of
rhubDestination
instead ofdestination
(which uses the Harvesine formula), which leads to an incorrect calculation of the coordinates of the points of the ellipse.This second example shows an other issue :
Once more, both geometry should be exactly superimposed. This time, the imprecision is due to the fact that the geometry is rotated once being completly calculated. This leads to bad behavior because it does not respect the projection.
The text was updated successfully, but these errors were encountered: