galaxymap.info: онлайн-карта Галактики

[Андрей Астрофизический]

galaxymap.info - интернет-ресурс, представляющий собой трехмерную карту нашей галактики. Для этого не требуется ставить на свой ПК какой-либо софт, нужно всего-лишь ввести адрес в браузер.
Сайт использует современные технологии WebGL, база данных постоянно пополняется информацией из различных открытых источников, которую собирают автоматические боты.
Что можно найти на этом сайте?
Приоритетное внимание уделяется звездным системам, в которых найдены экзопланеты, и собственно экзопланетам. Так же некоторый приоритет занесения в базу данных имеют двойные и кратные звездные системы. В то же время, избегается занесение в базу данных объектов, для которых неточно, с существенной погрешностью определена дистанция (параллакс). В базу данных НЕ заносятся никакие объекты, расположенные за пределами нашей галактики. Временно крайне низкое внимание уделено солнечной системе (будет исправлено позднее).
По каждой звезде или планете, информация предоставляется с опциональным (по желанию) указанием погрешностей и источника информации. В случае противоречий будут показаны разные варианты информации из разных источников. Ресурс стремится к максимально возможной достоверности данных, все что возможно вычислить о какой-либо планете или звезде - вычисляется, и показывается пользователю в тех величинах которые удобны ему. Категорически избегается размещение вымышленной информации, наподобие, к примеру, континентов на экзопланетах, которыми любят грешить различные "симуляторы".
Так же есть поиск по названию или координатам, планируются различные API (не сразу), онлайн-калькуляторы различных астрономических величин.
Пока число объектов, которые содержатся в базе данных, существенно ограничено объемом используемого хостинга. В обозримом будущем проект будет расти и развиваться.

[xd]

http://www.vendian.org/mncharity/dir3/starcolor/
просто оставлю это здесь

[Андрей Астрофизический]

Почему большой шаг градации отображаемых цветов звёзд (на картинках всего лишь 2 цвета)

Потому что это пока сырой вариант, и количество цветов я ограничил намеренно т.к. полностью функция перевода спектрального класса в видимый внешний вид еще не готова. У меня есть планы варьировать внешний вид не только в зависимости от спектра или светимости, но и других физических параметров, например переменные, углеродные звезды, и т.д. и т.п.
Различать множеством оттенков спектральные подклассы не считаю нужным, все равно G0 от G2 отличить "на глаз" будет невозможно. Лучше закладывать в внешний вид ту информацию которая может быть воспринята. А для подробных характеристик все равно придется нажимать на звезду и читать.

зачем такая усложнённая форма отображение звёзд

В каком-то смысле это тест, "потянет или нет". И во-первых, почему бы нет, если так можно сделать. Как выяснилось, эта картинка вычислительных ресурсов просит немного. И при любых встречающихся в реальности поблизости от нас, плотностях звезд, это остается немного. Во вторых как я уже говорил, есть планы сделать звезды более разными, чем для земного наблюдателя невооруженным глазом. Понятно, что "естественной" был бы внешний вид светящейся точки. Но он же и самый не-информативный.

[xd]

Браузер, <canvas> ?

[Андрей Астрофизический]

WebGL, полноценное 3D использующее видеокарту. Да, в браузере. Широких тестов пока не делал, но в разумных пределах оно кроссбраузерно. Понятно что всякие древние IE за бортом.

[дерево]

Во вторых как я уже говорил, есть планы сделать звезды более разными, чем для земного наблюдателя невооруженным глазом.

На мой взгляд, как пользователя, наоборот лучше, чтобы они были более одинаковыми по яркости. В частности чтобы яркость пикселей падала не квадратично с расстоянием, а линейно (с точки зрения ПО это только проще), чтобы относительная звёздная величина "0" и "10" отличались не в 10 000 раз, а лишь в 100. И при этом площадь пятна была пропорционально корню в большой степени из абсолютной светимости. Тогда на мониторе смогут отображаться все ближайшие (от выбранной точки наблюдения) звёзды, включая красных карликов.
Сейчас же глазом в радиусе 5 парсек видно лишь 1/7 часть звёзд.

В целом проект интересный, и кажется очень затратным (по времени и ресурсам) для одного исполнителя. Хочу пожелать его успешного исполнения и дальнейшего развития.

[Андрей Астрофизический]

В частности чтобы яркость пикселей падала не квадратично с расстоянием, а линейно (с точки зрения ПО это только проще), чтобы относительная звёздная величина "0" и "10" отличались не в 10 000 раз, а лишь в 100. И при этом площадь пятна была пропорционально корню в большой степени из абсолютной светимости. Тогда на мониторе смогут отображаться все ближайшие (от выбранной точки наблюдения) звёзды, включая красных карликов.

В данный момент размер отображения звезды пропорционален корню 8-й степени из светимости.
На то, какие звезды вообще видны а какие нет, влияют пороги отсечения по светимости в зависимости от выбранного масштаба. Их еще тоже конечно надо будет настроить.

