Есть идея написать программу...

[iNV]

Уже не первый год записываю все свои наблюдения в базу MSAccess. Не очень то это удобно - громоздко, медленно, бейсик там временами подглючивает не по-детски. В тоже время, ни одна из готовых программ такого рода меня не устраивает англоязычностью и способом организации записей в базе данных.
И вот возникла идея написать программу для записи результатов наблюдений. Прежде всего, по дипскаям.  Идеология уже выработана и отточена годами. База должна содержать как минимум две таблицы:
1. Сессия (сеанс) наблюдений, для которого указывается время, место, погода, засветка, инструмент, заметки
2. Объект наблюдения: имя, тип, зв. вел, пов. ярк, размеры, фаза (для планет) высота над горизонтом, номер сессии (сеанса), заметки, картинки. Все остальные данные об объекте можно подгрузить из какого-нибудь каталога дипскаев, например из каталога SAC 7.2.
И вот я с вопросом - а кому-нибудь кроме меня это нужно?

[Ernest]

Нужно наверное многим... Вопрос только в том, насколько сильно.

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

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

Я думаю, что в случае воплощения проблем с хостингом не будет - проект приютит любой из отечественных астро-порталов (astronomy, starlab, astronomer).

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

[iNV]

К таблице сессий и объектов наблюдений добавятся следующие таблицы: инструментов, наблюдателей, мест наблюдения, графических материалов (рисунки-фотографии) и, наконец, актов наблюдений (со ссылками на сессию, объект, инструмент, наблюдателя, графику)

Согласен, просто об этом я умолчал...

Я предлагаю создать программу записи результатов наблюдений, хранящую данные в своем формате, дабы не быть завязаным на "сторонних производителей". Возможность переноса данных может быть организована либо при помощи документированного формата базы, либо с помощью экспора в CSV.
Обмен данными между наблюдателями через интернет - это уже другая сторона проекта. Сайт просто необходим,  это мы уже обсуждали. Программа, о которой я говорю должна иметь возможность пересылки записей в такую интернет базу, что должно быть значительно удобнее заполнения форм по каждому объекту. Предлагаю обсудить эту тему...

P.s. Я уже как-то интересовался у местных обитателей, кто и как ведет журнал наблюдений. Никто не ответил. Неужели все так плохо...

[Виктор Степанов]

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

Много нужно обсудить прежде чем приступать к реализации. Если есть желание, предлагаю встретиться на следующем собрании МАК (12/11) и пообщаться на эту тему.

В.

[iNV]

Если есть желание, предлагаю встретиться на следующем собрании МАК (12/11) и пообщаться на эту тему.

Далековато будет... Уж лучше Вы к нам  ...

[Doof]

Идея очень хорошая. В настоящее время приходится пользоваться англоязычными вариантами типа http://www.visualdeepsky.org/netastrocatalog/objectlist.html.
Но там все это сделано на скору руку, с примитивным поиском и вообще, довольно слабенько.

[moron]

Полностью поддерживаю идею!

Несмотря на то, что я *начинающий* ЛА, почувствовал необходимость систематизации наблюдений.

Готов предложить посильную помощь:
программирование java, JSP, servlets, SQL.

Некоторые мысли по теме:

1. предлагаю XML для документирования, экспорта-импорта базы.

2. предлагаю наличие не только записей, доступных всем, но и "приватных". Скажем, в случае незаконченных или неотредактированных комментариев.

3. предлагаю в качестве DBMS - PostgeSQL. Гибко, просто и быстро.

4. ... использовать публичный CVS сервер для работы над проектом. (SourceForge.net, cvsdude.org ?)

[Виктор Степанов]

Далековато будет... Уж лучше Вы к нам  ...

Обсудить можно и здесь.

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

Надеюсь, Андрей Остапенко, который когда-то один из первых озвучил подобную идею на собрании МАК, подключится к дискуссии.

[moron]

Предлагаю для начала обсудить концепцию.

