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

[Ernest]

Я вот подумал, а может уже начать что-нибудь делать?

Ну, пока сыр да бор.

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

Кто-нибудь предоставит место на своем ftp сервере для мастер-копии .xls и графических файлов. Несколько человек будут иметь к нему доступ на запись и иметь возможность пополнять и редактировать его. Остальные участники проекта - только на чтение. Всякий, кто хочет пополнить присылает редакторам свои .xls или еще лучше .csv файлы + .jpeg, те просматривают и время от времени сливают с мастер файлом.

Excel-книга должна состоять из следующих страниц-таблиц

1) Участники проекта: уникальный ник-ID*, ФИО, контактная информация, ссылки на сайты и проч.
2) Инструменты участников: ник-ID*,  ник-ID владельца (или еще лучше линк на соотв. поле таблицы 1)*, апертура, относительное, схема, описание, внешние ссылки на описания
3) Список наблюдательных сессий: дата*, ник-ID наблюдателя (или линк на таблицу 1)*, ник-ID инструмента (или тинк на таблицу 2), описание условий (лучше отдельно по полям: видность, прозрачность, облака, возраст/высота Луны, артефактная засветка, ветер, температура, влажность...)
4) Список объектов Месье: номер*, координаты, созвездие, тип, характеристики, ссылки на внешние описания
5) Список объектов NGC: номер*, координаты, созвездие, тип, характеристики, ссылки на внешние описания
6) Список прочих объектов: обозначение*, номер*, координаты, созвездие, тип, характеристики, ссылки на внешние описания  
7) Наблюдение: обозначение каталога, номер объекта* (а лучше прямой линк на таблицы 4,5,6), ник-ID наблюдательной сессии (линк)*, описание объекта с указанием увеличения, фильтра, 5-бальная оценка трудности и впечатления, линк на рисунок, если он прилагается, ссылка внешний ресурс.

* - ключевые поля

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

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

Для информации:

https://astronomy.ru/forum/index.php?board=9;action=display;threadid=3588

[Doof]

Эрнест, у меня в общем-то, база своя есть. У Pluto, насколько я понимаю, тоже. И у многих других. Гораздо проще сконвертировать ее во что-то уже готовое, нежели сейчас записывать наблюдения в Excel. Может для тех у кого ничего нет, этот вариант и подходит. Но мне лично не хотелось бы делать двойную работу (тем более, что я до сих пор еще не все свое "отнаблюденное" оцифровал).

Но начинать что-то делать надо, я согласен...
 

[shandrik]

Для информации:

https://astronomy.ru/forum/index.php?board=9;action=display;threadid=3588

Как-то неожиданно все там закисло. Кстати, ML хостинг предлагал...

Я обдумаю представление Эрнеста. Но это дня два-три. Здесь спешка опасна, т.к. все остальное должно строится на этой основе.

[Ernest]

...у меня в общем-то, база своя есть. У Pluto, насколько я понимаю, тоже. И у многих других. Гораздо проще сконвертировать ее во что-то уже готовое, нежели сейчас записывать наблюдения в Excel.

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

[Doof]

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

Вот это точно! Нужно уже что-то реальное, тогда, глядишь, народ начнет потихоньку подтягиваться.

[plt]

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

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

[plt]

Но мне лично не хотелось бы делать двойную работу (тем более, что я до сих пор еще не все свое "отнаблюденное" оцифровал).

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

[Doof]

Но мне лично не хотелось бы делать двойную работу (тем более, что я до сих пор еще не все свое "отнаблюденное" оцифровал).

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

Сомневаюсь, что я буду хранить ВСЕ свои наблюдения в общедоступной БД. Это во-первых, будет очень много (я еще и двойные звезды наблюдаю), а во-вторых никому не нужно. К тому же, у меня все это привязано к собственным таблицам deep-sky и двойных, а также к сотням Мб картинок. В любом случае, в общедоступную БД будет включаться только "избранное".

[plt]

