## DrawFromCSV - adding ellipses

**Moderators:** andrew, Husky, J-J

### DrawFromCSV - adding ellipses

If I can just add a little capability to the DrawFromCSV package, QCAD is going to be a fantastic solution to my project.

Win 10, QCAD 3.27.9.0 build date Jan 16 2023

I need to add the ability to draw ellipses and elliptical paths from data in CSV files.

The demo works fine, and has a section for drawing a circle and I am using that as a code source. My googling is turning up nothing useful. This should be simple but I am unable to add a section of code for an ellipse.

existing code:

case "CIRCLE":

// Create new circle shape:

try {

refRv = new RVector(parseFloat(fields[1]), parseFloat(fields[2]));

newShape = new RCircle(refRv, parseFloat(fields[3]));

}

catch(err) { // On an error reset shape:

newShape = undefined;

}

break;

one of the many things I tried:

case "ELLIPSE":

// Create new ellipse shape:

try {

refRv1 = new RVector(parseFloat(fields[1]), parseFloat(fields[2]));

refRv2 = new RVector(parseFloat(fields[3]), parseFloat(fields[4]));

refRv3 = new RVector(parseFloat(fields[5]), parseFloat(fields[6]));

newShape = new REllipse(refRv1,refRv2,refRv3);

}

catch(err) { // On an error reset shape:

newShape = undefined;

}

break;

with the following line 43 added to the bottom of the demo's CSV file:

ellipse,50.0,50.0,75.0,75.0,90.0,90.0

because it looks like the ellipse command wants three coordinates, and three vectors should supply that.

Obv I do not know what I am doing with the javascript.

I get "not a correct entry, line 43"

I am not finding anything in my searches to guide me on the actual javascript. I tried lots of things, I just posted this to get started.

TIA

Win 10, QCAD 3.27.9.0 build date Jan 16 2023

I need to add the ability to draw ellipses and elliptical paths from data in CSV files.

The demo works fine, and has a section for drawing a circle and I am using that as a code source. My googling is turning up nothing useful. This should be simple but I am unable to add a section of code for an ellipse.

existing code:

case "CIRCLE":

// Create new circle shape:

try {

refRv = new RVector(parseFloat(fields[1]), parseFloat(fields[2]));

newShape = new RCircle(refRv, parseFloat(fields[3]));

}

catch(err) { // On an error reset shape:

newShape = undefined;

}

break;

one of the many things I tried:

case "ELLIPSE":

// Create new ellipse shape:

try {

refRv1 = new RVector(parseFloat(fields[1]), parseFloat(fields[2]));

refRv2 = new RVector(parseFloat(fields[3]), parseFloat(fields[4]));

refRv3 = new RVector(parseFloat(fields[5]), parseFloat(fields[6]));

newShape = new REllipse(refRv1,refRv2,refRv3);

}

catch(err) { // On an error reset shape:

newShape = undefined;

}

break;

with the following line 43 added to the bottom of the demo's CSV file:

ellipse,50.0,50.0,75.0,75.0,90.0,90.0

because it looks like the ellipse command wants three coordinates, and three vectors should supply that.

Obv I do not know what I am doing with the javascript.

I get "not a correct entry, line 43"

I am not finding anything in my searches to guide me on the actual javascript. I tried lots of things, I just posted this to get started.

TIA

### Re: DrawFromCSV - adding ellipses

In a way I should say thanks for your request ...

Remark that ellipses (...arcs) were not added because I had no mathematical grounds for it by spreadsheet data.

I don't see how I can work with ellipse shapes, intersections or endpoints in a simple way.

But sure, creation of the basic shapes can be added if of any use to someone.

First lets have a look at the signature of the Ellipse RShape:

https://qcad.org/doc/qcad/3.0/developer ... 0849e1b777

Remark that I use a Code display.
Thus, to draw an ellipse (arc) we need 2 vectors, 3 values and a boolean.

The creation of newShape fails, the shape is reset and further down no entity is created and a warning is displayed.

If we didn't catch the error then the script would halt on failing the creation of the RShape. QCAD would hang.

I think you want to draw a full ellipse by 3 points like with the QCAD GUI command

For Ellipse Arcs the question remains if we want to use common angles or elliptic parameters ...

The ratio can be sourced from the distance between center & majorPoint in relation to the distance between center & minorPoint.

For a full ellipse the startParam is zero and the endParam is 2pi and reversed is false.

These things can be calculated or set by the spreadsheet too.

But like with arcs and circles there are different approaches possible.

I am not sure where you sourced the Circle code from but present art can be found here:

https://github.com/qcad/qcad/blob/maste ... SV.js#L858

DrawFromCSV is part of the standard QCAD releases since Apr 7, 2021 and was updated on Nov 22, 2021.

Further updates were made by Andrew as part of the ongoing porting to qt6.

You may notice that newer art verifies inputs more strictly and warnings are more comprehensive.

