gergely/swe-glib
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'master' of github.com:gergelypolonkai/swe-glib

Browse Source
This commit is contained in:
Gergely Polonkai 2013-09-14 16:32:00 +02:00
commit 7a44c1305f
1 changed files with 22 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
README.md
View File

@ -1,8 +1,8 @@
# SWE-GLib
SWE-GLib is a GLib style wrapper library around the [Swiss Ephemeris library](http://www.astro.com/swisseph/), created by Astrodienst.
SWE-GLib is a GLib style wrapper library around Astrodienst's [Swiss Ephemeris library](http://www.astro.com/swisseph/).
The source tree contains Astrodienst's (the writers/publishers of the Swiss Ephemeris library) ephemeride files, as requested by Alois Treindl of Astrodienst in a mail written to me on 24 July, 2013.
The source tree contains Astrodienst's ephemeride files, as requested by Alois Treindl of Astrodienst in a mail written to me on 24 July, 2013.
## GTK-Doc
@ -12,7 +12,7 @@ Still, the documentation generates well, and at least gives a clue about object
## Usage
Many functions return non-opaque C structs; their documentation can be found inline, and in the generated GTK-Doc. Unless otherwise stated, the returned values should never be freed!
Many functions return non-opaque C structs; their documentation can be found inline, and in the generated GTK-Doc. Unless otherwise stated, the returned values should never be freed.
### Initialization
@ -29,7 +29,7 @@ Then you need to create a `GsweTimestamp` object:
GsweTimestamp *timestamp = gswe_timestamp_new_from_gregorian_full(1983, 3, 7, 11, 54, 45, 0, 1.0);
```
The `GsweTimetamp` object is used to convert dates between the Gregorian calendar dates and Julian Day values (not to be confused with Julian calendar dates!).
The `GsweTimetamp` object is used to convert dates between the Gregorian calendar dates and Julian Day values (not to be confused with Julian calendar dates).
Next, you have to create a `GsweMoment` object:
@ -86,9 +86,26 @@ The Swiss Ephemeris library requires the altitude value to be specified for seve
> the altitude above sea must be in meters. Neglecting the altitude can result in an error of about 2 arc seconds with the moon and at an altitude 3000m.
2 arc seconds is about 0.000555 degrees of error, which is, well, kind of small. Of course, if you need very precise horoscopes, precise horoscopes; otherwise, it is safe to pass any value (well, that seems logical. The average level of all dry lands is about 840 meters; the average level of the whole planet Earth (including oceans and seas) is around 280 meters).
2 arc seconds is about 0.000555 degrees of error, which is, well, kind of small. Of course, if you need very precise horoscopes or need planetary positions for a totally different thing, you should really provide a (close to) exact value; otherwise, it is safe to pass any value (well, which seems logical: the average level of all dry lands is about 840 meters; the average level of the whole planet Earth (including oceans and seas) is around 280 meters. Providing a value of ~400 should be OK most of the time).
## API stability
The project is currently marked as 1.0. This means that API and ABI changes are very unlikely to happen.
## Limitations
### Topocentric calculations only
Although the original Swiss Ephemeris library supports it, SWE-GLib can't do Heliocentric, nor Geocentric (as seen from the center of Earth) calculations, only Topocentric (as seen from a given point on Earth"s surface) calculations yet.
### Database size
The size of all data files provided by Astrodienst is around 40MB. Although it should not be a problem with today's home hardware, it can be a hard requirement on embedded systems. For basic calculations, keeping the following files under $(datadir)/swe-glib is usually enough:
* seas_18.se1
* semo_18.se1
* sepl_18.se1
### Fixed stars are not known yet
Although Swiss Ephemeris has the functionality to calculate the position of fixed stars, SWE-GLib doesn't provide such functionality. This, however, is a planned feature for the close future.