Lazmapviewer: overlaying a semi-transparent area

[alpine]

New commit r9385 for LazMapViewer in lazarus-ccr with opacity and line style issues fixed.
A new point editor added into the designer (double-click the MapView to activate) but largely irrelevant to this particular thread.

[MarkMLl]

Thanks, I'll take a look.

Demo program based on Barkway attached.

Not sure whether you're interested, but also illustrates the problem I describe at https://forum.lazarus.freepascal.org/index.php/topic,67908.msg523761.html#msg523761 ... my code's fairly sloppy but there's some sign errors in there I've not tracked down.

MarkMLl

[MarkMLl]

Appears OK as of r9394, although it's still safest to set the area's bounding line colour explicitly even if that is to clNone. If that is not done then it inherits from the body colour of the last-drawn area, and since the opacity is 100% this tends to be obtrusive. (Note that I'm not complaining, just commenting on how it appears best to use this tool).

I've slimmed my example down by moving the perimeter stuff into a separate unit, and attach the result as a useful demo.

MarkMLl

[alpine]

Appears OK as of r9394, although it's still safest to set the area's bounding line colour explicitly even if that is to clNone. If that is not done then it inherits from the body colour of the last-drawn area, and since the opacity is 100% this tends to be obtrusive. (Note that I'm not complaining, just commenting on how it appears best to use this tool).

Please complain, I'm glad to receive any feedback about LMV.
I would like to fix all that 'side-effects' appearing. Any additions as the opacity makes regressions inevitable and it would be nice when they're spotted to pinpoint them.

FYI there is an additional processing to obtain the track width and color (in TMapView.DrawTrack)

• TMapView.TrackLineColor - when the track color is clDefault, it returns the MapView.DefaultTrackColor (or if there is an ExtraData -> ExtraData.Color, which is a kind of a legacy code left)
• TMapView.TrackLineWidth - when the track width is -1, it returns the MapView.DefaultTrackWidth (or if there is an ExtraData -> ExtraData.Width, same legacy)

Please note that the track width is in mm, not pixels, i.e. = x / 25.4 * ScreenInfo.PixelsPerInchX

I'm surprised that you're observing such a color 'transfer' between objects, there shouldn't be because of the above explained processing, anyway can you tell me what combination of props will show it?

There was such a transfer of opacity, hope it is now fixed.

I've slimmed my example down by moving the perimeter stuff into a separate unit, and attach the result as a useful demo.

Thank you!

I was under impression that the polygon buffering is a something needed for your project, not for the demo itself. I'm not sure it will be valued enough, if noticed at all, when it is executed just once and just shown. However, I hope it will be useful to you and for the forum participants, of course.

[MarkMLl]

I'm surprised that you're observing such a color 'transfer' between objects, there shouldn't be because of the above explained processing, anyway can you tell me what combination of props will show it?

There was such a transfer of opacity, hope it is now fixed.

I can demonstrate it happening with r9384... do you need the details?

I was under impression that the polygon buffering is a something needed for your project, not for the demo itself. I'm not sure it will be valued enough, if noticed at all, when it is executed just once and just shown. However, I hope it will be useful to you and for the forum participants, of course.

The only thing that is going to be dynamic is aircraft moving along (and close to) the circuit, where it would be desirable if they could appear as distinctive blips along a track with the track+blips being removed in its entirety when the contact times out (i.e. has left the area, or turned off all systems after landing). I've got all the state transitions done which involved multiple caches and got a bit hairy.

I believe that could be "interesting" since LMV itself doesn't support distinctive markers due to that sort of thing not being portable across drawing engines. Example at https://github.com/MarkMLl/utils1090/blob/main/1697961664a.png which was the result of several hours monitoring and plotting using QGIS, I'd expect far fewer live tracks ** but it would be desirable to have each distinctive.

** Finger-in-air guess: the airfield's breakfast "fly-in" last September probably had between a dozen and a score live aircraft at any time, including those idling on the ground.

MarkMLl

[alpine]

I'm surprised that you're observing such a color 'transfer' between objects, there shouldn't be because of the above explained processing, anyway can you tell me what combination of props will show it?

There was such a transfer of opacity, hope it is now fixed.

I can demonstrate it happening with r9384... do you need the details?

Yes please.

I was under impression that the polygon buffering is a something needed for your project, not for the demo itself. I'm not sure it will be valued enough, if noticed at all, when it is executed just once and just shown. However, I hope it will be useful to you and for the forum participants, of course.

The only thing that is going to be dynamic is aircraft moving along (and close to) the circuit, where it would be desirable if they could appear as distinctive blips along a track with the track+blips being removed in its entirety when the contact times out (i.e. has left the area, or turned off all systems after landing). I've got all the state transitions done which involved multiple caches and got a bit hairy.

I believe that could be "interesting" since LMV itself doesn't support distinctive markers due to that sort of thing not being portable across drawing engines. Example at https://github.com/MarkMLl/utils1090/blob/main/1697961664a.png which was the result of several hours monitoring and plotting using QGIS, I'd expect far fewer live tracks ** but it would be desirable to have each distinctive.

Have you seen the "flights" example into the LMV? It is different scale/zoom there but similar as moving some blobs around a flight tracks in a timely manner.
Also, now there are OnDrawPoint/OnDrawTrack/OnDrawArea events for POI/Track/Area resp. (see the OI)
You can always inherit from TGPSObj (or descendant) and override its GetArea and Draw methods. You'll be restricted to the TMvCustomDrawingEngine capabilities of course.

[MarkMLl]

{quote]I can demonstrate it happening with r9384... do you need the details?

Yes please.
[/quote]

See attached, note line 127 in maincode.pas which- if commented out- causes the yellow area to inherit red outline from the preceding area.

Have you seen the "flights" example into the LMV? It is different scale/zoom there but similar as moving some blobs around a flight tracks in a timely manner.
Also, now there are OnDrawPoint/OnDrawTrack/OnDrawArea events for POI/Track/Area resp. (see the OI)
You can always inherit from TGPSObj (or descendant) and override its GetArea and Draw methods. You'll be restricted to the TMvCustomDrawingEngine capabilities of course.

I'll take another look once I've finished the current crop of message processing etc.

MarkMLl

[alpine]

I can demonstrate it happening with r9384... do you need the details?

Yes please.

See attached, note line 127 in maincode.pas which- if commented out- causes the yellow area to inherit red outline from the preceding area.

According to the explanation in reply #33 - since the scratchArea  just created at line #117, it has LineColor=clDefault and thus inherits its value from the MapView.DefaultTrackColor (by design), which coincidentally is clRed also.This misleads you into thinking that the color of the "avoids" area has affected the "perimeter" area.

[MarkMLl]

which coincidentally is clRed also.

Ah :-)

MarkMLl

[MarkMLl]

Updated version of my demo program attached. I admit that I've been sweating blood getting the geometry sorted out, but my variant of the code that expands the circuit track to a slightly larger area now works correctly with both clockwise and anticlockwise vertex ordering and has adequate handling of reentrant corners.

Principle of operation is to expand along the mean angle at each vertex with a fudge factor on the length, as an alternative there's code in there that expands along track normals but that really doesn't like reentrants.

I don't think it folds in your most recent changes at https://forum.lazarus.freepascal.org/index.php/topic,67908.msg524478.html#msg524478

Obviously all the juicy maths is in a separate unit so as not to detract from the example showing runtime creation of areas etc..

Feel free to fold it into LMV with the same license etc.

MarkMLl

[MarkMLl]

Final update attached. This sorts out problems in the code to scale along normals, but uses a fudge factor to get something visually acceptable where a vertex (corner of the circuit pattern) is reentrant.

Potential enhancements would be to eliminate reentrants (which are probably handled adequately, at least by scaling along mean angles rather than normals) and to combine multiple circuits into a single outline. However it's most unlikely that I will attempt either of these in the context of this demo program.

MarkMLl