The advise is to use the latest art because of several minor bug fixes.

I may have a look at this in the upcoming week(s) ....

The goal is then to patch it for full ellipses and ellipse arcs but it may take a while before it is implemented in QCAD.

Of course we can always supersede the standard implementation for the time being.

Please elaborate somewhat the requirements ...

Regards,

CVH

Remark that ellipses (...arcs) were not added because I had no mathematical grounds for it by spreadsheet data.

I don't see how I can work with ellipse shapes, intersections or endpoints in a simple way.

But sure, creation of the basic shapes can be added if of any use to someone.

First lets have a look at the signature of the Ellipse RShape:

https://qcad.org/doc/qcad/3.0/developer ... 0849e1b777

Remark that I use a Code display.

Code: Select all

`REllipse (const RVector ¢er, const RVector &majorPoint, double ratio, double startParam, double endParam, bool reversed)`

The creation of newShape fails, the shape is reset and further down no entity is created and a warning is displayed.

If we didn't catch the error then the script would halt on failing the creation of the RShape. QCAD would hang.

I think you want to draw a full ellipse by 3 points like with the QCAD GUI command

**EP**, is that right?For Ellipse Arcs the question remains if we want to use common angles or elliptic parameters ...

The ratio can be sourced from the distance between center & majorPoint in relation to the distance between center & minorPoint.

For a full ellipse the startParam is zero and the endParam is 2pi and reversed is false.

These things can be calculated or set by the spreadsheet too.

But like with arcs and circles there are different approaches possible.

I am not sure where you sourced the Circle code from but present art can be found here:

https://github.com/qcad/qcad/blob/maste ... SV.js#L858

DrawFromCSV is part of the standard QCAD releases since Apr 7, 2021 and was updated on Nov 22, 2021.

Further updates were made by Andrew as part of the ongoing porting to qt6.

You may notice that newer art verifies inputs more strictly and warnings are more comprehensive.

The advise is to use the latest art because of several minor bug fixes.

I may have a look at this in the upcoming week(s) ....

The goal is then to patch it for full ellipses and ellipse arcs but it may take a while before it is implemented in QCAD.

Of course we can always supersede the standard implementation for the time being.

Please elaborate somewhat the requirements ...

Regards,

CVH

Last edited by CVH on Sun Feb 12, 2023 8:13 pm, edited 1 time in total.

### Re: DrawFromCSV - adding ellipses

Thank you very very much for the help. This project has been a long saga because I am such a mediocre, brute force, old old school programmer. I just need some help getting over this "last" hurdle.

I am all over the math of an ellipse, however. I will have little trouble generating the parameter values needed once I know what the code needs to see for input.

The only language I am proficient in and able to actually run is LISP. Back in the day I would make AutoCAD dance using AutoLISP. I have spent thousands of hours running many different CAD packages in my career.

What I am doing is Orbital Mechanics. I have developed an algorithm to calculate elliptical paths to transfer between planets and asteroids, also transfers within Earth Orbit. I have at long last generated the data which gives the solutions for particular dates and targets, in particular going to Mars. This is currently in the form of a line of CSV data for each path, with about 24 data fields for a totally complete description of the solution. It will be a trivial matter to use LISP to generate a line of data to match the requirements of the Ellipse path command.

The path solutions are generated but I am not going to be able to be confident in them until I graphically plot them and visually inspect them. QCAD and DrawFromCSV to the rescue? (Also I have no money budget, just time.)

I just need to understand how to go from your link, the 'signature' of the command, to js code.

I need to draw complete ellipses and also elliptical paths.

If DrawFromCSV is now part of the main code, I freak out a little bit because to edit the code I suppose I will need to become a 'developer' and I am not one of you guys. Hacking this add-on js is much more in my wheelhouse. For instance, I see your link is to . . . QCAD/3.0/developer . . . which I suppose explains why I could not find that info myself.

Thanks for your time, it is hard to explain how much it means to me.

I am all over the math of an ellipse, however. I will have little trouble generating the parameter values needed once I know what the code needs to see for input.

**I think it's just a matter of forming the js code properly for the input fields**. For example, I am not sure that a vector is the same thing as a coordinate pair. If the vector originates from the origin, the non-zero coordinate pair might or might not be seen by the software as a point value. I apologize for being such a newb to QCAD that something that simple is not clear.The only language I am proficient in and able to actually run is LISP. Back in the day I would make AutoCAD dance using AutoLISP. I have spent thousands of hours running many different CAD packages in my career.

What I am doing is Orbital Mechanics. I have developed an algorithm to calculate elliptical paths to transfer between planets and asteroids, also transfers within Earth Orbit. I have at long last generated the data which gives the solutions for particular dates and targets, in particular going to Mars. This is currently in the form of a line of CSV data for each path, with about 24 data fields for a totally complete description of the solution. It will be a trivial matter to use LISP to generate a line of data to match the requirements of the Ellipse path command.

