Сделаем наш ресурс по дип-скаям!

[iNV]

Мои соображения:

t_object.interesting - нужно обязательно.

t_search_map - имеет смысл помещать сюда ссылку на файл для какого-нибудь планетария, например всеми любимый SkyChart...

t_observ_place.Quality - Предлагаю использовать шкалу наподобие этой:
http://skyandtelescope.com/resources/darksky/article_81_1.asp

[Ernest]

Степени засветки неба из указанной статьи

1 - Зодиакальный пояс хорошо виден через все небо, облака Млечного Пути в Стрельце отбрасывают заметную тень от предметов, невооруженный глаз видит звезды 7.6-8m и  туманность в Треугольнике

2 - Желтоватый Зодиакальный свет отличается по цвету от Млечного Пути, который виден с большим количеством деталей, невооруженный глаз видит звезды 7.1-7.5m и многие из шаровиков входящих в каталог Месье. Окружающие предметы и облака видны как черные дыры при проектировании на небо.

3 - Чуть заметен более светлый пояс засветки по горизонту. Зодиакальный Свет бесцветен и хорошо виден только весной и осенью. Невооруженный глаз видит М33 только боковым зрением, еще заметны самые яркие шаровики (М4, М22), звезды 6.5-7.0m уже можно видеть самые светлые из окружающих предметов.

4 - Хорошо видна неоднородность световой засветки по горизонту. Облака имеют заметные светлые детали, хотя вцелом черные. Млечный Путь не богат деталями. Для невооруженного глаза М33 - почти не заметна, звезды до 6.1-6.5m. Окружающие предметы видны.

5 - Млечный Путь ближе к горизонту теряется и хорошо просматривается только над головой. Зодиакальный Свет - практически не виден даже в удобные для его наблюдения осенние/весенние ночи. Облака заметно светлее чистого неба. Звезды до 5.6-6.0m

6 - Млечный Путь едва заметен в околозенитной области. Свечение неба серо-зеленым от горизонта до высоты 30-35 градусов. Но М31 еще можно найти невооруженным глазом, так-же как и звезды до 5.5m.

7 - Небо в заметной серовато-беловатой дымке, засветка со всех сторон. М31 уже весьма трудно увидеть невооруженным глазом, но звезды видны до 5.0m.

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

9 - Некоторые неяркие созвездия не видны. Только Плеяды видны невооруженным глазом. Предел - 4.0m

Крымское небо в Понизовке по этой шкале можно оценить примерно как 2.5, в нашей любимой Шумбе под Питером при хорошей погоде - 4.

[Doof]

Хорошая шкала!

На даче у меня получается где-то 4.5
В Бутово на балконе  - 6

[елVIс]

Давайте потихоньку определяться с клиентской частью. Во-первых, как я понимаю, большинство из нас ведет свою базу данных наблюдений, которую надо перегнать на будущий сервер. Это задача #1 - разовая. Несмотря на зоопарк программных средств ведения баз данных (кто-то писал сам или использовал готовые), подавляющее большинство поддерживает сохранение базы в текстовом виде с разделителем полей. Я думаю, этим свойством и следует воспользоваться. Далее -  клиентская часть "штатного" занесения информации. Она обязательно должна работать в режиме off-line, по окончании набивки создавать архив, отправлять на сервер и там уже сервером распаковываться и всасываться.
Ее следует писать на языке  TCL/TK или Perl-GTK дабы обеспечить одинаковую работу на всех платформах. Могу взяться за клиентов.

[shandrik]

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

Леонид.

[Ernest]

Ее следует писать на языке  TCL/TK или Perl-GTK дабы обеспечить одинаковую работу на всех платформах. Могу взяться за клиентов.

На мой взгляд для клиентов предпочтительнее Java/Swing против MySQL и транспорт на основе XML (наиболее распространенные кроссплатформенные средства программирования высокого уровня, масса народу сможет поучаствовать в дописывании), но если вместе с платформой предлагаются услуги по программированию - можно и прикрыть глаза на ее недостатки.

[елVIс]

