Indian vedic sky culture: Show longitude for the 27 asterisms

[vishvAs vAsuki]

Indian vedic sky culture divides the sky into 27 strips (full list, with western equivalents here: https://goo.gl/2PVi28 ), each approximately 360/27 ~ 13 degrees. This division is critical for several purposes including timing rituals and determining the birth lunar mansion/ nakShatra. As it is, users are forced to enable the ecliptic grid and then imagine parallel grid lines running through asterisms in the set of 27. Example pic: https://i.imgur.com/gRcwqcD.jpg . This is clumsy and inaccurate. So, the vedic indian sky culture should show the required 27 grid lines by default.

PS: Provided guidance, I will be glad to assist if needed - I am an active in the sanskrit programming community ( groups.google.com/forum/#!forum/sanskrit-programmers ) .

[Alexander Wolf (alexwolf)]

You can update the Indian vedic skyculture and propose patch for us.

[vishvAs vAsuki (vvasuki)]

@alexwolf, gladly - but I need to know the following:

- How to show desired equatorial grid lines (once I determine from other sources precisely where it should be placed) ?

- How to mark a group of stars clearly? For example, according to the link provided earlier: मूला (Mūla) is ε, ζ, η, θ, ι, κ, λ, μ and ν Scorpionis with position 00SG00-13SG20..

[vishvAs vAsuki (vvasuki)]

First question remains, but regarding the second question above a modification: I now realize that http://bazaar.launchpad.net/~stellarium/stellarium/trunk/view/head:/skycultures/indian/constellationship.fab lists the stars. But, how to show a boundary - ie surround these stars (82396 82545 82545 82729 82729 84143 84143 86228 86228 87073 87073 86670 86670 85927 85927 85696) with a dashed line?

[Alexander Wolf (alexwolf)]

No dashed line, but boundaries of the constellations is possible - see data/constelaltions_boundaries.dat file for details. Similar file should be created for Indian skyculture (he should be put with other files of skyculture).

[vishvAs vAsuki (vvasuki)]

Thanks for the idea. How do I understand what each line means? For example, what is each field in this line:

3 20.6386585 2.4360874 20.6392918 1.4361323 20.6399231 0.4361772 2 AQL AQR

[Alexander Wolf (alexwolf)]

This line need read as: 3 couples of coordinates (with sequence of RA & Dec for each point) for border between 2 constellations - AQL and AQR.

[vishvAs vAsuki (vvasuki)]

hi @alexwolf : I want to draw a line between the ecliptic poles via http://simbad.u-strasbg.fr/simbad/sim-id?Ident=Beta+Arietis , but:

3 270 66.82 028.66004579 20.80803147 90 -66.82 2 N27 N01

yields a totally misplaced line - http://imgur.com/a/S8iEk . How to fix?

[Alexander Wolf (alexwolf)]

RA is given in decimal hours, not degrees.

[vishvAs vAsuki (vvasuki)]

Thanks- Just to double check, would 1 hour 54 minutes be 1+54/60 (and not 1.54)? Also do you know of any website which would, given a star, provide the decimal hour for a given star (like http://simbad.u-strasbg.fr/simbad/sim-id?Ident=Beta+Arietis )?

[vishvAs vAsuki (vvasuki)]

I've deduced the answer to my first question by experimenting - and things look good so far - http://imgur.com/a/NITiZ . Once I get an answer for the second question, I should be able to rapidly add the other 26+ boundaries.

[Alexander Wolf (alexwolf)]

wolframalpha maybe useful tool here

[vishvAs vAsuki (vvasuki)]

shrI tanmoy in https://bugs.launchpad.net/stellarium/+bug/1710444/comments/15 and https://bugs.launchpad.net/stellarium/+bug/1711229 claims: "There is no mention of specific boundary co-ordinates of constellations in any authentic Vedic scripts or any papers, except that the ecliptic is divided into 27 equal parts of 13deg20". As such boundary or gridline implementation may not be correct."

This seems to be the best thread to discuss the matter.

1. There is explicit definition of boundary coordinates of nakShatra-s in the highly regarded text sUrya-siddhAnta in the form of yoga-tAra-s or junction stars ( Please refer to the last paragraph of this page: https://archive.org/stream/HistoryOfCalendarPanchangaCommittee/History-of-Calendar-Panchanga-Committee#page/n41/mode/1up ) .

2. Furthermore, it is clear from current ritual + astrological theory and practice (as I've elaborated in https://bugs.launchpad.net/stellarium/+bug/1710444/comments/16 ) that one needs to observe and ascertain the exact 13deg20 strip (or substrip thereof) which contains various celestial objects. This necessarily involves imagining elliptic longitudes separating the 13deg20 naxatra strips. Hence, this motivates making the task simple by drawing them out. And indeed, they are nothing but boundaries between the naxatra-s.

PS: Responses starting tomorrow until next wednesday will be delayed as I'll be travelling to witness the total solar eclipse.

[vishvAs vAsuki (vvasuki)]

A bit of clarification regarding [1] above. yoga-tAra-s are supposedly the most prominent stars *within* a naxatra-division, and do not by themselves specify the start of the respective divisions. Rather, sUrya-siddhAnta and vedAnga-jyotiSha specify start coordinates for the 13deg20 divisions using other stars (Please see penultimate paragraph in the next page: https://archive.org/stream/HistoryOfCalendarPanchangaCommittee/History-of-Calendar-Panchanga-Committee#page/n42/mode/1up ).

[vishvAs vAsuki (vvasuki)]

@alex, I think you missed my question in https://bugs.launchpad.net/stellarium/+bug/1710444/comments/16 : "are the last 2 fields in `3 18 66.82 1.9 20.80803147 6 -66.82 2 N27 N01` of any significance at all? Can they correspond to asterisms?"

[vishvAs vAsuki (vvasuki)]

shrI tanmoy in https://bugs.launchpad.net/stellarium/+bug/1710444/comments/19 onwards says: "Yes and that will create more confusion for most of the general users. That's why I think boundary implementation should be avoided but transliteration is very good idea. Pro user can implement this for their own use. We may provide a link in description to download the boundary.dat file but in default package it should not be included. ... I also created the boundary in first time but when I show some of my friends who uses stellarium regularly basis their opinion was it was confusing. ... " and attaches https://launchpadlibrarian.net/333918325/im2.png to illustrate the source of the confusion.

Regarding this, I observe that constellation boundaries can be toggled by the user as he desires, and they are off by default. As such, the non-serious user will not face such confusion unless they go and manually turn on boundaries for the Indian vedic skyculture. We can ward off confusion even in such a case by adding an appropriate note in the description. That should be good enough for non-serious Indian vedic skyculture users (which likely includes your stellarium user friends).

Asking serious vedic skygazers to download a boundary.dat file and copy it over to some directory by contrast is a much bigger burden, which we should avoid. Things should work well out of the box.

BTW, is there a good way of tagging particular users?

[vishvAs vAsuki (vvasuki)]

shrI tanmoy in says: "Found my old boundary.dat file and attached to the branch.
https://code.launchpad.net/~t4saha/stellarium-skycultures/indianV2boundary " This seems to solve the nakShatra-boundary problem. @tanmoy can you tell me how exactly you deduced these coordinates? Did you use a script? If everything looks good, we can just use that file to take care of this bug.

[Alexander Wolf (alexwolf)]

> "are the last 2 fields in `3 18 66.82 1.9 20.80803147 6 -66.82 2 N27 N01` of any significance at all? Can they correspond to asterisms?"

No, N27 and N01 should be significance of constellations. It's obvious IMHO.

[Tanmoy Saha (t4saha)]

I used stellarium to get those coordinates.
Just use: bzr branch lp:~t4saha/stellarium-skycultures/indianV2boundary in terminal then change accordingly and commit and push the update.

[vishvAs vAsuki (vvasuki)]

@alexwolf, the user guide states:
```
N RA_1 DE_1 RA_2 DE_2 ... RA_N DE_N 2 CON1 CON2
  where
  N number of corners
  RA_n, DE_n right ascension and declination (degrees) of the corners in J2000 coordinates.
  2 CON1 CON2 legacy data. They indicated “border between 2 constellations, CON1, CON1” but
  are now only required to keep the format.
```

But you say that N27 and N01 *should be* constellations and not asterisms or junk symbols. Am I to understand that violating your recommendation will break older (legacy) versions of stellarium but not newer ones? If so, how old? If possible, we would like to switch to representing naxatra-s with asterisms.

[Alexander Wolf (alexwolf)]

Yes, it's correct. We use separate file for asterisms now.

[Alexander Wolf (alexwolf)]

> 2 CON1 CON2 legacy data. They indicated “border between 2 constellations, CON1, CON1” but are now only required to keep the format.

Oops... it's not correct, because we use it for isolated boundaries.

[Alexander Wolf (alexwolf)]

I think I should update subsection 9.8 in the Stellarium User Guide.

[vishvAs vAsuki (vvasuki)]

Thanks, alexander - an update to the guide is indeed useful.
I have opened https://bugs.launchpad.net/stellarium/+bug/1712641 , but in the meanwhile we can stick with constellations to represent both raashi-s and nakShatra-s.

[vishvAs vAsuki (vvasuki)]

It delights me that so far shrI tanmoy's boundaries help me so that - I can for the first time **see** that the moon is in hasta - http://imgur.com/a/AJXF5 compared with http://www.prokerala.com/astrology/nakshatra-finder/?date=2017-08-25&time=03%3A06&loc=1277333&p=1 !

[Tanmoy Saha (t4saha)]

Mathematically boundaries are correct in the boundary.dat file. But The mathematical division does not fit with the division made with main star or Yogtara. So boundary implementation create more confusion for general users. More than 40% of Constellations or Nakshatra lies outside its mathematical boundaries. I think boundary implementation by default is not a good idea.

[vishvAs vAsuki (vvasuki)]

Namaste tanmoy.

* Boundary, as I said, is off by default - exactly as you desire.
* That the ecliptic division only roughly corresponds to the nakShatra-s is very well known among people with a basic introduction to vedic jyotiSha. (This is incidentally very much the case with western astrological tradition - the aries zodiac does not correpond in the current epoch with aries constellation!) People with no clue about the Indian vedic astronomical tradition are informed better by the description.
* It is not clear what boundaries you have implemented (I have not checked). In the hindu tradition, there are different opinions based on where the boundaries should like (you get different ones by varying the ayanaamsha - see http://www.astro.com/swisseph/swisseph.htm for an introduction. We will need to provide multiple boundary files to support these ayanamsha-s, with the lahiri-ayanamsha as the default.

[vishvAs vAsuki (vvasuki)]

Considering the above, I now wonder if we should take the following approach instead to clearly *see* the division of the ecliptic based on raashi-s and nakshatra-s :

* Leave the current nakShatra and raashi definitions be; with no added boundaries.
* Add boundary lines for newly defined *imaginary* raashi-s and nakshatra-s (eg: IN01 .. IN27), to divide the ecliptic as desired.

In this way, we are being clear about the rough correspondence between the raashi-s and nakshatra-s with the ecliptic "boundaries", while letting users benefit from the ecliptic partition display. In the future, if and when stellarium supports specification of longitudes by skycultures (as originally requested in this thread), we may elide this roundabout "boundary" technique.

BTW, the longitudes that show up look nothing like constellation "boundaries". So, user confusion seems all the more remote (unless he or she is primed by incomplete information).

[Alexander Wolf (alexwolf)]

> In the future, if and when stellarium supports specification of longitudes by skycultures (as originally requested in this thread), we may elide this roundabout "boundary" technique.

Funny. Please explain me one interesting result, who go from quoted sentence: what difference between boundary line, who leaves through the ecliptical longitude 13 degrees and some partition marker, who located on the ecliptical longitude 13 degrees? This is different 13 degrees in one scale? :D

I know how I can "put the constellations in described partitions" - just introducing a variable size of the degree. For example in the first nakshatra one degree will 0.8 of "standard size" and in second nakshatra one degree should be equal 1,2 of "standard size".

So that:
1) Current definition of partitions of nakshatra's is wrong
2) Current implementation of nakshatra's figures is wrong
3) Definition of partitions is given for one concrete date or epoch in the past and for modern time it's no have meaning.

You can select any "wrong" point :)

[vishvAs vAsuki (vvasuki)]

Hi @alexwolf -

I could not understand your first paragraph at all - perhaps you could rephrase? Did you mean to use the word "which" instead of "who"?

"I know how I can "put the constellations in described partitions" - just introducing a variable size of the degree. For example in the first nakshatra one degree will 0.8 of "standard size" and in second nakshatra one degree should be equal 1,2 of "standard size"." -> No, this is not how the Indian traditions do this. The "degree" is not redefined. So, I don't know why this proposal is pertinent.

The partitions of the sky are named after nakShatra-s, and they only roughly correspond with them in the current epoch. Still, the partitions are meaningful and useful; and the names of the partitions are not fully arbitrary.

[vishvAs vAsuki (vvasuki)]

I catch the drift from both @alexwolf and tanmoy's comments that you feel that the desired partition boundaries should not be implemented as nakShatra boundaries (based on conceptual ugliness in the force-fit, rather than any user inconvenience). This is reasonable. Perhaps we can use separate imaginary nakShatra-s as a stop-gap solution, as proposed.

Even that is unsatisfactory because:
* One needs to define these imaginary nakShatra-s.
* The actual boundaries (even having fixed the ayanAmsha regime) moves with time (dependent partly on the speed of the vernal point). The imaginary-nakShatra-boundary will only be good for today, but not for some other far-away time.

So what one really needs is support for defining ayanAmsha-based partition of the sky into 27 equal strips. What is the best way to accomplish this? (some script perhaps?) And how about the imaginary nakShatra solution for now?

[vishvAs vAsuki (vvasuki)]

namaste tanmoy, I finished writing code to produce the nakShatra-strip-boundaries - https://github.com/sanskrit-coders/jyotisha/blob/master/jyotisha/zodiac.py .

Regarding the boundaries you had provided earlier: They seemed to match the Lahiri ayanamsha regime for the current date (except that the RA values were all wrong, while the declination values were all right). The fixed boundaries look as follows - http://imgur.com/a/fxN3c , which seems quite sane.

[vishvAs vAsuki (vvasuki)]

Please ignore the last comment above - There's possible bug https://github.com/sanskrit-coders/jyotisha/commit/86c13cb0e3cf51bb9eb6a4726a047f0afdec97fc##commitcomment-23899164 .

[vishvAs vAsuki (vvasuki)]

Ah - all is well; it was a false alarm. Comment #31 holds.

[vishvAs vAsuki (vvasuki)]

I await a response for #30 . Mainly:

"So what one really needs is support for defining ayanAmsha-based partition of the sky into 27 equal strips. What is the best way to accomplish this? (some script perhaps?) And how about the imaginary nakShatra solution for now?"

[Alexander Wolf (alexwolf)]

The bug report was moved to https://github.com/Stellarium/stellarium/issues/437