The path solutions are generated but I am not going to be able to be confident in them until I graphically plot them and visually inspect them. QCAD and DrawFromCSV to the rescue? (Also I have no money budget, just time.)

I just need to understand how to go from your link, the 'signature' of the command, to js code.

I need to draw complete ellipses and also elliptical paths.

If DrawFromCSV is now part of the main code, I freak out a little bit because to edit the code I suppose I will need to become a 'developer' and I am not one of you guys. Hacking this add-on js is much more in my wheelhouse. For instance, I see your link is to . . . QCAD/3.0/developer . . . which I suppose explains why I could not find that info myself.

Thanks for your time, it is hard to explain how much it means to me.

### Re: DrawFromCSV - adding ellipses

TIA,

no problems at all, I wrote and donated it and Andrew integrated it in QCAD.

It is an extremely versatile and powerful bridge between math in Excel and drawings in QCAD for me.

See 'Developers' on : https://www.ribbonsoft.com/en/documentation

See https://www.ribbonsoft.com/doc/qcad/latest/developer/

Everyone that can write a functional QCAD script is basically a developer.

All the open source scripts can be found on GitHub: https://github.com/qcad/qcad

For example ... A full ellipse by:

- 3 points ... 2 points and ratio

- Center and radii or diameters plus an angle

... An ellipse arc by one of the above and end-angles or -parameters.

Endpoints will be an issue, fit-points too, but maybe we can learn something from you.

Don't bother, the script will validate the coordinate pair and construct an RVector what in essence is a zero based vector in QCAD.

Here is the RVector Class Reference:

https://qcad.org/doc/qcad/3.0/developer ... ector.html

DrawFromCSV has drawn its first full ellipse 2D shape ever just minutes ago.

I expanded the latest art with that.

Next is an ellipse arc with end angles but that is for tomorrow.

Regards,

CVH

no problems at all, I wrote and donated it and Andrew integrated it in QCAD.

It is an extremely versatile and powerful bridge between math in Excel and drawings in QCAD for me.

QCAD is open source, the link points to a place within all the open source modules, classes and so on.

See 'Developers' on : https://www.ribbonsoft.com/en/documentation

See https://www.ribbonsoft.com/doc/qcad/latest/developer/

Everyone that can write a functional QCAD script is basically a developer.

All the open source scripts can be found on GitHub: https://github.com/qcad/qcad

OK, but you need to be more specific.

For example ... A full ellipse by:

- 3 points ... 2 points and ratio

- Center and radii or diameters plus an angle

... An ellipse arc by one of the above and end-angles or -parameters.

Endpoints will be an issue, fit-points too, but maybe we can learn something from you.

DrawFromCSV uses all values and or text, things that can be stored in spreadsheet cells.

Don't bother, the script will validate the coordinate pair and construct an RVector what in essence is a zero based vector in QCAD.

Here is the RVector Class Reference:

https://qcad.org/doc/qcad/3.0/developer ... ector.html

I'm short of both. But I do this for free in the time I can spare.

Doesn't that require 3D?

DrawFromCSV has drawn its first full ellipse 2D shape ever just minutes ago.

I expanded the latest art with that.

Next is an ellipse arc with end angles but that is for tomorrow.

Regards,

CVH

### Re: DrawFromCSV - adding ellipses

OK this is cool, I am getting a feel for what's going on. I see that it makes more sense for you to add the capability than for me to hack away at old code, since you're willing.

I wasn't worried about error checking because my LISP code will provide totally consistent values, thinking that would make things easier. But I see now that was selfish. If we can add ellipse to the standard software's CSV driven drawing, that would be a very good thing in my book. Others could plot my data on QCAD and otherwise take advantage of the capability.

I will be studying your links today.

[btw TIA = thanks in advance, lol see how old school I am? ]

****

I am happy to write up ellipse math, it's pure recreation for me. copypasta time

This project turned out to be a fabulous vehicle for education. It touches on a lot of fundamentals in math and physics and history. Ultimately I hope to pull it all together in a readable form.

The main formula is Euler's polar equation of an ellipse, and the parameters worked out by Kepler centuries ago.

r = a * (1-e^2) / ( 1 + e * cos(TA))

r = distance (radius) from Sun to satellite

a = semi-major axis

e = eccentricity

TA = True Anomaly angle

E = Eccentric Anomaly angle

p = semi-latus rectum <-- definition

p = a*(1-e^2)

Substitute for p:

r = p / ( 1 + e * cos(TA))

TA = arccos((p / r) – 1) / e)

Another important equation is Kepler's time-of-flight equation but let's set that aside for now.

So the above math is for orbits, a thing following an elliptical path, not just for ellipses. Most ellipse math is in terms of the center of the ellipse, and so is every CAD package I've ever used. The base ellipse command is always based on the center, major radius, minor radius, and orientation.

