Witam, przerzucamy pomiary wyprawowe do Survexa

Mamy 2 jaskinie - znane współrzędne otworów + stworzona mapa ukształtowania terenu.

Składnia naszego pliku svx:

*begin Rejon
*include Belic\Belic.svx

*include 03_111_Jaskinia_Kolektor\03_111_Jaskinia_Kolektor.svx
*include 03_141_Jaskinia_Malej_Wielkiej_Burzy\03_141_Jaskinia_Malej_Wielkiej_Burzy.svx
*end Rejon

gdzie Belix.svx -> mapa terenu
oraz 2 ciągi pomiarowe 2 jaskiń.


Nie udaje się nam wyświetlić 2 jaskiń jednocześnie. Po skasowaniu jednej bądź drugiej jaskini bez problemu udaje się skompilować plik i wyświetlić ciąg jaskiniowy na tle mapy.

pozdrawiam

Michał

Michał, nie znam dobrze Survexa, ale sprawdź czy macie różne nazwy punków pomiarowych w każdej z jaskiń. W wallsie jest tak, ze jeśli w całym projekcie pojawią się 2 takie same nr pkt. pomiarowych to program się "krzaczy". Dlatego też wprowadza się prefixy. Sprawdź, może to ten sam problem.

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

problem rozwiązany - składnia w pliku jednej sesji pomiarowej musiała coś psuć. Teraz działa.

pytanie dla znawców - kiedy używamy polecenia *export

Nie używamy nigdzie, o ile w głownym pliku wpiszemy "*infer exports on"

Poważniej: polecenie "*export" ma zastosowanie razem z poleceniem "*equate" w momencie, kiedy chcemy połączyć ze sobą dwa pliki wspólnymi punktami.

Polecenie *equate mówi Survexowi, że dwa punkty pomiarowe należy traktować jako fizycznie zupełnie identyczne. Poleceniem *export trzeba zaznaczyć wszystkie punkty, które będą używane do łączenia.

Myślę, że najlepiej sprawę pokaże przykład. Otóż katalog 49H/G2/017_LuoShuiKong zawiera u nas wszystko, co w sensie pomiarowym wiemy o jaskini 49H-G2-017, w szczególności plik 017.svx, a w nim:

Cytat:

*begin 49H-G2-017
*include faud/faud.svx
*include gabki/gabki.svx
*include syfoniki/syfoniki.svx
*include nutella/nutella.svx
*include galery/galery.svx
*include wichry/wichry.svx
*include faudSyfon/faudSyfon.svx

*equate faud.1_0 faudSyfon.1_0
*equate gabki.3_4 syfoniki.4_0
*equate gabki.3_9 faud.1_7
*equate gabki.1_19 nutella.1_21
*equate nutella.1_14 galery.1_0
*equate syfoniki.4_10 wichry.1_0
*end 49H-G2-017

Akcje pomiarowe są nazywane słowami kluczowymi. W zależności od tego, czy jaskinie mierzą romantycy czy pragmatycy, akcje nazywają się tak jak wyżej (faud, nutella, galery), jeszcze bardziej niezrozumiale np. 20131103_MC_EW albo nawet jeszcze gorzej - a, b, c, d. Tak czy siak, nic nie szkodzi - ważne, żeby nazwy były unikalne w skali jaskini. Każda akcja pomiarowa ma swój podkatalog. W nim trzymamy wszystko, co wyszło z tej akcji: plik .top z PocketTopo, skonwertowany z niego plik .the, skonwertowany z pliku .the plik .svx itd. W przypadku akcji papierowych ładujemy do katalogu akcji również skany rysunków.

Przykładowo, plik syfoniki/syfoniki.svx zawiera:

Cytat:

