WISH LIST - Astro-mapping

[Jim Eshelman]

I know we're not going to get a graphical map out of this, but... down the road... maybe 0.9...

It would be easy to output a list for the geographic longitude of each planet (1) on MC and IC, (2) on EP and WP, and (3) on EP-a and WP-a (the latter being something that no existing software does). Such a list would be most useful, I think, if sorted by geographic longitude since the planet names would be easy to visually scan.

The hard part, of course, is how to display Asc/Dsc and Z/N. The way we used to do this manually (before computers) gives the inspiration: We could calculate the longitude of the crossing for several different latitudes and then connect the dots. (Yes, in high school I used to do this on printed maps with books of logs of trig functions. All praise Dover!)

One approach would be to ask the user for minimum and maximum latitude, decide in advance how many columns you could have, and then have the program decide from the input min/max what the plotting interval should be. For example, if I wanted the continental U.S. I could put in 25N to 50N (a 25° range): If you decide you can fit 10 of these |xxNxx| intervals across the page, the output would give the longitude of rising and of setting every 5° of latitude.

Since I have Solar Fire, I don't need this for myself EXCEPT the ability to calculate EP/WP in RA would be new. For those who don't have SF, this could be enormously useful - the simple table of longitudes combined with, say, Google Earth (which has easy long/lat listings on mouse-over) could be revolutionary. Also, no more trial-and-error to get an exact spot (other than a little interpolation between latitudes).

For a return chart, this would include both natal and transiting positions; but an option for a single chart would make personal relocation much easier (though I imagine the solunars option would be more popular). Having NATAL planet options in return charts (instead of just return/transiting planets) would be revolutionary!

[Jim Eshelman]

I think the programming is simple and the layout is all tables. Once width counting is determined, the rest should be super easy.

For a usability example: If I had wanted to find exactly the right spot for my 2021 SSR, the first part of the table would have such useful information as:

84W43 - r Ve EPa
90W22 - t Ju IC

Seeing this longitude, if I asked for all horizon crossings from 25N to 50N, the second half of the table would have (better organized than this):

25N00 @ 96W37 - t Uranus Dsc
30N00 @ 94W49 - t Uranus Dsc
35N00 @ 92N39 - t Uranus Dsc
40N00 @ 89W33 - t Uranus Dsc
45N00 @ 87W58 - t Uranus Dsc
50N00 @ 84W41 - t Uranus Dsc

With these numbers (which, admittedly, would be much harder to filter out of a long list of numbers, but much helped if the horizon items were sorted together by longitude), I could see that Uranus would set at the same time as Jupiter on IC between 35N and 40N, and would set with natal Venus on EP about 50N. I might check both locations, though my brain is already calculating that the Jupiter-Uranus is an actual paran and has the powerful beneficence of transiting Jupiter involved, while the Venus + Uranus is not a paran (not an aspect) and, while likely to be a good time, wouldn't have the same broad generosity from the universe as transiting Jupiter. Plus, the Venus + Uranus is probably too far north.

I can use Google Earth to wander my mouse around, or use Google Maps to search directly for the locations. A little interpolation gives me Uranus setting at 90W22 (t Jupiter on IC) at 38N41; Uranus set at 84W42 (r Venus on EP-a) at almost exactly 50N00.

I search the first as 38°41 N 90°22' W and get a spot on the outskirts of St. Louis. I can take this exactly or look around and see other cities in the general area, including Memphis (which I eventually picked). Seeing many options or a region on a map, it's easy and fast to run the SSR for each location and see what else is in the picture. Or, I can enter the Venus + Uranus as 50°00 N 84°42' W and confirm that this is in an obscure part of Ontario.

