|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Thu Feb 18, 2021 11:53 pm Post subject: Location a value in one dimensional vector and its display |
|
|
Hello,
I have several 1000 points irregularly distributed in a graph (with their x,y coordinates) which have also a height information contained in an input file
(in fact, the input file from which were the points read in and drawn in the graph has 3 columns - first column contains X-coordinate,
second one Y-coordinate and the third one height values.
I wrote to a binary file only height values for possible identification when searching in the bin file and I would need to display the
right height values on the corresponding point in the graph when pointing
with the cursor over a point in the graph from that one-dimensional vector written in the bin file.
Is there a function (something like location in i,j table) which could be used for this purpose?
Thanks for any advise.
Martin |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Feb 19, 2021 1:28 am Post subject: |
|
|
Nearest neighbour weighted interpolation. This would allow you construct a regular x,y grid with interpolated z data. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Fri Feb 19, 2021 9:16 am Post subject: |
|
|
I am not sure if this is relevant but there are two routines that can be used with %pl, get_plot_point@ and get_plot_data@.
get_plot_point@ can be called from within a %pl callback function in order to get the pixel coordinates of a particular point relative to the axes.
get_plot_data@ is effectively the inverse of get_plot_point@.
These are documented in ftn95.chm and in the Clearwin+ enhancements file cwplus.enh. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Fri Feb 19, 2021 11:31 am Post subject: |
|
|
Thanks to all for tips.
However, probably I did not explain it correctly what I want.
I use all of the CLRWIN+ functionalities as Paul and Robert suggested.
This is no problem and it works.
I need to show the height value on the corresponding point when hovering
with the cursor over the point (the same like this):
So, instead of the values DX,DY would be shown only H (height) value there.
BUT, I have a cloud of points in the graph, which are irregularly distributed
in the graph, since they coming from a surveying in the field and it looks as follows:
The red points are points which form some lines and they have NO height information. The blue points are - in fact - surveyed points in the field and they HAVE the height information.
So, for the blue points I would need to display the height info when pointing cursor over a blue point (like in first picture).
The input file containing the blue points, which I read in, is a TXT file
containing the X,Y,H coordinates. During the reading in the file I created
a binary file containing ONLY height information (although I could add there also X,Y). So, in fact, the BIN file is a one-dimensional vector
from which I would like to extract the right height information and display it when pointing the cursor over a blue point and to this point must be extracted the right height value from the
BIN file. I do not need to do interpolation.
For me is unclear, how to form a matrix (from one dimensional vector) and use there the function LOCATE_I_J_IN_TABLE (which successfully
works in any matrix NxM) to extract a correct
corresponding height value for the blue point
when hovering over it in the graph.
This is my problem/question.
Thanks! |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Feb 19, 2021 1:26 pm Post subject: |
|
|
It is unfortunate that the x, y data is not a uniform grid which is a prerequisite for LOCATE_I_J_IN_TABLE.
If the data was organised as x, y, z columns with i rows, for a given point xa, ya, for each row in turn calculate the Euclidean distance between (xi,yi) and (xa,ya) recording the minimum value of distance encountered so far and its corresponding i value. At the end of this process if the recorded distance is sufficiently small, you know the row i which contains the required z information. If the recorded distance remains large then you know you are not pointing to a real data point. Rather a brute force approach, which could be slow.
You could speed the process up by preprocessing the input data into a more organised form, for example dividing the initial ordering of the row data into N strips across the plane and record the starting and ending row/position of each strip, so that the search is limited to a subset of the data. If necessary the strips could be divided into squares…………… |
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Fri Feb 19, 2021 1:46 pm Post subject: |
|
|
Thanks Ken!
Really hard work.
I got the idea that I re-organize and re-write the ONE-dimensional bin file
to a matrix with the dimension NxN (N = number of points with height info)
and place the height info ONLY on the diagonal which also corresponds
the reality since only X,Y pair with the same index (when I=J) have
real height values, any other combinations (with different I,J have NO
height values.
So - for example - in case of Matrix 4x4 it would have the following
form (where H1 ... H4 are height values):
Y1 Y2 Y3 Y4
X1 H1 0 0 0
X2 0 H2 0 0
X3 0 0 H3 0
Y4 0 0 0 H4
So, only point pairs with the same index would have height values -
it means, ONLY when I=J, any other I,J combination would equal 0.
Although - to be honest, I doubt whether it is right direction. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Feb 19, 2021 2:40 pm Post subject: |
|
|
Well, Martin, in effect you erased/hid the very data that you need to do the job when you decided to put only the height data into the binary data file. Instead, you could have chosen to save the X and Y coordinates of the plotted points (which would be rounded approximations to the field x, y data) along with H. You can keep the binary file sorted with X as the first key and Y as the second key.
When the mouse is placed over a plot point, Clearwin gives your program the X and Y values of the point; with those two values, you search the sorted table using, say, binary search, to find the corresponding H, and then display that value at the cursor location. |
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Fri Feb 19, 2021 10:48 pm Post subject: |
|
|
Thanks for your hint Mecej4!
My idea with a matrix fulfilled with values on the diagonal (P(i,j), where i=j)
whereas all other P(i,j) positions would be equal 0 is hardly
practically feasible. Taking into account a Matrix of about 7000x7000
with record length of 8 bytes means 7000x7000x8 bytes what represents
extremely huge number of bytes.
So, I will try your suggestion!
Martin |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Sat Feb 20, 2021 3:12 pm Post subject: |
|
|
Many thanks Ken!
I will try to implement it later, since I am under the pressure with another thing now, which must be finished ASAP! Your code is complex and precise
- thanks again!
But, I thought about Mecej4 idea, tried it to simplify
and I got (during last night) an additional idea.
NOTE: all code is written in a MODULE except some lines in the MAIN program.
First, I abandoned the idea to write something into a BIN file. Instead,
in a subroutine which reads in the whole data set from the field (points with PointID,Y,X,H values) in a DO loop, I added INTEGER allocatable variables
for the purpose of comparison of real field data coordinates
with pixel coordinates transformed to real coordinates as follows:
Code: |
...
body_mm: do v = 1,L
read (9,15) riadok_mm(v)
15 format(a)
read(riadok_mm(v),*)point_id_mm(v), y_mm(v), x_mm(v), h_mm(v)
y_mm(v) = y_mm(v) * (-1.0d0)
x_mm(v) = x_mm(v) * (-1.0d0)
y_mm_i(v) = nint(y_mm(v))
x_mm_i(v) = nint(x_mm(v))
end do body_mm
rewind (9)
....
|
I used the NINT function to have both real field data points
and real pixel coordinates as INTEGERS for subsequent comparison test.
In the call-back PL_CB which is invoked at the line
'%`^pl[full_mouse_input]&',gw,gh,npoints,y_ok,x_ok,y_mm,x_mm,handle_pl_mm,pl_cb)
AFTER the 3 directives
Code: |
....
ylp = CLEARWIN_INFO@('GRAPHICS_MOUSE_X') ; xlp = CLEARWIN_INFO@('GRAPHICS_MOUSE_Y')
i = GET_PLOT_DATA@(ylp,xlp,ylr,xlr)
write (output_string(1),fmt(1)) ylr,',',xlr
|
I put the following code:
Code: |
ylr_i = nint(ylr); xlr_i = nint(xlr)
terenne_suradnice_vs_pixelove_suradnice: DO v = 1,L
IF (ylr_i == y_mm_i(v) .and. xlr_i == x_mm_i(v)) then
write (output_string(3), fmt(2))'H= ',H_MM(v) ! Do pravouholnika v grafike sa vypise hodnota H_MM v zmysle formatu FMT(2)
END IF
END DO terenne_suradnice_vs_pixelove_suradnice
...
|
The result can be seen here:
However, this approach has two shortcomings - one minor (negligible), the other a little bit more serious.
The minor problem is, when I move with the mouse outside the graph, after moving back to the graph area - instead of a height value value
there are some unreadable charcters displayed which quickly change back to a height value, as soon as the cursor starts moving over blue points.
To avoid this, it is necessary not to move outside the graph area.
A little bit more serious problem stems (at least I suppose so) with the use of function NINT and with the precise clicking of the cursor.
I compared the displayed HEIGHT value and horizontal coordinates with the source TXT file from which the field data were read in. The HEIGHT value is OK, but horizontal coordinates are NOT exactly the same in the
display box as in the source TXT file (they differ) sometimes very
little, sometimes more (1-3 meters).
I could post full source code of the module and main program along
with necessary 3 input TXT files along with RCX file (since part
of the main menu was created in the designer %wi) and JPG file (logo).
During the development I got some ideas to enhance/improve the %PL
options. I will post it soon under ClearWin+ topic.
Thanks for potential comments!
Martin |
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Sat Feb 20, 2021 6:18 pm Post subject: |
|
|
Additional info to my preceding post:
I solved the problem with the display of not quite "precise" coordinates.
I also added the code to display the real coordinates from the field in the yellow box which are read in from a TXT input file (in the box they are in red color - see picture below):
I checked the point with source data - and EVERYTHING is correct, both
horizontal coordinates and also height value, there are absolutely NO differences.
What newly appeared is a strange effect (the unreadable marks (underlined red in the picture above). I do not know, why they appear.
The output string for the output of X,Y,H values is as follows:
Code: |
...
CHARACTER(len=256) output_string(4), CLEARWIN_STRING@
character(len=22), parameter :: fmt(1:2)=(/'(SP,F10.2,1A,F11.2) ','(SP,2X,A3,1X,F5.2) '/)
...
|
Has anybody an idea why such signs appear?
Moreover, here I encountered a practical problem. When I checked whether
all displayed data in the yellow box are the same as in the input TXT file, I found that in the input there are several points (among about 7000 points) with the same HEIGHT value. And this adds another reason to enhance the %PL options.
Again, I will discuss it in more details in a new post in the CLRWIN+ section. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
|
Back to top |
|
|
Martin_K
Joined: 09 Apr 2020 Posts: 227
|
Posted: Sat Feb 20, 2021 10:22 pm Post subject: |
|
|
Thanks Ken!
I will have a look at this.
Finally, I removed the problem with the unreadable signs at the line displaying the heght values,
although - to be honest - I do not understand why they appeared (the unreadable signs).
Now - it looks like this:
The solution was that I shortened the string length for the H values in the output declaration of length string
from 256 characters to only 40 characters.
Code: |
CHARACTER(len=40) output_string(3)
|
Nevertheless , it does not explain me, why - when using the 256 characters buffer length - why there were displayed the unreadable signs.
I thought that when the character length is very long and is not
fully used, the remaining place for potential characters will be fulfilled
with blank spaces. Apparently, in this case it was not so and this remains
for me unclear - why.
Thanks again for your valuable help, Ken!
Last question (at least I hope so) in this context:
Is there a SNAP option/function in FTN95 (to snap the cursor to the point
in the graphic area within an aperture) which would have the user defined and changeable dimensions (the aperture)?
Martin |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Tue Feb 23, 2021 2:38 pm Post subject: |
|
|
Martin,
Here is my final offering.
Select a data point with a left mouse click. This will display X,Y,Z data at that point using tooltips. The current selection must be deselected by a right mouse click. This avoids using the %pl[full_mouse_input] option with its continuously calling of the %pl callback.
The new %pl[vscroll,hscroll] options are used to pan across the plot using scroll bars. An additional scrollbar provides a zoom function. (Note: the coordinate transforms need revisiting, this was a first hack.)
All updates to the %pl region are performed by the %dl timed call back. Simpleplot_redraw@ is only called when a change is detected, otherwise the timed call back simply returns. This is the reason for the saved variables in the %dl callback.
Paul,
The only real problem I can see, is that when the %pl[vscroll,hscroll] options are used, a small coloured square appears external to the bottom right corner of the %pl region.
https://www.dropbox.com/s/xhk84qfv2orjkkw/pl_scroll_zoom_th.f95?dl=0 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|