from:"Benedikt Hallinger"

Great, that works as intended!
Thank you very much!

Am 2021-11-23 21:35, schrieb Martin Budaj:

On Tue, Nov 23, 2021 at 4:34 PM Tarquin Wilton-Jones via Therion
 wrote:

> In which variable do i access the page's background color (the one set
> wit the layout option "map-bg")?

Fun fact ... you can't access that. Or at least, it didn't seem to be
available back when I was trying to do that in version 5. And I still
can't see any useful variable in version 6.

Hi,

it's now set as MapBackground in the latest commit.

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

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

Re: [Therion] Fwd: PDF output: layers nested?


Hi,
no, i really have submaps in my example.
mymap in my case is defined in my thconfig file, and it references a 
mainmap as submap.
That submap again is a collection of other submaps, that finally contain 
scraps:



-
source
  map 164-Grundriss -title "Mappe 164: Wandaugenlabyrinth Ost"

#preview above 172-Hauptplan@172.Wandaugenlabyrinth.Hirlatzhoehle
preview above 162-Hauptplan@162.Wandaugenlabyrinth.Hirlatzhoehle
preview above 180-Hauptplan@180.Wandaugenlabyrinth.Hirlatzhoehle
preview above 170-Hauptplan@170.Wandaugenlabyrinth.Hirlatzhoehle
preview above 171-Hauptplan@171.Wandaugenlabyrinth.Hirlatzhoehle

164-Hauptplan@164.Wandaugenlabyrinth.Hirlatzhoehle #<-- this 
contains several other maps, which finally contain scraps


  endmap
endsource




select 164-Grundriss -map-level 2
This works, but removes the previews (from 164-Grundriss) and also the 
offsets defined in 164-Hauptplan.
I also tried "select 164-Grundriss -map-level basic" with the same 
result.





Am 2021-11-23 17:01, schrieb Andrew Atkinson:

On 23/11/2021 15:49, Benedikt Hallinger wrote:
es, exactly, when i use "select" and fetch the maps that way, it 
generates layers as expected.
However, in this instance i just have one big "map" element, but it 
would be nice if i could have the submaps also as distinct layers.


With a map definition in th file

map mymap
 map1
 map2
 map3
endmap

then in thconfig

select mymap

should give you map1, map2.. as leyers in pdf

if you also have in a th file

map map1
 mapA
 mapB
 mapC
endmap

select mymap -maplevel 2

should give you layers of mapA, mapB...

In your example you had scraps, I don't think the map-level works on
scraps. If I have a survey with a single survey I always make it into
a map, I find this makes things easier in the end. I also do this if
In have many scraps that I want on several layers

map SingleScrap
 SingleScrapA
endmap

(I have no idea why scraps cannot just be treated as maps, it's
probably something to do with the coding, however it is easy to just
turn them into maps, I've not found any downside, well apart from a
little more typing and a larger map tree)

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

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

Re: [Therion] Fwd: PDF output: layers nested?

Yes, exactly, when i use "select" and fetch the maps that way, it 
generates layers as expected.
However, in this instance i just have one big "map" element, but it 
would be nice if i could have the submaps also as distinct layers.


Am 2021-11-23 16:41, schrieb Andrew Atkinson:

On 23/11/2021 15:08, Benedikt Hallinger wrote:

I don't know PDF specifics, but it would be very handy to have 
"nested" layers, i.e. submaps as separate layers in the main layer.


That would be very useful, don't know if it is possible


If sublayersa re not possible, it would be cool to have an optional 
option at the export config command to instruct therion to not collate 
submaps into a bigger layer, but add each map as independent layer.



If I understand correctly what you are after I think what you maybe
looking for are the options used with select. I used -map-level 2 to
get what you describe.


Other options are

recursive  and  chapter-level 

I cannot say I really understand these fully, however trial and error
got me there

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

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

[Therion] thfill with page background colour?


Hi metapost wizards,

I try to fill a label with the page background.
  thfill ((bbox lab)) scaled (sc * basescale * 1.5) withcolor 
;


For  i tried "label_fill_color", which however may be a 
different background.
I also tried "background", but that yields the cave passage background 
colour.


In which variable do i access the page's background color (the one set 
wit the layout option "map-bg")?



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

Re: [Therion] Existing xvi background images not visible in XTherion Map Editor, insertion causes error

2021-09-17 Thread Benedikt Hallinger


This is really a fine piece of software and a good project.
Thank you all for all the ongoing effort over all those years!


btw. my mapping project of the hirlatz cave is approaching to cross the 
70km mark soon :)



Am 2021-09-17 8:42, schrieb Bruce Mutton:

thanks a lot for finding out and reporting.


Introducing “Rob Davies”.  After a quick spin through, it looks
like 23b301e is working.

Thanks for the speedy turnaround Stacho.

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

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

Re: [Therion] How to morph sketches

2021-06-27 Thread Benedikt Hallinger

What is the advantage of digitizing a morphed sketch over just let therion 
morph the raw digitized sketch?

I usually just digitize the raw paper sketch and get good results.

> Am 27.06.2021 um 12:43 schrieb Torsten Schnitter via Therion 
> :
> 
> 
> Hi
> 
> As I read some of the last mails I came to the question how to morph a 
> sketch. 
> I searched the wiki and the Therion book but could not find how to do it. 
> All I found was on page 89 ff in the book which shows some pictures before 
> and after morphing.
> But no explanation how to do it in detail. 
> 
> If I got it right it is possible like that: 
> Someone have an image, a sketch of a cave area (which is not orientated 
> correctly at all). 
> And you have some survey data from that passage (which should be correct). 
> The sketch is scanned to a png or jpg file. 
> Now you can morph this image file into a xvi file where the image is morphed 
> to the correct orientation matching the messured survey data. 
> The final result is a new xvi file (with correctly morphed) image inside so 
> you can use this new xvi file (including survey data as a line and the 
> correctly morphed sketch itself) as a background image to draw the final 
> scrap. 
> Or did I get this wrong? 
> 
> Can anyone describe in detail how to do this please!?
> Apparently I'm too stupid to make it... 
> I put a sketch and the survey data from a small passage to this email as a 
> possible example to show how this process does work.
> Many thanks in advance. 
> 
> regards, 
> Torsten 
> 
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

2021-06-13 Thread Benedikt Hallinger

Another idea would be to have an -constraint option, that can appear multiple 
times let therion avoid certain passages for the route calculation, like 
passage height or crossing of a pit; much like avoiding toll roads in a car 
navigation unit

> Am 13.06.2021 um 21:49 schrieb Bruce Mutton :
> 
> 
>> 
>> I would have thought the easier way would be a "flags" switch that could do 
>> it for you. "flags mainroute". It wouldn't even be an estimate. Maybe some 
>> of the Survex folks on this list could shed some light on how feasible that 
>> would be. Might require a Survex modification though.
> ___
> 
> How about as a concept?
> 
> route  
> 
> where you can define one or more named routes in the survey network by 
> setting a name then a list of two or more stations that Therion then 
> consecutively finds the cumulative shortest surveyed route between.  Maybe it 
> could tack on to the loop detection routine.
> 
> Therion could then export these as a table in cave-list or survey-list, or it 
> could be its own 'route-list'.  Statistics could include total length, 
> altitude gain and loss, altitude range, altitude difference.
> A debug option could enumerate every survey station along the route Therion 
> has chosen.
> For visualising would need to highlight the route Therion has chosen in Aven 
> or in Loch.
> 
> Bruce
> 
> 
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

2021-06-13 Thread Benedikt Hallinger

Hi,
We might also differentiate the route finding symbols into two line types: one 
for the main junctions and one for the route in between. This way we can select 
if we just want to show the main junctions or all the route.

Is there a way of defining custom symbol groups? This way we might create our 
own to really hide all the routing symbols at once.

