Nowy programik do analizy zdjęć

sumas · 9 Marca 2007

FlashGet'em

8. część - katalogi od 090-099 - jest już ściągnięta - 2,37GB, ale z wyjątkiem jednego pliku U0917.bin

powalczę z nim później

GrzegorzP · 9 Marca 2007

Nie byłem pewien jak będzie szło, ale jest nieźle. Część 5 już prawie zeszła.

Dopisuję się więc dalej:

1. część - katalogi od 000-029 - kaluzny_m

2. część - katalogi od 030-039 - kaluzny_m

3. część - katalogi od 040-049 - mario2005

4. część - katalogi od 050-059 - mario2005

5. część - katalogi od 060-069 - GrzegorzP

6. część - katalogi od 070-079 - KrzysztofZ

7. część - katalogi od 080-089 - KrzysztofZ

8. część - katalogi od 090-099 - sumas ale bez pliku U0917.bin

9. część - katalogi od 100-109 - sumas

10. część - katalogi od 110-119 - GrzegorzP

11. część - katalogi od 120-129

12. część - katalogi od 130-139

13. część - katalogi od 140-149

14. część - katalogi od 150-179 - Piotr Brych

Jazz · 9 Marca 2007

Witam,

no to ja biorę 12.

Pzdr

Jazz

1. część - katalogi od 000-029 - kaluzny_m

2. część - katalogi od 030-039 - kaluzny_m

3. część - katalogi od 040-049 - mario2005

4. część - katalogi od 050-059 - mario2005

5. część - katalogi od 060-069 - GrzegorzP

6. część - katalogi od 070-079 - KrzysztofZ

7. część - katalogi od 080-089 - KrzysztofZ

8. część - katalogi od 090-099 - sumas ale bez pliku U0917.bin

9. część - katalogi od 100-109 - sumas

10. część - katalogi od 110-119 - GrzegorzP

11. część - katalogi od 120-129

12. część - katalogi od 130-139 - Jazz1972

13. część - katalogi od 140-149

14. część - katalogi od 150-179 - Piotr Brych

Edytowane 9 Marca 2007 przez Jazz1972

mario2005 · 9 Marca 2007

plik U0917.bin mam ściągnięty.

Jazz · 9 Marca 2007

12 mamy.

Pzdr

Jazz1972

Jazz · 9 Marca 2007

wezmę jeszcze 11

1. część - katalogi od 000-029 - kaluzny_m

2. część - katalogi od 030-039 - kaluzny_m

3. część - katalogi od 040-049 - mario2005

4. część - katalogi od 050-059 - mario2005

5. część - katalogi od 060-069 - GrzegorzP

6. część - katalogi od 070-079 - KrzysztofZ

7. część - katalogi od 080-089 - KrzysztofZ

8. część - katalogi od 090-099 - sumas + mario2005

9. część - katalogi od 100-109 - sumas

10. część - katalogi od 110-119 - GrzegorzP

11. część - katalogi od 120-129 - Jazz1972

12. część - katalogi od 130-139 - Jazz1972

13. część - katalogi od 140-149

14. część - katalogi od 150-179 - Piotr Brych

Pzdr

Jazz

Jazz · 9 Marca 2007

11 jest.

Pzdr

Jazz

Jazz · 10 Marca 2007

nio to jak nie ma chętnych wezmę jeszcze 13 i będzie po ptokach.

Pzdr

Jazz

1. część - katalogi od 000-029 - kaluzny_m

2. część - katalogi od 030-039 - kaluzny_m

3. część - katalogi od 040-049 - mario2005

4. część - katalogi od 050-059 - mario2005

5. część - katalogi od 060-069 - GrzegorzP

6. część - katalogi od 070-079 - KrzysztofZ

7. część - katalogi od 080-089 - KrzysztofZ

8. część - katalogi od 090-099 - sumas + mario2005

9. część - katalogi od 100-109 - sumas

10. część - katalogi od 110-119 - GrzegorzP

11. część - katalogi od 120-129 - Jazz1972

