### Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook

### Author Topic: Scaling a "skewed polygon"  (Read 2142 times)

#### alpine

• Hero Member
• Posts: 1210
##### Re: Scaling a "skewed polygon"
« Reply #15 on: July 18, 2024, 01:26:30 pm »
Here is the faulty calculation (which I deliberately neglected)
Code: Pascal  [Select][+][-]
1.   // Calculate expansion meters to pixels for the DoSegm/OfsLine
2.   ExpandPt := Point(
3.     Round(expandMetres * 1.0/68 * CI_FACTOR),
4.     Round(expandMetres * 1.0/111 * CI_FACTOR));
5.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

#### MarkMLl

• Hero Member
• Posts: 7247
##### Re: Scaling a "skewed polygon"
« Reply #16 on: July 18, 2024, 02:12:26 pm »
Ah- meters to pixels. I see.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

#### alpine

• Hero Member
• Posts: 1210
##### Re: Scaling a "skewed polygon"
« Reply #17 on: July 18, 2024, 02:26:06 pm »
Ah- meters to pixels. I see.
Even the comment is wrong
Should be in equirectangular units (LatLonToXY, XYToLatLon)
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

#### MarkMLl

• Hero Member
• Posts: 7247
##### Re: Scaling a "skewed polygon"
« Reply #18 on: July 18, 2024, 02:58:44 pm »
Ah- meters to pixels. I see.
Even the comment is wrong
Should be in equirectangular units (LatLonToXY, XYToLatLon)

Actually, I'm still scratching my head over that one: changing CI_FACTOR (e.g. to 10) appears to have no effect.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

#### alpine

• Hero Member
• Posts: 1210
##### Re: Scaling a "skewed polygon"
« Reply #19 on: July 18, 2024, 03:46:35 pm »
Ah- meters to pixels. I see.
Even the comment is wrong
Should be in equirectangular units (LatLonToXY, XYToLatLon)

Actually, I'm still scratching my head over that one: changing CI_FACTOR (e.g. to 10) appears to have no effect.

MarkMLl
This is the factor to make equirectangular coords integers suitable for TPoint. See LatLonToXY, XYToLatLon. Changing it will affect only the significance/precision (Range checks?).
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

#### alpine

• Hero Member
• Posts: 1210
##### Re: Scaling a "skewed polygon"
« Reply #20 on: July 22, 2024, 01:08:56 pm »
Since my trackToArea2 was so wrong at expansion offset calculation, I've performed some point-and-click measurements, found the miscalculation and corrected it:
Code: Pascal  [Select][+][-]
1.   // Calculate expansion meters to pixels for the DoSegm/OfsLine
2.   Rp.InitLatLon( // Rp: TRealPoint
3.     expandMetres * 1.0/111000,
4.     expandMetres * 1.0/68000);
5.   ExpandPt := LatLonToXY(Rp);
6.
8.   ExpandPt := Point(
9.     Round(expandMetres * 1.0/68) * CI_FACTOR,
10.     Round(expandMetres * 1.0/111) * CI_FACTOR);

Meanwhile, I've noticed that in your trackToArea1 the  region points were moved along the beam from the center of the bounding box. That moves vertices by the given distance, but results in a smaller distances between the line segments.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

#### MarkMLl

• Hero Member
• Posts: 7247
##### Re: Scaling a "skewed polygon"
« Reply #21 on: July 22, 2024, 09:04:13 pm »
Thanks, I'll take a look at that tomorrow.

I've been experimenting trying to get as much as possible done using simple geometry, the incentive- on reflection- being that I want the result to be easily processed by checks for whether an aircraft is following the circuit, close to the circuit and so on since different levels of alert apply.

I'm 50+ years out of practice at this sort of stuff :-)

I've got it working fairly well- including for reentrant angles- if I expand along the mean corner angle with a fudge factor so that the actual distance outside the circuit is realistic. I've not yet got it working if I try to expand along normals: I obviously know that it's basically just a lot of sin/cos stuff and while I can visualise what I'm trying to do I'm having a hard time getting it right in practice :-/

I'll probably put a few more hours into it tomorrow, but what I've got is visually OK and in practice smaller airfields will generally have a simple rectangular circuit: I suspect that the local field's kinked approach is fairly unusual which makes being able to handle that from the start useful.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

#### alpine

• Hero Member
• Posts: 1210
##### Re: Scaling a "skewed polygon"
« Reply #22 on: July 22, 2024, 09:44:52 pm »
Thanks, I'll take a look at that tomorrow.
No problem. I wanted just to resolve this in order to put it as an example in LMV.
I've been experimenting trying to get as much as possible done using simple geometry, the incentive- on reflection- being that I want the result to be easily processed by checks for whether an aircraft is following the circuit, close to the circuit and so on since different levels of alert apply.
IMHO Sin/cos for normals is not an issue since the expansion circuit will be calculated just once, then saved. The proximity checks can be performed fairly easy, even the distance between each pair of points in the expanded circuit (denominator) can be pre-calculated. Once a series of expanded circuits have been pre-computed (for each alarm), then the proximity check should be a simple check of which is the most outer circuit that the aircraft is inside of.
That is even easier - just the sign of the oriented distance must be the same for all segments, no need for magnitude.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000