Exporting Charts as .csv Files

[mikestar13]

This feature will be added to version 0.5. This thread is for discussion of what information should be included and how the file should be formatted. This simplest possibility is to include the information in the .dat file for the chart. TMSA on another computer could reconvert this to .dat format and generate the .txt file for the chart very rapidly.

Another possibility is to include the aspectarian and the cosmic state report (the chart wheel itself won't be drawn). This is considerably more complex, but is I think doable.

I think the main question is "what data are users likely to want to import into an Excel or Open Office spreadsheet?"

[Jim Eshelman]

Mike, I can see multiple situations where export to CSV is valuable. The first thing we discussed, though, was for the transit / progression / etc. report. (Every month I take about an hour to run a dozen specific searches for myself on Solar FIre, paste the results into Excel, and then massage them (remove things I don't want, put them in order, apply different fonts to highlight things, etc.). In response, you wrote:

I can output a csv file quite easily in addition to what will show on screen with the chart. I will start doing this for transits and will add on each type of progression and direction as I add them in successive releases of 0.5.x. I'm thinking of ordering the transits, quotadians, PSSR, solar arcs, primaries, tertaries in terms of the order I code them...

Once it's all dumped into Excel, the user has enormous flexibility in what to do with it - including add or remove or resequence columns, apply formatting, or delete things that came up inadvertently (silly example: in running transits to both a natal and SSR, you get duplicate transits to Sun). This allows the user to control a lot of output variations so that TMSA doesn't have to try to be all variations to all people.

Here is an example of what I do for myself every month, and what I'll end up doing for myself regardless (but, remember, my quirks are my own <g> and controllable through Excel formatting). PS - The reason everything says CST or CDT is that the underlying natal has that (born in CST, SSR occurred in CDT). It would be great if all forecast reports allowed specifying time zone for output.

Excel 50.png

[Jim Eshelman]

Solar Fire does similar output - highly flexible in columns that are output and the order in which you put them. Here is one example, giving transits to my natal for the start of March. It basically follows patterns created by Neil Michelsen and others in the earliest days of astrological computer calculating services.

Code: Select all

P1	Asp	P2	Type	Date		Time	Zone	
Mar	Sqr	Nep	Tr-Na	Mar 1 2022	4:02a	CST
Ven	Sqr	Nep	Tr-Na	Mar 1 2022	5:40p	CST
Sun	Sqq	Nep	Tr-Na	Mar 1 2022	6:15p	CST
Nep	Cnj	Mon	Tr-Na	Mar 1 2022	10:19p	CST
Sun	Sqq	Ura	Tr-Na	Mar 3 2022	5:54p	CST
Mar	Opp	Ura	Tr-Na	Mar 3 2022	8:13p	CST
Sun	Sqq	Jup	Tr-Na	Mar 4 2022	0:36a	CST
Ven	Opp	Ura	Tr-Na	Mar 4 2022	3:08a	CST
Mar	Opp	Jup	Tr-Na	Mar 4 2022	5:13a	CST
Ven	Opp	Jup	Tr-Na	Mar 4 2022	11:03a	CST
Mer	Sqr	Ven	Tr-Na	Mar 7 2022	7:49p	CST
Mer	Opp	Plu	Tr-Na	Mar 7 2022	11:18p	CST
Ura	SSq	MC	Tr-Na	Mar 8 2022	0:53a	CST

Some things I don't like about this that I can't control in SF:

1. I detest the "Type" column the way it's always been done by all the services for 50 years. It makes my eyes and brain have to go back and forth over the whole line. Half the hour I spend on this every month is manually breaking that out so that the "type" of each planet is immediately in front of it, so that instead of Mars sqr Nep Tr-Na I can have t Mars sqr r Neptune etc. [This is allowed in SF - what I actually use - but I wanted to show the other format for contrast.]

2. The date (which is one field) doesn't have a comma after the day. Therefore, when exported, Excel won't sort it. (I first have to select the column and do a global change of space 2022 to comma space 2022 before Excel will recognize it's a date. Similarly, the time format needs to be space am (or pm) instead of nospacea, or Excel won't recognize it as a time (again, I do two passes of global replacements).

[Jim Eshelman]

Solar Fire's options of what to include or not include (and put in any order you want). I suspect you won't even want to consider most of these, but you may like to have a list of things to consider. (I've put the ones at the top that are my default output.)

Type 1
Point 1
Aspect
Type 2
Point 2
Date
Time (hh.mm)
Zone

House 1
Point 1 (+House)
House 2
Point 2 (+House)
E/X/L [whether Entering, eXact, or Leaving]
Type 1-Type2 [Type as I showed it above]
Time (hh:mm:ss)
Age Yrs [your age in years and decimal]
Pos 1 [the longitude (position) of Point 1]
Pos 2
D/R 1 [Not sure, maybe whether the factor is Direct or Retro?]
Pos 1 D/R
Pos 2
Pos 2 D/R
Dyn. Red. Chart [I think this is the name field of the Position 1 chart, only useful in SF]
Alt. Rad. Posns Chart [ditto for Pos 2]

[Jim Eshelman]

So that's what I have for the dynamic reports. I think your original question above deal with exporting a static chart, as if you were going to move it to another program or create a special report, etc. In that case, csv simply becomes the most portable and flexible format for moving data and the user may not ever open it alone or think of it as Excel per se. In that case, the question seems to be, "What will the receiving program expect?"

I've never tried moving charts in or out of Solar Fire, so I'm looking now at its options. I find "Export Charts as Text" without a corresponding Import option. Still, their export option might be useful for showing what's already out there (what decisions were made previously). (There is a "Chart Import/Export" tool, but it seems only intended to move chart files from one version of SF to another SF version, no real cross-platform option.)

Back to the chart-by-chart export function SF has: The user selects types of points and types of data. Types of points defaults to Chart Points but could add many other things (midpoints, asteroids, house cusps, Arabic parts, fixed stars, etc.), By default, it exports long/lat with options to export RA/Dec, azi/alt, daily travel, direct/retro, sign, house, point type, chart name, chart type. Notice that this is not for chart for mobility of the data to another platform - it doesn't contain the birth data. Ah, there IS a "comma quote" option.

Here is my chart as SF exports it using defaults:

Code: Select all

Moon	Mon	327.399814604009	4.76557988345716
Sun	Sun	172.461552591483	1.19694124762887E-04
Mercury	Mer	197.350633530909	-3.17456147825815
Venus	Ven	211.87985137851	-5.80461586566448
Mars	Mar	268.922282040276	-2.83282013036381
Jupiter	Jup	93.612533721898	0.153253731934234
Saturn	Sat	194.943374673565	2.16555044179603
Uranus	Ura	93.3325104231166	0.498830983511231
Neptune	Nep	181.339938370092	1.65565838997314
Pluto	Plu	122.102255266403	9.91408981705304
Ascendant	Asc	152.33468463892	0
Midheaven	MC	61.7655308340256	0
Eq.Asc.	EqA	150.99388892947	0

[Jim Eshelman]

Perhaps obviously, I've been "thinking aloud" through this process and, along the way, throwing you anything that I think might be useful. The forecasting reports are a thing unto themselves, the thing that was of obvious use to me, and I haven't thought much about data mobility.

I think the question with no clear answer in my mind is: For what purposes will people want to export chart data? Mostly they won't - and (I'm surprised to learn) apparently the most obvious one, of mobility to another program, doesn't exist. It DOES have value if someone (you or someone else) builds on TMSA in the future and users want to move data across. In that case, the least that's needed is the originating data, and everything else is an add-on.

My initial thought for this, then, is to export the .DAT file just to get the method working and then modify it if we discover other purposes along the way. Because it's an export, it doesn't affect anything in TMSA's internal workings. If you give too much data, people in the future can delete columns easily. It also saves you a lot of work, gets the feature in place, and let's you move to the next thing on your list.

OK, that's my "Sorry, I just woke up and am finishing my RockStar" rambling for the moment.

[Jim Eshelman]

In case it's useful to the thinking-through process, here's what I include in my monthly day-by-day spreadsheet for myself. It changes over time, experimental things float in and out or find a place, but most of it remains stable and is my suggestion for what people might want to watch for themselves.

1. Transits to natal chart + progressed luminaries (45° aspects).
2. Repeat to SSR [no progs yet]
3. Repeat to local natal (angles only, appropriate aspects)
4. Repeat to local SSR if SSR occurred somewhere else
5. Secondary progressions to natal and progressed planets (expanded aspect list for progressions currently including all Ptolemaics plus octiles); include progressed planet sign changes and stations, use "primary" angles [I don't at all want to flood this day-by-day with quotidian crossings, but it's my one chance to capture "primary" angles to natal and progressed]
6. Repeat primary angle contacts for locality
7. Solar arc directions to natal (45° series)
8. All SSR progressions (SQ) to natal and SSR planets (I usually only count 45° series but fluctuate over the years with adding in trines and sextiles); include sign changes and stations
9. Repeat for PSSR
10. Transits to SQ and PSSR Moon (45° series like all my transit reports)
11. Transits to Novien. Currently testing Novien Moon & Sun [Transits to Novien Moon seem solid enough to use, just started experimenting with Sun and hoping I can report that transiting Jupiter square Novien Sun March 14 is a hit! <g>]

[mikestar13]

For data exchange humans are not likely to use static chart info, so I needn't export .csv at all, dat files will suffice for export. I will build .csv support into each transit, progression and direction report as I go. Each report can display a .txt file, export a .csv, or both at user option, with a default method selectable program wide. Abbreviations will be agreed on for various planet types (radical, transiting, SQ, PSSR, Solar Arc, SSR ...) and will be prefixed to the planet names, for example tr Ma sq ra Ne followed by appropriately formatted date and time information, and multiple reports can be combined into one.

I will provide an option to include or exclude moon transits, as they are so frequent and short lasting (I find them quite useful to flesh out slower transits). Other astrologers will have different preferences.

Sign changes and stations may be included or excluded as desired.

I will also develop a snapshot report that will show everything in effect at a given date, time, and location within the specified orb (not more than two degrees and specified by type so, transits, quotadians, and solar arcs need not use the same maximum orb (I would suggest one degree for transits and two degrees for quotadian angles by default, and such other defaults as you find sensible--I think it likely Solar Arcs and Progression (other then SQ, NQ and PSSR angles) should have a narrower orb than one degree, but I'm not sure what the sensible defaults will be. We can discuss when each report is built. My thought is most users will normally follow the regular report, but if they find a particular date/time interesting from the regular report or want a more exact look at an upcoming event (say a wedding or the 2025 presidential inauguration), they can run the snapshot report.

[mikestar13]

I will add quotidian crossings and tertiary progression to your list, all types can be included or excluded as desired. All reports can be for radical angles or locality angles as specified. Reading your list carefully, in general there should be four classifications: Moon, Sun, planets, and angles, so we can set say transits to PSSR Moon while ignoring transits to other PSSR planets.

[Jim Eshelman]

This sounds very cool.

[mikestar13]

It may well take the rest of the year to develop everything, though hopefully a good deal less. Version 0.6 will focus on synastry. Then we will see if any other features are lacking. When most users are satisfied. I will polish everything up and release version 1.0. Presupposing I live long enough, for which I have a reasonable hope.

[Jim Eshelman]

Living is good.

We're all really looking forward to the forecasting tools in v5 and the synastry tools in v6. Ah, but first... 0.4.7 any day now?

[mikestar13]

Pretty sure by Friday, not sure how long a couple of bugs will take to untangle, but sooner ore likely than later.