Друк

[Гість]

Ласкаво просимо, Гість. Будь ласка, увійдіть або зареєструйтеся.
22 Вересня 2024, 13:22:51

1 година 1 день 1 тиждень 1 місяць Назавжди

Увійти

[Новини]

•    Новини
•      Астрономія
•      Астрозаходи
•    Життя клуба
•      Новини
•      Проекти
•      Заходи
•      Звіти про спостереження
•      Документи
•    Статті
•      Обладнання та телескопи
•      Спостереження
•      Астрофотографія
•      Астрософт
•      Астрономія в Україні
•      Астрономи шуткують
•      Інше
•     
•      Файловий архів

Наш канал

Наші сайти

Астро-сайти

Програми

Наш канал

Наші сайти

Астро-сайти

Програми

[S.Fire]

Шикарно! Хостинг под такое дело считайте, что есть.

[stariy]

Только что попался яркий минусовой со вспышкой.

Красавец, однозначно.

Просто для ознакомления, как делают любители из Франции: http://www.boam.fr
Что касается базы данных, то думаю начинать нужно с постановки задачи. Завтра постораюсь запостить ER-диаграмму.

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

Что касается постановки задачи, то в общих чертах, мне кажется, она ясна (см. французов). Я бы это все дополнил только механизмом поиска на построенной карте радиантов.

[mnn72]

...Я бы это все дополнил только механизмом поиска на построенной карте радиантов.

Или другой выход (более простой). Кто владеет английским задать вопрос разработчикам почему UFOOrbit по данным анализатора считать ничего не хочет.

[astrotver]

начинать нужно с постановки задачи. Завтра постораюсь запостить ER-диаграмму.

Вот, для затравки. Сразу скажу, я не программист, не спец по БД, потому прошу снисходительности. Придвижу вопрос "а где принадлежность к потокам?". Ответ простой: не плоди entitys сверх необходимого. Установить принадлежность должен исследователь с помощью обработки запросов к БД. В БД только сырые данные.

[astrotver]

почему UFOOrbit по данным анализатора считать ничего не хочет.

Что именно не хочет? Trail map строит? А больше он ничего и не должен, если нет базисных наблюдений.

[stariy]

Вот, для затравки. Сразу скажу, я не программист, не спец по БД, потому прошу снисходительности. Придвижу вопрос "а где принадлежность к потокам?". Ответ простой: не плоди entitys сверх необходимого. Установить принадлежность должен исследователь с помощью обработки запросов к БД. В БД только сырые данные.

Вот видите, я впервые в жизни увидел ER-диаграмму, и ужаснулся... Особенно непонятно обилие стрелок (пунктирных и нет). Так, наверное, пишутся, по-настоящему серьезные вещи, но здесь - задача довольно проста: слив данных от каждого наблюдателя в общую базу  и возможность сделать выборку из этой базы данных по каким-то параметрам. И дальнейшая работа с этой выборкой. Единица информации - 1 метеор.
 О параметрах отдельный разговор. Абсолютно правильно то, что надо определиться в их наборе. Есть параметры приведенной французской базы, есть, в конце-концов, набор данных csv файла, который генерит УФО. Полагаю, что поскольку в основном все будут пользоваться УФО, то привязываться рациональнее именно к ней, хотя и можно добавить что-то свое, например инфу про наблюдателя.
Будет весьма отрадно, если Вы подключитесь к такой работе, и  мы создадим одну общую базу свободного пользования для метеорных видеонаблюдателей СНГ-вского пространства

[Jeff]

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

ps: ну, конечно, как у многих, времени свободного мало, но с первого взгляда задача простая - долго там делать нечего.

[astrotver]

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

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

Что касается нюансов. Метеоры наблюдают по крайней мере четырьмя методами - визуально, фото, видео и радио. И каждая методика даёт свой набор данных. Если уж делать БД, то такую, в которую можно внести любое наблюдение, и естественно их обработать. А иначе какой смысл? Чтобы как у всех - ты не из нашей песочницы, гуляй лесом. Одни только визуальные наблюдения берут, другие только из-под MetRec, третьи из-под UFO, а обработки практически ни у кого.

Хотя, может зря я распинаюсь? VMO за год изрядно продвинулась, может запустят скоро в эксплуатацию... Пошёл документацию читать.

[Jeff]

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

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

[stariy]

Если в таком формате как у французов, то могу исполнить. Не вижу там ничего сложного...

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

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