Orbital math (thanks to Kepler) is based on the occupied node, meaning the Sun's position. Real orbits are never circular, they are eccentric. The sun is not at the center of the ellipse.

https://en.wikipedia.org/wiki/Eccentric_anomaly

There are simple conversion formulas to go from my path solutions in terms of the orientation of the path's underlying ellipse, its semi-major axis and eccentricity, the starting angle, and the ending angle to get CAD parameters. I have starting and ending true anomaly angle values but they are sun-centered, not center-centered. No big deal, I have the formula to convert to eccentric anomaly. The real trick actually is the damn trig functions in LISP and most software.

So. I plan to draw the paths on QCAD like I would for AutoCAD:

1. The coordinates of the center point, found from the angle of periapse plus 180 and r = e * a

2. The orientation angle is the angle of periapse

3. The semi-major axis = a

4. The semi-minor axis = b

5. Start angle

6. End angle

But whatever works! I see no need to do anything but feed the existing commands what they want.

What would be totally amazing but not at all required for my needs is a path drawing function that uses the parameters in the polar equation. IOW moving the conversions from LISP to js. There is no actual need for that for me.

You are good. Yes it is a 3D problem. But there's a trick. First note that my calcs make very few simplifying assumptions. It fully accounts for elliptical orbits which is kind of the whole point. Transfers between circular orbits are trivial and useless. If the 2D simplification added significant error I would not even bother with the whole thing. The base data is from JPL Horizons, the solutions are basically 'exact'.

What I do is off-load the problem to detailed operations planning, requiring that when the spacecraft departs from Earth's orbit, it enters a plane which includes the position of the destination (e.g. Mars) at the time of arrival. The actual path is 2D so this works. If reality forces you to enter some other plane, you make a course correction for plane change, the plane change deltaV value is easily found and the remaining error can be estimated. In any case, using my solutions to compare flight choices is highly accurate.

To be clear, my 2D drawings will technically be a 'diagram' because it will show 3 different planes at once. But this is strictly a graphical simplification. There is no projecting between planes.

Please let me know if you have any questions, not all my posts are this long

Bob

I wasn't worried about error checking because my LISP code will provide totally consistent values, thinking that would make things easier. But I see now that was selfish. If we can add ellipse to the standard software's CSV driven drawing, that would be a very good thing in my book. Others could plot my data on QCAD and otherwise take advantage of the capability.

I will be studying your links today.

[btw TIA = thanks in advance, lol see how old school I am? ]

****

I am happy to write up ellipse math, it's pure recreation for me. copypasta time

This project turned out to be a fabulous vehicle for education. It touches on a lot of fundamentals in math and physics and history. Ultimately I hope to pull it all together in a readable form.

The main formula is Euler's polar equation of an ellipse, and the parameters worked out by Kepler centuries ago.

r = a * (1-e^2) / ( 1 + e * cos(TA))

r = distance (radius) from Sun to satellite

a = semi-major axis

e = eccentricity

TA = True Anomaly angle

E = Eccentric Anomaly angle

p = semi-latus rectum <-- definition

p = a*(1-e^2)

Substitute for p:

r = p / ( 1 + e * cos(TA))

TA = arccos((p / r) – 1) / e)

Another important equation is Kepler's time-of-flight equation but let's set that aside for now.

So the above math is for orbits, a thing following an elliptical path, not just for ellipses. Most ellipse math is in terms of the center of the ellipse, and so is every CAD package I've ever used. The base ellipse command is always based on the center, major radius, minor radius, and orientation.

Orbital math (thanks to Kepler) is based on the occupied node, meaning the Sun's position. Real orbits are never circular, they are eccentric. The sun is not at the center of the ellipse.

https://en.wikipedia.org/wiki/Eccentric_anomaly

There are simple conversion formulas to go from my path solutions in terms of the orientation of the path's underlying ellipse, its semi-major axis and eccentricity, the starting angle, and the ending angle to get CAD parameters. I have starting and ending true anomaly angle values but they are sun-centered, not center-centered. No big deal, I have the formula to convert to eccentric anomaly. The real trick actually is the damn trig functions in LISP and most software.

So. I plan to draw the paths on QCAD like I would for AutoCAD:

1. The coordinates of the center point, found from the angle of periapse plus 180 and r = e * a

2. The orientation angle is the angle of periapse

3. The semi-major axis = a

4. The semi-minor axis = b

5. Start angle

6. End angle

But whatever works! I see no need to do anything but feed the existing commands what they want.

What would be totally amazing but not at all required for my needs is a path drawing function that uses the parameters in the polar equation. IOW moving the conversions from LISP to js. There is no actual need for that for me.

You are good. Yes it is a 3D problem. But there's a trick. First note that my calcs make very few simplifying assumptions. It fully accounts for elliptical orbits which is kind of the whole point. Transfers between circular orbits are trivial and useless. If the 2D simplification added significant error I would not even bother with the whole thing. The base data is from JPL Horizons, the solutions are basically 'exact'.