На мой взгляд, как пользователя, наоборот лучше, чтобы они были более одинаковыми по яркости.

По яркости они и будут более одинаковыми. Различаться будут другими особенностями. Сейчас например все видимые на карте звезды четырехлучевые. А можно например сделать белые карлики шестилучевыми, цефеиды с двусторонним горизонтальным лучом, (двухлучевые), а углеродные звезды или звезды Вольфа-Райе выделить особенным цветом. Тут много вариантов может быть, пробовать надо, какие сочетания будут информативными, не режущими глаз и при этом не тяжелыми для железа.

[Ulmo]

А что вы будете делать с разбросом в определении дальности до звезды?

[Андрей Астрофизический]

Показывать звезду в среднем значении от всех погрешностей...
При обработке звезд, в 3-д картинку попадают звезды у которых расстояние определено с достаточно приемлемой погрешностью. Звезды для которых погрешности выше допустимого (30%) возможно, и показываться на 3д-карте не будут. Вообще вопрос дискуссионный, что с ними делать. Сейчас родилась идея - дать юзеру настройку допустимой погрешности отображения, все что не вписываются в установленный порог - не показывать. Но это не сразу и не скоро будет реализовано.
Я только добавлю... если параллакс звезды измерен с такой погрешностью, что значение параллакса минус погрешность - допускает отрицательные величины. То для таких звезд считается что расстояние надежно не определено. Известен лишь нижний предел, но не верхний. В таком случае ее вообще в 3д нельзя где-либо разместить.
Однако, в сочетании с анализом спектра и определением ветви на диаграмме Г-Р, можно определить и верхние пороги дистанций. Маловероятно что это даст приемлемые погрешности ниже 30%, но как знать, где-то может быть и повезет.

[Ulmo]

Ну, вообще не показывать это на мой взгляд плохая идея. Может рисовать вместо точки линию, от минимальной дистанции до максимальной?

[xd]

Я только добавлю... если параллакс звезды измерен с такой погрешностью, что значение параллакса минус погрешность - допускает отрицательные величины. То для таких звезд считается что расстояние надежно не определено. Известен лишь нижний предел, но не верхний. В таком случае ее вообще в 3д нельзя где-либо разместить.

А можно пример?
Погрешность в две стороны может быть (и чаще всего так и бывает) разная.

[Андрей Астрофизический]

Погрешность в две стороны может быть (и чаще всего так и бывает) разная.

Разумеется. Я уже несколько раз об этом написал...

http://www.astro.spbu.ru/sites/default/files/Tsvetkov,%20Hipparcos.pdf страница 34, (68), поле Н11 и его описание. Перечитывать до просветления.

И, дабы (я надеюсь) уменьшить число вопросов, расскажу немножко об архитектуре базы данных.
1) Базовым объектом считается не звезда, а "Система". Система имеет ряд основных параметров, выраженных целочисленными величинами для оптимизации поиска. Это округленные до целых координаты, звездная величина, числовое выражение спектрального класса. В обзоре межзвездного пространства показываются именно системы.
Кроме того, система может иметь любое количество включенных в нее объектов - звезд и планет. Хотя даже если речь идет об одиночной звезде без подтвержденных планет, она расценивается как "звездная система" содержащая единственный объект - звезду.
2) Таким образом, дочерние по отношению к системе, объекты, это звезды и планеты.
3) У каждого объекта может быть любое количество параметров. Параметр выглядит вот так:

(кликните для показа/скрытия)

Код: [Выделить]

--
-- Структура таблицы `parameters`
--

CREATE TABLE IF NOT EXISTS `metrics` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `owner_table` int(11) NOT NULL,
  `owner_id` bigint(20) unsigned NOT NULL,
  `name` int(11) NOT NULL,
  `val` double NOT NULL,
  `err_minus` double DEFAULT NULL,
  `err_plus` double DEFAULT NULL,
  `dimension` int(11) NOT NULL,
  `origin` int(11) NOT NULL,
  `create_data` bigint(20) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2677496 ;

Полагаю, названия параметров "параметра" - достаточно говорящие и пояснять ничего не надо?
У одной звезды может быть несколько разных "параметров" параллакса, данные из разных каталогов например. В таком случае выбирается наилучший из них. Лучший - это тот у кого меньше погрешность как в плюс, так и в минус. Когда параметр вычисляется на основе другого, то в origin (источник) это записывается соответственно. Очень удобная гибкая система, позволяющая одновременно какие угодно вычисления на основе чего угодно, и в то же время четкий контроль надежности данных, и отслеживание первоисточника(ов), откуда все взялось.

Может рисовать вместо точки линию, от минимальной дистанции до максимальной?

С одной стороны, это идея хорошая. Но не всем такое будет удобно. Делать опционально - хз... не хотелось бы городить море разновсяческих "настроек отображения" в которых черт ногу сломит.

[SpaceEngineer]

SpaceEngine не видели? Не сочтите за самопиар, просто по теме вроде