Приятные особенности интернет-журнала наблюдений очевидны:

 о  Доступ из любой точки мира (при наличии Интернета);
 о  Доступ к базе данных наблюдений, проводимых другими ЛА;
 о  Возможность сравнения результатов наблюдений;
 о  Поиск по ключевым словам;
 о  Возможность добавления комметнариев, уточнений, мнении, etc. к наблюдениям ЛА;
 о  Возможность коллективных обсуждений формализованных данных конкретных наблюдений;
 о  Оповещения о запланированных наблюдениях по e-mail, etc.

Недостатки:

 о  Отсутствие интернета под рукой в полевых условиях (иногда длительное).


...

Т.о. я вижу для себя необходимость в offline-клиенте. Скорее всего, достаточно простом. Без излишеств. С интерфейсом, примерно, соответствующим WEB-интерфейсу. C наличием кнопки "синхронизация с web".
В сочетании со Sky Charts (http://www.stargazing.net/astropc/) и/или StarCalc (http://www.relex.ru/~zalex) будет незаменимым помошником в документировании наблюдений.


Скажу сразу: я могу посвятить себя только online-проекту. К программированию под "окна" или X - я не готов. Давно это было...
Настоятельно рекомендую XML для представления данных. Готов заняться разработкой OLML (Observation Log Markup Language), но нужны опытные ЛА для понимания нужд.

Вопрос: Почему XML?
Ответ: Единая форма хранения (представления) данных, доступная для понимания даже в исходном виде. Строгий контроль целостности (до определенной степени). Хранить локальные дневники можно непосредственно в XML - это почти текст. ("Война и Мир" Толстого, примерно, 2.5 Мб ).


С уважением.

[DimoNNN]

2 moron: концепцию одобряю. Но не сложновато ли будет? Хотя бы на этапы нужно разбить.
Да и кто-то должен за этим хозяйством следить, когда заработает, а это тоже не просто.

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

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

Какую помощь предложить не знаю. Уже давненько не писал ничего. Может если только на Delphi что-нибудь нужно… Хотя с XML не общался никогда.

[елVIс]

Идея хороша :-)
Но есть нюанс. В полевых условиях доступ к интернету бывает крайне редко (у меня и моих друзей, во всяком случае). В то же время КПК есть практически у всех.
Но на них не развернешь офф-лайновский комплекс, базирующийся на SQL и использующий XML. Вообразите, сколько все это будет весить. Особенно какой объем будет занимать база. И особенно, если глянуть чуть-чуть дальше и хранить в ней не только данные о съемке объекта, но и саму фотографию этого объекта. :-)
И все это лишь для того, чтобы, скажем, уточниться с экспозицией Лунного затмения.
Идея красивая, но я считаю, надо проект разделить на 2 части: сделать платформно-независимую программуську с единым форматом базы данных для личного использования и обмена данными между ЛА (особенно начинающими ЛА, пока еще не имеющими практики и опытными ЛА) И веб-сайт с выкладыванием фоток и экспозиций/условий съемки.

[moron]

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

Я согласен, что база для КПК должна соответствовать ресурсам. Как я уже говорил ранее, offline-клиент должен быть максимально простым. Персональный журнал наблюдений можно хранить в текстовом виде, то есть в XML. Offline-клиент может как использовать библиотеки синтаксического анализа XML, так и напрямую работать с текстовым файлом на свой страх и риск. SQL здесь не причем - это уже дело сервера.

Для внесения же графических файлов в журнал можно просто использовать заранее предусмотренную клиентом директорию и ссылку на этот файл в журнале.
Например (фрагмент XML-записи):

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

<img name="M110" url="file:///C:/var/client/data/DS0023.jpeg">
Произвольный комментарий...
</img>

Позже я выложу полный пример записей в персональном журнале для обсуждений/дополнений/корректировки.

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

[Ernest]

Поддерживаю идею XML портирования данных с клиента на сервер и назад.
Предлагаю опираться при программировании как на клиенте, так и на сервере на Java/swing. Реляционная база на сервере необходима, и с ней проблем не будет, а на клиенте - вероятно стоит подумать об аскетической конфигурации.