12. część - katalogi od 130-139 - Jazz1972

13. część - katalogi od 140-149 - Jazz1972

14. część - katalogi od 150-179 - Piotr Brych

Piotr Brych · 10 Marca 2007

Super!

Taka współpraca mi się podoba!

Programik już niedługo (mam nadzieję).

Limax7 · 10 Marca 2007

Baza danych planetoid jest w pliku MP.dat a powstał on przez obróbkę bazy zamieszczonej na ftp://cfa-ftp.harvard.edu/pub/MPCORB/. Aby mieć aktualną bazę trzeba mieć programik który przekształca dostępny tam plik na bazę w formacie obsługiwanym przez AFA. Skoro jest taka potrzeba to programik ten będzie udostępniony razem z AFĄ. Każdy będzie mógł sam sobie ściągnąć z internetu bazę i ją przerobić. O ile MPCORB będzie udostępniało bazę w tym samym formacie w przyszłości.

Oj potrzebny będzie ten dodatkowy programik

Komety - tak. Bardzo dobry pomysł! Rozbuduję program o tę funkcję.

Cieszę się. Nie wiem tylko czy nie będzie z tym problemu. Chodzi mi o bazę komet, pojawienia się w przeszłości i nadchodzące. Problem tkwić może w kometach okresowych, gdzie przy następmym pojawieniu się komety, elementy orbity są zazwyczaj zmienione (mniej lub bardziej).

Napisz skąd wziąłbyś bazę komet. Domyślam się, że z MPEC/CFA, tam jednak są komety obecnie obserwowane.

Tu też niezbędny będzie programik do konwersji na bazę obsługiwaną przez AFA.

Zaznaczanie tylko gwiazd jasnych (<8 mag) zostało pominięte a to dlatego, że zdjęcia na których występują tylko gwiazdy jasne to zdjęcia szerokich obszarów nieba - a takie nie są obsługiwane przez program bo występują tu duże zniekształcenia w odwzorowaniu nieba na płaskim zdjęciu. Jasne gwiazdy są oznaczane ale razem ze slabymi. Może przesunę granice do 6 mag ale niżej nie ma sensu.

6 mag, OK, niech będzie

To naprawdę ciekawy program, Gratuluję pomysłu.

Czuję, że będzie z tego wielkie COŚ !

mario2005 · 10 Marca 2007

Część 3 i 4 na pokładzie.

:Salut:

Piotr Brych · 12 Marca 2007

Programik już nabiera kształtów i oczekuje na bazę na której mógłby sie wyżyć! Zatem przysyłajcie płytki! Coś czuję, że w ciągu trzech dni "trailer" programu będzie umieszczony na stronie.

dobsonme · 13 Marca 2007

Katalogu USNO uzywa sie zawsze i wszedzie jednak wiele placowk naukowych nawet nie posiada jego kopii.

Czy nie bylo by sensowniej zamiast zasysac dziesiatki gigabajtow danych z sieci, podlaczyc do programu skrypcik za pomoca ktorego laczylby sie z siecia i wyszukiwal gwiazdek dla wybranego pola :icon_question: :icon_idea:

Piotr Brych · 13 Marca 2007

Być może było by lepiej gdyby:

- użytkownik miał zawsze dostęp do internetu, najlepiej stałe i szybkie łącze

- bazy danych w internecie byłyby ciągle dostępne w tym samym formacie (właściciel serwera zmienia jeden bajt np. w ukladzie katalogów i program przestaje działać)

Ale na razie nie będzie, bo moja wiedza programistyczna jest zbyt skąpa i nie umiem takich rzeczy robić. Jeśli ktoś umie to zapraszam do tworzenia takich programów - miłośnicy astronomii będą mieli większy wybór. A poza tym dzięki dobrym ludziom, te GB zostały już zassane i zaraz się skurczą do rozmiarów jednej DVD którą każdy będzie mógł używać niezależnie od jakości połączenia z internetem.