What I do is off-load the problem to detailed operations planning, requiring that when the spacecraft departs from Earth's orbit, it enters a plane which includes the position of the destination (e.g. Mars) at the time of arrival. The actual path is 2D so this works. If reality forces you to enter some other plane, you make a course correction for plane change, the plane change deltaV value is easily found and the remaining error can be estimated. In any case, using my solutions to compare flight choices is highly accurate.

To be clear, my 2D drawings will technically be a 'diagram' because it will show 3 different planes at once. But this is strictly a graphical simplification. There is no projecting between planes.

Please let me know if you have any questions, not all my posts are this long

Bob

### Re: DrawFromCSV - adding ellipses

Topic moved to: QCAD 'Script Add-On & Plug-in challenge' - Work in Progress

Husky

Husky

Work smart, not hard:

If a thread is considered as "solved" please change the title of the first post to "[solved] Title...". Thanks!

**QCad Pro**If a thread is considered as "solved" please change the title of the first post to "[solved] Title...". Thanks!

### Re: DrawFromCSV - adding ellipses

spacester,

Writing ELLIPTICORBIT method ...

The dataset would then be:

1. The coordinates of the perihelion/periapsis

2. Eccentricity

3. The semi-major axis

4. The semi-minor axis

... and for ellipse arcs

5. Start angle

6. End angle

7. Reversed

But I can use the coordinates of the center point & the orientation angle just the same.

Again drawing origin based.

1. The coordinates of the center point

2. The orientation angle

3. The semi-major axis

4. The semi-minor axis

... and for ellipse arcs

5. Start angle

6. End angle

7. Reversed

What do you prefer?

I am not going to code more methods. A full ellipse starts at zero and ends at 360 degrees not reversed.

Remark that DrawFromCSV uses degrees by default for radians just add 'r' or 'rad' behind the value.

DrawFromCSV doesn't mind lower, upper or mix cases except for names like layer names, then it is literal.

Are we on the same level for this?

What should be considered invalid for A(2,3 and 4) B(3,4) ... Or what are reasonable limits?

... semi axis not zero or less

Regards,

CVH

Writing ELLIPTICORBIT method ...

Then I assume that the center of mass coincides with one focii and that is located at the drawing origin.

The dataset would then be:

1. The coordinates of the perihelion/periapsis

2. Eccentricity

3. The semi-major axis

4. The semi-minor axis

... and for ellipse arcs

5. Start angle

6. End angle

7. Reversed

But I can use the coordinates of the center point & the orientation angle just the same.

Again drawing origin based.

1. The coordinates of the center point

2. The orientation angle

3. The semi-major axis

4. The semi-minor axis

... and for ellipse arcs

5. Start angle

6. End angle

7. Reversed

What do you prefer?

I am not going to code more methods. A full ellipse starts at zero and ends at 360 degrees not reversed.

Remark that DrawFromCSV uses degrees by default for radians just add 'r' or 'rad' behind the value.

DrawFromCSV doesn't mind lower, upper or mix cases except for names like layer names, then it is literal.

Are we on the same level for this?

What should be considered invalid for A(2,3 and 4) B(3,4) ... Or what are reasonable limits?

... semi axis not zero or less

Regards,

CVH

### Re: DrawFromCSV - adding ellipses

The second set for sure. No need to find the perihelion in order to plot the ellipse, it would just be a distraction.

The sun is at one of the foci - the "occupied node".

The ellipse center AND the other foci are just somewhere in space with no physical relevance.

'Center of mass" does not apply, unless you mean the body being orbited, which establishes the gravity "field". So in that sense yes the sun is at one of the foci, the 'occupied node'.

So the drawing origin is the sun and the sun is the occupied node for ALL ellipses and elliptical arcs in the diagram.

Degrees are very much preferred over radians. Trig functions need to be defined from zero to 360 degrees but most languages define them from -90 deg to +90 deg. Sorting that out is done in the LISP code and plotting the results is largely about verifying that my implementation of that is bulletproof.

So yeah, the second dataset, just as you wrote. Perfect.

No negative values for anything.

Angles from zero to 360 deg. Modulo 360 is actually used in LISP to correct for anything out of that range.

I define a special unit system where the length unit is 1.00 AU exactly, where AU is the distance from the sun to Earth after you find the equivalent circular orbit. So the diagram will draw Earth's orbit, which looks almost like a circle of radius 1.0. I mention this because the axis values will be positive and close to 1.0. Pluto is out there at about 40 AU so an upper limit could be 50.0.

I do not believe there will ever be a need for reversing the ellipse. I need to think about that a bit.

I just realized I should get you some values for your testing. I get you that in a few hours.

You are my hero.

Bob

The sun is at one of the foci - the "occupied node".