So I pick Memphis (but could have picked St. Louis (which didn't sound like nearly so much fun) and zoom in on an exact spot in town.

PS - The example depends on my numbers above being correct, which I'm not sure they are. I screwed up a couple of times and may have screwed up again. But the example shows what I'm talking about.

[mikestar13]

I'm thinking user can specify a longitude and latitude range (can be whole world) and granularity for longitude and latitude.

[Jim Eshelman]

I'm thinking user can specify a longitude and latitude range (can be whole world) and granularity for longitude and latitude.

I agree that users should be able to specify a latitude range, since that determines how the Ascendant-based contacts work. It seems to me, though, that granularity should be determined by the program with an easy way to "refresh" to a new long/lat zone.

I assume this will be something like: Selected a chart (one-ring or two-ring), click a Mapping button (or whatever label), be asked for coordinates range, then get the report on screen. The MC-based items (six per planet) can be sorted together but the Ascendant-based items have to be in some kind of grid (latitude vs. angle) - have you a more clever idea than this?

The ability to pop in and out quickly with different coordinates would be awesome! In the same way that right now we can test numerous SSR locations by <calculate, change city, click calculate again>, we could within seconds narrow location. In my example above, I'd determined natal Jupiter on IC at 90W22 and (from a first attempt) that Uranus would cross Dsc at this longitude between 35N and 40N. (It doesn't matter where!) I could then simply change the latitude max/min to 40N/35N and click Calculate - voila! I have a more granular report. Within a couple of more times of narrowing this (mere seconds of work), I'd have the latitude of the exact crossing just by gradually narrowing the latitude range.

Because I think this is the most practical way to use the tool, I don't think granularity should be a user control. (It also would affect your table design horribly.) I think (for easy table design) you should pick the maximum number of latitudes that fit on the page or screen. (Let's pretend the answer is 5, meaning 5 pairs.) Then, once the user has picked the latitude max/min, you just divide it by this number to determine the granularity. It will make things faster and easier for the user. - I also suggest that you drop out any planet lines that don't fall in the range (e.g., if Mercury isn't on one of the four Asc-based angles, its line doesn't appear on the chart, so the option of available planets keeps narrowing as latitude range narrows). This filtering would look miraculous.

Especially since the user choices for this option will be few (at most, lat range and long range), I wonder if there could be a few buttons for preloaded coordinate ranges, e.g., "Continental U.S." 25N-50N x 65W-125W, "Europe" 25W-40E x 35N-75N (I was liberal with "Europe," not using EU boundaries), etc.

[mikestar13]

Your assumption is correct unless I think of something better, and it is probably worth dedicating a release to. Preloaded ranges are easy and will be done.

Discussion continued: https://www.solunars.com/viewtopic.php? ... 103#p48238

[Jim Eshelman]

One approach would be to ask the user for minimum and maximum latitude, decide in advance how many columns you could have, and then have the program decide from the input min/max what the plotting interval should be. For example, if I wanted the continental U.S. I could put in 25N to 50N (a 25° range): If you decide you can fit 10 of these |xxNxx| intervals across the page, the output would give the longitude of rising and of setting every 5° of latitude.

I thought I'd give an example of what I have in mind for this table. Mike, you may have a better vision, of course (you're awesome at table efficiency), but I thought I should be more visual in what I was thinking in the posts above (the usability model in my head).

What comes before: The first table should be a sort by geographic longitude of all planets for when they cross MC (in RA), IC (in RA), EP (in RA), EP (in long), WP (in RA), and WP (in long). It doesn't matter how many planets are selected: The table just goes on until it's done. Obviously, you can have many columns across the page to shorten its depth.

What comes next: Planet positions on Asc, Dsc, Z, and N vary by latitude: You need two coordinates (longitude and latitude) to identify them. The old manual calculation approach (which serves well here) was to calculate the longitude of angularity for each of several latitudes (say, at 5° intervals) then to take a physical map and draw lines on it.

What we need are:

• For each planet (natal and transiting) in use...
• ...the geographic longitudes of four angularities (Asc, Dsc, Z, N)...
• ...for a lot of different geographic latitudes.
• For use, all entries for a given planet need to be next to each other (all Mercury on Asc entries next to each other), not the set of all planets sorted together.

Because we have a minimum of 20 factors (in a return chart), and possibly more, we have to deal with an enormous amount of noise-abounding data. Fortunately, reducing this is easy.

Because having all entries for a given planet placed together is a big priority, and because each planet has only four angular crossings but potentially many different latitudes, the table should have the four angles (of a given planet) as the rows and as many latitudes as fit as the columns.

On counting columns: It looks like you're using 73 columns. Thinking initially of no more than 80 across, it goes something like: Put planet name above its five-row table. 2 chars for the angle and a space (leaves 78). Each entry should go to seconds, so xx°xx'xx" is 10 (with a space). So you can fit 7 latitudes. (Or "most possible" may make most sense.) Here's a sample table:

