Importing target data from Starry Night Pro


#1

I have just found that SGPro imports the first RA/DEC coordinate pair instead of the J2000 which is the second RA/DEC coordinate pair provided by Starry Night Pro. I am not sure why there is 2 pairs of coordinates provided by Starry Night but SGPro should choose the J2000 pair to avoid plate solving deception…

Simple software correction to SGPro should do the trick.


#2

I just ran into this same problem. Any update on how to correct?


#3

We’ll need a sample file to test against. If you can provide one I can check it out.

Thank you,
Jared


#4

Here it is.

New Observing List.txt (313 Bytes)


#5

Thanks John!

Will be addressed in the next 3.0 release.

image

Jared


#6

Many Thanks.


#7

Excellent! Thank you!


#8

It appears that now the import is only resolving down to the Hour/Minute and Degree/Minute; the seconds are not importing and this could cause an unacceptable deviation when centering an object. I imported 4 objects and the second values were all zeros in the target list when they were not zero in the imported TXT file.

Can we take another look at this?


#9

I just checked my imports and I am getting 1/10 second resolution in RA and 1.0 second in DEC. This may be limited by SkyX, but accurate enough from my work. Here is an example of the input:
RA: 0 02.8017 DEC: -24 56.7167
Make sure you have at least 4 decimal places in the input.


#10

Craig, what version are you on? This just started for me with 3.0.3.140 after the Starry Night import fix. Previous versions had the full values. I can’t specify any decimal position in the SN export; it is what it is.


#11

I am also on version 3.0.3.140. I don’t have Starry Night, so I had SkyX build me an Observing List, then I exported it to a text file. I imported the text file into Excel and reformatted the file to look like a Starry Night file. Fortunately, SkyX outputs the data to 4 decimal places which is used by SGP when importing. Maybe there is an option in the Starry Night export options to use more decimal places.


#12

I just realized that 3 decimal places is sufficient to express a position in seconds. Since the position is given in decimal minutes, 1/60 of a minute (1 second) is 0.017. So 3 decimal places will do it. My guess is something is trimming the seconds off the export. Can you show a couple of lines from your import file.


#13

Sorry this took so long, work got in the way of fun. You can see that the locations in the background images are being truncated in SGP import. 20 54’ 41" dec in the SN Observing List is being imported as 20 54’00.00" in the Target Settings.


#14

Can you display what the import file record looks like?

Craig


#15

The top 2 lines of the previous image.


#16

New Observing List
Name Kind Mag Size Alt Az Constellation Rise Transit Set Database RA Dec RA(J2000) Dec(J2000) Illumination Semi-Major Distance
NGC 2392 Planetary Nebula 9.90 1.4’ 30° 278.3° Gemini 8:43 PM 3:35 AM 10:28 AM Bright NGC Objects 7h 30m 16.4s 20° 52’ 15" 7h 29m 10.5s 20° 54’ 41"


#17

I am pretty sure the RA and DEC must be decimal minutes, that may be why it is truncating the seconds. Compare to this one from mine:

Name Kind Mag Size Alt Az Constellation Rise Transit Set Database RA DEC RA(J2000) DEC(J2000) Illumination Semi-major Distance
GCVS RU Scl # 9.35 # # # # # # # # 0 02.8017 -24 56.7167 0 02.8017 -24 56.7167 # # #

Notice the RA is 0 (hours) and 02.8017 for minutes. DEC is -24 (degrees) and 56.7167 for minutes.


#18

I found in Starry Night where I could change the “Number Format” and it works perfectly now.

Thanks, Craig!


www.mainsequencesoftware.com