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
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