*begin syfoniki
*export 4_0 4_10
*data normal from to compass clino tape
4_1 4_0 206.34 13.74 7.798
4_2 4_1 98.97 -33.84 3.868
4_3 4_2 197.73 -4.39 8.907
4_4 4_3 228.27 24.18 7.387
4_5 4_4 115.76 37.2 3.128
5_0 4_5 247.33 18.05 4.912
4_6 4_5 64.86 -3.15 5.67
4_7 4_6 157.88 -25.42 6.441
4_8 4_7 63.03 -16.11 2.587
4_9 4_8 122.86 -1.55 1.813
4_10 4_9 25.54 -86.43 1.6
*end syfoniki

Zaś plik wichry/wichry.svx:

Cytat:

*begin wichry
*export 1_0
*data normal from to compass clino tape
1_0 1_1 302.53 13.62 3.071
1_1 1_2 310.63 -42.12 0.325
1_2 1_3 293.5 -13.95 1.958
1_3 1_4 172.28 2.29 2.429
1_4 1_5 168.74 -35.35 2.373
1_5 1_6 171.2 4.94 3.47
1_6 1_7 198.53 -14.46 2.635
1_7 1_8 119.8 -11.79 2.987
1_8 1_9 45.42 -1.74 3.548
1_9 1_10 47.35 -13.2 4.279
1_10 1_11 92.31 -17.26 5.096
1_11 1_12 77.4 2.25 2.83
2_0 1_1 220.39 -61.72 2.003
2_0 2_1 357.9 24.62 3.572
2_1 2_2 22.79 10.61 2.411
2_2 2_3 356.28 28.17 2.745
(...)
*end wichry

Polecenie "*equate syfoniki.4_10 wichry.1_0" informuje Survex'a, że punkt 4_10 z pomiaru syfoniki to jest fizycznie ten sam punkt, co punkt 1_0 z pomiaru wichry.

Mam świadomość, że dla niektórych konserwatystów może być nie do zaakceptowania fakt, że jeden punkt pomiarowy jest oznaczony paroma numerami, w każdym razie Survex/PocketTopo na coś takiego pozwalają, choć nie ma obowiązku

To dzięki serii poleceń *equate, Survex wie, jak połączyć ze sobą ciągi z poszczególnych akcji. Bez tych paru *equate plik 017.svx w ogóle by się nie skompilował, bo nie byłoby wiadomo co z czym się wiąże. Trzeba pamiętać, że w Survex'ie łączenie ciągów NIE odbywa się na podstawie "rozpoznania identycznych nazw punktów". Survex bardzo silnie trzyma się hierarchii nazewnictwa punktów. Przykładowo, "shizilu.017.wichry.1_0" to zupełnie inny punkt niż "shizilu.017.faud.1_0", nie mówiąc już o "shizilu.020.nakolana.1_0", który jest w ogóle w innej jaskini.

Wracając do zasadniczego pytania, to moim zdaniem, w typowych przypadkach szkoda czasu na używanie *export. Lepiej w głównym pliku (w tym wypadku 017.svx) wpisać "*infer exports on", co powoduje w pewnym sensie automatyczny "*export" wszystkich punktów z wszystkich plików. Długo się z tym męczyłem (komunikaty o błędach: *equate użyte na punktach, które nie zostały wcześniej wy*export-owane), ale w końcu Furek znalazł w instrukcji ten trik z *infer

--
mteg



Zmieniany 3 raz/y. Ostatnio 2013-11-18 07:54 przez mteg.

Jak wygląda sprawa z zamykaniem pętli przez Survexa? Robiąc sobie przykładowy plik pomiarowy z poligonem zamkniętym:

*data normal from to tape compass clino
0 1 10 90 0
1 2 10 180 0
2 3 10 270 0
3 0 10 0 -10

z zamierzonym błędem Survex zamyka mi pętlę i rozkłada błąd na wszystkie kąty i wszystkie długości. Czy ma się wpływ na to jak program zamyka daną pętlę i czy informuje o % błędu?

Informacje o skali błędu w pętlach są zapisywane w pliku .err w momencie kompilowania. To jest tekstowy raport, wystarczy otworzyć go w czymkolwiek, np. Notatniku.

Co do wpływu - nie wiem. Chyba nie

m.

ok teraz już wszystko jasne

dzięki

pozdrawiam

Michał