Сомневаюсь, что я буду хранить ВСЕ свои наблюдения в общедоступной БД. Это во-первых, будет очень много (я еще и двойные звезды наблюдаю), а во-вторых никому не нужно. К тому же, у меня все это привязано к собственным таблицам deep-sky и двойных, а также к сотням Мб картинок. В любом случае, в общедоступную БД будет включаться только "избранное".

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

[shandrik]

Вот как я вижу Базу Проекта.
Красным выделены места, где я неуверен и/или требуется обсуждение.

NB: лицам, не работавшим с базами данных, смотреть не рекомендуется во избежание несчастных случаев.

Упс, нашел ошибку. Сейчас исправлю.

[Belatrix]

Когда-то, в студенческие годы, делал такую БД - для себя. Но уж больно лень было переводить все из журнала в цифровой формат, и это дело заглохло.
Сейчас, будучи профессиональным программистом и руководителем проекта (к сожалению, не в области WEB) могу изложить свое видение и даже разработать или курировать некоторую часть проекта. если будет время (спецы по WEB меня поправят, если я в чем не прав).
1) Я согласен, что должен быть клиент с локальной БД, а  браузером. Это как с электронной почтой - можно работать и в ie, но неудобно, и большинство работает с аутлуком, батом и т.д.
2)Пользователь ведет свою базу - локально. Если его интересует какой-то объект (группа объектов, по какому либо признаку и т.д.), он заполняет форму поиска, и из сети к нему скачивается необходимая инфа, и сохраняется в локальной БД.
3) Если пользователь желает опубликовать свои результаты - аналогично, на нужной форме ставит галочку, или выбирает свои результаты с помощью фильтра - и публикует.
4) Пользвательский интерфейс клиента предусамтривает все что нужно в подобных случаях - поиск, сортировку, добавление\удаление, вывод на печать, отправку по почте и т.д.

В качестве локальной БД лучше исспользовать Access по понятным. причинам:
движок MS Jet уже предустановлен во все оперционки семейств Win 2000, XP, возможно, Millenium (не уверен точно), а для установки на 98 и 95 движка достаточно поставить Access, который (пиратству форева!) есть на каждом диске с оффисом. Хоть база и примитивна, но она реляционная, поддерживает SQL.
Хотя, с другой стороны, современным провайдерам, той же ADO плевать, что у вас там стоит - Access, SQL Server, MySQL или Oracle - лишь бы формат баз совпадал да SQL не использовал уникальных спецификаций - а для нашего в общем-то элементарного случая это и не надо.

Что касается обмена с хостом- то с помощью современных средств разработки это делается элементарно.

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

Шандрику:
на мой взгляд, не стоит так подробно (в справочных таблицах) описывать окуляры, монтировки и т.д. Просто указывать название инструмента (ну по телескопам можно ввести справочную таблицу ), его диаметр, тип, увеличение, угловое поле зрения, ну и примичание.
Гораздо важнее предоставить подробную инфу по объекту - например, фотографии и зарисовки хранить в отдельной таблице, ведь на один объект может сссылаться несколько фотографий и зарисовок.
Расклад таков:
1) Разработка тех. предложений к проекту, разработка структуры базы данных - 1-2 недели в зависимости от энутзиазма
2) Разработка клиента в первом приближеннии - 30-50 опытныхчеловекочасов
3) Разработка серверной части - вопрос к спецам в этом вопросе

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

Предлагаю всем кто может приложить к этому свои руки писать здесь, кто на что способен и какую часть способен воплотить. Для осуществления проекта, на мой взгляд, нужно человека 4-5: 2-программистов, 2-web-программистов + координатор.
И еще: кто обеспечит хостинг?

Шандрику:
давненько я здесь не был, если народ будет проявлять интерес, готов поучавствовать. Тогда выложу свое видение БД, постараюсь использовать Ваше в качестве шаблона. Опыт в разработке у меня достаточно большой. А чем Вы готовы помочь? Кстати, спасибо за поздравления с днржд!