SpaceEngine это компьютерный планетарий, но, в отличие от почти всех планетариев, наблюдатель не прибит гвоздями к Земле. Можно летать куда хочешь, и всё в 3D. Используются реальные каталоги - HIPPARCOS, NGC/IC, экзопланеты, Солнечная система. Добавлять новые данные можно в виде csv файлов. За пределами каталогов все объекты генерируются процедурно (алгоритмически), но правдоподобно. Генерируется всё - галактики, туманности, звёзды, планеты, и даже рельеф на планетах (на планетах Солнечной системы - реальные данные).

Летать можно как в играх, WASD + мышь, колёсиком меняется скорость (экспоненциально, от скорости улитки до 100 мегапарсек в секунду). Но есть и режим управления попроще - клик по объекту выбирает его (пир этом слева вверху пишется разнообразная информация об объекте, часть этих данных рассчитывается на ходу), потом можно нажать G для автоматического перелёта к нему, правой кнопкой можно покрутить как глобус, сесть на поверхность и т.п.

Типичный "геймплей". Видео можете посмотреть в ютубе, по запросу "Space Engine" вывалит сотню.

люди, неужели никто в Mass Effect не играл? Помните какая там была карта галактики? вот я просто делаю такую же.

Карта галактики тоже есть, и не только галактики, всей Вселенной. Это как гугл мапс, только трёхмерный. Масштаб можно менять от планеты/астероида до миллиарда световых лет. Зум колёсиком мыши, дабл-клик по объекту центрирует карту на него.

Наши окрестности:


Все звёзды HIPPARCOS:


Кроме карты, есть "чарт" - показ планет выбранной системы в рядок, сортировка по размеру/массе и т.п:


Более подробную информацию о каждом объекте можно просмотреть в специальном окне. Не вся информация задаётся каталогами, часть рассчитывается, а часть генерируется процедурно (например, свойства атмосферы у экзопланет). Возможно, надо как-то помечать, какого типа та или иная информация.


В общем, программа полностью интерактивная, правда компьютер нужен помощнее, игрового класса. И вывод графики, и генерация рельефа на планетах осуществляется видеокартой, поэтому она гораздо более важна, чем процессор (на стареньком 4-ядерном Xeon 2009 года выпуска работает так же, как на 12-ядерном i7, при условии что видеокарта хорошая - GTX 760 и выше).

Возможно, проект станет доступен сначала в виде API, и лишь затем обзаведется визуальным клиентом.

Вот. Таким клиентом может выступать SE. Сейчас я каталоги (базы) объектов обновляю вручную перед каждым релизом (в основном - экзопланеты, т.к. хайповая тема). Если вам удастся сделать свою базу и API к ней, можно было бы как-то организовать взаимодействие. К слову, нечто подобное разрабатывается консорциумом Data2Dome для планетариев (которые физические, с куполом и цифровым проектором). Эти планетарии используют некий софт для вывода картинки на купол - Digistar, Digital Sky, StarryNight, Uniview. В будущем я планирую выйти на рынок планетариев (т.е. сделать SE ещё одним таким софтом), так что мне надо будет внедрять поддержку Data2Dome. Возможно, вам тоже стоит не изобретать велосипед, а разобраться, как использовать их протоколы/API? Или даже стать разработчиком. Я сам пока не разбирался, что там у них есть и в каком формате.

Созрел еще один вопрос, нужен алгоритм для пересчета сферических координат звезд для определенной эпохи. Конечно тут тоже все не просто, но хотя бы что-то найти бы.
Поясню для чего это нужно: для правильной интерпретации не-самых-новых каталогов, в которых данные приведены для эпохи 1950 или еще чего-то в таком духе. Чтобы найти совпадения для тех звезд в каталогах более свежих, надо пересчитать координаты.

Элементарно. Преобразуете в декартовы координаты, потом умножаете на матрицу поворота от системы данной эпохе к нужной (J2000 или какую вы хотите использовать). Матрицу поворота несложно посчитать - углы поворота небесной сферы известны, главное с осями системы координат не напутать (с нескольких попыток можно подобрать). Потом можно преобразовать обратно в сферические, или оставить как есть. Мне, как программисту 3D графики, такой подход гораздо ближе и понятнее, чем возня с тригонометрией.

Т.е. например, TESS вернулся с очередного витка->передал на землю новые данные->сотрудники проекта TESS эти данные обработали, внесли в свою базу данных новые экзопланеты->На карте проекта (ЭТОГО), новые экзопланеты появились автоматически. Сразу. Без каких-либо дополнительных телодвижений.

