Mike McCombe's TerrainTool has been fixed and is available again from http://www.ubss.org.uk/terraintool/terraintool.php Download and enjoy. It may not use the latest data but it remains the most straightforward way of adding topographic detail to Therion 3D models. Graham
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
Martin
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command? Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
Martin
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi, there is no change regarding the limits in Therion. If there is a real need, following could be done: - in the current version of MetaPost, it's possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits - instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX). And yes, the limit applies just to the data selected for export. Martin On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
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
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps. Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, it's possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
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
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello, for further testing i wrote a small script generating a sample cave of variable length. The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th eg "./generateTestCave.sh 1000 test.th" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file. With the contained thconig file one can pay a little to explore behavior. What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here? Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, it's possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
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
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello, I have not investigated to details a lot, but the problem with this huge file is search for automatic joins. All the scraps are in one giant file and have a lot of common points so it tries to auto-connect every scrap with every scrap, therefore n^2 memory usage. Situation that should not happen in reality. If you apply attached patch and disable automatic scrap joins - therion runs smoothly even with such a giant structure. But more proper solution would be to shift every scrap, that they will not have common points. S. diff --git a/thdb2d.cxx b/thdb2d.cxx index b8c9720..7d7b72e 100644 --- a/thdb2d.cxx +++ b/thdb2d.cxx @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj) // prida na koniec automaticke joiny jci = joincandlist.begin(); + jci = joincandlist.end(); while (jci != joincandlist.end()) { njci = jci; njci++; On 27 December 2017 at 13:26, Benedikt Hallinger via Therion < therion@speleo.sk> wrote:
Hello, for further testing i wrote a small script generating a sample cave of variable length.
The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th eg "./generateTestCave.sh 1000 test.th" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file.
With the contained thconig file one can pay a little to explore behavior.
What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here?
Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, it's possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu>
wrote:
> > It looks like the solution is to issue the following metapost > command: > warningcheck := 0; >
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself.
The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost.
On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references).
In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a > code metapost > warningcheck := 0; > endcode > block seems to have no effect, mpost still fails on more then 4096 > scraps. >
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon.
If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library.
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
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Shouldnt they be placed at the actual position according to station coordinates prior joining, ie the scrap point reference coordinates be local to its namespace? Am 2017-12-29 11:20, schrieb Stacho Mudrak via Therion:
Hello, I have not investigated to details a lot, but the problem with this huge file is search for automatic joins. All the scraps are in one giant file and have a lot of common points so it tries to auto-connect every scrap with every scrap, therefore n^2 memory usage. Situation that should not happen in reality.
If you apply attached patch and disable automatic scrap joins - therion runs smoothly even with such a giant structure. But more proper solution would be to shift every scrap, that they will not have common points.
S.
diff --git a/thdb2d.cxx b/thdb2d.cxx index b8c9720..7d7b72e 100644 --- a/thdb2d.cxx +++ b/thdb2d.cxx @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj) // prida na koniec automaticke joiny jci = joincandlist.begin(); + jci = joincandlist.end(); while (jci != joincandlist.end()) { njci = jci; njci++;
On 27 December 2017 at 13:26, Benedikt Hallinger via Therion <therion@speleo.sk [14]> wrote:
Hello, for further testing i wrote a small script generating a sample cave of variable length.
The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th [9] eg "./generateTestCave.sh 1000 test.th [10]" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th [11]. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file.
With the contained thconig file one can pay a little to explore behavior.
What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here?
Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, its possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk [6]> wrote:
Maybe another question: Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, is the blow limit of 4096 scraps still valid in the current version? Or is it already fixed so we can use more scraps?
> On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu > [1]> > wrote: > >> It looks like the solution is to issue the following metapost >> command: >> warningcheck := 0; > > Indeed. The new limit will be 32768 and could not be increased > further > in Metapost itself. > > The solution would be modification of how therion manages metapost > pictures (currently they are stored in files data.1 to data.4000, > with > files data.4001 to data.4095 reserved for pattern definitions). This > numbering scheme could be modified to allow more file name prefixes > and consequently theoretically unlimited number of scraps processed > by > metapost. > > On the other hand there is still pdfTeX limit which would not allow > much more scraps. PdfTeX uses internal registers for scraps > referencing (scrap data is included only once in pdf file and can be > referenced on multiple pages). You could avoid pdftex limit by using > SVG output (if SVG viewers would process large number of internal > references). > > In the longer-term future (a few years) I would like to use metapost > as a library instead of external metapost executable, which would > solve the problems with temporary files (and other problems as > well). > >> However adding it in a >> code metapost >> warningcheck := 0; >> endcode >> block seems to have no effect, mpost still fails on more then 4096 >> scraps. > > Therion currently inserts warningcheck:=1; before scraps without > good > reason, so it will be fixed soon. > > If the new warningcheck setting would work for you, I would prefer > not > to modify current file numbering scheme for metapost pictures and > have > it fixed later with implementation of metapost library. > > Martin
_______________________________________________ Therion mailing list Therion@speleo.sk [2] https://mailman.speleo.sk/listinfo/therion [3]
_______________________________________________ Therion mailing list Therion@speleo.sk [4] https://mailman.speleo.sk/listinfo/therion [5]
Therion mailing list Therion@speleo.sk [7] https://mailman.speleo.sk/listinfo/therion [8]
_______________________________________________ Therion mailing list Therion@speleo.sk [12] https://mailman.speleo.sk/listinfo/therion [13]
Links: ------ [1] http://umn.edu [2] mailto:Therion@speleo.sk [3] https://mailman.speleo.sk/listinfo/therion [4] mailto:Therion@speleo.sk [5] https://mailman.speleo.sk/listinfo/therion [6] mailto:therion@speleo.sk [7] mailto:Therion@speleo.sk [8] https://mailman.speleo.sk/listinfo/therion [9] http://test.th [10] http://test.th [11] http://scrap.th [12] mailto:Therion@speleo.sk [13] https://mailman.speleo.sk/listinfo/therion [14] mailto:therion@speleo.sk
I am sorry, I am not sure I understand. The problem is, if there are two lines in two different scraps within one .th2 file starting or ending from point with same coordinates, therion automatically creates a join between them. In your file, each of line of 5000 scraps are the same. Therefore they start and end at same points. Therefore therion automatically creates 5000x5000 joins for each line end. And this is the problem. I have modified your script to add some randomness to the coordinates (just shift every scrap by random vector) and it solves the problem. S. On 29 December 2017 at 15:42, Benedikt Hallinger via Therion < therion@speleo.sk> wrote:
Shouldnt they be placed at the actual position according to station coordinates prior joining, ie the scrap point reference coordinates be local to its namespace?
Am 2017-12-29 11:20, schrieb Stacho Mudrak via Therion:
Hello, I have not investigated to details a lot, but the problem with this huge file is search for automatic joins. All the scraps are in one giant file and have a lot of common points so it tries to auto-connect every scrap with every scrap, therefore n^2 memory usage. Situation that should not happen in reality.
If you apply attached patch and disable automatic scrap joins - therion runs smoothly even with such a giant structure. But more proper solution would be to shift every scrap, that they will not have common points.
S.
diff --git a/thdb2d.cxx b/thdb2d.cxx index b8c9720..7d7b72e 100644 --- a/thdb2d.cxx +++ b/thdb2d.cxx @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj)
// prida na koniec automaticke joiny jci = joincandlist.begin(); + jci = joincandlist.end(); while (jci != joincandlist.end()) { njci = jci; njci++;
On 27 December 2017 at 13:26, Benedikt Hallinger via Therion < therion@speleo.sk [14]> wrote:
Hello,
for further testing i wrote a small script generating a sample cave of variable length.
The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th [9] eg "./generateTestCave.sh 1000 test.th [10]" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th [11]. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file.
With the contained thconig file one can pay a little to explore behavior.
What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here?
Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this?
I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, its possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk [6]> wrote:
Maybe another question:
Assume a large cave with thousands of scraps. When i make a thconfig file sourcing all that data, but using "select" statements i only select partial data, does the metapost limit apply to the whole dataset or just the scraps covered by the select command?
Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
Hello Martin, > is the blow limit of 4096 scraps still valid in the current version? > Or is it already fixed so we can use more scraps? > > On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu >> [1]> >> >> wrote: >> >> It looks like the solution is to issue the following metapost >>> command: >>> warningcheck := 0; >>> >> >> Indeed. The new limit will be 32768 and could not be increased >> further >> in Metapost itself. >> >> The solution would be modification of how therion manages metapost >> pictures (currently they are stored in files data.1 to data.4000, >> with >> files data.4001 to data.4095 reserved for pattern definitions). This >> numbering scheme could be modified to allow more file name prefixes >> and consequently theoretically unlimited number of scraps processed >> by >> metapost. >> >> On the other hand there is still pdfTeX limit which would not allow >> much more scraps. PdfTeX uses internal registers for scraps >> referencing (scrap data is included only once in pdf file and can be >> referenced on multiple pages). You could avoid pdftex limit by using >> SVG output (if SVG viewers would process large number of internal >> references). >> >> In the longer-term future (a few years) I would like to use metapost >> as a library instead of external metapost executable, which would >> solve the problems with temporary files (and other problems as >> well). >> >> However adding it in a >>> code metapost >>> warningcheck := 0; >>> endcode >>> block seems to have no effect, mpost still fails on more then 4096 >>> scraps. >>> >> >> Therion currently inserts warningcheck:=1; before scraps without >> good >> reason, so it will be fixed soon. >> >> If the new warningcheck setting would work for you, I would prefer >> not >> to modify current file numbering scheme for metapost pictures and >> have >> it fixed later with implementation of metapost library. >> >> Martin >> > > _______________________________________________ > Therion mailing list > Therion@speleo.sk [2] > https://mailman.speleo.sk/listinfo/therion [3] >
_______________________________________________ Therion mailing list Therion@speleo.sk [4] https://mailman.speleo.sk/listinfo/therion [5]
_______________________________________________ Therion mailing list Therion@speleo.sk [7] https://mailman.speleo.sk/listinfo/therion [8]
_______________________________________________ Therion mailing list Therion@speleo.sk [12] https://mailman.speleo.sk/listinfo/therion [13]
Links: ------ [1] http://umn.edu [2] mailto:Therion@speleo.sk [3] https://mailman.speleo.sk/listinfo/therion [4] mailto:Therion@speleo.sk [5] https://mailman.speleo.sk/listinfo/therion [6] mailto:therion@speleo.sk [7] mailto:Therion@speleo.sk [8] https://mailman.speleo.sk/listinfo/therion [9] http://test.th [10] http://test.th [11] http://scrap.th [12] mailto:Therion@speleo.sk [13] https://mailman.speleo.sk/listinfo/therion [14] mailto:therion@speleo.sk
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello Stacho, thank you very much for your modification! I was not aware of the autojoin feature which i abused by acident here. I will play a little with this! Am 2017-12-29 22:47, schrieb Stacho Mudrak via Therion:
I am sorry, I am not sure I understand.
The problem is, if there are two lines in two different scraps within one .th2 file starting or ending from point with same coordinates, therion automatically creates a join between them. In your file, each of line of 5000 scraps are the same. Therefore they start and end at same points. Therefore therion automatically creates 5000x5000 joins for each line end. And this is the problem. I have modified your script to add some randomness to the coordinates (just shift every scrap by random vector) and it solves the problem.
S.
On 29 December 2017 at 15:42, Benedikt Hallinger via Therion <therion@speleo.sk [31]> wrote:
Shouldnt they be placed at the actual position according to station coordinates prior joining, ie the scrap point reference coordinates be local to its namespace?
Am 2017-12-29 11:20, schrieb Stacho Mudrak via Therion:
Hello, I have not investigated to details a lot, but the problem with this huge file is search for automatic joins. All the scraps are in one giant file and have a lot of common points so it tries to auto-connect every scrap with every scrap, therefore n^2 memory usage. Situation that should not happen in reality.
If you apply attached patch and disable automatic scrap joins - therion runs smoothly even with such a giant structure. But more proper solution would be to shift every scrap, that they will not have common points.
S.
diff --git a/thdb2d.cxx b/thdb2d.cxx index b8c9720..7d7b72e 100644 --- a/thdb2d.cxx +++ b/thdb2d.cxx @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj) // prida na koniec automaticke joiny jci = joincandlist.begin(); + jci = joincandlist.end(); while (jci != joincandlist.end()) { njci = jci; njci++;
On 27 December 2017 at 13:26, Benedikt Hallinger via Therion <therion@speleo.sk [14] [14]> wrote:
Hello, for further testing i wrote a small script generating a sample cave of variable length.
The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th [9] [9] eg "./generateTestCave.sh 1000 test.th [10] [10]" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th [11] [11]. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file.
With the contained thconig file one can pay a little to explore behavior.
What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here?
Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, its possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk [6] [6]> wrote:
> Maybe another question: > Assume a large cave with thousands of scraps. > When i make a thconfig file sourcing all that data, but using > "select" > statements i only select partial data, > does the metapost limit apply to the whole dataset or just the > scraps > covered by the select command? > > Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion: > >> Hello Martin, >> is the blow limit of 4096 scraps still valid in the current >> version? >> Or is it already fixed so we can use more scraps? >> >>> On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu >>> [1] [1]> >>> >>> wrote: >>> >>>> It looks like the solution is to issue the following metapost >>>> command: >>>> warningcheck := 0; >>> >>> Indeed. The new limit will be 32768 and could not be increased >>> further >>> in Metapost itself. >>> >>> The solution would be modification of how therion manages metapost >>> pictures (currently they are stored in files data.1 to data.4000, >>> with >>> files data.4001 to data.4095 reserved for pattern definitions). >>> This >>> numbering scheme could be modified to allow more file name >>> prefixes >>> and consequently theoretically unlimited number of scraps >>> processed by >>> metapost. >>> >>> On the other hand there is still pdfTeX limit which would not >>> allow >>> much more scraps. PdfTeX uses internal registers for scraps >>> referencing (scrap data is included only once in pdf file and can >>> be >>> referenced on multiple pages). You could avoid pdftex limit by >>> using >>> SVG output (if SVG viewers would process large number of internal >>> references). >>> >>> In the longer-term future (a few years) I would like to use >>> metapost >>> as a library instead of external metapost executable, which would >>> solve the problems with temporary files (and other problems as >>> well). >>> >>>> However adding it in a >>>> code metapost >>>> warningcheck := 0; >>>> endcode >>>> block seems to have no effect, mpost still fails on more then >>>> 4096 >>>> scraps. >>> >>> Therion currently inserts warningcheck:=1; before scraps without >>> good >>> reason, so it will be fixed soon. >>> >>> If the new warningcheck setting would work for you, I would prefer >>> not >>> to modify current file numbering scheme for metapost pictures and >>> have >>> it fixed later with implementation of metapost library. >>> >>> Martin >> >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk [2] [2] >> https://mailman.speleo.sk/listinfo/therion [3] [3] > > _______________________________________________ > Therion mailing list > Therion@speleo.sk [4] [4] > https://mailman.speleo.sk/listinfo/therion [5] [5] _______________________________________________ Therion mailing list Therion@speleo.sk [7] [7] https://mailman.speleo.sk/listinfo/therion [8] [8]
_______________________________________________ Therion mailing list Therion@speleo.sk [12] [12] https://mailman.speleo.sk/listinfo/therion [13] [13]
Links: ------ [1] http://umn.edu [15] [2] mailto:Therion@speleo.sk [16] [3] https://mailman.speleo.sk/listinfo/therion [17] [4] mailto:Therion@speleo.sk [18] [5] https://mailman.speleo.sk/listinfo/therion [19] [6] mailto:therion@speleo.sk [20] [7] mailto:Therion@speleo.sk [21] [8] https://mailman.speleo.sk/listinfo/therion [22] [9] http://test.th [23] [10] http://test.th [24] [11] http://scrap.th [25] [12] mailto:Therion@speleo.sk [26] [13] https://mailman.speleo.sk/listinfo/therion [27] [14] mailto:therion@speleo.sk [28]
_______________________________________________ Therion mailing list Therion@speleo.sk [29] https://mailman.speleo.sk/listinfo/therion [30]
Links: ------ [1] http://umn.edu [2] mailto:Therion@speleo.sk [3] https://mailman.speleo.sk/listinfo/therion [4] mailto:Therion@speleo.sk [5] https://mailman.speleo.sk/listinfo/therion [6] mailto:therion@speleo.sk [7] mailto:Therion@speleo.sk [8] https://mailman.speleo.sk/listinfo/therion [9] http://test.th [10] http://test.th [11] http://scrap.th [12] mailto:Therion@speleo.sk [13] https://mailman.speleo.sk/listinfo/therion [14] mailto:therion@speleo.sk [15] http://umn.edu [16] mailto:Therion@speleo.sk [17] https://mailman.speleo.sk/listinfo/therion [18] mailto:Therion@speleo.sk [19] https://mailman.speleo.sk/listinfo/therion [20] mailto:therion@speleo.sk [21] mailto:Therion@speleo.sk [22] https://mailman.speleo.sk/listinfo/therion [23] http://test.th [24] http://test.th [25] http://scrap.th [26] mailto:Therion@speleo.sk [27] https://mailman.speleo.sk/listinfo/therion [28] mailto:therion@speleo.sk [29] mailto:Therion@speleo.sk [30] https://mailman.speleo.sk/listinfo/therion [31] mailto:therion@speleo.sk
Hello, i played a little more and it looks good. For the archive, here the source of the revised script. I changed it so each survey gets its own th2-file now. Included is now also an extendet elevation and two sectionals. ----------------------------------- tar -xzf MASSTEST.tar.gz cd MASSTEST ./generateTestCave.sh 15000 #bash; produces 15k surveys (~250km) and scrap data in out/ therion # results are in results/ ----------------------------------- I tested atlas on more data (see thconfig-more): Can i unselect the sectionals to get more room for plan-data? Using "symbol-hide point section" in layout seems to not conserve any memory... The limit with this dataset seems to be somewhere between 1350 and 1380 selected maps (1350 still compiles successfully; each survey contains one plan- and one none-scrap (section); total 2). With best regards and thank you! Am 2017-12-29 22:47, schrieb Stacho Mudrak via Therion:
I am sorry, I am not sure I understand.
The problem is, if there are two lines in two different scraps within one .th2 file starting or ending from point with same coordinates, therion automatically creates a join between them. In your file, each of line of 5000 scraps are the same. Therefore they start and end at same points. Therefore therion automatically creates 5000x5000 joins for each line end. And this is the problem. I have modified your script to add some randomness to the coordinates (just shift every scrap by random vector) and it solves the problem.
S.
On 29 December 2017 at 15:42, Benedikt Hallinger via Therion <therion@speleo.sk [31]> wrote:
Shouldnt they be placed at the actual position according to station coordinates prior joining, ie the scrap point reference coordinates be local to its namespace?
Am 2017-12-29 11:20, schrieb Stacho Mudrak via Therion:
Hello, I have not investigated to details a lot, but the problem with this huge file is search for automatic joins. All the scraps are in one giant file and have a lot of common points so it tries to auto-connect every scrap with every scrap, therefore n^2 memory usage. Situation that should not happen in reality.
If you apply attached patch and disable automatic scrap joins - therion runs smoothly even with such a giant structure. But more proper solution would be to shift every scrap, that they will not have common points.
S.
diff --git a/thdb2d.cxx b/thdb2d.cxx index b8c9720..7d7b72e 100644 --- a/thdb2d.cxx +++ b/thdb2d.cxx @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj) // prida na koniec automaticke joiny jci = joincandlist.begin(); + jci = joincandlist.end(); while (jci != joincandlist.end()) { njci = jci; njci++;
On 27 December 2017 at 13:26, Benedikt Hallinger via Therion <therion@speleo.sk [14] [14]> wrote:
Hello, for further testing i wrote a small script generating a sample cave of variable length.
The bash-script generateTestCave.sh generates a th-file one main survey and *n* linked subusrveys with included scrap and is called as following: ./generateTestCave.sh <number-of-surveys> test.th [9] [9] eg "./generateTestCave.sh 1000 test.th [10] [10]" generates a survey "test" containing 1000 linked subsurveys containing each a suitable inline-copy of the scrap.th [11] [11]. On the main "test"-survey level also for each subsurvey a "map n-Plan" is generated. This is then selected in the "thconfig" file.
With the contained thconig file one can pay a little to explore behavior.
What i encounter is the following unexepected: With raising survey count the memory needed and time to compile increases very heavily. This is DESPITE i only select 3 distinct maps for output in lox and pdf plan projection. Why is that so? i expected, that the selection influences the scraps selected and thus compile time should nearly remain constant (at least only increase slightly due to more data processed and discarded)? Also, in the mailing list there was an encounter of strange behavior of the select/unselect command - do we have a bug here somewhere that also causes the behavior i see here?
Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
Thank, how could i switch this? I also wrote a small testcase that segfaulted at about 3000 scraps.
Am 2017-12-02 9:55, schrieb Martin Budaj via Therion:
Hi,
there is no change regarding the limits in Therion. If there is a real need, following could be done:
- in the current version of MetaPost, its possible to used "double" arithmetic just by specifying a command line option, which practically eliminates MetaPost limits
- instead of pdfTeX we could use LuaTeX to produce the PDFs. This doubles the number of registers available from 32768 to 65536. Registers are needed to reference the fragments of all scraps/sections; you usually need up to 6 of them for a scrap. So you would get maybe 12000 instead of 6000 scraps in one output file. It would require some substantial work to support LuaTeX (there is e.g. completely different font handling compared to PdfTeX).
And yes, the limit applies just to the data selected for export.
Martin
On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion <therion@speleo.sk [6] [6]> wrote:
> Maybe another question: > Assume a large cave with thousands of scraps. > When i make a thconfig file sourcing all that data, but using > "select" > statements i only select partial data, > does the metapost limit apply to the whole dataset or just the > scraps > covered by the select command? > > Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion: > >> Hello Martin, >> is the blow limit of 4096 scraps still valid in the current >> version? >> Or is it already fixed so we can use more scraps? >> >>> On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213 at umn.edu >>> [1] [1]> >>> >>> wrote: >>> >>>> It looks like the solution is to issue the following metapost >>>> command: >>>> warningcheck := 0; >>> >>> Indeed. The new limit will be 32768 and could not be increased >>> further >>> in Metapost itself. >>> >>> The solution would be modification of how therion manages metapost >>> pictures (currently they are stored in files data.1 to data.4000, >>> with >>> files data.4001 to data.4095 reserved for pattern definitions). >>> This >>> numbering scheme could be modified to allow more file name >>> prefixes >>> and consequently theoretically unlimited number of scraps >>> processed by >>> metapost. >>> >>> On the other hand there is still pdfTeX limit which would not >>> allow >>> much more scraps. PdfTeX uses internal registers for scraps >>> referencing (scrap data is included only once in pdf file and can >>> be >>> referenced on multiple pages). You could avoid pdftex limit by >>> using >>> SVG output (if SVG viewers would process large number of internal >>> references). >>> >>> In the longer-term future (a few years) I would like to use >>> metapost >>> as a library instead of external metapost executable, which would >>> solve the problems with temporary files (and other problems as >>> well). >>> >>>> However adding it in a >>>> code metapost >>>> warningcheck := 0; >>>> endcode >>>> block seems to have no effect, mpost still fails on more then >>>> 4096 >>>> scraps. >>> >>> Therion currently inserts warningcheck:=1; before scraps without >>> good >>> reason, so it will be fixed soon. >>> >>> If the new warningcheck setting would work for you, I would prefer >>> not >>> to modify current file numbering scheme for metapost pictures and >>> have >>> it fixed later with implementation of metapost library. >>> >>> Martin >> >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk [2] [2] >> https://mailman.speleo.sk/listinfo/therion [3] [3] > > _______________________________________________ > Therion mailing list > Therion@speleo.sk [4] [4] > https://mailman.speleo.sk/listinfo/therion [5] [5] _______________________________________________ Therion mailing list Therion@speleo.sk [7] [7] https://mailman.speleo.sk/listinfo/therion [8] [8]
_______________________________________________ Therion mailing list Therion@speleo.sk [12] [12] https://mailman.speleo.sk/listinfo/therion [13] [13]
Links: ------ [1] http://umn.edu [15] [2] mailto:Therion@speleo.sk [16] [3] https://mailman.speleo.sk/listinfo/therion [17] [4] mailto:Therion@speleo.sk [18] [5] https://mailman.speleo.sk/listinfo/therion [19] [6] mailto:therion@speleo.sk [20] [7] mailto:Therion@speleo.sk [21] [8] https://mailman.speleo.sk/listinfo/therion [22] [9] http://test.th [23] [10] http://test.th [24] [11] http://scrap.th [25] [12] mailto:Therion@speleo.sk [26] [13] https://mailman.speleo.sk/listinfo/therion [27] [14] mailto:therion@speleo.sk [28]
_______________________________________________ Therion mailing list Therion@speleo.sk [29] https://mailman.speleo.sk/listinfo/therion [30]
Links: ------ [1] http://umn.edu [2] mailto:Therion@speleo.sk [3] https://mailman.speleo.sk/listinfo/therion [4] mailto:Therion@speleo.sk [5] https://mailman.speleo.sk/listinfo/therion [6] mailto:therion@speleo.sk [7] mailto:Therion@speleo.sk [8] https://mailman.speleo.sk/listinfo/therion [9] http://test.th [10] http://test.th [11] http://scrap.th [12] mailto:Therion@speleo.sk [13] https://mailman.speleo.sk/listinfo/therion [14] mailto:therion@speleo.sk [15] http://umn.edu [16] mailto:Therion@speleo.sk [17] https://mailman.speleo.sk/listinfo/therion [18] mailto:Therion@speleo.sk [19] https://mailman.speleo.sk/listinfo/therion [20] mailto:therion@speleo.sk [21] mailto:Therion@speleo.sk [22] https://mailman.speleo.sk/listinfo/therion [23] http://test.th [24] http://test.th [25] http://scrap.th [26] mailto:Therion@speleo.sk [27] https://mailman.speleo.sk/listinfo/therion [28] mailto:therion@speleo.sk [29] mailto:Therion@speleo.sk [30] https://mailman.speleo.sk/listinfo/therion [31] mailto:therion@speleo.sk
Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://therion.speleo.sk/samples.doc/60.html b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm but neither seems to work. a) produces no change and b) triggers a compile error :( This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) = % draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) ); % if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0); % draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8); % restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout -------------------- and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown... What am i doing wrong? With best regards and happy christmas!
Hi Benedikt, Adding a continuation ? should be a standard use of a TH2 file, check in: points/All Symbols/Possible continuation/Type [continuation]. This should produce a ?, even without the code to produce the text as well. If it's not producing a ? then there's something going wrong before. I've never tried adding continuation text, but I assume you're adding the text to the options box (much like producing a label). Options: -text "water too cold to continue" -code A If you're not adding this to the options then this is what is causing your problems. If it doesn't solve your problems, then we were having fun defining new rocks and Debris a couple of months ago. To insert these new icons, there were a few steps to go through. The test example is on Wookey's website, so I can't take credit for that, but it does just reduce the problem of defining new symbols to a simple file, so is a good example for you to look at and work out. http://wookware.org/surveys/therion/index.html In the Config file Wookey and Andrew defined the symbol in the layout. "Symbol-assign area debris TEST" Then Initiated the Symbol within the Metapost wrapping "initsymbol ("a_debris_TEST") and then defined the symbol. At present I think you may have only defined the symbol. So i'd advise also trying to define your continuation as def p_continuation_TEST(expr pos,theta,sc,al) = Then above assigning the symbol symbol-assign point continuation TEST and then within your metapost wrapper initsymbol ("p_continuation_TEST") By doing this, you should be able to turn on and off your "test" point continuation by # the symbol-assign line. as Wookey and Andrew did below for the AUT and SKBB blocks. Do I make any sense? ---layout from wookeys Debris and rock---- layout local scale 1 100 symbol-set NZSS symbol-hide group cave-centreline #copy blocksAUT #copy blocksSKBB symbol-assign area debris TEST symbol-assign area blocks TEST #symbol-assign area blocks AUT #symbol-assign area blocks SKBB code metapost initsymbol ("a_debris_TEST"); initsymbol ("a_blocks_TEST"); def a_blocks_TEST (expr p) = T:=identity; symbol_distance:=1.6; scale_factor:= 0.8; pickup PenC; path q, qq; q = bbox p; pair outside; outside:= ulcorner q + up; picture tmp_pic; uu := max(u, (xpart urcorner q - xpart llcorner q)/100, (ypart urcorner q - ypart llcorner q)/100); tmp_pic := image( for i = xpart llcorner q step symbol_distance*uu until xpart urcorner q: for j = ypart llcorner q step symbol_distance*uu until ypart urcorner q: qq := punked (((-.5uu,-.5uu)--(.5uu,-.5uu)--(1.05uu,0.05uu)--(.5uu,.5uu)--(-.5uu,.5uu)--cycle) randomized (uu/2)) scaled (uniformdeviate(0.7)+scale_factor ) rotated uniformdeviate(360) shifted ((i,j) randomized 0.75uu); if xpart (p intersectiontimes qq) < 0: if pointinside((i,j),p,outside): thclean qq; thdraw qq; fi; else: qq:= qq scaled (uniformdeviate(.2)+.5 ) if xpart (p intersectiontimes qq) < 0: if pointinside((i,j),p,outside): thclean qq; thdraw qq; fi; fi; fi; endfor; endfor; ); clip tmp_pic to p; drawoptions(); draw tmp_pic; enddef; def a_debris_TEST (expr p) = T:=identity; pickup PenC; path q, qq; q = bbox p; picture tmp_pic; tmp_pic := image( for i = xpart llcorner q step u until xpart urcorner q: for j = ypart llcorner q step u until ypart urcorner q: qq := punked (((-.2u,-.2u)--(.2u,-.2u)--(.2u,.2u)--(-.2u,.2u)--cycle) randomized (u/2)) rotated uniformdeviate(360) shifted ((i,j) randomized u); if xpart (p intersectiontimes qq) < 0: thclean qq; thdraw qq; fi; endfor; endfor; ); clip tmp_pic to p; draw tmp_pic; enddef; endcode endlayout Regards, Alastair Gott. AlastairGott@hotmail.com, M: 07931779380. ________________________________ From: Therion <therion-bounces@speleo.sk> on behalf of Benedikt Hallinger via Therion <therion@speleo.sk> Sent: 22 December 2018 11:12 To: List for Therion users Cc: Benedikt Hallinger Subject: [Therion] Showing qestion mark texts broken? Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftherion.speleo.sk%2Fsamples.doc%2F60.html&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=WEN25vHGKS75bd2iOmYY8N3phCECVrGVoznqMnrqC20%3D&reserved=0 b) https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarcocorvi.altervista.org%2Fcaving%2Ftbe%2Fm_05%2Fm_054.htm&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=3FtoNdR%2BuWBMfXX3hZtoNaKunH9%2FrMfyeyyrE5TXdzw%3D&reserved=0 but neither seems to work. a) produces no change and b) triggers a compile error :( This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) = % draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) ); % if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0); % draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8); % restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout -------------------- and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown... What am i doing wrong? With best regards and happy christmas! _______________________________________________ Therion mailing list Therion@speleo.sk https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.speleo.sk%2Flistinfo%2Ftherion&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=0bzsKCPTIBGAWAM4vi5hQhuOhqBghQppJ1j%2BCv1DnLI%3D&reserved=0
Hello, unfortunately this does not help. The standard "?"-symbol does show like expected. It is just the extension code not having the stated effect if showing the text. As such, i just want to override the default p_continuation symbol with the code showing the text, and only so when i choose it by including the layout option. It just looks like the "if" clause in the code is not run properly, however it is correctly included in the parse because i can break the compile process when introducing garbage code there. Am 2018-12-22 16:01, schrieb alastair gott:
Hi Benedikt,
Adding a continuation ? should be a standard use of a TH2 file, check in: points/All Symbols/Possible continuation/Type [continuation].
This should produce a ?, even without the code to produce the text as well. If it's not producing a ? then there's something going wrong before.
I've never tried adding continuation text, but I assume you're adding the text to the options box (much like producing a label). Options: -text "water too cold to continue" -code A
If you're not adding this to the options then this is what is causing your problems.
If it doesn't solve your problems, then we were having fun defining new rocks and Debris a couple of months ago. To insert these new icons, there were a few steps to go through.
The test example is on Wookey's website, so I can't take credit for that, but it does just reduce the problem of defining new symbols to a simple file, so is a good example for you to look at and work out. http://wookware.org/surveys/therion/index.html In the Config file Wookey and Andrew defined the symbol in the layout. "Symbol-assign area debris TEST"
Then Initiated the Symbol within the Metapost wrapping "initsymbol ("a_debris_TEST")
and then defined the symbol.
At present I think you may have only defined the symbol. So i'd advise also trying to define your continuation as def p_continuation_TEST(expr pos,theta,sc,al) =
Then above assigning the symbol symbol-assign point continuation TEST
and then within your metapost wrapper initsymbol ("p_continuation_TEST")
By doing this, you should be able to turn on and off your "test" point continuation by # the symbol-assign line. as Wookey and Andrew did below for the AUT and SKBB blocks.
Do I make any sense?
---layout from wookeys Debris and rock---- layout local
scale 1 100 symbol-set NZSS symbol-hide group cave-centreline #copy blocksAUT #copy blocksSKBB symbol-assign area debris TEST symbol-assign area blocks TEST #symbol-assign area blocks AUT #symbol-assign area blocks SKBB code metapost initsymbol ("a_debris_TEST"); initsymbol ("a_blocks_TEST"); def a_blocks_TEST (expr p) = T:=identity; symbol_distance:=1.6; scale_factor:= 0.8; pickup PenC; path q, qq; q = bbox p; pair outside; outside:= ulcorner q + up; picture tmp_pic; uu := max(u, (xpart urcorner q - xpart llcorner q)/100, (ypart urcorner q - ypart llcorner q)/100); tmp_pic := image( for i = xpart llcorner q step symbol_distance*uu until xpart urcorner q: for j = ypart llcorner q step symbol_distance*uu until ypart urcorner q: qq := punked (((-.5uu,-.5uu)--(.5uu,-.5uu)--(1.05uu,0.05uu)--(.5uu,.5uu)--(-.5uu,.5uu)--cycle) randomized (uu/2)) scaled (uniformdeviate(0.7)+scale_factor ) rotated uniformdeviate(360) shifted ((i,j) randomized 0.75uu); if xpart (p intersectiontimes qq) < 0: if pointinside((i,j),p,outside): thclean qq; thdraw qq; fi; else: qq:= qq scaled (uniformdeviate(.2)+.5 ) if xpart (p intersectiontimes qq) < 0: if pointinside((i,j),p,outside): thclean qq; thdraw qq; fi; fi; fi; endfor; endfor; ); clip tmp_pic to p; drawoptions(); draw tmp_pic; enddef; def a_debris_TEST (expr p) = T:=identity; pickup PenC; path q, qq; q = bbox p; picture tmp_pic; tmp_pic := image( for i = xpart llcorner q step u until xpart urcorner q: for j = ypart llcorner q step u until ypart urcorner q: qq := punked (((-.2u,-.2u)--(.2u,-.2u)--(.2u,.2u)--(-.2u,.2u)--cycle) randomized (u/2)) rotated uniformdeviate(360) shifted ((i,j) randomized u); if xpart (p intersectiontimes qq) < 0: thclean qq; thdraw qq; fi; endfor; endfor; ); clip tmp_pic to p; draw tmp_pic; enddef; endcode endlayout
Regards, Alastair Gott.
AlastairGott@hotmail.com, M: 07931779380.
-------------------------
FROM: Therion <therion-bounces@speleo.sk> on behalf of Benedikt Hallinger via Therion <therion@speleo.sk> SENT: 22 December 2018 11:12 TO: List for Therion users CC: Benedikt Hallinger SUBJECT: [Therion] Showing qestion mark texts broken?
Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftherion.speleo.sk%2Fsamples.doc%2F60.html&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=WEN25vHGKS75bd2iOmYY8N3phCECVrGVoznqMnrqC20%3D&reserved=0 [1] b) https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarcocorvi.altervista.org%2Fcaving%2Ftbe%2Fm_05%2Fm_054.htm&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=3FtoNdR%2BuWBMfXX3hZtoNaKunH9%2FrMfyeyyrE5TXdzw%3D&reserved=0 [2] but neither seems to work. a) produces no change and b) triggers a compile error :(
This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) =
% draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) );
% if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0);
% draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8);
% restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout --------------------
and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown...
What am i doing wrong?
With best regards and happy christmas! _______________________________________________ Therion mailing list Therion@speleo.sk https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.speleo.sk%2Flistinfo%2Ftherion&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=0bzsKCPTIBGAWAM4vi5hQhuOhqBghQppJ1j%2BCv1DnLI%3D&reserved=0
Links: ------ [1] https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftherion.speleo.sk%2Fsamples.doc%2F60.html&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=WEN25vHGKS75bd2iOmYY8N3phCECVrGVoznqMnrqC20%3D&reserved=0 [2] https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarcocorvi.altervista.org%2Fcaving%2Ftbe%2Fm_05%2Fm_054.htm&data=02%7C01%7C%7C0ca209370ddc495c109308d667ffbce5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636810745412347133&sdata=3FtoNdR%2BuWBMfXX3hZtoNaKunH9%2FrMfyeyyrE5TXdzw%3D&reserved=0
and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it.
Hi Benedikt Does the above statement mean that you have other projects where the 'show continuation text' has worked properly and it is just stopped working for this project? Or have you never used 'show continuation text' before? I just checked one of my projects, and both my continuation layout metaposts are working just fine with the latest Therion release 5.4.1+a08b94e (2018-12-17) Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Benedikt Hallinger via Therion Sent: Sunday, 23 December 2018 00:12 To: List for Therion users <therion@speleo.sk> Cc: Benedikt Hallinger <beni@hallinger.org> Subject: [Therion] Showing qestion mark texts broken? Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://therion.speleo.sk/samples.doc/60.html b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm but neither seems to work. a) produces no change and b) triggers a compile error :( This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) = % draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) ); % if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0); % draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8); % restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout -------------------- and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown... What am i doing wrong? With best regards and happy christmas! _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi, no i never had implemented before. Could you please send me your layout and compiler file? I probably made some dumb error somewhere :( Am 22.12.2018 um 22:55 schrieb Bruce Mutton via Therion <therion@speleo.sk>:
and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it.
Hi Benedikt Does the above statement mean that you have other projects where the 'show continuation text' has worked properly and it is just stopped working for this project? Or have you never used 'show continuation text' before?
I just checked one of my projects, and both my continuation layout metaposts are working just fine with the latest Therion release 5.4.1+a08b94e (2018-12-17)
Bruce
-----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Benedikt Hallinger via Therion Sent: Sunday, 23 December 2018 00:12 To: List for Therion users <therion@speleo.sk> Cc: Benedikt Hallinger <beni@hallinger.org> Subject: [Therion] Showing qestion mark texts broken?
Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://therion.speleo.sk/samples.doc/60.html b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm but neither seems to work. a) produces no change and b) triggers a compile error :(
This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) =
% draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) );
% if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0);
% draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8);
% restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout --------------------
and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown...
What am i doing wrong?
With best regards and happy christmas! _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
This is what I use. Slightly different to your example. Code in my standard layout... #CODE TO DISPLAY CONTINUATIONS (LEADS) #------------------------------------ layout LayoutShowContinuationQmarkOnly #Show question marks only where continuations #are flagged in survey or scrap symbol-show point flag:continuation endlayout LayoutShowContinuationQmarkOnly layout LayoutShowContinuationFullText #Show full text highlighted in pink where continuations # are flagged in survey or scrap code metapost def p_continuation(expr pos,theta,sc,al) = % draw default continuation symbol ie ? p_continuation_UIS(pos,theta,sc,al); % if text attribute is set if known(ATTR__text) and picture(ATTR__text): % set labeling color to light orange push_label_fill_color(1.0, 0.9, 0.8); % draw filled label with text next to symbol ? p_label.urt(ATTR__text,(.5u,-.25u) transformed T,0.0,8); % restore original labeling color pop_label_fill_color; fi; enddef; endcode symbol-show point flag:continuation endlayout LayoutShowContinuationFullText Code in my layout called from export statement. #INVOKE LAYOUTS from INPUT files #------------------------------- #select NEITHER or ONE of the following, NOT both copy LayoutShowContinuationFullText # copy LayoutShowContinuationQmarkOnly Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Benedikt Hallinger via Therion Sent: Sunday, 23 December 2018 00:12 To: List for Therion users <therion@speleo.sk> Cc: Benedikt Hallinger <beni@hallinger.org> Subject: [Therion] Showing qestion mark texts broken? Hi, i try to add a layout for showing the question mark texts. For this i tried the additions from the websites: a) https://therion.speleo.sk/samples.doc/60.html b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm but neither seems to work. a) produces no change and b) triggers a compile error :( This is a) implemented in my layout.conf (taken from the web) --------------------------- layout showContinationText.inc code metapost def p_continuation(expr pos,theta,sc,al) = % draw question mark above station: % rotation=0, scaling=1, offset=(0,2) % p_continuation_UIS(pos, 0.0, 1.0, (0, 2) ); % if text attribute is set if known ATTR_text: % set labeling color to red push_label_fill_color(1.0, 0.0, 0.0); % draw filled label with text below station p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8); % restore original labeling color pop_label_fill_color; fi; enddef; endcode endlayout -------------------- and my thconfig export command includes this: "-layout showContinationText.inc", which in other cases is enough to activate it. The layout file is also loaded, i checked that. However, no text is shown... What am i doing wrong? With best regards and happy christmas! _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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" command in the region.th 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
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@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" command in the region.th 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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi Stacho, hello Bruce, you understood correctly. The problem here is, we are talking about uncorrelated maps and scraps. They are from several subsurveys. is there any kind of debug output i can activate to get the average scrap height? And is the sorting done scrap-wise, or are the maps averaged? 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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello, I´ve solved this with "select" from "Map structure" in config: #BENIKOVA okolie select j_c17m@j_c17.indexDJ select j_c18m@j_c18.indexDJ select benik@benikova.indexDJ select portal_pod_benikovouo@portal_pod_benikovou.indexDJ select mala_j_pod_benikovoum@mala_j_pod_benikovou.indexDJ select j_jelenich_stopm@j_jelenich_stop.indexDJ select tunelova_j_pri_benikovejm@tunelova_j_pri_benikovej.indexDJ select j_s_plesnoum@j_s_plesnou.indexDJ select otvor_naprotim@otvor_naproti.indexDJ #DVERE okolie select miesto_na_balkone1m@miesto_na_balkone1.indexDJ select miesto_na_balkone2m@miesto_na_balkone2.indexDJ select previs_na_balkonem@previs_na_balkone.indexDJ select j_s_bazoum@j_s_bazou.indexDJ ... There is 200 caves in my dataset, I have decided to select them for eachone (at highiest level), so it´s bit painful, but you can do it by groups. There is just one limitation, that one group or cave cannot be below and above of another at once - then must be divided in two parts. Hope I´ve unerstood your problem well. Pavel Dňa 2019-05-30 22:40 Benedikt Hallinger napísal(a):
Hi Stacho, hello Bruce, you understood correctly.
The problem here is, we are talking about uncorrelated maps and scraps. They are from several subsurveys.
is there any kind of debug output i can activate to get the average scrap height?
And is the sorting done scrap-wise, or are the maps averaged?
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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 <beni@hallinger.org> 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 <beni@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 <beni@hallinger.org> 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 <beni@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] [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 Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 <beni@hallinger.org> 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 <beni@hallinger.org> 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 <beni@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] [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 Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 <lists@group-s.sk>:
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 <beni@hallinger.org> 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 <beni@hallinger.org> 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 <beni@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] [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 Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ 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
Just an illustration of problem of calculation of relative position of scraps based on average altitude of stations. Blue station(s) is bellow pink station(s), but blue scrap is above pink scrap. Martin
3. 6. 2019 v 8:21, Benedikt Hallinger <beni@hallinger.org>:
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?
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 <beni@hallinger.org> 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 <lists@group-s.sk>:
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 <beni@hallinger.org> 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 <beni@hallinger.org> 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 <beni@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] [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 Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ 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
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 <therion-bounces@speleo.sk> On Behalf Of Stacho Mudrak Sent: Friday, 28 June 2019 05:20 To: List for Therion users <therion@speleo.sk> 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 <beni@hallinger.org <mailto:beni@hallinger.org> > 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 <lists@group-s.sk <mailto:lists@group-s.sk> >: 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 <beni@hallinger.org <mailto:beni@hallinger.org> > 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 <beni@hallinger.org <mailto:beni@hallinger.org> > 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 <beni@hallinger.org <mailto:beni@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 <http://2.th> [1] [1]" command in the region.th <http://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 Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
Very nice, cant wait to try it out once it reaches release!
Am 27.06.2019 um 21:49 schrieb Bruce Mutton <bruce@tomo.co.nz>:
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 <therion-bounces@speleo.sk> On Behalf Of Stacho Mudrak Sent: Friday, 28 June 2019 05:20 To: List for Therion users <therion@speleo.sk> 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 <beni@hallinger.org> 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 <lists@group-s.sk>:
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 <beni@hallinger.org> 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 <beni@hallinger.org> 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 <beni@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] [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 Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://2.th [2] http://region.th _______________________________________________ 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
BeniI think that I tend to arrange my projects as you have described. Are you using the 'break' statement in map definitions to enforce the separation of different levels within the cave?If you are, you should not experience random rendering, and it will solve your problem most of the time. The situation where it fails is when one of your regions is generaly lower than another, but there is for example one piece that is higher than and overlaps that other region. In this situation I think that we have to rearrange the map structure (just locally), which is, I admit, philosophically painful. Have I understood your original correctly? BruceSent from my Samsung Galaxy smartphone. -------- Original message --------From: Benedikt Hallinger <beni@hallinger.org> Date: 31/05/19 01:54 (GMT+12:00) To: List for Therion users <therion@speleo.sk> Subject: [Therion] Sorting scraps/maps by height in default mode 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" command in the region.th 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 listTherion@speleo.skhttps://mailman.speleo.sk/listinfo/therion
participants (8)
-
alastair gott -
Benedikt Hallinger -
Bruce Mutton -
Graham Mullan -
Martin Budaj -
Martin Sluka -
Pavel Herich -
Stacho Mudrak