Very nice, cant wait to try it out once it reaches release!
> Am 27.06.2019 um 21:49 schrieb Bruce Mutton <[email protected]>: > > Thanks for following up on this Stacho, it is an important topic! > I have just done a trial run, and it works, but there could be issues with > exported pdf file sizes (7MB becomes 113MB) and with some of my scraps and > maps that have strange elevations. Ie these are very common > “ > M > -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 > SL-SilentSumpPlan@MiddleEarth (SL-SilentSump Plan ) > S 379.51 SL-SilentSumpPlan-s2@MiddleEarth () > S 387.63 SL-SilentSumpPlan-s1@MiddleEarth () > “ > I need to research this before commenting further. The average scrap > elevations in the log looks like it will be helpful in planning map outputs. > > But the very best thing for me is that ‘maps off’ has the effect of disabling > all passage offsets with a single switch. > Something I have long been hoping for. > > Thanks, a great addition to Therion. > Bruce > > From: Therion <[email protected]> On Behalf Of Stacho Mudrak > Sent: Friday, 28 June 2019 05:20 > To: List for Therion users <[email protected]> > Subject: Re: [Therion] Sorting scraps/maps by height in default mode > > Hello, > > sorry for reopening this thread, but finally this feature (to ignore existing > map structures) was added to therion. Just use > > maps off > > in your thconfig file, and it should work (in the latest development > version). Also, selection (with scrap/map altitudes) was added to therion.log > for debugging purposes. > > S. > > On Mon, 3 Jun 2019 at 08:21, Benedikt Hallinger <[email protected]> wrote: > Good morning, > thank you for that info! > Would it be a huge effort to make such an option available? Just asking. > > To define the top level hierarchies, it would be cool to somehow get the > altitude-sorted map names from some debug log or so. That list could be used > directly to construct the map-command block that reproduces the current > result. This would drastically reduce the effort. > Would it be possible to add a debug log output command, that produces such a > list? Or is it already possible to get that list somehow, for example from > the sql database output? > > Am 01.06.2019 um 22:44 schrieb Stacho Mudrak <[email protected]>: > > Unfortunately, there is no such option. Once a map is defined in your > dataset, it will be used with its average altitude in the export when only > surveys are selected for output. The idea behind is, that once you start > defining maps out of the scraps, you will build the whole tree of them > including top-level ones. So the only way how to overcome this problem is to > comment all your maps in the code until you define the whole hierarchy of > them. > > S. > > On Fri, 31 May 2019 at 22:15, Benedikt Hallinger <[email protected]> wrote: > Thank you for your message, this helps alot. > There is a way out tough, a middle ground: one can define custom maps in > the thconfig file using source. > > I need to think about how this affects the projects structure. > > Besides that, is there a option to disable map-averaging and tell > therion to use the scrap average for each scrap? > That would solve this imho. > > Thanks, i understand i better now, how this works currently. > > > Am 2019-05-31 21:22, schrieb Stacho Mudrak: > > Hello Beni, > > > > I am not 100% sure if I understand your problem correctly, but this is > > how therion does average altitude calculations: > > > > the altitude of a scrap = arithmetic average of altitudes of its > > stations > > the altitude of a map = arithmetic average of altitudes of scraps > > > > And your observation is correct. If you have some maps defined in your > > dataset, then maps of selected surveys are exported and sorted > > according to their altitudes. If you have no maps defined, then scraps > > in selected surveys are taken and altitude sorted. > > > > So if you are working on a large dataset and you do not want to define > > upper-level maps, it is probably better not to define any maps at all > > - then only scraps will be taken into consideration. > > > > Best regards, S. > > > > On Fri, 31 May 2019 at 15:38, Benedikt Hallinger <[email protected]> > > wrote: > > > >> 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 > >> <[email protected]> > >>> 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] > >>>> [1]" > >>>> command in the region.th [2] [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 > >>>> [email protected] > >>>> https://mailman.speleo.sk/listinfo/therion > >>> > >>> > >>> Links: > >>> ------ > >>> [1] http://2.th > >>> [2] http://region.th > >>> _______________________________________________ > >>> Therion mailing list > >>> [email protected] > >>> https://mailman.speleo.sk/listinfo/therion > >> _______________________________________________ > >> Therion mailing list > >> [email protected] > >> https://mailman.speleo.sk/listinfo/therion > > > > > > Links: > > ------ > > [1] http://2.th > > [2] http://region.th > > _______________________________________________ > > Therion mailing list > > [email protected] > > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > [email protected] > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > [email protected] > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > [email protected] > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > [email protected] > https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list [email protected] https://mailman.speleo.sk/listinfo/therion