The ellipse center AND the other foci are just somewhere in space with no physical relevance.

'Center of mass" does not apply, unless you mean the body being orbited, which establishes the gravity "field". So in that sense yes the sun is at one of the foci, the 'occupied node'.

So the drawing origin is the sun and the sun is the occupied node for ALL ellipses and elliptical arcs in the diagram.

Degrees are very much preferred over radians. Trig functions need to be defined from zero to 360 degrees but most languages define them from -90 deg to +90 deg. Sorting that out is done in the LISP code and plotting the results is largely about verifying that my implementation of that is bulletproof.

So yeah, the second dataset, just as you wrote. Perfect.

No negative values for anything.

Angles from zero to 360 deg. Modulo 360 is actually used in LISP to correct for anything out of that range.

I define a special unit system where the length unit is 1.00 AU exactly, where AU is the distance from the sun to Earth after you find the equivalent circular orbit. So the diagram will draw Earth's orbit, which looks almost like a circle of radius 1.0. I mention this because the axis values will be positive and close to 1.0. Pluto is out there at about 40 AU so an upper limit could be 50.0.

I do not believe there will ever be a need for reversing the ellipse. I need to think about that a bit.

I just realized I should get you some values for your testing. I get you that in a few hours.

You are my hero.

Bob

### Re: DrawFromCSV - adding ellipses

i have some data, the coordinates of the ellipse are in polar coordinates

btw I will just be setting the units on the drawing to meters and not worry about a thing with units.

So values are all meters or degrees.

radius, center theta, center Axis angle semimajor semiminor Start Angle (Type A: zero) End angle

0.9834164105 263.8396998538 83.8396998538 1.199051567 1.1795024891 0 179.2573094625

0.9834570365 264.8591042406 84.8591042406 1.1991262045 1.1795721403 0 178.0352326103

0.9835027228 265.878420442 85.878420442 1.1997912308 1.180134839 0 176.0868396499

0.9835534546 266.8976377789 86.8976377789 1.2012047669 1.1813216033 0 173.4118844534

0.9836092152 267.9167449427 87.9167449427 1.2028849935 1.1827300695 0 170.736320883

0.9836699863 268.9357300532 88.9357300532 1.2056328959 1.185024519 0 167.3340837553

0.9837357479 269.9545807631 89.9545807631 1.2097781687 1.1884729679 0 163.2050229186

0.9838064784 270.9732845298 90.9732845298 1.2146676366 1.1925269528 0 159.0731637973

0.9838821544 271.991828921 91.991828921 1.2215961735 1.1982442262 0 154.2110506749

0.983962751 273.0102019608 93.0102019608 1.2297373036 1.2049268262 0 149.3404618591

0.9840482417 274.0283924411 94.0283924411 1.2392193456 1.2126632877 0 144.4576409768

These are very similar arcs, one line of data per departure and one departure at noon each day from Jan 11 2031 to Jan 21 2031 to Mars.

LISP was very friendly with double precision calculations. I just have to change a setting on my first line of code and hey presto everything is calculated in double-float mode. These calculations for sure need as much precision as possible. but of course we can drop all the digits we want for plotting graphics.

In fact . .

ELLIPTICORBIT,0.983,263.839,83.839,1.199,1.179,0.0,179.257

btw I will just be setting the units on the drawing to meters and not worry about a thing with units.

So values are all meters or degrees.

radius, center theta, center Axis angle semimajor semiminor Start Angle (Type A: zero) End angle

0.9834164105 263.8396998538 83.8396998538 1.199051567 1.1795024891 0 179.2573094625

0.9834570365 264.8591042406 84.8591042406 1.1991262045 1.1795721403 0 178.0352326103

0.9835027228 265.878420442 85.878420442 1.1997912308 1.180134839 0 176.0868396499

0.9835534546 266.8976377789 86.8976377789 1.2012047669 1.1813216033 0 173.4118844534

0.9836092152 267.9167449427 87.9167449427 1.2028849935 1.1827300695 0 170.736320883

0.9836699863 268.9357300532 88.9357300532 1.2056328959 1.185024519 0 167.3340837553

0.9837357479 269.9545807631 89.9545807631 1.2097781687 1.1884729679 0 163.2050229186

0.9838064784 270.9732845298 90.9732845298 1.2146676366 1.1925269528 0 159.0731637973

0.9838821544 271.991828921 91.991828921 1.2215961735 1.1982442262 0 154.2110506749

0.983962751 273.0102019608 93.0102019608 1.2297373036 1.2049268262 0 149.3404618591

0.9840482417 274.0283924411 94.0283924411 1.2392193456 1.2126632877 0 144.4576409768

These are very similar arcs, one line of data per departure and one departure at noon each day from Jan 11 2031 to Jan 21 2031 to Mars.

