PDF/PNG Astrological Chart Service FAQ

29 June 2008 - updated 2 April 2012
Tags for this page:
Others:

Contents

Basic questions

What is the PDF/PNG Astrological Chart Service?

It's a Web page on which you can enter a date, time, and geographic location, and it will generate an astrological chart corresponding to that information. Normally one would use the data for a person's birth, though there's nothing in the system that requires that. The system supports a bunch of options for exactly how to draw the chart, and offers a variety of asteroids and minor planets. It computes the astrological information with Swiss Ephemeris and uses LaTeX with the horoscop and starfont packages to generate the output in PDF or PNG format.

Who runs this service?

My name is Matthew Skala. You can read more about me on the rest of my Web site, or send me email.

Please do email me if you have suggestions for other features you'd like to see included in this service. I can't promise to implement them all, but if it's something simple like adding an object of interest, I'd be happy to get the request.

Are there other similar services on the Web?

Many people like the free chart service at astro.com. It provides some interpretation information, and a wider range of types of chart. That service is probably better suited to end-users than mine. I think the charts from my software are better-looking on the page, though.

So I filled out the form and got the chart... but what does it mean?

This service does not provide interpretation at all, only charts. Take it to an astrologer, or learn to interpret it yourself.

Where can I learn to interpret charts?

I like the astrology lessons section on Bob Marks's Web site.

Is Scorpio romantically compatible with Libra (or any of the 143 other possible questions of that form)?

It is not possible to provide any meaningful compatibility assessment based on just the people's Sun signs like that. At the very least you need the Moon signs as well - which require specific birthdates and at least approximate times of day. Elsewhere on this site I provide a quick-and-dirty compatibility test using Sun and Moon signs, but understand that that also is a very rough approximation.

Aren't there really 13 signs?

No.

But Ophiucus ought to be included! Ha ha!

That wasn't a question. However: Ophiucus is an astronomical constellation, not an astrological sign. Saying that Ophiucus ought to be included in astrology because astronomers use it is like saying that the alphabet for present-day English ought to include the letters thorn and eth because writers of Icelandic use those.

Technical issues

What if I want to enter the coordinates in decimal degrees instead of degrees, minutes, and seconds?

Enter the decimal degrees in the "degrees" boxes and leave the minutes and seconds at zero. You can also enter degrees and decimal minutes, leaving the seconds as zero. Either will be converted and displayed as degrees, minutes, and seconds.

Do not enter a sign (+ or -) on the degrees; that must still be indicated as North, South, East, or West with the dropdown boxes. This is to avoid taking a position on the contentious issue of which direction the longitude signs go.

This kind of thing does not work for the time: that must be entered in hours, minutes, and seconds. Seconds of time are optional and will be taken as zero if left blank.

How are rounding issues handled?

Astrology presents some unique challenges for computer arithmetic because of the mixed-base representation used for describing positions in the sky. We need to not only represent a position as accurately as possible within the number of digits we use, but also have rounding boundaries in specific places that have symbolic significance. First of all, times, latitudes, and longitudes are truncated to seconds of time or of arc, with a tiny offset to account for precision loss inherent in the computer's internal 32-bit representation. If you entered them in integer hours or degrees, minutes, and seconds, then the rounded result should be exactly what you entered.

For Zodiac positions, rounding is a configurable option. The default behaviour is that all mixed-base digits of the position except the least-significant will be displayed with the values they would have assuming truncation, and the least-significant will be rounded to nearest even if that gives it an out-of-range value. For instance, a position 29.99999999 degrees after the equinoctial point - almost at the end of Aries - might display as 29° Aries 59' 60"; 29° Aries 60'; or 30° Aries; but never in Taurus. The point of this rounding method is that although it does round to nearest, it will never round in such a way as to change the higher-order mixed-base digits, which have important symbolic value. A position before the sign cusp, in particular, should never be displayed in the wrong sign; and similar protection is enforced at the boundaries of degrees and minutes, to allow unambiguous determination of things like decans. This method has the disadvantage of sometimes producing out-of-range digits, but it seems to me to be the best compromise. It is used in some hardcopy ephemerides.