Это одна из самых желанных фич пользователей SE - регулярные обновления каталога экзопланет. Т.к. релизы у меня редко, раз в год-два, пользователи подолгу сидят с устаревшими каталогами, а новички прибегают на форум жаловаться, что SE не показывает "вчера открытую" экзопланету.
Но боюсь "без телодвижений" сделать это не получится. Сам столкнулся с этим, когда импортировал базу экзопланет. Данные беру с NASA exoplanet archive и с exoplanets.eu в виде csv файлов. Так вот, в обоих базах полно опечаток! Вы запаритесь писать парсер. Я пишу на C++, и мне проще было некторые опечатки вручную исправить в csv файле, чем учитывать их в парсере. Например, незакрытая кавычка, левые символы в спектральном классе (GOV вместо G0V и т.д.), разнобой в формате имени (то GJ xxxx, то gliese xxxx, то Gl xxxx), пропущенные или лишние пробелы, и т.п.
Самая жесть - несовпадение названий. В одном каталоге звезда обозначена, например, как HD xxx, в другом только номер KOI. Пришлось делать кросс-идентификацию по координатам, о чем вы писали. Только по RA и Dec, по параллаксу - ни в коем случае! Его точность обычно очень плохая, или же он вообще не указан. С планетами всё ещё хуже. Для них тоже надо делать идентификацию при несовпадении названий (напр., Kepler-xxx b и KOI XXX.02, внезапно). Можно по орбитальному периоду, можно по большой полуоси, смотря что есть.
В общем, я не вижу способа автоматически всё это делать. Может, потому что пишу на C++, а там всё надо делать ручками? Мой парсер полуавтоматический, всякие нестыковки приходится разрешать вручную, ища информацию на симбаде, вики и в статьях. Для облегчения работы себе, парсер сохраняет обработанную базу данных, а импортирует только новые планеты  из насовской базы и с exoplanets.eu (там есть поле с датой последнего изменения - очень удобно).
Есть ещё проблема с планетами в двойных системах. Каталог двойных звёзд в SE - это отдельная тема, он составлен вручную для нескольких сотен систем (в SE тоже базовый объект - система, в неё могут входить звёзды и планеты, для каждого такого объекта надо описывать элементы орбиты). Планеты у двойных звёзд я переношу в отдельную базу, описывая их вручную, а в базе парсера помечаю, что не нужно их парсить в будущем (только уведомить об изменениях, чтобы потом проверить вручную).
Без всех этих танцев с бубном в SE встречались дикие вещи типа красного карлика размером с орбиту Юпитера, планеты внутри звезды, две пересекающиеся планеты на почти одной орбите и т.д. И до сих пор встречаются, каталог HIPPARCOS, использованный в SE, содержит кучу неверно классифицированных звёзд.

Кстати, вы в курсе, что в настоящее время работает новый астрометрический спутник GAIA? Недавно был выпущен первый релиз базы данных, содержащий свыше 1 миллиарда звёзд. Боюсь, если вы хотите загрузить их все в свою базу, вам придётся собрать мини-кластер. Я сам пока ещё не приступал к её импорту в SE, но предварительное исследование показало, что юзабельных звёзд там около 300 миллионов (у большей части остальных пока нет параллакса, у других очень большая погрешность, у многих не указаны зв. величины). У меня проблема в том, что SE опирается на спектральный класс звезды, а эти данные есть только у пары миллионов звёзд. Для остальных известны только фотографическая величина и параллакс. Надо переделать звёздный каталог в SE так, чтобы он опирался на эти известные параметры, а остальные рассчитывал. В SE уже есть т.н. звёздный солвер - это как раз то, что вы ищете. Если у звезды не указаны какие-то параметры, он пытается вычислить их (напр., светимость по визуальной величине и расстоянию, радиус по светимости и температуре, и прочее). В т.ч. есть попытка классифицировать звезду, по известной температуре и светимости поместить её на диаграмму Г-Р и определить, к какой последовательности она относится.

Кросс-идентификация например. Вводим к примеру Кеплер номер такой-то, (планета), а API выдает названия материнской звезды в других каталогах. Или наоборот, вводим идентификатор звезды из каталога, в котором кроме звезд ничего и нету. А API сообщает, кроме идентификации этой звезды в других ресурсах, еще например что возле этой звезды вот такая-то планета крутится.

Так вроде Simbad умеет это делать.

M0+IIIa - такого зверя как расшифровывать? что там делает знак "+" между различных частей, казалось бы должных относиться к одной звезде. Таки это одна звезда или две?
Это если что, не единичный случай, таких удивительно солидное число...

Это звезда класса светимости 0+, гипергигант. Бывают ещё 0-, и далее по списку I+, I, I-, II+, II, II- и т.д. Мне тоже пришлось бороться с переменными классами и всякими доп. буквами типа p, e и т.п. SE пока это всё не поддерживает, поэтому парсер просто берёт то, что понимает. Подозреваю, что стоит всё-таки сохранять все данные, на будущее.

[Андрей Астрофизический]

Благодарю за ответ. Проект интересный, действительно по теме но все же, различия есть.
Среди показываемых характеристик по звездам/планетам. Бросается в глаза:
1) Отсутствие информации о погрешности, как будто это понятие программе неведомо. В то же время, она очень меняет смысл написанного в диапазоне от "достоверных точных данных" до "надписей вилами по воде".
2) Отсутствие информации об источнике информации. Откуда взялось каждое конкретное число. Это должно быть указано обязательно.
Ну и, красивая графика требующая игровой комп, и вообще привязка к компу пользователя, вместо веб-сервиса - для меня это все жирный минус. А так, конечно проект интереснейший, наиболее близкий по теме.

Вот. Таким клиентом может выступать SE.

Вполне возможно. Мой проект скорее всего в конечной форме будет предусматривать API для вывода информации по любой интересующей системе, звезде, планете. Просто потому что клиентская сторона веб-ресурса должна получать информацию через ajax, а серверной стороне, в принципе безразлично кому выдавать информацию из базы данных.

Сейчас я каталоги (базы) объектов обновляю вручную перед каждым релизом (в основном - экзопланеты, т.к. хайповая тема). Если вам удастся сделать свою базу и API к ней, можно было бы как-то организовать взаимодействие.

Вероятно, да Подумаем над этим несколько позднее.

надо будет внедрять поддержку Data2Dome. Возможно, вам тоже стоит не изобретать велосипед, а разобраться, как использовать их протоколы/API?

Учитывая что у меня все же не планетарий, а в первую очередь именно концентратор по возможности точных цифровых данных, я полагаю у нас с ними будет намного меньше точек пересечения, чем кажется на первый взгляд.

Данные беру с NASA exoplanet archive и с exoplanets.eu в виде csv файлов. Так вот, в обоих базах полно опечаток! Вы запаритесь писать парсер

Знаю, видел. Спотыкался. Начать с того что у них выдаваемый ими JSON не собирается синтаксически как JSON. 
Вообще, это единственная причина, по которой парсер и сама база данных пока не готовы. Однако, пишу. И совершенно уверен в том что парсер будет, в том числе способный переваривать их опечатки и выдавать корректный результат.

разнобой в формате имени (то GJ xxxx, то gliese xxxx, то Gl xxxx)

Такое уже исправно проглатывает и переваривает.

Самая жесть - несовпадение названий. В одном каталоге звезда обозначена, например, как HD xxx, в другом только номер KOI. Пришлось делать кросс-идентификацию по координатам, о чем вы писали. Только по RA и Dec, по параллаксу - ни в коем случае! Его точность обычно очень плохая, или же он вообще не указан.

В общем, я не вижу способа автоматически всё это делать.

Опять же, к сказанному выше. Есть данные или их отсутствие. А есть достоверность этих данных, выражаемая через погрешность. Использовать параллакс (и другие параметры) для распознавания звезд можно и нужно, в тех случаях когда он указан с достаточно малой погрешностью. И конечно на него не стоит смотреть, если его погрешность приводит к погрешностям определения расстояния в десятки и более процентов. Все это урегулируется алгоритмически.
А вот по одним только RA & Dec, идентифицировать звезды категорически НЕ СТОИТ. Между двух наблюдаемых с Земли звезд, угловое расстояние может быть совершенно ничтожно, но при этом линейное расстояние больше, чем расстояние от ближайшего из них до Солнечной системы. В общем, кросс-идентификация звезд это комплексный процесс, в котором надо учитывать максимально возможное число параметров, доступных с достаточной точностью. И обязательно в алгоритме оценивать точность каждого параметра - можно ли им пользоваться.

Каталог двойных звёзд в SE - это отдельная тема, он составлен вручную для нескольких сотен систем (в SE тоже базовый объект - система, в неё могут входить звёзды и планеты, для каждого такого объекта надо описывать элементы орбиты). Планеты у двойных звёзд я переношу в отдельную базу, описывая их вручную, а в базе парсера помечаю, что не нужно их парсить в будущем (только уведомить об изменениях, чтобы потом проверить вручную).

Кошмар  Сколько же это возни "вручную" при совершенно мизерном результате. В каталоге двойных звезд приложенном к Hipparcos, 24 c половиной тысячи звезд. Их же надо обработать)
Кстати, именно алгоритм построения систем, удобоваримых для дальнейшей 3д-визуализации с корректными параметрами, сейчас в процессе разработки.

Без всех этих танцев с бубном в SE встречались дикие вещи типа красного карлика размером с орбиту Юпитера, планеты внутри звезды, две пересекающиеся планеты на почти одной орбите и т.д.

Все подобные вещи можно, как минимум, обнаружить с помощью алгоритма. А по результатам обнаружения уже можно писать и алгоритм их излечения.

каталог HIPPARCOS, использованный в SE, содержит кучу неверно классифицированных звёзд.

Сомнительное утверждение насчет прям "кучи". Но насчет некоторых параметров да. Так опять же надо смотреть на погрешность параметров, и выбирать более точные данные из более точных источников. Совсем не все параметры можно в наилучшем виде вытянуть из Hipparcos, что-то лучше читать из других мест. А уже внутри базы, при каких-либо вычислениях алгоритм автоматически выберет наилучшее (самое точное) значение из доступных.

вы в курсе, что в настоящее время работает новый астрометрический спутник GAIA?

