A spreadsheet to compute the coordinates of the nebula image

[sunshuwei]

This is a spreadsheet to compute the coordinates of the nebula image.

It only requires four parameters: RA, Dec, Size, Orientation.

Coordinates of DSO Texture.zip

This is an example.

[alex-w]

Hmm. Could you write a paragraph for Stellarium User Guide with instructions how to use your spreadsheet for the users?

P.S. We may store your spreadsheets into stellarium-data repository (or as an attachment like DSO catalog) to provide a permanent URL.

@gzotti please comment it.

[gzotti]

We have just received a modern tool and docs on how to create the JSON lines for DSO textures. This will go into the next user guide.
If you can write a complete description on how to use the spreadsheet, we could add another such chapter. Please write it for absolute beginners! E.g. "Image RA hours" etc: Do we need to know the image center, where to get those data etc. How could we proceed when e.g. coordinates of 3 stars in the photo are known, but not the image center? There may be more than one path.

[axd1967]

I'd like to put a tangentially related remark here on config files in general.

In the long term, the Stellarium dev team should consider switching to a more flexible and user-friendly format such as YAML. The config file for the Oculars plugin is a good example of user unfriendliness: one has to specify counts and indexes, and cannot be easily merged or rearranged. Other modules would also benefit from this far more user-friendly format: see eg

stellarium/guide/app_ssystem_ini.tex

Lines 38 to 41 in 46c807d

	All elements are stored in alphabetic order in the files, however it
	makes more sense to present the elements in another structure which
	better reflects the meaning. The actual order of the objects in the files,
	and order of entries inside an object section, is irrelevant.

But I totally understand what a revolution this signifies for software as well as community. I am from the .ini/.xml format generation, it was only a few years ago that I started seeing the advantages of the YAML format, and by then I had already started working with JSON.

One reason to choose for YAML is that - as far as I know - most interaction is done through user-controlled config files; JSON is a format that is less flexible and more designed for machine interaction, and the .ini format has shown its limitations in the Oculars plugin.

rgds

-alex-

[gzotti]

We see some limitations in the .ini format, but were always able to somehow still use it. Moving all configs to JSON may appear to improve some things, for the price of total incompatibility between versions. YAML, yet another format, likely has some benefits, but again for the price of incompatibility.
Actually, most user interaction is through GUI buttons. What is behind the back should be no user's concern as long as it works. How it works in the background is ugly, indeed, but nobody is expected to edit the oculars.ini in a text editor!

Unfortunately, our spare time is limited, so we concentrate on things that we think are more urgent than exchanging one "just working" config file format for another "more elegant". But we always accept suggestions in form of working pull requests. And yes, we could use 1-5 more experienced C++/Qt developers, for some topics preferably with a strong astronomical background, to solve deprecation and maybe some efficiency issues.

[axd1967]

Another concept to keep in mind when offering config files to end users is the possibility to be able to share, version control and merge such files.
I am facing a huge merge hell because the oculars config files were never designed for this use case in mind. As a result, it's very hard to combine/merge ocular config files from different users (or git branches, for example). In fact, I am unable to confirm if my merges have not deleted or mangled information. The YAML format allows much smoother merge operations.

[alex-w]

Alex, sorry, but I see a huge number of problem, who will be introduced by switching to using yaml as config data and zero improvements. If you want to share some parts of ini or all ini file into XML/YAML/JSON/SQL/whatever format or from the XML/YAML/JSON/SQL/whatever format into ini, then just write a script on python/perl/bash/etc. for converting the data. Or define the specification of data files for sharing the oculars/lenses/telescopes/sensor data and write a tool for export/import those data and propose pull request to merge this tool. Is it a big problem? Why you publish you ideas for config data into report, who has nothing common with config data?

[gzotti]

Merging .ini files from several users is nowhere part of the regular, documented program use. Users are told that their config files are in their private user data folder, and are their own private data. The more adventurous user will dare to edit them, but it is like hacking the Windows registry: do it carefully. Do some stupid mistake, and your system becomes unusable.
I hope you understand "Someone Else's Problem". Hacking these .ini files sounds like a very rare use case, given that just editing the Oculars/telescope/etc. data is so simple with the provided GUI, and the format has not changed in the latest versions. If you feel Stellarium should be able to cater for your needs, please develop a working solution. Maybe it is indeed easier to write simple converters .ini->YAML, edit/merge/whatever the YAML, then convert back YAML->.ini.

[axd1967]

update: YAML (.yml) format is now appearing in Stellarium master (even if for build use only).

[alex-w]

No YAML for usage within Stellarium!