> На мой взгляд для клиентов предпочтительнее Java/Swing против MySQL и транспорт на основе XML

Согласен, Java тоже хороший выбор для написания интерфейса. Ориентироваться тогда надо на версию <1.3
MySQL и XML -  это хорошо, но не совсем  :-) Не лишайте  юзеров наладонников возможности делиться впечатлениями оперативно на астрофесте.  Я думаю, "базаданновский" движок вообще не нужен на клиентском месте... Хотя нет, ведь если выработаем единую стандартную софтинку,  с помощью ее можно будет любому вести локальную базу данных для собственных нужд, и при необходимости сливать на сервер. Но тогда надо подумать хорошенько над протоколом синхронизации. Какие будут предложения/идеи?

[shandrik]

t_Eyepieces   - это что? справочник по окулярам или список всех окуляров в наличности и наблюдателей? Если справочник окуляров (то есть 5 мм Meade 4000 серии будет присутствовать как одна запись), то нужна еще одна таблица связывающая владельца с окуляром - там можно разместить отзыв, да и при выборе окуляра с которым шло наблюдение не будет вываливаться комбо-бокс на несколько сотен позиций. Добавить поле описания (ну типа есть резиновый наглазник, исполнение для гидирования с сеткой и т.п.), а так-же, раз пошла такая пьянка, поля с размером посадки, весом, габаритами.

Я предполагал эту таблицу именно как справочник окуляров - на каждый по одной записи. Отзывы владельцев не планировались и я не вижу в них особого смысла. Мы же решили ограничиться описание Дип-Скаев, а не инструментами. Иначе мы очень быстро придем к начальному виду базы, так напугавшей участников дискуссии. Или мы хотим объять необъятное? Ну зачем наличие наглазника, вес и габариты. Раздумья об их учете отдалают нас от главной темы. Насчет сотен позиций в списке - это легко устранимо: у клиента добавляем эту таблицу булевым полем (Есть/Нету). При первом старте юзер активирует нужные чек-боксы (соответствующие имеющимся у него окулярам), далее при протоколировании наблюдения в попуп-меню будут только помеченные окуляры. Также можно поступить и с телескопами. Купил новый окуляр - пошел в настройки и поставил галочку. И не следует привязывать окуляры и телескопы к владельцам - на совместных наблюдениях все смотрят во все подряд, и если я увидел очаги звездообразования в М33 в 250мм Ричи-Критьен Антона Савельева, то это не значит, что я не имею права отметить это в журнале.
Вы же сами, Эрнест, сказали, что мы не инструментами меримся, а делимся впечатениями от Дипов, и я с этим категорически согласен.

t_Eyepieces.id_eyepieces   integer   - рекомендую заменить ключи string и забивать чем-то более менее понятным типа 5meade4000 (5 мм Meade 4000 серии) - это не сильно скажется на задержке запросов, но облегчит работу с дампами данных и ручной работой по коррекции базы etc.

t_telescopes.id_telescope   integer   - заменить на string см. выше
t_telescopes.id_type_telescope   integer   - заменить на string см. выше

Текстовый тип ключевого поля?   Не позволю!
Для ручной работы воспользуемся конструкцией t_observ key join t_eyepieces
Ввиду малости окулярного справочника, сервер это не шибко напряжет.
     

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

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

t_observer - может быть добавить ICQ

Аська у нас запрещена, потому я о ней все время забываю. Ради Бога.

t_observer.id_observer   заменить на строку (nick, может совпадать со Звездочетовским), см. выше

Против - см. выше

t_observer.Sex   boolean   - можно выбросить, во всяком случае должен принимать три значения - не указан/муж/жен

Согласен со вторым.

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

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

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

Фотографии-то зачем? Я, например, лишь спустя два месяца увидел как выглядит мое наблюдательное место при дневном свете. Зачем это мне и тем более остальным?

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

m_name,   ngcic_name, another_name - думаю лучше заменить на пару полей - имя каталога (NGC, M, IC, PK...) и ID (13, 1223, 8953, 12-3-5) - оба текстовые, можно дополнить еще и парой ссылок на альтернативный каталог (почти все из Месье входят в NGC)