Да, в курсе.

Недавно был выпущен первый релиз базы данных, содержащий свыше 1 миллиарда звёзд.

Я видел 
Загружать их все - пока что, и не надо. Там для очень многих достаточно мало что указано. Полагаю, несколько позже составлю селективный алгоритм который будет из этой базы выбирать только те объекты, по которым известно достаточно ключевых параметров.

Если у звезды не указаны какие-то параметры, он пытается вычислить их (напр., светимость по визуальной величине и расстоянию, радиус по светимости и температуре, и прочее). В т.ч. есть попытка классифицировать звезду, по известной температуре и светимости поместить её на диаграмму Г-Р и определить, к какой последовательности она относится.

Опять же, чтобы подобные манипуляции имели какой-то смысл и не превращались в гадание на кофейной гуще, критически важно при каждом вычислении, каждой мат.операции учитывать погрешность всех исходных данных. И оценивать достоверность результата. А то от радиуса звезды, вычисленного с погрешностью в 500%, толку не много.
Про кросс-идентификацию Симбада - он как раз идентифицирует только по Ra & Dec, ну еще по названию. Это недостаточно точно, и выше я уже говорил почему в целом неприемлемо.
Симбад уже выдавал мне как "предположительно одну и ту же" две звездные системы с достоверными значениями параллакса, различающимися в 3 раза. При погрешности менее 5%. Так что нет, это не надежно) Надежно - оценивать надежность при каждом шаге.

Это звезда класса светимости 0+, гипергигант

Благодарю Я уже эту информацию нашел и встроил в алгоритм, уже все работает.

Мне тоже пришлось бороться с переменными классами и всякими доп. буквами типа p, e и т.п. SE пока это всё не поддерживает, поэтому парсер просто берёт то, что понимает.

Мой уже практически все понимает и перерабатывает) с практически всеми доп. буквами и префиксами всех встречающихся разновидностей.
Среди прочего, генерирует человекочитаемый текст с описанием спектральной информации - на основе всех этих буквенных обвесов.

[Андрей Астрофизический]

Визуализация тоже уже не за горами. За красотами SE я конечно не гонюсь, и мне незачем генерировать внешний вид атмосферы на планете, где неизвестен сам факт наличия атмосферы.
Но кое-что мои алгоритмы умеют. Это пока не реальная звездная система, а тестовая, сгенерированная на основе произвольно взятых значений параметров.
Непопадание звезд на свою положенную орбиту будет фикситься) работы еще много...

[SpaceEngineer]

1) Отсутствие информации о погрешности, как будто это понятие программе неведомо. В то же время, она очень меняет смысл написанного в диапазоне от "достоверных точных данных" до "надписей вилами по воде".

Да, это надо прикрутить, но в урезанном виде. Самому движку это не нужно, огромный объем лишней информации. Да и пользователю в 99% случае тоже. Но если будет онлайн сервис, можно информацию брать из него по запросу пользователя. Если он захочет узнать погрешности или источник информации, откроет wiki окно, и туда подгрузятся все нужные данные, и ссылки на статьи например.
Но придётся перепарсить все каталоги.

Учитывая что у меня все же не планетарий, а в первую очередь именно концентратор по возможности точных цифровых данных, я полагаю у нас с ними будет намного меньше точек пересечения, чем кажется на первый взгляд.

Я имею в виду, что у них, возможно, уже есть готовая база звёзд с кросс-идентификацией. Или же, наоборот, у них её нет, а вы сможете в будущем предложить. $$$

Использовать параллакс (и другие параметры) для распознавания звезд можно и нужно, в тех случаях когда он указан с достаточно малой погрешностью. И конечно на него не стоит смотреть, если его погрешность приводит к погрешностям определения расстояния в десятки и более процентов.

SE всё же делает исключение для звёзд-хостов экзопланет: если нет параллакса и невозможно вычислить расстояние, он берёт и генерирует рандомное значение (точнее, процедурное, чтобы у всех пользователей получалось одинаково). Иначе многие экзопланеты просто отсутствовали бы в SE, например, почти все микролинзовые.

А вот по одним только RA & Dec, идентифицировать звезды категорически НЕ СТОИТ.

У меня задача была проще, т.к. нужно было идентифицировать только хосты экозпланет. 10 угловых секунд хватило для надежного слияния всех случаев разного наименования, кроме одного неверного слияния - компонентов двойной HD 133131, которая разрешается на две звезды ближе 10 секунд, у каждой из которых есть свои планеты. Её я просто поместил в список исключений. Вам, кстати, такие подставы тоже стоит учесть.

Кошмар   Сколько же это возни "вручную" при совершенно мизерном результате. В каталоге двойных звезд приложенном к Hipparcos, 24 c половиной тысячи звезд. Их же надо обработать)

Это делал не я, чел с ником Cirax с форума SE. А я потом находил и исправлял ошибки Значительная часть звёздного солвера появилась в результате работы с ним, в том числе для отлова ошибок.

