Import pdf-a powoduje, że wszystko zapisuje się do jednej warstwy. Poza tym w Inkscape na raz można zaimportować tylko 1 stronę projektu (nie znalazłem sposobu na import całości).
Z plikiem dwg kiedyś próbowałem (przy próbie przejścia na Illustratora) i niestety też się krzaczyło.

Te wszystkie problemy z niestandaryzowanymi formatami (oficjalnie są standardowe) to celowa praktyka producentów oprogramowania, która niejako zmusza do "lojalności" Dlatego też tak trudno się przestawić do pracy w innym środowisku, zbyt dużo problemów, żal czasu na ich rozwiązywanie.

- Jak Pan myśli, co w dzisiejszych czasach jest większym problemem: niewiedza, czy obojętność?
- Nie wiem, nie obchodzi mnie to.

Inkscape 0.48.4 r9939 u mnie otwiera Corela 12 i 13 bez problemu. No ale tracimy podział warstw.

hern Napisał(a):
-------------------------------------------------------
> Inkscape 0.48.4 r9939 u mnie otwiera Corela 12 i
> 13 bez problemu. No ale tracimy podział warstw.

Łał. No mnie się to nigdy skutecznie nie udało Ale nie miałem też nigdy dużej determinacji (dużej potrzeby).

Jest jeszcze deweloperska wersja Inkscape. "Release highlights: (...) Improved support for Corel DRAW documents, Visio importer" (vide [wiki.inkscape.org]). Niestety jest mniej stabilna. Udało mi się ją zawiesić w ciągu 10 minut zabawy. Ale czekam z niecierpliwością co z nią będzie dalej, bo ma nareszcie całkiem wygodną funkcję "bibliotek symboli".

A co do celowego utrudniania przenoszenia danych przez producentów oprogramowania, to firma Corel chyba jest w czołówce tego sportu. Format CDR jest zamknięty. Nie ma oficjalnej specyfikacji, więc nawet oficjalnie nie jest to standardowy format. Jeśli chodzi o Adobe i format Photoshopa (PSD), to Adobe udostępnia publicznie specyfikację (http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/). Może aż tak bardzo rysowania jaskiń to nie dotyczy, no ale jest to zgoła inne podejście... A format PDF w wersji 1.7 stał się standardem ISO. Także z dwojga złego chyba wolę tych.

Pozdrowienia!
m.

akurat Inkscape jest od ciebie od czasu warsztatów z kartowania może kwestia zapisania plików CDR w odpowiednio "starej" wersji?

Michał



Zmieniany 1 raz/y. Ostatnio 2013-09-19 09:49 przez hern.

No tak, na siłę się da, ale utrata podziału na warstwy i wrzucenie wszystkiego do jednej powoduje taki chaos w projekcie, że mnie to nie przekonuje.


- Jak Pan myśli, co w dzisiejszych czasach jest większym problemem: niewiedza, czy obojętność?
- Nie wiem, nie obchodzi mnie to.

no wrzucenie wielkiego projektu z Corela na Inkscape to nie ma za bardzo sensu. Ale rysownie od początku - ja nie narzekam.

Oczywiście narzędzie jest tylko narzędziem. Nie ma znaczenia w czym rysujemy. Jednak standaryzacja zapisu danych jest sprawą niezbędną. Prędzej czy później każdy mierzy się z problemem wymiany danych.

Formaty przemijają. Pewnie i wam się zdarzyło, że próbowaliście otworzyć jakiś plik utworzony 10 lat temu. I okazało się, że nie ma już narzędzi, którymi dało by się go otworzyć.

Sprawą niezbędną jest więc według mnie z formatów otwartych i dobrze udokumentowanych. Najlepiej tekstowych.

Śledząc workflow procesu tworzenia dokumentacji jaskiniowej możemy sobie wyróżnić następujące dokumenty wymagające ustandaryzowanych formatów.