> Am 13.06.2021 um 10:28 schrieb Axel :
> 
> 
> Morning,
> 
> we experiment with a custom line (bold, dashed line in purple). It gives the 
> advantage that the complete mainroute can be hidden easily (if the issue with 
> context line:u is solved, labels can be assignet to it as well -eg for time 
> of travell between camps).
> But discussion is on if we use it all the way or just at main junctions.
> All the way makes it easier to use the map in the cave as it draws ones 
> attention directly to the route (+ u can show where the path is in big 
> chambers and it looks coherent in the survey). However it looks odd in long 
> galleries with no junctions...
> To have the lines/arrows just at junctions also looks odd in the survey (at 
> least that's my impression) but I wanted to experiment with the 
> pencile-pressure lines which where posted here a while ago and see if that 
> looks better... (has one of u used them so far?)
>  
> cheers,
> Axel
>  
> Gesendet: Sonntag, 13. Juni 2021 um 09:49 Uhr
> Von: "Tarquin Wilton-Jones via Therion" 
> An: "Therion" 
> Cc: "Tarquin Wilton-Jones" 
> Betreff: [Therion] Main route through a cave
> Hi folks,
> 
> I am surveying a cave that could be best described as an insanity of
> hidden routes.
> 
> When you go through the cave, it feels easy. You follow the obvious route.
> 
> When drawing up the survey, there are loads of alternative routes all
> crossing over each other and hiding underneath the floor. This means
> that the survey is harder to navigate than the cave itself.
> 
> I was wondering what the general ideas were that people use to
> counteract this situation. These are what I could come up with:
> 
> 1. Fail to draw all the passages (GAH!).
> 
> 2. Draw the walls of the main route with different line types? like
> subtype "underlying" and "overlying" instead of regular walls (useless
> if you are trying to use "subtype blocks" which is my specific problem;
> the passage is a mess of boulders and ceiling steps creating false walls).
> 
> 3. Arrows.
> 
> But does anyone have a dedicated, better approach? Some way of shading
> the main route differently? A dedicated symbol?
> 
> Cheers,
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] therionsurfac2survex now also on mac!

2021-04-21 Thread Benedikt Hallinger


Hi,
just wanted to drop a note that I just managed to compile the 
therionsurfac2survex tool also for mac now.
You can use it to generate a surface mesh (legs with -flag surface) out 
of GDAL or therion surface files.
This is useful if you for example want to measure distances from cave to 
surface with the help of aven.


I updated the latest release with the binary:
https://github.com/hbeni/therionsurface2survex/releases/tag/1.1.0

Have fun, and let me know if it works,
Beni
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Symbol-hide and user defined symbols ?

2021-03-09 Thread Benedikt Hallinger


See here: https://github.com/therion/therion/issues/239

Am 2021-03-09 11:41, schrieb Xavier Robert:

Hello,

For my Therion’s projects, I wrote a global config file (Config.thc)
where I defined all the user defined symbols. In my thconfigs, I call
this config file at the beginning of the file with input config.thc.
In the layouts, I call the layouts of the config.thc that I want to
use with for instance copy drawingconfig.

In one of my thconfig, I would like to hide some of these symbols that
I have defined in the config file and drawn in a survey. For that, I
used in a layout, for instance, symbol-hide point u:symbol_plan (in my
config.thc in the layout drawingconfig, I defined the point
p_u_symbol_plan as proposed by Juraj Halama).

When I compile (with c43b32a), it crashes with this error : -- unknown
symbol specification -- point u:symbol_plan

Is it because symbol-hide cannot take in account user defined symbols
?
Is it because I misunderstood the syntax of this command for user
defined symbols ?
Is-it a bug ?

Cheers,

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

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

[Therion] therionsurface2survex can flip grids now

2021-03-01 Thread Benedikt Hallinger

Hello, 
as some of you already know, the therionsurface2survex tool can generate 
surface meshes for aven out of therion surface or gdal grids. This allows for 
example to display a 3d-grid in loch and aven, and to take measures between 
cave and surface in aven.

Today i enhanced the tool so it can understand the grid-flip command: 
https://github.com/hbeni/therionsurface2survex/issues/2#issuecomment-787776692
Also negative step size in gdal headers yield flipped grids.

It would be cool if some people here could test it with real datasets :)
The test case does what i would expect, but I’m not sure i fully understood the 
input data and its implications.
Before i merge the feature, i would be much more confident by test results from 
more proficient people than me.

Thanks and greetings!
Beni___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Question about "grid" command

2021-02-24 Thread Benedikt Hallinger

So, after reading the thbook (p. 31) again, I think I can answer that to 
myself.

But it would be good if someone could step in and confirm:


 

may be negative, depending in used CS.


   

Is not allowed to be negative:
- origin is always lower-left (southwest) corner, and spacing is assumed 
to be from west to east and south to north, thus always positive.

row and cols count cannot be zero or negative for obvious reasons.


Stay safe!
kind regards, Beni


Am 2021-02-24 8:18, schrieb Benedikt Hallinger:

Good morning,
while debugging
https://github.com/hbeni/therionsurface2survex/issues/1 i stumbled
upon a format question i did not give tought until yesterday.

With the "grid" command you specify coordinate origin and size of a
surface grid:
  grid  count>



Until now i assumed that:

a) these data has to be all positive.
But i'm not sure... origin may surely get negative (like in wgs89 and
for example western and southern of the 0-meridian/equator)
And also stepsize - might it get negative too (esp. with flipped grids 
maybe)?


b) the spacing might only be integer numbers, not floats
Is this true? I just got an example with not-round stepsize.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

[Therion] Question about "grid" command

2021-02-23 Thread Benedikt Hallinger


Good morning,
while debugging https://github.com/hbeni/therionsurface2survex/issues/1 
i stumbled upon a format question i did not give tought until yesterday.


With the "grid" command you specify coordinate origin and size of a 
surface grid:

  grid  


Until now i assumed that:

a) these data has to be all positive.
But i'm not sure... origin may surely get negative (like in wgs89 and 
for example western and southern of the 0-meridian/equator)
And also stepsize - might it get negative too (esp. with flipped grids 
maybe)?


b) the spacing might only be integer numbers, not floats
Is this true? I just got an example with not-round stepsize.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] 3D model height

2021-02-22 Thread Benedikt Hallinger

As far as i understood, when you tag your data to be in a certain coordinate 
system that should include all three data points when the coordinate system 
defines them.
If you want an altitude offset, i would expect that we must manually convert.

As an example: i tag my data to be wsg89, which defines altitude pegged to a 
certain reference.
Assume alt is 0.
When i now switch coordinate systems to something really (artifically) weird, 
like the origin pegged to the peak of mt. Everest, i would expect all three 
coordinates to be correctly transformed (making especially altitude very 
negative).
If i now want to say that a point is at the same level as everests peak, i 
would have to apply a manual transformation step.
But that’s not the fault of wgs89 mir the target cs, the reason was that my 
initial calibration was never in wgs89!

What do i get wrong in this thought process?


> Am 22.02.2021 um 21:37 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> 
>> 
>> If there is a real need for a switch between converting and not
>> converting the heights, let us know.
> 
> At least here in the UK, a lot of rough and ready surveys seem to use
> Garmin handheld GPS units like the 66sr. These use barometric altitude,
> which you calibrate to a local benchmark. That means you get local
> mapping heights that do not need to be converted, while the GPS
> coordinates would need to be converted.
> 
> Anyone relying on this approach (which already is rather poor from an
> accuracy perspective) would indeed need you to perform conversion on x
> and y but not z, while anyone using a proper GPS unit which outputs
> ellipsoid heights would need you to convert x, y, and z. I therefore see
> a need for it to be controllable.
> 
> Personally, I use real GPS ellipsoid heights, which I manually convert
> using continental drift calculations and the higher quality
> OSTN15+OSGM15 transformation (since these then remain correct in spite
> of continental drift). I do not rely on proj for that, and have built my
> own tool instead, since proj does not have access to the data required
> for it.
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] 3D model height

Well then i'm out of ideas, however i do not get weird results here when 
invoking proj manually:


echo "647151 242509 262" | cs2cs EPSG:23700 EPSG:4326
47d31'35.376"N  19d0'34.596"E 262.000

echo "47.526453 19.009617 262" | cs2cs EPSG:4326 EPSG:23700
647151.52   242504.51 262.00


When using EPSG:23700, does the problem also occur in kmlth.3d or just 
the kml?



Am 2021-02-19 12:06, schrieb Balambér Hakapesz:

The error only occurs when using the EOV (EPSG: 23700) coordinate
system.

 [3]
Mentes a vírusoktól. www.avg.com [3]

On Fri, Feb 19, 2021 at 11:59 AM Balambér Hakapesz
 wrote:


# 2021.02.08 created by TopoDroid v 5.0.79

#source "../th/kml.th [2]"
source "kml.th [2]"

layout topodroid
legend on
symbol-hide group centerline
symbol-show point station
debug station-names
endlayout

export map -layout topodroid -o kml-p.pdf -proj plan

export map -layout topodroid -o kml-s.pdf -proj extended