Code: Select all

TRANSITING MERCURY
  25N 0' 0" 30N 0' 0" 35N 0' 0" 40N 0' 0" 45N 0' 0" 50N 0' 0"
A xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" 
Z xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" 
D xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" 
N xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" 

Or, with 7 columns (interval divided by 6):

Code: Select all

TRANSITING MERCURY
  25N 0' 0" 29N10' 0" 33N20' 0" 37N30' 0" 41N40' 0" 45N50' 0" 50N 0' 0"
A xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00"
Z xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00"
D xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00"
N xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00" xxWxx'00"

From this point, the math is straightforward. Layout and usability are the considerations, because we'll have at least 20 tables like this initially. If the whole world is selected, it is an expansive, breathtaking, comprehensive table (that needs a simple circumpolar check on a planet: no latitudes above its co-declination, etc.). As the user narrows latitude and longitude range, the tables start narrowing and simplifying elegantly: Though there won't be a map, the user will nonetheless visually observe the options narrowing and simplifying as the long/lat range is changed, if the following two filters are applied:

• If, for the selected geographic range, the planet on a specific angle (e.g., Me Asc) doesn't occur, don't print the line.
• If all four lines for a given planet are empty, don't print that planet's section at all.

BTW, I've changed my mind on thinking we don't need longitude filtering: You were right, it's basic to the tool and makes the above filtering quite powerful and usable. Obviously, on the earlier MC/IC/EP/WP table, any value outside the selected longitude range would not be printed.

Final usability, I think, is elegant. The user picks a calculated SSR (it could be a natal, too, of course) - this automatically has precessed natals included - and picks the widest geographic range (whole world, U.S., some other range). Click Calculate and study the tables to find desired lines. Change lat/long range, click Calculate, and instantly have a narrower range with fewer planets and lines. Rinse and repeat: With a couple of more iterations (each taking a few seconds), one can "walk down" to an exact longitude and latitude. I doubt this will ever take more than four or five iterations if one starts at an area as large as, say, the U.S.

Once you add a feature you've mentioned - bi-wheel for any two charts - this would let someone answer a question like, "Is there a place in the U.S. where two people could both be happiest?" in a few minutes at most. (The answer usually will be, "No, there aren't enough lines overlapping," but - if there IS an answer - it will only take a few minutes to answer a question of that magnitude.) Finding a spot for personal relocation (of a natal) isn't much more complicated than knowing the geographic limits (wqhere you're willing to live).

Having worked on one of these this morning, I can easily get very excited about it. Even without a map, it would blow away anything else anyone has produced for astrologers to use. It produces at-a-glance answers that someone with the least amount of astrological knowledge (just a basic knowledge of the planets' natures, usually no more than knowing benefics vs. malefics) could intuitively use.

Additional feature: I suppose one of the buttons on the mapping page should be a temporary selection of which planets to use. This would be useful for the most common types of questions, such as, "Where in the world do I have Venus or Jupiter [or pick your planets] on an angle?" Run for the whole world, get the longitude table and (in this case) the short Venus and Jupiter tables, and start narrowing from there.

An exciting possibility: You could have a button that opens Google Maps in a browser for the center of the selected lat/long boundaries. (Ignore curvature, just arithmetic center.) People could see at a glance (after scrolling out) what's in the broad area they're searching, and watch it narrow as they narrow the bounds. The web path (using a spot near my home where GPS currently thinks I'm sitting) is:

https://www.google.com/maps/place/34.06 ... 18.3111258

[Jim Eshelman]

This merits a version of its own, but this will happen if I'm spared. I would really like to have the any two charts in a bi-wheel mechanism in place first. I'm thinking some time in 2023.

Thanks: It would be a literal God-send to, oh, everybody. (Dare I say: Even without maps, this could literally PUT TMSA ON THE MAP.)

[Jim Eshelman]

Great idea and doable.

As time goes by (and with the requests we get here increasingly), I think this is one of the highest items on my wish list. It would be revolutionary, providing things nobody provides and making zeroing in on a precise location simplicity itself. In a minute or two, someone could actually plan how to make their life significantly better.