LISP was very friendly with double precision calculations. I just have to change a setting on my first line of code and hey presto everything is calculated in double-float mode. These calculations for sure need as much precision as possible. but of course we can drop all the digits we want for plotting graphics.

In fact . .

ELLIPTICORBIT,0.983,263.839,83.839,1.199,1.179,0.0,179.257

### Re: DrawFromCSV - adding ellipses

Busy with it but I still have to test ellipses and ellipse arcs in further detail.

I don't want DrawFromCSV to return false positive errors or fail big time.

The danger of automating stuff is that we don't verify the intermediate data/data-structure anymore.

DrawFromCSV validates every CSV data field to match the requirements of the instruction.

DrawFromCSV will do the same when validating an angle field with RMath.getNormalizedAngle ... In radians.

Internally everything is in radians, trig functions, entity methods and so on. (up to 2 extra digits accuracy, see floating point below)

Still, angle properties in the QCAD GUI are displayed in degrees.

There is no actually reasonable limit for angle floating point values but the double precision and usually they are normalized to within -2pi to 2pi.

The return of trig functions is also within -2pi to 2pi.

By definition forward is CCW and reversed is CW.

Maybe I make an exception and let it default to 'false' if omitted ... DrawFromCSV is strict about the CSV field count.

I understand and always better for floating point operations.

Values within 0-99 will have about 14 decimal digits.

Values in the ballpark of 149597870.7km only 5 or 6. In meter that is 3 less.

I have to remark that AU is not up to date in QCAD:

https://qcad.org/rsforum/viewtopic.php?t=9506&p=38295

On the follow up ...

Radius, Center theta, Center Axis angle, Semimajor, Semiminor, Start Angle, (Type A: zero), End angle

Is a different signature as:

Doesn't really matter because an RVector can be created from XY or from polar with the same ease.

But you really need to decide what the final signature for EllipticOrbit must be.

Please explain Type A: zero

I see it is zero but it is an extra CSV field. Is this 'not reversed' aka 'foreward' aka CCW ...

Don't worry about the line length in CSV, full floating point is just fine.

A drawing is in essence unit-less, the unit only counts for conversions.

You could call it 'Astro' just the same ... The remark above is only important with converting units, copy/paste with different units ...

Regards,

CVH

### Re: DrawFromCSV - adding ellipses

Copy all of that, I am thrilled to have this done professionally and I do not want your nice software to draw errors either. I do not expect to be objecting to anything.

The positive rotation direction matches the solar system's rotation direction, so any reversed path would be retrograde and too exotic to worry about. Maybe maybe way down the road, but no reversed arcs will be required.

The type A discussion is a long one. I am finding paths with a propulsive departure, a coast phase tracing the entire path and then a propulsive arrival. A Type A departure means the transfer path is by definition constrained tangent to Earth's path (actually, tangent to a circular arc at Earth's current position) and arrives at Mars non-tangental to a circular orbit at Mars' position. Type B reverses the tangency with arrival at Mars constrained to be tangent. Almost no one worries about Type B but I do. There is a Type C, Lambert's solution, which I hope to add later.

Whenever a propulsive event happens, the resulting velocity vector and the position of the craft lock in the resulting orbit. For transfers to larger radius orbits, the new orbit is automatically at its periapse. Well, the periapse is where the true anomaly and the eccentric anomaly are defined as at zero. So all Type A paths will have a start angle of zero.

Feel free to try other start angles, of course.

Polar coordinates for the ellipse center are much preferred, let's do that.

The positive rotation direction matches the solar system's rotation direction, so any reversed path would be retrograde and too exotic to worry about. Maybe maybe way down the road, but no reversed arcs will be required.

The type A discussion is a long one. I am finding paths with a propulsive departure, a coast phase tracing the entire path and then a propulsive arrival. A Type A departure means the transfer path is by definition constrained tangent to Earth's path (actually, tangent to a circular arc at Earth's current position) and arrives at Mars non-tangental to a circular orbit at Mars' position. Type B reverses the tangency with arrival at Mars constrained to be tangent. Almost no one worries about Type B but I do. There is a Type C, Lambert's solution, which I hope to add later.

Whenever a propulsive event happens, the resulting velocity vector and the position of the craft lock in the resulting orbit. For transfers to larger radius orbits, the new orbit is automatically at its periapse. Well, the periapse is where the true anomaly and the eccentric anomaly are defined as at zero. So all Type A paths will have a start angle of zero.

Feel free to try other start angles, of course.

Polar coordinates for the ellipse center are much preferred, let's do that.

### Re: DrawFromCSV - adding ellipses

Thus 'Type' is not a part of the drawing signature for DrawFromCSV.

Rather a tag ... A custom property what is also possible with DrawFromCSV.

Custom properties can be set by adding an extra CSV field at the end with &[Custom, key1:value1, key2:value2, key3 ...]

Any text here for key and value separated by a colon is literal.

