Мировая орбитальная группировка: сколько их?

[G.K.]

ОАЯ пишет:
Надо просто молиться на GK и потакать всем его запросам, что бы наконец началось заполнение таблиц БД.

Не надо на меня молиться, я не идол  . Коллеги, я не обещаю, что процесс будет быстрым, но я приложу все усилия, что бы всё получилось.

[G.K.]

peery пишет:
А это уже "доморощенная" СУБД.

Пири, давайте я скажу, как я себе представляю процесс: мы пишем ПО, которое взаимодействует с БД (например с аксессовским файлом или с онлайн-базой, не суть дела) и при помощи которой можно будет получать данные в удобной форме.

[G.K.]

peery пишет:
без изменения каталожного номера и международного обозначения могут легко и по-тихому "обменять" орбиты между физически разными объектами(особенно в запусках, где есть много объектов)

Это "классика" и такие моменты очень сильно бесят. 

peery пишет:
Если что - по этому вопросу предлагаю писать сообщения мне и G.K., чтобы не заваливать данную ветку чисто программистскими аспектами.

Пири, подумайте и напишите мне в ЛС как бы вам было бы удобнее обсуждать эти технические вопросы. 

peery пишет:
Уйти, я думаю, не получится, поскольку в этом случае придётся поступить как Джонатан МакДауэлл - написать свой обработчик системы текстовых файлов определённого формата и свою систему контроля целостности данных в этой системе. А это уже "доморощенная" СУБД.

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

[G.K.]

peery пишет:
пределиться со структурой данных и всеми правилами, описать всё это на SQL, потом выбрать СУБД (Postgres, на мой взгляд, был бы оптимальным), реализовать структуру там и прикрутить к ней веб-интерфейс. Поставить всё это хозяйство где-то на постоянно работающем сервере (найдём)

n-страниц назад я предлагал взять локальную СУБД, что бы не морочиться с сервером. Кмк эта база не будет находится в состоянии непрерывного обновление. Пуски происходят не каждый день, поэтому файл может спокойно обновляться, а конечные пользователи смогут ( механизм обновления стоит обсудить отдельно) периодически его забирать и тем самым обновляться. Можно, конечно, поднять и сервер, я не настаиваю. Но я никогда не работал с ними. То есть клиент, скорее всего, я написать смогу. А вот с созданием и подъёмом самой БД- это уже далеко не факт.

[G.K.]

peery пишет:
Прошу ещё раз обратить внимание на мою просьбу - посмотрите критически перечень предложенных атрибутов, которые предполагается хранить в базе, и скажите, чего не хватает, на ваш взгляд.

Ок, с утра посмотрю. Сейчас уже сил нет...

[G.K.]

peery пишет:
Пользователь будет просто отмечать то, что ему нужно, не заморачиваясь с SQL.

Именно так. Типа: выведите мне список всех объектов, образовавшихся при пуске с cospar обозначением 2014-001, отметив отдельно объекты, прекратившие баллистическое существование. Он и выведет все объекты, пометив красным все сошедшие.

[G.K.]

peery пишет:
Нормализацию структуры нужным образом мы проведём, уж поверьте - опыт в этом большой.

Это обнадёживает. 

[G.K.]

ОлегЗайцев пишет:
Предлагаю параллельно создавать на базе имеющейся в базе информации создать подобие информационно-справочного ресурса (подобного wikipedia)

Ну зачем нам нужна ещё одна википедия? Для пиара? Или для привлечение внимания к нашим скромным персонам? Старый и Пири и так хорошо известны, а я манией величия и желанием привлекать внимание к себе не страдаю.

[peery]

ОлегЗайцев пишет:
Предлагаю параллельно создавать на базе имеющейся в базе информации создать подобие информационно-справочного ресурса (подобного wikipedia), в котором можно будет хранить данные, которые плохо ложатся на предлагаемую peery реляционную структуру. Например если страница википедии имеет специальное форматирование из нее возможно извлекать информацию , подобно получению выборки из бд. Пример на странице http://dbpedia.org/page/USA-230 приведена структурированная информация по объекту.

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

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

[peery]

G.K. пишет:

peery пишет:
пределиться со структурой данных и всеми правилами, описать всё это на SQL, потом выбрать СУБД (Postgres, на мой взгляд, был бы оптимальным), реализовать структуру там и прикрутить к ней веб-интерфейс. Поставить всё это хозяйство где-то на постоянно работающем сервере (найдём)

n-страниц назад я предлагал взять локальную СУБД, что бы не морочиться с сервером. Кмк эта база не будет находится в состоянии непрерывного обновление. Пуски происходят не каждый день, поэтому файл может спокойно обновляться, а конечные пользователи смогут ( механизм обновления стоит обсудить отдельно) периодически его забирать и тем самым обновляться. Можно, конечно, поднять и сервер, я не настаиваю. Но я никогда не работал с ними. То есть клиент, скорее всего, я написать смогу. А вот с созданием и подъёмом самой БД- это уже далеко не факт.

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

То, что пуски - не каждый день, понятно. Но вот остальная информация может сыпаться постоянно, особенно если включить в модель планируемые пуски и КА, а также орбитальные данные.

[Старый]

peery пишет:
Уважаемые форумчане! Прошу ещё раз обратить внимание на мою просьбу - посмотрите критически перечень предложенных атрибутов, которые предполагается хранить в базе, и скажите, чего не хватает, на ваш взгляд. Также попытайтесь каждому атрибуту (ну кроме совершенно очевидных) дать определение. Эти определения будут положены в основу правил, по которым будет осуществляться заполнение базы, контроль целостности данных и отображение данных в пользовательском интерфейсе. Правила эти нужно программировать и поэтому если не будет согласованных определений, то не будет правил и не будет базы.