Katalogu USNO uzywa sie zawsze i wszedzie jednak wiele placowk naukowych nawet nie posiada jego kopii.
Czy nie bylo by sensowniej zamiast zasysac dziesiatki gigabajtow danych z sieci, podlaczyc do programu skrypcik za pomoca ktorego laczylby sie z siecia i wyszukiwal gwiazdek dla wybranego pola

dobsonme · 13 Marca 2007

Z tego co pamietam to katalogi sa ustandaryzowane i raczej nic sie nie ma prawa tam zmienic.

Z checia bym pomogl ale obawiam sie, ze mam z programowaniem podobny problem

Ale jesli uda mi sie do czegos sensownego dojsc to dam znac.

Maciej Reszelski · 15 Marca 2007

nio to jak nie ma chętnych wezmę jeszcze 13 i będzie po ptokach.

13. część - katalogi od 140-149 - Jazz1972

14. część - katalogi od 150-179 - Piotr Brych

Czy będziecie pożniej udostępniać je?

Ja mam cieniutkie złącze...

pozdrawiam,

Maciek

KrzysztofZ · 15 Marca 2007

6. część - katalogi od 070-079 - KrzysztofZ

7. część - katalogi od 080-089 - KrzysztofZ

katalogi już mi się ściągnęły - wysyłam jutro

Piotr Brych · 16 Marca 2007

Czy będziecie pożniej udostępniać je?
Ja mam cieniutkie złącze...

pozdrawiam,

Maciek

Całość będzie dostępna z programem (po obcięciu zbędnych informacji)

16 Marca 2007

ja też już kończe ostatnie katalogi - proszę o adres na priv.

Pozdrawiam !

Piotr Brych · 21 Marca 2007

Katalogi od sumasa i GrzegorzaP już doszły. Dzięki wielkie. Programik już czyta katalogi USNO, ale jeszcze wymaga dopracowania w paru miejscach. Sam katalog jest niesamowicie pogmatwany i zrobienie z niego porządnego wyciągu to problem który mam już jednak prawie za sobą. Twórca tej wersji (*.bin) zadał sobie dużo trudu aby skompresować go do dostępnej postaci przez co ja spędziłem parę dni próbując pojąć głębie jego myśli. Czekam na dalsze części.

Maciej Reszelski · 21 Marca 2007

Katalogi od sumasa i GrzegorzaP już doszły. Dzięki wielkie. Programik już czyta katalogi USNO, ale jeszcze wymaga dopracowania w paru miejscach. Sam katalog jest niesamowicie pogmatwany i zrobienie z niego porządnego wyciągu to problem który mam już jednak prawie za sobą. Twórca tej wersji (*.bin) zadał sobie dużo trudu aby skompresować go do dostępnej postaci przez co ja spędziłem parę dni próbując pojąć głębie jego myśli. Czekam na dalsze części.

Jakby to nie było problemem możesz opisać sposób czytania z tych bin-ów (na priva:

macres (at) pro.onet.pl). Stokrotne dzięki!

pozdrawiam,

Maciek

Piotr Brych · 1 Maja 2007

Po przerwie spowodowanej obowiązkami służbowymi wracam, korzystając z "dłuuuugiego łikendu" do tematu. Otóż prace na AFA w wersji USNO wstrzymały się gdyż napotkałem pewne problemy. Jeżeli ktoś potrafi mi pomóc je rozwiązać to będę wdzięczny.

1. Najmniejszym problemem jest fakt, że katalog ten jest nieco kiepski pod jednym względem - powstał na podstawie zdjęć i każdą białą część zdjęcia traktuje jak obiekt godny uwagi. W ten sposób za obiekty uważa też "piki" i pierścienie wokół jasnych gwiazd uwidocznione na zdjęciach, przez co program również w otoczeniu jasnych gwiazd pokazuje elegacko "gwiazdy" ułożone w krzyżyk i pierścień wycentrowane na jasnej gwieździe. Jest to wkurzające ale nie znalazłem sposobu na obejście. Myślałem, że takie obiekty zaznaczone są w katalogu odpowiednim bitem nazwanym w opisach (pliki usno1def.h) jako "SPK" ale to nieprawda. Wg mnie takie pseudoobiekty nie są wogóle w katalogu odróżnione od rzeczywistych gwiazd i galaktyk. Jeśli się mylę to proszę o podanie metody jak odróżnić takie śmieci od wartościowych danych. W ostateczności program będzie działał z tymi niepotrzebnymi danymi.

