mgala Napisał(a):
-------------------------------------------------------
>
> Od dawna marzy mi się, żeby KTJ zorganizował
> konferencję wraz z zainteresowanymi ośrodkami
> akademickimi, Ministerstwem Administracji i
> Cyfryzacji czy Ministerstwem Środowiska, na
> której ustalone zostałyby nowe standardy
> tworzenia dokumentacji jaskiniowej. Ale może
> bredzę.
Marcin,
Moim zdaniem świetny pomysł. Jeśli tylko chciałbyś taką konferencję zorganizować, KTJ jest gotów udzielić Ci pełnego poparcia. W ramach możliwości udzieli nawet wsparcia, tylko najpierw musisz nakreślić jakiś plan i potrzeby w tym zakresie.
Chociaż miałbym może sugestię, żeby zacząć od czegoś mniejszego, może najpierw tak naprawdę trzeba porządnie "rozeznać rynek" i ustalić na czym stoimy, jako środowisko. Może więc najpierw zorganizować seminarium, na którym Kiero coś powie o Wallsie i Corelu, Darek o Flashu i tabletach, ja o Survexie i Inkscape, Magda o CaveSniperze, Stahoo o Picos, a Miłosz trochę ponarzeka na dzisiejsze czasy. To już samo w sobie nie jest łatwe - trzeba paru ludzi przekonać, że warto przyjechać. Trzeba jakoś pokierować dyskusją, żeby nie szła w kierunku udowadniania wyższości jednego rozwiązania nad drugim.
Dopiero wtedy będziemy wiedzieli, od czego w ogóle możemy wyjść i co możemy zaproponować uczelniom i ministerstwom.
Podejmujesz temat?
... a poniżej moje trzy grosze w temacie formatów. Wypowiadam się całkowicie prywatnie.
> Sprawą niezbędną jest więc według mnie z
> formatów otwartych i dobrze udokumentowanych.
> Najlepiej tekstowych.
Marcin, co do zasady się zgadzam. Jeśli mamy wybór, to warto pomyśleć o przyszłych pokoleniach oraz archeologach z przyszłości, którzy będą próbowali rozgryźć o co chodziło w naszej cywilizacji i dlaczego myśmy do tych jaskiń wchodzili. Na pewno używając otwartych formatów możemy im ułatwić robotę. Jest to bardzo szlachetne.
Ale czasami nie mamy wyboru. Co nam po standardowym i otwartym formacie, jeśli nie mamy sensownych narzędzi, żeby z tego formatu korzystać...
Weźmy dla przykładu wizualizacje 3D. Jeśli miałbym przygotować je w KML, to chyba nie mam po prostu czym ich przeglądać? W jakim programie i jak sposób wygodnie sprawdzę, jak daleko jest do powierzchni?
> 1. skan oryginalnych notatek pomiarowych
> tutaj zaryzykowałbym pdf. głównie ze względu
> na możliwość zebrania wielu stron skanów w
> jeden.
Tu nie ma dużego problemu, bo gromadzenie notatek pomiarowych nie różni się zbytnio od gromadzenia jakichkolwiek innych dokumentów.
> 2. plik z wejściowymi danymi pomiarowymi
> niewątpliwie musi być to plik tekstowy.
> konwersja między różnymi formatami jest wtedy
> banalna.
Tak - zgoda, ale...
> Przez wiele lat w UIS był rozwijany CaveXML ( ).
> niemniej projekt został zarzucony. Głównie
> przez brak zrozumienia w środowisku.
... myślę, że to nie jedyna przyczyna. Myślę, że CaveXML z technicznego punktu widzenia jest złym pomysłem. Zabrakło pragmatyzmu.
W przypadku danych pomiarowych, XML wprowadza bardzo duży narzut. XML nie jest receptą na wszystko. Nikt rozsądny nie będzie tworzył formatów przechowywania zdjęć czy plików wideo w XML.
Naturalnym, czytelnym, będącym de facto standardem, tekstowym formatem przechowywania danych pomiarowych jest CSV (Character Separated Values). Co wymaga standaryzacji, to sposób opisu znaczenia poszczególnych kolumn, metadane (kto mierzył, czym mierzył, kiedy mierzył) i łączenie poszczególnych sesji pomiarowych. To tym powinien był zająć się UIS.
> 3. Zwektoryzowane plany i przekroje
> Możemy silić się na kurtuazję, ale .cdr czy
> .ai uniemożliwiają jakąkolwiek współpracę.
> Stawiałbym na nieskompresowany svg.
Wszystkie ogólne formaty grafiki wektorowej są złym rozwiązaniem. Mówimy tu o wyborze mniejszego zła.
Argument 1: O ile mi wiadomo, żaden z popularnych formatów nie przewiduje możliwości powiązania ze sobą obrysu korytarza czy znaków konwencjonalnych z konkretnym punktem ciągu pomiarowego. Tym samym, po zgodnym ze sztuką zamknięciu pętli (z rozproszeniem błędów), plan trzeba ręcznie edytować.
Argument 2: Kwestia przecinających się na planie korytarzy... na ogół, trzeba ją rozwiązywać ręcznie. Wymyślać i wprowadzać w czyn taki czy inny sposób przedstawienia sytuacji przestrzennej.
Odnoszę wrażenie, że wektoryzując plany w każdym dostępnym narzędziu trzeba stosować jakieś protezy. W takiej sytuacji chyba trudno jest wprowadzić jednolity standard. Nie twierdzę, że nie warto próbować - po prostu myślę, że będzie to trudne
> 4. Trójwymiarowe wizualizacje
> też musi być otwarty, tekstowy, optymalnie w
> xml.
Nie chcę tutaj się wymądrzać, bo nie jestem zbyt głęboko w temacie grafiki 3D. Ale coraz częściej korzysta się ze skanerów 3d w jaskiniach. Ciarki mnie przechodzą na myśl o zapisaniu miliona punktów i obliczonej z nich triangulacji w XML.
> 5. GIS
> Tutaj też mamy do czynienia z bitwą na
> standardy. Uważam, że należy wspierać otwarty
> .KML. .KMZ jest skompresowany zwykłym zipem i
> też jest godny polecenia. Uciekałbym od .shp
Może do rozważenia jest jeszcze GPX. "Sama nie wiem".
No i jeszcze jeden punkt.
0. Dane inwentarzowe o jaskini.
Tu właśnie jest miejsce do zastosowania XML.
Nawet zacząłem pracę w tym temacie. Luźno bazując na formacie wykorzystywanym przez CUCC napisałem taką schemę: [
pliki.jaszczur.org]
Mam na finiszu edytor/przeglądarkę do tej schemy w JavaScript-cie. To zresztą ciekawy pomysł podsunięty przez Brytyjczyków. Chodzi o to, żeby tę samą aplikację można było używać na bazie na dysku, bez Internetu, jak również z centralną bazą (np. wszystkie jaskinie Polski) z historią zmian i rozwiązywaniem konfliktów, dostępną przez Internet.
Paradoksalnie, Javascript (przy wykorzystaniu jQuery) wydaje się na dzień dzisiejszy najbardziej przenośnym pomiędzy platformami językiem programowania. Działa na Linuksie, pod Windowsem, jeśli użyć jQuery to działa tak samo pod IE, Firefoxem, Chrome. Działa także na iPhone i Androidzie. Ciągle jakoś trudno mi w to uwierzyć, ale faktycznie nie potrafię podać lepszego przykładu platformy.
Jedynym (poważnym) problemem jest brak możliwości wygodnego dostępu do lokalnych plików (np. listowanie katalogu).
Chcę tego użyć na najbliższych Chinach, ale jeszcze nie wiem, czy projekt osiągnie wystarczający stopień gotowości
m.
Zmieniany 1 raz/y. Ostatnio 2013-09-20 23:56 przez mteg.