Давайте попробуем. Отвечать на сообщения где их целый список не удобно. Поднимайте по одному по порядку и попробуем обсудить. 

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

[Старый]

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

[G.K.]

Старый пишет:
Один номер сквозной как у норада, другой для идентификации и нумерации объектов конкретного запуска.

Очень хороший вопрос. 

Пири, может быть можно будет для объектов, которые должны были образовываться, но которые не видели американцы ( мало ли будут) свои "фантомные" псевдо-cospar номера в духе независимых наблюдателей? 

Знать бы ещё закономерность их создания самими наблюдателями...

[G.K.]

Старый пишет:
Поэтому для аварийных запусков видимо следует включать только заведомо известные "серъёзные" объекты - сами космические аппараты, ступени РН, переходники и т.п.

То же интересный вопрос. В принципе согласен.

[G.K.]

peery пишет:
Но вот остальная информация может сыпаться постоянно, особенно если включить в модель планируемые пуски и КА, а также орбитальные данные.

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

[peery]

Старый пишет:

peery пишет:
Уважаемые форумчане! Прошу ещё раз обратить внимание на мою просьбу - посмотрите критически перечень предложенных атрибутов, которые предполагается хранить в базе, и скажите, чего не хватает, на ваш взгляд. Также попытайтесь каждому атрибуту (ну кроме совершенно очевидных) дать определение. Эти определения будут положены в основу правил, по которым будет осуществляться заполнение базы, контроль целостности данных и отображение данных в пользовательском интерфейсе. Правила эти нужно программировать и поэтому если не будет согласованных определений, то не будет правил и не будет базы.

Давайте попробуем. Отвечать на сообщения где их целый список не удобно. Поднимайте по одному по порядку и попробуем обсудить.

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

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

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

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

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

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

Какой тип данных должен использоваться для формирования номера - число и текстовая строка, зависит от того, где предполагается его использовать. Например, если считать, что он будет не будет использоваться при формировании каких-либо данных в соответствии с какими-то внешними по отношению к данной базе стандартами, то можно выбрать любой вариант. Если же подразумевается, что в какой-то момент может захотеться, например, сформировать TLE (или какие-то иные данные в соответствии с каким-либо стандартом) с таким номером, то расклад будет совсем другой.

[peery]

Старый пишет:
По идентификации объектов потеряных в аварийных запусках. Очень сложно узнать сколько операционных фрагментов могло бы образоваться в данном запуске. Даже если это серийный запуск и известно сколько фрагментов было в аналогичных запусках то всё равно в данном конкретном запуске могли быть отличия. А уж если запуск уникальный то вообще неизвестно.
 Поэтому для аварийных запусков видимо следует включать только заведомо известные "серъёзные" объекты - сами космические аппараты, ступени РН, переходники и т.п.

Я поддерживаю идею, чтобы для аварийных не орбитальных запусков (т.е. когда ни один объект до орбиты не добрался) в перечне "индивидуальных" объектов хранить только записи о КА и, возможно, орбитальных ступенях, например, РБ, для которых даже номера зачастую известны (но тут будут явные проблемы в некоторых случаях, когда циклограмма не известна и не понятно, а должна ли была конкретная верхняя ступень выйти на орбиту)

[peery]

G.K. пишет:

Старый пишет:
Один номер сквозной как у норада, другой для идентификации и нумерации объектов конкретного запуска.

Очень хороший вопрос.

Пири, может быть можно будет для объектов, которые должны были образовываться, но которые не видели американцы ( мало ли будут) свои "фантомные" псевдо-cospar номера в духе независимых наблюдателей?

Знать бы ещё закономерность их создания самими наблюдателями...

Идентификаторы, использующие в качестве основы cospar'овскую систему международных обозначений объектов, вполне могут быть и не "фантомные" для случаев, когда точно известно, что какой-то из объектов точно образовался в данном запуске, но не был каталогизирован американцами. Просто ведём свой собственный учёт и всё, а с американскими номерами по неким правилам устанавливаем соответствие (это всё-равно придётся делать, поскольку на американские номера, как уже обсуждалось, полагаться ни в коей мере нельзя). В контексте данного обсуждения мне вот интересно, что американцы будут делать со Спрайт'ами в количестве 104 штуки, когда (и если) они будут таки "выпущены на свободу" на орбите. Маловероятно, что хоть один из них будет каталогизирован официально в силу малости размеров. С другой стороны, раз уж мы хотим вести учёт всего, что достоверно образовалось на орбите, то вне зависимости от поведения Страткома мы должны будем такие "мусоросаты" записать в качестве индивидуальных объектов в базу, образовать "составной" орбитальный объект KickSat-1 и потом, если эта вся хрень начнёт самостоятельный полёт, образовать ещё 104 записи в списке орбитальных объектов с присвоением каждому объекту обозначения, образованного по cospar'овской системе. 

Для объектов, источник образования которых не известен, действительно можно использовать правило образования международного обозначения, используемое любителями:
ГГNППnnn
где ГГ - год обнаружения объекта
NПП - номер "псевдо-пуска", к которому относится объект (формируется как, например, 200+ДДД, где ДДД - номер дня в году, соответствующий моменту, по UTC, первого наблюдения объекта)
nnn - номер объекта в "псевдо-пуске" (можно зарезервировать разное количество позиций - 1,2,3)

[peery]

G.K. пишет:

peery пишет:
Но вот остальная информация может сыпаться постоянно, особенно если включить в модель планируемые пуски и КА, а также орбитальные данные.

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

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

[peery]

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