| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| extend [2019/01/14 05:47] – [Summary of all extend options, for survey centrelines] add some confusion or not brucemutton | extend [2020/07/07 09:59] – [Enumerating extend station sequence] brucemutton |
|---|
| |
| It turns out, that even though we cannot take extend control outside of centreline definitions, we can take it outside of the trip surveys, and place it in a single file, one for each separate extended centreline. A bit like [[https://survex.com/docs/manual/extend.htm|Survex’s ESpec file approach]]. Having overall control in one place, away from scraps and away from the survey data allows us to keep extended control conceptually and functionally separate, and allows multiple extended centrelines to be readily maintained. | It turns out, that even though we cannot take extend control outside of centreline definitions, we can take it outside of the trip surveys, and place it in a single file, one for each separate extended centreline. A bit like [[https://survex.com/docs/manual/extend.htm|Survex’s ESpec file approach]]. Having overall control in one place, away from scraps and away from the survey data allows us to keep extended control conceptually and functionally separate, and allows multiple extended centrelines to be readily maintained. |
| | |
| | ====Enumerating extend station sequence==== |
| | Shortly after defining your extended centreline, you are likely to want to know what station sequence Therion is using to create the extended centreline.\\ |
| | Add ''log extend'' to your thconfig before the export statement.\\ |
| | Therion will now add to the therion.log file, a transcript of the extend option and station sequence it has used to generate the extended elevation. |
| |
| ====Summary of all extend options, for survey centrelines==== | ====Summary of all extend options, for survey centrelines==== |
| |
| * They must be followed either by a valid survey **<station>** id, or a valid survey **<leg>** (pair of stations).\\ | * They must be followed either by a valid survey **<station>** id, or a valid survey **<leg>** (pair of stations).\\ |
| * Generally specifying a **<leg>** applies the option to ONLY that leg, and specifying a **<station>** applies the option to all subsequent **<legs>** within the centreline. But there is an exception with hide, and perhaps ignore, so read the notes below carefully.\\ | * Generally specifying a **<leg>** applies the option to ONLY that leg, and specifying a **<station>** applies the option to both the leg used to reach that station, and all subsequent **<legs>** within the centreline. But there is an exception with hide, and perhaps ignore, so read the notes below carefully.\\ |
| * You can include multiple caves in the same extended elevation, or [[extend#how_to_export_correct_extended_elevation_from_zig-zag_centerline|straighten out zig-zag surveys]], by way of ''data nosurvey'' legs. | * You can include multiple caves in the same extended elevation, or [[tips#how_to_export_correct_extended_elevation_from_zig-zag_centerline|straighten out zig-zag surveys]], by way of ''data nosurvey'' legs. |
| |
| ''extend start <leg>'' - start generating extended elevation centreline with this leg. (In one case i have found, it can have unexpected effects, even far from the starting leg. I think i prefer 'extend start station' as below.)\\ | ''extend start <leg>'' - start generating extended elevation centreline with this leg. (In one case i have found, it can have unexpected effects, even far from the starting leg. I think i prefer 'extend start station' as below.)\\ |
| ''extend left <leg> or <station>'' - same as for extend right, but extending left!\\ | ''extend left <leg> or <station>'' - same as for extend right, but extending left!\\ |
| \\ | \\ |
| ''extend normal <leg>'' - extend this leg only, in the same direction as the leg immediately previous, then continue extending subsequent legs as per leg immediately previous [I’m not sure when this is particularly useful! I tend to be explicit, and use right or left in preference to normal and reverse.]\\ | ''extend normal <leg>'' - extend this leg only, in the same direction as the leg immediately previous, then continue extending subsequent legs as per leg immediately previous.\\ |
| ''extend normal <station>'' - continue generating all extended centreline legs from this station onwards, in the same direction as the leg immediately previous.\\ | ''extend normal <station>'' - continue generating all extended centreline legs from this station onwards, in the same direction as the leg immediately previous. \\ If extent normal is the first statement after extend start, then it will extend to the right.\\ |
| ''extend reverse <leg>'' - extend this leg only, in the opposite direction to the leg immediately previous, then continue extending subsequent legs as per leg immediately previous.\\ | ''extend reverse <leg>'' - extend this leg only, in the opposite direction to the leg immediately previous, then continue extending subsequent legs as per leg immediately previous.\\ |
| ''extend reverse <station>'' - continue generating all extended centreline legs from this station onwards, in the opposite direction to the leg immediately previous.\\ | ''extend reverse <station>'' - continue generating all extended centreline legs from this station onwards, in the opposite direction to the leg immediately previous. \\ If extent reverse is the first statement after extend start, then it will extend to the left.\\ |
| \\ | \\ |
| ''extend vertical <leg>'' - do not extend this leg horizontally, extend only the vertical component of this leg, then continue extending subsequent legs as per leg immediately previous. The order of stations in your vertical statement should usually match the direction of extended elevation centreline generation. However if Therion seems to ignore this vertical statement, try reversing the order of the stations in your vertical statement, and it might work!\\ | ''extend vertical <leg>'' - do not extend this leg horizontally, extend only the vertical component of this leg, then continue extending subsequent legs as per leg immediately previous. The order of stations in your vertical statement should usually match the direction of extended elevation centreline generation. However if Therion seems to ignore this vertical statement, try reversing the order of the stations in your vertical statement, and it might work!\\ |
| * If leg is part of a loop, it beaks the loop. ie a loop connection gap, with joining map-connection line will be formed between two instances of the first station in the leg specification. | * If leg is part of a loop, it beaks the loop. ie a loop connection gap, with joining map-connection line will be formed between two instances of the first station in the leg specification. |
| The order of stations in your ignore statement should usually match the direction of extended elevation centreline generation. However if Therion seems to ignore your ignore statement, try reversing the order of the stations in your ignore statement, and it might work! In any case, try reversing the order to get a different effect (loop connection gap arrangement). Sometimes the leg specification needs to follow the direction of survey, if it differs from the current direction of extend generation.\\ | The order of stations in your ignore statement should usually match the direction of extended elevation centreline generation. However if Therion seems to ignore your ignore statement, try reversing the order of the stations in your ignore statement, and it might work! In any case, try reversing the order to get a different effect (loop connection gap arrangement). Sometimes the leg specification needs to follow the direction of survey, if it differs from the current direction of extend generation.\\ |
| ''extend ignore <station>'' - where <station> is one leg past a junction in the direction of generation. The generation of extended centreline shall not take this leg. I have found this syntax unreliable, and the following may offer an insight as to why. Marco Corvi says (if I understand correctly) this does not work where there are only three legs meeting at a junction ie the usual case. So only for use where 4 or more legs meeting at junction(?). | ''extend ignore <station>'' - where <station> is one or more legs past a junction in the direction of generation. ie The generation of extended centreline shall not take this leg, but take another one instead. The map-connection break will occur at <station>. A bug in this functionality was resolved with Therion version 094ac85 14Nov2019.\\ |
| Also do not use this syntax where <station> IS the junction station, obviously that will have unpredictable results. \\ | |
| Try to avoid ''ignore''ing the same looped passage (ie an oxbow) at each of its junctions to a main passage. This can have the effect of offsetting the whole oxbow to the far end of the map (which of course is undesirable). \\ | Try to avoid ''ignore''ing the same looped passage (ie an oxbow) at each of its junctions to a main passage. This can have the effect of offsetting the whole oxbow to the far end of the map (which of course is undesirable). \\ |
| <del>''extend break''</del> is mentioned in some Therion posts, presumably as an alias for extend ignore (Survex terminology). It will trigger a Therion error “unknown extend flag – break”.\\ | <del>''extend break''</del> is mentioned in some Therion posts, presumably as an alias for extend ignore (Survex terminology). It will trigger a Therion error “unknown extend flag – break”.\\ |
| Sometimes branch centrelines will be ignored (hidden?) by default, and an extend right (or similar) statement will be required to stimulate it’s generation.\\ | Sometimes branch centrelines will be ignored (hidden?) by default, and an extend right (or similar) statement will be required to stimulate the continuation of the centreline generation.\\ |
| \\ | \\ |
| //There is a lot about ''extend ignore'' behaviour that I do not understand and cannot explain. If anyone has insight or explanations for odd behaviour, please amend this page or post on the forum.// \\ | For more details of how to use ''extend ignore'', see the article [[breakingextend|Breaking extended elevations on specific stations]]. |
| \\ | \\ |
| ''extend hide <leg>'' - hides the centreline part of the specified leg only, but NOT its stations. Stations that form the leg remain visible! Does not hide subsequent stations or legs. \\ | ''extend hide <leg>'' - hides the centreline part of the specified leg only, but NOT its stations. Stations that form the leg remain visible! Does not hide subsequent stations or legs. \\ |
| ''extend hide <station>'' - hides [the station* and] all leg centrelines (usually two of these) that emanate directly from THIS station. Unlike with other extend options, it does not hide subsequent stations or legs. \\ | ''extend hide <station>'' - hides [the station* and] all leg centrelines (usually two of these) that emanate directly from THIS station. Unlike with other extend options, it does not hide subsequent stations or legs. \\ |
| Note that the centreline generation is carried out as per normal, the stations and legs are just made ‘not visible’.\\ | Note that the centreline generation is carried out as per normal, the stations and legs are just made ‘not visible’.\\ |
| | |
| | **Important note:** with ''left'', ''right'', ''normal'', ''reverse'' and ''vertical'', Therion and Pocket Topo both apply the selected options to the leg before the station (in whichever direction Therion is traversing the centreline), as well as the ones following it - that is to say, it applies it to the leg that creates the station. Survex, on the other hand, applies the selected option to all legs after the selected station. This rare difference from Survex is by design. Because of this, and because it helps clarification too, it is a common approach to specify two lines, one saying to apply the option to the initial leg where it is wanted, and one saying to apply the option to that station. This also avoids some bugs mentioned above. |
| | |
| | extend left 3 4 |
| | extend left 4 |
| |
| //* Something I don't understand with 'hide' above, stations are sometimes hidden, and sometimes not.// | //* Something I don't understand with 'hide' above, stations are sometimes hidden, and sometimes not.// |
| |
| ===General Tips=== | ===General Tips=== |
| * Remember to comment out all extend options in the trip surveys before creating a separate extended elevation centreline. I put mine in it’s own file and call it something like Extend-CaveName-ElevEXT.th file. | * Remember to comment out all extend options in the trip survey files before creating a separate extended elevation centreline. I put mine in it’s own file and call it something like Extend-CaveName-ElevEXT.th file. |
| | |
| | * Using this approach, splay shots cannot be controlled (because they have no unique name) independent of the survey legs that they are associated with ie extending a splay left when the legs at that station are extended right. Somewhat contrary to the above point, it seems that you may be able to extend the splays 'in-line' with the survey data, in a trip survey file, so long as you take care not to try to also control the survey legs. |
| |
| * Sometimes, if generating the centreline against the direction of survey, then every <leg> needs to be enumerated, ie they don’t autogenerate if just a single <station> is specified. Other times, they autogenerate nicely. | * Sometimes, if generating the centreline against the direction of survey, then every <leg> needs to be enumerated, ie they don’t autogenerate if just a single <station> is specified. Other times, they autogenerate nicely. |
| * Often specifying one <leg> then in the next line specifying a <station> will stimulate the desired autogeneration. | * Often specifying one <leg> then in the next line specifying a <station> will stimulate the desired autogeneration. |
| |
| * Don't miss Martin Sluka's [[extend#how_to_export_correct_extended_elevation_from_zig-zag_centerline|hot tip for obtaining realistic extended centrelines]] from zig-zagged survey data (uses ''data nosurvey'') | * Don't miss Martin Sluka's [[tips#how_to_export_correct_extended_elevation_from_zig-zag_centerline|hot tip for obtaining realistic extended centrelines]] from zig-zagged survey data (uses ''data nosurvey'') |
| |
| * Caves, or parts of caves that comprise a linear passage with one or two dead-end branches are easiest to generate extended centrelines for. | * Caves, or parts of caves that comprise a linear passage with one or two dead-end branches are easiest to generate extended centrelines for. |