# export model -fomat survex -o kmlth.3d

export model -output kmlo.3d
export model -output kmlo.lox
export model -output kmlo.dxf
export model -output kmlo.kml

# 2021.02.08 created by TopoDroid v 5.0.79

survey kml -title "kml"

centerline
#cs long-lat
#fix 0 19.009617 47.526453 262
cs EPSG:23700   #ez felel meg az EOV-nek
fix 0 647151 242509 262
date 2021.02.08
# declination 5. degrees
units length meters
units compass clino degrees
data normal from to length compass clino
extend right
0 1 10.00 180.0 -90.0
1 2 10.00 0.0 0.0
2 3 10.00 90.0 0.0
units left right up down meters
data dimensions station left right up down
endcenterline

endsurvey

[3]
Mentes a vírusoktól. www.avg.com [3]

On Fri, Feb 19, 2021 at 11:49 AM Benedikt Hallinger
 wrote:


What does the survex/aven file give you, is the error there also
apparent?

What is your full thconfig file for generating the kml and aven
.3d?

Dies the problem also exists when specifying this:
cs EPSG:4326
fix 0 19.009617 47.526453 262

Am 2021-02-19 11:25, schrieb Balambér Hakapesz:

If I were to enter the ellisoid height, the error of Proj4 would

still

remain on the EOV projection.
I could work in a UTM coordinate system, but it would be much

simpler

if Therion didn’t recalculate anything. (There is no height

issue

between UTM and WGS84 because there is no conversion)
This error is only present in the national projections where

Proj4

performs approximate calculations for the advantage of

horizontal

coordinates and the disadvantage of height.

On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz
 wrote:


thconfig:
#cs long-lat
#fix 0 19.009617 47.526453 262
cs EPSG:23700   # Hungarian EOV
fix 0 647151 242509 262

kml:

19.00961011626948,47.52649337576407,291.08568208889801

291-262 = 29 m = 44m geoid height - 15m Proj4 error

[2]
Mentes a vírusoktól. www.avg.com [1] [2]

On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger
 wrote:


Isn't EGM84 the reference ellipsoid currently used by WGS84?
What you get with GPS is *not* sea level, but the altitude

above

that
reference geoid (which takes into account gravital anonalys).

If you calibrate your barometric altimeter to the hieght given

by

a
height coordinate of WGS84 (like read from your car's navi at

the

parking lot, or from a map calibrated to WGS84) then you

should

get
about the same altitude.
If you take the cave location from GPS and enter that

coordinates

into
the therion dataset wirh correct "cs" marking, the conversion
should
yield the correct result.
If you take the altitude from a map (or an altimeter

calibrated to

that
map) in another coordinate system, you have to either apply an
offset
manually, add an instrument correction factor in therion, or
supply the
correct coordinate system (which then probalby demands

conversion

of the
lat/lon coordinates).

If generating 3D surfce meshes, you also need to supply

matching

coordinate systems data and/or specify the correct "cs"

parameter.


I think your problem comes from mixing coordinate systems in
respect to
the height model, either at data input or when using the

height

mesh.

Am 2021-02-19 9:49, schrieb Balambér Hakapesz:

Very rarely can anyone work at ellipsoidal heights. In local
coordinate systems, it only makes sense for upper geodetic
calculations. Only for GPS measurements we get an ellipsoidal
altitude, even there the devices can immediately calculate

the

altitude of the EGM96 model with an altitude above sea level

(with a

few meters error which is not significant compared to the 15m

altitude

error of handheld GPS).
Proj4 calculates the horizontal coordinates well, but there

is a

