i put together comments to all the posts about "extend" (1) yes, -1 = left, 1 = right and vert is in the middle (0) (2) evaristo, with his proposal of idealized profile not only suggested a way to control shortening, but that also allows stretching. that's good (3) bruce described a procedure for a program to automatically decide how to draw splays in the extended profile. it's more or less what topodroid implements: at a station the range of azimuths is divided into angular sectors one for each leg at that station. a splay is "projected" using the leg of the sector its azimuth falls in. (by the way, to really be in bad luck one need three vert in a row) (4) a program may assign extends to splays automatically, but the user should always be allowed to override what the program does. (that's why a user can set extend also for splays, in topodroid) (5) "cave length": in the (old) manuals i studied that the cave length is "computed" measuring the length of an ideal line that goes thru the middle of the passage. now it is rather cumbersome to compute that line, and all the programs uses the length of the midline, with some discount (duplicate in therion, L in compass, and so on). the problem, i think, is that cave length is not a thing that can be well-defined. so the numbers we give for cave length are an approximation of a fuzzy concept. marco
(5) "cave length": in the (old) manuals i studied that the cave length is "computed" measuring the length of an ideal line that goes thru the middle of the passage. now it is rather cumbersome to compute that line
In Ukraine we are using term "Projected Cave Length", which is length of middle line of cave plan, for more or less horizontal caves, or middle line of extended elevation for vertical ones. In practice good middle line approximation is skeletal line of 2d shape, computed on its vector or raster representation. For doing such for a vector data there are some scripts for AcrGIS by A. Grachev: http://speleo.land.kiev.ua/surveying-cave.html#2-5 Also Global Mapper has feature to compute middle line. So when dealing with therion output i.e. plan in kml format it is possible to compute projected cave length in Global Mapper. If your input to calculate projected cave length is raster monochrome mask of cave internal area in any projection (plan|ext) than you can use thinning algorithm to produce single-pixel line and then vectorize it. There are 2 apps from GRASS Gis to do such - namely r.thin ( https://grass.osgeo.org/grass70/manuals/r.thin.html) and r.to.vect (https://grass.osgeo.org/grass70/manuals/r.to.vect.html) In the 2010 I and A. Vechenko implemented own app to automate cave projected length calculation using raster data: https://bitbucket.org/ngry/cavevaluer/src/CaveValuer/ Raster gets thinned and then vectorized in the way similar to use r.thin + r.to.vect, but in gui app and with different thinning algorithm. Certainly raster-based approach has some drawbacks, such it is unable to do proper calculation for overlapping passages (GlobalMapper capable to handle overlapped plans to compute centerline), you need to do a post-process near entrance areas and so on, but it has significant advantage - raster skeleton can be computed very fast, compared to vector-based algorithms (cavevaluer is not the fastest one, it is possible to do factor 100x faster on GPU). Thinking about how it should be done in general, not relating to projections - is to compute 3d skeleton from 3d cave model, then we will have a good length approximation in all meanings. For convenience, attaching our with A. Verchenko thesis about the raster algorithm in Ukrainian language.
The reason? The map itself is an abstraction. What size of details you will draw? Way not smaller? Etc. etc. What about thermal and hypogenic caves? There is no sense for in this discussion. Martin S. Odesláno z iPhonu 11. 6. 2018 v 9:03, Nikita Kozlov via Therion <therion@speleo.sk>:
(5) "cave length": in the (old) manuals i studied that the cave length is "computed" measuring the length of an ideal line that goes thru the middle of the passage. now it is rather cumbersome to compute that line
In Ukraine we are using term "Projected Cave Length", which is length of middle line of cave plan, for more or less horizontal caves, or middle line of extended elevation for vertical ones.
In practice good middle line approximation is skeletal line of 2d shape, computed on its vector or raster representation.
For doing such for a vector data there are some scripts for AcrGIS by A. Grachev: http://speleo.land.kiev.ua/surveying-cave.html#2-5
Also Global Mapper has feature to compute middle line. So when dealing with therion output i.e. plan in kml format it is possible to compute projected cave length in Global Mapper.
If your input to calculate projected cave length is raster monochrome mask of cave internal area in any projection (plan|ext) than you can use thinning algorithm to produce single-pixel line and then vectorize it.
There are 2 apps from GRASS Gis to do such - namely r.thin (https://grass.osgeo.org/grass70/manuals/r.thin.html) and r.to.vect (https://grass.osgeo.org/grass70/manuals/r.to.vect.html)
In the 2010 I and A. Vechenko implemented own app to automate cave projected length calculation using raster data: https://bitbucket.org/ngry/cavevaluer/src/CaveValuer/ Raster gets thinned and then vectorized in the way similar to use r.thin + r.to.vect, but in gui app and with different thinning algorithm.
Certainly raster-based approach has some drawbacks, such it is unable to do proper calculation for overlapping passages (GlobalMapper capable to handle overlapped plans to compute centerline), you need to do a post-process near entrance areas and so on, but it has significant advantage - raster skeleton can be computed very fast, compared to vector-based algorithms (cavevaluer is not the fastest one, it is possible to do factor 100x faster on GPU).
Thinking about how it should be done in general, not relating to projections - is to compute 3d skeleton from 3d cave model, then we will have a good length approximation in all meanings.
For convenience, attaching our with A. Verchenko thesis about the raster algorithm in Ukrainian language. <Thezy UkrObraz.pdf> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
The map itself is an abstraction What about thermal and hypogenic caves? There is no sense for in this discussion.
We use map as model of cavity shape. Using model we do a measurements on model. Using correspondence between model and reality we make conclusions. It is the scientific approach. Thats it. Cave genesis is not point here, selecting projection of map is the process of selecting more appropriate cavity shape model. Most adequate model is 3d, but for some sort of caves - 2d is enough adequate.
Nice theory. Martin Sluka 11. 6. 2018 v 12:26, Nikita Kozlov via Therion <therion@speleo.sk>:
The map itself is an abstraction What about thermal and hypogenic caves? There is no sense for in this discussion.
We use map as model of cavity shape. Using model we do a measurements on model. Using correspondence between model and reality we make conclusions. It is the scientific approach. Thats it.
Cave genesis is not point here, selecting projection of map is the process of selecting more appropriate cavity shape model. Most adequate model is 3d, but for some sort of caves - 2d is enough adequate.
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Many many years there is the "length of centerline" term for it. It is defined. Martin S. Odesláno z iPhonu 10. 6. 2018 v 14:33, Marco Corvi via Therion <therion@speleo.sk>:
i put together comments to all the posts about "extend"
(1) yes, -1 = left, 1 = right and vert is in the middle (0)
(2) evaristo, with his proposal of idealized profile not only suggested a way to control shortening, but that also allows stretching. that's good
(3) bruce described a procedure for a program to automatically decide how to draw splays in the extended profile. it's more or less what topodroid implements: at a station the range of azimuths is divided into angular sectors one for each leg at that station. a splay is "projected" using the leg of the sector its azimuth falls in. (by the way, to really be in bad luck one need three vert in a row)
(4) a program may assign extends to splays automatically, but the user should always be allowed to override what the program does. (that's why a user can set extend also for splays, in topodroid)
(5) "cave length": in the (old) manuals i studied that the cave length is "computed" measuring the length of an ideal line that goes thru the middle of the passage. now it is rather cumbersome to compute that line, and all the programs uses the length of the midline, with some discount (duplicate in therion, L in compass, and so on). the problem, i think, is that cave length is not a thing that can be well-defined. so the numbers we give for cave length are an approximation of a fuzzy concept.
marco _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (3)
-
Marco Corvi -
Martin Sluka -
Nikita Kozlov