If you don't like the default rounding mode, you can choose one of the other settings in the options box. "Truncate instead of rounding" will always truncate. This mode is easier to understand; it never produces out-of-range digits; and it means that positions truncated to different boundaries will always agree with each other for as many digits as they have. However, it means that a reported position could be off by as much as one full unit of the smallest digit, instead of one half unit as in the default mode. The example position of 29.99999999 degrees from the equinoctial point might display as 29° Aries 59' 59"; 29° Aries 59'; or 29° Aries.

If you choose the "Clamp rounded values" mode (and not the "Truncate instead of rounding" mode, which takes precedence when both are chosen), then you get the default mode except that any out-of-range values are displayed as being at the end of the range instead of outside it; so anything that would be shown as 60", 60', or 30° will be shown instead as 59", 59', or 29°. This mode seems to combine the disadvantages of the other two, and it is not recommended. In particular, it means that in round-to-minute positions, the last minute of a degree is 90 seconds long while the first of the next is 30 seconds long. (In the default mode, first and last minutes are 30 seconds each, which at least is symmetrical.) But some other software uses the clamped rounding mode, so it is provided for users who might prefer it.

True round-to-whatever, under which 29.99999999 degrees from the equinox would appear as 0° Taurus 0' 0", and several other modes that treat particular digits specially, are offered by the underlying horoscop LaTeX package but not supported by this Web interface.

As of this writing, the currently-downloadable version of the horoscop package does not support advanced rounding yet; it currently does a poorly specified thing almost equal to truncation. The new version, already used in the online service and supporting really correct and configurable rounding support, will be posted for download after I finish documenting it and incorporating a few other requested features. Note that the downloadable version is marked as a beta version, and that's what you get with beta software.

What general principle should we be aware of regarding this service's astrological calculations?

The point and purpose of this service is astrological typesetting, not astrological calculation. It exists to demonstrate the horoscop LaTeX package. The calculations are performed by a separate software module (Swiss Ephemeris) that I did not create; and date and time conversion (from whatever you enter to UTC) are handled by the PHP programming language. My software that I actively maintain and am responsible for is only the part that typesets the chart and the glue logic that combines these and a few other modules into a Web service.

Accordingly, some aspects of the astrological and date-time calculations are not directly under my control. The general policy is that you get whatever comes out of Swiss Ephemeris and PHP; I will attempt to work around any bugs I know about in either package but will not necessarily be responsible for tracking down every last questionable issue. My commitment is that my chart should accurately represent the planets and such as being where my installation of Swiss Ephemeris says they are; whether that's where they really are is an issue to take up with the authors of Swiss Ephemeris.

What range of dates can this service cover?

Whichever dates are covered by BOTH my home computer's installation of Swiss Ephemeris and my hosting provider's installation of PHP. That raises some isses.

Swiss Ephemeris's high-precision ephemeris files for the traditional planets, the Moon, and Astrodienst's idea of the "major" asteroids (Ceres, Pallas, Juno, Vesta, Chiron, and Pholus) are supposed to cover the range 2 January -5400 to 31 December 5399. However, they're not provided in a single package but as separate files for different year ranges, and Astrodienst discourages people from downloading the whole set all at once because of server-load issues. They request that you only take what you really need. As of this writing I have the ones covering the years 0 through 2399. If there are other year ranges you really want, contact me and I'll grab others. I may at times acquire additional data files without promptly updating this FAQ entry, so the real coverage may be greater than what's described here.

Swiss Ephemeris also includes what they call the "Moshier semi-analytic theory" which covers the years -2999 to 3000 for the traditional planets and Moon only. It is less accurate, but should be plenty accurate for astrological purposes (within less than a second of arc except for the Moon and Lunar derived points). If you enter a date that is in this range but not in the range covered by my installation of the high-precision ephemeris files, then this is what you get.

