No Asc or Mc for Whole Sign - House System Selection

[1OnesAndZeros0]

Thank you so much for implementing the house system selection! This is great!

However there's still the problem of showing the Asc and Mc as 00°00'00 when generating the SVG.

Using the John Lenon example, they should be Asc: 16°04' and Mc: 5°33' (rounded by the generator I used) for the Whole Sign system.

Unless there's something I'm doing wrong?

          Closing, here the example of the implementation:

https://www.kerykeion.net/docs/examples/houses-systems

Originally posted by @g-battaglia in #105 (comment)

[g-battaglia]

Hi, can you share a code snippet of the issue?

[1OnesAndZeros0]

Here's a sample of a script I'm using:
`from kerykeion import AstrologicalSubject, KerykeionChartSVG

def get_user_input():
name = input("Enter the person's name: ")
year = int(input("Enter birth year: "))
month = int(input("Enter birth month (1-12): "))
day = int(input("Enter birth day: "))
hour = int(input("Enter birth hour (0-23): "))
minute = int(input("Enter birth minute (0-59): "))
city = input("Enter birth city: ")
nation = input("Enter birth country code (e.g., US, CA, UK): ")
return name, year, month, day, hour, minute, city, nation

def generate_birthchart():
print("Please enter the birth information:")
name, year, month, day, hour, minute, city, nation = get_user_input()

# Create an AstrologicalSubject instance with user input
person = AstrologicalSubject(
    name=name,
    year=year,
    month=month,
    day=day,
    hour=hour,
    minute=minute,
    city=city,
    nation=nation,
    houses_system_identifier="W"  # Whole House system
)

# Create a KerykeionChartSVG instance
person_chart = KerykeionChartSVG(person)

# Generate the SVG
person_chart.makeSVG()

print("\nSVG generated successfully!")
print(f"The Whole House system chart has been saved as '{name}_Chart.svg' in your home directory.")

if name == "main":
generate_birthchart()`

I've tried hard coding as well. 
You can see in the attached image.

[g-battaglia]

Hi @1OnesAndZeros0, I'm not much of an expert of the Whole Sign system. Can you provide me more details about how it should work?
I checked and it looks there are not issues with the code, the data is correctly generated by the underling implementation of the swiss ephemeris.

[fkostadinov]

@g-battaglia In the whole-sign house system (preferred in India), the sign which the ascendant falls into is simply considered house 1. For example, if the ascendant is in 20° gemini then house 1 spans from 0° gemini to 30° gemini, HOWEVER the AC/DC axis itself is still defined as being in 20° gemini / 20° sagittarius. Even in an extreme situation where the AC falls into e.g. 29°59' of gemini, house 1 is still defined as 0° gemini to 30° gemini. But only a few minutes later all the houses "jump" from gemini to cancer. (That's why birth time correction is very important in this situation.)

Once house 1 is defined taking this approach then all the remaining houses are simply counted according to the signs, so house 2 is 0° cancer to 30° cancer, house 3 from 0° leo to 30° leo, and so on. Cusps of house 10/4 are NOT aligned with the MC/IC! The effect is that the MC may end up anywhere in the houses 9, 10 or 11 (and the IC accordingly anywhere between h3, 4 or 5).

[fkostadinov]

@g-battaglia I have been working on this issue. Right now, the explicit calculation of Asc/Desc and MC/IC works fine locally on my laptop. I have pushed the preliminary work here: https://github.com/fkostadinov/kerykeion/tree/fix_axes_with_equal_sign_houses

