Hi Folks I haven't given up on bringing Astrology to the People.

RE Base software to handle and process core Astro data ?

Pretty simple once you've got the base data and software that happily handles Nautical data.

It's the second bit that's the problem.

So have you got any answers to these

1/ What does the IT world call data that comes in the form 000?00'00" to 359?59'59" ?

That's ? = degrees, ' = minutes, " = seconds (humour me!)

2/ I managed to develop a first "app" using EXCEL but I couldn't find a function for the Nautical data.

That meant I couldn't really do what I wanted with the data.

Any ideas of off the self software that happily process it ?

I want to lay the base data out and then write simple programmes/ graphs on top of it. IT'S NOT ROCKET SCIENCE, is it!

3/ Any other input about handling this sort of data.

I tried converting it to decimal but in the end couldn't make the computer understand that 0 came after 359?59'59". Oh what a mess and what a waste of time trying to circle the square.

Any ideas gratefully welcomed.

Er Um ?

H

Hi Rocko,

Rocko wrote:Hi Folks I haven't given up on bringing Astrology to the People.
RE Base software to handle and process core Astro data ?

There's Morinus (https://sites.google.com/site/pymorinus/) which is a free and open-source astrology software. In my developers opinion, the Python source code is very badly structured and "un-pythonic", but you can still get something useful out of the source, if you can understand it..

Rocko wrote:Pretty simple once you've got the base data and software that happily handles Nautical data.

I guess if it was that simple, it would be widely available by now! I know what I am saying because I've done it so. And I would love to give it all away freely (and someday I probably will open-source a lot of it) but unfortunately for now a man's got to put bread on his table..

But I'll try to give a few tips..

Rocko wrote: 1/ What does the IT world call data that comes in the form 000?00'00" to 359?59'59" ?
That's ? = degrees, ' = minutes, " = seconds (humour me!)

Angle? But that kind of formatting is usually only presented to end users. Inside the software, you should do decimal math, with angles from 0.0 to 359.99999(..). You also have to implement functions for normalization of angles. For instance, if you add 359.0 + 2.5 you have 361.5 which is a valid angle. But usually, you will want to normalize it to 1.5 after such mathematical operations and then convert it to 001?30'00" (degree-minutes-second) only if you want to present it to the user..

Rocko wrote: 2/ I managed to develop a first "app" using EXCEL but I couldn't find a function for the Nautical data.
That meant I couldn't really do what I wanted with the data.

Any ideas of off the self software that happily process it ?

Excel? Well, I wouldn't trust Excel to make a complex astrology application, but with some effort you could do some interesting things. As an idea, you could do a C program to use the SwissEphemeris to get planetary positions for a given date/time/location and export that data as a CSV file which then you could import in your Excel spreadsheet.

If your layout was correctly made (specific cells were filled as expected), you could then apply formulas to the values and get results. It is pretty messy, but could work..

Rocko wrote: I want to lay the base data out and then write simple programmes/ graphs on top of it. IT'S NOT ROCKET SCIENCE, is it!

Not rocket science, but not a walk in the park, or it would be already done by now..

Rocko wrote: 3/ Any other input about handling this sort of data.

I tried converting it to decimal but in the end couldn't make the computer understand that 0 came after 359?59'59". Oh what a mess and what a waste of time trying to circle the square.

If you are using Excel, have a cell next to the values where you need to do normalization. But all your math should better be done in decimal numbers, as I've said above. Just do conversions from decimal to angle and vice-versa when you need to show or get something to/from the "user"..


Regards,
Jo?o Ventura

I very much appreciate your comments which I will study again very carefully.

I did spend several months writing in Excel. Plenty of lessons learnt then.

But that's was then.

Trying now to get the base planetary data downloaded.

I think they call it an Ephermis and is a Swiss one the best ?

I did get something from NASA I think.

Where might I download the data from say 1950 to 2100 ?

Rocko wrote:Trying now to get the base planetary data downloaded. I think they call it an Ephermis and is a Swiss one the best ?
(...)
Where might I download the data from say 1950 to 2100 ?

Check the SwissEphemeris here: http://www.astro.com/swisseph/swephinfo_e.htm
The SwissEphemeris is not an end-user program, but a computer library where you use a programming language such as C/C++ to get the values from..