For individual asteroids, I have also installed a bunch of the "short asteroid files" from Astrodienst, which only cover the years 1500 to 2100. On request I may be able to get the "long" versions of some of these files; I'm not sure whether those are on the Astrodienst FTP site or not.

If you request an object for a date on which I have no ephemeris data, it will probably appear on the chart as being at 0° Aries. That's less than ideal, but as the doctor said to the patient, "Don't do that."

Be aware that for some minor planets or asteroids, accurate data may simply not exist for dates too far from the end of the Twentieth Century in either direction. Many of them have orbits extrapolated from just a few observations, the accuracy of which necessarily degrades for dates far from the dates of the observations. Some of them have orbits that interact with those of major planets in a chaotic way. For instance, Chiron had a close encounter with Saturn in the year 720 and it is not possible to compute where Chiron came from prior to that time based on present-day observations.

In light of these issues, to prevent people from confusing themselves there is an "allow dates outside the 20th and 21st Centuries" check box on the Web form. To use such dates, this box must be checked; and if it is, the date you enter will be just passed through to the Swiss Ephemeris interface and it will be assumed you know what you're doing. See also the next two questions and answers.

What about the Julian calendar?

During testing with a date in the year 1626, a user discovered some bizarre behaviour that seemed to relate to an incorrect conversion between the Julian and Gregorian calendars. On investigation this turned out to be the consequence of a bug in PHP 5.2.1. It seems to be similar to bug #40743, but I am not sure that it is exactly the same bug. I have upgraded to PHP 5.2.6, and this bug seems to have been fixed, but PHP's handling of the Julian and Gregorian calendars remains poorly documented.

The way in which I am using PHP's calendar functions is intended to make it use the Gregorian calendar consistently. However, this may be related to the selected time zone. It is possible that in some time zones, PHP will assume you entered a Julian date for dates before some date which may or may not be 3 September 1752, the traditional assumption of the Unix cal(1) program. It is also possible that PHP may interpret the date in a way that is not correctly the Julian nor Gregorian calendar, because I am not confident that all the bugs in this area were correctly fixed by the PHP team. It appears to me that the chances of correct behaviour are best for dates entered as UTC.

Accordingly: I strongly recommend that for dates prior to the mid-Eighteenth Century, you enter them as Gregorian dates and select the UTC time zone; and cross-check with some other software (the position of the Sun should be a dead give-away) to make sure you're getting the date you intended.

What about dates before the First Century?

The traditional Gregorian calendar counts "2 BC, 1 BC, AD 1, AD 2..." with no year zero. Nowadays a lot of people substitute "BCE" and "CE" to avoid the affirmation of Christian religious doctrine implicit in using the older abbreviations, but they still count "2 BCE, 1 BCE, 1 CE, 2 CE..." Others, who want arithmetic to work consistently and thus need a zero, count "-1, 0, 1, 2..."

The ISO 8601 standard appears to specify the last of those conventions, with a year 0 equivalent to 1 BCE. PHP claims to follow the ISO standard, and this service uses PHP's date-handling functions; so you should enter dates prior to the year 1 as zero or negative, with 0 = 1 BC = 1 BCE. I cannot promise that it will actually work correctly; see comments above regarding PHP bugs. Swiss Ephemeris also claims to use the year-zero numbering scheme; it is easier to test and does seem to be doing it correctly.

When did the Twenty-First Century begin?

On 1 January, 2001.

What happens when I enter a combination of latitude and house system for which the house cusps are undefined?

This situation occurs for instance with Placidus or Koch houses and locations inside the Arctic or Antarctic Circles. You get whatever comes out of Swiss Ephemeris, without comment or warning. I think Swiss Ephemeris will automatically switch to Porphyry houses in such cases. See its documentation, and/or "don't do that."