1. skan oryginalnych notatek pomiarowych
tutaj zaryzykowałbym pdf. głównie ze względu na możliwość zebrania wielu stron skanów w jeden.

2. plik z wejściowymi danymi pomiarowymi
niewątpliwie musi być to plik tekstowy. konwersja między różnymi formatami jest wtedy banalna.
Przez wiele lat w UIS był rozwijany CaveXML ( [www.cavexml.uis-speleo.org]). Według mnie był to strzał w dziesiątkę, niemniej projekt został zarzucony. Głównie przez brak zrozumienia w środowisku.

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. Można go sobie zmodyfikować choćby i w notatniku. Jest wspierany przez większość przeglądarek. Jego najpoważniejszą wadą jest brak warstw, jednak można je emulować obiektami, tak jak to się dzieje w inkscape.
Do publikacji póki co sugeruję pdf. Eksportując można zachować warstwy, co prawda bez możliwości zagnieżdżania, ale jednak. Oddzielnym tematem pozostaje standaryzacja nazewnictwa warstw.

4. Trójwymiarowe wizualizacje
też musi być otwarty, tekstowy, optymalnie w xml. Póki co pewnie (nieskompresowane) vrml i x3d. A może jednak KML.

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

Standaryzacja jest nam niezbędna na wielu polach. To samo dotyczy wyboru układu mapy, formatu współrzędnych, tabeli pomiarowych, baz danych. I nie chodzi o to, żeby jedna grupa narzuciła swój sposób pracy innej grupie. Standaryzacja nie oznacza przymusu stosowania rozwiązań.

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ę.

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.

> ... Miłosz
> trochę ponarzeka na dzisiejsze czasy. ...

Och, czy to nie za wielki zaszczyt być wymienionym w tak znamienitym gronie.
No, jak zostałem wywołany do tablicy; nieważne jak, najważniejsze by robić porządnie. Jak na razie cała dokumentacja i tak ląduje na starym dobrym papierze i do tego musimy się dostosować.
Oczywiście rozwój technik pomiarowych i informatycznych powoduje, że produkujemy masy danych nie do opanowania metodami pradziadków. Tutaj rzeczywiście konieczne są standardy i to zanim wyprodukujemy masy specyficznych danych.

mgala Napisał(a):
-------------------------------------------------------
.... Stawiałbym na nieskompresowany svg. Można go sobie zmodyfikować choćby i w notatniku. Jest wspierany przez większość przeglądarek. Jego najpoważniejszą wadą jest brak warstw, jednak
> można je emulować obiektami, tak jak to się
> dzieje w inkscape...

Jak dla mnie brak podziału na warstwy jest mało praktyczny. Osobiście lubię mieć porządek w projekcie. Bardzo się on przydaje w przypadku poprawek, zmian, rozbudowywania. Jeśli jest inny sposób na uporządkowanie wielkiego zbioru wektorów to chętnie "posłucham". Niestety nie za bardzo wiem co masz na myśli pisząc "emulować obiektami" Możesz to rozwinąć?

mteg Napisał(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ć.

Z tego co pamiętam to Therion sobie z tym radzi. Przy czym obsługa tego programu nie należy do najłatwiejszych.


> 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.

W tym przypadku również Therion ma świetny sposób przedstawiania tego na planie, bez konieczności tworzenia "okienek"

Co do "wielkich" spotkań to planujemy już je odkąd pamiętam, że chodzę po jaskiniach. Oczywiście trzeba wierzyć że kiedyś "to się musi udać" ale proponowałbym bardziej skupić się na merytorycznej dyskusji na forum. Przynajmniej zostanie po tym jakiś ślad i dostęp do tych danych będzie dla wszystkich a nie tylko uczestników seminarium.



- Jak Pan myśli, co w dzisiejszych czasach jest większym problemem: niewiedza, czy obojętność?
- Nie wiem, nie obchodzi mnie to.