Hi Bruce,
Ok, only a waypoint-block per line in the surface statement should be
enougth to create manually something and still control it free.
I've attached an idea.
A single waypoint could have a name, that printed to the map.
A automatic description of the cardinal/ordinal direction would be very
nice.
Problematic could be, that above the highest surface-profile is now air. And
the background-colour should be switched off?
dirk
Date: Fri, 15 May 2015 19:50:28 +1200
From: Bruce <bruce(a)tomo.co.nz>
Subject: [Therion] Idea: elevation projection surface panorama
To: 'List for Therion users' <therion(a)speleo.sk>
Message-ID: <E2AFDCBE938848648B4643A1DB5B3266@JUICEBRAIN>
Content-Type: text/plain; charset="us-ascii"
Seems like a good idea for the wish list Dirk.
'Panorama' seems like the wrong word to me however.
Conceptually, what you describe would compliment the 'surface' statements we
already have in Therion.
In layouts we already have;
surface [top|bottom|off] that is only really relevant to layouts used with
plan projections.
What you describe would be the natural extension to a projected elevation
context.
So for elevations, your elevation-panorama [on|off] would be surface
[top|bottom|off] (ie do the surface profile drawing layers display over or
beneath the cave drawing), and elevation-panorama grid would be surface
grid.
As you suggest, some way of defining the grid spacing and or a profile trail
would be required.
If I were to use such a feature I would probably want to define sets of
way-points that I could call up at will.
I could imagine using them for extended elevations as well. In that case
one would need to be able to set the profile to 'extend left' or 'extend
right', as, like extended centerlines themselves, the shape of the surface
becomes an artistic endeavor.
Bruce
_____
From: therion-bounces(a)speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf
Of Dirk Peinelt
Sent: Friday, 15 May 2015 3:29 a.m.
To: therion(a)speleo.sk
Subject: [Therion] Idea: elevation projection surface panorama
Hi mappers!
I've an idea for a new Therion-feature.
The feature affects only the elevation view, in a stated view direction.
The target is, to get a map with a elevation projection and a reference to
the surface.
If a surface is integrated in the project, it could be used to generate
automatically a surface-panorama from the surface point-cloud, on the basis
of the elevation-view-direction. And this could be printed to the elevation
map.
(like http://www.viewfinderpanoramas.org/panoramas.html)
With an layout option should it be controlled: e.g.:
elevation-panorama on|grid|off
off:
no surface panorama (default)
on:
One panorama piece, calculated from view direction and the middled object
extension.
Or serval panorama pieces, one per entrance reference or/and the panorama
was calculated by topographic prominence in the integrated surface.
(http://en.wikipedia.org/wiki/Topographic_prominence)
grid:
serval panoramas (each calculated on the grid value, opaque on top of each
other)
Optional:
With a waypointlist in the surface block could be peak's or other interessts
marked.
Or with a new fixed station flag, e.g. "peak".
This would be a nice feature.
Is this possible? Or absolutely utopistic?
//dirk
Hi mappers!
I've an idea for a new Therion-feature.
The feature affects only the elevation view, in a stated view direction.
The target is, to get a map with a elevation projection and a reference to
the surface.
If a surface is integrated in the project, it could be used to generate
automatically a surface-panorama from the surface point-cloud, on the basis
of the elevation-view-direction. And this could be printed to the elevation
map.
(like http://www.viewfinderpanoramas.org/panoramas.html)
With an layout option should it be controlled: e.g.:
elevation-panorama on|grid|off
off:
no surface panorama (default)
on:
One panorama piece, calculated from view direction and the middled object
extension.
Or serval panorama pieces, one per entrance reference or/and the panorama
was calculated by topographic prominence in the integrated surface.
(http://en.wikipedia.org/wiki/Topographic_prominence)
grid:
serval panoramas (each calculated on the grid value, opaque on top of each
other)
Optional:
With a waypointlist in the surface block could be peak's or other interessts
marked.
Or with a new fixed station flag, e.g. "peak".
This would be a nice feature.
Is this possible? Or absolutely utopistic?
//dirk
Hi
Is there a way to use Cyrillic characters in folder and file names? Maybe
it is a setting, which can be configured, but therion.exe doesn't seem to
handle them.
"therion.exe: error -- can't open file for input --
Светата вода/Somecave.th"
The thconfig file itself shows the path properly and is encoded in UTF8.
Thanks
Vladimir
-------------------------------------
Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg
I think I have mastered extended elevations, and have control of extended
centrelines using extend left/right statements within a single top-level
file for an entire cave. This means that it is easy to simultaneously
create different extended elevation shapes from the same parts of the
centreline.
So just because I could, I decided to reflect an entire cave elevation (300m
deep pitch series) after having finished all of the scrap drawings, using;
scrap -flip horizontal and swapping all extend left for extend right etc
Some aspects work nicely, for example;
* Point entity (ie labels etc) alignment relativity is preserved, ie
-align bottom-left, when transformed by -flip horizontal, behaves as if it
is -align bottom-right, and
* Whole scraps join perfectly, ie join 01-SpanishParrotElevEXT-s3
02-SpanishElevEXT-s2
However other aspects are not so good, as can be seen on the attached image;
* Arrows are a problem, ie line arrow, when transformed by -flip
horizontal, ends up with the arrow-heads on the wrong end,
* -text "<left>." (ie justified text, whether explicitly specified or
implicitly inferred), is not transformed by -flip horizontal, so it ends up
looking wrong,
* Joins of specific points on lines end up with undesirable distortion
join 02-s3-rockb:1 07-s1-wall:0 07-s1-rborder:0
#top of passage 3 waters apex
join 02-s3-rockb:end 07-s1-wall:end 07-s1-rborder:end
#btm of passage 3 waters floor
The arrows and text justification are easy, if tedious, to work-around,
however I have not as yet figured out how to fix the joins (the 'correct'
join example in the attached image was modified with Paint.net, not
Therion). I thought it might be something to do with line point numbering
swapping around on transformation, but the lines in this example are only 2
and 3 points long, and combined with the shape of distortion, I think not.
Perhaps it is the bezier curve parameters that are twisting it up on
transformation? Not sure how I could fix that. I also notice that the
nearby but unattached rock is distorted as well.
I have not done an exhaustive test on all line types, so there may be others
that cause problems.
Interested in people's thoughts on whether justified text should be
transformed
And actually I am not just reflecting the elevation because I can (almost),
I made a mistake at the beginning of the survey, so I really would like to
be able to get a clean reflection and produce a quality map. Any
workarounds for the join issue gratefully received.
Thanks
Bruce