Не смею Вам перечить. Резонность замечания принимается. Но есть фактор времени и ресурса (что по сути одно и то же). Здесь, больше высказываю именно свое личное отношение к работе. Лучше ставить небольшую тактическую задачу для достижения определенной цели, чтобы потом, ее выполнив, поставить сл. задачу. И т.д. Хуже ставить большую всеобъемлющую задачу - со стратегическим замыслом. Велик риск не довести дело до конца и потратить усилия впустую. По разным причинам сорваться и забросить затею. Но повторюсь - это лично мое отношение.  Может кто-то работает по-другому. Короче - нужно попроще, ибо синица в руке...

Что касается нюансов. Метеоры наблюдают по крайней мере четырьмя методами - визуально, фото, видео и радио. И каждая методика даёт свой набор данных. Если уж делать БД, то такую, в которую можно внести любое наблюдение, и естественно их обработать. А иначе какой смысл? Чтобы как у всех - ты не из нашей песочницы, гуляй лесом. Одни только визуальные наблюдения берут, другие только из-под MetRec, третьи из-под UFO, а обработки практически ни у кого.

Здесь никак не могу согласиться. 4 метода вкратце следующие.
1 - визуально. Это совсем другие задачи, т.е. определение активности больших потоков. Нанесение визуально метеоров а карту - метод совсем изжил, ибо требует высокой квалификации и имеет низкую точность. Сейчас этим не занимаются. А задачи, кторые этим методом решались взяло на себя видео. Визуальная база имеется - ИМО.
2 - фото - с развитием видео этим тоже практически никто не занимается.
3 - видео - имеет место быть! Действительно привязка только к УФО порочна. Но УФО - это единственная программа, которая позволяет более-меннее адекватно работать в этом направлении. Наверное можно и нужно предусмотреть введение в базу результатов вручную, а не только с csv-файлов
4 - радио - здесь абсолютно все свое. Цели, доступные любителям те же, что и в п.1 - то есть активность крупных потоков. Радиолокация на любительском уровне недоступна.
Короче. Я вижу задачу только как создание базы видеоналюдений метеоров, проводимых c помощью УФО.

Хотя, может зря я распинаюсь? VMO за год изрядно продвинулась, может запустят скоро в эксплуатацию... Пошёл документацию читать.

Никак не зря. Спасибо, что принимаете активное участие в обсуждении.
Если не секрет, че такое VMO ?

[astrotver]

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

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

Если не секрет, че такое VMO ?

http://vmo.imo.net/ База давно в разработке, но последнее время пошло кое-какое шевеление. Почитал документацию и убедился, что даже у этих профессионалов нет чёткого представления как, а главное зачем они это делают. Что касается собственно базы, то худо-бедно её сделали. Вот с обработкой пока негусто. Хотя базисные наблюдения уже ищет, и даже орбиты на лету считает. Но вот незадача, он их в отдельную таблицу записывает, причём не временную. Так нажатием кнопки я увеличил объём этой таблицы на треть...

[mnn72]

почему UFOOrbit по данным анализатора считать ничего не хочет.

Что именно не хочет? Trail map строит? А больше он ничего и не должен, если нет базисных наблюдений.

Trial строит. Получается, что нужны наблюдения из нескольких точек чтобы строились радианты ? Тогда конечно нужна централизованная база. И с архивом файлов csv.

[Jeff]

Если в таком формате как у французов, то могу исполнить. Не вижу там ничего сложного...

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

Вроде в интернете полистал про наблюдения метеоров..
Что нужно для начала процесса:
1) определить формат данных для "заливки" в базу. Т.е. в каких форматах может сохранять UFO. Хочется выбрать максимально удобный/безошибочный для обработки.
2) Я ещё не понимаю о каких данных(количество и свойства) идёт речь, но во избежании ошибок, у меня будут вопросы по каждому из параметров. Задам отдельно после получения "выводного файла" UFO.
3) Делаем сначала простой ввод-вывод(а-ля французы), про "навороты" разговоры будут только после запуска самого простого интерфейса. Главное сделать математику.
4) Наверняка у меня будет масса глупых вопросов, думаю форум засорять не стоит и нужно определиться с методом связи(например гугл-рассылка со всеми участниками/бета-тестерами) и чтоб не было споров - определиться с ведущим специалистом(слово которого - закон).

Прочитал что написал - думаю нумерацию моих пунктов нужно "перевернуть"

[mnn72]

