×

INDI Library v1.9.6 Released (21 May 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Automatic import of Horizon files from Observer Pro

  • Posts: 527
  • Thank you received: 138
I use Observer Pro on the iPhone to generate horizons using the iPhone camera. It has an export feature that exports the coordinates to a text file. I've used it to generate a JPG to bring that horizon into SkySafari (detailed in my linked blog post), but would like to see if there were a way to add functionality to import it into the horizon manager within KStars. Here's the file it generates for reference.

File Attachment:

File Name: horizon.txt
File Size:3 KB
-Andrew
––––––––––
Mac Observatory - All about using the Mac for Astrophotography: www.macobservatory.com
Astrobin: www.astrobin.com/users/Lead_Weight/
2 years 4 months ago #49628
Attachments:

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

  • Posts: 527
  • Thank you received: 138
An update to my wishlist feature here. After talking to the developer of Observer Pro, the text file it outputs lists the coordinates in sequential number. The first number in the text file is 0, then 1, 2, 3, etc. The coordinates are ordered altitude first, azimuth second. Using the example numbers below the first number would be 42° Altitude, 0° azimuth, and so on down the line.:

0,42.00
1,41.20
2,40.40
3,39.00
4,36.50

These are just the first 5 points in the text file linked above. There are 300 points! A lot to input manually. It would be fantastic if KStars could import the text file or allow me to upload in some way that doesn't require me manually entering 300 data points.
-Andrew
––––––––––
Mac Observatory - All about using the Mac for Astrophotography: www.macobservatory.com
Astrobin: www.astrobin.com/users/Lead_Weight/
2 years 4 months ago #49731

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

  • Posts: 839
  • Thank you received: 108
Seconded. Any import possibility would be great that understands a well documented (text) format.
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 years 4 months ago #49766

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

  • Posts: 224
  • Thank you received: 54
well, it's not an automatic import at all but if you want to give it a try it should work:
- reduce the number of points in your horizon mask to max 255 points (eg only even degrees ).
- 'Close' the polygon: add 0 values for the base of the polygon (see attached file after row 180)
- save the file as .csv
- close kstars
- use a sql lite editor (like 'DB Browser for SQL Lite') and open ./local/share/kstars/userdb.sqlite (do a backup first).
- Then in 'DB Browser for SQL lite' File->Import ->Table from csv file to import all the data in a table. Choose a table name like 'my_horizon'
- in the table 'horizons' add a record with these values: 1,my_horizon, My Horizon, 1
- reopen Kstars and select the horizon in Settings.

The area around the N Pole looks weird but I can be fixed.
Ferrante
2 years 4 months ago #49783
Attachments:

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

  • Posts: 527
  • Thank you received: 138
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.
-Andrew
––––––––––
Mac Observatory - All about using the Mac for Astrophotography: www.macobservatory.com
Astrobin: www.astrobin.com/users/Lead_Weight/
2 years 4 months 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

1 year 10 months ago #59291

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

  • Posts: 527
  • Thank you received: 138
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.
-Andrew
––––––––––
Mac Observatory - All about using the Mac for Astrophotography: www.macobservatory.com
Astrobin: www.astrobin.com/users/Lead_Weight/
1 year 10 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

1 year 10 months ago #59293
Attachments:

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

  • Posts: 297
  • Thank you received: 55
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
1 year 10 months ago #59294

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

  • Posts: 297
  • Thank you received: 55
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: 1 year 10 months ago by Scott Denning.
1 year 10 months ago #59300
Attachments:

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

  • Posts: 839
  • Thank you received: 108
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....
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
1 year 10 months ago #59315
Attachments:

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

  • Posts: 297
  • Thank you received: 55
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!

1 year 10 months ago #59322
Attachments:

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

Time to create page: 0.612 seconds