P.S Интересно, сколько человек это заинтересует? Стоит ли игра свечь?
С другой стороны, а может у нас родится мега - интерактивное руководство по наблюдениям? Помните, "Сокровища звездного неба" По - моему, для начинающего нет книги лучше. А все почему - информация в ней структурирвоана по созвездиям, описывается каждый объект, а не как в других книгах - вот галактика выглядит так-то и так-то, а дальше сухой список. Аналогично был когда-то "Звездный ларец", у Остапенко, кажется.
Кстати, кроме всего прочьего, хорошо было бы предусмотреть поисковую карту - одну, общую на объект. RedShift, конечно, хорошо наверное(кстати, сегодня я его заказал), но пока не видел ,  интересно, возможно ли применение в нем плагинов - ну скажем, выделяете объект на карте, наживаете кнопку - и получаете подробную информацию из нашей БД?

[wladimir]

Начать надо с переименования темы...
Сделам -> Сделаем

[shandrik]

1. Добавлено забытое поле id_mount в таблицу t_observ
2. Удалено поле t_mount из таблицы t_telescopes
2. Добавлено поле moderation_level для защиты пользователей от "вчера смотерл М31 - НУ ВАЩЩЕЕ!!!!"
3. Добавлен лист History

[shandrik]

Просьба не вносить самим изменения в файл, т.к. это затруднит синхронизацию.
Эту привилегию я оставлю за собой.  

[shandrik]

О, Виталий, привет. Давненько тебя не было.

1) Я согласен, что должен быть клиент с локальной БД, а  браузером. Это как с электронной почтой - можно работать и в ie, но неудобно, и большинство работает с аутлуком, батом и т.д.
2)Пользователь ведет свою базу - локально. Если его интересует какой-то объект (группа объектов, по какому либо признаку и т.д.), он заполняет форму поиска, и из сети к нему скачивается необходимая инфа, и сохраняется в локальной БД.
3) Если пользователь желает опубликовать свои результаты - аналогично, на нужной форме ставит галочку, или выбирает свои результаты с помощью фильтра - и публикует.
4) Пользвательский интерфейс клиента предусамтривает все что нужно в подобных случаях - поиск, сортировку, добавление\удаление, вывод на печать, отправку по почте и т.д.

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

В качестве локальной БД лучше исспользовать Access по понятным. причинам:
движок MS Jet уже предустановлен во все оперционки семейств Win 2000, XP, возможно, Millenium (не уверен точно), а для установки на 98 и 95 движка достаточно поставить Access, который (пиратству форева!) есть на каждом диске с оффисом. Хоть база и примитивна, но она реляционная, поддерживает SQL.
Хотя, с другой стороны, современным провайдерам, той же ADO плевать, что у вас там стоит - Access, SQL Server, MySQL или Oracle - лишь бы формат баз совпадал да SQL не использовал уникальных спецификаций - а для нашего в общем-то элементарного случая это и не надо.

Access, говоришь.   Ну, не знаю, не знаю. Как-то я пробовал в нем писать - что-то не понравилось, но может настроение не то было. Но больше я к нему не возвращался. Может Sybase выбирем? Он как раз репликации через письма поддерживает, не так сложен, как ORACLE в администрировании и очень удобен в использовании. У меня есть дистриб SQL Anywhere 7. Могу разослать пользователям. Поди не посадят за пиратство. Клиент ставится за 10 минут. Хотя нет, там же нужно и сервер ставить   Но я могу написать подробную инструкцию настройки.

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

Насчет метеоров не знаю, а вот о двойных подумываю.

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

Окуляр нужен обязательно, т.к. его влияние на видимое изображение уступает только объективу. А вот насчет монтировок я не уверен - просто я хотел отразить все факторы, влияющие на видимое изображение. Кошачий Глаз в 300х с Добсон-монтировкой пролетит поле зрения десять секунд, а с часовым механизмом есть возможность рассмотреть хорошенько. Кроме того, были посты о том, что с ГО-ТО галактики с низкой поверхностной яркостью не видны, в без ГОТО видны. Надо всем подумать и решить, нужно ли монтировки учитывать.

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

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

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

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