serious error in the height coordinates (for special national
projections












(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),

so it would be better if not we would count on it but leave

the

altitude unchanged.
Could it be an option not to change the height with

Re: [Therion] 3D model height

What does the survex/aven file give you, is the error there also
apparent?

What is your full thconfig file for generating the kml and aven .3d?

Dies the problem also exists when specifying this:
cs EPSG:4326
fix 0 19.009617 47.526453 262

Am 2021-02-19 11:25, schrieb Balambér Hakapesz:

If I were to enter the ellisoid height, the error of Proj4 would still
remain on the EOV projection.
I could work in a UTM coordinate system, but it would be much simpler
if Therion didn’t recalculate anything. (There is no height issue
between UTM and WGS84 because there is no conversion)
This error is only present in the national projections where Proj4
performs approximate calculations for the advantage of horizontal
coordinates and the disadvantage of height.

On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz
wrote:

thconfig:
#cs long-lat
#fix 0 19.009617 47.526453 262
cs EPSG:23700 # Hungarian EOV
fix 0 647151 242509 262

kml:

19.00961011626948,47.52649337576407,291.08568208889801

291-262 = 29 m = 44m geoid height - 15m Proj4 error

[2]
Mentes a vírusoktól. www.avg.com [2]

On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger
wrote:

Isn't EGM84 the reference ellipsoid currently used by WGS84?
What you get with GPS is *not* sea level, but the altitude above
that
reference geoid (which takes into account gravital anonalys).

If you calibrate your barometric altimeter to the hieght given by
a
height coordinate of WGS84 (like read from your car's navi at the
parking lot, or from a map calibrated to WGS84) then you should
get
about the same altitude.
If you take the cave location from GPS and enter that coordinates
into
the therion dataset wirh correct "cs" marking, the conversion
should
yield the correct result.
If you take the altitude from a map (or an altimeter calibrated to
that
map) in another coordinate system, you have to either apply an
offset
manually, add an instrument correction factor in therion, or
supply the
correct coordinate system (which then probalby demands conversion
of the
lat/lon coordinates).

If generating 3D surfce meshes, you also need to supply matching
coordinate systems data and/or specify the correct "cs" parameter.

I think your problem comes from mixing coordinate systems in
respect to
the height model, either at data input or when using the height
mesh.

Am 2021-02-19 9:49, schrieb Balambér Hakapesz:

(with a

few meters error which is not significant compared to the 15m

altitude

error of handheld GPS).
Proj4 calculates the horizontal coordinates well, but there is a
serious error in the height coordinates (for special national
projections

(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),

so it would be better if not we would count on it but leave the
altitude unchanged.
Could it be an option not to change the height with Therion?

[2]
Mentes a vírusoktól. www.avg.com [1] [2]

On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger
wrote:

Hi there,
if you measure the altitude with a barometric device, you do

not get

the
altitude above the ellipsoid. You have to account for that at

the

input
of your data.

With the "cs" command you define your input data to be in a

specific

coordinate system, and also your altitude has to be given in

that

system. If you just put the barometric altitude there (which

you

usually
did calibrate to a map, didn't you?) you have to transform the
altitude
manually if the reference altitude differs.

Am 2021-02-19 8:44, schrieb Balambér Hakapesz:

Hi!

When generating 3D models, Proj4 transforms between different
coordinate systems.
This also transforms the ellipsoidal altitude, but the data

always

refer to altitude above sea level and should not be changed.
The finished models do not fit the topography, you have to

cheat

with

the height to be good.

Balázs Holl.

[1]
Mentes a vírusoktól. www.avg.com [1] [1] [1]

Links:
--
[1]

http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail

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

Links:
--
[1] http://www.avg.com
[2]

http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail

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

___
Therion mailin

Re: [Therion] 3D model height

Isn't EGM84 the reference ellipsoid currently used by WGS84?
What you get with GPS is *not* sea level, but the altitude above that
reference geoid (which takes into account gravital anonalys).

If you calibrate your barometric altimeter to the hieght given by a
height coordinate of WGS84 (like read from your car's navi at the
parking lot, or from a map calibrated to WGS84) then you should get
about the same altitude.
If you take the cave location from GPS and enter that coordinates into
the therion dataset wirh correct "cs" marking, the conversion should
yield the correct result.
If you take the altitude from a map (or an altimeter calibrated to that
map) in another coordinate system, you have to either apply an offset
manually, add an instrument correction factor in therion, or supply the
correct coordinate system (which then probalby demands conversion of the
lat/lon coordinates).

If generating 3D surfce meshes, you also need to supply matching
coordinate systems data and/or specify the correct "cs" parameter.

I think your problem comes from mixing coordinate systems in respect to
the height model, either at data input or when using the height mesh.

Am 2021-02-19 9:49, schrieb Balambér Hakapesz:

Very rarely can anyone work at ellipsoidal heights. In local
coordinate systems, it only makes sense for upper geodetic
calculations. Only for GPS measurements we get an ellipsoidal
altitude, even there the devices can immediately calculate the
altitude of the EGM96 model with an altitude above sea level (with a
few meters error which is not significant compared to the 15m altitude
error of handheld GPS).
Proj4 calculates the horizontal coordinates well, but there is a
serious error in the height coordinates (for special national
projections
(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
so it would be better if not we would count on it but leave the
altitude unchanged.
Could it be an option not to change the height with Therion?

[2]
Mentes a vírusoktól. www.avg.com [2]

On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger
wrote:

Hi there,
if you measure the altitude with a barometric device, you do not get
the
altitude above the ellipsoid. You have to account for that at the
input
of your data.

With the "cs" command you define your input data to be in a specific

coordinate system, and also your altitude has to be given in that
system. If you just put the barometric altitude there (which you
usually
did calibrate to a map, didn't you?) you have to transform the
altitude
manually if the reference altitude differs.

Am 2021-02-19 8:44, schrieb Balambér Hakapesz:

Hi!

When generating 3D models, Proj4 transforms between different
coordinate systems.
This also transforms the ellipsoidal altitude, but the data always
refer to altitude above sea level and should not be changed.
The finished models do not fit the topography, you have to cheat

with

the height to be good.

Balázs Holl.

[1]
Mentes a vírusoktól. www.avg.com [1] [1]

Links:
--
[1]

http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail

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

Links:
--
[1] http://www.avg.com
[2]
http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

Re: [Therion] 3D model height


Hi there,
if you measure the altitude with a barometric device, you do not get the 
altitude above the ellipsoid. You have to account for that at the input 
of your data.


With the "cs" command you define your input data to be in a specific 
coordinate system, and also your altitude has to be given in that 
system. If you just put the barometric altitude there (which you usually 
did calibrate to a map, didn't you?) you have to transform the altitude 
manually if the reference altitude differs.




Am 2021-02-19 8:44, schrieb Balambér Hakapesz:

Hi!

When generating 3D models, Proj4 transforms between different
coordinate systems.
This also transforms the ellipsoidal altitude, but the data always
refer to altitude above sea level and should not be changed.
The finished models do not fit the topography, you have to cheat with
the height to be good.

Balázs Holl.

 [1]
Mentes a vírusoktól. www.avg.com [1]



Links:
--
[1]
http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

Re: [Therion] Removing the lines between survey stations created for surface features

2021-02-07 Thread Benedikt Hallinger

An option could be to overwrite the symbols with empty metapost ones

> Am 07.02.2021 um 17:51 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> Hi David,
> 
>> Does anyone know how to remove the lines that appear between survey
>> stations used for surveying around surface features?
> 
> symbol-hide group surface-centreline
> 
> This also hides the stations. If you want those, you need to put them back:
> 
> symbol-show point station
> 
> And then you can also hide the temporary stations, so only the
> fixed/painted/permanent stations are shown:
> 
> symbol-hide point station:temporary
> 
> The statements are interpreted in the order you write them, so put the
> most generic one first, then get more specific. As far as I remember,
> you cannot choose to show/hide only surface temporary stations while
> showing only the underground painted ones (you can only do the whole
> surface centreline at once, while the stations relate to surface and
> underground at the same time). Maybe others know of a way though.
> 
>> Apart from this, the surface feature drawing all works pretty well,
>> using the line type "border" with "clip" set to "off".
> 
> I like slope for dolines, and pitch for cliffs.
> 
> https://therion.speleo.sk/wiki/surfacefeatures
> 
> Cheers,
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] endless chimneys (was: Splays appearing when not selected)

2021-02-02 Thread Benedikt Hallinger


Hello,
that is not the case here: the sole drawer was myself and there is no 
overlap (i know of - the data is self contained in that folder).


The scraps are like this:
map 1-Deckenschlot-vor-KPZ
  1.1-2-26a-SP1-Aufstieg   # <- has stations, is OK
  1.1-2-26a-SP1# <- has stations, is OK
  1.1-2-26a-SP2# <- last known station at start. OK until 
the middle of the scrap!
  1.1-2-26a-SP3# <- no station; joined to 1.1-2-26a-SP2, 
completely "endless chimney"

endmap

What puzzles me is that the chimney starts at a bend in my scrap.
The altitude range is that of the entire cave, and thus the 
"endless-chimney" is very prominent; I think this is a second issue we 
should tackle also (it will somewhat help with the issue here, but not 
solve it).



Am 2021-02-02 10:01, schrieb Martin Sluka via Therion:

Hi Beni

that is not a problem of „spikes“ but as you may see on attached
picture I had the same problem with one my project.

There were two scraps covered part the same area overlapped. Surveyed
in two different surveying trips by two different groups drawn by two
different people. As a result that overlapped area created something
as infinite vertical chimney.

I had to comment one scrap in time from that part of cave and checked
the result. Than I shorted one of those particular scraps and added
correct join.

HTH

Martin


2. 2. 2021 v 9:48, Benedikt Hallinger :

Hm, that didn't help, unfortunately.
in the meantime I also tried coloring the PDF by altitude, this is
not affected and working like expected.

Martin has readonly svn access to the data and may investigate in
the dataset?
I just unlocked it for that purpose.

The affected thconfig is
svn/Hirlatzhoehle/Zubringer/therion/thconfig
and the scrap in question is in
svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2
The last known station is 1.2.26j

In the thconfig I noted the following (just local here)

# Hirlatzdaten importieren
source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th [1]
# wrong dimensions in lox
#source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th [2]
# works somewhat-ok in lox (still extruded to top of box, but the
box itself is small)

Greetings,
Beni

Am 2021-02-02 6:31, schrieb Stacho Mudrak:
In that case and if there is just one station in this wrong scrap,
maybe inserting point dimensions with some reasonable -value [
 m] over this station in the scrap should help to normalize
these crazy heights.
If there are no up/down data in the centreline, therion calculates
up/down dimensions from shots from a given station. It is not a
perfect algorithm and in your case, there is some issue. Placing a
point dimension close to the station should override this
calculation.
HTH, S.
On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger 
wrote:
It's hard to isolate.
The structure is like this:
Hirlatzhoehle/Zubringer/,
where Zubringer contains more surveys.
Each folder has its own therion/ subfolder containing the therion
sources.
If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th [1]"
the
bug
occurs.
That command sources the entire cave.
If i do source just the region with "source
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th [2]" (which
contains
essentially the same maps and scraps!) the bug occurs.
I have no idea how to track this don further, since we already talk
about alot of data (2.4 km).
Am 2021-02-01 21:37, schrieb Benedikt Hallinger:
I try to boil it down
Am 2021-02-01 21:12, schrieb Stacho Mudrak:
Hmmm, even scraps extending far beyond a known station could

 cause a


problem - usually, it is the case with steep passages. In your

 case,


it looks like some outline problem.
Are you able to isolate such scrap and send me some minimalistic
sample?
Thanks, S.
On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger

 


wrote:
Hi, thanks for responding,
i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.
Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond

 a


known
station (walls are marked unsurveyed).
Am 2021-02-01 19:52, schrieb Stacho Mudrak:
Hi Beni,
thanks for review.
Are you having coloring problem with .lox file or .pdf map?
I have tried on my dataset, but when I select whole cave -

 entire


color range is used - from magenta to red.
When I select just a part of the cave, coloring changes and the
whole
range is used for selected part.
Does your red rectangle fit selected data or is it much bigger?

 If


the
latter is the case, there must be some artifacts still

 remaining -


that were not removed with selection. Maybe some stations? Does
this
problem remain also with aven .3d export?
It would be great if we could find this bug before therion goes

 to


debian release.
S.
On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger

wrote:
Checked it, looks good for me (data selection, a

Re: [Therion] Splays appearing when not selected

2021-02-02 Thread Benedikt Hallinger


Hm, that didn't help, unfortunately.
in the meantime I also tried coloring the PDF by altitude, this is not 
affected and working like expected.


Martin has readonly svn access to the data and may investigate in the 
dataset?

I just unlocked it for that purpose.

The affected thconfig is svn/Hirlatzhoehle/Zubringer/therion/thconfig
and the scrap in question is in  
svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2

The last known station is 1.2.26j

In the thconfig I noted the following (just local here)

# Hirlatzdaten importieren
source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th  # wrong 
dimensions in lox
#source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th   # works 
somewhat-ok in lox (still extruded to top of box, but the box itself is 
small)



Greetings,
Beni



Am 2021-02-02 6:31, schrieb Stacho Mudrak:

In that case and if there is just one station in this wrong scrap,
maybe inserting point dimensions with some reasonable -value [
 m] over this station in the scrap should help to normalize
these crazy heights.

If there are no up/down data in the centreline, therion calculates
up/down dimensions from shots from a given station. It is not a
perfect algorithm and in your case, there is some issue. Placing a
point dimension close to the station should override this calculation.

HTH, S.

On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger 
wrote:


It's hard to isolate.

The structure is like this:
Hirlatzhoehle/Zubringer/,
where Zubringer contains more surveys.
Each folder has its own therion/ subfolder containing the therion
sources.

If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the
bug
occurs.
That command sources the entire cave.

If i do source just the region with "source
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which
contains
essentially the same maps and scraps!) the bug occurs.
I have no idea how to track this don further, since we already talk
about alot of data (2.4 km).

Am 2021-02-01 21:37, schrieb Benedikt Hallinger:

I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could

cause a

problem - usually, it is the case with steep passages. In your

case,

it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger



wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond

a

known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave -

entire

color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger?

If

the

latter is the case, there must be some artifacts still

remaining -

that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes

to

debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison

to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual

min/max

values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

___

Re: [Therion] Splays appearing when not selected


It's hard to isolate.

The structure is like this:
Hirlatzhoehle/Zubringer/,
where Zubringer contains more surveys.
Each folder has its own therion/ subfolder containing the therion 
sources.


If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the bug 
occurs.

That command sources the entire cave.

If i do source just the region with "source 
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which contains 
essentially the same maps and scraps!) the bug occurs.
I have no idea how to track this don further, since we already talk 
about alot of data (2.4 km).



Am 2021-02-01 21:37, schrieb Benedikt Hallinger:

I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could cause a
problem - usually, it is the case with steep passages. In your case,
it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger 
wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a
known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If

the

latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

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

___
Therion mailing list
Therion@speleo.sk




https://mailman.speleo.sk/listinfo/therion___

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

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

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

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

Re: [Therion] Splays appearing when not selected


I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could cause a
problem - usually, it is the case with steep passages. In your case,
it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger 
wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a
known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If

the

latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

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

___
Therion mailing list
Therion@speleo.sk




https://mailman.speleo.sk/listinfo/therion___

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

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

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

Re: [Therion] Splays appearing when not selected


Yes, the scraps are like this (s=station:)

[good scrap: s1 s2 s3]
joined
[bad scrap: s3 ..only walls]


Am 2021-02-01 20:19, schrieb Martin Sluka via Therion:

1. 2. 2021 v 20:10, Benedikt Hallinger :

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a 
known station (walls are marked unsurveyed).


I had the same artifact when I created two overlapped scraps of the
same part of passage referenced by the same stations.

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

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

Re: [Therion] Splays appearing when not selected


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a known 
station (walls are marked unsurveyed).



Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the whole
range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If the
latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does this
problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger 
wrote:


Checked it, looks good for me (data selection, and pdf map printout
with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having significant
altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to the
entire system the altitude difference is negligible, but i expected
the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

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

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

Re: [Therion] Splays appearing when not selected

Checked it, looks good for me (data selection, and pdf map printout with 
people showing up again), with one exception:



- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having significant 
altitude changes in the dataset.
  The reason seems to be that the coloring is done according in relation 
to ALL the cave, not just the selected parts - in comparison to the 
entire system the altitude difference is negligible, but i expected the 
lox to generate the altitude band according to the actual min/max values 
of the selected dataset.



$ therion -v
therion 5.5.6 (2020-12-27)
  - using Proj 7.2.1, compiled against 7.2.1


But: therion compile cdf201b5bf921 has the same behaviour.



Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

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

Re: [Therion] Splays appearing when not selected

2021-01-27 Thread Benedikt Hallinger


I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

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

Re: [Therion] Splays appearing when not selected

2021-01-24 Thread Benedikt Hallinger

Wookey, when is this expected to appear in testing?
I would test it

> Am 24.01.2021 um 13:57 schrieb Wookey :
> 
> On 2021-01-23 11:34 +0100, Stacho Mudrak wrote:
>>   Hi Axel,
>>   these big numbers are just NaNs in fact. It does not affect any output -
>>   it just means the map has no altitude associated with it. But thanks for
>>   finding out, I have tried to fix it in the latest commit, could you please
>>   try?
> 
> I've included this fix (and the other minor one you did) in the debian
> package (as 5.5.6ds1-5).  It turns out that updates to non-core packages 
> (which
> definately includes Therion :-) are actually allowed until 12th Feb,
> not 12th Jan so it should still make it the next stable release.
> 
> It looks like this stable release of therion should be in quite good shape.
> 
> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

2021-01-20 Thread Benedikt Hallinger

I just recompiled and can confirm that my problem indeed was the same 
and is gone with therion 5.5.6+5208297 (2021-01-19)


Good work!
Thank you!


Am 2021-01-19 22:00, schrieb Benedikt Hallinger:

Hello,
Axel and i had the same bug, and we noticed that when explicitely
select the wall source at the export lox command, the issue is solved
("export model -o out.lox -wall-source maps").

Personally i would assume this is a bug, because when i select
datasets i would want the remaining data to be not present in my
output. That is the purpose of selecting in the first place, isn’t it?


Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion 
:


Hi Rhys,

I have noticed something that I am not sure if it's a bug or not. I 
am

trying to export a selected bit of a survey as a loch file:


From my experience...
Lox file export will always select all of the survey that were 
imported.

It will generate walls using all splays. It will use all scraps to
enhance the passage walls, even if you do not select them. If they 
exist

in any surveys or subsurveys, they are used, no matter which survey or
map is selected.

I always assumed this was intentional behaviour.

Personally, I have wanted to be able to select the specific maps that
should be used for lox, since I may have more than one version of a
survey in my data - traces over an old low quality survey, and a new
high quality survey of the same cave. Lox export insists on trying to
merge both versions rather than being able to select just one of them.

Cheers,

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

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

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

Re: [Therion] Splays appearing when not selected

2021-01-19 Thread Benedikt Hallinger

Hello,
Axel and i had the same bug, and we noticed that when explicitely select the 
wall source at the export lox command, the issue is solved ("export model -o 
out.lox -wall-source maps").

Personally i would assume this is a bug, because when i select datasets i would 
want the remaining data to be not present in my output. That is the purpose of 
selecting in the first place, isn’t it?


> Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> Hi Rhys,
> 
>> I have noticed something that I am not sure if it's a bug or not. I am
>> trying to export a selected bit of a survey as a loch file:
> 
> From my experience...
> Lox file export will always select all of the survey that were imported.
> It will generate walls using all splays. It will use all scraps to
> enhance the passage walls, even if you do not select them. If they exist
> in any surveys or subsurveys, they are used, no matter which survey or
> map is selected.
> 
> I always assumed this was intentional behaviour.
> 
> Personally, I have wanted to be able to select the specific maps that
> should be used for lox, since I may have more than one version of a
> survey in my data - traces over an old low quality survey, and a new
> high quality survey of the same cave. Lox export insists on trying to
> merge both versions rather than being able to select just one of them.
> 
> Cheers,
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.5.5 bug - statistics missing from header

2020-12-26 Thread Benedikt Hallinger


GLX issue seems to be fixed in the debian package!

Am 2020-12-23 15:06, schrieb Benedikt Hallinger:

Ok wookey, will check that regarding the glx Patch issue then.


Am 23.12.2020 um 14:26 schrieb Wookey :

On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:

  I am sorry, one bug fixed, another introduced :/
  It should be OK in 5a614ef. Windows binaries should be 
automatically built

  within half an hour.


And the Debian packages are now built in unstable. They should move 
into testing in 5 days time.



Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

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

Re: [Therion] Therion 5.5.5 bug - statistics missing from header

2020-12-26 Thread Benedikt Hallinger

Here Explorers/etc statistics are missing with the debian package, sadly 
:(


Am 2020-12-25 23:07, schrieb Wookey:

On 2020-12-23 15:06 +0100, Benedikt Hallinger wrote:

Ok wookey, will check that regarding the glx Patch issue then.

> Am 23.12.2020 um 14:26 schrieb Wookey :
>
> On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:
>>   I am sorry, one bug fixed, another introduced :/
>>   It should be OK in 5a614ef. Windows binaries should be automatically built
>>   within half an hour.
>
> And the Debian packages are now built in unstable. They should move into 
testing in 5 days time.


Therion 5.5.5 is now in debian testing (for testing :-)
https://tracker.debian.org/pkg/therion

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

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

Re: [Therion] Therion 5.5.5 bug - statistics missing from header

2020-12-23 Thread Benedikt Hallinger

Ok wookey, will check that regarding the glx Patch issue then.

> Am 23.12.2020 um 14:26 schrieb Wookey :
> 
> On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:
>>   I am sorry, one bug fixed, another introduced :/
>>   It should be OK in 5a614ef. Windows binaries should be automatically built
>>   within half an hour.
> 
> And the Debian packages are now built in unstable. They should move into 
> testing in 5 days time.
> 
> 
> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Converter for Compass to Therion

2020-12-20 Thread Benedikt Hallinger


Cool!
I added it to the complimentary cave softwares wiki page: 
https://therion.speleo.sk/wiki/contrib:complimentarycaveapps


Am 2020-12-20 11:44, schrieb Roger Schuster:

Hello cavers,

for those of you who either use the "Compass" cave surveying package
together with Therion or need to convert legacy data from Compass
there is something to try out. I wrote a little converter that
transfers Compass raw data (*.dat) to Therion (*.th). You can find a
description and the source code at



and a compiled package for download at



Please give it a try, I hope it is useful for some of you!

Best regards,

Roger

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

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

Re: [Therion] Italian translation update

2020-12-16 Thread Benedikt Hallinger


That is a good way to go, it's what i always do.

You can fork it via githubs website and then clone that locally.
When you create and push your branch to _your_ repo, github offers an 
option at your forks main site to create such a pull request in the 
therion repo.



Am 2020-12-17 0:09, schrieb Rodrigo Severo via Therion:

‐‐‐ Original Message ‐‐‐

 Em quarta-feira, dezembro 16, 2020 7:23 PM, Fra
 escreveu:


Hello everyone,

I recently started using Therion and I noticed that the Italian
translation has some typos and it was probably not updated for quite
a while.

I updated the /thlang/texts.txt file, is there a way to get
permissions to push it with git? Or else can I just send the updated
file to anybody so it can maybe be included in the next update?


I believe you should fork Therion's github project, create a branch in
your fork just for these updates, commit your changes there and them
make a push request to Therion original repository.

Regards,

Rodrigo


Thank you!

Best regards,

Francesco Bellamoli

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

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

Re: [Therion] FYI Therion explorer name and explored length counting insight

2020-11-28 Thread Benedikt Hallinger

Thank you very much for sharing!

> Am 29.11.2020 um 06:15 schrieb Bruce Mutton :
> 
> 
> This is just an ‘I should have known better’ story, in case you are 
> interested…
>  
> Learnings about map output statistics (that are or probably should have been 
> self-evident):
> This is for a cave where some plan scraps were drawn on the original 
> centreline and were retained in the final map, when the entire original 
> survey was made duplicate due to a subsequent more comprehensive survey that 
> was flagged ‘not-duplicate’. For the extended elevation scraps, these were 
> all drawn on the subsequent ‘not-duplicate’ survey.
> If a whole centreline is made ‘flags duplicate’ then the explorers names 
> appear in the list, but not the length that they explored (it is shown as 
> zero).  You must (also) add the explorers to the corresponding 
> ‘not-duplicated’ centreline to have their explored length credited!
> Only the statistics for the centrelines that are (partly) included in scraps 
> that are output are presented.
>  
> For this plan map, where the duplicated centrelines are actually the ones for 
> which the scraps are exported, the ‘not-duplicate’ centrelines did not have 
> the explorer’s names entered (repeated) and so their names are recorded, but 
> their survey length is not.  Lesson: Always record the original explorers in 
> subsequent survey centrelines.  This behaviour is nice because it alerts the 
> author to a problem with their data entry.
> 
>  
> For this extended map, where the ‘not-duplicate’ surveys have scraps 
> exported, but the duplicate surveys do not, the ‘duplicate’ explorers names 
> are not presented.  This is appropriate behaviour.
> But why is there a surveyor whose name appears with a zero length?  I think 
> it is because, for the entire ‘not-duplicate’ survey, I only contributed to 
> one survey leg (and it is in its very own centreline) and this leg is a 
> surface leg connecting the subsequent ‘not-duplicate’ survey to the original 
> ‘duplicate’ survey.  So my name is recorded as a surveyor, but I have no 
> ‘cave length’ and Therion records zero.  Possibly this is not ideal 
> behaviour, but it would seem inconsistent to change it.
> 
> Here is part of the html survey-list for the cave, with the statistics 
> discussed above highlighted.
> 
>  
> I then thought that if I associated the cave survey with the plan and the 
> elevation maps,
> 
> the statistics might have been better (a feature that I was involved in 
> requesting if I recall correctly).  They are.
> For the plan, there is no change (I still need to add the original explorers 
> to the ‘not-duplicate’ centrelines).
> 
>  
> And for the extended elevation, the duplicate zero length explorers names are 
> brought in, as have the surveyors for the centrelines for which there are no 
> scraps.  It matches the plan statistics.  Perfect (once I fix my centreline 
> metadata as mentioned above).
> 
>  
> Bruce
>  
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Vertical scalebar created by Juraj Halama added to wiki

2020-11-26 Thread Benedikt Hallinger


Cool, do you have a link? :)

Am 2020-11-26 11:55, schrieb Martin Sluka via Therion:

Vertical scalebar created by Juraj Halama added to wiki

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

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

Re: [Therion] Colorizing sections of centerline

2020-11-15 Thread Benedikt Hallinger

No idea, but i usually just use the generated .3d file and aven at this stage.
Aven can also generate screenshots for printing, and can color the centerline 
based on various metrics.

> Am 15.11.2020 um 12:48 schrieb Alvaro Aguilera :
> 
> Hello everyone,
> 
> is there a way to change the color of different sections of the centerline?
> 
> I'm at the stickmap-stage of the survey and it would be really helpful to put 
> some colors to it.
> 
> Regards
> Alvaro
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Connection of Really straight mine level to surveyed passage

2020-11-15 Thread Benedikt Hallinger

Another option would be to get the coordinates of the linking mine station and 
fixing it, and just giving that station a „perfect“ Standards deviation (isn’t 
that default if not given?)

> Am 14.11.2020 um 21:29 schrieb Ben Cooper :
> 
> 
> Hi Alistair
> I would definitely link all the survey centrelines. The implication is that 
> you have some errors in the survey, but you know that the straight mine level 
> needs to be straight so the error isn’t there. One thing you could try is to 
> set the SD for the level to be very low, and the SD for the rest of the cave 
> to be quite high. When Therion distributes the error, most of this should go 
> to the survey sections either the highest SD, and the level should be less 
> distorted. 
> Best regards 
> Ben
> 
> 
> Sent from my iPhone
> 
>>> On 14 Nov 2020, at 11:49, alastair gott  wrote:
>>> 
>> 
>> HI Therion people,
>> 
>> I'm helping with a project we've got a cave/mine system with a really 
>> straight mine level for one of the entrances, which we have the centreline 
>> data for (but no sketches to show where the points are).
>> 
>> When the system was joined up together with all the entrances there was a 
>> kink in the mine level. so to counteract this, I removed some of the unknown 
>> survey points in the centre of the level and hung the survey on some points 
>> at the beginning and end of the level.
>> 
>> I now want to add in a section of cave in the centre of the level. I have 
>> connected this quite well in a map at a lower level with just the one 
>> entrance coordinates in it, but when I run the full map with all the 
>> entrances in, the model then tries to remove the loop error by doing it's 
>> statisical wizardry.
>> 
>> Unfortunately in doing so, it shifts the start of the level (the entrance) 
>> to the east. and then leaves the section of cave out unconnected.
>> 
>> If anyone can help, then the config for the full system is here: 
>> http://www.cave-registry.org.uk/svn/PeakDistrict/Castleton/peak_speedwell_model/
>> 
>> This is what I get:
>> 
>> 
>> 
>> 
>> the config for the one entrance coordinate is here: 
>> http://www.cave-registry.org.uk/svn/PeakDistrict/Castleton/peak_speedwell_model/speedwell_mine/Speedwell_mine_thconfig.thc
>> 
>> and these are the two selects if you want to run it at the lower level:
>> select bottomless_pit.speedwell_mine
>> select oakden_level.speedwell_mine
>> This is what I want:
>> 
>> 
>> 
>> 
>> 
>> If I add in a survey point to hook it to, then I get this:
>> 
>> 
>> 
>> Rather than this:
>> 
>> 
>> 
>> Adding in more survey points further down the passage to the south only 
>> increases the amount of distortion in a small space of passage. as there are 
>> three loop closures at the bottom of the picture [just below the red circle) 
>> which the model is running (i've just not included the maps on the drawing 
>> for clarity).
>> 
>> 
>> Regards,
>> Alastair Gott.
>> 
>> alastairg...@hotmail.com,
>> M: 07931779380.
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Symbol assign - use metapost def instead

2020-11-02 Thread Benedikt Hallinger


I just did that with the AUT symbol set and it looks good:

--- snip 
layout 
...

code metapost
def l_wall_underlying_UIS (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_presumed_UIS (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_pit_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_sand_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_clay_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_pebbles_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_debris_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_blocks_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_ice_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_underlying_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_overlying_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_moonmilk_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_flowstone_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;

endcode

...
endlayout
--- snap --


Am 2020-11-02 9:25, schrieb Bruce Mutton:

I have done exactly that, but with conjectural water to be shown with
the permanent water symbol.
Need to use a little metapost in your layout...

  #replace conjectural waterflow symbol with permanent symbol to
improve visibility
code metapost
def l_waterflow_conjectural (expr Path) =
  l_waterflow_permanent_UIS (Path);
enddef;
endcode

You need to do a similar thing with the definition of your debris and
presumed wall lines to show instead as bedrock.
Bruce

-Original Message-
From: Therion  On Behalf Of Pavel Herich
Sent: Monday, 2 November 2020 20:27
To: List for Therion users 
Subject: [Therion] Symbol assign

Hi,
when exporting maps to a large scale, I´d like to assign wall:debris,
wall:presumed etc. to just "wall". "Symbol-assign line wall:debris
wall:bedrock" in config file doesn´t work, any idea?
Thank you
Pavel
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

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

Re: [Therion] Symbol assign

2020-11-01 Thread Benedikt Hallinger

No idea, but i second the reques - that would be utterly useful for me 
too!


Am 2020-11-02 8:26, schrieb Pavel Herich:

Hi,
when exporting maps to a large scale, I´d like to assign wall:debris,
wall:presumed etc. to just "wall". "Symbol-assign line wall:debris
wall:bedrock" in config file doesn´t work, any idea?
Thank you
Pavel
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

Re: [Therion] Creating PDF/A map files

2020-10-22 Thread Benedikt Hallinger


Hi,
instalation of veraPDF was straightforward.

For a test run i get this:
failedChecks="1846">

This will be a long road.

But your idea is quite good, as it will preserve valuable work.
OTOH the PDFs are just results, what is really valuable would be the 
source files. And they are pretty good to archive already, as they are 
just text files!
Therion should be fine to run a long time into the future, hopefully. 
And as its OpenSource, there are no constraints whatsoever to fix bugs 
in the future to make it work again...



Am 2020-10-22 15:17, schrieb Bill Gee:

Hello everyone -

I propose a new feature for Therion. This will probably take some
work, and I am sure there will be discussion about how to implement
it.

It seems to me that the maps we produce with Therion are likely going
to be stored for a very long time, perhaps running into multiple tens
of years. As we all know, computer technology over that amount of time
will change drastically. Just think about the contrast in both
hardware and software in the last 25 years - from Windows 95 running
on 486dx processors to Linux and Windows 10 running on i7 and i9
processors.

I think we have some obligation to make sure the cave maps we generate
are still usable many years from now. Saving them in PDF format is a
large - but incomplete - step in that direction.

The new feature I propose is to modify the PDF creation code so that
it produces files that are PDF/A version 1b (or possibly version 2)
compliant.

https://en.wikipedia.org/wiki/PDF/A [1]

I have checked all of the PDF files I created in Therion, and none of
them are flagged as PDF/A compliant. It is possible that they are, in
fact, compliant and simply do not have the necessary flag. The experts
can check that against the PDF/A specifications.

Existing PDF documents can be checked for PDF/A compliance with a
command-line tool called "verapdf". The web site for that tool is

https://openpreservation.org/products/verapdf/ [2]

It is possible to use GhostScript to transform an existing PDF into a
PDF/A file. The command line is daunting.

https://www.mcbsys.com/blog/2018/10/batch-convert-pdf-to-pdf-a-2018-edition/
[3]

I tried the GhostScript conversion on one of my Therion maps.
Immediately at startup it produced this message three times:

"GPL Ghostscript 9.53.3: UTF16BE text string detected in DOCINFO
cannot be represented in XMP for PDF/A1, reverting to normal PDF
output"

The process continued running and took about 10 minutes. The resulting
file failed verapdf analysis. It also increased the file size from 4.3
megabytes to over 52 megabytes! The output file displayed correctly in
Okular.

I do not have any idea how Therion produces PDF files. It probably
uses some combination of TeX and GhostScript to get it done. The new
feature may be as simple as adding some additional parameters to the
command lines that call the external programs.

Let the discussion begin! :-)

--

Bill Gee



Links:
--
[1] https://en.wikipedia.org/wiki/PDF/A
[2] https://openpreservation.org/products/verapdf/
[3] 
https://www.mcbsys.com/blog/2018/10/batch-convert-pdf-to-pdf-a-2018-edition/

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

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

Re: [Therion] Survex (loop closure) related fixes

I just made a new issue ticket: 
https://github.com/therion/therion/issues/278



Am 2020-10-14 22:53, schrieb Benedikt Hallinger:

Hi there,
i performed a git bisect (the very first in my lifetime, and that is
really a nice and easy tool to search such things!!!).

The commits at and before c7d41d9 compiled the cave sucessfully 10 of 
10 times.


1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit
commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8
Author: mbudaj 
Date:   Wed Aug 19 07:25:53 2020 +0200

dynamically load EPSG/ESRI labels in Proj>=6

https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8

This compiles unstable like described before.



Am 2020-10-14 22:32, schrieb Wookey:

On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote:

OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something 
else

somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per 
se, but

some memory issue of the compiled therion program.

The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny


Oh dear. This could be fun to track down

Better check 5.5.1 always works, not just more often. But if it does
then careful examination of what changed is in order. Maybe send some
others the dataset to see who can reproduce (windows/linux/macOS)?

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

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

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

Re: [Therion] Survex (loop closure) related fixes


Hi there,
i performed a git bisect (the very first in my lifetime, and that is 
really a nice and easy tool to search such things!!!).


The commits at and before c7d41d9 compiled the cave sucessfully 10 of 10 
times.


1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit
commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8
Author: mbudaj 
Date:   Wed Aug 19 07:25:53 2020 +0200

dynamically load EPSG/ESRI labels in Proj>=6

https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8

This compiles unstable like described before.



Am 2020-10-14 22:32, schrieb Wookey:

On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote:

OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something 
else

somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per 
se, but

some memory issue of the compiled therion program.

The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny


Oh dear. This could be fun to track down

Better check 5.5.1 always works, not just more often. But if it does
then careful examination of what changed is in order. Maybe send some
others the dataset to see who can reproduce (windows/linux/macOS)?

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

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

Re: [Therion] Survex (loop closure) related fixes


OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something else 
somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per se, 
but some memory issue of the compiled therion program.


The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny




Am 2020-10-14 21:53, schrieb Martin Sluka via Therion:

I use BBEdit on MacOSX and it has all features you mentioned.

Martin

14. 10. 2020 v 21:17, Tarquin Wilton-Jones via Therion 
:


On 14/10/2020 20:08, Martin Sluka via Therion wrote:
What about multifile search for”P]” in text files? It is quite 
strange combination of characters and they are part of ASCII set.


If you have an editor that is working in the same character set as
Therion, that could work. Definitely worth a try.

I suspect the fault relates to character set conversion though. Such 
as

an editor working in 8859-1, and Therion trying to interpret it in
UTF-8. Most basic text editors don't let you control character set, 
and

just work in the system default (Windows-1252 on English-based Windows
systems). Even if they do, most users are not aware of what it all
means, and just stick with the default.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


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

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

Re: [Therion] Survex (loop closure) related fixes


I sent Martin a dataset to investigate.
Hopefully he can spot something...


Am 2020-10-14 21:40, schrieb Benedikt Hallinger:

Hello all, thanks for all the hints.

What about multifile search for”P]” in text files? It is quite strange 
combination of characters and they are part of ASCII set.

I had that in mind, but i don't think its the problem here. If it
would, 5.5.1 should fail too...


What about multifile search for”P]”

With every run the string changes. I have seen that before with C++
code, that was when i tried to put out a memory adress instead of the
actual string. Maybe the passed string is already memory garbage at
this point?


QA folks start grinning. Generic instructions below:

Uh, then i will have a grey beard finishing this. We talk about 130km
of cave in way over 600 files here.


I also commented the the error line in the source code that bails out
here, and everything (therion, but also the map) compiles just fine as
it should. Also the cartographers names print nicely.


Nonewithstanding i had a idea i went trough. A part of the cave is
done using an inkscape plugin, which converts the svg data into th2
files. That usually goes good, and did to therion 5.5.1.

I also was able to isolate a scrap line causing the problem (excerpt 
attached).

However, if i craft a very simple thconfig, it compiles fine; and the
isolated line looks not suspicious at all for me!

The problem occurs only if i try to render the whole cave (in a very
big scale 1:5000); if i craft a very simple thconfig and source only
the passage th file, it goes OK.
Could it be that somewhere some string buffer runs over when gathering
all the cartographers?
or that something else messes stuff up memory-wise, because the
dataset is so big already?

I'm out of ideas.


Am 2020-10-14 20:34, schrieb Benedikt Hallinger:

Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It
surely must be somewhere in the .th2 files "author", since that is
probably the only place where this gets gathered from, isn't it?

I enhanced the thtexfonts.cxx on line 247 to print out the offending
string (if you want i make a PR for that) that now shows something
looking like garbage:
  ./therion: error -- Invalid utf-8 string! (offending string: 
'P]���U')



I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

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

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

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

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

Re: [Therion] Survex (loop closure) related fixes


Hello all, thanks for all the hints.

What about multifile search for”P]” in text files? It is quite strange 
combination of characters and they are part of ASCII set.
I had that in mind, but i don't think its the problem here. If it would, 
5.5.1 should fail too...



What about multifile search for”P]”
With every run the string changes. I have seen that before with C++ 
code, that was when i tried to put out a memory adress instead of the 
actual string. Maybe the passed string is already memory garbage at this 
point?



QA folks start grinning. Generic instructions below:
Uh, then i will have a grey beard finishing this. We talk about 130km of 
cave in way over 600 files here.



I also commented the the error line in the source code that bails out 
here, and everything (therion, but also the map) compiles just fine as 
it should. Also the cartographers names print nicely.



Nonewithstanding i had a idea i went trough. A part of the cave is done 
using an inkscape plugin, which converts the svg data into th2 files. 
That usually goes good, and did to therion 5.5.1.


I also was able to isolate a scrap line causing the problem (excerpt 
attached).
However, if i craft a very simple thconfig, it compiles fine; and the 
isolated line looks not suspicious at all for me!


The problem occurs only if i try to render the whole cave (in a very big 
scale 1:5000); if i craft a very simple thconfig and source only the 
passage th file, it goes OK.
Could it be that somewhere some string buffer runs over when gathering 
all the cartographers?
or that something else messes stuff up memory-wise, because the dataset 
is so big already?


I'm out of ideas.


Am 2020-10-14 20:34, schrieb Benedikt Hallinger:

Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It
surely must be somewhere in the .th2 files "author", since that is
probably the only place where this gets gathered from, isn't it?

I enhanced the thtexfonts.cxx on line 247 to print out the offending
string (if you want i make a PR for that) that now shows something
looking like garbage:
  ./therion: error -- Invalid utf-8 string! (offending string: 
'P]���U')



I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

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

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therionencoding  utf-8
##XTHERION## xth_me_area_adjust 0 0 1432.044359 1455.405165
##XTHERION## xth_me_area_zoom_to 100


# THIS HAS OFFENDING CHARACTERS:
scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan -author 
2020.03.22 "Foo Bar"

# THIS DOES WORK:
#scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan


line wall -subtype debris
  698.1766 498.9593
  698.9107 510.1675 698.4598 521.3301 693.7274 532.328
endline

point 1350.6446 56.0884 u:mappe -attr text 253
point 1017.9026 158.2627 passage-height -value 16
point 1264.195 71.1864 passage-height -value 12
point 905.4025 90.8898 passage-height -value 4
point 674.3731 473.9263 passage-height -value 1.1
point 956.171 212.2135 continuation -text [Schlot]
point 1058.3538 248.9031 continuation -text [Schlot]
point 742.8787 178.1511 altitude -align r
point 1231.4015 34.8879 altitude -align l
point 1103.6943 242.364 altitude -align r
point 710.4934 492.3343 altitude -align r
point 1353.6321 105.8449 station-name -scale xs
point 1237.7953 57.0631 station-name -scale xs
point 998.0274 167.6244 station-name -scale xs
point 676.8842 539.3195 station-name -scale xs
point 700.5987 294.6161 station-name -scale xs
point 729.1645 393.9866 label -text [Klamm] -align r -scale s
line border 
  1349.3419 95.0398
  1350.8979 92.9743 1351.8803 90.4498 1351.3281 86.6977
endline

point 1158.2586 159.375 debris -orientation 336.025125
point 967.0364 196.1817 height -value "+"
point 1065.6624 231.3641 height -value "+"
point 776.7726 142.1957 gradient -scale xs -orientation 258.18624432
line border -close on -id 237-plan1.3_debris_1 -visibility off
  684.8291 528.1967
  675.2952 519.2984
  684.1935

Re: [Therion] Survex (loop closure) related fixes


Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It 
surely must be somewhere in the .th2 files "author", since that is 
probably the only place where this gets gathered from, isn't it?


I enhanced the thtexfonts.cxx on line 247 to print out the offending 
string (if you want i make a PR for that) that now shows something 
looking like garbage:

  ./therion: error -- Invalid utf-8 string! (offending string: 'P]���U')


I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

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

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

Re: [Therion] Survex (loop closure) related fixes


I experimented a little bit more.

In the thconfig file I set some header data.
statistics explo off
statistics topo  off
statistics carto off
statistics copyright all

If i comment out the line
#statistics carto off
the compilation works again (then showing the people of course).
The same is true with "statistics carto all".

Why does turning off the carto yield invalid UTF8 data?




Am 2020-10-14 10:38, schrieb Benedikt Hallinger:

I tried to compile the model of the Hirlatz cave with it and it looks
good, from a big picture view.
The passages shifted sometimes slightly, as expected.

When trying to compile a specific plan map view PDF i get an error
about UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


therion 5.5.2+4683494 (2020-10-13)
cavern - Survex 1.2.42
initialization file: therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED

This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ...
NOT INSTALLED
configuration file:
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/plan.DOP.map.thconfig
reading ... done
reading source files ... done
preprocessing database ... done
./therion: warning -- year 1951 magnetic declination used for undated 
surveys

undated surveys:
155.Wilder_Westen.Hirlatzhoehle
323.Westen.Hirlatzhoehle
326.Hochdonnerbach.Hirlatzhoehle
scanning centreline tree ... done
searching for centerline loops ... done
calculating station coordinates ... done
average loop error: 1.98%
processing survey data ... done
calculating basic statistics ... done
processing extended elevation ... done
processing references ... done
selecting export objects ... done
processing projection plan ... done
average distortion: 3.21%
writing
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/../Hirlatz.plan.DOP.map.pdf
...
./therion: error -- Invalid utf-8 string!



Am 2020-10-14 10:02, schrieb Tarquin Wilton-Jones via Therion:

Hi folks,

Stacho fixed these "when using Survex loop closure" bugs in 
yesterday's

development release:

https://github.com/therion/therion/issues/269 Therion miscalculates
fixes in multiple centreline blocks when using Survex loop closure

https://github.com/therion/therion/issues/270 Therion cannot have
exactly 2 fixes for a station when using Survex loop closure

And this Survex compatibility bug:

https://github.com/therion/therion/issues/263 Scale value should 
default

to 1 when omitted from "calibrate" commands

I have checked and verified the fixes, and my surveys still look 
right.

But could someone with a bigger dataset check that it didn't break
anything else when using Survex loop closures. That particular fix 
looks
like the kind that could create regressions. It only improved things 
for

me though :)

Yes, your cave entrance locations will change if you ever ran into 
#269

without realising - they are supposed to. And yes, you might find some
parts of the cave change size if you ever hit the calibrate statement 
bug.


Cheers,

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

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

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

Re: [Therion] Survex (loop closure) related fixes