It must start with '&[Custom', end with ']' and it uses the common list separator ... a comma or semicolon.

So I don't implement that.

Coordinates, usually XY, can also be passed on in relative polar notation.

Of no use because that is based on the relative zero functionality similar as in QCAD.

I don't see you resetting the relative zero position after each ellipse ...

Absolute polar notation it is.

We then we get an odd signature:

Center distance, Center angle, Center Axis angle, Semimajor, Semiminor, Start Angle, End angle

Where Center angle = Center Axis angle + 180 degrees

From my point of view one of the two is redundant.

I'll implement Reversed as an optional field and default false if omitted.

Regards,

CVH

### Re: DrawFromCSV - adding ellipses

This is great stuff. I am learning from you about the kind of attention to detail needed to do this kind of thing, and you are a good educator so I am sure this info will also be very useful to others in the future. Of course it also makes sense for me as the first user to understand all this under the hood stuff which i would have blown off as a brute force programmer.

In that vein, to be clear for the record, for this new command, Type A and Type B paths only differ by start and end angle values. So far I have only talked about outbound transfers, but there are also inbound trips (e.g. Mars to Earth).

Type A outbound starts at the zero angle (periapse) and ends somewhat short of 180 deg

Type B outbound starts somewhat after zero deg and ends at 180 deg (apoapse)

Type A inbound starts at 180 deg (apoapse) and ends somewhat short of 360 deg

Type B inbound starts somewhat after 180 deg and ends at 360 deg (periapse)

These all will use the exact same input fields and command and only need the correct angle values to be drawn.

'Center radius' and 'center angle' are the polar coordinates of the center.

'Center axis angle' was dumb, but it is worth discussing so I guess I left that open on purpose.

The orientation angle is the angle of the major axis (correct?) and needs to work over the full 360 deg range.

Yes the orientation angle is redundant data.

I have kept the redundancy for purposes of error checking before plotting. Not eliminating the redundancy is optional, my thinking was to not confuse a future user with a 'missing' field.

The 'orientation angle' will always be in the opposite direction to the vector from the drawing center (Sol) to the ellipse center, so

'orientation angle' = modulo 360 of ('center angle' + 180). For any orbit ever, by definition.

In that vein, to be clear for the record, for this new command, Type A and Type B paths only differ by start and end angle values. So far I have only talked about outbound transfers, but there are also inbound trips (e.g. Mars to Earth).

Type A outbound starts at the zero angle (periapse) and ends somewhat short of 180 deg

Type B outbound starts somewhat after zero deg and ends at 180 deg (apoapse)

Type A inbound starts at 180 deg (apoapse) and ends somewhat short of 360 deg

Type B inbound starts somewhat after 180 deg and ends at 360 deg (periapse)

These all will use the exact same input fields and command and only need the correct angle values to be drawn.

'Center radius' and 'center angle' are the polar coordinates of the center.

'Center axis angle' was dumb, but it is worth discussing so I guess I left that open on purpose.

The orientation angle is the angle of the major axis (correct?) and needs to work over the full 360 deg range.

Yes the orientation angle is redundant data.

I have kept the redundancy for purposes of error checking before plotting. Not eliminating the redundancy is optional, my thinking was to not confuse a future user with a 'missing' field.

The 'orientation angle' will always be in the opposite direction to the vector from the drawing center (Sol) to the ellipse center, so

'orientation angle' = modulo 360 of ('center angle' + 180). For any orbit ever, by definition.

### Re: DrawFromCSV - adding ellipses

spacester,

Below are the 11 test-cases but I have my doubts ...

The first and the last set are isolated on a dedicated layer.

And I added the center, semimajor and semiminor vector to verify with the dataset.

Every ellipse is tagged with CSV order and date.

All seems to be fine as far as I understand it.

But:

When you make 'Oddities' visible you may remark that:

A) The start points are on an ellipse that doesn't include the origin. (The red shape is only a rudimentary fit as example)

B) Ellipse centers are on an almost circle around the origin.

Now only display layer 'Jan_11_2031(1)' and its sublayer 'Oddity' and select the ellipse arc.

I find it odd that these distances match.

The ellipses seems to be exact but I am not sure about their placement in the plane.

Regards,

CVH

Below are the 11 test-cases but I have my doubts ...

The first and the last set are isolated on a dedicated layer.

And I added the center, semimajor and semiminor vector to verify with the dataset.

Every ellipse is tagged with CSV order and date.

All seems to be fine as far as I understand it.

But:

When you make 'Oddities' visible you may remark that:

A) The start points are on an ellipse that doesn't include the origin. (The red shape is only a rudimentary fit as example)

B) Ellipse centers are on an almost circle around the origin.

Now only display layer 'Jan_11_2031(1)' and its sublayer 'Oddity' and select the ellipse arc.

I find it odd that these distances match.

The ellipses seems to be exact but I am not sure about their placement in the plane.

Regards,

CVH