Re: [Therion] Bounding Box to big in Loch but fine in Aven

2019-09-23 Thread Max D


> On 22. Sep 2019, at 23:28, Max D  wrote:
> 
> So I'm still searching.

Found it. Inside a th2 file there was a big scrap and a small one .
The small one contained no stations. Adding Stations fixed the lox bounding box.

Regards

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Bounding Box to big in Loch but fine in Aven

2019-09-22 Thread Max D


> On 20. Sep 2019, at 22:16, kevin dixon  wrote:
> 
> Is there a 0,0,0 origin coordinate in one of your files ?
> Are you using the same PROJ for all files ?

I'm not sure where to check. Searching vor "cs" I see "cs UTM32" all around - 
so same PROJ everywhere.
I also checked all my "fix" statements. 

In scraps I see 0,0 ana n origin like in this:

scrap s_aussen -scale [0 0 1600 0 0.0 0.0 40.64 0.0 m]

but to my understanding this should not matter.

So I'm still searching.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


[Therion] Bounding Box to big in Loch but fine in Aven

2019-09-20 Thread Max D
I have a somewhat big cave (2400 Stations) and since a few weeks Loch shows a 
huge bounding box of obout 250x7500 km (!) see 
http://filez.foxel.org/2c4512e8a235

Export is done like this:

 select m_all
 export model -output output/windloch.lox
 export model -format survex -output output/windloch-konstruktion.3d
 export model -format compass -output output/windloch.plt
 export model -format dxf -output output/windloch.dxf
 export model -format kml -output output/windloch-konstruktion.kml

survex Data is fine, PLT also (when viewed in Aven)

lox and dxf have the huge bounding box

kml seems to have only the surface survey and is missing the cave.


So far I have not been able to poin down the change that caused it. Any 
suggestions on how to hunt this error down?

Regards

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-05 Thread Max D


> On 5. Sep 2019, at 08:28, Olly Betts  wrote:
> 
>> On Fri, Aug 16, 2019 at 05:11:22AM +0200, MD wrote:
>> We also then to measure the same small loop at the beginning  of each trip: 
>> A-B in four device orientations
>> B-A in four device orientations
>> A-C in four device orientations
>> C-A in four device orientations
>> C-B once
>> 
>> So I could calculate an SD based on that. 
> 
> You probably don't want to work out a set of SDs per-trip -

Currently we set the SD per calibration - which works out to about every second 
trip. We Take the "Error stddev" from Topodroid Calibration Results - 
e.g.0.1058 in the attached Screenshot.

Thinking of it, this might be the wrong approach because it only considers the 
instrument.

> *sd tape 0.002 metres ; 2 millimetres
> *sd compass clino 0.5 degrees
> *sd position 0.05 metres ; 5 centimetres

Interesting. I will read up on the difference between tape and position

>> For sone Devices errors seem to be bound very much to orientation. In
>> the data saved by TopoDroid you can see the device orientation and so
>> we could set a sd based on the direction in which the shot was taken.
>> I have nit investigated this further so far. Also because we have this
>> data only for about 20% of the cave.
> 
> This is already taken into account - you tell Survex the SD for the
> "tape" (read laser range-finder), "compass" and "clino" (read magnetic
> field measuring devices) and position (how close to the station you
> actually measure from) and it uses the direction of the leg to produce
> a 3D set of expected errors, which are then summed along each traverse.

But I would need a extra set SD data per device orientation. 
So I know that if the display is to the right the Disto tends to reassure an 
Azimuth 2 degrees to high and if the display is to the left.
And when the display is to the left it tends to give an Azimuth 1 degree to low.

But perhaps I just should try to do more and better calibrations instead of 
fixing stuff afterwards.


>> TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally
>> sure how but this als could be used in setting a per shot SD. i have
>> not looked much into this.
> 
> I think you want to treat that as an in-cave indication that you should
> check for sources of magnetic interference and redo affected readings.

Good Advice!

Thanks!

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Display Station comments on Map?

2019-09-03 Thread Max D


> On 3. Sep 2019, at 22:32, Bruce Mutton  wrote:
> 
> Hmm, I have not time to look into this, don't really understand much about 
> metapost at all, but my recollection is that I could get all the features 
> implied in the code of the original p_station to manifest in outputs (at 
> least of centrelines, if not scraps).  If you have removed code, then I 
> suggest others look very carefully before this is committed.
> Although looking at your diff, it seem like you have taken little if anything 
> out, so maybe my concern is unfounded?

This certainly should not be committed.

* I removed the "is this flag defined in this symbol set" check
* I also changed the calling convention for p_station 

So this is definitively only Proof of Concept.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Display Station comments on Map?

2019-09-03 Thread Max D


> On 3. Sep 2019, at 14:35, Max D  wrote:
> 
> To me it seems that the "flags" parameter in therion 5.4.4+b998d1b 
> (2019-06-12) is always empty.
> Not sure if this is a bug or if I'm missing something. The p_station_SKBB() 
> macro has a lot of code for handling different flags which seems to be unused.
> 

I produced a patch for therion which makes it display all flags for "station" 
entries. I'm not very firm with MetaPost and Therion internal structures, but 
it seems to me, the original code simply could not work. OR I just did not 
understand.

The patch is at.
https://gist.github.com/mdornseif/3b3764844cae2f6274726674a9c68a0f