2. Problem podstawowy:

Nie mogę znaleść opisu formatu tego katalogu. Są skromne opisy np. w pliku usnob1def.h ale zawierają błędy i jakieś stare formaty już w tej wesji nie używane i nie wyjaśniają aktualnego formatu do końca. Pewnie z załączonych kodów w języku C można by dojść do formatu, ale ja tego języka nie znam (posługuję się Delphi czyli pascalem). Najprostszym rozwiązaniem tego problemu byłoby znalezienie katalogu w wersji nie tak brutalnie spakowanej jak ta którą dysponujemy. Tutaj autor tej kompresji zadał sobie niesamowicie dużo trudu aby zdusić katalog, co wydaje mi się bezsensem, bo dzięki totalnemu zagmatwaniu kodu uzyskał zduszenie z ok. 80GB do ok. 40GB. Pewnie to samo by uzyskał po prostu kompresując dane jakimś ZIPem (pewnie chodziło mu o skompresowanie danych bez konieczości używania potem programu odzipowującego przez co z katalogu mogą korzystać zewnętrzne programy bezpośrednio). Jeżeli katalog oryginalny nie jest dostępny to trzeba rozszyfrować ten format jaki mamy dostępny.

Powiem od razu, że dzięki temu co wiem, mogę odszyfrować większość danych ale nie wszystkie, co mnie martwi i wskazuje na dwie rzeczy:

- Albo moje algorytmy zawierają jakiś błąd, co wyłazi w pewnych miejscach katalogu w sposób jawny (powstają totalnie bezsensowe dane) ale też może się okazać że w innych miejscach są błędy w odczycie ale już nie tak oczywiste i dlatego umykają uwadze, co jest bardzo niebezpieczne dla programu. Dlatego algorytm aby uznać za właściwy musi być w 100% dobry i dlatego wstrzymało to moje prace.

- Albo w plikach które ściągneliśmy są błędy (poprzestawiane bity) co powoduje, że dobry algorytm psuje się na tych miejscach. To też jest źle. Jednak biorąc pod uwagę, że wiele elementów moich algorytmów jest jedynie domyślna, nie mogę z całą pewnością stwierdzić, że algorytm jest OK a dane są zepsute.

A oto wiedza jaką osiągnąłem sam próbując rozszyfrować format - przy czym zwracam uwagę tylko na te dane które uważam za potrzebne dla programu tj. numer USNO, jasność i położenie.

1. Pliki z danymi są dwóch rodzajów, nazwijmy je "biegunowymi" i "równikowymi".

2. Każdy plik z danymi składa się z nagłówka zakończonego znakiem ascii 10 (znak końca linii).

3. Na początku każdego pliku znajduje się tekst w stylu: "USNO-B1.0(17) ..." lub "USNO-B1.0(18) ..." Typ równikowy to ten z "17" a biegunowy z "18".

4. Dla pliku nr 900 ta linia nagłówkowa brzmi: "USNO-B1.0(17) 090/U0900.bin fld=0(0) pm=-500(1001) mag=700(1801) xi=-750(1501)" i z niej interesująca i zrozumiała jest dla mnie tylko wartość "mag=700" która oznacza, że do wartości jasności odczytanych potem z danych należy dodać 7.00 aby otrzymac rzeczywistą wartość jasności. Pozostałe dane raczej mnie nie interesują z wyjątkiem następującego po tej "700" nawiasu z liczbą 1801 - nie wiem o co tu chodzi a podejrzewam, że może to mieć znaczenie.

Dalsze informacje dotyczą tylko plików równikowych.

5. Po wierszu nagłówkowym następuje tabela 128 elementowa, każdy element to 2 liczby czterobajtowe (delphi cardinal).

6. Dane następujące po tej tabeli podzielone są na 124 (a nie 128) kawałków (chunk) które różnią się od siebie tym, że w każdym kawałku trzeba dodać inną wartość do odczytanej z danych wartości rektascencji (offset). Kawałki te są rozłożone równomiernie w rektascencji. Dane o rektascencji zapisane są w postaci 20 bitów (co daje 1048576 możliwości, a jednostką jest 0,01" co daje 2,9127(1) stopnia. Na pokrycie 360 stopni potrzeba zatem 124 kawałki (chunk'i). Tabela o której mowa w p. 5 zawiera w każdym wierszu: jako pierwszą liczbę numer bajtu w którym zaczyna się kolejny kawałek, jako drugą liczbę numer kolejny gwiazdy występującej jako pierwsza w danym kawałku. Tym samym np. dwusetna w kolejności gwiazda w kawałku nr 10, który to kawałek zaczyna się od gwiazdy nr 12345 ma numer 12345+200-1=12544. Natomiast jeżeli odczytamy rektascencję jakiejś gwiazdy z 15 kawałka jako 500 to jej rzeczywista rektascencja wynosi: (15-1)x2,9127(1) stopnia + 500x0,01".

7. Do opisu wszystkich kawałków wystarczy 125 par liczb czterobajtowych, a tabela z p. 5 ma 128 elementów. Po co? Nie wiem. W końcowych parach jest ukryta całkowita długość pliku i całkowita ilość gwiazd, ale po co są jeszcze dwa wiersze tabeli - nie wiem.

8. Następują potem 124 kawałki z których każdy składa się z nagłówka i danych o gwiazdach.

9. Nagłówek każdego kawałka to ciąg liczb (będący pełną wielokrotnością 4 bajtów) zakończonych sekwencją bajtów: 127,255,255,255 występującą w nieokreślonym z góry miejscu.

10. Nagłówek dzieli się na dwie grupy z których pierwsza to następujące elementy:

a) 4 bajty - liczba określająca długość pierwszej grupy w nagłówku wyrażona (jak pisze instrukcja) w "Sun binary" ????? Wg. mnie po prostu w bajtach

trzy liczby czterobajtowe oznaczające kolejno najmniejszy numer gwiazdy w kawałku, najmniejszą rektascencję i najmniejszą deklinację (czyli wartości które trzeba dodać do odczytanych potem danych aby uzyskać prawidłowy wynik)

c) trzy liczby czterobajtowe oznaczające kolejno największy numer gwiazdy w kawałku, największą rektascencję i największą deklinację

d) pozostałe dane, jak sądzę nieistotne dla programu których łączna długość z elementami opisanymi w a,b,c jest podana w a).

11. Druga grupa nagłówka (tzw. INDEX) to nieistotna chyba tabela pomocnicza która kończy się sekwencją 127,255,255,255

12. Po tych dwóch grupach składających się na nagłówek następuje dane o gwiazdach.

13. Każda gwiazda to 17 bajtów danych + bajty fotometrii których jest od 2x6 do 5x7 (dlaczego tak o tym dalej)

14. Jeżeli gwiazda jest gwiazdą z katalogu Tycho to ma 27 bajtów (27 to liczba która została przeze mnie określona eksperymentalnie - nie ma jej podanej wprost)

15. W przypadku gwiazd "nie Tycho" dane to:

- 8 bitów statusu

- 4 bity "Ndet"

- 16 bitów RA

- 16 bitów SPD (South Polar distance - odległość od bieguna południowego)

- 10 bitów niepewności RA

- 10 bitów niepewności SPD

- 3 bity flagowe

- 9 bitów epoki

- 4 bity "fit_RA"

- 4 bity "fit_SD"

- 2x12 bitów ruchu własnego