However, I'm now stuck with the calculation of aspects to and from the axes. I don't fully understand the intended logic in aspects/natal_aspects.py or tests/aspects/*.

What looks like a challenge here is the assumption that axes are necessarily congruent with houses. That might be true with house systems like Placidus or Campanus, but it's not true with whole-sign houses. As I wrote above, in Indian astrology using whole-sign houses AC always is in house 1, and therefore DC always in house 7, but the MC can be located in any of the houses 9, 10 or 11. (I don't know if there are scenarios where it could even in houses 8 or 12, e.g. for horoscopes very far north or south, cannot tell.)

In kr.config.json I find this:

    {
      "id": 13,
      "name": "First_House",
      "color": "var(--kerykeion-chart-color-first-house)",
      "is_active": true,
      "element_points": 40,
      "related_zodiac_signs": [],
      "label": "Asc"
    },
    {
      "id": 14,
      "name": "Tenth_House",
      "color": "var(--kerykeion-chart-color-tenth-house)",
      "is_active": true,
      "element_points": 20,
      "related_zodiac_signs": [],
      "label": "Mc"
    },

And in natal-aspects.py there is AXES_LIST, maybe building on these settings, I'm not fully sure. I don't know exactly whether or not this causes troubles with whole-sign houses.

[g-battaglia]

Thank you so much for your contribution, it's greatly appreciated! 😊 However, this is an issue that must be addressed in a major version. Therefore, even if we tackle the aspects calculation, I won’t be able to release it in the short term.

I’ll make sure to review your commit as soon as possible and move it to a separate branch so it will be available when it’s time for the final merge.

[fkostadinov]

Alright, I was successfully able to fix test cases including ascendant for tests/aspects/test_natal_aspects.py. In kr.config.json I set the is_active flag for ascendant to true for this. This could also be rightfully put to false, not sure how important aspects to AC/DC are. Pushed this to my own branch in my own repository.

    {
      "id": 20,
      "name": "Ascendant",
      "color": "var(--kerykeion-chart-color-asc)",
      "is_active": true,
      "element_points": 0,
      "related_zodiac_signs": [],
      "label": "Ascendant"
    },

I have not tested aspects to MC/IC though at this point.

Test cases for synastry aspects are now also failing, given that AC/DC must be taken into account between two horoscopes, but that should only be a matter of effort now that I (hopefully) understand all the pieces. Hope I can finish this in the next few days too.

@g-battaglia Can you elaborate, what's holding you back to publish this in another minor version (once all other things are fixed)? The reason why I'm working on this is that it's crucial for vedic astrology. Of course I can also use the branch for the moment for my own purposes, but having an "officially published version" is just nicer. :)

[fkostadinov]

Finally I also fixed the synastry aspects including aspects to each other's ascendant between two people's charts. (I did still not include calculations with the MC/IC axis, though.) Code is here: https://github.com/fkostadinov/kerykeion/tree/fix_axes_with_equal_sign_houses

I see that now tests/charts/test_charts.py is failing. Will look into that next.

[g-battaglia]

@fkostadinov

Can you elaborate, what's holding you back to publish this in another minor version (once all other things are fixed)? The reason why I'm working on this is that it's crucial for vedic astrology. Of course I can also use the branch for the moment for my own purposes, but having an "officially published version" is just nicer. :)

The main reason is that it could potentially introduce breaking changes for all applications using v4. I'll take a deep look at it, and if it doesn't, I'll be super glad to merge it and publish it in v4!

I see that now tests/charts/test_charts.py is failing. Will look into that next.

When your done with that, can you squash al the commits in a single one a open a pull request?

Thanks again for the contribution!

[fkostadinov]

When your done with that, can you squash al the commits in a single one a open a pull request?

Yes, will do and keep you posted. Not sure I'll finish until my vacation end on Sunday, though, so maybe this will take me a bit more time.

[fkostadinov]

Finally, I fixed everything as far as my understanding was able to take me. When running tests/charts/test_charts.py, I am still confronted with errors how the SVG is actually built, but here I'm really missing information on the structure and logic of those SVGs. The error right now is this:

Expected: xlink:href='#Mean_Lilith' /></g><g kr:node='ChartPoint' kr:house='None' kr
Actual: xlink:href='#Mean_Lilith' /></g><g kr:node='ChartPoint' kr:house='First_Ho

I did not fiddle around with Mean_Lilith, so no idea why the house should be None in the first place rather than the actual house placement of it? Anyway, I will now create a pull request with corresponding documentation. Would be lovely to include this!