Не согласен - я до сих пор не знаю соответствия объектов Мессье каталогу NGC. Настаиваю на трех полях (Мессье, NGC/IC(надо придумать как разделять NGC и IC, альтернативные - менее известные каталоги(строковое поле)).

t_object.Size1, Size2 - хранить в минутах или даже секундах

Согласен на секунды.

t_object.photo - выбросить в отдельную таблицу внешних ссылок t_object_external_link: три обязательных поля - ссылка на объект, гиперссылка, тип ссылки (поисковая карта, фотография, рисунок, описание...) и опционально - описание

     
Все таки настаиваю на одной фотографии и множественности зарисовок - проект визуальный.

t_search_map -  можно отбросить, если будет t_object_external_link

t_observ_session - нет поля длительности наблюдений, тектового описания и ссылки на основной инструмент

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

t_observ_session.JD_observ - не удобна при ручной работе и расшифровке дампамов базы данных, думаю стоит заменить на календарную дату начала наблюдений

Согласен на указание даты и времени начала наблюдений.
 

   
t_observ.id_observ integer - просто порядковый номер наблюдения в сессии (часть составного ключа)

К какой таблице вязаться этим составным ключом?

t_observ.observ_object_descript_lyric - скорее уместно в таблице наблюдательных сессий

Может быть и туда следует добавить, но в t_observ тоже следует оставить.

[shandrik]

Степени засветки неба из указанной статьи

Все-таки неудобная таблица. Лучше 5 по этой шкале неба я не видел. Зато видел множество оттенков интервала 7-9. Очень грубая шкала. Сколько наблюдений у нас на форуме было с оценкой <4? Одно-два? Нужна более точная шкала для 7-9, а все что <4 взять за один идеальный.

Саша, а где у тебя дача? Сколько до города (Москва?)

[shandrik]

Подведем промежуточные итоги:

Почти со всеми таблицами разобрались.

Осталось три вопроса:
1. Следует ли указывать тип телескопа? Как быть с многочисленными у нас уникальными Добсонами? Может стоит вообще убрать t_telescopes, а вместо t_observ.id_telescope ввести D и F и все? На клиентской стороне можно иметь справочник имеющихся телескопов, например для портировантя в Звездочет, но в Базу будут браться только два этих параметра?

2. Нужна ли t_observ_place?

3. Как быть с t_search_map? Надо бы обсудить ВСЕ детали поисковых карт, и я могу делать их штук по 20-30  за дежурство. Наверное, заведу завтра тему об этом в Наблюдениях.

[iNV]

Фотографии-то зачем? Я, например, лишь спустя два месяца увидел как выглядит мое наблюдательное место при дневном свете. Зачем это мне и тем более остальным?

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

Все-таки неудобная таблица. Лучше 5 по этой шкале неба я не видел. Зато видел множество оттенков интервала 7-9. Очень грубая шкала. Сколько наблюдений у нас на форуме было с оценкой <4? Одно-два? Нужна более точная шкала для 7-9, а все что <4 взять за один идеальный

То есть приравнять Понизовку к Шумбе  
Вы меня конечно извините, но я бы наоборот 8-9 свел к одному уровню...

Как быть с t_search_map? Надо бы обсудить ВСЕ детали поисковых карт, и я могу делать их штук по 20-30  за дежурство. Наверное, заведу завтра тему об этом в Наблюдениях

Возьмите за эталон Уранометрию - не прогадаете.
IMHO карты нужны только для сложных в поиске объектов, типа G1. А забивать базу картами с дипами вроде NGC7331 - кому это нужно? Новичкам? Так пусть не расслабляются, а учаться работать с электронными планетариями  

[Doof]

Степени засветки неба из указанной статьи

Все-таки неудобная таблица. Лучше 5 по этой шкале неба я не видел. Зато видел множество оттенков интервала 7-9. Очень грубая шкала. Сколько наблюдений у нас на форуме было с оценкой <4? Одно-два? Нужна более точная шкала для 7-9, а все что <4 взять за один идеальный.

Саша, а где у тебя дача? Сколько до города (Москва?)

70 км на запад (дальше чем Звенигород). Место действительно темное, так что засветка от Москвы просматривается на высоту 30-40 градусов.

[Doof]

Все-таки неудобная таблица. Лучше 5 по этой шкале неба я не видел. Зато видел множество оттенков интервала 7-9. Очень грубая шкала. Сколько наблюдений у нас на форуме было с оценкой <4? Одно-два? Нужна более точная шкала для 7-9, а все что <4 взять за один идеальный

То есть приравнять Понизовку к Шумбе  
Вы меня конечно извините, но я бы наоборот 8-9 свел к одному уровню...

Лучше таблицу не трогать, составлена очень грамотно. И несмотря на то, что большинство наблюдателей на этом форуме довольствуется небом > 5, но редкие вылазки в Крым и на Кавказ оставялют надежды на пополнение базы и при гораздо лучшем небе.  Только вот зодиакальный свет я за свою жизнь так ни разу и не видел  

[Ernest]

> t_Eyepieces   - это что? справочник по окулярам или список всех окуляров в наличности и наблюдателей?

Я предполагал эту таблицу именно как справочник окуляров - на каждый по одной записи. Отзывы владельцев не планировались и я не вижу в них особого смысла. Мы же решили ограничиться описание Дип-Скаев, а не инструментами. Иначе мы очень быстро придем к начальному виду базы, так напугавшей участников дискуссии. Или мы хотим объять необъятное? Ну зачем наличие наглазника, вес и габариты. Раздумья об их учете отдалают нас от главной темы. Насчет сотен позиций в списке - это легко устранимо: у клиента добавляем эту таблицу булевым полем (Есть/Нету). При первом старте юзер активирует нужные чек-боксы (соответствующие имеющимся у него окулярам), далее при протоколировании наблюдения в попуп-меню будут только помеченные окуляры. Также можно поступить и с телескопами. Купил новый окуляр - пошел в настройки и поставил галочку. И не следует привязывать окуляры и телескопы к владельцам - на совместных наблюдениях все смотрят во все подряд, и если я увидел очаги звездообразования в М33 в 250мм Ричи-Критьен Антона Савельева, то это не значит, что я не имею права отметить это в журнале.
Вы же сами, Эрнест, сказали, что мы не инструментами меримся, а делимся впечатениями от Дипов, и я с этим категорически согласен.

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

>t_Eyepieces.id_eyepieces   integer   - рекомендую заменить ключи string и забивать чем-то более менее понятным типа 5meade4000 (5 мм Meade 4000 серии)

Текстовый тип ключевого поля?   Не позволю!

В чем проблема?

Для ручной работы воспользуемся конструкцией t_observ key join t_eyepieces

Едва-ли это добавит мнемоничности.

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

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

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

> t_observ_place - полезная таблица.

Фотографии-то зачем? Я, например, лишь спустя два месяца увидел как выглядит мое наблюдательное место при дневном свете. Зачем это мне и тем более остальным?

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

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

Ну и какая фотография будет признана самой правильной для того, чтобы дать представление о М42? Да и потом - ели графический материал будет множественным, то ограничение на разные типы (фото, рис., карта) становится уже искусственным.

>t_observ_session - нет поля длительности наблюдений, тектового описания и ссылки на основной инструмент

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

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

   
> t_observ.id_observ integer - просто порядковый номер наблюдения в сессии (часть составного ключа)
К какой таблице вязаться этим составным ключом?

Ни к какой - для упорядочивания.

> t_observ.observ_object_descript_lyric - скорее уместно в таблице наблюдательных сессий
Может быть и туда следует добавить, но в t_observ тоже следует оставить.

То есть сообщение о том, что приходил сержант и спрашивал документы важно именно в контексте наблюдения М31?

[shandrik]

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

Имелся ввиду немного не такой справочник - просто таблица с ВАЖНЫМИ для наблюдения параметрами - фокусное расстояние и поле. Вес , вынос зрачка, покрытия и т.п. - вторично. Это можно, конечно, сделать, но не вижу смысла. Неужто большой вес Паноптика заставит сделать выбор в пользу СуперПлоссла НПЗ? Поле и f, больше ничего не нужно.
Не понадобится заново птички ставить - добавляемые  окуляры будут иметь больший ID и с более ранними не пересекутся. При Inserte будет условие на присутствие вписываемой записи. Обратная связь (скачивание обновленных справочников), на мой взгляд, должна быть только по желанию пользователя.

>t_Eyepieces.id_eyepieces   integer   - рекомендую заменить ключи string и забивать чем-то более менее понятным типа 5meade4000 (5 мм Meade 4000 серии)
Текстовый тип ключевого поля?   Не позволю!

В чем проблема?

Ну что за необходимость писать строку, если можно поставить цифру, на которую можно посадить функцию автоинкремента?

Для ручной работы воспользуемся конструкцией t_observ key join t_eyepieces

Едва-ли это добавит мнемоничности.

Чего-чего добавит? Чевой-то такое?

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

Решено - таблицу типов телескопов оставляем, но без привязки к владельцам.

> t_observ_place - полезная таблица.

Фотографии-то зачем? Я, например, лишь спустя два месяца увидел как выглядит мое наблюдательное место при дневном свете. Зачем это мне и тем более остальным?

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

Для этого есть е-мэйл наблюдавшего там. Все равно выбравший это место будет связываться к его указавшим. Зачем фото наблюдений - туда же не земным пейзажем любоваться ездим.

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

Ну и какая фотография будет признана самой правильной для того, чтобы дать представление о М42? Да и потом - ели графический материал будет множественным, то ограничение на разные типы (фото, рис., карта) становится уже искусственным.

Пусть, например, Павел Бахтинов решит.

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

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

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

   
> t_observ.id_observ integer - просто порядковый номер наблюдения в сессии (часть составного ключа)
К какой таблице вязаться этим составным ключом?

Ни к какой - для упорядочивания.

Для упорядочивания есть дата наблюдения.

> t_observ.observ_object_descript_lyric - скорее уместно в таблице наблюдательных сессий
Может быть и туда следует добавить, но в t_observ тоже следует оставить.

То есть сообщение о том, что приходил сержант и спрашивал документы важно именно в контексте наблюдения М31?

  Согласен, надо бы и туда добавить.

[Dima Zarkov]

Всем привет!

Если тема прекращает своё существование, то может быть у кого есть возможность систематизации темы: "Журнал наблюдений Deep Sky". Уж очень хочется посмотреть чего мы достигли и/или можем достигнуть.

Я бы и сам взялся, но у меня GPRS - интернет, соответственно можете сами представить, по денюшкам и времени. Можно, и мне кажется, желательно сделать в виде таблицы Excel для простоты и меньшего местозагромождения.

Всем спасибо.

p.s.: желательно, с возможностью добавления (обнавления) таблицы.

[shandrik]

Всем привет!

Если тема прекращает своё существование, то может быть у кого есть возможность систематизации темы: "Журнал наблюдений Deep Sky". Уж очень хочется посмотреть чего мы достигли и/или можем достигнуть.

Нет, не прекращает. Осталось только потолочку приклеить и плинтуса прицепить - за завтра сделаю и работа над проектом продолжится.

[Роман Чириков]

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

[Роман Чириков]

 Ну и где результаты?
Сайт Deep-Sky готов на www.deepsky.detalk.ru .
Хочу посмотреть на ваши достижения.

[Алеkсей]

Не подскажете, было ли у этой ветки где-то продолжение? Больше постов Романа Чурикова по этой теме я не нашел, а ссылка на сайт похоже не работает.

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

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

М13 - (1) - (2) - (3) - (4) - [5]
где
(1) - степень засветки неба по шкале, предложенной несколькими постами выше (цифра).
(2) - тип телескопа (буква, сокращенно) и его апертура в мм (цифра)
(3) - модель телескопа (желательно некоторое простое полусокращенное название)
(4) - широта и дата/время наблюдения
[5] - само описание объекта, с указанием некоторых обязательных параметров описания

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

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

Как вам такая идея?