- 24 inne mało interesujące bity (muprob,e_pmRA i e_pmSD)

po czym następuje od 2 do 5 danych fotometrycznych o długości 6 lub 7 bajtów każdy. To ile jest danych fotometrycznych i jaką mają długość określa status.

16. Status to 8 bitów kolejno znaczących:

- Czy jest to gwiazda Tycho

- nieaktywny, zawsze zero

- czy fotometria jest 7 bajtowa (mam wrażenie, że wbrew opisowi to drugi bajt opisuje fotometrię a trzeci jest nieaktywny)

- czy występuje fotometria dla zakresu blue1

- czy występuje fotometria dla zakresu red1

- czy występuje fotometria dla zakresu blue2

- czy występuje fotometria dla zakresu red2

- czy występuje fotometria dla zakresu N (IR)

Przynajmniej 2 bity z pięciu końcowych są na "tak"

17. Następujące po statusie bity Ndet obrazują liczbę która powinna być równa ilości bitów statusu ustawionych na "tak". W rzeczywistości dotyczy to tylko ostatnich 5 bitów statusu i jest równe liczbie pakietów fotometrii.

18. Do odczytanych wartości RA i SPD wyrażonych w 0,01" należy dodać odczytany osobno dla każdego kawałka offset RA i SPD. Offset RA powinien jak wcześniej pisałem być wielokrotności liczby 2,9127(1) stopnia, Offset SPD wynika wprost z numeru pliku który jest jednocześnie dolną wartością SPD dla gwiazd pomnożoną przez 0,1 stopnia. Np. do odczytanej wartości SPD (w 0,01") z danych gwiazd z pliku U0900 należy dodać 900x0,1 = 90 stopni (od bieguna południowego) a więc są to gwiazdy na półkuli północnej o deklinacji w zakresie 0,0 do 0,1 stopnia.

19. Bity flagowe opisane zostały jako: USNO_PM + SPK + YS4. Podejrzewałem, że środkowy bit SPK to znacznik problemu pierwszego (obecności obiektów będącyh w rzeczywistości pikami i kołami wokół jasnych gwiazd na zdjęciach). Po pierwsze, porównując dane z plików USNO z danymi USNO w postaci rozszyfrowanej (dostępne w drobnych porcjach w internecie) SPK wystepuje na bicie trzecim a nie drugim a ponadto nie występuje wogóle w gwiazdach z pików i pierścieni. Tak więc nie wiem o co tu chodzi.

20. Pozostałe bity z zakresu podstawowego nie są dla mnie istotne.

21. Fotometria zawiera w sobie m.in. jasność w bitach (do których trzeba dodać offset z nagłówka pliku) okupujących pozycje: cały bajt trzeci i dwa bity czwartego w fotometrii 6 bajtowej (razem 10 bitów), lub 7 bitów bajtu 3-go i 6 bitów bajtu 4-go w fotometrii 7 bajtowej (razem 13 bitów)

22. Inne dane są raczej nieistotne.

Z tego wszystkiego najważniejszym chyba elementem jest długość danych gdy pierwszy bit danych (Tycho) jest na "tak". Wstawiona tu przeze mnie liczba 27 zazwyczaj się sprawdza, ale czasami rozsypuje całą strukturę (może długość danych tycho jest zmienna?). W sumie to mnie nie interesują dane Tycho bo je mam z innego katalogu, ale jeżeli w tych danych jest zawarta ich zmienna długość to interesuje mnie jaka ona jest. W opisie jest podane, że dane tycho składają się z 16 bajtów podstawowych zawierających numer oraz "Seq<0 (1bit), File Number (5bitów) Seq (18bitów)" ale co z 11 brakującymi bajtami (do 27).

Jeżeli ktoś potrafi rozszyfrować te zagadki, albo zna lokalizację niezmasakrowanych w powyższy sposób danych usno proszony jest o pomoc.

Edytowane 1 Maja 2007 przez Piotr Brych

sumas · 1 Maja 2007