Beware of accidentally interchanging the latitude and longitude; I discovered some bugs in the polar-circle handling (now fixed) when I entered Waterloo, Ontario (longitude 80° 31' W) as being at latitude 80° 31' N.

What's the deal with hosted PNG charts?

Sometimes people want to post charts on the Web for others to view, for instance in online Web logs, journals, BBS discussions, and so on. The best way to do that is to download the chart and post it in one's own server space. However, many people don't have server space they can conveniently use for this purpose.

If I ever display a chart as an image in an HTML page, then I must make the chart available through some kind of URL, however temporary and obscure, and then it is inevitable that people will embed the URL elsewhere on the Web, hoping to get the benefits of image hosting while using my bandwidth and server space instead of their own. This practice is variously known as "hot-linking," "embedding," or "bandwidth theft."

There are two ways I can go on that. I can attempt to prevent you from doing it, or I can accept that you will attempt to do it no matter what I say, and then work out a way to turn it to my advantage. Other services, like astro.com's, try to prevent hot-linking by expiring the images really fast, and/or blocking access based on Referer: [sic] headers, so that if you try to embed their images, it won't work. I've chosen to take the other path and make hot-linking be okay.

So here's the deal. If you want to hot-link a PNG chart from this service as an embedded image somewhere, fine, go ahead and do it. You'll need to generate the chart with the "PNG - hosted" output option so that it gets a URL in the first place. Then you can use the embedding code on the resulting page to post it wherever. I've included both HTML and BBcode versions. But when you post it, please post it with a link back to my site. If you use the provided embedding code, the link will be included automatically. Then when people click the link, I get the chance to show them some of my content, promote my own projects, sell ad impressions, and so on. These clicks compensate me for the small but nonzero amount of money it costs to serve your embedded image.

As an incentive to encourage you to really post the link properly, and also to prevent unused images from cluttering up my server, the image expiry is tied to the incoming clicks. Charts will be kept until seven days after the last click. So you can keep a chart on your page indefinitely as long as people click on it at least once a week, but if a chart isn't being used and clicked on, it will eventually go away. It is important that you use the exact URL provided in the embedding code, because it contains the ID of the chart whose expiry date should be adjusted; if you use some other URL to link to my site, that's nice, but it won't help your chart stay online.

I reserve the right to point the incoming-click URL to whatever I want to advertise, filter it to block cheaters, change the timeout settings if I run out of server resources, and so on.

Notices and disclaimers

Is there anything we should know about privacy?

You can enter your name and birth data on the form, and if you do, that is obviously information you might want to keep secret. The system makes some effort to protect it. In particular, because this is a POST form, assuming your Web browser obeys the standards, the data won't go into the server logs. However, it does get written to disk as part of the normal process of generating the chart. Normally each new chart overwrites the old data; but the last chart generated at any given moment does remain on my disk until it's overwritten, and when there is an error I will examine that data for debugging purposes. Note, also, that the data crosses the unencrypted Net on its way between your browser and the Web server and between the Web server and the backend server.

If you choose the "PNG - hosted" output format, then the resulting chart will be stored on the Web server and shown, including the personal information included in the chart, to anyone who views it with the associated URL. These URLs are randomly generated and difficult to guess. It is extremely improbable that anyone could view one of these charts unless you give them the URL, directly or indirectly. Nonetheless, such charts should be considered public knowledge. The purpose of the "PNG - hosted" option is to make it easy for you to publish charts to the world; do not choose it for any chart you wish to keep private.

I believe that the privacy of data on this system is at least as good as on any comparable free astrological chart service. If you want tighter security, I suggest downloading an astrological software package (mine or any other) and running it locally on your own computer.

What if I live in a jurisdiction where providers of astrological information are required to state that it is for entertainment purposes only?

In that case, astrological information on this site is provided to you for entertainment purposes only.

Errors and other problems

After filling out the form and clicking "submit," why do I just get the form again instead of a chart?

This most likely means that you didn't fill in some necessary piece of information on the form, such as the date and time.

Why doesn't the name I entered appear in the chart?

This probably means that you entered some punctuation in the name that the system considers invalid for names, such as a backslash.

What does "500 Internal Server Error" mean?

Error 500 usually happens when the Web server can't connect to the backend server (my home computer) to compute the actual chart. Because the software used to make the charts won't run on my hosting account, the page you connect to on the Web host is just a sort of gateway that passes your information back to my home computer. If the connection between the two breaks, as it sometimes does, then you get error 500. It is also possible for other problems inside the system to cause this error. Unfortunately, there is not much you can do about error 500 except wait and try again later. If it persists more than a day or so, email me to complain.

What does it mean if my browser says the connection timed out?

That may mean the connection to the backend broke (like error 500 above) or it might conceivably mean that the service is so heavily loaded by other people using it, that it can't handle all incoming requests. Overload is unlikely, but if the service becomes extremely popular it could be a possibility. Timeouts could also be caused by general Internet connection problems on your end.

What does "503 Service Unavailable" mean?

Error 503 normally indicates that you have exceeded the limit for how often the service will generate charts. You're limited to a long-term average of one chart per four hours (six charts per day), although you can exceed this limit for short periods. If you get this error, try waiting at least four hours and then trying again.

In more detail: the system uses what is called a "token bucket" rate limiter. Every unique IP has a store of tokens. You start with 50 tokens. Every time you successfully generate a chart you use up one token. If you have no tokens remaining, you get error 503 instead of a chart. Every four hours you get a new token, unless you already have 50 in which case you just stay at 50. So you can make charts in bursts of up to 50 at a time, but the long-term average is limited to one per four hours.

The reason for the limit is to prevent the system from putting an undue load on my server resources, bearing in mind that I have to pay for my hosting and I don't get paid to operate the service. The ad boxes on my site currently bring in about $0.20 per day for the whole site - nowhere near enough to cover hosting expenses, and almost none of that is directly attributable to the chart service. I figure that anyone who needs more than six charts per day over the long term is probably either a professional, in which case they shouldn't be exploiting a free service, or else a serious amateur who could download the software and compute their own charts themselves.

Nonetheless, if you think you have a good reason to use my service beyond the limit, or if you want to pay me to help you build a service of your own, please email me.

Related pages:

Comments

other from 65.93.62.223 at Sun, 29 Jun 2008 21:03:01 +0000:
Very cool.

One thing I did wrong was I put '-79' in the longitude and the chart interpreted that as 0.

Vilhelm S from 217.146.104.65 at Mon, 30 Jun 2008 17:50:42 +0000:
I tried to put in decimal numbers in the long/lat fields, and leave the minutes/seconds as zero. This also gets interpreted as 0, but it would be nice if it worked since the coordinates you get from Google Maps are in decimal form.

Matt from 129.97.79.144 at Mon, 30 Jun 2008 18:50:25 +0000:
Okay, I've changed the data sanitization a little... you can now enter decimal quantities into the lat/lon boxes. You can't do negative numbers, though; direction still has to be designated with the east/west and north/south boxes.

If you enter a decimal into the degrees box, it would be advisable to leave the minutes and seconds at zero. The actual handling is the obvious formula - total number of degrees is degrees plus minutes/60 plus seconds/3600. It'll still be displayed in the result as degrees/minutes/seconds.

There remain some issues with rounding in the current code. I'm working on them.

Captain Smokeblower from 72.35.99.225 at Mon, 30 Jun 2008 21:32:13 +0000:
Where is a good map website to pick up your Latitude and Longitude?
Is this your current Lat/Long or your birth Lat/Long?
Birth certificates (US) don't list seconds and new moms don't pay that no mind neither. How critical is seconds to the formula(s)?
Thanks,

Matt from 69.63.56.54 at Mon, 30 Jun 2008 21:52:33 +0000:
A standard natal horoscope uses the location of your birth. But people do also cast what are called "relocation" charts, using your birth time and current (or potential) location, to get an idea of how a given location relates to your personality or destiny.

Time of birth to within a few minutes should be just fine. The most significant thing it affects is your ascendant - which changes as a rate of about one sign every two hours. Better precision is better, but if you have it to the nearest minute it's unlikely that further precision would make much difference. The more common situation is that people come to astrologers with *just* a birthdate, no time of day at all, and then it becomes a bit of an issue. Even knowing to within plus or minus an hour is a lot better than not having a time at all. A competent reader of the chart should be able to judge which parts of it may be in doubt based on the amount of uncertainty you have in your time and location.

There's always some uncertainty. Bear in mind that birth doesn't happen instantaneously, clocks and watches are often not set precisely, whoever wrote on the certificate was probably very busy with other things at the actual time and had to guess and backdate it afterwards, and so on.

Axel from 65.94.179.241 at Sat, 05 Jul 2008 23:06:29 +0000:
Do you mention cut-off dates in the FAQ? I tried a map for 1626 and then another for 1782 and both times got a map for 4 July 2008 instead.

Matt from 129.97.79.144 at Sun, 06 Jul 2008 01:47:18 +0000:
Strange. It ought to work several thousand years from the present in either direction, and if it rejected a date, using the current one isn't what I'd expect it to do. Thanks for reporting; I'll investigate further.

Axel from 65.94.188.3 at Sun, 06 Jul 2008 20:30:09 +0000:
Ah! It now works. I entered the Gregorian date 4 June 1626 and the chart came with exactly the same positions that I get from CCRS for the same hour (except it had the Moon 13°20' Libra and you have 13°19' - but that must be due to perturbation series truncation or a difference in assumed Delta-T). I wonder if it would be possible to allow for a switch - say, entering the day part of the date as negative - to make the date read as Julian. And if PHP is decent, it will read any date earlier than 15 October 1582 as Julian. After that date, and up to the Russian civil war following 1917, there has always been somebody or other remaining on the Julian calendar.

Axel from 65.94.188.3 at Sun, 06 Jul 2008 20:43:53 +0000:
Because my horoscope is a speculative one for the foundation of New York (when Peter Minuit bought Manhattan for a bag of glass beads), I had entered the chart name as "NYC?"; in an earlier test I had entered "Is this New York?" Both names failed to appear. When I used a title without a question mark ("Minuit speculative") it got printed as usual.

Matt from 69.63.56.54 at Sun, 06 Jul 2008 20:58:04 +0000:
See my updated FAQ. I think if I were going to offer a choice between Julian and Gregorian dates, I'd want to do it as a separate switch rather than overloading an otherwise-meaningless value for one of the existing boxes (like negative day part); using in-band signalling for that kind of thing tends to be a major cause of annoying bugs and maintainability problems. (Obvious example: what happens next week when I decide I want to support a *third* calendar, such as the Jewish one? Negative months?)

However, there isn't much (indeed, any) documentation on how PHP's DateTime class handles Julian/Gregorian date conversion, and without that documentation there isn't much way to make the conversion happen in a controllable way. By trial and error I've found that it seems to treat dates as Gregorian consistently when it's told to use UTC, now that I've upgraded to a version with the DateTime constructor bug fixed. You *may* get dates before 1582 as Julian if you enter them in some timezone other than UTC. Absent good documentation, I'm inclined just recommend that people use Gregorian and UTC for all dates where it's an issue, and treat the Julian conversion as beyond the scope of what the service will do. Even time zones at all are beyond the scope of the horoscop package, which demands UTC Gregorian input; I'm supporting time zones just because I already had some code for that from my compatibility test page.

I think the Julian calendar is still used today in Orthodox Christianity for calculating feast days.

Matt from 69.63.56.54 at Sun, 06 Jul 2008 21:19:33 +0000:
Question marks aren't allowed in names - see the FAQ. It might be safe for me to permit question marks in particular, and I might do that; I'll add it to the list of things to look at. What's really going on here is that this is a consequence of a fail-closed security policy. The data you enter on this form get written into a document and run through LaTeX. LaTeX is a fully general computer programming language, and in order to connect to the astrological software these particular documents must be run with what is called "write18 support" turned on, allowing LaTeX scripts to run shell commands, so a person who could enter their choice of data into the document without restriction would be able to make my computer execute arbitrary commands - a huge security problem notwithstanding that the Web server runs at limited privilege.

So to be safe, the system examines the input carefully before passing it through to LaTeX, and only permits data which I'm absolutely sure cannot contain dangerous LaTeX commands. It does that by forbidding all LaTeX commands in general, and anything resembling a LaTeX command, rather than attempting the (provably impossible under some assumptions) task of judging which LaTeX commands are safe and which aren't. The check actually happens twice - both on the Web form and at the backend. This comes down to the fail-closed principle: instead of removing known dangerous input and permitting everything else, it permits known safe input and forbids everything else. Question marks, although probably harmless, weren't on the short list of things I said should be allowed, so at the moment, they aren't allowed.

See: http://canonical.org/~kragen/security-holes.html , particularly the item titled "Fail-openness."

Grzegorz from 83.13.241.82 at Mon, 07 Jul 2008 11:48:55 +0000:
Krusinski house system isn't working - when I chose it I get Placidus cusps instead :<

Matt from 69.63.56.54 at Mon, 07 Jul 2008 12:28:49 +0000:
Thanks for the report; it should be fixed now.

Axel from 65.94.189.95 at Mon, 07 Jul 2008 14:10:13 +0000:
Answer to *Captain Smokeblower* - "Where is a good map website to pick up your Latitude and Longitude?" If you just want general longitude and latitude for a city, town, or village anywhere in the world, the best site is probably Falling Rain:

http://www.fallingrain.com/world/

If you want precise coordinates for a house, hospital, or other object with a street address, I like TravelGIS:

http://www.travelgis.com/geocode/Default.aspx

This is essentially a front end for Google maps with some added functions. Move the cursor around and the coordinates in the border of the image (hybrid satellite/map) will change; zoom out one or two notches and street names will appear; clicking on the cardinal pointers will pan n, e, s, or w. You can also enter a postal code if you don't know the address.

Grzegorz from 83.13.241.82 at Tue, 08 Jul 2008 10:12:52 +0000:
Yes, now it works. Thanks!

Axel from 65.94.187.146 at Wed, 09 Jul 2008 14:30:04 +0000:
It's official - I now come to Matt's service for a quick map because the input is *so much less finicky* than at Dienst. And there are no insulting messages such as "Most likely a false chart will be the result."

Axel from 65.94.189.81 at Sun, 27 Jul 2008 02:00:10 +0000:
"Is Virgo romantically compatible with Gemini (or any of the 143 other possible questions of that form)?" Shouldn't that be 65?

Matt from 216.75.190.36 at Sun, 27 Jul 2008 05:54:46 +0000:
I was thinking that there can be a meaningful difference between "I am Virgo and my potential partner is Gemini" and "I am Gemini and my potential partner is Virgo"; either you can assume heterosexual relationships (or asymmetric homosexual, like top/bottom or butch/fem) and then it might matter which role is which sign, or you can assume that you'd have different advice for the two people in the relationship so it would matter which one is asking. I also assumed that whether a given sign is compatible with itself, is a meaningful question. So then it becomes 12 times 12 = 144 possible questions.

If you assume that there's only one question per pairing (so Gemini-Virgo and Virgo-Gemini are the same question) and also that you're only interested in pairs of distinct signs (so Gemini-Gemini is not a question) then you have 12 choose 2 = 66 possible questions. It sounds like that's what you had in mind.

ghap from 70.71.65.215 at Tue, 02 Sep 2008 05:09:03 +0000:
Cool!

Coincidently, I was using astrological/astronomical software to compute my saturn return yesterday (turns out it's two years away). I was surprised that I couldn't find a way to compute it easily. Is there an app somewhere which will compute time based on a planet and astrological co-ordinate?

I also found it oddly difficult to compute between astrological degree-sign-minute notation and right ascention hour-minute-second notation. The fact that they're using different units (12 signs, 30 degrees, 60 minutes vs 24 hours, 60 minutes, 60 seconds) was unhelpful. Converting between those I got an inexact match. They seemed to be using a different point of Aries, at least.

Matt from 216.75.188.95 at Tue, 02 Sep 2008 12:07:19 +0000:
I don't know of an app like that. The latest version of NASA's HORIZONS package probably can do it with the "geometry search" function (a new experimental thing I haven't tried yet) but you'd need to write your own code to call it. One complicating factor is the retrograde thing - the planet may go retrograde and cross the coordinate several times in a short period, and you have to figure out which one you want. The general problem is numerical root-finding, for which lots of numerical-methods stuff has been developed.

Right ascension is measured around the Earth's equator, whereas astrological zodiac positions are measured around the ecliptic (the plane of the Earth's orbit). Those two circles are tilted to each other at an angle of about 23 degrees. As a result, you can't directly compare numbers on one to numbers on the other. You need to factor in the latitude and do some spherical trigonometry. Also, be aware that astronomical software will probably give you some kind of sidereal coordinates (referenced to the "fixed" stars) rather than tropical coordinates referenced to the equinox, which is what you'd want for Western-style astrology, so you'll end up needing to add a correction for precession of the equinoxes.

It'll still require some manual poking around, but I'd suggest you try using the Swiss Ephemeris test page at http://www.astro.com/swisseph/swetest.htm .

Matt from 216.75.188.95 at Wed, 03 Sep 2008 23:36:32 +0000:
On further thought, it occurs to me that you can extract planetary returns quite easily with Astrolog; tell it to search for transits to your birth chart, but restrict it to only conjunctions (not other aspects) and only one planet. Then it'll show you the returns of that planet.

Cernael from 81.224.124.160 at Thu, 16 Oct 2008 22:05:34 +0000:
On Saturn Returns; I was born with Saturn in retrograde, apparently - does that mean that my first one occurred in my toddlerhood?

To expand on the issue - if Saturn, after passing its natal position, goes into retrograde, and so passes thrice, which of the three passing times is *the* Saturn Return?

Matt from 69.63.53.9 at Thu, 16 Oct 2008 22:40:51 +0000:
Good question. I don't know if there's a general consensus for what to do in that kind of case. I'd be inclined not to count any that might occur in the first year (there could be two of those, if you were born while Saturn was direct and about to go retrograde), and then count as "the" return the one that occurs in the same point in the cycle - so if it was direct shortly before retrograde when you were born, take the first one, if it was retrograde take the second one, and if it was direct shortly after retrograde take the third one. That seems to make intuitive sense because you can say that it's Saturn returning to its original state, not just its original location on the Zodiac.

However, bear in mind that the Saturn return is usually thought of as a long-term event, covering a period of as much as a couple years centred on the moment of exact conjunction - so which exact moment you choose to count shouldn't necessarily make much difference.

Cernael from 81.224.124.160 at Thu, 16 Oct 2008 23:46:46 +0000:
Ah, right...hmm...the retrograde reoccurs at roughly the same point on the ecliptic, then? Makes sense, though I figure it might drift somewhat - or, wait, no. The retrograde of the outer planets is more tied to the Earth's orbit than that of the outer planets, right? So Saturn retrogrades take place about once per year, at a time that, itself, drifts one lap around the year over a 30-year period? In an over-simplified model, of course, and anyway...it returns. But, the retrograde around the Return would be, if not at the identical points of the ecliptic, then very close to them. Or...no, again, the Saturn orbit is generally 29.5 years, not 30. That ought to mean that my Saturn Return should/could be around November rather than May, the Earth would/could travel in the other direction, and there'd be no Saturn retrograde then.

Sorry for the rambling.

Anyway, a thought I had concerning this; if you use some method of house division that places the first direct, retrograde, and second direst Return in different houses, they'd influence different areas of your life - but the house division is generally taken from the natal chart in this case, I guess, and it'd be the same in all three.

New comments are disabled, pending transition to new site code.
Copyright 2008, 2012 Matthew Skala
Updates to this site: [RSS syndication file]