You may get some data from the SwissEphemeris site in PDF or something, but that is something which you cannot automate in the long run..

With a little guidance I was able to download data from NASA.

Looking now it looks more complicated.

I easily downloaded Txt files and imported them to Excel.

H

Dear Rocko,

Just some general advice for those who wish to create their own astrological software.

1. Use the swiss ephemeris, NOT the data from nasa. Using this data to create an ephemeris requires professional level programming abilities and a huge amount of time. I know because this is the road we went down when we created the first version of AstrologyExplorer3D. Stick with swiss ephemeris. Make a basic program which links with the DLL and gets the planet positions from a given Julian Date as a starting point.

2. All dates are Julian Dates, not standard gregorian dates. There are functions in the swiss ephemeris to transform between the two. You should familiarise yourself with this concept : http://en.wikipedia.org/wiki/Julian_day

3. You will need some form of atlas. The astrological community really needs a good quality free, open atlas, especially after Astrolabes defeat in their legal case against Olson et al, this is now a real possibility for the future. However right now your choices are limited. If you have a lot of birth date data from different locations this is likely to be a really big barrier you will come up against. The zoneinfo data https://zoneinfo.codeplex.com/ is a good choice and is actually pretty accurate.

4. Best to represent an angle as a floating point number, not as deg/min/sec. Most trig function in programming languages use angles in radians, whereby a circle is 0 to 2PI. The best practice is to get used to this and store all your angles in radians, only converting to degrees in the user interface layer or if the specific circumstances call for degree use. The same for all other quantities, time, distance, etc, have a standard method of storing them internally in your program and convert them as necessary for the user.

You will also need some code to deal with angles. Specifically the clockwise and counter-clockwise distances, difference between 2 angles, etc. Also create a text document in which you define for your system whether an angle of say PI/2 is 90 clockwise or counter-clockwise. Is east or west positive. Defining these things for yourself will make life a lot easier.

That is all I have time for just now.

I hope it is helpful,

Gavin

Gavin786 wrote:1. Use the swiss ephemeris, NOT the data from nasa. Using this data to create an ephemeris requires professional level programming abilities and a huge amount of time. I know because this is the road we went down when we created the first version of AstrologyExplorer3D.

Same here. I didn't know the Swiss Ephemeris existed until version 3 of Timaeus and so I used the text "Astronomical Algorithms" by Jean Meeus (available from Willman-Bell). Having a background in astronomy helped me a lot, but the Swiss Ephemeris is the best option if you're just starting out and wanting to do professional level software. However, I've still retained my TZTDateTime component which is based upon the book "Astronomical Algorithms" by Jean Meeus. I've been wanting to expand the time range available with SWE 2.0 so will be adding more code soon to expand the range of calculation which will instead just query the DLL for expanded Julian date.

Using the DLL frequently in many different units caused me to create an OOP interface (component) to the Swiss Ephemeris that one can just click and drop on the form to access the DLL from any unit in the developers IDE. This will be important if your program gets complicated like my software has because you will want to make sure that you aren't overwriting values due to inconvenience and wanting to use the same code so it is best to encapsulate and "black box" your routines so you can track down errors more easily. The component uses a method of dynamic linking to keep the IDE from throwing static access errors when the DLL is not found.

If you enjoy writing lower level code, I highly recommend Jean Meeus's "Astronomical Algorithms" because his writing style makes it very easy to almost directly translate to code. One of my other favorites is "Fundamentals of Celestial Mechanics" by J.M.A. Danby.

One thing Gavin didn't mention about the atlas situation is that there is the Geonames database available (http://www.geonames.org) which already has the Olson tz labels as one of the fields. This actually isn't the best way to handle the zone region issue because I don't think it's a good idea to directly link a location to a zone, but if you're willing to update your geonames data whenever a location switches zones then it's a fair option. A better way to go IMO is to use Eric Mullers vector "shape file" polygons (http://efele.net/maps/tz/world/) which determine the zone from latitude and longitude of a location. This latter option requires less maintenance since geo data changes rather infrequently and you don't generally want to disturb a database with frequently changing time zone attributions. I wrote about some of the other issues affecting time change history here:

http://www.astrology-x-files.com/terranatlas.html

For more history involving the legal issues involving the TZ database:

http://skyscript.co.uk/forums/viewtopic.php?t=6384