forums.silverfrost.com

[Kenneth_Smith]

Works very well in this example:

https://www.dropbox.com/sh/n3x2o37tzlpb14u/AAAwtVLFlno5gLvN3a9f-SI6a?dl=0

[Kenneth_Smith]

Re item C)

Surely you know the physical coordinates corresponding to the top left and bottom right corners of your image, and GET_DIB_SIZE@ gives you the dimensions of the image in pixels.

So for the horizontal direction the physical coordinates of the image range from xmin to xmax, and the pixel coordinates of the image range from 1 to width (or pmax) returned by GET_DIB_SIZE@.

For the physical range [xmin,xmax] and the pixel range [1,pmax], then a value x in the range [xmin,xmax] is linearly mapped to a value p in the range [1,pmax] (using real arithmetc) as

p = 1 + (x-xmin)*(pmax-1)/(xmax - xmin)

Same for the vertical direction.

The top left and bottom right pixel coordinates of the %pl frame can be calculated from the %pl graphics width, height, and margins.

The corresponding physical coordinates can be determined from GET_PLOT_DATA@.

Using these physical coodinates and the linear mapping, you can calculate SX, SY, SWIDTH, SHEIGHT for COPY_GRAPHICS_REGION@ for any x and y ranges displayed by %pl, such that the different coordinate systems are correctly aligned.

Unfortunately, I cannot comment on the correction of planar (stretch) distortion in your image.

PS The required mathematics to undistort photographs taken of a flat piece of land photographed from an angle are clearly described here http://paulbourke.net/geometry/transformationprojection/

[Martin_K]

Many thanks for your kind help, Ken!

Now, it is clear and understandable what means a pixel coordinate system and how it is associated with real geodetic coordinates in the graph.
It is pity that such essential information is not available in the on-line help (at least � I did not find it there).

Based on your explanation I added automatic computation of graph�s scale, which is written next to the graph as can be seen below
(scale is an important and essential information for any surveyor when dealing with graphs/maps):



