[Therion] Joining surveys at a curved/sloping pitch

[Duncan Collis]

I've been running into the problem of how to join scraps at curved
lines as well and had come up with essentially the same solution as
Tarquin. However I sometimes find that the two lines that are joined
at every point still don't follow each other closely enough, leaving
either a gap or an overlap. Also, it becomes much more difficult when
the two scraps are in different th2 files - I've used an Excel
spreadsheet to transform coordinates from one file to another with
moderate success, but again sometimes find that the lines don't quite
follow each other.

My dream is to have a syntax like:

# in one scrap...
line wall -id wall1
  [points]
endline

# in another scrap
line wall -conform wall1

with the -conform wall1 telling Therion to make the line's path
exactly follow the specified line (in this case wall1) in the final
output.

A different approach would be able to specify the background colour of
an area within one scrap by referring to the name of another scrap,
with Therion applying whatever that scrap's background colour is to
the area in question.

Best regards,

Duncan

On 11/05/2019, Bruce Mutton <bruce at tomo.co.nz> wrote:
>> If the two scraps are in the same map layer (i.e. not separated by a break
>> line in the map definition) then the upper scrap will completely hide any
>> part of the lower scrap which passes under it.
>
>> So the lower scrap curved outline of the pit bottom can be quickly drawn a
>> bit larger than the curved line of the pit in the upper scrap, as any
>> overlap will be hidden.
>
>
>
> Not sure I've experienced that behaviour, but then I always have -
> transparency on with a midrange opacity set.  Scraps on the same layer that
> overlap tend to render poorly with those settings.
>
>
>
>>>     Perhaps a way forward would be a feature whereby a passage fill area
>
>>>     be defined that is completely transparent to show any scraps that
>
>>>     happen to pass below it.
>
>
>
> I imagine that at the time a scrap is rendered, the code  cannot know
> whether there will be a scrap below/behind.   But I don't know.
>
> But still, maybe...
>
>
>
> area open(ing)
>
>                 -place bottom #always
>
>                 -clip on #always
>
>                 -visibility [on|off] #off effectively disables the 'opening'
> effect, as though the area was not specified at all
>
>                 -fill-* # background colour in the ‘opening’ as below
>
>                ... border line references ...
>
> endarea
>
>
>
> I imagine the opacity of the 'area open' could be set to some fraction of
> the opacity set for the current layout.  That would give the relative
> impression of transparency, and would let the colour of the passage below
> bleed through.  It could be a default setting, or user definable.
>
> To account for scenarios where there is no passage surveyed or drawing
> immediately below, or if Therion indeed cannot know whether there will be a
> scrap rendered below the current scrap, there could be -fill-* options to
> set the underlying colour.
>
> It would need to accommodate the -lookup -map-fg options
> <https://therion.speleo.sk/wiki/examples?s%5b%5d=lookup#colour_scales_-_lookups>
>  that apply to the layout, and respond appropriately to a user input.
>
> ie
>
> colour map-fg altitude would need area open to accept say -fill-station
> 23 at survey02, or
>
>
>                                    -fill-altitude 850 m, or
>
>
>                                    -fill-colour [r g b]
>
> colour map-fg explo-date or topo-date would need area open to accept say
> -fill-survey survey02 *, or
>
>
>
> -fill-date <date>, or
>
>
>
> -fill-colour [r g b]
>
> * each centreline or subsurvey could have a different date, so I guess it
> would just average the date of all centrelines in the survey.
>
> colour map-fg map or scrap would need area open to accept say -fill-map or
> fill-scrap <map or scrap name>, or
>
>
>
> -fill-colour [r g b]
>
> I guess multiple fill colour options could be set in any one area, and
> options inappropriate to the current lookup would be silently ignored, and
> the last valid fill-option defined would be the one implemented for a
> particular area at compile time.
>
>
>
> This arrangement would allow the user to easily specify outputs that would
> be consistent across a number of different selection, map, lookup and export
> scenarios.
>
>
>
> Its getting complicated now.  Sorry coders…
>
> Bruce
>
>
>
> -----Original Message-----
>
> From: Therion <therion-bounces at speleo.sk> On Behalf Of Tarquin Wilton-Jones
> via Therion
>
> Sent: Saturday, 11 May 2019 09:33
>
> To: therion at speleo.sk
>
> Cc: Tarquin Wilton-Jones <tarquin.wilton-jones at ntlworld.com>
>
> Subject: Re: [Therion] Joining surveys at a curved/sloping pitch
>
>
>
>>>     Perhaps a way forward would be a feature whereby a passage fill area
>
>>>     be defined that is completely transparent to show any scraps that
>
>>>     happen to pass below it.
>
>>
>
>>
>
>> Genius! I really want this feature. Don't know if it is possible, but
>
>> I want it anyway.
>
>
>
>
>
> -outline hollow -fillstation 23
>
>
>
> meaning that wherever there is nothing behind it, it should take its colour
> from station 23. but that would mean it is impossible to colour unless there
> is a relevant station in the same survey (no idea of how to mix stations).
> And if there are three passages stacked under each other at the pitch (which
> is the case for one of mine), then it might think it doesn't need to render
> the fill colour because there is a passage there, even though the pitch
> doesn't actually connect to that passage. So there would be some kinks to
> work out.
>
> _______________________________________________
>
> Therion mailing list
>
> Therion at speleo.sk
>
> https://mailman.speleo.sk/listinfo/therion
>
>