×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Automatic import of Horizon files from Observer Pro

  • Posts: 527
  • Thank you received: 139
Thanks for taking a look at it. Nice to know it can be done at least manually. I’m personally not comfortable editing the SQL database, so don’t think I’ll try it. But the horizon looks good other than what you mentioned at the North Pole, it doesn’t look like it closes the last polygon.
4 years 1 month ago #49784

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10
I really don't get the existing input interface. I just manually entered the 360 values from observer pro, still get the message "invalid polygon ...", I set the last and the first value to the same values, does not work, I tried to change the value for the first row, now it only accepts 0.

Somehow finally I managed to get something working, but it puts the VISIBLE area in red shade, is that intended?
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

3 years 6 months ago #59291

Please Log in or Create an account to join the conversation.

  • Posts: 527
  • Thank you received: 139
Strange, that seems wrong to me. Also, apparently the scheduler does not take the horizon into effect. so maybe this feature is essentially useless unless you need to see where your horizon is in KStars just for picking targets. But I usually use SkySafari for that, and it will directly import the horizon file from Observer Pro.
3 years 6 months ago #59292

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10
Yes, it is definitely strange. I would like to use it with the scheduler, but I am fine for now, using it for target selection. Observer pro is fine for general selection, but when it comes to selecting the right gear for the required FoV, KStars is way better.

Attached is a screenshot of my red visible area.
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

3 years 6 months ago #59293
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
I just finally got my custom horizon to work this afternoon after having precisely the same problems as RogueSquadron.

The trick is to "close" the polygon by "wrapping" the actual horizon with a string of fake points along the zero elevation (underneath the values you have already put in). Depending on the projection and zoom level you use in KStars both the real values and the "fake" zero values that close the polygon have to be fairly dense or you get weird artifacts. Closing the polygon underneath like this will reverse the "blocked zenith/open trees" problem RogueSquadron describes above ("VISIBLE area in red shade").

I will experiment with the SQL editor approach outlined by Fenriques. It sounds like this is a better long-term solution but requires installing software.

As Andrew/Lead_weight points out, the whole thing is kind of futile because Ekos doesn't pay any attention to the artificial horizon anyway. This is a shame and certainly it would make Ekos more useful to be able to mask off part of the celestial sphere to prevent slewing or imaging there. It's especially handy to have this in mount modeling, as I use it in TheSkyX. 15 minutes of automatic mount modeling with solved images in the visible part of the sky at dusk does a world of good for pointing the rest of the night!

Here's a a simple example:
Suppose your tree/house/garage line is 20 degrees high everywhere except due south where there's a big tree that sticks up 50 degrees. In that case you might use:

AZ ALT
0 0
1 20
90 20
170 20
180 50
190 20
270 20
359 20
360 0
30 0
60 0
90 0
120 0
150 0
180 0
210 0
240 0
270 0
300 0
330 0
360 0
The following user(s) said Thank You: Alfred
3 years 6 months ago #59294

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
I used Fenrique's method to redo my horizon in KStars and it worked very well (see attached).

You can see that (a) I have a LOT of trees and not much sky; and (b) the colored area is in the right place (not at the zenith!). You can tweak the colors so your trees aren't red.

Steps I used:

ON MY LAPTOP
1) Laboriously create a horizon file. Observer Pro works. I hacked my own as a list of altitudes in a text file
2) Use external programs (spreadsheet, python, whatever) to interpolate and trim to a list of about 180 points
3) Concatenate a bunch of zeros along the base to "close the polygon"
4) Save as a csv file & copy to the R Pi where I run Kstars

ON THE PI
5) Make a backup of the KStars database: cp .local/share/kstars/userdb.sqlite .local/share/kstars/userdb.sqlite.backup
6) Copy the database to someplace I can edit it more easily: cp .local/share/kstars/userdb.sqlite ~
7) Install a SQL Editor on the pi: sudo apt-get install sqlitebrowser
6) From the pi menu, start DB Browser for SQLite

In DB Browser for SQ Lite
8 ) File->Open Database & choose ~/userdb.sqlite
9) File->Import ->Table from csv file ... choose your csv file & label new table "my_horizon"
10) Choose tab "Browse Data", click pull-down "Table" and choose table named "horizons" (see 2nd screen cap)
11) Either "Add Record" or in my case edit the existing record (see 3rd screen cap)
12) First value id doesn't matter. Mine said 12. No problem
13) Second value "name" must be the name of the table you created in step 9 above "my_horizon"
14) Click on this value, but then type in the "Edit Database Cell" box on the right side of the window (see 3rd screen cap)
15) After you've entered the new value in the right side, you MUST click Apply (see 3rd screen cap)
16) Now do the same for the third value in this record "label": click on the existing value
17) Edit the value in the right pane "Edit Database Cell"
18) Click Apply
19) Make sure the fourth value "enabled" in the record is 1 (mine already was)
20) Click tab "Write Changes" near top of window (see 4th screen cap)
21) File -> Exit (or click close app)

IN PI TERMINAL
22) cp ~/userdb.sqlite .local/share/kstars

23) Then restart KStars and voila! A nice horizon, except for that weird notch at the north pole (see 1st screen cap)

Obviously this is ridiculously complicated, especially as you have already gone to the trouble to digitize your whole horizon and save it in a text file!

It would be nice if this was easier, but the REAL wish list item is to have Ekos honor the custom horizon as a slew limit and a guide for the scheduler!

Hope this helps,
Scott
The following user(s) said Thank You: Alfred
Last edit: 3 years 6 months ago by Scott Denning.
3 years 6 months ago #59300
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Yes, as already mentioned you need to close the polygon(s) against the horizon to make it valid.

It's however still quite limited in use, as it gets rendered fixed on the sky background when you enable it, and then gets moved together with the skymap, instead of being fixed to the horizon. So if you enable it, then wait, you'll see that after a while it detaches from horizon, and stars would never vanish behind the mask, unless you open the control menu again and hit 'Apply'. See attached image, after waiting some 20 minutes....
3 years 6 months ago #59315
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
Weird. My artificial horizon is rendered correctly for many hours (all night) with the stars moving through the "hole in the trees" till morning.

It's pretty, but would be a lot more useful if Ekos treated it as the true horizon by scheduling around it and preventing slews underneath it!

3 years 6 months ago #59322
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133

.... no idea what to say. What is different in your setup? Is it because my horizon is only a small part, and not all around?

:blink:
3 years 6 months ago #59330

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
I dunno ... maybe a different projection?

At any rate it's just eye candy until the Ekos Scheduler can see it.
3 years 6 months ago #59332

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
It is something in kstarsrc. If I remove that, i.e., start from scratch, the horizon map stays in place relative to the horizon. Guess I'll have to step through all settings to locate the culprit :-/
3 years 6 months ago #59575

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10
Is there a limit of points per polygon? I entered 360 + 36 points and the next time, only part of them were saved.
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

3 years 6 months ago #59576

Please Log in or Create an account to join the conversation.

Time to create page: 0.875 seconds