I plan to add to the graph above in the future also some statistical data for lines (like total line length, line length of each segment and maybe more � simply
properties of each map�s object. I hope, I will be able to do it, since it requires quite extensive coding and the use of drawing functions of FTN95.
With respect to the scale in the graph above I have two simple questions:

1. As can be seen in the picture above, the computed scale is exact scale based on pixel and meter conversion (1px = 0.0002645833m) between two pairs of identical points having both pixel and real geodetic coordinates.
However, I would like to round it (since the scale like the one in the graph � 1:33927 is very unusual).
Is there an intrinsic function in FTN95 (I do NOT mean ANINT/CEILING/FLOOR functions since it seems to me that they do not provide what I exactly want) which would round the number provided as argument to the whole tens or hundreds? (I mean � for example � to round the scale 1:33927 to 1:33900 or 1:34000).

Although, it would be a little bit deceptive, it looks much better.

2. I would also like to import to the graph a north sign (north arrow) which points to the north. Should I use the same functions (GET_DIB_SIZE@ and IMPORT_FILE_IMAGE@) like in the case of JPG import?


Regarding your answer to the item C and the link you provided: Thanks. The datum transformations and different map projections was/is my professional job. This was main topic of my dissertation of which practical result was a software called DatTra � Datum Transformation which computes 3D transformations between global geocentric coordinate systems like WGS-84 (World Geodetic System 1984) and/or ETRF-89 (European Terrestrial Reference Frame 1989) and our local coordinate systems used in Slovakia (System of unified cadastral network � S-JTSK, based on local Bessel�s ellipsoid and Krovak�s projection and a former military coordinate system S-42 (based on Krasovsky�s ellipsoid and Gauss-Kruger projection, which is similar to UTM � Universal Transversal Mercator projection) and vice-versa. In the past, we had the DatTra package (of which I am main co-author) as standalone utility, but now � we also have it in DLL version which can be built-in in any GIS software package. In fact, it is also built-in in such packages like ESRI ArcGIS or Q-GIS. They have a default transformation also for Slovakia, nevertheless it is not precise enough, so some customers in Slovakia with the highest requirements with respect to accuracy selected to built-in our DLL functionality.

With respect to the distortion of the raster JPG image overlayed in the graph of points/lines: I am afraid that it cannot be fully aligned, since the raster JPG is pure image with no coordinate association (therefore I suggested to have an option in %PL to load in a geo-referenced image). Maybe it can be reduced with much effort.

[Kenneth_Smith]

Martin,

This may help, but the question of rounding numbers (particularly negative numbers) opens a "can of worms". This function round_n10 rounds to a power of 10 symmetrically about zero. Where the input data would cause an integer overflow, the returned number is simply returned unrounded.

[Kenneth_Smith]

Or more simply:-

[Martin_K]

Great Ken!

The one-line code for rounding is brilliant (to paraphrase a classic: all brilliant ideas and their beauty ground in their simplicity).
In the meantime, I added the logo for N/S/E/W directions as can be seen in the picture below (the letters in the logo are in slovakian: S=sever/north, J=juh/south, V=v�chod/east, Z=z�pad/west).
As can also be seen in the picture, I was able to adjust the JPG image exactly between the axes (what I also wanted). However, this was achieved (again) by experimenting only.



I use the code for adjusting JPG image in the graph (after its import using IMPORT_FILE_IMAGE@) as follows:

[Kenneth_Smith]

Martin,

Why is the second argument passed to COPY_GRAPHICS_REGION@ the variable MRIGHT?

Suggest you print out all the relevant variables so that you can do a manual check.

Also are you getting mixed up between gw, gh, and dw, dh ?

Is there a %pv in your code before the %pl? That might be causing problems since the graphics width and height of the %pl will change when the user resizes the window - I can see you have used %ww which permits this.

[Martin_K]

Ken,

see my picture of how I understand the pixel coordinate system on the display in my post of Mon Mar 22, 2021 11:24 am in this conversation.

So, the WHOLE window area (it means whole size of the windows, where all these things are displayed) has the following dimensions:

width (gw) = 1400, height (gh) = 800

This size 1400x800 of the whole window includes all (caption of the window, graph itself and buttons to the right and also the OK button at the bottom).

The graph itself (where lines, points and raster JPG image are drawn and displayed) has the dimension of 1000x 575 since I used the margins mright=200, mleft=200, mtop=100 and mbottom=125 (so 1400-200-200=1000 and 800-100-125=575).

As I understand it, the origin of my drawing surface (area of 1000x575) has its pixel coordinates at the values MLEFT, MTOP. And YES, formally it is an error to use MRIGHT (my mistake - thanks for revealing it, I already corrected it to MLEFT, but in this specific case, it caused no harm due to the fact that MLEFT=MRIGHT=200). Therefore I used the variable MLEFT in the COPY_GRAPHICS_REGION@ as one of its offset values to be able to paste the top left corner of the JPG raster exactly on the top left corner of may graph area (on its origin).

Maybe I should somehow compute the SX, SY values, since in the copy function I use for them both ZERO values.

The dh is my typing error and is - in fact - gh (I do not use the dh variable in my program at all).
Although I use %ww, I have NO use of %pv within the whole program.

I will check all above mentioned variables once again by printing them out to visually confront their values - as you suggested.[/b]

[Kenneth_Smith]

OK, you have told me the same thing twice, and I thought it was incorrect the first time.

If width (gw) = 1400, height (gh) = 800 are the values used to define the %pl region, then this is not the size of the whole window.

These sizes define the size of the rectangular graphics area into which the %pl graph including its margins are drawn.

The buttons on the RHS and the OK button are not in the graphics region. They are in the ClearWin+ window, as is the %pl graphics region which has the dimensions specified in the winio@ call which sets up the %pl.

Here is a simple example, which draws two graphs sequentially. The size of the %pl graphics region is the same in each case, but the overall window size differs.

[Martin_K]

Thanks Ken for your correction of my wrong imagination!
I will try to find out how to compute in the program the offsets
for imported JPG raster image (IMPORT_FILE_IMAGE@ offsets)
BEFORE pasting it on the graph to coincide exactly with the axes.

Now, I added some statistics to the graph (in yellow rectangle). All numbers there are variables extracted from input data:



I would like to use different colors for the numbers (red for all) in the statistics (8.5 km is length of the route,
20 means different sections of the route, 2098 means number of surveyed points during mapping of the route and 57.12m is the maximum height difference between two points).

So the text would be black as it is now and the numbers (variables) would be in red.

I use the following code to write a string (for SCALE as example):

[Kenneth_Smith]

Martin,

Split each of output strings into two strings, one with the description and one with the number values.

The first is written using draw_characters@(description(i),x,y,rgb@(0,0,0))

The second is draw_characters@(number(i),x+offset,y,rgb@(255,0,0))

In each case the x,y will be the current coordinates you are using, and offset chosen to align all the numerical values.

Note that the pixel length (and height) of x(i) is returned by GET_TEXT_SIZE@, but you need to use TRIM since the length returned by this includes trailing blank characters.

call GET_TEXT_SIZE@( trim(adjustl(txt))//achar(0),tw,th )

This could be used in a simple DO LOOP to determine automatically the length of the longest description string and this plus and extra few pixels determines your offset (and avoids some alignment problems when you change the descriptions at a later date [however the margin may be too small]).

Re: IMPORT_FILE_IMAGE@ offsets, since you don't have a %pv, I cannot see a reason why this is necessary. You might want to try a) importing a different file (size in pixels), and/or changing the %pl graphics size. The results, what ever they are may help pinpoint where the problem lies. Are gw and gh, as well as your margins truly global values, or do you have local declarations with the same name in some of your routines? For example, consider the chaos this example could result in:

[Martin_K]

Thanks Ken!

I will do it as you suggested.

After your explaining what are the graph�s dimensions (I mixed it with window dimensions) I made some additional steps and the graph/map looks like this:



Now, the graph/map above contain all essential (from geodetical point of view) information to properly interpret the data which it contains (scale, info about horizontal and vertical coordinate system, north arrow, number of objects).
It is intuitive that the text in red in the statistic relates to the red objects in the graph (red lines), the text in blue relates to the blue objects (blue points).
Nevertheless, I will improve it as you suggested (text in black and numbers in red/blue), since sometimes too many colors can be extravagant.

Regarding the importing of JPG raster image to the graph - have a look
please to my code below:

[Kenneth_Smith]

Add the following immediately after you call to COPY_GRAPHICS_REGION@

[Martin_K]

Here is how the graph looksafter implementing your test code with rectangle:



It seems to me that my assumption was correct and it was that the destination graphics
region (its dimensions) also includes the number below tick marks (its bottom or base of the numbers) - not only axes as such
as can be seen in the picture above.
Probably this is also the reason why JPG raster image is stretched in such way that it also overlaps axes and the numbers below tick marks and ends
exactly at the base of the numbers.

So, the question is how to automatically compute these values to eliminate it.

Important note:
I moved the following code from a call-back, which loads in the JPG raster image to the beginning of my plot function which uses %PL:

[Martin_K]

John,

After moving the code as described above and using offsets -10, -15 the result is:



I meant the black strip in vertical and horizontal direction as can be seen in the picture above. So, I have to use 0,0 offset (then no black strip appears,
but overlapping remains with raster image exactly in the area, where black strips are.

The reason for black strip is clear - COPY_MODE 8913094 since it copies as follows:
The colors of the source and destination areas are combined using the Boolean AND operator.
And when they NOT EXACTLY FIT (are NOT exactly aligned) then the result is as in my picture.