[Therion] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Hi Stacho,
your infos did the trick.
indeed the data showed at closer examination, that the parts where 
averaged lower than the part in question. The wrongly-lower part 
contains a steep slope but the average height was still some few meters 
below the average of the offending part.

What puzzled me was that even splitting the scraps was not enough!
I now have a scrap containing only the sloped part of the tunnel, and 
that is surely averaged above the lower part.

What solved it was to also rearrange the map definitions that contain 
the sloped part: i put the low part prior the slope in question in 
another map like this:
-------snip----------
# This works instead:
map working-priortunnel
   scrap-low-tunnel-before-slope
endmap
map working-slope
   scrap-slope-itself-with-followig-high-part
endmap


# this does NOT work lie intendet:
#map notWorking-combined
#  scrap-low-tunnel-before-slope
#  scrap-slope-itself-with-followig-high-part
#endmap
-------snap----------

It looks like therion currently uses the average height of the MAP, not 
the contained scraps, to calculate which part is above or below. In this 
example, it looks like it is getting the average height of the 
"notWorking-combined" combined map and comparing this to the 
uncorrelated below-tunnel.
If i put the "scrap-low-tunnel-before-slope" in its own MAP definition, 
the average calculation can only take the 
"scrap-slope-itself-with-followig-high-part" and thus resulting in a 
much higher average height.

Can you confirm this from therions sourcecode, and is this really the 
intendet behaviour, since i think each scrap shopuld be averaged for 
itself, regardless of its map allocation...?


Wih best regards,
Beni


Am 2019-05-30 22:27, schrieb Stacho Mudrak:
> Hello,
> 
> if you select just survey, then all maps consisting of scraps in this
> and sub-surveys should be ordered by average altitude. But this may
> easily cause that some overlapping is not done correctly. But it is
> also possible, there is some bug and it is not done correctly. Are you
> able to post some minimalistic sample, where depth sort fails?
> 
> The only way how to manually order maps in the output is to create
> upper-level maps (in your case probably what you mean by
> <region>-Hautplan) consisting of lower level maps in the correct
> order.
> 
> HTH, S.
> 
> On Thu, 30 May 2019 at 15:55, Benedikt Hallinger <beni at hallinger.org>
> wrote:
> 
>> Hello there,
>> i have a very large dataset here. It is organised by regions like
>> this
>> (but much more leaf objects and regions):
>> 
>> =====snip=====
>> - survey TheCave
>> - survey RegionWest
>> - survey 1
>> - survey 3
>> - survey 5
>> - survey RegionEast
>> - survey 2
>> - survey 4
>> - survey 6
>> =====snap=====
>> 
>> I currently work from bottom to up, that is i draw the individual
>> surveys as scraps, based on original material (sometimes they are
>> really
>> large and cosnsist of several many scraps).
>> 
>> In each of they leaf surveys (the numbered ones) i make by
>> convention a
>> map called "<n>-Hauptplan". The main idea is that every leaf survey
>> can
>> be treaten modular and that i can compile varoius maps at upper
>> levels
>> (i.e regions).
>> 
>> Currently, the regions have no "<region>-Hautplan". When i use
>> "select
>> RegionWest.TheCave", therion is instructed to select all scraps
>> below
>> it. For the most part, this works like intendet and the overlappings
>> are
>> calculated correctly. There are some places however, where the upper
>> 
>> part of the passage is rendered below the lower part, which is
>> wrong.
>> This is with about 10-15% of the passages (so most is already ok).
>> 
>> I know from the manuals that therion does this "randomly" so there
>> is no
>> real way to adjust this from my perspective (placing the "input 2.th
>> [1]"
>> command in the region.th [2] file, wich then inputs the scraps etc,
>> lower in
>> the list does not help - it seems random where it is).
>> I think, however, that it would be a very great addition, if there
>> would
>> be some code in the renderer, that sorts the vertical presentation
>> of
>> the scraps/maps by average altitude of said scrap/map, and that this
>> 
>> behavior is controllable by some configuration (cmdline option, or
>> even
>> better, thconfig parameter).
>> => Is there maybe already something hidden like this i don't know so
>> 
>> far?
>> That would be very great, because when i look at the dataset, i face
>> 
>> about 30-50 hours producing correctly manually sorted handcrafted
>> maps
>> at the region level...
>> 
>> Sincerely, Beni
>> _______________________________________________
>> Therion mailing list
>> Therion at speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> 
> 
> Links:
> ------
> [1] http://2.th
> [2] http://region.th
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> https://mailman.speleo.sk/listinfo/therion