P.S Интересно, сколько человек это заинтересует? Стоит ли игра свечь?
С другой стороны, а может у нас родится мега - интерактивное руководство по наблюдениям?

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

Кстати, кроме всего прочьего, хорошо было бы предусмотреть поисковую карту - одну, общую на объект.

Есть же таблица t_search_map. Правда я считаю, что надо изменить её структуру:
id_object
id_uvelichenie
id_map
Но надо пронормировать увеличения.

[dmitryP]

Можно маленькое IMHO сочувствующего?  

Вы чего с базой собираетесь делать? На сайт ставить? Тогда выбор базы будет на 100% определяться возможностями хостинга. А стало быть нужно плясать отсюда.

А реалии здесь такие: если ориентироваться на недорогой приличный хостинг (не аренда сервера) -- это Unix + Apache + MySQL + php или perl (реже, к моему сожалению). С хостингами под Windows дело имел -- работает только если сам этим сервером рулишь.

Соответственно выбор базы тривиальный: MySQL и ничего другого (ADO, Sybase, Access...).

А уж если хочется писать клиента под этот сайт, то пусть этот клиент генерит xml, котрый на сайте можно поимпортить/поэкспортить.

[Ernest]

Мне кажется, что в предложенная shandrik-ом система таблиц не очень удачна - слишком громоздка, что-ли?

t_manufacturer - влияние производителя инструмента на вид конкретного дипа много меньше, чем уровня засветки на месте наблюдения и скорости ветра. Зачем тогда усложнять себе жизнь? Мы ведь не инструментами собираемся меряться, а впечатлениями от дипов.

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

t_filters и t_filters_type - соображения аналогичное вышеприведенному, помноженное на редкость применения фильтров (достаточно одного опционального поля в таблице наблюдений)

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

t_observer - таблица чрезмерно усложнена (см. данные по участнику этой конференции)

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

t_observ_place - полезная таблица хотя и чрезмерно детализированная, достаточно, наименования, высоты над уровнем моря, описания и опциональных координат

t_object - должна быть дополнена таблицей ссылок на внешние данные, каждая запись которой ссылается на соотв. запись в t_object

t_object_type, t_object_subtype - избыточны, достаточно соотв. строкового поля в t_object

t_search_map - просто пара ключей - ссылка на t_object и линк на интернет-ресурс с опциональным описанием

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

t_observ - ссылки на окуляр и фильтр заменить на увеличение и, возможно, опциональное текстовое поле использованного фильтра (можно и без этого - достаточно его упоминания в описании), JD - можно отбросить, дипы довольно малоизменчивы - достаточно даты в t_observ_session и, возможно, дополнения к описанию в виде засечки момента времени, если это потребуется

[Doof]

Комментарии:

t_eyepieces и t_eyepieces_type, t_filters и t_filters_type, t_telescopes и t_telescopes_type, t_mount и t_mount_type  руки чешутся объединить. Не надо структуру приводить к 5 НФ  

t_observer

Пол (True - муж, false -жен) - Долго смеялся  
Adress, Phone - действительно не нужны

t_observ_place

Надо еще подумать

t_object

Честно говоря, не совсем понятно зачем использовать t_object_type и t_object_subtype - типичные "слабые сущности", гораздо проще и понятнее использовать отдельные поля в t_object типа:

type - тип объекта (GALXY,OPNCL,GLOCL,PLNNB,BRTNB,DRKNB и пр.)
class - класс объекта в соответствии с общепринятой классификацией
numstr - количество звезд в скоплении (для рассеяных)
brtstr - VMag самой яркой звезды в скоплении (в том числе и для шаровиков) или блеск центральной(главной) звезды для планетарок или отражающих туманностей.


t_searchmap

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

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

По поводу описания и качественных оценок, здесь предстоит еще договориться.

[Doof]

Пока писал, уже ответил Эрнест. Радует, что многое совпадает...