Нужна возможность импорта в базу файлы типа csv ("CSV (от англ. Comma-Separated Values — значения, разделённые запятыми) — текстовый формат, предназначенный для представления табличных данных. Каждая строка файла — это одна строка таблицы." цит.Вики). Эти файлы формируются анализатором. Одновременно должна быть возможность из этой же базы сформировать такой же файл для себя чтобы подгружать данные в UFOOrbit, которая строит радианты.

[Jeff]

Нужна возможность импорта в базу файлы типа csv

С csv - всё ясно и понятно. Парсить его проще простого. Но если вдруг в новой версии UFO появятся какие-то новые столбцы, то - "Шеф! Усё пропало!" и нужно будет ковырять парсер и вывод.
Просто если есть формат xml, то он более подходящий - каждый объект данных имеет описание и любые добавления/удаление/смешивание параметров не повлияет на работоспособность.

Вообщем приглашаю перейти в группу meteor-ua [ухо] googlegroups.com
Т.к. тему засорим мелочными вопросами разработки web-приложения:)

[stariy]

Вроде в интернете полистал про наблюдения метеоров..
...
Прочитал что написал - думаю нумерацию моих пунктов нужно "перевернуть"

Мы в исходной нумерации.
1. полностью согласен с mnn72 (см. предыдущий пост). Хотелось бы еще узнать мнение S.Fire. Пример импортированного csv файла  - ссылка в посте #227. Да и по ссылкам на ранних постах Вы найдете образцы csv -файлов для примера.
2. Что означает каждый столбец и какие важны, а какие не очень - отдельный вопрос. Пока, для "нулевого варианта" можно просто сделать кальку со всех столбцов. 
3. Конечно. Именно так. Решаем задачи поэтапно.
4. Глупые вопросы - это именно то, что нужно. Я вообще уверен, что "глупые вопросы" и есть настоящие вопросы. По поводу участников проекта. Насколько я вижу по ветке есть по крайней мере 2 человека, которые сейчас активно юзают УФО: mnn72 и S.Fire. Лично я собираюсь только подключиться: и на Лиридах буду дебютировать. Мнение этих участников форума предлагаю считать как имеющее максимальный авторитет. Что касается споров - мне кажется их не будет. Предлагаю общаться в открытую на этой ветке -  это привлечет к данным наблюдениям новых людей.
Вообще конечно этот проект с прицелом на будущее. Мы надеемся, что к нам подключатся еще ЛА и не только на Украине, но и в Беларуси, России, на всем русскоязычном пространстве. Да, кстати, все предлагаю делать по-русски, думаю возражений не будет.

[stariy]

То есть имеется конвертер  csv в xml. При изменении формата csv - новый конверт нового csv в тот же стандартный xml - я правильно понял? Если так удобнее вносить изменения - то конечно давайте так.
Jeff: По поводу места общения - возразите мне, я когда писал пост вашего последего сообщения не видел.

[mnn72]

Лично мое мнение:
1. Не нужно никаких конверторов. Достаточно импорта\экспорта. Не думаю что будут добавляться какие-нибудь новые столбцы. Т.к. программа отработана и юзается уже довольно давно. Хотя... как будет удобно и правильнее с точки зрения программиста. Главное это не только ввод в базу, но и вывод из нее в формате cvs.
2. Да русскоязычный ресурс нужен притом с инструкциями и рекомендациями. В том же ресурсе можно размещать данные наблюдений метеоров и в радиодиапазоне (для полноты картины). Просто многих ЛА останавливает именно англоязычность специализированных ресурсов.

[Jeff]

.. написал большой ответ и случайно нажал ctrl-w.. всё пропало:)
Теперь вкратце:

1) Гляньте в UFO может-ли он сохранять xml. Если не может - тогда забыли и будет csv. Вывод можно сделать в каких угодно форматах.

2) Файл мне нужен оригинальный csv или xml(не в гугл-док - он там уже конвертированный). Можно на мыло в гугл-группу или ссылку на файлообменник.

3) Нужно описание столбцов со свойствами. Часть мне ясна, но их там столько...
Например:
LocalTime:
Локальное время на компьютере
- Дата-время

Loc_Cam:
Название камеры точки наблюдения
- текстовое поле до 64 символов.

Dur(sec):
Длительность пролёта метеора
- значения от 0.001 до 99.999

и т.д.


Может где-то есть расшифровка столбцов в документах по UFO?

[stariy]

1. Ответить пока не могу - надо ответ тех, кто крутил хорошо программу.
2. По ссылке в посте #218 посмотрите японские результаты. Там можно спокойно скачать csv-файлы. Своих образцов пока нет.
3. Давайте я попробую это сделать, что не смогу или сделаю ошибку - поправляйте