Piotrze, zupełnie się na tym nie znam, ale może tu znajdziesz jakąś podpowiedź:

http://www.nofs.navy.mil/data/fchpix/usnob_format.html#b1 a tam to:

http://www.nofs.navy.mil/data/fchpix/2003.AJ.125.984.pdf

oprócz tego na tym ftp, z którego ściągaliśmy pliki tego katalogu, jest jeszcze taki folder:

http://badc.lamost.org/archives/cats/bincats/USNO_B1.0/bin/

a w nim plik: http://badc.lamost.org/archives/cats/binca...B1.0/bin/usnob1

a dla mnie to robaczki, ale w podglądzie notatnikiem, coś tam można znaleźć o strukturze danych

i czy to czytałeś: http://badc.lamost.org/archives/cats/binca...B1.0/src/ReadMe ?

pozdrowienia

teha · 1 Maja 2007

Piotrze,

Tak mnie zastanawia czy warto się bawić z takim ogromnym katalogiem.

Potrzebowałem danych z USNOB1. Podłączyłem się do Viziera, wybrałem kolumny, które mnie interesują i teraz zapodaję mu ra, dec, promień poszukiwań i ewentaulnie warunek na graniczny na magnitudo, a dane tak ograniczone w formacie csv ciągnę z sieci. Ściągnięte dane są cachowane lokalnie na HD.

Mam to napisane co prawda w javce, ale ten kawałek kodu jest bez problemu do przetłumaczenia na dowolny język, przez który można się podłączyć do neta przez http. W pascalu nie pisałem już z 15 lat, ale na pewno można się do też podłączyć.

Ma to wiele zalet. Przede wszystkim nie trzymam tak ogromnej bazy lokalnie. Dostaję sformatowane dane tylko te które chcę. Łatwe nakładanie kolejnych predykatów ograniczajacych zapytanie.

W ten sposób można podłączyć się nie tylko do USNOB1, ale także do ogromnej bazy katalogów dostępnych na vizierze zmieniając tylko postać URLa.

Wada tylko może być jedna. Trzeba mieć dostęp do neta. Oczywiście jest też pytanie o stabilnośc w czasie tego rozwiązania, jak vizier zmieni na przykłąd postać zapytań.

Wieczorem mogę wrzucić taki kawałek kodu.

pozdr

th

teha · 1 Maja 2007

jak powiedział tak zrobił,

w załączniku klaska w javce, która czyta z neta katalog USNOB1. Klaska nie jest zbyt produkcyjna, dla przejrzystości okrojona do minimum obsługa błędów, żadnych template'ów, interfejsów i takich innych, to nawet nie nazwałbym obiektowym programowaniem.

Trzeba do pascala przełożyć tylko otwarcie strumienia na podstawie URLa (zapewne coś takiego jest), a reszta jest chyba oczywista.

Co do utworzenia URLa.

Odpalamy stronę Viziera.

szukamy interesującego nas katalogu np. usnob1, ale może być np. Abell

pokazuje się strona wyszukiwarki USNOB1@vizier.

wprowadzamy format np. pałka-separated, ra, dec, możemy ściągnąć limit zwracanych obiektów domyslnie jest 50, wybieramy promień przeszukiwania, możemy dołożyć warunek na magnitudo na przykład.

i teraz w firefoxie mam jakiegoś plugina Live http Headers, włączam na nim monitoring i robię submit, w logu plugina odkłada sie pięknie URL zapytania, które można wkleić sobie do programu. tak można rozszerzyć sobie klaskę o nowe kolumny, warunki, ograniczenia,itp. W innych przeglądarkach też jest coś takiego.

W międzyczasie ściągnął się nam plik, który trzeba rozparsować.

W identyczny sposób działa np. CdC czy Aladin

można tak ciągnąć większośc innych katalogów z CDS, ale brakuje mi na vizierze np. aktualnego katalogu pgc 2006.

plik z kodem ma doklejone rozszerzenie ZIP, ale nie jest pakowany

powodzenia

th

CUSNOVizierReader.java.zip