Кстати, именно алгоритм построения систем, удобоваримых для дальнейшей 3д-визуализации с корректными параметрами, сейчас в процессе разработки.

Есть такой Sixth Catalog of Orbits of Visual Binary Stars, я планирую его распарсить и сгенерировать файл каталога для SE. Тут тоже встал вопрос о кросс-идентификации и слиянии с уже имеющимися в SE звёздами. Я пока не придумал удобный формат базы данных, подходящий, с одной стороны, для удобного представления звёзд, их орбит и иерархии в кратной системе, и, с другой стороны, хранение в сжатом бинарном виде в форме узлов октодерева для быстрой загрузки с диска и использования в 3D движке. Он основан на октодереве, что позволяет, кстати, иметь бесконечное расстояние прорисовки при конечном числе видимых одновременно звёзд. Вам для веб-сервиса тоже надо разработать что-то подобное, для быстрого стримига миллиарда звёзд. Если хотите, подробно опишу устройство октодерева.

Опять же, чтобы подобные манипуляции имели какой-то смысл и не превращались в гадание на кофейной гуще, критически важно при каждом вычислении, каждой мат.операции учитывать погрешность всех исходных данных. И оценивать достоверность результата. А то от радиуса звезды, вычисленного с погрешностью в 500%, толку не много.

В таком случае надо применять или расчёт из других параметров, или процедурную генерацию. Нарисовать же пользователю что-то надо, а чтобы нарисовать, надо знать минимальный набор параметров - координаты, радиус, светимость, и, возможно, цвет. Для двойных звёзд тоже придётся генерировать, для подавляющего числа двойных известен только факт двойственности, и период, иногда эксцентриситет. Что-то можно рассчитать (например, если известен тип звёзд, можно взять массу из таблички, по ней и периоду вычислить большую полуось орбиты). Но остальное придётся сгенерировать, как ни крути, например, наклонение почти никогда не известно (в смысле его знак, на нас или от нас). Либо же отображать звёздную систему в виде условной диаграммы, как в "чарте" SE. Но для SE это не вариант.

Мой уже практически все понимает и перерабатывает) с практически всеми доп. буквами и префиксами всех встречающихся разновидностей.
Среди прочего, генерирует человекочитаемый текст с описанием спектральной информации - на основе всех этих буквенных обвесов.

А можно пример? В SE csv каталог выглядит вот так:

Код: [Выделить]

Name,RA,Dec,Dist,AppMagn,SpecClass,MassSol,RadSol,Temperature
HIP 14066/HD 18665,3.02094205,36.1179219,487.804884,7.24999999,K2V,,,
HIP 14775/HD 278329,3.17876994,36.5130485,505.050497,10.1093756,K0V,,,
HIP 12888,2.76132567,32.8238759,476.190497,9.64843834,K0V,,,
HIP 14822/HD 19686,3.18955144,35.0858171,436.681229,8.26953186,G5V,,,

Кроме него, есть еще специальный "скриптовый" формат, где параметры описываются так:

Код: [Выделить]

Star "11 Oph"
{
RA      16.37367053
Dec     -24.087208
Dist    125
AppMagn 13.804
Class  "M9"
MassSol 0.02
RadSol  0.12
Teff    2375
Age     0.011
}

Star "11 UMi/HD 136726/HIP 74793"
{
RA      15.28496907
Dec     71.823898
Dist    119.47
AppMagn 5.016
Class  "K4III"
MassSol 1.8
RadSol  24.08
Teff    4340
FeH     0.04
Age     1.56
}

Т.е. всё человеко-читаемо, csv используется для массовых каталогов, таких как HIPPARCOS и NGC/IC (но в нем задается фиксированный набор параметров), а скриптовый для отдельных сравнительно редких случаев, где есть дополнительные параметры, отсутствующие в csv. Скриптовые каталоги также используются для патчинга некоторых звёзд в csv (исправление ошибок, апдейт, перевод системы в тип "барицентр двойной" с одновременным заданием другого скрипта для компаньонов). После загрузки и быстрого парсинга каталогов, движок строит octree для рендера. Для каталога GAIA это не прокатит, миллиард звёзд на видеокарту сразу не загрузишь, да и не надо это. Каталог должен быть в некоем бинарном формате, уже сразу разбитом на отдельные файлы по узлам октодерева. Тогда движок будет стримить с диска только те узлы, которые нужны в данный момент рендереру. Кроме данных для рендерера, нужен какой-то индекс для работы встроенного интерфейса поиска, реально быстрый и компактный (миллиард записей надо ведь держать в памяти). И в довершение ко всему, каталог должен иметь возможность быстрого апдейта. Чтобы при изменении/добавлении пары звёзд не нужно было репарсить весь миллиард записей, переразбивать октодерево и пересохранять бинарники.

[Андрей Астрофизический]

у них, возможно, уже есть готовая база звёзд с кросс-идентификацией. Или же, наоборот, у них её нет, а вы сможете в будущем предложить. $$$