Думаю будет правильно еще недельку (скажем, до 17-го) максимально интенсивно пообмениваться идеями (все предложения приветствуются, и по функциональности, и по реализации на клиенте/сервере). А затем подумать, взять недельный (до 24-го) таймаут и предложить таки черновые концепции проекта. Затем в течение недели пообсуждать, остановиться на лучшей и приступить (в начале Декабря) к организации команды.

Лады?

[moron]

Java-клиент - это, конечно, хорошо, мульти-платформенно и быстро программируемо. Но, в настоящий момент, это будет не слишком функционально. Пользователю приятнее будет иметь быструю программку, которая не требует большого времени реакции на его действия.
Я все же расчитываю на людей, которые займутся разработкой клиента на c/cpp. Для хорошего, up-to-date, программиста это не займет много времени. Я верю - здесь есть такие.

Мои конекретные предложения:

сервер:

  о  DBMS: PostgreSQL
  о  Java SDK SE
  о  Tomcat 4.x
  о  JSP/Servlets

клиент:

  о  Хранение данных о собственных наблюдениях в чистом XML
  о  Разработка на С/C++



p.s. draft структуры данных в процессе разработки...

[moron]

Как прошло собрание МАК?
Обсуждали вопрос?

[Виктор Степанов]

Как прошло собрание МАК?
Обсуждали вопрос?

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

[moron]

Не люблю изобретать велосипед. Тем более, если концепция уже есть. Это - BLOG. Кто не знает, что это такое - поищите в поисковых системах - я не нашел (с первой попытки) достойного описания технологии. (Пример - blog.ru)
Наткнулся на проект, именуемый blojsom. Попробую рассмотреть его, как основу для "Astronomical Observation Logging System" (Система Регистрации Астрономических Наблюдений). Если гибкость библиотеки оправдает себя - попытаюсь реализовать прототип web-интерфейса.


p.s. рекомендую посмотреть программку AstroByte Logging System (win).

[Максим Гераськин]

Хранить локальные дневники можно непосредственно в XML - это почти текст. ("Война и Мир" Толстого, примерно, 2.5 Мб ).

Ну. Типа

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

<?xml version='1.0' encoding="windows1251" ?>
<book name="Война и Мир" author="Лев Толстой">
<![CDATA[
Текст объемом 2.5 Mb
]]>
</book>


Разработка на С/C++

Э-э. А библиотека какая?
MFC не предлагать

Но вообще лучше на Delphi

[Самодуров Владимир]

Идея хорошая, даже отличная. Но в хороших идеях самое главное - что? Чтобы все можно было апгрейдить как можно легче и проще. Сегодня кому-то важны только фото, завтра - описания добавить, послезавтра - описания инструментов, потом, ой - координаты наблюдателя тож необходимы....
В общем, система должна нести в себе возможности гибкого и безболезненного расширения, это главное, остальное - вторично.
Второе.
Все распадается, насколько я понял, на две части - серверную начинку, и легкий клиент на стороне. Но - никто ведь не говорил, что они должны быть написаны на одном языке. Например, почему бы сервер не делать из связки  Postgresql (лучше все равно нет, и в ближайшее время не будет из  free-sql баз) и Perl или Php, как языка? Какой-такой особый выигрыш C даст на сервере, если вы не собираетесь пользоваться алгоритмами обработки и создания изображений (а не простого считывания) on-line? Вроде как никакого...
О клиенте. Если о аппаратной переносимости говорите, так тогда либо глючная Ява, либо Дельфи ( Kulix под Linux же есть...).
И последнее. Надо, наверное, ориентироваться на наиболее широко распростаненные кадры для написания сего продукта. Поскольку люди будут работать за-бесплатно и в большой муравьиной куче, то... Так, дельфистов вроде как больше, чем си-шников, Php-ков больше, чем Perl-истов. Правда, и mysql -щиков больше в природе, чем Postgresql-щиков, но тут явно mysql все же не потянет... Кстати, еще - в таком проекте вопрос технической документации - ключевой...

[Ernest]

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