https://tug.org/pipermail/metapost/2006-February/000527.html helped me to 
understand what is going on in MetaPost.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Display Station comments on Map?

2019-09-03 Thread Max D


> On 2. Sep 2019, at 21:25, Bruce Mutton  wrote:
> 
> Max
> Does this start to solve your problem?
> ...
> I use this always to show only fixed or painted station symbols, but I don't 
> think I have ever had luck with combined control of both underground and 
> surface stations.

Thanks for the Pointers. I think Therion data structures  has no concept of 
"surface stations" - only shots have that attached. But I might be wrong.

I'm still fiddeling, but this is enough to display station comments:

layyout showcomments
code metapost
def p_station(expr pos,mark,txt)(text flags) =
p_station_SKBB(pos,mark,txt,flags)
T:=identity shifted pos;
if picture(txt):
p_smartlabel(txt,pos);
fi;
enddef;
endcode
endlayout

To me it seems that the "flags" parameter in therion 5.4.4+b998d1b (2019-06-12) 
is always empty.
Not sure if this is a bug or if I'm missing something. The p_station_SKBB() 
macro has a lot of code for handling different flags which seems to be unused.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


[Therion] Display Station comments on Map?

2019-09-02 Thread Max D
Hello,

I have Stations like this in a survey:

fix wiesenponor 391349.0 5650631.0 154
station wiesenponor "Wiesenponor" sink
fix quelleinderagger 391952.0 5650078.0 125
station quelleinderagger "Quelle in der Agger" spring
fix aggertalhoehle 391124 5650259 150
station aggertalhoehle "Aggertalhöhle" entrance 
fix gipfel 391528 5650356 254.3
station gipfel "Gipfel Mühlenberg" 

Is there a way to display Icons for these (but not for all stations) and the 
Comments (e.g. "Gipfel Mühlenberg") in the map without creating a scrap and 
retyping them there? I checked the MetaPost files and found no obvious way to 
enable that.

Regards

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-20 Thread Max D


> On 20. Aug 2019, at 11:21, Max D  wrote:
> 
>> 
>> On 20. Aug 2019, at 11:15, Bruce Mutton  wrote:
>> 
>> Survex loop closure seems to be fed arbitrary station names 
> 
> Maybe be we can ask Therion to dump a mapping between svx station names and 
> it's own names. 

We can!

1. Ensure that you generate an SQL export in your thcondig: 
export database -format sql -output mycave.sql

2. load the data in SQLite (it comes preinstallted on MAc and most Linux boxes):
rm -f cave.db
sqlite3 mycave.db < /mycave.sql

3. extract the data you want:


sqlite3 mycave.db 
.headers on
SELECT s.ID as sid, (s.NAME || '@' || su.NAME) AS station FROM STATION s LEFT 
OUTER JOIN SURVEY su ON s.SURVEY_ID=su.ID where s.NAME not in ('-', '.') order 
by sid;
.mode tabs
.output stations.tsv
SELECT s.ID as sid, (s.NAME || '@' || su.NAME) AS station FROM STATION s LEFT 
OUTER JOIN SURVEY su ON s.SURVEY_ID=su.ID where s.NAME not in ('-', '.') order 
by sid;
.quit

The file ' stations.tsv' should now contain the desired mapping. IT looks like 
this:

sid station
1   1.0@g1
2   1.1@g1
3   1.2@g1

If you have much deeper nested surveys the code could be extended to resolve 
them. For me one level is enough to know what was meant by the station name.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-20 Thread Max D


> On 20. Aug 2019, at 11:15, Bruce Mutton  wrote:
> 
> Survex loop closure seems to be fed arbitrary station names 

Maybe be we can ask Therion to dump a mapping between svx station names and 
it's own names. Something like this but for all stations:


therion.log
…
### cavern log file 
 1> Survex 1.2.27
 2> Copyright © 1990-2016 Olly Betts
…
13> Vertical range = 77.55m (from 11088 at 202.55m to 10918 at 125.00m)
14> North-South range = 651.00m (from 10917 at 5650639.00m to 10918 at 
5649988.00m)
15> East-West range = 630.39m (from 10918 at 391931.00m to 43 at 391300.61m)
… # transcription 
13> 11088 : C@g28aussen.aussen -- 10918 : B@virtuelle_verbindungen.aussen
14> 10917 : A@virtuelle_verbindungen.aussen -- 10918 : 
B@virtuelle_verbindungen.aussen
15> 10918 : B@virtuelle_verbindungen.aussen -- 43 : 2_14s1@g2.windloch2019
…
 end of cavern log file 

but for all stations.

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Different Color for Rocks?

2019-06-25 Thread Max D


> On 24. Jun 2019, at 12:00, therion-requ...@speleo.sk wrote:
> 
> BTW, what is the PDF viewer the screenshot from you sent?

It is Apple default "Preview" (PDFKit).

Bruce, thanks for the Pointer!

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


[Therion] Different Color for Rocks?

2019-06-23 Thread Max D
Currently if I have a closed `rock-border` the contents (the rock) will be 
drawn slightly darker than the passage fill due to transparency and this area 
being painted twice - see http://filez.foxel.org/e817c23fd65d

Is it possible to fill rocks with an other color than the  passage fill color?

Best regards

--max

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion