Re: [Therion] Surface or Canyon walls
It is from AUT symbol set: Better idea is "-outline none -clip off" option, because it is surface morphology, not a part of an underground cavity. m.s. On Feb 14, 2017, at 11:48 AM, Henry Bennett via Therion <therion@speleo.sk> wrote: Thanks Martin – your pointer got me there. From thbook - Scrap border consists of lines with the -outline out or -outline in options (passage walls have -outline out by default). So the answer is simply to define a line of type “pitch” with option “–outline out”. From: Martin Sluka [mailto:martinsluka@mac.com] Sent: 14 February 2017 10:19 To: List for Therion users <therion@speleo.sk> Cc: Henry Bennett <henry@hbennett.com> Subject: Re: [Therion] Surface or Canyon walls There is a symbol of surface pit, what is let's say circular canyon. Check wiki. m.s. On Feb 14, 2017, at 11:09 AM, Henry Bennett via Therion <therion@speleo.sk> wrote: What is the accepted standard for handling canyon walls on the surface? I’d like to use a pitch style line but believe I’d have to duplicate the wall and change type to do this. Also requires setting the original wall to invisible. Any ideas? Many thanks, Henry _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Henry There are subtleties associated with the choice between using walls and lines with -outline set, that go beyond appearance and internal passage shading. This from https://therion.speleo.sk/wiki/drawingchecklist Walls <https://therion.speleo.sk/wiki/drawingchecklist#wall> (and lines with -outline in/out) define the outline of the scrap. Walls are just a special type of <https://therion.speleo.sk/wiki/drawingchecklist#lines> line that; * has the option '-outline out' set by default, * clips many symbols that typically only appear inside the cave passage (unless '-outline none' is set), * have their own special subtypes, and altitude labelling, that are not available to other lines, * are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only), * define the shape of previewed (above and below) scrap outlines (other linetypes with -outline set to in or out do not do this <unfortunately>). Like Martin, my preference for surface bluffs and similar features, after experimenting some years ago, is to use… line wall:pit -outline none -clip off (I think the second bullet point statement above, in parentheses is incorrect, maybe should read – unless ‘-clip off’ is set) If I wanted a different appearance to line wall:pit, I would probably redefine the symbol for wall:pit rather than use a non-wall linetype, so that I can retain the scrap joining and preview characteristics of walls. Bruce From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Sluka via Therion Sent: Tuesday, 14 February 2017 11:55 PM To: List for Therion users <therion@speleo.sk> Cc: Martin Sluka <martinsluka@mac.com> Subject: Re: [Therion] Surface or Canyon walls It is from AUT symbol set: Better idea is "-outline none -clip off" option, because it is surface morphology, not a part of an underground cavity. m.s.
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk>: clips many symbols that typically only appear inside the cave passage (unless '-outline none' is set),
In case -outline none Therion is not able to decide which part of symbol (let’s say block) to clip off. But on other hand if there is not -clip off there the symbol (block) will be not appeared.
are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block. m.s.
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: clips many symbols that typically only appear inside the cave passage (unless '-outline none' is set),
In case -outline none Therion is not able to decide which part of symbol (let’s say block) to clip off. But on other hand if there is not -clip off there the symbol (block) will be not appeared.
are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block. m.s.
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm: line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm. lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join. This caused me a fair amount of confusion until I figured it out! Duncan.
You are right There is a short wall which has different setup of subtype and visibility 1. without command join 2. with join subtype invisible 3. with join visibility off But on other hand this is not standard use of invisible wall. It is used to „close“ outline of scraps if there is too wide space between ends of walls or a morphology outside of regular cave should be visible (cave entrances), usually without join: join wall subtype invisible with join visibility off m.s.
17. 2. 2017 v 5:03, Duncan Collis via Therion <therion@speleo.sk>:
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm:
line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm.
lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join.
This caused me a fair amount of confusion until I figured it out!
Duncan. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello, i found out that the declination handling seems to be somewhat inaccurate. The produced error is marginal and negligible with small caves, however i am currently working on a system with >100km and this produces errors of >10m there. What i observe is the following: - Therion seems to use the first day of any given year referenced by "date" command. - If a survey was taken at the end of a year it seems that the 1.1 of the following year will be used (i assume this happens at mid-year). - This approach looses at most half a years magnetic drift. This alone is acceptable as the data by itself is already not that accurate. However if you have several centerlines in the survey, each with different date-commands, therion seems to calculate the average of all dates and then uses the calculated declination for that date (applying the rule above, so taking the "closest 1.1."). This is then applied to all shots of the whole survey. A possible solution to this seems, to get the correct declination for each date and explicitely write suitable "declination" commands that override the "date"-calculated values. This then gives the proper results. I attached a test survey where one can see this easily. The western survey line shows the date-behviour, the right one the explicit declination-commands active. You can see this at the northernmost survey legs, the error on 2km is 13m corresponding to roughly ~0.65% error introduced additionally to the measurement errors itself. I got the values by the GFZ-Potsdam website (http://www-app1.gfz-potsdam.de/cgi-bin/igrf.pl?Year=2013&Month=01&Day=3&alt=...), but note, that the declination has to be converted to decimal degrees. Am i right with my assumptions and is my only solution to this to introduce explicite declination-commands everywhere? Would this easily be fixable in therions code? With best Regards, Benedikt Hallinger
On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
i found out that the declination handling seems to be somewhat inaccurate. The produced error is marginal and negligible with small caves, however i am currently working on a system with >100km and this produces errors of >10m there.
Therion calculates all declination values at the same location (the average location of all the fixed points), which is potentially problematic if your survey spans that sort of distance. I wonder if this might actually be the source of your problems. Survex requires specifying the location to calculate declination values at, and you can use different locations for different parts of the survey hierarchy. So keeping your centreline data in Survex format and feeding therion a 3d file would be one solution if this is the issue you're hitting. (Using the actual location of the station the reading was taken at is hard as you need the declination value to calculate that location. It would also be fairly slow to evaluate the IGRF model at every station where a compass was read.)
What i observe is the following: - Therion seems to use the first day of any given year referenced by "date" command.
If that's from looking at therion's log file, the "geomag declinations (deg)" table there is just a summary. It indeed shows the values on January 1st of each "interesting" year, but doesn't reflect the dates actually being used to calculate declinations for surveys. Or was that from looking at the source code? The get_start_year() and get_end_year() methods actually return a fractional year value, not just the year of the survey. The fraction is calculated assuming each month is 1/12 of the year - not quite right, but probably not a significant error in practice.
- If a survey was taken at the end of a year it seems that the 1.1 of the following year will be used (i assume this happens at mid-year). - This approach looses at most half a years magnetic drift. This alone is acceptable as the data by itself is already not that accurate.
However if you have several centerlines in the survey, each with different date-commands, therion seems to calculate the average of all dates and then uses the calculated declination for that date (applying the rule above, so taking the "closest 1.1."). This is then applied to all shots of the whole survey.
Not sure - I don't know therion's code that well.
A possible solution to this seems, to get the correct declination for each date and explicitely write suitable "declination" commands that override the "date"-calculated values. This then gives the proper results.
This approach is less than ideal, and not just because it's a significant effort. Each generation of the IGRF model is necessarily predictive for dates after it was issued and only declared to be definitive for dates more than 5 years before it was issued. So each new generation of the model can change the declination figures reported for the last 10 years compared to the previous generation. In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give different answers for all dates in 2010 and later (not hugely different one would hope, but your motivation here is to avoid introducing unnecessary errors). See table 1 here for the date information for each IGRF model generation: http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228... So unless you're dealing with historic data, you really want your software to calculate the declination automatically so that you get the benefit of improvements when the IGRF model is updated. Cheers, Olly
If therion calculates the average position of all fixed points this is fine. the cave spans about 5km w/e and about 3km n/s. I strongly dont think this is the error source as it is also visible in the test file. Also, calculating the igrf for each station should not be neccessary unless there are some strong amd small local anomalys which is not the case here. For the date-observation, indeed my conclusion came from the summary in the log. Thank you for claryfying this. Good to hear, therion uses fractions here, and 1/12 is perfectly good. However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer? Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification. The main issue here is, that we have surveys which were taken in the 1950s and extended with an additional centerline in 2000s. Am 2017-02-17 23:26, schrieb Olly Betts:
On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
i found out that the declination handling seems to be somewhat inaccurate. The produced error is marginal and negligible with small caves, however i am currently working on a system with >100km and this produces errors of
10m there.
Therion calculates all declination values at the same location (the average location of all the fixed points), which is potentially problematic if your survey spans that sort of distance. I wonder if this might actually be the source of your problems.
Survex requires specifying the location to calculate declination values at, and you can use different locations for different parts of the survey hierarchy. So keeping your centreline data in Survex format and feeding therion a 3d file would be one solution if this is the issue you're hitting.
(Using the actual location of the station the reading was taken at is hard as you need the declination value to calculate that location. It would also be fairly slow to evaluate the IGRF model at every station where a compass was read.)
What i observe is the following: - Therion seems to use the first day of any given year referenced by "date" command.
If that's from looking at therion's log file, the "geomag declinations (deg)" table there is just a summary. It indeed shows the values on January 1st of each "interesting" year, but doesn't reflect the dates actually being used to calculate declinations for surveys.
Or was that from looking at the source code? The get_start_year() and get_end_year() methods actually return a fractional year value, not just the year of the survey. The fraction is calculated assuming each month is 1/12 of the year - not quite right, but probably not a significant error in practice.
- If a survey was taken at the end of a year it seems that the 1.1 of the following year will be used (i assume this happens at mid-year). - This approach looses at most half a years magnetic drift. This alone is acceptable as the data by itself is already not that accurate.
However if you have several centerlines in the survey, each with different date-commands, therion seems to calculate the average of all dates and then uses the calculated declination for that date (applying the rule above, so taking the "closest 1.1."). This is then applied to all shots of the whole survey.
Not sure - I don't know therion's code that well.
A possible solution to this seems, to get the correct declination for each date and explicitely write suitable "declination" commands that override the "date"-calculated values. This then gives the proper results.
This approach is less than ideal, and not just because it's a significant effort.
Each generation of the IGRF model is necessarily predictive for dates after it was issued and only declared to be definitive for dates more than 5 years before it was issued. So each new generation of the model can change the declination figures reported for the last 10 years compared to the previous generation.
In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give different answers for all dates in 2010 and later (not hugely different one would hope, but your motivation here is to avoid introducing unnecessary errors).
See table 1 here for the date information for each IGRF model generation:
http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228...
So unless you're dealing with historic data, you really want your software to calculate the declination automatically so that you get the benefit of improvements when the IGRF model is updated.
Cheers, Olly
18. 2. 2017 v 9:20, Benedikt Hallinger via Therion <therion@speleo.sk>:
Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification.
The main issue here is, that we have surveys which were taken in the 1950s and extended with an additional centerline in 2000s.
date and date - each survey has calculated its own declination according the date it was surveyed. The position of point for which the declination is calculated is averaged. m.s.
On Sat, Feb 18, 2017 at 9:20 AM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
If therion calculates the average position of all fixed points this is fine. the cave spans about 5km w/e and about 3km n/s.
The change in declination over 5 km distance in your area is about 1' which is completely negligible for compass surveys.
I strongly dont think this is the error source as it is also visible in the test file.
The problem with your test file is that the declination on 2013-12-31 should be 3.08 degrees, not 3.8. If you use 3.08 (or more precisely 3.083333), than the error in the test file is less than 20 cm on 2 km legs. You should also take into account that the declination value at GFZ Potsdam is rounded to the nearest minute.
Also, calculating the igrf for each station should not be neccessary unless there are some strong amd small local anomalys which is not the case here.
IGRF model does not take local anomalies into account anyway.
However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer?
No rounding in therion here.
Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification.
The automatic declination is bound to centreline. You can check it also in your example if you change the date of the first centerline to e.g. 1950. Maybe there is some other source of error in the data? Martin
Am 2017-02-17 23:26, schrieb Olly Betts:
On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
i found out that the declination handling seems to be somewhat inaccurate. The produced error is marginal and negligible with small caves, however i am currently working on a system with >100km and this produces errors of
10m there.
Therion calculates all declination values at the same location (the average location of all the fixed points), which is potentially problematic if your survey spans that sort of distance. I wonder if this might actually be the source of your problems.
Survex requires specifying the location to calculate declination values at, and you can use different locations for different parts of the survey hierarchy. So keeping your centreline data in Survex format and feeding therion a 3d file would be one solution if this is the issue you're hitting.
(Using the actual location of the station the reading was taken at is hard as you need the declination value to calculate that location. It would also be fairly slow to evaluate the IGRF model at every station where a compass was read.)
What i observe is the following: - Therion seems to use the first day of any given year referenced by "date" command.
If that's from looking at therion's log file, the "geomag declinations (deg)" table there is just a summary. It indeed shows the values on January 1st of each "interesting" year, but doesn't reflect the dates actually being used to calculate declinations for surveys.
Or was that from looking at the source code? The get_start_year() and get_end_year() methods actually return a fractional year value, not just the year of the survey. The fraction is calculated assuming each month is 1/12 of the year - not quite right, but probably not a significant error in practice.
- If a survey was taken at the end of a year it seems that the 1.1 of the following year will be used (i assume this happens at mid-year). - This approach looses at most half a years magnetic drift. This alone is acceptable as the data by itself is already not that accurate.
However if you have several centerlines in the survey, each with different date-commands, therion seems to calculate the average of all dates and then uses the calculated declination for that date (applying the rule above, so taking the "closest 1.1."). This is then applied to all shots of the whole survey.
Not sure - I don't know therion's code that well.
A possible solution to this seems, to get the correct declination for each date and explicitely write suitable "declination" commands that override the "date"-calculated values. This then gives the proper results.
This approach is less than ideal, and not just because it's a significant effort.
Each generation of the IGRF model is necessarily predictive for dates after it was issued and only declared to be definitive for dates more than 5 years before it was issued. So each new generation of the model can change the declination figures reported for the last 10 years compared to the previous generation.
In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give different answers for all dates in 2010 and later (not hugely different one would hope, but your motivation here is to avoid introducing unnecessary errors).
See table 1 here for the date information for each IGRF model generation:
http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228...
So unless you're dealing with historic data, you really want your software to calculate the declination automatically so that you get the benefit of improvements when the IGRF model is updated.
Cheers, Olly
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On Sat, Feb 18, 2017 at 10:20:54AM +0200, Benedikt Hallinger via Therion wrote:
If therion calculates the average position of all fixed points this is fine. the cave spans about 5km w/e and about 3km n/s.
Ah, the 100km is total passage length not extent then. For a few km the variation is probably fairly small for most of the world compared to the errors from the instrument readings, though the instrument errors are random and the declination discrepenacy is systematic - systematic errors are worse because they don't lessen when you combine a lot of readings (for random errors the error of the sum increases as the square root of the number of readings - e.g. for 100 readings, the random error only increases 10 times). The grid convergence may well be larger (IIRC therion calculates that at the same average fixed point location; I know that Survex calculates it at the same coordinates you give in "*declination auto"). To quantify these errors, for the coordinates in your test file, 5km E means about 0.015 degrees change in declination and about 0.049 degrees change in grid convergence (in opposite directions).
For the date-observation, indeed my conclusion came from the summary in the log. Thank you for claryfying this. Good to hear, therion uses fractions here, and 1/12 is perfectly good.
To be clear, therion calculates the fractional year taking into account the day of the month - it just doesn't assign quite equal lengths to every day of the year, but instead puts the start of each month 1/12 of a year apart, and then splits up each 1/12 into 28, 29, 30 or 31 equal pieces. Really it should split the year into 365 or 366 equal pieces.
However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer?
Aven currently only shows a whole number of degrees, which is unhelpful for this sort of thing. It probably ought to show one decimal place.
Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification.
I think you need Stacho or Martin to comment on whether that's happening. Cheers, Olly
Thank you everybode for those insights! It is good to hear therion is this accurate, however i need to learn what i understand wrong in the test data. Is the centerline shown in aven correct and only the displayed angles rounded (i.e. the calculated coordinates are valid)? How about loch? Am 2017-02-18 23:24, schrieb Olly Betts:
On Sat, Feb 18, 2017 at 10:20:54AM +0200, Benedikt Hallinger via Therion wrote:
If therion calculates the average position of all fixed points this is fine. the cave spans about 5km w/e and about 3km n/s.
Ah, the 100km is total passage length not extent then.
For a few km the variation is probably fairly small for most of the world compared to the errors from the instrument readings, though the instrument errors are random and the declination discrepenacy is systematic - systematic errors are worse because they don't lessen when you combine a lot of readings (for random errors the error of the sum increases as the square root of the number of readings - e.g. for 100 readings, the random error only increases 10 times).
The grid convergence may well be larger (IIRC therion calculates that at the same average fixed point location; I know that Survex calculates it at the same coordinates you give in "*declination auto"). To quantify these errors, for the coordinates in your test file, 5km E means about 0.015 degrees change in declination and about 0.049 degrees change in grid convergence (in opposite directions).
For the date-observation, indeed my conclusion came from the summary in the log. Thank you for claryfying this. Good to hear, therion uses fractions here, and 1/12 is perfectly good.
To be clear, therion calculates the fractional year taking into account the day of the month - it just doesn't assign quite equal lengths to every day of the year, but instead puts the start of each month 1/12 of a year apart, and then splits up each 1/12 into 28, 29, 30 or 31 equal pieces. Really it should split the year into 365 or 366 equal pieces.
However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer?
Aven currently only shows a whole number of degrees, which is unhelpful for this sort of thing. It probably ought to show one decimal place.
Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification.
I think you need Stacho or Martin to comment on whether that's happening.
Cheers, Olly
On Sun, Feb 19, 2017 at 01:50:45PM +0200, Benedikt Hallinger via Therion wrote:
Thank you everybode for those insights! It is good to hear therion is this accurate, however i need to learn what i understand wrong in the test data.
Is the centerline shown in aven correct and only the displayed angles rounded (i.e. the calculated coordinates are valid)? How about loch?
Not sure about loch, but (as I mentioned in the message you replied to) released versions of aven indeed show the bearing of the measuring line as an integer (probably actually truncated to the integer <= the value rather than rounded). I've already pushed a change to show one decimal place, as this thread reminded me that I'd been meaning to sort this out, and it was a simple issue to address. Cheers, Olly
On Sun, Feb 19, 2017 at 09:00:52PM +0000, Olly Betts via Therion wrote:
On Sun, Feb 19, 2017 at 01:50:45PM +0200, Benedikt Hallinger via Therion wrote:
Is the centerline shown in aven correct and only the displayed angles rounded (i.e. the calculated coordinates are valid)? How about loch?
Not sure about loch, but (as I mentioned in the message you replied to) released versions of aven indeed show the bearing of the measuring line as an integer (probably actually truncated to the integer <= the value rather than rounded).
Someone smarter than me just pointed out that you're actually asking if the angles in the displayed centreline are also rounded. The only rounding of the centreline is that coordinates in the 3d file are stored in centimetres, which should have a negligible effect on the ~1000m long legs in your testcase. Cheers, Olly
On Sat, Feb 18, 2017 at 10:24 PM, Olly Betts via Therion <therion@speleo.sk> wrote:
For a few km the variation is probably fairly small for most of the world compared to the errors from the instrument readings, though the instrument errors are random and the declination discrepenacy is systematic - systematic errors are worse because they don't lessen when you combine a lot of readings (for random errors the error of the sum increases as the square root of the number of readings - e.g. for 100 readings, the random error only increases 10 times).
The grid convergence may well be larger (IIRC therion calculates that at the same average fixed point location; I know that Survex calculates it at the same coordinates you give in "*declination auto"). To quantify these errors, for the coordinates in your test file, 5km E means about 0.015 degrees change in declination and about 0.049 degrees change in grid convergence (in opposite directions).
BTW, there is even more significant source of (possibly systematic) error: daily variation of magnetic declination. A real world example of the daily variation of declination from an average value in the central Europe is: 0 AM: 0' 5 AM: -6' 10 AM: 0' 1 PM: +7' 6 PM: +1' 10 PM: -1' In this case you get a systematic error of about 4'-7' (0.07-0.12 degrees) if you regularly survey between 11 AM and 3 PM in the summer (the daily variation is lower in the winter). For other example end an explanation check http://www.geomag.bgs.ac.uk/education/earthmag.html#_Toc2075560 Martin
On Sat, Feb 18, 2017 at 09:24:42PM +0000, Olly Betts via Therion wrote:
On Sat, Feb 18, 2017 at 10:20:54AM +0200, Benedikt Hallinger via Therion wrote:
For the date-observation, indeed my conclusion came from the summary in the log. Thank you for claryfying this. Good to hear, therion uses fractions here, and 1/12 is perfectly good.
To be clear, therion calculates the fractional year taking into account the day of the month - it just doesn't assign quite equal lengths to every day of the year, but instead puts the start of each month 1/12 of a year apart, and then splits up each 1/12 into 28, 29, 30 or 31 equal pieces. Really it should split the year into 365 or 366 equal pieces.
FYI, I submitted a patch to address this which Stacho has merged, so the next release should calculate this using even sized days (leap years aside): https://github.com/therion/therion/pull/52
However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer?
Aven currently only shows a whole number of degrees, which is unhelpful for this sort of thing. It probably ought to show one decimal place.
The next release of Survex will show one decimal place. Cheers, Olly
Thanks Duncan and Martin I was not aware of this distinction between the different (in)visibilities for wall behaviour. I'll add it to the wiki page. -----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Duncan Collis via Therion Sent: Friday, 17 February 2017 5:04 PM To: List for Therion users <therion@speleo.sk> Cc: Duncan Collis <duncan.collis@gmail.com> Subject: Re: [Therion] Surface or Canyon walls On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm: line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm. lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join. This caused me a fair amount of confusion until I figured it out! Duncan. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Please, don't do it! It is evidently a bug. Invisible wall must not change the behaviour of clipping. In any case. I'll do one test more to see which way is correct. Martin Odesláno z iPhonu 19. 2. 2017 v 0:54, Bruce Mutton via Therion <therion@speleo.sk>:
Thanks Duncan and Martin I was not aware of this distinction between the different (in)visibilities for wall behaviour. I'll add it to the wiki page.
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Duncan Collis via Therion Sent: Friday, 17 February 2017 5:04 PM To: List for Therion users <therion@speleo.sk> Cc: Duncan Collis <duncan.collis@gmail.com> Subject: Re: [Therion] Surface or Canyon walls
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm:
line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm.
lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join.
This caused me a fair amount of confusion until I figured it out!
Duncan. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Too late. In any case I don't think it looks like a bug. I think the difference is a good thing, it gives valuable drawing options and the -visibility off for walls seems to be consistent behaviour with -visibility off for other line types. I'm not sure it affects clipping unless wall subtype outline is none. Testing would to be good, just to be sure. Bruce -----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Sluka via Therion Sent: Sunday, 19 February 2017 9:11 PM To: List for Therion users <therion@speleo.sk> Cc: Martin Sluka <martinsluka@mac.com> Subject: Re: [Therion] Surface or Canyon walls Please, don't do it! It is evidently a bug. Invisible wall must not change the behaviour of clipping. In any case. I'll do one test more to see which way is correct. Martin Odesláno z iPhonu 19. 2. 2017 v 0:54, Bruce Mutton via Therion <therion@speleo.sk>:
Thanks Duncan and Martin I was not aware of this distinction between the different (in)visibilities for wall behaviour. I'll add it to the wiki page.
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Duncan Collis via Therion Sent: Friday, 17 February 2017 5:04 PM To: List for Therion users <therion@speleo.sk> Cc: Duncan Collis <duncan.collis@gmail.com> Subject: Re: [Therion] Surface or Canyon walls
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm:
line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm.
lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join.
This caused me a fair amount of confusion until I figured it out!
Duncan. _______________________________________________ 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
Bruce, check attached images. „subtype invisible“ ("wall:invisible“) is correct, "-visibility off" behavior is definitely bug: m.s.
19. 2. 2017 v 9:21, Bruce Mutton via Therion <therion@speleo.sk>:
Too late. In any case I don't think it looks like a bug. I think the difference is a good thing, it gives valuable drawing options and the -visibility off for walls seems to be consistent behaviour with -visibility off for other line types.
I'm not sure it affects clipping unless wall subtype outline is none.
Testing would to be good, just to be sure.
Bruce
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Sluka via Therion Sent: Sunday, 19 February 2017 9:11 PM To: List for Therion users <therion@speleo.sk> Cc: Martin Sluka <martinsluka@mac.com> Subject: Re: [Therion] Surface or Canyon walls
Please, don't do it! It is evidently a bug. Invisible wall must not change the behaviour of clipping. In any case.
I'll do one test more to see which way is correct.
Martin
Odesláno z iPhonu
19. 2. 2017 v 0:54, Bruce Mutton via Therion <therion@speleo.sk>:
Thanks Duncan and Martin I was not aware of this distinction between the different (in)visibilities for wall behaviour. I'll add it to the wiki page.
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Duncan Collis via Therion Sent: Friday, 17 February 2017 5:04 PM To: List for Therion users <therion@speleo.sk> Cc: Duncan Collis <duncan.collis@gmail.com> Subject: Re: [Therion] Surface or Canyon walls
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm:
line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm.
lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join.
This caused me a fair amount of confusion until I figured it out!
Duncan. _______________________________________________ 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
You are right, there are two kinds of behavior, so it should not be bug, but very important difference: 1. wall „-visibilty off" will create normal wall, just invisible. 2. wall "-subtype invisible“ will create dummy wall, just to restrict a scrap Funny, I never think about it. m.s.
19. 2. 2017 v 9:21, Bruce Mutton via Therion <therion@speleo.sk>:
Too late. In any case I don't think it looks like a bug. I think the difference is a good thing, it gives valuable drawing options and the -visibility off for walls seems to be consistent behaviour with -visibility off for other line types.
I'm not sure it affects clipping unless wall subtype outline is none.
Testing would to be good, just to be sure.
Bruce
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Sluka via Therion Sent: Sunday, 19 February 2017 9:11 PM To: List for Therion users <therion@speleo.sk> Cc: Martin Sluka <martinsluka@mac.com> Subject: Re: [Therion] Surface or Canyon walls
Please, don't do it! It is evidently a bug. Invisible wall must not change the behaviour of clipping. In any case.
I'll do one test more to see which way is correct.
Martin
Odesláno z iPhonu
19. 2. 2017 v 0:54, Bruce Mutton via Therion <therion@speleo.sk>:
Thanks Duncan and Martin I was not aware of this distinction between the different (in)visibilities for wall behaviour. I'll add it to the wiki page.
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Duncan Collis via Therion Sent: Friday, 17 February 2017 5:04 PM To: List for Therion users <therion@speleo.sk> Cc: Duncan Collis <duncan.collis@gmail.com> Subject: Re: [Therion] Surface or Canyon walls
On 15/02/2017, Martin Sluka via Therion <therion@speleo.sk> wrote:
14. 2. 2017 v 19:30, Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk>>: are used by the scrap join algorithm to decide which line ends to join (for visible wall lines only),
For automatic scrap join algorithm. But you may join any kind of lines at any line points - typically wall to corner of block
It's worth noting that there are two different ways of making a wall line invisible in Therion, which are treated differently by the automatic scrap join algorithm:
line wall -subtype invisible The wall line is not displayed, and will be ignored by the scrap join algorithm.
lne wall -visibility off The wall line is not displayed, but can be used by the scrap join algorithm when it chooses which points to join.
This caused me a fair amount of confusion until I figured it out!
Duncan. _______________________________________________ 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
participants (6)
-
Benedikt Hallinger -
Bruce Mutton -
Duncan Collis -
Martin Budaj -
Martin Sluka -
Olly Betts