Кросс-идентификацию в любом случае полезно свою написать. Чтобы потом иметь возможность оценивать достоверность любой сторонней, сравнивать данные из разных источников.
Предложить - посмотрим) сначала надо сделать.

если нет параллакса и невозможно вычислить расстояние, он берёт и генерирует рандомное значение (точнее, процедурное, чтобы у всех пользователей получалось одинаково)

Но так же нельзя делать! Если у вас компьютерная игра, то можно конечно. И зеленых человечков на планете пририсовать, для пущего эффекта.
В моем ресурсе, данные будут только достоверные, или вычисленные на основе достоверных, с приемлемой точностью. Если приемлемое вычисление невозможно, то тут уж честно написать в соответствующей графе "Нет данных" - самое верное решение.
А из доступности в базе данных отсутствие даже параллакса, планетную систему не уберет. Т.к. для того чтобы посмотреть какую-то систему, не обязательно к ней "лететь" в симуляторе, достаточно ввести ее название в поиске.

двойной HD 133131, которая разрешается на две звезды ближе 10 секунд, у каждой из которых есть свои планеты. Её я просто поместил в список исключений. Вам, кстати, такие подставы тоже стоит учесть.

Такие "подставы" мой алгоритм уже успешно обрабатывает. Хоть я пока и не уверен в том что результат не дырявый. скоро проверю.

Я пока не придумал удобный формат базы данных, подходящий, с одной стороны, для удобного представления звёзд, их орбит и иерархии в кратной системе, и, с другой стороны, хранение в сжатом бинарном виде в форме узлов октодерева для быстрой загрузки с диска и использования в 3D движке.

Ввиду того что у меня это веб-интерфейс, требования к скорости загрузки куда мягче. А база данных MySQL с соответствующей серверной обвязкой завершает решение проблемы.

Вам для веб-сервиса тоже надо разработать что-то подобное, для быстрого стримига миллиарда звёзд.

Уже готово и работает при любом желаемом ограничении отображения звезд, и любом масштабе. MySQL достаточно хорошо умеет решать такие задачи.

В таком случае надо применять или расчёт из других параметров, или процедурную генерацию. Нарисовать же пользователю что-то надо, а чтобы нарисовать, надо знать минимальный набор параметров - координаты, радиус, светимость, и, возможно, цвет. Для двойных звёзд тоже придётся генерировать, для подавляющего числа двойных известен только факт двойственности

Это ваше мнение Мое мнение, если данных нет, и достоверно вычислить их невозможно, то честно сообщить что данных нет. И все.

А можно пример?

Скину API разбора спектрального класса в личку.

[дерево]

SpaceEngine это компьютерный планетарий, но, в отличие от почти всех планетариев, наблюдатель не прибит гвоздями к Земле.

Почти всех — это каких? В наиболее известных Stellarium и Celestia тоже не прибит.

[SpaceEngineer]

Почти всех — это каких? В наиболее известных Stellarium и Celestia тоже не прибит.

Я потому и написал "почти". В стеллариуме, к слову, прибит, правда можно планету поменять.

[Андрей Астрофизический]

GAIA? Недавно был выпущен первый релиз базы данных, содержащий свыше 1 миллиарда звёзд. Боюсь, если вы хотите загрузить их все в свою базу, вам придётся собрать мини-кластер.

В свете последних событий... я думаю что результаты Gaia я к себе буду загружать в обязательном порядке, иначе это не дело.

предварительное исследование показало, что юзабельных звёзд там около 300 миллионов

Вполне доступный объем, кстати говоря. Я думаю, мини-кластер под это дело не потребуется. Исходя из того, сколько мегабайт сейчас у меня занимает база данных - прирост объема на три порядка, вполне выполним. И к каким-то фатальностям привести не должен.
Hipparcos, таким образом, послужит в основном тому чтобы отработать технологию. Наладить работу базы данных, научить ботов автоматом подгружать указанные каталоги и интегрировать в бд с существующими звездами. Это собственно сейчас и делается.

[Андрей Астрофизический]

Созрел еще вопрос Не научный/технический, а скорее на тему общепринятых правил чтоли...
Короче: допустим у нас двойная звезда. Две звезды вращаются вокруг общего центра масс, и если по массе они примерно равны, то можно сказать что они вращаются вдвоем по одной орбите, находясь в противоположных ее точках в любой момент.
И другой пример. Тоже двойная звезда, но, массы компонентов различаются очень сильно. Одна из звезд кружит по орбите вокруг второй... хотя понятно конечно, что крутятся они все так же вокруг общего центра масс. Будь там хоть перышко на орбите у звезды, летают оба, вокруг общего центра... но расположен он совсем не посередине.
И собственно вопрос, как лучше поступить с двойными звездами. В смысле отображения. изображать меньшую на орбите вокруг большей? Изображать их вдвоем в противоположных точках одной общей орбиты? переключаться между вариантами в зависимости от соотношения масс?
Реализовать любой вариант можно, интересует, как оно принято в приличных кругах.